Android กับ RISC-V: สิ่งที่ควรรู้เพื่อเตรียมตัว

 (opensource.googleblog.com)
2 คะแนน โดย GN⁺ 2023-11-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Google กำลังเพิ่ม การรองรับ RISC-V ลงใน AOSP เพื่อขยาย Android ไปยังสถาปัตยกรรม CPU ใหม่ และกำลังขยายจากขั้นทดลองไปสู่ความร่วมมือระดับระบบนิเวศ
  • การรองรับระยะแรกยึดตาม โปรไฟล์ rva22 และส่วนขยาย vector·vector crypto โดยมุ่งเน้นให้ชุดความสามารถตรงกับสิ่งที่จำเป็นต่อการส่งมอบสมรรถนะที่ Android คาดหวัง
  • ตอนนี้ก็สามารถ build·test·run Android สำหรับ RISC-V ได้ด้วย Cuttlefish แล้ว แต่ แบ็กเอนด์ ART และการปรับแต่งคอมไพเลอร์ยังไม่เสร็จสมบูรณ์
  • ช่วงปลายปี 2023 คาดว่าจะมี การยืนยัน NDK ABI และ canary build บน CI สาธารณะ ส่วนปี 2024 มีแผนเปิดอีมูเลเตอร์สาธารณะสำหรับทดสอบหลายฟอร์มแฟกเตอร์
  • การพอร์ต Android เพียงอย่างเดียวยังไม่พอ ดังนั้น Google จึงกำลังเตรียมสภาพแวดล้อมการพัฒนาแอปไปพร้อมกันกับ RISE Project, RISC-V International และชุมชน toolchain·support library

การรองรับ RISC-V ที่กำลังเข้ามาใน Android

  • Android เป็น ระบบปฏิบัติการโอเพนซอร์ส ที่รองรับอุปกรณ์หลายประเภทและสถาปัตยกรรม CPU หลายแบบ และกำลังเพิ่ม RISC-V เป็นแพลตฟอร์มใหม่
  • RISC-V คือสถาปัตยกรรมชุดคำสั่ง (ISA) แบบฟรีและเปิดกว้าง เป็นแนวทางที่ต้องการนำรูปแบบความร่วมมือของซอฟต์แวร์โอเพนซอร์สในระดับอุตสาหกรรมมาสู่ระบบนิเวศฮาร์ดแวร์
  • หลังถูกสร้างขึ้นที่ UC Berkeley เมื่อ 10 ปีก่อน ก็ถูกนำไปใช้อย่างรวดเร็วในด้าน embedded และไมโครคอนโทรลเลอร์ และช่วงหลังได้ขยายไปสู่ accelerator·server·mobile computing

จากการรับแพตช์สู่ช่วงสุกงอมของการรองรับ

  • Google ประกาศในงาน RISC-V Summit เดือนพฤศจิกายน 2022 ว่าเริ่มรับ แพตช์ RISC-V สำหรับ Android
  • ตอนนี้ได้ก้าวพ้นจากการรับแพตช์อย่างเดียว ไปสู่ขั้นการทำให้การรองรับ RISC-V บน Android เติบโตเต็มที่มากขึ้น
  • RISC-V เป็น ISA แบบโมดูลาร์จึงมีส่วนขยายให้เลือกมากมาย ดังนั้นหากต้องการมอบประสิทธิภาพสูงตามที่ Android คาดหวัง จำเป็นต้องกำหนดชุดความสามารถขั้นต่ำในระยะแรก
    • เกณฑ์นี้รวม โปรไฟล์ rva22
    • รวมส่วนขยาย vector และ vector crypto ด้วย

สภาพแวดล้อม AOSP ที่ build·run ได้บนเครื่องโลคัล

  • การรองรับ Android สำหรับ RISC-V สามารถ build·test·run บนเครื่องโลคัลผ่าน Cuttlefish Virtual Device ได้เหมือนกับแพลตฟอร์มเป้าหมายอื่นของ AOSP
  • โค้ดที่เกี่ยวข้องดูได้ที่ google/android-riscv64
  • ตัวอย่างการรันมีดังนี้
$ lunch aosp_cf_riscv64_phone-userdebug
$ m -j
$ launch_cvd -cpus=8 -memory_mb=8192
  • สามารถเชื่อมต่อกับอุปกรณ์ที่กำลังรันอยู่เพื่อโต้ตอบได้ผ่าน vncviewer

งานด้านการปรับแต่งที่ยังเหลืออยู่

  • แพตช์ในปัจจุบันช่วยให้สามารถ build และรัน ประสบการณ์ Android Open Source Project พื้นฐาน ได้ แต่ยังไม่ใช่สถานะที่ปรับแต่งสมบูรณ์แล้ว
  • งานในส่วน แบ็กเอนด์ปรับแต่ง ART ของ Android Runtime ยังอยู่ระหว่างดำเนินการ
  • AOSP, โปรเจกต์ภายนอก และคอมไพเลอร์ ยังไปไม่ถึงระดับที่ใช้ประโยชน์จากส่วนขยายที่ได้รับการรับรองล่าสุดได้อย่างเต็มที่ พร้อมสร้างโค้ดที่ถูกปรับแต่งและย่อขนาดได้สมบูรณ์
  • เป้าหมายของระยะนี้ใกล้เคียงกับการเปิดให้ ทดลองและทำงานร่วมกัน มากกว่าการเป็นสภาพแวดล้อมผลิตภัณฑ์ที่เสร็จสมบูรณ์

โรดแมปการทดสอบสำหรับนักพัฒนาและอีมูเลเตอร์

  • คาดว่าช่วงปลายปี 2023 จะมีการยืนยัน NDK ABI
  • และจะมี canary build บน CI สาธารณะของ Android ตามมาในไม่ช้า
  • มีแผนรองรับการรัน RISC-V บน x86-64 และ ARM64 เพื่อให้ทดสอบแอป Android แบบ riscv64 บนเครื่องโฮสต์ได้ง่ายขึ้น
  • ในปี 2024 มีแผนเปิดอีมูเลเตอร์สาธารณะที่มีฟังก์ชันครบชุดสำหรับทดสอบแอปบนฟอร์มแฟกเตอร์อุปกรณ์ที่หลากหลาย
  • ตามประกาศความร่วมมือกับ Qualcomm ฟอร์มแฟกเตอร์แรกคาดว่าจะเป็น อุปกรณ์สวมใส่

ความร่วมมือในระบบนิเวศและ RISE Project

  • การพอร์ตเฉพาะตัวระบบปฏิบัติการ Android เองยังไม่เพียงพอ จึงต้องมีการเตรียมความพร้อมของระบบนิเวศซอฟต์แวร์รอบข้างไปพร้อมกัน
  • Google กำลังทำงานร่วมกับชุมชนและ RISE
  • RISE Project ถูกสร้างขึ้นเพื่อเร่งความพร้อมใช้งานของซอฟต์แวร์บนคอร์โปรเซสเซอร์ RISC-V ที่มีประสิทธิภาพสูงและประหยัดพลังงาน ซึ่งสามารถรันระบบปฏิบัติการระดับสูงได้
  • ขอบเขตการใช้งานไม่ได้มีแค่ Android แต่รวมถึง Linux และระบบปฏิบัติการอื่น ๆ ด้วย
  • โดเมนแอปพลิเคชันเป้าหมายยังรวมถึงการประมวลผลสมรรถนะสูง
  • บริษัทที่เข้าร่วม ได้แก่ Andes, Google, Intel, Imagination Technologies, MediaTek, Nvidia, Qualcomm Technologies, Red Hat, Rivos, Samsung, SiFive, T-Head และ Ventana

มาตรฐานและเส้นทางการมีส่วนร่วม

  • Google ยังคงขยายการลงทุนใน RISC-V International อย่างต่อเนื่อง นอกเหนือจากสถานะ Premium member และการมีส่วนร่วมในบอร์ดบริหารที่มีอยู่แล้ว
  • ผู้มีส่วนร่วมหลายรายรับบทบาทสำคัญใน horizontal committee, working group และ technical committee เพื่อมีส่วนร่วมในการออกแบบและให้สัตยาบันสเปก
  • การรองรับ RISC-V ของ Android พึ่งพาการมีส่วนร่วมอย่างกว้างขวาง ตั้งแต่ LLVM toolchain ไปจนถึง support library พื้นฐาน
  • แหล่งข้อมูลหลักสำหรับการมีส่วนร่วมและการทดสอบมีดังนี้
    • google/android-riscv64: ให้ข้อมูลวิธี build·test การรองรับ RISC-V ของ Android, ปัญหาที่ทราบแล้ว, และโอกาสร่วมพัฒนา AOSP, toolchain และ support library
    • RISC-V Android SIG: เมลลิงลิสต์สำหรับติดตามความคืบหน้า และส่งข้อเสนอหรือข้อคิดเห็น
  • Google กำลังมองหาวิธีทำให้นักพัฒนา Android ที่เขียน native code สามารถกำหนดเป้าหมายแพลตฟอร์มใหม่ได้ง่าย เช่นเดียวกับที่นักพัฒนา Java และ Kotlin กำหนดเป้าหมายแพลตฟอร์มใหม่ได้

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

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

 
GN⁺ 2023-11-02
ความคิดเห็นจาก Hacker News

  • คาดหวังให้นักพัฒนาต้องเตรียมตัวงั้นหรือ? แนวทางนี้ผิดแล้ว ค่าเริ่มต้นควรเป็นงานที่แทบเป็น 0 เหมือนที่ Apple ทำตอน เปลี่ยนผ่านไป M1 แล้วค่อยเปิดให้ปรับแต่งเพิ่มเป็นตัวเลือกได้
    ลองนึกถึงตอนที่ Google บอกให้ทดสอบแอป Android บน x86 แล้วต่อมาก็บอกให้ทดสอบบน MIPS ด้วย สุดท้ายก็ไม่มีอะไรเกิดขึ้น และนักพัฒนาก็จะไม่เสียเวลาไปกับมัน

    • งานเป็น 0 งั้นหรือ? ความทรงจำบางทีก็เลือนเร็วเหมือนกันนะ
      Apple ให้เช่าระบบ DTK ราคา 500 ดอลลาร์ เพื่อให้นักพัฒนาได้ลองจับฮาร์ดแวร์ ARM และพอร์ตแอป งานนั้นห่างไกลจากคำว่า 0 มาก แถมยังต้องส่งฮาร์ดแวร์คืน และตอนแรกยังไม่มีแม้แต่เครดิต 500 ดอลลาร์สำหรับใช้ซื้อผลิตภัณฑ์ที่วางขายจริงด้วยซ้ำ เพิ่งแก้หลังจากเกิดกระแสต่อต้านที่คาดเดาได้
      ส่วน Google ให้ตัวจำลองซอฟต์แวร์แทน จัดการง่ายกว่ามากและไม่ต้องมีโลจิสติกส์อุปกรณ์ที่ซับซ้อน คนที่ต้องเตรียมงานจริง ๆ คือคนทำแอป NDK หรือคนที่รองรับฮาร์ดแวร์ RISC-V
      แอป Java/Kotlin ไม่ต้องพอร์ต ดังนั้นในมุมมองของผมก็ใกล้เคียงงาน 0
    • บิลด์ x86 ของแอปและไลบรารี Android เป็นเป้าหมายที่พบบ่อยที่สุดบนอีมูเลเตอร์ จึงพบได้ทั่วไปมาก
      MIPS ดูไม่เหมือนว่า Google จะผลักดันหนัก แค่มีอยู่เฉย ๆ มากกว่า
      อีกอย่าง บทความนี้มุ่งไปที่ผู้ผลิตอุปกรณ์มากกว่านักพัฒนาแอป โดยพูดถึงบิลด์ AOSP และแพตช์ที่รออยู่ ไม่ได้เป็นบทความที่เรียกร้องให้นักพัฒนาแอปทำอะไร ตรงกันข้าม ตอนท้ายยังบอกว่า “เราจะดูวิธีทำให้นักพัฒนา Android แบบเนทีฟทำได้ง่ายพอ ๆ กับที่นักพัฒนา Java และ Kotlin เล็งเป้าหมายแพลตฟอร์มใหม่”
    • MIPS บน Android แทบจะตายไปแล้วหลังจาก Imagination Technologies เข้าซื้อในปี 2013 ถ้าไม่มี SoC ใหม่หรือโทรศัพท์รุ่นใหม่ Google ก็ทำอะไรไม่ได้มาก
      x86 ยังใช้อย่างแพร่หลายเพราะ Chromebook ถ้าไม่ได้ใช้ NDK ก็ไม่มีอะไรที่นักพัฒนาต้องทำเพราะเป้าหมายใหม่นี้
    • ในความหมายทั่วไป ดูไม่เหมือนว่าคาดหวังให้นักพัฒนาต้องเตรียมตัว ชื่อเรื่องก็เป็น “สิ่งที่ต้องรู้ถ้าจะเตรียมตัว” จึงใกล้เคียงกับการบอกว่าจะให้ข้อมูลและคำแนะนำหากคุณอยากเตรียมตัว จะรับหรือไม่ก็เลือกได้
      คำว่า “you” ตรงนี้เป็นไปตามสำนวนในชื่อเรื่อง ไม่ได้หมายถึงบุคคลใดเป็นพิเศษ
    • เพราะไม่มีอุปกรณ์ที่มีนัยสำคัญออกมาบนสถาปัตยกรรมนั้น

  • แบบนี้จะต้องใช้ ส่วนขยาย C ที่ Qualcomm คัดค้านหนักขนาดนั้นหรือเปล่า?
    ดูเธรดย่อยที่เกี่ยวข้องได้ที่ https://news.ycombinator.com/item?id=37996820
    เอกสารล่าสุดของ Qualcomm อยู่ที่ https://lists.riscv.org/g/tech-profiles/attachment/400/0/AOS... โดยพวกเขาอ้างว่าส่วนขยาย Zics ที่ตนเสนอ ซึ่ง “ทำให้ RISC-V คล้าย aarch64 ขึ้นเล็กน้อย” และ long jump แบบ 32 บิต ให้ความหนาแน่นของโค้ดดีกว่า RV64GC และไม่มีข้อเสียของส่วนขยาย C ที่พวกเขาคอยยกมาเป็นประเด็นอยู่เรื่อย ๆ

    • ไม่รู้ว่าทำไมถึงโดนกดลง คำถามนี้เป็นประเด็นที่ยังดำเนินอยู่จริง ๆ
      ถ้า Qualcomm ตัดสินใจทำ RISC-V Snapdragon โดยไม่มีส่วนขยาย C ก็ยากจะเห็นว่าแอป Android NDK ที่ใช้ส่วนขยายนั้นจะทำงานอย่างไร ถ้าไม่ใช่วิธี trap แล้วจำลองคำสั่งอะไรทำนองนั้น ก็น่าจะช้าจนน่าขัน
    • ดูเหมือน Qualcomm ก็มีเหตุผลอยู่บ้าง แต่ก็ดูมีแรงจูงใจว่าอยาก นำเทคโนโลยี ARM มาใช้ซ้ำ ให้มากขึ้นด้วย
      ถ้า Google บังคับใช้ RV64GC หรือ RV64G_Zics เรื่องนี้ก็อาจตัดสินกันตรงนั้น
      อย่างไรก็ตาม การตัดคำสั่ง C ออกหรือเปลี่ยนมันไม่ใช่ตัวเลือกหลังจากมีการใช้งานจริงแล้ว และตอนนี้ส่วนใหญ่ยังอยู่ในขั้นทดสอบบนอีมูเลเตอร์ จึงอาจไม่ต้องกังวลมากนัก
    • ดูค่อนข้างคล้ายกับ ชุดคำสั่ง Thumb ของ ARM
      คำถามจริง ๆ คือ ทำไม
      อ้างอิง: https://www.quora.com/Why-was-the-ARM-Thumb-instruction-set-...

  • นอกเรื่องนิดหนึ่ง ตอนรู้จักอีมูเลเตอร์ AOSP ตัวใหม่ ผมดันคิดไปเองว่าถ้าจะใช้ อีมูเลเตอร์ Cuttlefish ใน AOSP แทน Goldfish ต้องรัน acloud แต่ acloud กลับปฏิเสธที่จะรันถ้าไม่ใช่ Ubuntu
    ผมลองแฮ็กด้วย LD_PRELOAD เพื่อเปลี่ยนเอาต์พุตของฟังก์ชัน uname แล้วด้วย แต่จากนั้นมันก็พยายามรัน dpkg ผมใช้ NixOS อยู่
    อีมูเลเตอร์รุ่นเก่าทำให้ทำงานได้จริงนั้นยุ่งยากมาก ส่วนอีมูเลเตอร์ใหม่มีข้อดีเยอะ
    แต่แปลกที่ผมไม่เคยรู้เลยว่าสามารถรัน launch_cvd โดยตรงได้

    • ถ้าจำไม่ผิด ช่วยเปิด feature request ที่ https://github.com/tadfisher/android-nixpkgs ให้หน่อย อย่างน้อยผมก็อยากทำให้แพ็กเกจลงใน repository SDK ของผมได้

  • หวังว่า “Android for RISC-V” จะประสบความสำเร็จกว่า “Android for x86” ที่เป็นหายนะโดยสมบูรณ์ ผมยังมีแท็บเล็ต Android x86 ของ Lenovo อยู่เลย
    ถึงอย่างนั้น พออ่านบทความนี้แล้วก็ไม่ได้ทำให้มั่นใจมากนัก ความหวังสูง แต่ความคาดหมายต่ำ

    • ดูเหมือนหลีกเลี่ยงไม่ได้ที่อุปกรณ์ผู้บริโภคราคาถูกซึ่งใช้ อิมพลีเมนเทชัน RISC-V เป็นโปรเซสเซอร์หลักจะหลั่งไหลเข้าสู่ตลาด
      ผมน่าจะกังวลมากกว่าว่าการรองรับ ARM จะชะงัก
    • ตอนนี้ Chromebook ส่วนใหญ่เป็น x86 และรันแอป Android ได้ Android อีมูเลเตอร์ก็เช่นกัน
      ไม่ใช่ทุกคนจะเป็นคนอเมริกันร่ำรวยที่มี ARM MacBook

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

    • สงสัยว่าใช้ทางเลือกอะไรแทน
    • DJI ดูเหมือนยังใช้ Android ในคอนโทรลเลอร์อยู่

  • ยังไม่ค่อยเข้าใจสถานการณ์เท่าไร มี โทรศัพท์มือถือหลัก ๆ ที่ใช้ RISC-V แล้วหรือยัง? แล้วเรื่องนี้ต้องเปลี่ยนทั้งสแตกเลยไหม? คงไม่ใช่แค่เปลี่ยนระบบปฏิบัติการอย่างเดียว

    • ตอนนี้ยังไม่มี แต่ใกล้จะออกมาแล้ว
      ผมไม่ค่อยแน่ใจว่าคุณขีดเส้นแบ่งระหว่าง “สแตก” กับ “ระบบปฏิบัติการ” ไว้ตรงไหน ช่วยอธิบายเพิ่มเติมได้ไหม?
    • ไม่มี แต่ Qualcomm กำลังเตรียม โปรเซสเซอร์สมาร์ตวอตช์ RISC-V อยู่ ซึ่งก็ไม่ใช่เรื่องเล็ก
      ยังไม่เคยลองพอร์ต AOSP สำหรับ LiCheePi 4A คงต้องลองรันดูสักครั้งว่าใช้ได้เลยไหม
      การดาวน์โหลด Minecraft จาก Play Store น่าจะง่ายกว่าการบูตสแตรป toolchain ทั้งชุดที่จำเป็นสำหรับการทำให้ PolyMC ทำงานได้

  • ในบรรดาสิ่งที่จะติดตั้งบน RISC-V นั้น Google Android เป็นตัวเลือกสุดท้ายเลย

    • สงสัยว่าถ้า RISC-V ถูกใช้ใน CPU มือถือบ่อยขึ้น จะส่งผลดีต่อระบบนิเวศไหม หรือบริษัทยักษ์ใหญ่จะผลัก RISC-V ไปทาง use case ระดับองค์กรยิ่งขึ้น จนไม่เป็นมิตรกับนักพัฒนาสาย hobby เท่าเดิม
    • ถึงอย่างนั้นก็อาจมีวันที่ซื้ออุปกรณ์ RISC-V ที่ติดตั้ง Android มาให้ล่วงหน้า แล้วค่อยลบทิ้งก็ได้

  • ถ้าหลีกเลี่ยงได้ การรัน Android เป็นทางเลือกที่ไม่ฉลาด และยิ่งถ้ามีโอกาสเปลี่ยนสถาปัตยกรรมแล้วไปใช้ Linux แบบบริสุทธิ์ ได้ ก็ยิ่งควรทำ
    ปัญหาคือเรื่องธนาคาร อย่างน้อยในสวีเดน ตอนนี้ยังพึ่งพา BankID บนมือถืออยู่ เช่น แม้แต่การซื้อของออนไลน์เกิน 20 ดอลลาร์ก็ต้องใช้ และมันทำงานได้เฉพาะบน iOS กับ Android

    • มีวิธีที่ใช้งานได้จริงไหมในการรันระบบปฏิบัติการที่ไม่ใช่ Android บนโทรศัพท์ แต่ยังได้ประสิทธิภาพพลังงานที่ดี, รองรับแอป Android พร้อมมัลติทัชและการเร่งความเร็ว GPU ฯลฯ?
      เช่น โซลูชันสำเร็จรูปที่รัน Android บน KVM ได้อย่างมีประสิทธิภาพ หรือแนวทางที่ให้ฟีเจอร์เคอร์เนลของ Android กับ RPC server ใน user space อะไรทำนองนั้น
      ถ้าไม่มี ก็จำเป็นต้องรัน Android เพื่อเข้าถึงแอปมือถือ และเรื่องนี้แทบจะเป็นสิ่งจำเป็น
    • ในเดนมาร์กมี MitID สำหรับเว็บไซต์ธนาคารและภาครัฐ บางครั้งก็ใช้ยืนยันการซื้อด้วย
      ถ้าไม่มีสมาร์ตโฟนหรือไม่อยากใช้ ก็สามารถรับอุปกรณ์ขนาดเล็กสำหรับใช้ยืนยันตัวตนได้ ดูแปลกที่สวีเดนบังคับให้ทุกคนที่มีบัญชีธนาคารต้องเป็นเจ้าของสมาร์ตโฟนด้วย โดยเฉพาะเมื่อคงมีผู้สูงอายุจำนวนมากที่ไม่มีสมาร์ตโฟน