Skip to content

AMD EDF: khi Yocto thuần thay thế PetaLinux

AMD EDF

AMD đang thay PetaLinux bằng Embedded Development Framework (EDF), một workflow dựa hoàn toàn trên Yocto Project, ra mắt cùng Vivado 2025.1; PetaLinux được đưa vào diện deprecate trong năm 2026. Bài viết trình bày EDF là gì, lý do AMD chuyển hướng, cơ chế SHEL flow nằm bên dưới, các dòng chip được hỗ trợ và những điểm cần lưu ý khi migrate một dự án PetaLinux sẵn có.

Kết luận chính của bài: đây là bước chuyển từ sự tiện lợi đóng gói sẵn sang minh bạch và kiểm soát, đổi lại bằng một đường học dốc hơn. Meta-user layer cũ vẫn tái sử dụng được, nên phần lớn công sức của việc migrate nằm ở khâu audit chứ không phải viết lại.

Bối cảnh: PetaLinux đã làm được gì và cái giá phải trả

PetaLinux thành công vì nó biến việc dựng một hệ Linux nhúng trên Zynq thành một chuỗi lệnh quen thuộc. Với petalinux-create, petalinux-config và petalinux-build, một kỹ sư firmware có thể đi từ file XSA xuất ra từ Vivado đến một image khởi động được mà không cần hiểu sâu về cấu trúc layer của Yocto.

Sự tiện lợi đó dựa trên một lớp trừu tượng hóa. PetaLinux tự động hóa nhiều bước dưới nền: tạo cấu trúc project, đặt tên machine, đóng gói BSP vào file .bsp, sinh device tree bằng Device Tree Generator (DTG). Phần lớn thời gian lớp này hữu ích, nhưng nó cũng che khuất Yocto thật sự bên dưới. Khi cần tùy biến sâu hơn hoặc khi gặp lỗi nằm ngoài những gì wrapper dự liệu, người dùng buộc phải lần ngược xuống các lớp mà họ chưa từng thấy.

Sự đánh đổi này là điểm xuất phát để hiểu quyết định của AMD: PetaLinux tối ưu cho tốc độ bring-up ban đầu, còn nhu cầu của các dự án dài hạn nghiêng về khả năng kiểm soát và bảo trì.

Những thay đổi chính

EDF thay thế PetaLinux Tools bằng một workflow Yocto thuần. EDF xuất hiện cùng Vivado 2025.1, còn PetaLinux được AMD đưa vào diện deprecate trong năm 2026. Theo AMD, EDF là sự tiến hóa của các flow Yocto của hãng, cung cấp một môi trường mã nguồn mở để đánh giá, phát triển và triển khai ứng dụng trên các adaptive SoC.

Bảng dưới so sánh những điểm khác biệt chính giữa hai cách tiếp cận.

PetaLinux EDF
Nền tảng Yocto qua lớp đóng gói (wrapper) Yocto thuần
Ra mắt Có từ trước EDF Cùng Vivado 2025.1
Trạng thái Deprecated trong 2026 Hướng đi chính thức
Mô tả board/hardware File .bsp Machine config trong layer meta-amd-adaptive-socs
Sinh device tree Device Tree Generator (DTG) SDTgen + Lopper (SHEL flow)

Về phạm vi chức năng, EDF Linux BSP cung cấp những thành phần tương tự một PetaLinux BSP: boot firmware, bootloader, Linux OS và root file system. Theo AMD, phần kernel configuration và rootfs của EDF phong phú hơn.

Lý do AMD chuyển hướng

Đây không phải một quyết định xuất phát từ một lý do kỹ thuật đơn lẻ mà là một lựa chọn chiến lược: PetaLinux ưu tiên giảm độ phức tạp và tăng tốc bring-up, còn EDF ưu tiên sự minh bạch và kiểm soát dài hạn theo đúng triết lý của Yocto. Năm lý do chính mà AMD nêu hoặc hàm ý trong tài liệu của mình như sau.

  1. Đồng bộ với Yocto chuẩn công nghiệp. Workflow Yocto thuần giúp build có thể tái lập (reproducible), dễ bảo trì và đi theo các thực hành chung của ngành, thay vì một wrapper riêng của AMD.
  2. Minh bạch và kiểm soát hơn. PetaLinux tự động hóa nhiều bước và che đi Yocto bên dưới. EDF bỏ lớp che này, để lộ toàn bộ cách một project Yocto được xử lý. Đổi lại, đường học dốc hơn, nhưng nhà phát triển nắm quyền kiểm soát đầy đủ.
  3. Vòng đời rõ ràng hơn. EDF được định vị là nền tảng dài hạn, xuyên suốt từ đánh giá, phát triển đến triển khai.
  4. Stack phong phú hơn. Theo FAQ của AMD, kernel configuration và rootfs trong EDF Linux BSP phong phú hơn so với PetaLinux BSP, dù chức năng cốt lõi tương đương.
  5. Tcl thiết kế được mở mã nguồn. Với PetaLinux, người dùng không có mã Tcl cho việc sinh các file thiết kế; EDF mở phần này, tăng khả năng tùy biến.

Một yếu tố đi kèm là thu hẹp phạm vi hỗ trợ: AMD Classic MicroBlaze không nằm trong EDF, và hỗ trợ Linux cho dòng này sẽ kết thúc cùng PetaLinux. Theo suy đoán của tác giả, đây cũng có thể là dịp để AMD giảm bớt các nhánh ít dùng; tài liệu của AMD không nêu lý do này.

Cơ chế SHEL flow

SHEL (Software Hardware Exchange Loop) là chuỗi công cụ thay cho bước petalinux-config --get-hw-description <XSA>, và mọi thứ xoay quanh System Device Tree (SDT). Ba công cụ tham gia:

  1. SDTgen (dựa trên XSCT) sinh SDT từ file XSA xuất ra từ Vivado, kèm pl.dtsi mô tả phần PL và các IP trong block design.
  2. gen-machine-conf chạy parse-sdt để biến SDT thành machine config Yocto, đặt tại build/conf/machine/<target>.conf.
  3. Lopper sinh device tree theo từng domain từ SDT.

SDT là điểm trung tâm của SHEL flow

Hình 1. SHEL flow: ba công cụ, hai đầu ra.

SDTgen biến file XSA thành SDT. Từ SDT, gen-machine-conf sinh machine config còn Lopper sinh device tree theo domain, rồi cả hai đi vào bước build Yocto.

Phạm vi hỗ trợ: dòng chip và những vùng xám

EDF bao phủ các dòng adaptive SoC chính của AMD, nhưng chưa phải mọi board đã chuyển hẳn sang. Bảng sau tổng hợp theo trang sản phẩm EDF và tài liệu của AMD.

Dòng Ghi chú
Zynq UltraScale+ MPSoC Được hỗ trợ; gồm cả các module Kria K24 và K26
Zynq-7000 SoC Nằm trong hệ sinh thái EDF theo UltraFast Embedded Design Methodology Guide
Versal AI Core, AI Edge, Prime, Premium, HBM Được hỗ trợ
Versal AI Edge Gen 2, Prime Gen 2 Được hỗ trợ
MicroBlaze V Nằm trong hệ sinh thái EDF theo hướng dẫn nói trên
AMD Classic MicroBlaze Không được hỗ trợ; Linux cho dòng này kết thúc cùng PetaLinux

Về các vùng xám, tính đến bản 2026.1, một số platform cụ thể như vck190_base, vck190_base_dfx, vek280_base và kv260_base vẫn dùng naming convention Xilinx cũ và cần PetaLinux. Trước khi lên kế hoạch migrate cho một board cụ thể, cần đối chiếu trang Supported Boards and Scope trong tài liệu EDF để biết chính xác trạng thái của board đó.

Migrate dự án PetaLinux: giữ meta-user, audit trước khi đổi

Một dự án PetaLinux không cần viết lại từ đầu: meta-user layer cũ vẫn thêm được vào Yocto project của EDF, nên công việc chính là kiểm kê những gì đã tùy biến. Phần này đi qua bốn việc theo thứ tự nên làm.

Dựng lại nền hardware bằng gen-machine-conf

Bước petalinux-config --get-hw-description <XSA> được thay bằng chuỗi SDTgen, gen-machine-conf, Lopper như mô tả ở phần SHEL flow. Kết quả là một machine config nằm tại build/conf/machine/<target>.conf, thay cho file .bsp trước đây.

Đưa meta-user layer vào Yocto project

Meta-user layer cũ được thêm trực tiếp vào build/conf/bblayers.conf. Với cấu hình U-Boot tùy chỉnh, nơi lưu cũ là project-spec/meta-user/recipes-bsp/u-boot/files/user.cfg. Khái niệm vẫn giữ nguyên trong EDF, chỉ khác ở bước lưu: file .config đã sinh ra cần được sao vào defconfig của layer tương ứng.

Audit các tùy biến

Bốn nhóm cần rà soát trước khi build lần đầu:

  • Kernel config fragment
  • Chỉnh sửa device tree và overlay
  • Recipe tùy chỉnh trong meta-user
  • Danh sách package trong rootfs

Flow import cũ đã ngừng hỗ trợ

Từng có một flow dùng plnx-yocto-migrate.run để import trực tiếp project PetaLinux sang Yocto, nhưng chỉ hoạt động ở các bản 2021.1 đến 2022.2 và đã bị deprecate từ 2023.1. Từ 2023.1 trở đi, đường chính thức là gen-machine-conf, tiền thân trực tiếp của workflow EDF hiện tại.

Thảo luận

EDF đổi sự tiện lợi lấy quyền kiểm soát, và cái giá nằm ở chỗ kỹ sư phải hiểu Yocto thật sự. Với PetaLinux, nhiều quyết định được đưa ra thay người dùng. Với EDF, những quyết định đó trở về tay nhóm phát triển: chọn layer, quản lý machine config, giữ cho meta-user gọn và có thể tái lập. Đội đã quen Yocto sẽ thấy đây là bước thuận lợi; đội chỉ quen gói lệnh petalinux-* sẽ cần thời gian làm quen.

Rủi ro cần theo dõi. gen-machine-conf hiện vẫn phụ thuộc XSCT, trong khi XSCT cũng nằm trong lộ trình deprecate của AMD. Vì vậy chuỗi công cụ của EDF chưa hoàn toàn ổn định ở phần sinh hardware description, và nên theo dõi các release tiếp theo trước khi cố định quy trình.

Đối tượng nên chuyển ngay. Theo nhận định của tác giả, các dự án mới trên Zynq UltraScale+ hoặc Versal nên bắt đầu thẳng bằng EDF, vì PetaLinux đã có lịch deprecate. Các dự án đang vận hành ổn định có thể lên kế hoạch migrate theo từng bước, bắt đầu bằng audit meta-user, rồi chạy thử trên một nhánh riêng trước khi chuyển hẳn. Với các board còn nằm trong danh sách cần PetaLinux, cần chờ AMD hoàn tất phần hỗ trợ của chính board đó.

Kết luận

Việc AMD thay PetaLinux bằng EDF đưa workflow về Yocto thuần, với ba điểm chính:

  1. EDF là Yocto thuần, ra mắt cùng Vivado 2025.1, trong khi PetaLinux bước vào giai đoạn deprecate trong 2026.
  2. Cơ chế SHEL flow (SDTgen, gen-machine-conf, Lopper) thay cho .bsp và DTG, còn meta-user layer cũ vẫn tái sử dụng được.
  3. Việc migrate nên bắt đầu bằng audit tùy biến và kiểm tra trạng thái hỗ trợ của từng board, đồng thời theo dõi lộ trình thay thế XSCT.

Tài liệu tham khảo

Nội dung bài dựa trên tài liệu và trang sản phẩm công khai của AMD; chưa được kiểm chứng trên phần cứng hay build thực tế.