Contenuto nascondere
1 Avvio sicuro TQMa93
2 Informazioni sul prodotto
3 Procedura
4 Preparazione
5 U-Boot
6 Immagine FIT
7 Domande frequenti
8 Documenti / Risorse
8.1 Riferimenti

Logo TQMa93

Avvio sicuro TQMa93

Prodotto TQMa93-Secure-Boot

Informazioni sul prodotto

Specifiche

  • Modello: TQMa93xx
  • Sistema operativo: Linux (Ubuntu 22.04)
  • Funzione di sicurezza: avvio protetto

ATTENZIONE: In questa guida vengono impostati i fusibili (programmabili una sola volta); questo processo è irreversibile. Si consiglia pertanto vivamente di utilizzare un modello di sviluppo per questa guida.

Procedura

Questa guida spiega come stabilire una catena di fiducia dal boot loader tramite il kernel Linux fino a una partizione root con dm-verity.
La tabella seguente fornisce una descrizione semplificata dei passaggi coinvolti nella creazione della catena di attendibilità e verifica durante il processo di avvio:

TQMa93-Secure-Boot-01

Preparazione

Per creare un flusso di avvio firmato per TQMa93xx sono necessari i seguenti progetti:

Il bootstream per TQMa93xx è costituito da diversi artefatti. Per ottenere tutti questi artefatti dalla stessa fonte, si consiglia di utilizzare l'area di lavoro TQ Yocto ci-meta-tq. Le istruzioni incluse possono essere seguite per creare un'immagine completa (tq-image-weston-debug o tq-image-generic-debug) per uno dei seguenti dispositivi basati su TQMa93xx:

  • tqma93xx-mba91xxca.conf
  • tqma93xx-mba93xxca.conf
  • tqma93xxla-mba93xxla.conf

ATTENZIONE: Per creare U-Boot con funzionalità di avvio sicuro (AHAB), è necessario aggiungere la seguente riga a local.conf:
DISTRO_FEATURES:append = "sicuro"
Successivamente, è necessario ricreare il flusso di avvio:
$ bitbake imx-boot

L'area di lavoro di TQ Yocto può essere utilizzata anche per creare un'immagine completa della catena di fiducia qui presentata. Le impostazioni necessarie a tale scopo sono descritte nella sezione 5.2.
I sorgenti del kernel Linux e di U-Boot sono facoltativi ma consigliati. Possono essere scaricati da Github:

U-Boot

Generazione delle chiavi
La firma e la verifica del flusso di avvio vengono eseguite utilizzando un'infrastruttura a chiave pubblica (PKI). Se non è già disponibile, è possibile utilizzare il Code Signing Tool per creare una PKI adatta. Il CST 3.4.x è un archivio tar.gz che deve solo essere decompresso. Non è necessaria alcuna ulteriore installazione. Per generare il file s, è possibile seguire i seguenti passaggi:ample chiavi per questa guida:

ATTENZIONE: I percorsi sono relativi alla cartella estratta dall'archivio.

  1. Inserire il numero di serie del primo certificato in keys/serial (file deve essere creato): 12345678
  2. Inserisci la passphrase due volte in keys/key_pass.txt (file deve essere creato):
    la mia_passphrase la mia_passphrase
  3. Crea albero PKI:
    $ chiavi/ahab_pki_tree.sh -existing-ca n -kt ecc -kl p521 -da sha512 -duration 10 -srk-ca n
    Per una spiegazione delle opzioni, fare riferimento alla Guida utente contenuta nel CST (nella sottocartella docs) o all'opzione –help dello script sopra.
    In alternativa, lo script può essere richiamato anche senza opzioni e configurato in modalità interattiva.
    Lo script genera chiavi in ​​keys/ e certificati in crts/.
  4. Crea la tabella SRK e la tabella hash SRK:
    $ linux64/bin/srktool -a -s sha512 -d sha256 -t SRK_1_2_3_4_table.bin \
    -e SRK_1_2_3_4_fuse.bin -f 1 -c
    crts/SRK1_sha512_secp521r1_v3_usr_crt.pem,crts/SRK2_sha512_secp521r1_v3_usr_crt. pem,crts/SRK3_sha512_secp521r1_v3_usr_crt.pem,crts/SRK4_sha512_secp521r1_v3_usr_ crt.pem
  5. Scrivi la tabella hash SRK in fuses:
    ATTENZIONE: Questo passaggio è possibile solo una volta ed è irreversibile. I seguenti valori sono solo esemplificativi.ampe devono essere sostituiti dai tuoi valori.
    • Visualizza hash:
      $ hexdump -e '/4 “0x”' -e '/4 “%X””\n”' SRK_1_2_3_4_fuse.bin
      0x00000000
      0x11111111
      0x22222222
      0x33333333
      0x44444444
      0x55555555
      0x66666666
      0x77777777
    • Scrivere gli hash nei fusibili (TQMa93xx U-Boot):
      => fusibile prog 16 0 0x00000000
      => fusibile prog 16 1 0x11111111
      => fusibile prog 16 2 0x22222222
      => fusibile prog 16 3 0x33333333
      => fusibile prog 16 4 0x44444444
      => fusibile prog 16 5 0x55555555
      => fusibile prog 16 6 0x66666666
      => fusibile prog 16 7 0x77777777

 Creazione di un flusso di avvio firmato

 U-Boot Proper e ATF

  1. Copia il testo richiesto files (creazione riuscita di un'immagine TQ, vedere sopra, oppure si presumono le sorgenti U-Boot):
    • Firmware ARM Trusted: ${DEPLOY_DIR_IMAGE}/bl31-imx93.bin, rinomina in bl31.bin
    • U-Boot Proper:
      ${DEPLOY_DIR_IMAGE}/u-boot.bin
      Questo file è un collegamento, quindi copialo con cp –-dereference o visualizza e copia l'originale file con ls –-long
      or
      da sorgenti U-Boot autocompilate
      Questi filedevono essere copiati in imx-mkimage/iMX9/. imx-mkimage può essere ottenuto dal repository Github menzionato sopra, non è necessaria alcuna installazione.
  2. Crea il contenitore con U-Boot Proper e ATF (esegui nella cartella imx-mkimage):
    $ make SOC=iMX9 REV=A1 u-boot-atf-container.img include autobuild.mak
    • …
    • CST: CONTENITORE 0 offset: 0x0
    • CST: CONTENITORE 0: Blocco firma: l'offset è a 0x110
    • Offset = 0x0 0x110
    • FATTO.
    • Nota: si prega di copiare l'immagine per compensare: IVT_OFFSET + IMAGE_OFFSET
      ATTENZIONE: nel passaggio successivo saranno necessari gli offset per il contenitore e il blocco della firma.
    • L'artefatto imx-mkimage/iMX9/u-boot-atf-container.img deve quindi essere copiato nella cartella CST decompressa nel passaggio "3.1 Generazione delle chiavi".
  3. Trasferisci l'offset del contenitore e del blocco della firma alla sequenza di comandi File (CSF):
    • [Intestazione]
    • Obiettivo = ACHAB
    • Versione = 1.0
    • [Installa SRK]
    • File = “SRK_1_2_3_4_table.bin”
    • Source = “crts/SRK1_sha512_secp521r1_v3_usr_crt.pem”
    • Indice sorgente = 0
    • Set sorgente = OEM
    • Revoche = 0x0
    • [Autenticazione dati]
    • File = “u-boot-atf-container.img”
    • Offset = 0x0 0x110
    • CSF basato su: https://github.com/nxp-imx/uboot-imx/blob/lf_v2024.04/doc/imx/ahab/csf_examples/csf_uboot_atf.txt
    • Il CSF è memorizzato anche nella cartella CST con il nome csf_uboot_atf.txt, che è stata decompressa nel passaggio “3.1 Generazione delle chiavi”.
  4. Contenitore dei segni (percorso relativo alla cartella CST):
    $ linux64/bin/cst -i csf_uboot_atf.txt -o signed-u-boot-atf-container.img Il contenitore firmato deve quindi essere copiato nuovamente in imx-mkimage/iMX9/u-boot-atf-container.img. Notare la ridenominazione in u-boot-atf-container.img.

 Bootstream completo

  1. Copia il testo richiesto files (si presume la compilazione riuscita di un'immagine TQ, vedere sopra, o delle sorgenti U-Boot):
    • Firmware Edgelock Secure Enclave: ${DEPLOY_DIR_IMAGE}/mx93a1-ahab-container.img
    • Firmware RAM: ${DEPLOY_DIR_IMAGE}/lpddr4*.bin
    • Livello di pressione sonora U-Boot:
      ${DEPLOY_DIR_IMAGE}/u-boot-spl.bin
      Questo file è un collegamento, quindi copialo con cp –-dereference o visualizza e copia l'originale file con ls –-long
      or
      da sorgenti U-Boot autocompilate
    • Contenitore firmato con U-Boot Proper e ATF dal passaggio "3.2.1 U-Boot Proper e ATF"
      Questi files devono essere copiati anche in imx-mkimage/iMX9/.
  2. Crea bootstream
    • $ make -j8 SOC=iMX9 REV=A1 flash_singleboot
      includere autobuild.mak
    • …
    • CST: CONTENITORE 0 offset: 0x400
    • CST: CONTENITORE 0: Blocco firma: l'offset è a 0x490
    • Offset = 0x400 0x490
    • FATTO.
    • Nota: Si prega di copiare l'immagine per compensare: IVT_OFFSET + IMAGE_OFFSET aggiungere u-boot-atf-container.img a 379 KB, psize=1024
    • 1145+0 record in
    • 1145+0 record fuori
    • 1172480 byte (1.2 MB, 1.1 MiB) copiati, 0.00266906 s, 439 MB/s
    • ATTENZIONE: Nel passaggio successivo saranno richiesti gli offset per il contenitore e il blocco della firma.
      L'artefatto imx-mkimage/iMX9/flash.bin deve quindi essere copiato nella cartella CST decompressa nel passaggio "3.1 Generazione delle chiavi".
  3. Trasferisci l'offset del contenitore e del blocco della firma alla sequenza di comandi File (CSF):
    • [Intestazione]
    • Obiettivo = ACHAB
    • Versione = 1.0
    • [Installa SRK]
    • File = “SRK_1_2_3_4_table.bin”
    • Source = “crts/SRK1_sha512_secp521r1_v3_usr_crt.pem”
    • Indice sorgente = 0
    • Set sorgente = OEM
    • Revoche = 0x0
    • [Autenticazione dati]
    • File = “flash.bin”
    • Offset = 0x400 0x490
    • CSF basato su: https://github.com/nxp-imx/uboot-imx/blob/lf_v2024.04/doc/imx/ahab/csf_examples/csf_boot_image.txt
    • Il CSF è memorizzato nella cartella CST con il nome csf_boot_image.txt, decompresso nel passaggio “3.1 Generazione delle chiavi”.
  4. Firma il bootstream
    • linux64/bin/cst -i csf_boot_image.txt -o signed-flash.bin

I passaggi per la sostituzione del flusso di avvio possono essere trovati nel livello BSP (https://github.com/tq-systems/meta-tq) sotto meta-tq/doc.

Verifica
Per verificare se il flusso di avvio firmato è valido, utilizzare il comando ahab_status in U-Boot:

  • => stato_ahab
  • Ciclo di vita: 0x00000008, OEM aperto
  • Nessun evento trovato!
  • Se viene rilevato un evento, il flusso di avvio non è valido e non sarà possibile avviarlo su un dispositivo bloccato.

Per la falsificazione, è possibile avviare un bootstream non firmato e quindi chiamare ahab_status:

  • => stato_ahab
  • Ciclo di vita: 0x00000008, OEM aperto
  • 0x0287fad6
  • IPC = MU APD (0x2)
  • CMD = ELE_OEM_CNTN_AUTH_REQ (0x87)
  • IND = ELE_BAD_KEY_HASH_FAILURE_IND (0xFA)
  • STA = ELE_SUCCESS_IND (0xD6)
  • 0x0287fad6
  • IPC = MU APD (0x2)
  • CMD = ELE_OEM_CNTN_AUTH_REQ (0x87)
  • IND = ELE_BAD_KEY_HASH_FAILURE_IND (0xFA)
  • STA = ELE_SUCCESS_IND (0xD6)

 Blocca il dispositivo

ATTENZIONE: Questo passaggio è irreversibile e deve essere eseguito solo se necessario. Se la configurazione non è corretta, questo passaggio renderà il dispositivo inutilizzabile.

Il dispositivo può essere bloccato in U-Boot con il comando ahab_close. Ciò significa che verranno avviati solo i flussi di avvio validi verificati dalla Boot ROM. Dopo il riavvio, viene visualizzato il seguente stato:

  • => stato_ahab
  • Ciclo di vita: 0x00000020, OEM chiuso
  • Nessun evento trovato!

Immagine FIT

ATTENZIONE: Le informazioni sul percorso sono relative a una nuova cartella vuota, ad esempio
fit_image_work, o i sorgenti del kernel, se autocompilati. Di seguito denominati directory di lavoro.

Generazione di una coppia di chiavi
Per firmare l'immagine FIT viene utilizzata una coppia di chiavi asimmetriche. Tale coppia può essere generata con OpenSSL:

$ openssl genpkey -algorithm RSA -out dev.key -pkeyopt rsa_keygen_bits:2048
$ openssl req -batch -new -x509 -key dev.key -out dev.crt

Crea sorgente albero immagini

  • Crea l'origine dell'albero delle immagini sign.its per l'immagine FIT.
  • /dts-v1/;
  • / {
  • descrizione = “Kernel fitImage per TQMa93xx”;
  • #cellule-indirizzo = <1>;
  • immagini {
  • kernel-1 {
  • descrizione = “kernel Linux”;
  • dati = /incbin/(“Immagine”);
  • tipo = “kernel”;
  • arco = “arm64”;
  • sistema operativo = “linux”;
  • compressione = “gzip”;
  • carico = <0x90000000>;
  • voce = <0x90000000>;
  • hash-1 {
  • algoritmo = “sha256”;
  • };
  • };
  • fdt-1 {
  • descrizione = "Blob dell'albero dei dispositivi appiattito";
  • dati = /incbin/(“ ”);
  • tipo = “flat_dt”;
  • arco = “arm64”;
  • compressione = “nessuna”;
  • carico = <0x97000000>;
  • hash-1 {
  • algoritmo = “sha256”;
  • };
  • };
  • };
  • configurazioni {
  • predefinito = “conf-1”;
  • conf-1 {
  • descrizione = “Kernel Linux, blob FDT”;
  • kernel = “kernel-1”;
  • fdt = “fdt-1”;
  • hash-1 {
  • algoritmo = “sha256”;
  • };
  • firma-1 {
  • algoritmo = “sha256,rsa2048”;
  • suggerimento-nome-chiave = “dev”;
  • imbottitura = “pkcs-1.5”;
  • sign-images = “kernel”, “fdt”;
  • };
  • };
  • };
  • };

 Creazione di un'immagine FIT firmata

Nota: Per questo passaggio è necessario il binario devicetree per U-Boot. I binari devicetree già pronti sono disponibili nell'area di lavoro Yocto, nella directory di build di U-Boot. Il percorso della directory di build può essere visualizzato con bitbake virtual/bootloader –e | grep ^B=.

  1. Copia il testo richiesto files nella directory di lavoro:
    • Rinominare il devicetree U-Boot imx93-tqma9352-mba91xxca.dtb, imx93-tqma9352-mba93xxca.dtb o imx93-tqma9352-mba93xxla.dtb, in pubkey.dtb:
      Dalla directory di compilazione U-Boot nell'area di lavoro Yocto (percorso: bitbake virtual/bootloader –e | grep ^B=)
      or
      da sorgenti U-Boot autocompilate
    • Kernel Linux:
      ${DEPLOY_DIR_IMAGE}/Immagine
      Questo file è un collegamento, quindi copialo con cp –-dereference o visualizza e copia l'originale file con ls –-long
      or
      da sorgenti Linux autocompilate
    • Albero dei dispositivi Linux:
      A seconda della variante ${DEPLOY_DIR_IMAGE}/imx93-tqma93…
      Questo file è un collegamento, quindi copialo con cp –-dereference o visualizza e copia l'originale file con ls –-long
      or
      da sorgenti Linux autocompilate
    • Le chiavi generate nel passaggio 4.1
    • L'ITS file generato nel passaggio 4.2
  2. Crea un'immagine FIT con firma
    $ mkimage -f sign.its -K pubkey.dtb -k . -r image.itb
    La chiave pubblica viene scritta nel devicetree dell'U-Boot. Questa chiave viene utilizzata per verificare l'immagine FIT firmata sopra.

ATTENZIONE: Per impacchettare il devicetree di U-Boot con la chiave pubblica nel bootstream firmato del capitolo 3.2, è necessario ripetere i passaggi del capitolo 3.2 con un file u-boot.bin personalizzato di U-Boot. Per fare ciò, è necessario specificare il devcietree con la chiave pubblica pubkey.dtb tramite l'opzione EXT_DTB durante la compilazione di U-Boot:
crea EXT_DTB=

Verifica
In U-Boot con chiavi pubbliche, l'immagine FIT firmata image.itb può essere avviata con bootm dopo essere stata caricata da un supporto adatto (TFTP, eMMC, SD).
Durante l'avvio dell'immagine FIT, U-Boot restituisce le informazioni Verifica dell'integrità dell'hash … sha256,rsa2048:dev+ OK con nome, algoritmo e lunghezza della chiave generata nel capitolo 4.1 sulla console:

  • ## Caricamento del kernel dall'immagine FIT a 80400000 …
    …
  • Verifica dell'integrità dell'hash … sha256,rsa2048:dev+ OK
    …
  • ## Caricamento del ramdisk dall'immagine FIT a 80400000 …
    …
  • Verifica dell'integrità dell'hash … sha256,rsa2048:dev+ OK
    …
  • ## Caricamento fdt dall'immagine FIT a 80400000 …
    …
  • Verifica dell'integrità dell'hash … sha256,rsa2048:dev+ OK
    …

Per la falsificazione, è possibile generare un'altra coppia di chiavi come descritto nella sezione 4.1 e utilizzarla per firmare l'immagine FIT. Questa immagine FIT non può essere avviata senza scambiare la chiave nel Devicetree di U-Boot:
## Caricamento del kernel dall'immagine FIT a 80400000 …

Utilizzo della configurazione 'conf-1'
Verifica dell'integrità dell'hash... sha256,rsa2048:test- errore!
Verifica fallita per ' ' nodo hash nel nodo di configurazione 'conf-1'
Impossibile verificare la firma richiesta 'key-dev'
Hash dati errato
ERRORE: impossibile ottenere l'immagine del kernel!

Estendi la catena di fiducia: partizione root
La catena di attendibilità precedentemente stabilita verifica l'origine di U-Boot e del kernel Linux. Con i meccanismi sopra menzionati, solo il proprietario della chiave privata generata può firmare il proprio software e avviarlo sul dispositivo. Ulteriori collegamenti possono essere aggiunti alla catena. La sezione seguente illustra come proteggere la partizione di root da manipolazioni utilizzando dm-verity. Per l'implementazione reale, viene anche mostrato come creare la catena completa con TQ-BSP. Una guida dettagliata alla protezione di dm-verity è stata omessa a causa della complessità dei requisiti.

 Schizzo: Verity Devicemapper

  1. Genera hash Verity:
    Veritysetup calcola i valori hash e li memorizza alla fine della partizione root. La partizione root può essere una partizione reale file o un dispositivo a blocchi file (ad esempio /dev/sdaX).
    • veritysetup \
    • –dimensione-blocco-dati=1024 \
    • –hash-block-size=4096 \
    • –offset-hash= \
    • formato \
    • \
    • veritysetup restituisce le seguenti informazioni (con valori corrispondentemente diversi):
    • Informazioni sull'intestazione VERITY per data.img
    • UUID: e06ff4cb-6b56-4ad4-bd97-0104505a70a5
    • Tipo di hash: 1
    • Blocchi dati: 204800
    • Dimensione del blocco dati: 1024
    • Dimensione del blocco hash: 4096
    • Algoritmo hash: sha256
    • Salt: 17328c48990b76fbb3e05d0ebfd236043674cf0d14c278bc875b42693621cc21
    • Root hash: a0e1a449d452f74d041706b955794c0041e3d8ad051068df6589e08485323698
    • L'hash di root è il valore sensibile che deve essere protetto. Se questo hash viene compromesso, ad esempio se può essere modificato da una persona non autorizzata, la protezione dell'integrità della partizione di root da parte di dm-verity è inutile.
  2. Integrare l'hash radice nella catena di fiducia
    • L'hash radice generato sopra viene memorizzato nell'immagine FIT firmata, che lo protegge da manipolazioni. A tale scopo, all'immagine FIT viene aggiunto un initramfs in cui l'hash radice viene memorizzato in un file.
    • Il nodo immagini dell'ITS file dal capitolo 4.2 è ampliato, tra gli altri, dalla seguente sezione:
    • ramdisk-1 {
    • descrizione = “dm-verity-image-initramfs”;
    • dati = /incbin/(“ ”);
    • tipo = “ramdisk”;
    • arco = “arm64”;
    • sistema operativo = “linux”;
    • compressione = “nessuna”;
    • carico = <0x98000000>;
    • voce = <0x98000000>;
    • hash-1 {
    • algoritmo = “sha256”;
    • };
    • };
  3. Controllare l'integrità della partizione root
    • L'initramfs contiene uno script adatto che genera un device mapper dalla partizione root e dall'hash root.
    • veritysetup \
    • –dimensione-blocco-dati=${DIMENSIONE_BLOCCO_DATI} \
    • –offset-hash=${DIMENSIONE_DATI} \
    • crea rootfs \
    • \
    • \

Il mappatore del dispositivo viene quindi montato:

  • montare \
  • -o ro\
  • /dev/mapper/rootfs \
  • /rootfs

La radice fileil sistema è di sola lettura. Per passare alla radice effettiva filesistema, utilizzare switch-root.

Creazione automatizzata con TQ-BSP
In linea di principio, con TQ-BSP è possibile creare automaticamente un'immagine con una catena di fiducia dal boot loader alla partizione root.
Per TQMa93xx è necessario aggiungere le seguenti opzioni a local.conf:

  • # Le opzioni di configurazione DISTRO_FEATURE sono necessarie per proteggere U-Boot e Kernel
  • DISTRO_FEATURES:append = "sicuro"
  • # Nome della chiave utilizzata per firmare il bootloader
  • IMX_HAB_KEY_NAME = “ahab”
  • # Attiva la firma dell'immagine FIT nel processo di compilazione
  • UBOOT_SIGN_ENABLE = “1”
  • # Questa classe contiene la logica per creare una partizione root protetta
  • IMAGE_CLASSES += “dm-verity-img”
  • # Nome dell'immagine initramfs per la gestione di dm-verity
  • INITRAMFS_IMAGE = “dm-verity-image-initramfs”
  • # Initramfs è memorizzato come un artefatto separato nell'immagine
  • INITRAMFS_IMAGE_BUNDLE = “0”
  • # Memorizza l'immagine FIT con initramfs nella partizione di avvio
  • IMAGE_BOOT_FILES:append = ” fitImage-${INITRAMFS_IMAGE}-${MACHINE}-
  • ${MACHINE};fitImage” # Immagine da proteggere con dm-verity
  • # Alternativa: tq-image-weston-debug
  • DM_VERITY_IMAGE = “tq-image-generic-debug”
  • # Tipo dell'immagine sopra
  • DM_VERITY_IMAGE_TYPE = “ext4”

ATTENZIONE: Le opzioni esatte potrebbero cambiare nelle versioni future del BSP. Le informazioni più recenti sono disponibili nella documentazione del livello BSP (https://github.com/tq-systems/meta-tq) sotto meta-tq/doc.

L'immagine completa viene creata con bitbake tq-image-generic-debug e può quindi essere scritta su una scheda SD, ad esempioamplui.

Verifica
In Linux, mount -a può essere utilizzato per verificare se Verity Devicemapper è montato come root filesistema:

  • # montare
  • …
  • /dev/mapper/rootfs su / tipo ext4 (ro,relatime)
  • …
  • Inoltre, l'intera radice file in questo caso il sistema è di sola lettura:
  • # test del tocco
  • tocco: impossibile toccare 'test': sola lettura file sistema

Per la falsificazione, la radice file Il sistema può essere modificato offline e il dispositivo riavviato. La modifica causa un hash di root diverso e il processo di avvio viene interrotto: device-mapper: verity: 179:98: il blocco dati 1 è danneggiato.

Ulteriori informazioni sul TQMa93xx sono disponibili nel TQ Support Wiki: https://support.tq-group.com/en/arm/modules#nxp_imx_9_series

TQ-Systems GmbH
Mühlstraße 2 l Gut Delling l 82229 Seefeld Info@TQ-Group | TQ-Group

Domande frequenti

D: È possibile invertire il processo irreversibile di impostazione dei fusibili menzionato nella Guida?
R: No, l'impostazione dei fusibili è irreversibile. Si consiglia di utilizzare un modello di sviluppo.

D: Dove posso trovare le fonti necessarie per Linux e U-Boot?

A: Linux:
Repository Linux
Sottomarino: U-Boot
Deposito

Documenti / Risorse

TQ TQMa93 Avvio sicuro [pdf] Guida utente
TQMa93xx, TQMa93 Avvio sicuro, Avvio sicuro, Avvio

Riferimenti

Lascia un commento

Il tuo indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *