Android và RISC-V: những điều cần biết để chuẩn bị

 (opensource.googleblog.com)
2 điểm bởi GN⁺ 2023-11-02 | 1 bình luận | Chia sẻ qua WhatsApp
  • Google đang thêm hỗ trợ RISC-V vào AOSP để mở rộng Android sang kiến trúc CPU mới, và đang mở rộng từ giai đoạn có thể thử nghiệm sang hợp tác ở cấp hệ sinh thái
  • Hỗ trợ ban đầu lấy hồ sơ rva22 cùng các phần mở rộng vector và vector crypto làm chuẩn, tập trung vào việc đáp ứng tập tính năng cần thiết để hiện thực hóa mức hiệu năng mà Android kỳ vọng
  • Ngay lúc này đã có thể build, test và chạy Android cho RISC-V bằng Cuttlefish, nhưng backend ART và các tối ưu hóa trình biên dịch vẫn chưa ở giai đoạn hoàn thiện
  • Cuối năm 2023 dự kiến sẽ chốt NDK ABI và có các bản build CI canary công khai, còn trong năm 2024 có kế hoạch phát hành emulator công khai để kiểm thử nhiều dạng thiết bị khác nhau
  • Chỉ port Android thôi là chưa đủ, vì vậy Google đang cùng RISE Project, RISC-V International và cộng đồng toolchain - thư viện hỗ trợ chuẩn bị cả môi trường phát triển ứng dụng

Hỗ trợ RISC-V đang đến với Android

  • Android là hệ điều hành mã nguồn mở hỗ trợ nhiều loại thiết bị và kiến trúc CPU, và hiện đang bổ sung RISC-V như một nền tảng mới
  • RISC-V là một kiến trúc tập lệnh (ISA) miễn phí và mở, theo hướng đưa cách cộng tác toàn ngành của phần mềm mã nguồn mở vào hệ sinh thái phần cứng
  • Sau khi được tạo ra tại UC Berkeley cách đây 10 năm, nó đã nhanh chóng được chấp nhận trong lĩnh vực nhúng và vi điều khiển, và gần đây đang mở rộng sang bộ tăng tốc, máy chủ và điện toán di động

Từ tiếp nhận bản vá đến giai đoạn hỗ trợ trưởng thành

  • Google đã công bố tại RISC-V Summit vào tháng 11/2022 rằng họ bắt đầu nhận các bản vá RISC-V cho Android
  • Hiện nay, dự án đã chuyển từ việc chỉ tiếp nhận bản vá sang giai đoạn làm cho hỗ trợ RISC-V trên Android trở nên trưởng thành hơn
  • Vì RISC-V là ISA dạng mô-đun nên có nhiều phần mở rộng tùy chọn; để đạt hiệu năng cao như Android kỳ vọng, cần xác định một tập tính năng bắt buộc ban đầu
    • Chuẩn này bao gồm hồ sơ rva22
    • Cũng bao gồm các phần mở rộng vector và vector crypto

Môi trường AOSP có thể build và chạy cục bộ

  • Hỗ trợ Android cho RISC-V có thể được build, test và chạy trên máy cục bộ bằng Cuttlefish Virtual Device, giống như các nền tảng mục tiêu khác của AOSP
  • Có thể xem mã liên quan tại google/android-riscv64
  • Ví dụ chạy như sau
$ lunch aosp_cf_riscv64_phone-userdebug
$ m -j
$ launch_cvd -cpus=8 -memory_mb=8192
  • Có thể kết nối với thiết bị đang chạy bằng vncviewer để tương tác

Những bài toán tối ưu vẫn còn ở phía trước

  • Các bản vá hiện tại cho phép build và chạy trải nghiệm Android Open Source Project ở mức cơ bản, nhưng vẫn chưa phải trạng thái được tối ưu hoàn toàn
  • Công việc với backend tối ưu hóa ART của Android Runtime vẫn đang tiếp diễn
  • AOSP, các dự án bên ngoài và cả trình biên dịch cũng chưa đạt tới mức có thể tạo ra mã đã được tối ưu đầy đủ và tinh gọn trong khi tận dụng các phần mở rộng đã được chuẩn hóa mới nhất
  • Mục tiêu ở giai đoạn này gần với việc tạo điều kiện cho thử nghiệm và hợp tác hơn là cung cấp một môi trường sản phẩm hoàn chỉnh

Lộ trình kiểm thử cho nhà phát triển và emulator

  • Dự kiến NDK ABI sẽ được chốt vào cuối năm 2023
  • Các bản build canary trên CI công khai của Android cũng sẽ sớm được cung cấp
  • Có kế hoạch hỗ trợ chạy RISC-V trên x86-64 và ARM64 để việc kiểm thử ứng dụng Android riscv64 trên máy host trở nên dễ dàng hơn
  • Trong năm 2024, dự kiến sẽ có emulator công khai với đầy đủ tính năng để kiểm thử ứng dụng trên nhiều dạng thiết bị khác nhau
  • Theo thông báo hợp tác với Qualcomm, dạng thiết bị đầu tiên được kỳ vọng sẽ là thiết bị đeo

Hợp tác hệ sinh thái và RISE Project

  • Chỉ port riêng hệ điều hành Android là chưa đủ; việc chuẩn bị hệ sinh thái phần mềm xung quanh cũng cần được thực hiện song song
  • Google đang hợp tác với cộng đồng và RISE
  • RISE Project được thành lập để đẩy nhanh tính sẵn sàng của phần mềm trên các lõi xử lý RISC-V hiệu năng cao, tiết kiệm điện, có khả năng chạy các hệ điều hành cấp cao
  • Phạm vi áp dụng không chỉ có Android mà còn gồm Linux và các hệ điều hành khác
  • Các miền ứng dụng mục tiêu cũng bao gồm điện toán hiệu năng cao
  • Các bên tham gia gồm Andes, Google, Intel, Imagination Technologies, MediaTek, Nvidia, Qualcomm Technologies, Red Hat, Rivos, Samsung, SiFive, T-Head và Ventana

Tiêu chuẩn hóa và con đường đóng góp

  • Google đang tiếp tục mở rộng đầu tư vào RISC-V International, vượt ra ngoài tư cách Premium member và việc tham gia hội đồng quản trị hiện có
  • Nhiều bên đóng góp đang đảm nhiệm vai trò chủ chốt trong các ủy ban ngang, nhóm công tác và ủy ban kỹ thuật để tham gia thiết kế và phê chuẩn đặc tả
  • Hỗ trợ RISC-V của Android phụ thuộc vào các đóng góp trên diện rộng, từ LLVM toolchain cho đến các thư viện hỗ trợ cơ bản
  • Các tài nguyên chính để đóng góp và kiểm thử gồm
    • google/android-riscv64: cung cấp cách build và test hỗ trợ RISC-V của Android, các vấn đề đã biết, cũng như cơ hội đóng góp cho AOSP, toolchain và thư viện hỗ trợ
    • RISC-V Android SIG: danh sách thư điện tử để theo dõi tiến độ và gửi đề xuất, phản hồi
  • Google cũng đang tìm cách để các nhà phát triển Android viết mã native có thể dễ dàng nhắm tới nền tảng mới, giống như cách các nhà phát triển Java và Kotlin có thể nhắm tới một nền tảng mới

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-11-02
Ý kiến trên Hacker News

  • Có phải họ đang kỳ vọng lập trình viên phải chuẩn bị sao? Cách tiếp cận này sai rồi. Như Apple đã làm khi chuyển sang M1, mặc định phải gần như không cần làm gì, rồi sau đó mới có thể tối ưu thêm nếu muốn
    Cứ nhớ lại thời Google từng bảo hãy kiểm thử ứng dụng Android trên x86, rồi lại bảo kiểm thử cả trên MIPS. Cuối cùng chẳng có gì xảy ra, và các lập trình viên sẽ không phí thời gian đâu

    • Không cần làm gì á? Trí nhớ đúng là đôi khi phai nhanh thật
      Apple đã cho lập trình viên thuê hệ thống DTK với giá 500 USD để họ có thể chạm tay vào phần cứng ARM và port ứng dụng. Chuyện đó còn xa mới là “không cần làm gì”, còn phải trả lại phần cứng nữa, và ban đầu thậm chí còn không có cả khoản tín dụng 500 USD để dùng khi mua sản phẩm thương mại. Chỉ sau phản ứng dữ dội có thể đoán trước thì họ mới sửa lại
      Thay vào đó Google cung cấp trình giả lập phần mềm nên dễ xử lý hơn nhiều và không cần logistics thiết bị phức tạp. Thực tế, phía cần công việc chuẩn bị là những người làm ứng dụng NDK hoặc hỗ trợ phần cứng RISC-V
      Ứng dụng Java/Kotlin không cần port, nên theo tôi thì gần như là không cần làm gì
    • Bản dựng x86 của ứng dụng và thư viện Android rất phổ biến vì đó là mục tiêu thường gặp nhất trên trình giả lập
      MIPS thì có vẻ chưa từng được Google thúc đẩy mạnh, mà chỉ kiểu tồn tại vậy thôi
      Hơn nữa, bài này nhắm tới nhà sản xuất thiết bị nhiều hơn là lập trình viên ứng dụng, vì nó nói về bản dựng AOSP và các bản vá đang chờ. Đây không phải bài yêu cầu lập trình viên ứng dụng phải làm gì, mà ngược lại còn kết ở câu “chúng tôi sẽ xem xét cách giúp các lập trình viên Android native nhắm tới nền tảng mới dễ dàng như cách các lập trình viên Java và Kotlin làm”
    • MIPS trên Android về cơ bản đã chết sau khi Imagination Technologies bị mua lại vào năm 2013. Không có SoC mới hay điện thoại mới thì Google cũng chẳng thể làm gì
      x86 vẫn còn được dùng rộng rãi nhờ Chromebook. Nếu không dùng NDK thì phía lập trình viên không có gì phải làm vì mục tiêu mới này
    • Theo nghĩa thông thường thì có vẻ họ không kỳ vọng lập trình viên phải chuẩn bị. Tiêu đề cũng là “những điều cần biết để chuẩn bị”, nên gần hơn với việc cung cấp thông tin và lời khuyên nếu bạn muốn chuẩn bị. Chấp nhận hay không là tùy
      Từ “you” ở đây là cách diễn đạt theo tiêu đề chứ không nhắm vào cá nhân cụ thể nào
    • Vì không có thiết bị đáng kể nào được phát hành trên kiến trúc đó cả

  • Có phải mở rộng C mà Qualcomm phản đối mạnh đến vậy sẽ trở thành bắt buộc không?
    Xem luồng thảo luận phụ liên quan: https://news.ycombinator.com/item?id=37996820
    Tài liệu mới nhất của Qualcomm là https://lists.riscv.org/g/tech-profiles/attachment/400/0/AOS..., trong đó họ cho rằng phần mở rộng Zics do họ đề xuất — “biến RISC-V hơi giống aarch64 hơn một chút” — cùng với lệnh nhảy dài 32 bit cho mật độ mã tốt hơn RV64GC, đồng thời không có các nhược điểm của mở rộng C mà họ liên tục chỉ trích

    • Không hiểu vì sao lại bị downvote. Đây thật sự vẫn là một vấn đề còn đang được tranh luận
      Nếu Qualcomm quyết định làm RISC-V Snapdragon mà không có mở rộng C, thì rất khó hình dung các ứng dụng Android NDK dùng phần mở rộng đó sẽ chạy thế nào. Nếu không có kiểu trap rồi giả lập gì đó thì sẽ chậm đến mức vô lý
    • Qualcomm có vẻ cũng có phần đúng, nhưng đồng thời dường như họ cũng có động cơ muốn tái sử dụng công nghệ ARM nhiều hơn
      Nếu Google bắt buộc RV64GC hoặc RV64G_Zics thì có thể chuyện sẽ ngã ngũ ở đây
      Dù vậy, bỏ hoặc thay đổi lệnh C thì sau khi triển khai thực tế sẽ không còn là lựa chọn nữa, còn hiện tại chủ yếu vẫn đang ở giai đoạn kiểm thử trên trình giả lập nên có thể họ chưa quá bận tâm
    • Trông khá giống tập lệnh Thumb của ARM
      Câu hỏi thực sự là tại sao
      Tham khảo: https://www.quora.com/Why-was-the-ARM-Thumb-instruction-set-...

  • Hơi ngoài lề, nhưng khi biết tới trình giả lập AOSP mới, chẳng hiểu sao tôi lại nghĩ rằng để dùng trình giả lập Cuttlefish trong AOSP thay cho Goldfish thì phải chạy acloud. Nhưng acloud lại từ chối chạy nếu không phải Ubuntu
    Tôi còn thử cả trò hack LD_PRELOAD để đổi đầu ra của hàm uname, nhưng rồi sau đó nó lại cố chạy dpkg. Tôi dùng NixOS
    Trình giả lập cũ thật sự rất phiền để chạy cho ra hồn, còn trình giả lập mới có nhiều ưu điểm
    Thế mà lạ là tôi hoàn toàn không biết rằng chỉ cần chạy trực tiếp launch_cvd là được

  • Mong rằng “Android for RISC-V” sẽ thành công hơn “Android for x86”, thứ từng là một thảm họa hoàn toàn. Tôi vẫn còn giữ một chiếc tablet Android x86 của Lenovo
    Dù vậy, đọc bài này xong cũng chưa thấy thêm được bao nhiêu niềm tin. Hy vọng thì nhiều nhưng kỳ vọng thì thấp

    • Việc thị trường tràn ngập các thiết bị tiêu dùng giá rẻ dùng triển khai RISC-V làm bộ xử lý chính có lẽ là điều không thể tránh khỏi
      Tôi thậm chí còn lo chuyện hỗ trợ ARM bị chững lại hơn
    • Chromebook hiện giờ phần lớn là x86 và chạy được ứng dụng Android. Trình giả lập Android cũng vậy
      Không phải ai cũng là người Mỹ giàu có sở hữu MacBook ARM đâu

  • Vài năm trước, Android từng được dùng khá rộng trong lĩnh vực nhúng cần màn hình cảm ứng đồ họa, chứ không phải điện thoại hay máy tính bảng, nhưng giờ nó gần như chỉ còn cho điện thoại và phần nào đó là máy tính bảng
    Lý do là khác với các hãng làm điện thoại và máy tính bảng, các công ty nhỏ không thể theo kịp những thay đổi mới cực kỳ phức tạp của Android nên dần rời bỏ nó

    • Tôi tò mò không biết họ đang dùng gì thay thế
    • Có vẻ DJI vẫn dùng Android trên bộ điều khiển của họ

  • Tôi không rõ tình hình lắm, nhưng đã có điện thoại di động lớn nào triển khai RISC-V chưa? Và việc này có đòi hỏi thay đổi trên toàn bộ stack không? Có vẻ không chỉ là mức thay hệ điều hành

    • Chưa có, nhưng thời điểm ra mắt đang đến gần
      Tôi không rõ ranh giới giữa “stack” và “hệ điều hành” được đặt ở đâu. Bạn có thể nói kỹ hơn một chút không?
    • Chưa. Tuy vậy Qualcomm đang chuẩn bị bộ xử lý smartwatch RISC-V. Không phải là chuyện nhỏ
      Tôi vẫn chưa thử bản port AOSP cho LiCheePi 4A. Có lẽ nên chạy thử một lần xem có hoạt động đơn giản không
      So với việc bootstrap toàn bộ toolchain cần để chạy PolyMC, tải Minecraft từ Play Store về để thử còn dễ hơn

  • Trong số những thứ để cài lên RISC-V, Google Android sẽ là lựa chọn cuối cùng của tôi

    • Tôi tự hỏi nếu RISC-V bắt đầu được dùng thường xuyên trên CPU di động thì điều đó sẽ tác động tích cực đến hệ sinh thái, hay các tập đoàn lớn sẽ đẩy RISC-V nhiều hơn về các use case doanh nghiệp và khiến nó kém thân thiện hơn với lập trình viên hobby
    • Dù vậy, tôi vẫn có thể mua một thiết bị RISC-V cài sẵn Android rồi xóa nó đi

  • Nếu có thể tránh thì chạy Android là một lựa chọn ngớ ngẩn, và nếu đã đổi kiến trúc mà có cơ hội chuyển sang Linux thuần thì lại càng như vậy
    Vấn đề là dịch vụ ngân hàng. Ít nhất ở Thụy Điển, người ta vẫn phụ thuộc vào BankID trên di động. Ví dụ, ngay cả mua hàng online trên 20 đô la cũng cần nó, và nó chỉ hoạt động trên iOS và Android

    • Có cách thực tế nào để chạy một hệ điều hành không phải Android trên điện thoại mà vẫn có được hỗ trợ ứng dụng Android, hiệu quả điện năng, đa chạm và tăng tốc GPU không?
      Ví dụ như một giải pháp dựng sẵn để chạy Android hiệu quả trong KVM, hoặc kiểu cung cấp các tính năng kernel Android và máy chủ RPC ở user space
      Nếu không có thì gần như buộc phải chạy Android để truy cập ứng dụng di động, và điều này gần như là bắt buộc
    • Ở Đan Mạch có MitID cho ngân hàng và các trang chính phủ. Đôi khi nó cũng được dùng để xác thực mua hàng
      Nếu bạn không có hoặc không muốn dùng smartphone thì có thể nhận một thiết bị nhỏ để dùng cho xác thực. Việc Thụy Điển dường như buộc mọi người có tài khoản ngân hàng phải sở hữu smartphone có vẻ khá kỳ lạ. Nhất là khi hẳn vẫn còn nhiều người cao tuổi không có smartphone