Input per l'adattamento del sistema RK3588: ambito Android, Linux e OpenHarmony

Guida di ingegneria

Per l'approvvigionamento della baseline SDK Android per scheda RK3588, verificare gli input, le evidenze e le voci irrisolte riportate di seguito prima di selezionare un approccio. Assegnare responsabili e modalità di acquisizione per i documenti mancanti; una sola dimostrazione non stabilisce compatibilità o prestazioni.

Cosa devono confermare le tre direzioni progettuali

Scorrere la tabella orizzontalmente per visualizzare tutte le colonne.

Direzione	Input principali	Attività da definire separatamente
Sistemi Android e applicazioni device	SDK Android del fornitore, scheda, periferiche e APK/SDK	Configurazione di sistema, permessi, interfacce periferiche, servizi applicativi, firma e aggiornamenti.
BSP Linux e applicazioni device	Bootloader, kernel, device tree, root filesystem e periferiche target	Avvio, driver, interfacce userspace, servizi, immagini e ripristino.
Adattamento OpenHarmony a stadi	Sorgenti specificate, documentazione della scheda e target di build/avvio	Valutare avvio minimo, servizi, grafica e multimedia come stadi separati.

Questa è una tabella delle responsabilità di progetto, non un elenco di compatibilità cross-system. Rivalutare i record di verifica esistenti quando cambiano OS, SDK o scheda.

Input da preparare prima di richiedere un preventivo

• Modello completo della scheda, revisione, schematico, storage e connessioni di debug.

• SDK/sorgenti, versione o commit, toolchain, comandi di build e immagini esistenti.

• Modelli delle periferiche, interfacce, modalità target e stati operativi attuali.

• Applicazioni, interfacce, permessi, input/output e dipendenze di terze parti.

• Passaggi di riproduzione, log, frequenza e tentativi di risoluzione per i guasti esistenti.

• Sorgenti concordate, patch, immagini, documentazione e responsabilità di manutenzione.

Elencare i documenti non disponibili come lacune e concordare come ottenerli o definire una fase di valutazione. Non colmare le lacune con versioni non verificate.

Definire condizioni di accettazione ripetibili

Sostituire "adattamento di sistema completato" con condizioni quali l'avvio della versione specificata sulla scheda specificata dal supporto specificato, verificando log e servizi tramite passaggi documentati. Display, fotocamera, audio, rete, applicazioni, aggiornamenti e test di durata richiedono ciascuno condizioni proprie; l'avvio minimo non li copre automaticamente.

Per attività NPU, aggiungere modello, campioni, pre-elaborazione, post-elaborazione e ambiente target. Un sistema avviabile non costituisce evidenza di deployment del modello.

Utilizzare i casi documentati per comprendere gli stadi di progetto

Il caso originale cinese OpenHarmony RK3588 Stage-0 documenta uno stadio di avvio headless limitato su una scheda specifica. I relativi log e controlli immagine illustrano la consegna a stadi; non attestano il completamento di grafica, multimedia o certificazioni di produzione.

L'integrazione di applicazioni Android può fare riferimento al caso SDK TTS offline, mantenendo i confini di sistema, dispositivo e test propri del caso.

Suddividere i pacchetti di lavoro successivi

Se si dispone già di un SDK ma le periferiche non sono funzionanti, consultare l'adattamento Android o il servizio BSP Linux. La conversione dei modelli e l'integrazione dell'inferenza rientrano nel servizio NPU. Questi link rimandano agli ambiti originali in cinese. Preparare scheda, versione, interfaccia e input di test prima di valutare ambito e costi di sviluppo.

Checklist di approvvigionamento

Scorrere la tabella orizzontalmente per visualizzare tutte le colonne.

Voce	Input e controlli	Limite decisionale
Corrispondenza versioni	Associare revisione scheda, commit SDK, patch e immagine esistente	Lo stesso processore non garantisce la compatibilità a livello di scheda
Accesso a sorgenti e build	Confermare ambito sorgenti, toolchain, accesso alle dipendenze e diritti di build	Assegnare responsabili per gli input mancanti anziché sostituire con versioni non verificate
Firma e rilascio	Distinguere build di debug, servizi di firma, aggiornamenti e licenze di terze parti	Le chiavi private di produzione non devono essere consegnate allo sviluppatore; concordare un processo di firma controllato

Quali input sono necessari prima di iniziare?

Modello completo e revisione della scheda, SDK Android, istruzioni di build, immagini esistenti, elenco periferiche e log seriali. Verificare prima versioni e disponibilità dei documenti e conservare le voci mancanti come input da confermare.

Come definire consegna e accettazione?

Eseguire build e avvio della scheda target nell'ambiente concordato seguendo la procedura consegnata; verificare versioni, log e problemi e concordare la gestione dei difetti bloccanti. Una baseline riproducibile non attesta la readiness di periferiche, applicazioni, durata o produzione; definire Linux e OpenHarmony come progetti separati.

Le aziende di Shenzhen, Cina, possono inviare questi input per una revisione remota. Concordare integrazione prototipo, spedizione campioni, attività in loco e costi associati per il progetto specifico.

Controlli aggiuntivi per l'approvvigionamento di schede target Linux

Scorrere la tabella orizzontalmente per visualizzare tutte le colonne.

Voce	Input e controlli	Limite decisionale
Scheda e supporto	Verificare revisione scheda, configurazione storage e selezione boot	Lo stesso processore non garantisce una configurazione di avvio identica
Componenti SDK	Elencare versioni di bootloader, kernel, device tree, root filesystem e toolchain	Distinguere binari del fornitore, sorgenti modificabili e diritti di ridistribuzione
Debug e ripristino	Confermare livelli seriali, cablaggio, strumenti di ripristino e accessi autorizzati	Non sovrascrivere il supporto di avvio originale senza un percorso di ripristino

Questi controlli aggiuntivi supportano le revisioni della baseline Linux per le aziende di Tianjin, Cina. Definire separatamente gli ambiti Android, Linux e OpenHarmony; i risultati dei test non sono intercambiabili.

Esaminare l'ambito del servizio e inviare gli input del progetto prima di concordare sviluppo e consegna. Ambito del servizio nel testo originale in cinese