ข้อมูลจำเพาะทางเทคนิคของบอร์ดพัฒนากล่อง Android TV สำหรับ Linux และ Android Dual-OS

1. บอร์ดพัฒนากล่อง Android TV แบบ Dual-OS: สถาปัตยกรรมฮาร์ดแวร์และการเลือก SoC

SoC เป็นรากฐานของบอร์ดพัฒนาระบบปฏิบัติการคู่ โดยจะกำหนดสถาปัตยกรรม CPU, ความสามารถของ GPU, ตัวควบคุมหน่วยความจำ, กลไกมัลติมีเดีย, อินเทอร์เฟซต่อพ่วง และความพร้อมใช้งานของทรัพยากรการพัฒนาซอฟต์แวร์ Android/Linux

สำหรับโครงการ B2B แพลตฟอร์ม Rockchip คุ้มค่าที่จะประเมิน เนื่องจากระบบนิเวศของผลิตภัณฑ์ครอบคลุมมัลติมีเดีย, Linux แบบฝัง, Android และแอปพลิเคชันทางอุตสาหกรรม

แพลตฟอร์มตัวแทนสองแพลตฟอร์มแสดงให้เห็นถึงข้อกำหนดของโครงการที่แตกต่างกัน

ร็อคชิป RK3568

แพลตฟอร์มฝังตัวที่สมดุล

• ซีพียู Quad-core Cortex-A55

• มาลี-G52 GPU

• 1 ท็อป NPU

• ถอดรหัส 4K H.265/H.264/VP9

• รองรับ Android 11/12 และ Linux SDK สำหรับแพลตฟอร์ม

  เหมาะสำหรับ IPTV, เทอร์มินัลแบบฝัง, จอแสดงผลอัจฉริยะ และการควบคุมทางอุตสาหกรรม

ร็อคชิป RK3588

แพลตฟอร์มประสิทธิภาพสูง

• 4× คอร์เทกซ์-A76 + 4× คอร์เทกซ์-A55

• มาลี-G610 MP4 GPU

• NPU สูงสุด 6 TOPS

• ความสามารถในการถอดรหัสวิดีโอ 8K

• รองรับ Android และ Linux หลายรุ่นบนแพลตฟอร์มการพัฒนาที่จัดทำเป็นเอกสาร

  เหมาะสำหรับมัลติมีเดียขั้นสูง แอปพลิเคชัน AI และระบบอุตสาหกรรมที่ซับซ้อน

1.1 กรอบข้อกำหนดฮาร์ดแวร์ที่แนะนำ

ตารางต่อไปนี้ให้ข้อมูลอ้างอิงที่เป็นประโยชน์สำหรับการวางแผนบอร์ดพัฒนา Android TV Box สำหรับ Linux และ Android Dual-OS

สิ่งเหล่านี้คือการกำหนดค่าทางวิศวกรรมที่แนะนำ ไม่ใช่ข้อมูลจำเพาะของผลิตภัณฑ์ SZTomato ที่ได้รับการยืนยันเพียงรายการเดียว

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

1.2 สถาปัตยกรรมหน่วยความจำและการจัดเก็บข้อมูลสำหรับระบบปฏิบัติการสองระบบ

การจัดสรรหน่วยความจำเป็นหนึ่งในการตัดสินใจที่สำคัญที่สุดในบอร์ดพัฒนาระบบปฏิบัติการแบบคู่

โดยทั่วไปแล้ว Android ต้องการพื้นที่เก็บข้อมูลสำหรับอิมเมจระบบ กรอบงานแอปพลิเคชัน แอปพลิเคชันระบบ และกลไกการอัปเดต OTA มากกว่าการกระจาย Linux แบบฝังขั้นต่ำ

บอร์ดพัฒนาที่มี RAM 4GB และ eMMC ขนาด 32GB อาจเป็นจุดเริ่มต้นที่เป็นประโยชน์สำหรับโปรเจ็กต์มัลติมีเดียแบบฝังตัวจำนวนมาก แม้ว่าแอปพลิเคชันที่มีความต้องการสูงอาจต้องใช้ RAM 8GB หรือความจุที่สูงกว่าก็ตาม

โครงสร้างพาร์ติชัน eMMC ที่เป็นไปได้คือ:

เค้าโครงพาร์ติชันต้องคำนึงถึงสถาปัตยกรรมการบูตของ SoC, รุ่น Android, การแจกจ่าย Linux, ข้อกำหนดการอัปเดต A/B และกลยุทธ์การกู้คืน

พาร์ติชันข้อมูลที่ใช้ร่วมกันสามารถทำให้การแลกเปลี่ยนไฟล์ระหว่างระบบปฏิบัติการง่ายขึ้น แต่ต้องพิจารณาความเข้ากันได้ของระบบไฟล์ สิทธิ์ การเข้ารหัส และการเข้าถึงพร้อมกัน

1.3 อินเทอร์เฟซสำหรับบอร์ดพัฒนาที่สำคัญ

บอร์ดพัฒนาควรมีอินเทอร์เฟซฮาร์ดแวร์เพียงพอสำหรับการรวมผลิตภัณฑ์

อินเทอร์เฟซต่อไปนี้สมควรได้รับความสนใจเป็นพิเศษ:

• HDMI: เอาต์พุตวิดีโอ, การส่งสัญญาณเสียง, ความเข้ากันได้ของจอแสดงผล และการใช้งาน HDCP

• โฮสต์ USB/OTG: ที่จัดเก็บข้อมูลภายนอก กล้อง คีย์บอร์ด การดีบัก และการรวมอุปกรณ์ต่อพ่วง

• Gigabit Ethernet: การส่ง IPTV ที่เชื่อถือได้ การจัดการระยะไกล และเครือข่ายอุตสาหกรรม

• UART: คอนโซล Bootloader การดีบักเคอร์เนล และการวินิจฉัยฮาร์ดแวร์

• GPIO: การควบคุมพลังงาน เซ็นเซอร์ ปุ่ม ไฟแสดงสถานะ และอุปกรณ์ภายนอก

• I2C/SPI: การสื่อสารกับตัวควบคุมการแสดงผล เซ็นเซอร์ และไอซีต่อพ่วง

• PCIe/M.2: ตัวเลือกเสริมไร้สาย พื้นที่จัดเก็บข้อมูล และการสื่อสาร

รายการอินเทอร์เฟซควรได้รับการสรุปก่อนเค้าโครง PCBA การเพิ่มตัวเชื่อมต่อหลังจากการผลิต PCB อาจทำให้เกิดข้อขัดแย้งในการกำหนดเส้นทาง ข้อจำกัดด้านพลังงาน และต้นทุนการออกแบบใหม่ที่ไม่จำเป็น

2. การใช้งานระบบปฏิบัติการ Dual-OS สำหรับ Linux และ Android: Bootloader, Kernel และ BSP

การรองรับ Linux และ Android บนแพลตฟอร์มฮาร์ดแวร์เดียวต้องใช้สถาปัตยกรรมซอฟต์แวร์ที่มีการประสานงาน

จุดสำคัญคือความสามารถแบบ dual-OS ไม่ได้หมายความว่าระบบปฏิบัติการทั้งสองจะทำงานพร้อมกันเสมอไป

การใช้งานบอร์ดพัฒนาส่วนใหญ่ใช้หนึ่งในสามแนวทาง:

1. ดูอัลบูต: เลือก Linux หรือ Android ระหว่างการเริ่มต้น

2. การสลับเฟิร์มแวร์: แฟลชอิมเมจ OS ที่จำเป็นเมื่อเปลี่ยนสภาพแวดล้อมของแอปพลิเคชัน

3. การจำลองเสมือนหรือสถาปัตยกรรมบนคอนเทนเนอร์: เรียกใช้ปริมาณงานแบบแยกที่รองรับภายใต้ระบบปฏิบัติการหลัก โดยขึ้นอยู่กับการสนับสนุน SoC และไฮเปอร์ไวเซอร์

สำหรับโปรเจ็กต์ OEM/ODM ของ Android TV Box ส่วนใหญ่ ดูอัลบูตหรือเฟิร์มแวร์แบบเลือกได้นั้นเป็นสถาปัตยกรรมที่ตรงไปตรงมามากกว่า

2.1 การกำหนดค่า U-Boot และ Bootloader

U-Boot รับผิดชอบในการเริ่มต้นแพลตฟอร์มฮาร์ดแวร์และโหลดระบบปฏิบัติการ

ในบอร์ดพัฒนาระบบปฏิบัติการคู่ บูตโหลดเดอร์จำเป็นต้องระบุระบบปฏิบัติการที่เลือก และโหลดการกำหนดค่าการบูตที่สอดคล้องกัน

ลำดับการบูตโดยทั่วไปคือ:

สถาปัตยกรรมแนวคิด ขั้นตอนการบูตและรูปแบบรูปภาพจริงจะแตกต่างกันไปตาม SoC และ BSP ของผู้จำหน่าย

ฟังก์ชั่น bootloader ที่สำคัญ ได้แก่ :

• การเริ่มต้น DDR และการกำหนดค่าฮาร์ดแวร์

• การตรวจจับ eMMC, SPI NOR, NAND หรือการ์ด SD

• กำลังโหลดรูปภาพเคอร์เนล

• การเลือกอุปกรณ์ Tree Blob (DTB)

• การกำหนดค่าอาร์กิวเมนต์การบูต

• การตรวจสอบการบูตอย่างปลอดภัยเมื่อจำเป็น

• รองรับการกู้คืนและอัปเกรดเฟิร์มแวร์

เอกสารการพัฒนาของ Rockchip อธิบายการกำหนดค่า U-Boot เฉพาะบอร์ด โครงสร้างอุปกรณ์เคอร์เนล แหล่งการบูต และขั้นตอนการติดตั้งเฟิร์มแวร์

Das U-Boot เอกสารเวอร์ชันที่ไม่รู้จัก +2

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

2.2 ความเข้ากันได้ของ Android BSP และ Linux BSP

BSP ย่อมาจาก Board Support Package โดยจัดเตรียมส่วนประกอบซอฟต์แวร์ที่จำเป็นในการใช้งานแพลตฟอร์มฮาร์ดแวร์เฉพาะ

Android BSP และ Linux BSP อาจใช้ SoC เดียวกัน แต่ยังคงมีการใช้งานไดรเวอร์ การกำหนดค่าเคอร์เนล สแตกกราฟิก และเฟรมเวิร์กมัลติมีเดียที่แตกต่างกัน

ปัญหาการพัฒนาที่สำคัญคือความพร้อมใช้งานของ GPU และไดรเวอร์ตัวถอดรหัสวิดีโอ

บอร์ดอาจบูต Linux ได้สำเร็จ แต่ขาดการเร่งด้วยฮาร์ดแวร์ที่จำเป็นสำหรับการเล่น 4K ในทำนองเดียวกัน ระบบ Android อาจแสดงอินเทอร์เฟซได้อย่างถูกต้องในขณะที่ฟังก์ชัน HDMI, เสียง, Wi-Fi หรือ Bluetooth บางอย่างยังไม่รองรับ

นี่คือเหตุผลว่าทำไมการพัฒนาระบบปฏิบัติการคู่ที่ประสบความสำเร็จจึงต้องมีการตรวจสอบฮาร์ดแวร์อย่างเต็มรูปแบบภายใต้ระบบปฏิบัติการทั้งสองระบบ

2.3 การเลือกการกระจาย Linux

การกระจาย Linux ควรตรงกับแอปพลิเคชันแทนที่จะเลือกตามความนิยมเพียงอย่างเดียว

สำหรับระบบที่ใช้งานจริง Buildroot และ Yocto มีความเกี่ยวข้องเป็นพิเศษเมื่อนักพัฒนาจำเป็นต้องควบคุมแพ็คเกจ เวลาบูต ขนาดระบบไฟล์ การกำหนดค่าความปลอดภัย และการบำรุงรักษาซอฟต์แวร์

ความพร้อมใช้งานของอิมเมจที่ใช้งานได้เพียงอย่างเดียวไม่เพียงพอ ผู้ซื้อควรขอความพร้อมใช้งานของแหล่งที่มาของเคอร์เนล ไฟล์แผนผังอุปกรณ์ คำแนะนำในการคอมไพล์ข้าม และเอกสารประกอบการเผยแพร่ BSP ที่เกี่ยวข้อง

3. การพัฒนาซอฟต์แวร์กล่อง Android TV แบบ Dual-OS: ไดรเวอร์ มัลติมีเดีย และ OTA

ความแตกต่างระหว่างบอร์ดพัฒนาและผลิตภัณฑ์พร้อมการผลิตคือคุณภาพของการรวมซอฟต์แวร์

บอร์ดพัฒนาอาจบูต Android และ Linux ได้สำเร็จ แต่การใช้งานเชิงพาณิชย์จำเป็นต้องมีข้อกำหนดเพิ่มเติม: ความเข้ากันได้ของมัลติมีเดีย การจัดส่งเนื้อหาที่ปลอดภัย การจัดการแอปพลิเคชัน การอัปเดตระยะไกล และความน่าเชื่อถือของฮาร์ดแวร์

3.1 การพัฒนาไดรเวอร์ฮาร์ดแวร์และการปรับอินเทอร์เฟซ

อุปกรณ์ต่อพ่วงทุกชิ้นที่เชื่อมต่อกับ PCBA ต้องใช้ไดรเวอร์และการกำหนดค่าระบบที่เข้ากันได้

งานพัฒนาทั่วไป ได้แก่ :

• การรวมไดรเวอร์อีเทอร์เน็ตและการกำหนดค่าเครือข่าย

• การปรับไดรเวอร์โมดูล Wi-Fi และ Bluetooth

• การรวมจอแสดงผล HDMI และไดรเวอร์เสียง

• โฮสต์ USB และฟังก์ชัน OTG

• การกำหนดค่าไดรเวอร์ GPIO, UART, I2C และ SPI

• รองรับ RTC และ Watchdog

• การจัดการพลังงานและพฤติกรรมการระงับ/ดำเนินการต่อ

การกำหนดค่า Device Tree มีความสำคัญอย่างยิ่งในการพัฒนา Linux

DTB อธิบายการกำหนดค่าฮาร์ดแวร์ให้กับเคอร์เนล รวมถึงขอบเขตหน่วยความจำ บัส การกำหนด GPIO ตัวควบคุม นาฬิกา และการเชื่อมต่ออุปกรณ์ต่อพ่วง

การกำหนดค่าแผนผังอุปกรณ์ที่ไม่ถูกต้องอาจทำให้เกิดความล้มเหลวในการเริ่มต้นฮาร์ดแวร์ แม้ว่าตัว PCB เองจะทำงานอย่างถูกต้องก็ตาม

สำหรับ Android ส่วนประกอบฮาร์ดแวร์ที่เกี่ยวข้องจะต้องรวมเข้ากับบริการ HAL และผู้จำหน่ายที่เหมาะสมด้วย

3.2 การเร่งความเร็วมัลติมีเดียและความเข้ากันได้ของ DRM

สำหรับบอร์ดพัฒนา Android TV Box ประสิทธิภาพด้านมัลติมีเดียมักเป็นเกณฑ์การคัดเลือกที่สำคัญ

การออกแบบการผลิตควรตรวจสอบ:

สำหรับบริการสตรีมมิ่งเชิงพาณิชย์ DRM และ HDCP ไม่ใช่รายละเอียดเพิ่มเติม

อาจจำเป็นต้องมีการจัดเตรียม Widevine, เส้นทางวิดีโอที่ปลอดภัย, การตรวจสอบสิทธิ์ HDCP และการรับรองเฉพาะบริการ ความพร้อมใช้งานไม่สามารถสันนิษฐานได้เพียงเพราะ SoC รองรับ Android

ระบบ Linux อาจรองรับการเล่นมัลติมีเดียในเครื่องโดยไม่ต้องจัดเตรียมระบบนิเวศการสตรีมที่ได้รับใบอนุญาตแบบเดียวกับอุปกรณ์ที่ได้รับการรับรอง Android

ด้วยเหตุนี้ ผู้ซื้อ B2B จึงควรแยกแยะระหว่าง:

• ความเข้ากันได้ของบอร์ดพัฒนา Android

• การรับรองแพลตฟอร์ม Android TV

• การรับรองของ Google และความพร้อมในการให้บริการของ Google Play

• Netflix หรือใบรับรองบริการสตรีมมิ่งอื่นๆ

• ข้อกำหนดสิทธิ์การใช้งาน DRM และ HDCP

ข้อกำหนดเหล่านี้เป็นข้อกำหนดทางวิศวกรรมและเชิงพาณิชย์ที่แยกจากกัน

3.3 การอัปเดต OTA และสถาปัตยกรรมการบำรุงรักษาระยะไกล

ควรพิจารณาการบำรุงรักษาซอฟต์แวร์ในระยะยาวในระหว่างการพัฒนาบอร์ดครั้งแรก

กล่อง Android TV ที่ใช้งานในโรงแรม ร้านค้าปลีก เครือข่าย IPTV หรือการติดตั้งป้ายดิจิทัลอาจต้องอัปเดตเฟิร์มแวร์โดยไม่ต้องมีการเข้าถึงทางกายภาพ

ผลิตภัณฑ์ dual-OS แนะนำข้อควรพิจารณาในการอัพเดตเพิ่มเติม

ระบบแอนดรอยโอต้า

กลไกการอัปเดต Android ควรรองรับแพ็คเกจเฟิร์มแวร์ที่ลงนามแล้ว การควบคุมเวอร์ชัน การกู้คืน และการอัปเดตระบบ A/B ในกรณีที่รองรับ

ระบบอัพเดตลินุกซ์

การอัพเดตเฟิร์มแวร์ Linux สามารถใช้การปรับใช้ตามอิมเมจ พาร์ติชันระบบไฟล์รูท A/B การจัดการแพ็คเกจ หรือกลไกการกู้คืนแบบกำหนดเอง

การจัดการระยะไกล

แพลตฟอร์มการจัดการแบบรวมศูนย์สามารถตรวจสอบ:

• เวอร์ชันเฟิร์มแวร์ของอุปกรณ์

• สถานะของระบบปฏิบัติการ

• การเชื่อมต่อเครือข่าย

• การใช้งาน CPU และหน่วยความจำ

• สุขภาพการจัดเก็บ

• บันทึกอุณหภูมิและระบบ

• อัปเดตสถานะการใช้งาน

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

สำหรับอุปกรณ์ระบบปฏิบัติการคู่ ระบบการอัพเดตจะต้องป้องกันบูตโหลดเดอร์และพาร์ติชันของระบบปฏิบัติการอื่นจากการแก้ไขโดยไม่ตั้งใจ

4. การปรับแต่ง PCBA และการบูรณาการทางอุตสาหกรรม: การเปลี่ยนบอร์ดพัฒนาให้เป็นผลิตภัณฑ์เชิงพาณิชย์

บอร์ดพัฒนามาตรฐานได้รับการออกแบบเพื่อให้สามารถเข้าถึงทรัพยากรฮาร์ดแวร์ได้ Android TV Box เชิงพาณิชย์ต้องมีการออกแบบที่เน้นมากขึ้น

ผลิตภัณฑ์ขั้นสุดท้ายอาจต้องใช้ PCB ที่เล็กลง ตัวเชื่อมต่อน้อยลง วงจรไฟฟ้าที่ปรับแต่งเอง กล่องหุ้มที่แตกต่างกัน และการกำหนดค่าเฟิร์มแวร์ที่ปรับให้เหมาะกับแอปพลิเคชันเดียว

นี่คือจุดที่วิศวกรรม OEM/ODM มีความสำคัญ

4.1 การเพิ่มประสิทธิภาพเค้าโครง PCBA

การปรับแต่ง PCBA สามารถตอบสนองความต้องการทางวิศวกรรมหลายประการ:

ขนาด PCB และการจัดวางส่วนประกอบ

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

สถาปัตยกรรมแหล่งจ่ายไฟ

วงจรอินพุต DC, การเลือก PMIC, ตัวควบคุมแรงดันไฟฟ้า, ส่วนประกอบการป้องกัน และการจัดลำดับพลังงานควรตรงกับ SoC และอุปกรณ์ต่อพ่วงที่เลือก

บูรณาการอุปกรณ์ต่อพ่วง

อินเทอร์เฟซเสริม เช่น RS232, RS485, CAN, GPIO, M.2, SATA หรือพอร์ต USB เพิ่มเติมสามารถพิจารณาได้ในกรณีที่ SoC และสถาปัตยกรรมบอร์ดรองรับ

EMI และความสมบูรณ์ของสัญญาณ

อินเทอร์เฟซความเร็วสูง การกำหนดเส้นทาง DDR การต่อสายดิน และการกระจายพลังงาน จำเป็นต้องมีการออกแบบและการตรวจสอบอย่างรอบคอบ

การจัดการความร้อน

SoC หน่วยความจำ และส่วนประกอบด้านพลังงานควรได้รับการประเมินร่วมกันเพื่อป้องกันความร้อนที่เข้มข้นภายในตัวเครื่องขนาดกะทัดรัด

4.2 โซลูชั่นการทำความเย็นสำหรับงานอุตสาหกรรม

บอร์ดพัฒนาที่ทำงานในห้องปฏิบัติการไม่จำเป็นต้องดำเนินการในลักษณะเดียวกันภายในตู้เชิงพาณิชย์ที่ปิดสนิท

การใช้งานทางอุตสาหกรรมอาจเกี่ยวข้องกับ:

• การดำเนินงานต่อเนื่องตลอด 24 ชั่วโมงทุกวัน

• อุณหภูมิแวดล้อมสูง

• การไหลของอากาศที่ถูกจำกัด

• อุปกรณ์ต่อพ่วงที่เชื่อมต่อหลายตัว

• การถอดรหัสวิดีโออย่างต่อเนื่องหรือปริมาณงาน AI

• ติดตั้งในตู้หรืออุปกรณ์แสดงผล

โซลูชันการระบายความร้อนที่เป็นไปได้ ได้แก่:

1. ฮีทซิงค์อะลูมิเนียมสำหรับการกระจายความร้อน SoC โดยตรง

2. แผ่นความร้อนและตัวกระจายความร้อนเพื่อปรับปรุงการสัมผัสระหว่างส่วนประกอบกับกล่อง

3. กรอบอะลูมิเนียมที่ทำหน้าที่เป็นตัวระบายความร้อนแบบพาสซีฟ

4. ท่อความร้อนสำหรับการใช้งานที่มีภาระความร้อนสูงกว่า

5. ระบบระบายความร้อนแบบแอคทีฟซึ่งการจัดการระบายความร้อนแบบพาสซีฟไม่สามารถตอบสนองความต้องการในการใช้งานได้

การออกแบบการระบายความร้อนควรได้รับการตรวจสอบโดยการทดสอบปริมาณงานเพิ่มเติม การตรวจสอบอุณหภูมิ และการวิเคราะห์การควบคุมปริมาณความร้อน

4.3 เฟิร์มแวร์ที่กำหนดเองและการรวม SDK/API

แอปพลิเคชันเชิงพาณิชย์ที่แตกต่างกันต้องมีพฤติกรรมของระบบปฏิบัติการที่แตกต่างกัน

ตัวอย่างเช่น:

SZTomato รองรับการพัฒนา Android TV Box แบบกำหนดเอง รวมถึงการปรับเปลี่ยนฮาร์ดแวร์ PCBA, เฟิร์มแวร์ UI/UX แบบกำหนดเอง, การรวม SDK/API และโซลูชันระบายความร้อนเฉพาะทางสำหรับการใช้งานทางอุตสาหกรรม

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

วัตถุประสงค์ไม่ใช่เพื่อให้อิมเมจระบบปฏิบัติการสองอิมเมจเป็นการส่งมอบแยกกัน มันคือการจัดหาแพลตฟอร์มฮาร์ดแวร์และซอฟต์แวร์ที่ผ่านการตรวจสอบซึ่งสนับสนุนการปรับใช้ตามที่ตั้งใจไว้

5. การพัฒนา SZTomato OEM/ODM: จากบอร์ดพัฒนาระบบปฏิบัติการคู่ไปจนถึงกล่อง Android TV แบบกำหนดเอง

สำหรับแบรนด์ฮาร์ดแวร์ ผู้ให้บริการ IPTV บริษัทโทรคมนาคม และผู้วางระบบ การเลือกบอร์ดพัฒนาเป็นเพียงก้าวแรกเท่านั้น

คำถามที่สำคัญกว่านั้นคือผู้ผลิตสามารถปรับแพลตฟอร์มให้ตรงกับความต้องการผลิตภัณฑ์ของลูกค้าและรักษาความเข้ากันได้ของซอฟต์แวร์ตลอดวงจรชีวิตผลิตภัณฑ์ได้หรือไม่

SZTomato (Shenzhen Tomato Technology Co., Ltd.) ให้บริการพัฒนาและผลิตฮาร์ดแวร์มัลติมีเดียมาตั้งแต่ปี 2554 โดยมุ่งเน้นที่ Android TV Box, กล่องรับสัญญาณ IPTV, เครื่องเล่นสื่อสตรีมมิ่ง, ป้ายดิจิทัล และโซลูชันมัลติมีเดียแบบฝังที่ปรับแต่งเอง

ความสามารถด้านวิศวกรรม OEM/ODM ครอบคลุมด้านต่อไปนี้:

การปรับเปลี่ยนฮาร์ดแวร์ PCBA

เค้าโครง PCB แบบกำหนดเอง วงจรไฟฟ้า การเลือกส่วนประกอบ อินเทอร์เฟซต่อพ่วง และการกำหนดค่าของเมนบอร์ด

การปรับแต่งเฟิร์มแวร์ Android/Linux

การรวมระบบปฏิบัติการ การกำหนดค่าเคอร์เนล การปรับไดรเวอร์ การปรับแต่งบูตโหลดเดอร์ และการเพิ่มประสิทธิภาพระดับแอปพลิเคชัน

การบูรณาการ SDK/API

การควบคุมฮาร์ดแวร์ การรวมแอปพลิเคชันของบุคคลที่สาม การจัดการอุปกรณ์ และการสื่อสารกับระบบภายนอก

วิศวกรรมความร้อนอุตสาหการ

ฮีทซิงค์ที่ปรับแต่งได้ อินเทอร์เฟซการระบายความร้อน การเพิ่มประสิทธิภาพตู้ และโซลูชันการระบายความร้อนเพื่อการทำงานที่ต่อเนื่อง

การผลิต OEM/ODM

การตรวจสอบฮาร์ดแวร์ การทดสอบการทำงาน การควบคุมคุณภาพการผลิต และการสนับสนุนทางเทคนิคระยะยาว

กระบวนการพัฒนาที่แนะนำ

สำหรับโปรเจ็กต์ Linux และ Android Dual-OS Android TV Box ขั้นตอนการพัฒนาเชิงปฏิบัติประกอบด้วย:

1. การวิเคราะห์ความต้องการ: กำหนดแอปพลิเคชัน, SoC ที่ต้องการ, ระบบปฏิบัติการ, หน่วยความจำ, พื้นที่เก็บข้อมูล และข้อกำหนดอินเทอร์เฟซ

2. การประเมินแพลตฟอร์ม: ยืนยันความพร้อมใช้งานของ Linux/Android BSP, เวอร์ชันเคอร์เนล, ไดรเวอร์ และความสามารถด้านมัลติมีเดีย

3. การพัฒนาฮาร์ดแวร์: การปรับเปลี่ยน PCBA การออกแบบพลังงาน การกำหนดค่าอินเทอร์เฟซ และวิศวกรรมด้านความร้อนโดยสมบูรณ์

4. การรวมซอฟต์แวร์: พัฒนาการกำหนดค่า bootloader, อิมเมจ OS, ไดรเวอร์เคอร์เนล, เฟิร์มแวร์ และฟังก์ชันการทำงานของ SDK/API

5. การตรวจสอบทางวิศวกรรม: ทดสอบความน่าเชื่อถือในการบูต การเล่นวิดีโอ การเชื่อมต่อเครือข่าย ความเข้ากันได้ของอุปกรณ์ต่อพ่วง และประสิทธิภาพการระบายความร้อน

6. การผลิตจำนวนมาก: สรุปการกำหนดค่าฮาร์ดแวร์ การเผยแพร่เฟิร์มแวร์ มาตรฐานคุณภาพ และเอกสารประกอบการผลิต

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

สรุป: การเลือกแพลตฟอร์มการพัฒนากล่อง Android TV แบบ Dual-OS ที่เหมาะสม

Linux และ Android Dual-OS กล่องแอนดรอยด์ทีวี บอร์ดพัฒนานำเสนอความยืดหยุ่นสำหรับบริษัทที่กำลังพัฒนาเทอร์มินัลมัลติมีเดีย ผลิตภัณฑ์ IPTV ระบบอุตสาหกรรม และอุปกรณ์ป้ายดิจิทัล

อย่างไรก็ตาม การสนับสนุนระบบปฏิบัติการคู่จะต้องได้รับการประเมินในระดับแพลตฟอร์มที่สมบูรณ์

ความเข้ากันได้ของ SoC, การกำหนดค่า U-Boot, ความพร้อมใช้งานของ BSP, ไดรเวอร์เคอร์เนล, สถาปัตยกรรมหน่วยความจำ, การแบ่งพาร์ติชันพื้นที่เก็บข้อมูล, การเร่งความเร็วมัลติมีเดีย และการบำรุงรักษา OTA ล้วนมีอิทธิพลต่อว่าบอร์ดพัฒนาจะกลายเป็นผลิตภัณฑ์เชิงพาณิชย์ที่เชื่อถือได้หรือไม่

สำหรับผู้ซื้อ B2B แพลตฟอร์มที่ดีที่สุดไม่จำเป็นต้องเป็นแพลตฟอร์มที่มีความถี่ CPU สูงสุดหรือมีอินเทอร์เฟซจำนวนมากที่สุด เป็นรุ่นที่ให้การผสมผสานที่ลงตัวระหว่างประสิทธิภาพของฮาร์ดแวร์ ความเข้ากันได้ของซอฟต์แวร์ ความยืดหยุ่นในการปรับแต่ง และการสนับสนุนด้านเทคนิคในระยะยาว

การพัฒนา Linux และ Android Dual-OS แบบกำหนดเอง กล่องแอนดรอยด์ทีวี ?

SZTomato รองรับการพัฒนาฮาร์ดแวร์มัลติมีเดีย OEM/ODM, การปรับเปลี่ยน PCBA, การปรับแต่งเฟิร์มแวร์ Android/Linux, การรวม SDK/API และการออกแบบระบบระบายความร้อนทางอุตสาหกรรม

ติดต่อทีมงานวิศวกร SZTomato ได้ที่ www.sztomato.com เพื่อหารือเกี่ยวกับการเลือก SoC, สถาปัตยกรรมระบบปฏิบัติการคู่, ข้อมูลจำเพาะของบอร์ดพัฒนา และข้อกำหนดการผลิตที่ปรับแต่งเอง