รายงานความคืบหน้า Asahi Linux 7.1

 (asahilinux.org)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ณ Linux 7.1 Asahi Linux กำลังดำเนินงานหลายด้านพร้อมกัน ได้แก่ การขยายการรองรับ M3, ความเข้ากันได้กับ macOS 27 beta, การถอดรหัสวิดีโอ AVD และการเปลี่ยนแปลงใน m1n1 1.6.0
  • ใน macOS 27 Golden Gate developer beta รายการบูตของ Asahi หายไปจาก Startup Disk และ boot picker แต่พาร์ทิชันและข้อมูลยังคงอยู่ และสามารถกู้คืนได้ด้วยการตั้งค่า แฟล็กการบูต APFS
  • การเปลี่ยนแปลงเฟิร์มแวร์ SMC ทำให้ค่าที่ส่งกลับของการจัดการแบตเตอรี่เปลี่ยนไป จนทำให้เกิด การปิดเครื่องฉุกเฉิน ภายใต้เงื่อนไขบางอย่าง และเคอร์เนล downstream ตั้งแต่ 7.0.12 เป็นต้นไปรองรับ firmware ABI ทั้งสองแบบแล้ว
  • ตระกูล M3 มีเสียง, การสลับความถี่ CPU, การจัดตารางงานแบบ big.LITTLE, เซนเซอร์ SMC, PCIe, WiFi, Bluetooth, NVMe, คีย์บอร์ด และแทร็กแพดทำงานบน Linux แล้ว แต่ยังไม่ถึงขั้น รองรับ Asahi Installer
  • AVD มีความคืบหน้าไปสู่การถอดรหัส AVC ด้วยฮาร์ดแวร์ผ่านเฟิร์มแวร์ของตัวเองและไดรเวอร์ V4L2 แทนเฟิร์มแวร์ของ Apple ส่วน m1n1 1.6.0 ต้องใช้ Rust สำหรับการบิลด์ stage 2 จึงมีผลกระทบต่อดิสโทรอย่างมาก

รายการบูต Asahi ที่หายไปใน macOS 27

  • รายการ Asahi ที่เห็นใน boot picker ซึ่งเปิดโดยกดปุ่มเปิดเครื่องบน Mac ค้างไว้ หรือในแอป Startup Disk ไม่ใช่พาร์ทิชันระบบปฏิบัติการจริง
  • เครื่องมือบูตของ Apple จัดการเฉพาะ “การติดตั้ง macOS ที่ถูกต้อง” ภายใน APFS container เท่านั้น ดังนั้น Asahi Installer จึงสร้าง APFS container ขนาด 2.5GB และใช้คอนฟิก macOS ขั้นต่ำที่ใส่ m1n1 ไว้เสมือนเคอร์เนล
  • วิธีนี้ทำงานโดยไม่ต้องเปลี่ยนแปลงมาตั้งแต่ macOS 12 ถึง macOS 26 และ Apple ยังแก้บั๊กบางส่วนของเครื่องมือที่เคยปรากฏเฉพาะตอนบูต raw binary ที่ไม่ใช่เคอร์เนล XNU จริงด้วย
  • หลังจาก macOS 27 Golden Gate developer beta ผู้ใช้บางส่วนพบปัญหารายการ Asahi หายไปจาก Startup Disk และ boot picker
    • จากการตรวจสอบด้วย diskutil พบว่าพาร์ทิชันที่เกี่ยวข้องกับ Asahi ยังอยู่บนดิสก์ และ ไม่มีข้อมูลสูญหาย
    • หากใช้เครื่องมือบูตของ macOS 26 บนเครื่องเดียวกัน Asahi ยังสามารถบูตได้
  • macOS Installer ตั้งค่า metadata ของ APFS ก่อนรีบูต และจากการตรวจสอบเพิ่มเติมพบว่าค่านี้เป็นแฟล็กที่ระบุว่า volume สามารถบูตได้
    • เครื่องมือบูตก่อน macOS 27 ไม่สนใจแฟล็กนี้
    • หากตั้งค่าแฟล็กนี้ด้วยตนเองบน Asahi APFS container รายการจะกลับมาแสดงใน boot picker ของ macOS 27
  • สำหรับการติดตั้ง Asahi ใหม่ Asahi Installer จะตั้งค่าแฟล็กนี้โดยอัตโนมัติ
  • มีการเพิ่มโหมดติดตั้งสำหรับแก้ไขการติดตั้งเดิมด้วย
    • หากติดตั้ง macOS 27 developer beta แล้วไม่สามารถเข้าถึง Asahi ได้ ให้รัน installer อีกครั้งและใช้ตัวเลือก “Fix macOS 27 boot picker compatibility”
  • มีการสร้างโปรแกรมสำหรับแก้ปัญหานี้จาก Linux แล้วเช่นกัน แต่ยังต้องการข้อมูลทดสอบเพิ่มเติมก่อนแจกจ่ายอัตโนมัติ
    • หากต้องการทดสอบ ให้ clone คลัง asahi-fix27 ก่อนอัปเกรดเป็น macOS 27 แล้วบิลด์และรันจาก Linux
    • หลังจากนั้น หากสามารถเลือก volume ของ Asahi เป็นเป้าหมายการบูตใน macOS ได้ แปลว่าโปรแกรมทำงานแล้ว
    • สามารถแชร์ผลลัพธ์และปัญหาได้ที่ community channels ของ Asahi

การเปลี่ยนแปลงเฟิร์มแวร์ SMC และการปิดเครื่องฉุกเฉินของไดรเวอร์แบตเตอรี่

  • macOS 27 รวมการอัปเดตเฟิร์มแวร์ของอุปกรณ์ต่อพ่วงทั้งหมดที่ใช้ global firmware รวมถึง SMC
  • SMC รับผิดชอบการจัดการแบตเตอรี่ และไดรเวอร์ Linux power supply จะสื่อสารกับ SMC เพื่อรับข้อมูลสถานะการชาร์จ แรงดัน เวลาเหลือจนแบตเตอรี่หมด และสภาพแบตเตอรี่
  • ไดรเวอร์เดียวกันนี้ยังตั้งค่า threshold สำหรับเริ่มและหยุดชาร์จผ่านอินเทอร์เฟซเฟิร์มแวร์ SMC เพื่อยืดอายุแบตเตอรี่
  • เฟิร์มแวร์ SMC ใน macOS 27 เปลี่ยนอินเทอร์เฟซการจัดการแบตเตอรี่หนึ่งรายการจาก การส่งกลับจำนวนเต็ม 32 บิต เป็น การส่งกลับ 1 ไบต์
  • การเปลี่ยนแปลงนี้ทำให้ไดรเวอร์ Asahi ตีความว่าแบตเตอรี่เสียภายใต้เงื่อนไขบางอย่าง และเริ่มปิดเครื่องฉุกเฉินเพื่อปกป้องระบบ
  • เคอร์เนล downstream มีแพตช์แล้ว และตั้งแต่ 7.0.12 เป็นต้นไป ไดรเวอร์ power supply จะจัดการ firmware ABI ได้ทั้งสองแบบ

คำเตือนเกี่ยวกับการติดตั้ง developer beta

  • ปัญหาสองอย่างที่เกิดขึ้นใน macOS 27 แสดงให้เห็นว่า developer beta เป็น developer beta จริง ๆ
  • ไม่แนะนำให้ติดตั้ง developer beta บนเครื่องที่ใช้จริงในโปรดักชัน
  • ปัญหาสองอย่างที่เกิดขึ้นจนถึงตอนนี้โชคดีที่เป็นปัญหาเล็ก แต่ไม่มีหลักประกันว่าปัญหาในอนาคตทั้งหมดจะเล็กเช่นกัน
  • การอัปเดต global firmware แทบจะถาวร และหากต้องการย้อนกลับต้องทำ DFU restore กับเครื่อง
  • ฝั่ง Asahi ใช้เครื่องสละสำหรับการทดสอบ จึงเห็นว่าผู้ใช้ไม่จำเป็นต้องนำฮาร์ดแวร์ราคาแพงและข้อมูลสำคัญไปเสี่ยง

ความคืบหน้าการรองรับตระกูล M3

  • แพลตฟอร์มคอมพิวเตอร์และการออกแบบ·ตรวจสอบ IC มีต้นทุนและใช้เวลามาก การเปลี่ยนดีไซน์เดิมโดยไม่จำเป็นจึงไม่สมเหตุสมผล
  • โครงการ Asahi อาศัยสมมติฐานว่า Apple จะไม่ทำการเปลี่ยนแปลงที่ทำให้แพลตฟอร์มและ IC แตกต่างจนพังอยู่เรื่อย ๆ และโดยรวมก็เป็นไปตามนั้น ยกเว้นบล็อก SoC ขนาดใหญ่ที่เปลี่ยนง่ายตามแต่ละเจเนอเรชัน เช่น GPU

  • เอาต์พุตเสียง

    • เสียงในโน้ตบุ๊ก Apple Silicon ใช้ IC และบล็อก SoC หลายตัว
    • มาตรฐานโดยพฤตินัยของอุตสาหกรรมสำหรับ IC เสียงคือ I2S ซึ่งเป็นบัสบนพื้นฐาน I2C ที่ปรับให้เหมาะกับข้อมูลเสียง
    • คอนโทรลเลอร์ I2S ของ Apple และ Apple NCO ซึ่งเป็นแหล่งสัญญาณนาฬิกาที่เสถียร ไม่ได้เปลี่ยนไปตั้งแต่ M1
    • Apple ใช้ชิปแอมป์ลำโพงและเฮดเซ็ตแบบเดียวกันในเครื่อง Apple Silicon เกือบทั้งหมด
    • งานที่จำเป็นเมื่อเพิ่มการรองรับลำโพงและช่องเสียบหูฟังให้เครื่อง M3 ส่วนใหญ่เป็นการเพิ่ม Devicetree เล็กน้อย และไฟล์คอนฟิกของ asahi-audio, speakersafetyd
    • เครื่อง M3 รองรับ เอาต์พุตเสียงคุณภาพสูง บน Asahi Linux

  • ความถี่ CPU และการจัดตารางงาน big.LITTLE

    • เครื่อง M3 รองรับการสลับความถี่ CPU และ การจัดตารางงาน big.LITTLE ที่เหมาะสมแล้วเช่นกัน
    • Apple ไม่ได้เปลี่ยนวิธีสลับความถี่ CPU ตั้งแต่ M2 รุ่นพื้นฐาน
    • SoC M3, M3 Pro, M3 Max, M3 Ultra ทำงานได้กับไดรเวอร์ cpufreq เดิมโดยแก้เฉพาะ Devicetree
    • งานจะถูกวางบนคอร์ประหยัดพลังงานหรือคอร์ประสิทธิภาพอย่างชาญฉลาดขึ้นตามความต้องการ และคอร์ CPU จะเพิ่มหรือลดคล็อกตามโหลด
    • การเปลี่ยนแปลงนี้ช่วยทั้งประหยัดพลังงานและเพิ่มประสิทธิภาพ

  • เซนเซอร์และอุปกรณ์หลัก

    • เฟิร์มแวร์ SMC แตกต่างกันระหว่างเครื่องไม่มากนัก การรองรับเซนเซอร์ฮาร์ดแวร์ SMC จึงต้องการเพียงการแก้ Devicetree บางอย่าง
    • บนเครื่องตระกูล M3 ไดรเวอร์ของ PCIe, WiFi, Bluetooth, NVMe, คีย์บอร์ด, แทร็กแพด และบล็อก SoC หลักอื่น ๆ ก็ทำงานบน Linux แล้ว
    • งานส่วนใหญ่ในส่วนนี้ทำโดย Yureka ซึ่งทำงานกับ m1n1 และ Linux บนเครื่องตระกูล M3 มาโดยตลอด
    • ยังต้องมีงานเพิ่มเติมก่อนเปิดใช้การรองรับ Asahi Installer บนเครื่อง M3 แต่ความคืบหน้ารวดเร็ว

การถอดรหัสวิดีโอ AVD และเฟิร์มแวร์ของตัวเอง

  • ฮาร์ดแวร์ที่ซับซ้อนส่วนใหญ่บนแพลตฟอร์ม Apple Silicon ใช้ blob เฟิร์มแวร์ที่ซับซ้อน
  • เฟิร์มแวร์จำนวนมากอิงกับ RTKit ซึ่งเป็นเฟรมเวิร์กคล้าย RTOS ที่ Apple ใช้เพื่อให้มีอินเทอร์เฟซค่อนข้างมาตรฐานระหว่างเคอร์เนลกับบล็อกฮาร์ดแวร์หลายตัว
  • บล็อกบางส่วน เช่น DCP และ AOP อิงกับ RTKit แล้วเพิ่ม abstraction อีกชั้นชื่อ EPIC
  • บางกรณีใช้เฟิร์มแวร์จากบุคคลที่สามที่ Apple ไม่ได้ควบคุมโดยตรง เช่น ชิปเซ็ต Broadcom WiFi/Bluetooth
  • Apple Video Decoder หรือ AVD ใช้เฟิร์มแวร์ที่มีโครงสร้างแยกต่างหาก ไม่ใช่ RTKit หรือ EPIC

  • โครงสร้าง AVD และปัญหาของวิธีเดิม

    • ฮาร์ดแวร์ AVD ใกล้เคียงกับ ARM Cortex-M3 ที่ควบคุมยูนิตฮาร์ดแวร์ฟังก์ชันตายตัวสำหรับถอดรหัสเฟรมวิดีโอ AVC(H.264), HEVC(H.265), VP9 และ AV1 บน SoC รุ่นใหม่
    • Cortex-M3 มีอินเทอร์เฟซให้ XNU ชี้ไปยังข้อมูลวิดีโอ และรัน blob เฟิร์มแวร์ที่ตั้งค่าฮาร์ดแวร์ตัวถอดรหัสจริง
    • Apple ใส่เฟิร์มแวร์ AVD และข้อมูลการตั้งค่าไว้ด้วยกัน ภายใน AVD kext
    • แต่ละ SoC ใช้ตัวแปร AVD ที่ต่างกันเล็กน้อย ทำให้เกิดปัญหาด้านโลจิสติกส์ที่ Asahi Installer ต้องติดตามและอัปเดต offset ของข้อมูลเฟิร์มแวร์ภายใน kext อย่างต่อเนื่อง

  • แนวทางเฟิร์มแวร์ของตัวเอง

    • เฟิร์มแวร์ AVD ที่ XNU โหลดไม่ได้ถูกตรวจสอบบน Cortex-M3
    • เมื่อได้รับสัญญาณ จะเริ่มรันจาก reset vector ดังนั้นโค้ดที่อยู่ข้างในจริง ๆ ไม่ว่าจะเป็นอะไรก็จะถูกรัน
    • บทบาทของเฟิร์มแวร์โดยพื้นฐานคือการ abstract ฮาร์ดแวร์ตัวถอดรหัสวิดีโอ ดังนั้นหากติดตั้งเฉพาะ interrupt handler ของแต่ละบล็อกฮาร์ดแวร์ ก็สามารถโปรแกรมจากไดรเวอร์ Linux ได้โดยตรง
    • เนื่องจากเป็นโค้ด Cortex-M3 มาตรฐาน เฟิร์มแวร์ AVD จึงรันใน emulator ได้
    • QEMU รองรับการรันทีละขั้นและการตรวจสอบการทำงานของบัสและรีจิสเตอร์
    • Jamie, R, Eileen เคยร่วมกันทำ reverse engineering คำสั่งและรูปแบบข้อมูลที่จำเป็นสำหรับตัวถอดรหัส AVC และ VP9
    • XNU kext ยังใช้ tunable เฉพาะของ AVD แต่ละ revision ด้วย
    • ยังไม่แน่ชัดทั้งหมดว่าค่าเหล่านี้ทำอะไร
    • การนำไปใช้ใกล้เคียงกับการ replay การเขียน MMIO ของ XNU
    • ต้องติดตามแต่ละ AVD revision, ชุด tunable และ revision เป้าหมายที่นำไปใช้
    • สิ่งนี้ดูแลให้เป็นที่น่าพอใจในไดรเวอร์ upstream Linux kernel ได้ยาก จึงเหมาะกว่าที่จะเก็บส่วนนี้ไว้ในเฟิร์มแวร์ด้วย

  • ไดรเวอร์ V4L2 AVC

    • ผู้ร่วมพัฒนารายใหม่ sofus สร้าง custom AVD firmware พื้นฐานที่ติดตั้ง interrupt handler และใช้ tunable ของแต่ละตัวแปร
    • จากฐานนี้ เขาเขียน ไดรเวอร์ V4L2 ที่ทำงานได้สำหรับฮาร์ดแวร์ AVC
    • ฮาร์ดแวร์สามารถถอดรหัสวิดีโอ AVC แบบ 10-bit ได้ถึง 4K
    • ทำงานได้ดีกับซอฟต์แวร์ที่ implement V4L2 Request API
    • หากคงเฟิร์มแวร์ให้เรียบง่ายและไร้สถานะ แล้วให้ userspace กับเคอร์เนลรับผิดชอบการ parse ข้อมูลวิดีโอและการโปรแกรมตัวถอดรหัส ก็จะทำให้รองรับ API เร่งความเร็ววิดีโออื่น ๆ เช่น VA-API หรือ Vulkan Video ได้ง่ายขึ้นในอนาคต
    • ยังมีงานที่ต้องทำก่อนจะให้ผู้ใช้ใช้งานการรองรับ AVD ได้
    • AVD รองรับ VP9, HEVC และ AV1 บน SoC บางรุ่นด้วย แต่ยังไม่ได้ implement
    • ยังต้องทดสอบ quirks ของอุปกรณ์บางรุ่นและสะท้อนกลับเข้าไปในไดรเวอร์
    • เป้าหมายคือรูปแบบที่แจกจ่ายได้ในอนาคตที่ไม่ไกลนัก

m1n1 1.6.0 release

  • m1n1 1.6.0 ถูก tag แล้ว และเป็น release ที่มีผลกระทบมากในมุมมองของดิสโทร
  • เวอร์ชันนี้เป็นครั้งแรกที่ต้องใช้ Rust สำหรับการบิลด์ stage 2
  • ก่อนหน้านี้ Rust ถูกใช้เฉพาะเมื่อบิลด์โดยใส่การรองรับ chainloading
  • stage 1 m1n1 แทนที่เคอร์เนล XNU ในเครื่องมือบูตของ Apple และใช้เพียงเพื่อ mount EFI System Partition แล้ว chainload stage 2 m1n1 จากที่นั่น
  • เมื่อย้ายการเริ่มต้น GPU ไปไว้ใน m1n1 ไดรเวอร์เคอร์เนลจึงไม่ต้องจัดการค่าทศนิยมในข้อมูลการเริ่มต้นฮาร์ดแวร์ของ Apple อีกต่อไป และ Devicetree binding ก็ง่ายขึ้นมาก
  • เวอร์ชันของไดรเวอร์ GPU ที่จะส่งไปยัง Linux Kernel Mailing List ในอนาคตจะอาศัยสมมติฐานว่า m1n1 ทำการเริ่มต้นนี้
  • โค้ด parsing ของ Apple Device Tree ก็ถูกพอร์ตไปเป็น Rust แล้ว และถูกใช้ในส่วนอื่น ๆ แทบทั้งหมดของ m1n1

  • การบิลด์และ target

    • เนื่องจาก m1n1 โดยพฤตินัยเป็นเฟิร์มแวร์ จึงใช้ Rust แบบ no_std และ target เป็น aarch64-none-softfloat
    • หากไม่ต้องการดึง dependency ที่ไม่จำเป็นเข้ามา สามารถส่ง BUILDSTD=1 ให้ make เพื่อบิลด์ core และ alloc ได้โดยไม่ต้องติดตั้ง toolchain softfloat ทั้งชุด

  • การเตรียมพร้อมสำหรับ M3, M4, A18 Pro

    • 1.6.0 รวมการปรับปรุงหลายอย่างสำหรับการรองรับตระกูล M3
    • รองรับคอนโทรลเลอร์ SPMI
    • รองรับการเริ่มต้น PCIe
    • รองรับการ tunnel โดยตรงจาก DebugUSB ไปยัง UART ฮาร์ดแวร์ของ SoC ผ่าน kisd
    • การ tunnel DebugUSB UART สามารถให้ฟังก์ชันได้ใกล้เคียงกับ Central Scrutiniser
    • งานส่วนใหญ่ในส่วนนี้ก็เป็นผลงานของ Yureka เช่นกัน
    • งานพื้นฐานสำหรับรองรับ M4 และ A18 Pro หรือ MacBook Neo ก็กำลังดำเนินอยู่
    • จัดการ non-macOS boot mode ของ Apple ได้ดีขึ้น
    • รองรับ power domain metadata ใหม่ใน Apple Device Tree

การสนับสนุนและผู้ร่วมพัฒนา

  • Asahi Linux ขอขอบคุณผู้สนับสนุนผ่าน GitHub Sponsors และ Open Collective
  • ด้วยการสนับสนุนนี้ จึงสามารถเดินหน้าฟีเจอร์ M1·M2 ที่ยังไม่เสร็จ, การรองรับ M3·M4·A18 Pro และการสนับสนุนผู้ร่วมพัฒนารายใหม่ได้ต่อไป

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความเห็นจาก Hacker News

  • ข้อความที่ว่า “มาตรฐานอุตสาหกรรมโดยพฤตินัยของ audio IC คือ I²S ซึ่งเป็นบัสที่อิง I²C และปรับให้เหมาะกับข้อมูลเสียง” นั้นไม่ถูกต้องนัก I²S ไม่เกี่ยวข้องกับ I²C
    ชิป I²S ส่วนใหญ่มีอินเทอร์เฟซ I²C ติดมาด้วยก็จริง แต่เป็นเพราะ I²S ขนส่งแค่ข้อมูลเสียงดิบ และไม่มีสัญญาณเสริมอย่างการควบคุมระดับเสียงหรือการตั้งค่านาฬิกา
    อย่างไรก็ตาม นั่นเป็นอินเทอร์เฟซแยกต่างหาก และอาจเป็น SPI แทน I²C ก็ได้ ในทางปฏิบัติ SPI ใกล้เคียงกับ I²S มากกว่า I²C

    • ใช่เลย I²S ใกล้กับ SPI มากกว่ามาก
      ที่ทั้งคู่ใช้รูปแบบการตั้งชื่อคล้ายกันก็เพราะ Philips Semiconductor (ปัจจุบันคือ NXP) เป็นผู้สร้างทั้งสองอย่าง
    • I²S เป็นการออกแบบที่เรียบง่ายอย่างน่าทึ่ง ไม่มีการจับมือของโปรโตคอล มีแค่ PCM ดิบไหลผ่าน
      ฉันชอบที่มันถูกออกแบบมาให้ไม่มีปัญหาความเข้ากันได้ แม้ผู้ส่งและผู้รับจะใช้ความลึกบิตของตัวอย่างต่างกันในคนละทิศก็ตาม
      https://web.archive.org/web/20070102004400/http://www.nxp.co...

  • น่าทึ่งจริง ๆ ที่คนจำนวนน้อยแต่มีแรงจูงใจสามารถแก้ปัญหาแบบนี้ได้

    • ปัญหาจำนวนมากยังไม่ได้รับการแก้เลย ตัวอย่างเช่น อินเทอร์เฟซจัดการพลังงาน PSCI ของ Apple Silicon ยังคงเป็นปริศนา
      device tree ของ Linux ตัวอื่นมีโค้ด PSCI อยู่ แต่ไม่มีใครรู้ว่า Apple นำมันไปใช้อย่างไร ดังนั้นผู้ใช้ Asahi จึงต้องพึ่งแฮ็กเพื่อไม่ให้แบตเตอรี่ลดลงเรื่อย ๆ มาเกือบ 5 ปีแล้ว และเท่าที่ฉันรู้ก็ยังไม่มีแนวทางแก้ที่ดูมีหวัง
      นี่คือทั้งด้านสว่างและด้านมืดของการทำวิศวกรรมย้อนกลับ การที่อุปกรณ์เหล่านี้มีไดรเวอร์ Vulkan 1.2 แบบเนทีฟนั้นยอดเยี่ยมมาก แต่กว่าจะมาถึงจุดนั้นก็ใช้เวลาหลายปี ทุกวันนี้แม้จะผ่านไป 7 ปีนับจาก Apple Silicon เปิดตัว ก็ยังมีปัญหาที่ไม่ถูกแก้อยู่ และฮาร์ดแวร์รุ่นใหม่ล่าสุดส่วนใหญ่ก็ยังไม่รองรับโดยรวม สุดท้ายก็กลับมาสู่บทเรียนเดิมที่ผู้ใช้ Linux พูดกันมาตลอดว่า ไดรเวอร์ปิดไม่ค่อยดีนัก

  • ส่วนที่น่ากังวลเป็นพิเศษคือ CM3 ไม่ได้ตรวจสอบเฟิร์มแวร์ที่ XNU โหลด และเมื่อได้รับสัญญาณก็จะเริ่มรันจากรีเซ็ตเวกเตอร์ไม่ว่าเนื้อหาจริงจะเป็นอะไร
    ความสำเร็จในการเขียน เฟิร์มแวร์แบบกำหนดเอง เพื่อต่อกรกับเป้าหมายที่เป็นกรรมสิทธิ์และเปลี่ยนแปลงตลอดเวลานั้นยิ่งใหญ่เกินจะบรรยาย แต่แยกจากความหวังว่า Apple จะไม่ตั้งใจทำให้ระบบปฏิบัติการของบุคคลที่สามพังอยู่เรื่อย ๆ แล้ว ก็ไม่ใช่เรื่องไกลตัวเลยที่พวกเขาอาจนำ ลายเซ็นฮาร์ดแวร์ มาใช้กับเฟิร์มแวร์บล็อบหรือข้อมูลที่ป้อนให้การโปรแกรมฮาร์ดแวร์ขณะรันไทม์ จากมุมมองของ Apple นี่อาจเป็นข้อกังวลด้านความปลอดภัยที่สมเหตุสมผล ถึงอย่างนั้นก็หวังว่าการเสี่ยงครั้งนี้จะสำเร็จ

  • สงสัยว่าสิ่งนี้จะคงเป็น Fedora “remix” ไปตลอดหรือไม่ สักวันจะมี การรองรับแบบอัปสตรีม จนสามารถรันดิสโทรที่อิง Debian ได้ไหม?
    รู้สึกเหมือนครั้งสุดท้ายที่ฉันใช้ดิสโทรสาย RPM คือเกือบ 20 ปีก่อน

    • พวกเขากำลังส่งแพตช์ขึ้นอัปสตรีม ดังนั้นสุดท้ายไดรเวอร์ที่จำเป็นก็น่าจะเข้าไปอยู่ใน upstream Linux
      แน่นอนว่า kernel fork ก็เป็นโอเพนซอร์สเช่นกัน จึงไม่มีอะไรขวางไม่ให้คุณเอา Debian aarch64 root มาแล้วคอมไพล์เคอร์เนล Asahi เอง หรือใช้บิลด์ของ Fedora แล้วประกอบ Debian สำหรับอุปกรณ์นี้เอง เพียงแต่ต้องลงแรงหน่อย
      ถ้า Ubuntu ใช้ได้ ก็มี Ubuntu Asahi ด้วย: https://ubuntuasahi.org/
      ลองค้นดูแล้วก็เจอหน้า wiki นี้ด้วย: https://wiki.debian.org/InstallingDebianOn/Apple/M1
    • ฉันกลับชอบตรงกันข้าม เลยขำกับคอมเมนต์นี้นิดหน่อย ฉันชอบ ดิสโทรสาย RPM และใช้ Fedora เป็นหลักแทบทุกที่ แม้แต่บน M1 Ultra Mac Studio ก็ใช้ Fedora Asahi Remix และมีแค่บาง cloud instance เท่านั้นที่ใช้ Ubuntu กับ Debian เป็นครั้งคราว
      ดังนั้นฉันเข้าใจความรู้สึกที่อยากใช้ดิสโทรเดิมที่คุ้นเคยต่อไป เพราะงานน้อยกว่า และไม่ต้องจำความแตกต่างเล็ก ๆ น้อย ๆ ของโครงสร้างมากนัก ถึงอย่างนั้นเวลาโดนบังคับให้ใช้ดิสโทรใหม่ เช่น ตอนที่ Asahi ออกรุ่นแรกและรองรับเฉพาะ Arch Linux ARM ฉันก็ไม่เคยเสียใจกับการเรียนรู้เล็ก ๆ ที่ได้จากมัน
    • ยังใช้ Arch ได้อยู่ และก็มี Ubuntu Asahi
      พวกเขากำลังทำงานอัปสตรีมอย่างหนักก็ด้วยเหตุผลนี้เอง เพื่อให้ทุกดิสโทรพอร์ตมาได้ง่ายขึ้น
      https://ubuntuasahi.org/
    • ทีม Bananas กำลังทำงานเพื่อให้ Debian มาตรฐานทำงานบน Apple Silicon และตอนนี้ก็มีวิธีติดตั้งโดยเพิ่มคลังแพ็กเกจแบบไม่เป็นทางการได้แล้ว: https://wiki.debian.org/InstallingDebianOn/Apple/M1#The_Bana...
      แต่ฉันยังไม่ได้ลองติดตั้งเอง
    • linux-asahi ใช้ได้บน Void Linux ด้วย
      https://voidlinux.org/download/#arm%20platforms
      มันเป็นแพ็กเกจ Linux ปกติภายในดิสโทร: https://github.com/void-linux/void-packages/tree/master/srcp...

  • ดีใจที่เห็นว่า การรองรับ M3 คืบหน้าไปด้วยดี
    ครั้งแรกที่มีการพูดถึงการเริ่มทำงานเพื่อเพิ่มการรองรับ M3 คือในเดือนกุมภาพันธ์
    “เป็นเวลาพอสมควรแล้วที่ m1n1 มีการรองรับพื้นฐานสำหรับอุปกรณ์ตระกูล M3 สิ่งที่ยังขาดคือ device tree ของแต่ละอุปกรณ์ และแพตช์ไดรเวอร์เคอร์เนล Linux เพื่อรองรับลักษณะฮาร์ดแวร์เฉพาะของ M3 และการเปลี่ยนแปลงต่าง ๆ จาก M2 เราตั้งใจมาโดยตลอดว่าจะทำให้งานนี้เป็นรูปธรรมมากขึ้นเมื่อชุดแพตช์เดิมดูแลง่ายขึ้น”
    https://asahilinux.org/2026/02/progress-report-6-19/

  • ตื่นเต้นที่ได้ยินว่ากำลังทำ ไดรเวอร์ AVD

  • บน Mac ตั้งแต่ M1 ขึ้นไป ถ้าใช้ ffmpeg หรือ VLC จะใช้ AVD ไหม?

  • Asahi อาจเป็นทางเลือกที่ใช้งานได้จริง แต่ด้วยเงินทุนระดับนี้และทีมงานขนาดเล็ก ความเร็วในการพัฒนาก็ดูจะช้าเกินเลี่ยงไม่ได้
    อย่างที่บทความบอกไว้ งานฐานรากที่วางไว้แล้วมีอยู่และก็มีผลงานจากมันจริง แต่สุดท้ายทุกปีก็มี Mac รุ่นใหม่ออกมาพร้อมชิปใหม่ ไมโครคอนโทรลเลอร์จำนวนมาก และการเปลี่ยนแปลงของ GPU จนตามไม่ทันอยู่ดี นั่นจึงเป็นเหตุผลที่ทีม Asahi เองก็โฟกัสกับรุ่น M1 และ M2 มากกว่า
    ถึงอย่างนั้น ตอนนี้ทั้งสองรุ่นก็ยังมีปัญหาเรื่องการจัดการพลังงานขณะว่างและการทำ Alt-DP อยู่ ทำให้หลายคนยังย้ายมาใช้ไม่ได้ พอถึงเวลาที่ปัญหาเหล่านี้ถูกเก็บงานเรียบร้อย มูลค่าของเครื่องก็น่าจะตกลงไปมากแล้ว
    การที่คนจำนวนน้อยทำได้ขนาดนี้ถือเป็นปาฏิหาริย์ แต่ถึงจะได้รับการรายงานข่าวจากสื่ออย่างกว้างขวาง สุดท้ายความมุ่งมั่นและแรงจูงใจของทีมก็ดูเหมือนจะลดลง และดูเหมือนว่าแม้แต่ M1 Air ก็อาจจะทำไม่เสร็จสมบูรณ์

    • มากกว่าจะเป็น "ความเร็วในการพัฒนาช้าเกินเลี่ยงไม่ได้" ประเด็นคือเมื่อทีมผู้นำชุดใหม่เข้ามา พวกเขาประกาศว่าจะให้ความสำคัญกับการ upstream งานเดิม มากกว่าการเพิ่มการรองรับฮาร์ดแวร์ใหม่ล่าสุด
      การ upstream การเปลี่ยนแปลงเข้าเคอร์เนลใช้เวลาพอสมควร
      ตอนนี้ก็ประกาศแล้วว่าเริ่มทำงานกับ M3 ตั้งแต่เดือนกุมภาพันธ์ และความคืบหน้าก็ดูดี
      “นอกเหนือจากที่กล่าวมาข้างต้น ไดรเวอร์สำหรับ PCIe, WiFi, Bluetooth, NVMe, คีย์บอร์ด, แทร็กแพด และบล็อก SoC หลักอื่น ๆ บนอุปกรณ์ตระกูล M3 ก็ทำงานบน Linux ได้แล้ว งานส่วนใหญ่นี้ Yureka เป็นคนทำ และเธอก็แฮ็กทั้ง m1n1 และ Linux บนอุปกรณ์ตระกูล M3 อย่างต่อเนื่องและเข้มข้นมาระยะหนึ่งแล้ว ยังมีทางอีกไกลก่อนที่ Asahi Installer จะเริ่มรองรับอุปกรณ์เหล่านี้ได้ แต่ความคืบหน้าเร็วมาก โปรดติดตาม!”
      นี่ดูใกล้เคียงกับภาพของคนเก่ง ๆ ที่กำลังทำ งานอย่างละเอียดรอบคอบ มากกว่าจะเป็นหายนะ
    • ถ้าทุก ๆ สองสามปีสามารถตั้งเป้าแค่เครื่องรุ่นหนึ่งแล้วทำให้มันใช้งานได้ดีจริง ก็ยังดีกว่าไม่มีทางเลือกอื่นเลยมาก
      การรองรับ M1 ทุกวันนี้ค่อนข้างใช้งานได้ดีแล้ว และอย่างน้อยงานบางส่วนก็น่าจะต่อยอดไปยังอุปกรณ์ในอนาคตได้ มันไม่ใช่ภาพสวยหรูทั้งหมด แต่ก็ไม่ใช่โครงการที่ถูกกำหนดให้ล้มเหลวตั้งแต่ต้น

  • คงจะดีมากถ้า Apple สนับสนุนเงินให้ทีมเล็ก ๆ เปิดเอกสารและไดรเวอร์บางส่วนเป็นโอเพนซอร์สเพื่อช่วย Asahi
    แน่นอนว่ารู้แหละว่าคงไม่ทำ แต่ฝันได้ Apple แทบไม่ต้องใช้เงินมากเลย และถ้าทำแบบนั้น ฮาร์ดแวร์ของตัวเองก็คงยิ่งกลายเป็นมาตรฐานโดยพฤตินัยในหมู่วิศวกร Silicon Valley มากขึ้น

    • Hypervisor framework ของ Apple เองก็ใกล้เคียงกับสิ่งนั้นพอสมควร ผมเลยรัน Fedora และ Arch Linux builds ด้วยแอป UTM โดยตั้งค่าให้ใช้ Apple Silicon virtualization ไม่ใช่การ emulation และ UTM ก็เป็น wrapper ครอบเฟรมเวิร์กนั้นอีกที
      มันยอดเยี่ยมมากจนทำให้ผมลบ Asahi แล้วฟอร์แมตใหม่ไปเมื่อหลายปีก่อน
      https://developer.apple.com/documentation/hypervisor
      https://docs.getutm.app/installation/macos/

  • สงสัยว่าเมื่อไม่นานมานี้ Asahi ใช้ โมเดลภาษาขนาดใหญ่ ไปมากแค่ไหนแล้ว มันเป็นเครื่องมือที่ทรงพลังมากสำหรับงานวิศวกรรมย้อนกลับ เคยมีเขียนเรื่องนี้ไว้บ้างไหม?

  • สงสัยว่ากระบวนการพัฒนา/CI ของโปรเจกต์นี้หน้าตาเป็นอย่างไร
    สุดท้ายแล้วทุกครั้งต้องโหลดบิลด์ลงฮาร์ดแวร์เฉพาะแบบแมนนวลหรือเปล่า หรือมีขั้นไหนที่ ทำอัตโนมัติ ได้บ้าง?

    • m1n1 ทำอะไรน่าสนใจไว้มากทีเดียวตรงนี้: https://asahilinux.org/docs/sw/tethered-boot/
      มันเพิ่มชั้นที่บางมากไว้ระหว่างฮาร์ดแวร์จริงกับเคอร์เนล โดยไม่ไปรบกวนพฤติกรรม I/O ของฮาร์ดแวร์ แต่ช่วยให้ควบคุมและทำงานโหลดเคอร์เนลกับดีบักจากระยะไกลแบบอัตโนมัติได้