ข้อมูลนำเข้าสำหรับการปรับระบบ RK3588: ขอบเขต Android, Linux และ OpenHarmony

คู่มือวิศวกรรม

สำหรับการจัดซื้อพื้นฐาน SDK บอร์ด RK3588 Android โปรดตรวจสอบข้อมูลนำเข้า หลักฐาน และรายการที่ยังไม่สรุปด้านล่างก่อนเลือกแนวทาง กำหนดผู้รับผิดชอบและวิธีการจัดหาเอกสารที่ขาดหาย การสาธิตเพียงอย่างเดียวไม่สามารถยืนยันความเข้ากันได้หรือประสิทธิภาพ

สิ่งที่สามทิศทางโครงการต้องยืนยัน

เลื่อนตารางในแนวนอนเพื่อดูคอลัมน์ทั้งหมด

ทิศทาง	ข้อมูลนำเข้าหลัก	งานที่ต้องกำหนดขอบเขตแยก
ระบบ Android และแอปพลิเคชันอุปกรณ์	Android SDK จากผู้ผลิต บอร์ด อุปกรณ์ต่อพ่วง และ APK/SDK	การตั้งค่าระบบ สิทธิ์ อินเทอร์เฟซอุปกรณ์ต่อพ่วง บริการแอปพลิเคชัน การเซ็นชื่อ และการอัปเดต
Linux BSP และแอปพลิเคชันอุปกรณ์	Bootloader เคอร์เนล Device Tree ระบบไฟล์รูท และอุปกรณ์ต่อพ่วงเป้าหมาย	การบูต ไดรเวอร์ อินเทอร์เฟซ Userspace บริการ อิมเมจ และการกู้คืน
การปรับใช้ OpenHarmony แบบเป็นขั้นตอน	ซอร์สโค้ดที่กำหนด เอกสารบอร์ด และเป้าหมายการบิลด์/บูต	ประเมินการบูตขั้นต่ำ บริการ กราฟิก และมัลติมีเดีย แยกเป็นแต่ละขั้นตอน

นี่คือตารางแบ่งความรับผิดชอบของโครงการ ไม่ใช่รายการความเข้ากันได้ข้ามระบบ ต้องประเมินบันทึกการยืนยันเดิมใหม่เมื่อมีการเปลี่ยนแปลง OS, SDK หรือบอร์ด

ข้อมูลที่ต้องเตรียมก่อนขอใบเสนอราคา

• รุ่นบอร์ดแบบเต็ม เลขรีวิชัน แผนผังวงจร การจัดเก็บข้อมูล และการเชื่อมต่อเพื่อดีบัก

• SDK/ซอร์สโค้ด เวอร์ชันหรือเลขคอมมิต Toolchain คำสั่งบิลด์ และอิมเมจที่มีอยู่

• รุ่นอุปกรณ์ต่อพ่วง อินเทอร์เฟซ โหมดเป้าหมาย และสถานะการทำงานปัจจุบัน

• แอปพลิเคชัน อินเทอร์เฟซ สิทธิ์ ข้อมูลเข้า/ออก และการพึ่งพาบุคคลที่สาม

• ขั้นตอนการทำซ้ำปัญหา บันทึก (Log) ความถี่ที่เกิดขึ้น และมาตรการแก้ไขที่ได้ลองทำไปแล้วสำหรับข้อผิดพลาดที่มีอยู่

• ซอร์สโค้ด แพตช์ อิมเมจ เอกสาร และความรับผิดชอบในการบำรุงรักษาที่ตกลงกัน

ระบุเอกสารที่ไม่สามารถจัดหาได้เป็นช่องว่าง และตกลงวิธีการจัดหาหรือกำหนดขั้นตอนการประเมิน ห้ามใช้เวอร์ชันที่ยังไม่ยืนยันมาเติมในช่องว่าง

กำหนดเงื่อนไขการยอมรับที่ทำซ้ำได้

แทนที่ข้อความ "การปรับระบบเสร็จสมบูรณ์" ด้วยเงื่อนไข เช่น "บูตเวอร์ชันที่กำหนดบนบอร์ดที่กำหนดจากสื่อที่กำหนด แล้วเก็บ Log และตรวจสอบสถานะบริการตามขั้นตอนที่บันทึกไว้" จอแสดงผล กล้อง เสียง เครือข่าย แอปพลิเคชัน การอัปเดต และการรันต่อเนื่อง ล้วนต้องมีเงื่อนไขเฉพาะของตน การบูตขั้นต่ำผ่าน ไม่ครอบคลุมงานเหล่านี้โดยอัตโนมัติ

หากมีงาน NPU ต้องระบุโมเดล ตัวอย่างข้อมูล การประมวลผลล่วงหน้า/ภายหลัง และสภาพแวดล้อมเป้าหมาย การที่ระบบบูตได้ ไม่ได้เป็นหลักฐานว่าโมเดลถูกนำไปใช้งานแล้ว

ใช้บันทึกกรณีศึกษาเพื่อทำความเข้าใจขั้นตอนโครงการ

กรณีศึกษา OpenHarmony 6.1 RK3588 Stage-0 ฉบับภาษาจีนต้นฉบับ บันทึกขั้นตอนการบูตแบบไม่มีหน้าจอ (Headless) บนบอร์ดที่จำกัด วิธีการตรวจสอบ Log และอิมเมจสามารถใช้เป็นอ้างอิงการส่งมอบแบบเป็นขั้นตอนได้ แต่ไม่ได้หมายความว่ากราฟิก มัลติมีเดีย หรือการรับรองการผลิตเสร็จสมบูรณ์

การบูรณาการแอปพลิเคชัน Android สามารถอ้างอิงจาก กรณีศึกษา Offline TTS SDK ซึ่งต้องคงขอบเขตระบบ อุปกรณ์ และการทดสอบของกรณีศึกษานั้นไว้

การแบ่งชุดงานถัดไป

หากมี SDK อยู่แล้วแต่อุปกรณ์ต่อพ่วงยังทำงานไม่ได้ สามารถเริ่มจาก การปรับใช้ Android หรือ บริการ Linux BSP ส่วนการแปลงโมเดลและการบูรณาการ Inference อยู่ใน บริการ NPU ลิงก์เหล่านี้นำไปสู่ขอบเขตบริการฉบับภาษาจีนต้นฉบับ โปรดเตรียมบอร์ด เวอร์ชัน อินเทอร์เฟซ และข้อมูลทดสอบ ก่อนประเมินขอบเขตการพัฒนาและต้นทุน

รายการตรวจสอบการจัดซื้อ

เลื่อนตารางในแนวนอนเพื่อดูคอลัมน์ทั้งหมด

รายการ	ข้อมูลนำเข้าและการตรวจสอบ	ขอบเขตการตัดสินใจ
การจับคู่เวอร์ชัน	จับคู่รีวิชันบอร์ดกับเลขคอมมิต SDK แพตช์ และอิมเมจที่มีอยู่ทีละรายการ	ชิปเซ็ตเดียวกันไม่สามารถทดแทนการตรวจสอบความเข้ากันได้ในระดับบอร์ด
ซอร์สโค้ดและการบิลด์	ยืนยันขอบเขตซอร์สโค้ด Toolchain การเข้าถึง Dependencies และสิทธิ์ในการบิลด์	ระบุผู้รับผิดชอบสำหรับข้อมูลที่ขาดหาย แทนการใช้เวอร์ชันที่ยังไม่ยืนยันมาเติม
การเซ็นชื่อและการเผยแพร่	แยก Debug Build บริการเซ็นชื่อ การอัปเดต และใบอนุญาตบุคคลที่สามออกจากกัน	ไม่ต้องส่งมอบ Private Key สำหรับการผลิตให้ผู้พัฒนา ตกลงกระบวนการเซ็นชื่อภายใต้การควบคุม

ต้องใช้ข้อมูลอะไรบ้างก่อนเริ่มต้น?

รุ่นบอร์ดและเลขรีวิชันที่ครบถ้วน Android SDK คำแนะนำการบิลด์ อิมเมจที่มีอยู่ รายการอุปกรณ์ต่อพ่วง และ Serial Log ตรวจสอบเวอร์ชันและความพร้อมของเอกสารก่อน และเก็บรายการที่ขาดหายเป็นข้อมูลนำเข้าที่ยังไม่สรุป

ควรกำหนดขอบเขตการส่งมอบและการยอมรับอย่างไร?

บิลด์และบูตบอร์ดเป้าหมายในสภาพแวดล้อมที่ตกลงโดยใช้ขั้นตอนที่ส่งมอบ ตรวจสอบเวอร์ชัน Log และรายการปัญหา รวมถึงตกลงวิธีจัดการกับ Blocking Defect การที่ Baseline ทำซ้ำได้ ไม่ได้หมายความว่าอุปกรณ์ต่อพ่วง แอปพลิเคชัน ความเสถียรระยะยาว หรือความพร้อมสำหรับการผลิตผ่านการรับรอง ให้กำหนดขอบเขต Linux และ OpenHarmony แยกกัน

องค์กรในเซินเจิ้น ประเทศจีน สามารถส่งข้อมูลข้างต้นเพื่อรับการตรวจสอบระยะไกลได้ การดีบักต้นแบบร่วมกัน การส่งตัวอย่าง งานหน้างาน และค่าใช้จ่ายที่เกี่ยวข้อง ให้ตกลงตามโครงการเฉพาะ

รายการตรวจสอบเพิ่มเติมสำหรับการจัดซื้อบอร์ดเป้าหมาย Linux

เลื่อนตารางในแนวนอนเพื่อดูคอลัมน์ทั้งหมด

รายการ	ข้อมูลนำเข้าและการตรวจสอบ	ขอบเขตการตัดสินใจ
บอร์ดและสื่อเก็บข้อมูล	ตรวจสอบรีวิชันบอร์ด การตั้งค่าพื้นที่เก็บข้อมูล และการเลือกบูต	โปรเซสเซอร์เดียวกันไม่สามารถยืนยันว่าการตั้งค่าบูตเหมือนกัน
องค์ประกอบ SDK	ระบุเวอร์ชัน Bootloader เคอร์เนล Device Tree ระบบไฟล์รูท และ Toolchain	แยกแยะระหว่าง Binary จากผู้ผลิต ซอร์สโค้ดที่แก้ไขได้ และสิทธิ์ในการแจกจ่ายซ้ำ
การดีบักและการกู้คืน	ยืนยันระดับสัญญาณ Serial การเดินสาย เครื่องมือกู้คืน และสิทธิ์การเข้าถึง	ห้ามเขียนทับสื่อบูตเดิมหากไม่มีวิธีกู้คืน

รายการตรวจสอบเพิ่มเติมนี้รองรับการตรวจสอบข้อมูลพื้นฐาน Linux สำหรับองค์กรในเทียนจิน ประเทศจีน กำหนดขอบเขต Android, Linux และ OpenHarmony แยกกัน ผลการทดสอบไม่สามารถใช้แทนกันได้

โปรดตรวจสอบขอบเขตบริการและส่งข้อมูลโครงการก่อนตกลงดำเนินการพัฒนาและส่งมอบ ขอบเขตบริการในต้นฉบับภาษาจีน