Đầu vào thích ứng hệ thống RK3588: Phạm vi Android, Linux và OpenHarmony

Hướng dẫn kỹ thuật

Đối với việc mua sắm SDK baseline của bo mạch Android RK3588, hãy kiểm tra các đầu vào, bằng chứng và mục chưa giải quyết dưới đây trước khi lựa chọn phương án. Phân công người phụ trách và cách thức thu thập tài liệu còn thiếu; bản demo đơn thuần không đủ để xác nhận tính tương thích hay hiệu năng.

Ba hướng dự án cần xác nhận những gì

Vuốt ngang bảng để xem đầy đủ các cột.

Hướng	Đầu vào chính	Công việc cần tách riêng phạm vi
Hệ thống Android và ứng dụng thiết bị	Android SDK từ nhà cung cấp, bo mạch, thiết bị ngoại vi và APK/SDK	Cấu hình hệ thống, quyền, giao diện ngoại vi, dịch vụ ứng dụng, ký số và cập nhật.
Linux BSP và ứng dụng thiết bị	Bootloader, kernel, device tree, root filesystem và thiết bị ngoại vi đích	Khởi động, driver, giao diện userspace, dịch vụ hệ thống, image và khôi phục.
Thích ứng OpenHarmony theo giai đoạn	Mã nguồn chỉ định, tài liệu bo mạch và mục tiêu build/boot	Đánh giá khởi động tối thiểu, dịch vụ, đồ họa và đa phương tiện thành từng giai đoạn riêng biệt.

Đây là bảng phân công trách nhiệm dự án, không phải danh sách tương thích chéo giữa các hệ thống. Khi thay đổi hệ điều hành, SDK hoặc bo mạch, cần đánh giá lại phạm vi áp dụng của các hồ sơ xác minh hiện có.

Đầu vào cần chuẩn bị trước khi yêu cầu báo giá

• Model bo mạch đầy đủ, phiên bản phần cứng (revision), sơ đồ nguyên lý, lưu trữ và kết nối gỡ lỗi.

• SDK/mã nguồn, phiên bản hoặc commit hash, toolchain, lệnh build và các image hiện có.

• Model thiết bị ngoại vi, giao diện, chế độ hoạt động đích và trạng thái hiện tại.

• Ứng dụng nghiệp vụ, giao diện, quyền, luồng dữ liệu vào/ra và các phụ thuộc bên thứ ba.

• Các bước tái tạo lỗi, log, tần suất xuất hiện và biện pháp đã thử đối với sự cố hiện có.

• Mã nguồn, bản vá, image, tài liệu và trách nhiệm bảo trì dự kiến bàn giao.

Liệt kê các tài liệu chưa có thành mục thiếu hụt và thống nhất cách thu thập hoặc xác định giai đoạn đánh giá. Không điền vào chỗ trống bằng các phiên bản chưa được xác minh.

Xác định điều kiện nghiệm thu có thể tái kiểm tra

Thay thế cụm từ “thích ứng hệ thống hoàn tất” bằng các điều kiện cụ thể như: khởi động phiên bản chỉ định trên bo mạch chỉ định từ phương tiện chỉ định, sau đó thu thập log và kiểm tra trạng thái dịch vụ theo các bước đã ghi chép. Hiển thị, camera, âm thanh, mạng, ứng dụng, cập nhật và vận hành dài hạn đều cần điều kiện kiểm tra riêng; việc khởi động tối thiểu thành công không tự động bao hàm các hạng mục này.

Nếu bao gồm tác vụ NPU, cần bổ sung mô hình, tập mẫu, tiền xử lý, hậu xử lý và môi trường đích. Hệ thống khởi động được không đồng nghĩa với việc mô hình đã được triển khai.

Sử dụng hồ sơ case study để xác định giai đoạn

Case study OpenHarmony 6.1 RK3588 Stage-0 ghi lại quá trình xác minh khởi động không giao diện (headless) tối thiểu trên một bo mạch giới hạn. Phương pháp kiểm tra log và image trong tài liệu này minh họa cho việc bàn giao theo giai đoạn; chúng không xác nhận rằng đồ họa đầy đủ, đa phương tiện hay chứng nhận sản xuất đã hoàn tất.

Việc tích hợp ứng dụng Android có thể tham khảo Case study TTS SDK ngoại tuyến, nhưng cũng cần tuân thủ ranh giới về hệ thống, thiết bị và kiểm tra của chính case study đó.

Phân chia các gói công việc tiếp theo

Nếu đã có SDK nhưng thiết bị ngoại vi chưa hoạt động, hãy bắt đầu từ Thích ứng Android hoặc Dịch vụ Linux BSP. Việc chuyển đổi mô hình và tích hợp suy luận thuộc về Dịch vụ triển khai NPU. Chuẩn bị sẵn thông tin bo mạch, phiên bản, giao diện và đầu vào kiểm tra trước khi thảo luận phạm vi phát triển và cơ sở báo giá.

Danh sách kiểm tra mua sắm

Vuốt ngang bảng để xem đầy đủ các cột.

Mục kiểm tra	Đầu vào và kiểm tra	Ranh giới phán đoán
Tương thích phiên bản	Đối chiếu revision bo mạch với commit SDK, bản vá và image hiện có	Cùng chip xử lý không thay thế được việc kiểm tra tương thích cấp bo mạch
Mã nguồn và quyền build	Xác nhận phạm vi mã nguồn, toolchain, quyền truy cập phụ thuộc và quyền build	Phân công người chịu trách nhiệm thu thập đầu vào còn thiếu, không dùng phiên bản chưa xác minh để lấp đầy
Ký số và phát hành	Phân biệt bản build debug, dịch vụ ký số, cập nhật và giấy phép bên thứ ba	Khóa bí mật sản xuất không bắt buộc phải bàn giao cho bên phát triển; thống nhất quy trình ký số được kiểm soát

Cần những đầu vào nào trước khi bắt đầu?

Model và revision bo mạch đầy đủ, Android SDK, hướng dẫn build, image hiện có, danh sách thiết bị ngoại vi và log cổng serial. Kiểm tra phiên bản tài liệu và tính khả dụng trước; giữ lại các mục thiếu làm đầu vào chờ xác nhận.

Làm thế nào để xác định phạm vi bàn giao và nghiệm thu?

Build và khởi động bo mạch đích trong môi trường đã thỏa thuận theo quy trình bàn giao; kiểm tra phiên bản, log và các vấn đề phát sinh; thống nhất cách xử lý các lỗi chặn (blocking defects). Baseline có thể tái tạo không đồng nghĩa với việc thiết bị ngoại vi, ứng dụng, vận hành dài hạn hay sẵn sàng sản xuất đã đạt yêu cầu; Linux và OpenHarmony cần được lập dự án riêng.

Các doanh nghiệp tại Thâm Quyến, Trung Quốc, có thể gửi các đầu vào trên để đánh giá từ xa. Việc tích hợp mẫu thử, gửi mẫu, làm việc tại hiện trường và chi phí liên quan sẽ được xác nhận theo từng dự án cụ thể.

Kiểm tra bổ sung khi mua sắm bo mạch đích Linux

Vuốt ngang bảng để xem đầy đủ các cột.

Mục kiểm tra	Đầu vào và kiểm tra	Ranh giới phán đoán
Bo mạch và phương tiện	Kiểm tra revision bo mạch, cấu hình lưu trữ và lựa chọn khởi động	Cùng bộ xử lý không chứng minh được cấu hình khởi động giống nhau
Thành phần SDK	Liệt kê phiên bản bootloader, kernel, device-tree, root-filesystem và toolchain	Phân biệt file nhị phân của hãng, mã nguồn có thể chỉnh sửa và quyền phân phối lại
Gỡ lỗi và khôi phục	Xác nhận mức điện áp serial, đấu nối, công cụ khôi phục và quyền truy cập được ủy quyền	Không ghi đè lên phương tiện khởi động gốc khi chưa có phương án khôi phục

Các bước kiểm tra bổ sung này cũng áp dụng cho việc đánh giá tài liệu baseline Linux dành cho doanh nghiệp tại Thiên Tân, Trung Quốc. Android, Linux và OpenHarmony cần xác nhận phạm vi riêng biệt; kết quả kiểm tra của hệ thống này không thể dùng thay thế cho hệ thống khác.

Xem xét phạm vi dịch vụ và gửi đầu vào dự án trước khi thống nhất kế hoạch phát triển và bàn giao. Phạm vi dịch vụ trong bản gốc tiếng Trung