Contidos ocultar
1 Arranque seguro TQMa93
2 Información do produto
3 Procedemento
4 Preparación
5 U-Boot
6 Imaxe FIT
7 Preguntas frecuentes
8 Documentos/Recursos
8.1 Referencias

Logotipo de TQMa93

Arranque seguro TQMa93

Produto de arranque seguro TQMa93

Información do produto

Especificacións

  • Modelo: TQMa93xx
  • Sistema operativo: Linux (Ubuntu 22.04)
  • Función de seguridade: Arranque seguro

ATENCIÓN: Os fusibles (programables dunha soa vez) establécense nesta guía práctica; este proceso é irreversible. Polo tanto, recoméndase encarecidamente usar un patrón de desenvolvemento para esta guía.

Procedemento

Esta guía explica como se pode establecer unha cadea de confianza desde o cargador de arranque a través do kernel de Linux ata unha partición raíz con dm-verity.
A seguinte táboa ofrece unha descrición simplificada dos pasos implicados na creación da cadea de confianza e verificación durante o proceso de arranque:

TQMa93-Arranque-seguro-01

Preparación

Os seguintes proxectos son necesarios para crear un fluxo de arranque asinado para TQMa93xx:

O fluxo de arranque para TQMa93xx consta de varios artefactos. Para obter todos estes artefactos da mesma fonte, recoméndase usar o espazo de traballo ci-meta-tq de TQ Yocto. As instrucións incluídas alí pódense seguir para crear unha imaxe completa (tq-image-weston-debug ou tq-image-generic-debug) para un dos seguintes dispositivos baseados en TQMa93xx:

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

ATENCIÓN: Para crear U-Boot con funcionalidade de arranque seguro (AHAB), débese engadir a seguinte liña a local.conf:
CARACTERÍSTICAS_DE_DISTRIBUCIÓN: engadir = "seguro"
A continuación, débese recrear o fluxo de arranque:
$ bitbake imx-boot

O espazo de traballo de TQ Yocto tamén se pode usar para crear unha imaxe da cadea de confianza completa que se presenta aquí. A configuración necesaria para isto descríbese na sección 5.2.
As fontes para o kernel de Linux e U-Boot son opcionais pero recomendables. Pódense descargar desde Github:

U-Boot

Xerando claves
A sinatura e a verificación do fluxo de arranque lévanse a cabo mediante unha infraestrutura de clave pública (PKI). Se aínda non está dispoñible, pódese usar a ferramenta de sinatura de código para crear unha PKI axeitada. O CST 3.4.x é un arquivo tar.gz que só precisa ser descomprimido. Non é necesaria ningunha instalación adicional. Os seguintes pasos pódense seguir para xerar o sampclaves para esta guía:

ATENCIÓN: As rutas son relativas ao cartafol extraído do arquivo.

  1. Introduza o número de serie do primeiro certificado en claves/serie (file debe crearse): 12345678
  2. Introduza o contrasinal dúas veces en keys/key_pass.txt (file debe crearse):
    o_miño_contrasinal o_miño_contrasinal
  3. Crear árbore PKI:
    $ keys/ahab_pki_tree.sh -existing-ca n -kt ecc -kl p521 -da sha512 -duration 10 -srk-ca n
    Para obter unha explicación das opcións, consulte a Guía do usuario contida no CST (na subcartafol docs) ou a opción –help do script anterior.
    Alternativamente, o script tamén se pode chamar sen opcións e configurarse en modo interactivo.
    O script xera chaves en keys/ e certificados en crts/.
  4. Crear táboa SRK e táboa hash SRK:
    $ linux64/bin/srktool -a -s sha512 -d sha256 -t SRK_1_2_3_4_táboa.bin \
    -e SRK_1_2_3_4_fusible.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. Escribe a táboa hash de SRK nos fusibles:
    ATENCIÓN: Este paso só é posible unha vez e é irreversible. Os seguintes valores son só exemplos.amples e deben ser substituídos polos teus propios valores.
    • Mostrar hashes:
      $ hexdump -e '/4 “0x”' -e '/4 “%X””\n”' SRK_1_2_3_4_fuse.bin
      0x00000000
      0x11111111
      0x22222222
      0x33333333
      0x44444444
      0x55555555
      0x66666666
      0x77777777
    • Escribir hashes en fusibles (TQMa93xx U-Boot):
      => fusible prog 16 0 0x00000000
      => fusible prog 16 1 0x11111111
      => fusible prog 16 2 0x22222222
      => fusible prog 16 3 0x33333333
      => fusible prog 16 4 0x44444444
      => fusible prog 16 5 0x55555555
      => fusible prog 16 6 0x66666666
      => fusible prog 16 7 0x77777777

 Creando unha secuencia de arranque asinada

 U-Boot Proper e ATF

  1. Copia o requirido files (asúmese que a compilación dunha imaxe TQ foi correcta, véxase máis arriba, ou que as fontes de U-Boot se realizaron):
    • Firmware de confianza de ARM: ${DEPLOY_DIR_IMAGE}/bl31-imx93.bin, renomear a bl31.bin
    • Bota en U propiamente dita:
      ${DEPLOY_DIR_IMAGE}/u-boot.bin
      Isto file é unha ligazón, polo que a copias con cp –dereference ou mostra e copias o orixinal file con ls –long
      or
      de fontes de U-Boot autocompiladas
      Estes fileOs ficheiros s deben copiarse a imx-mkimage/iMX9/. imx-mkimage pódese obter do repositorio de Github mencionado anteriormente; non é necesario ningún tipo de instalación.
  2. Construír o contedor con U-Boot Proper e ATF (executar no cartafol imx-mkimage):
    $ make SOC=iMX9 REV=A1 u-boot-atf-container.img include autobuild.mak
    • …
    • CST: CONTENEDOR 0 desprazamento: 0x0
    • CST: CONTENEDOR 0: Bloque de sinatura: o desprazamento está en 0x110
    • Desprazamentos = 0x0 0x110
    • FEITO.
    • Nota: Copie a imaxe ao desprazamento: IVT_OFFSET + IMAGE_OFFSET
      ATENCIÓN: Os desprazamentos para o contedor e o bloque de sinatura son necesarios no seguinte paso.
    • O artefacto imx-mkimage/iMX9/u-boot-atf-container.img debe copiarse ao cartafol CST descomprimido no paso “3.1 Xeración de claves”.
  3. Transferir o desprazamento do contedor e o bloque de sinatura á secuencia de comandos File (LCR):
    • [Encabezado]
    • Obxectivo = AHAB
    • Versión = 1.0
    • [Instalar SRK]
    • File = “SRK_1_2_3_4_táboa.bin”
    • Source = “crts/SRK1_sha512_secp521r1_v3_usr_crt.pem”
    • Índice de orixe = 0
    • Conxunto de orixe = OEM
    • Revogacións = 0x0
    • [Autenticar datos]
    • File = “u-boot-atf-container.img”
    • Desprazamentos = 0x0 0x110
    • LCR baseado en: https://github.com/nxp-imx/uboot-imx/blob/lf_v2024.04/doc/imx/ahab/csf_examples/csf_uboot_atf.txt
    • O CSF tamén se almacena no cartafol CST co nome csf_uboot_atf.txt que se descomprimiu no paso “3.1 Xeración de claves”.
  4. Contedor de sinatura (ruta relativa ao cartafol CST):
    $ linux64/bin/cst -i csf_uboot_atf.txt -o signed-u-boot-atf-container.img O contedor asinado debe copiarse de volta a imx-mkimage/iMX9/u-boot-atf-container.img. Teña en conta o cambio de nome a u-boot-atf-container.img.

 Arranque completo

  1. Copia o requirido files (asúmese que se compila correctamente unha imaxe TQ, véxase arriba, ou das fontes de U-Boot):
    • Firmware de Edgelock Secure Enclave: ${DEPLOY_DIR_IMAGE}/mx93a1-ahab-container.img
    • Firmware da RAM: ${DEPLOY_DIR_IMAGE}/lpddr4*.bin
    • U-Boot SPL:
      ${DEPLOY_DIR_IMAGE}/u-boot-spl.bin
      Isto file é unha ligazón, polo que a copias con cp –dereference ou mostra e copias o orixinal file con ls –long
      or
      de fontes de U-Boot autocompiladas
    • Contenedor asinado con U-Boot Proper e ATF do paso "3.2.1 U-Boot Proper e ATF"
      Estes fileOs ficheiros s tamén deben copiarse a imx-mkimage/iMX9/.
  2. Crear o fluxo de arranque
    • $ make -j8 SOC=iMX9 REV=A1 flash_singleboot
      incluír autobuild.mak
    • …
    • CST: CONTENEDOR 0 desprazamento: 0x400
    • CST: CONTENEDOR 0: Bloque de sinatura: o desprazamento está en 0x490
    • Desprazamentos = 0x400 0x490
    • FEITO.
    • NotaCopia a imaxe ao desprazamento: IVT_OFFSET + IMAGE_OFFSET engade u-boot-atf-container.img a 379 KB, psize=1024
    • 1145+0 rexistros
    • 1145+0 rexistros fóra
    • 1172480 bytes (1.2 MB, 1.1 MiB) copiados, 0.00266906 s, 439 MB/s
    • ATENCIÓN: Os desprazamentos para o contedor e o bloque de sinatura son necesarios no seguinte paso.
      O artefacto imx-mkimage/iMX9/flash.bin debe copiarse ao cartafol CST descomprimido no paso “3.1 Xeración de claves”.
  3. Transferir o desprazamento do contedor e o bloque de sinatura á secuencia de comandos File (LCR):
    • [Encabezado]
    • Obxectivo = AHAB
    • Versión = 1.0
    • [Instalar SRK]
    • File = “SRK_1_2_3_4_táboa.bin”
    • Source = “crts/SRK1_sha512_secp521r1_v3_usr_crt.pem”
    • Índice de orixe = 0
    • Conxunto de orixe = OEM
    • Revogacións = 0x0
    • [Autenticar datos]
    • File = “flash.bin”
    • Desprazamentos = 0x400 0x490
    • LCR baseado en: https://github.com/nxp-imx/uboot-imx/blob/lf_v2024.04/doc/imx/ahab/csf_examples/csf_boot_image.txt
    • O CSF almacénase no cartafol CST co nome csf_boot_image.txt descomprimido no paso “3.1 Xeración de claves”.
  4. Asinar o fluxo de arranque
    • linux64/bin/cst -i imaxe_de_arranque_csf.txt -o flash-asinado.bin

Os pasos para substituír o fluxo de arranque pódense atopar na capa BSP (https://github.com/tq-systems/meta-tq) en meta-tq/doc.

Verificación
Para comprobar se o fluxo de arranque asinado é válido, use o comando ahab_status en U-Boot:

  • => estado_de_ahab
  • Ciclo de vida: 0x00000008, OEM aberto
  • Non se atoparon eventos!
  • Se se atopa un evento, o fluxo de arranque non é válido e non se podería arrincar nun dispositivo bloqueado.

Para a falsificación, pódese iniciar un fluxo de arranque sen asinar e despois pódese chamar a ahab_status:

  • => estado_de_ahab
  • Ciclo de vida: 0x00000008, OEM aberto
  • 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)

 Bloquear o dispositivo

ATENCIÓN: Este paso é irreversible e só se debe levar a cabo se é necesario. Se a configuración é incorrecta, este paso resultará nun dispositivo inutilizable.

O dispositivo pódese bloquear no U-Boot co comando ahab_close. Isto significa que só se arrincarán os fluxos de arranque válidos verificados pola ROM de arranque. O seguinte estado móstrase despois de reiniciar:

  • => estado_de_ahab
  • Ciclo de vida: 0x00000020, OEM pechado
  • Non se atoparon eventos!

Imaxe FIT

ATENCIÓN: A información da ruta é relativa a un cartafol novo e baleiro, por exemplo
fit_image_work, ou as fontes do núcleo, se for autocompilada. De agora en diante, denominarase directorio de traballo.

Xeración dun par de claves
Úsase un par de claves asimétricas para asinar a imaxe FIT. Este par pódese xerar 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

Crear fonte de árbore de imaxes

  • Crea a fonte da árbore de imaxes sign.its para a imaxe FIT.
  • /dts-v1/;
  • / {
  • descrición = "Imaxe de axuste do núcleo para TQMa93xx";
  • #celas-de-enderezo = <1>;
  • imaxes {
  • núcleo-1 {
  • descrición = "núcleo de Linux";
  • datos = /incbin/("Imaxe");
  • tipo = "núcleo";
  • arco = “brazo64”;
  • sistema operativo = “linux”;
  • compresión = "gzip";
  • carga = <0x90000000>;
  • entrada = <0x90000000>;
  • hash-1 {
  • algo = “sha256”;
  • };
  • };
  • fdt-1 {
  • descrición = "Blob da árbore de dispositivos aplanado";
  • datos = /incbin/(“ ");
  • tipo = “plano_dt”;
  • arco = “brazo64”;
  • compresión = "ningunha";
  • carga = <0x97000000>;
  • hash-1 {
  • algo = “sha256”;
  • };
  • };
  • };
  • configuracións {
  • predeterminado = “conf-1”;
  • conf-1 {
  • descrición = "kernel de Linux, blob FDT";
  • núcleo = “núcleo-1”;
  • fdt = “fdt-1”;
  • hash-1 {
  • algo = “sha256”;
  • };
  • sinatura-1 {
  • algo = “sha256,rsa2048”;
  • pista-nome-clave = “dev”;
  • recheo = “pkcs-1.5”;
  • imaxes-de-signos = “kernel”, “fdt”;
  • };
  • };
  • };
  • };

 Creando unha imaxe FIT asinada

Nota: O binario de DeviceTree para U-Boot é necesario para este paso. Os binarios de DeviceTree xa feitos pódense atopar no espazo de traballo de Yocto, no directorio de compilación de U-Boot. A ruta ao directorio de compilación pódese mostrar con bitbake virtual/bootloader –e | grep ^B=.

  1. Copia o requirido files no directorio de traballo:
    • Cambia o nome da árbore de dispositivos U-Boot imx93-tqma9352-mba91xxca.dtb, imx93-tqma9352-mba93xxca.dtb ou imx93-tqma9352-mba93xxla.dtb, en pubkey.dtb:
      Desde o directorio de compilación de U-Boot no espazo de traballo de Yocto (ruta: bitbake virtual/bootloader –e | grep ^B=)
      or
      de fontes de U-Boot autocompiladas
    • Núcleo de Linux:
      ${DEPLOY_DIR_IMAGE}/Imaxe
      Isto file é unha ligazón, polo que a copias con cp –dereference ou mostra e copias o orixinal file con ls –long
      or
      de fontes de Linux autocompiladas
    • Árbore de dispositivos de Linux:
      Dependendo da variante ${DEPLOY_DIR_IMAGE}/imx93-tqma93…
      Isto file é unha ligazón, polo que a copias con cp –dereference ou mostra e copias o orixinal file con ls –long
      or
      de fontes de Linux autocompiladas
    • As claves xeradas no paso 4.1
    • Os ITS file xerado no paso 4.2
  2. Crear imaxe FIT con sinatura
    $ mkimage -f asinar.its -K clave_pub.dtb -k . -r imaxe.itb
    A chave pública escríbese na árbore de dispositivos do U-Boot. Esta chave úsase para verificar a imaxe FIT asinada arriba.

ATENCIÓN: Para empaquetar a árbore de dispositivos U-Boot coa clave pública no fluxo de arranque asinado do capítulo 3.2, débense repetir os pasos do capítulo 3.2 cun ficheiro u-boot.bin U-Boot Proper personalizado. Para iso, débese especificar a árbore de dispositivos coa clave pública pubkey.dtb mediante a opción EXT_DTB ao compilar o U-Boot:
facer EXT_DTB=

Verificación
En U-Boot con claves públicas, a imaxe FIT asinada image.itb pódese arrincar con bootm despois de cargala desde un medio axeitado (TFTP, eMMC, SD).
Ao arrincar a imaxe FIT, U-Boot devolve a información Verificando a integridade do hash... sha256,rsa2048:dev+ Aceptar co nome, o algoritmo e a lonxitude da clave xerada no capítulo 4.1 na consola:

  • ## Cargando o núcleo desde a imaxe FIT en 80400000 …
    …
  • Verificación da integridade do hash... sha256,rsa2048:dev+ Aceptar
    …
  • ## Cargando o disco RAM desde a imaxe FIT en 80400000 …
    …
  • Verificación da integridade do hash... sha256,rsa2048:dev+ Aceptar
    …
  • ## Cargando fdt desde a imaxe FIT en 80400000 …
    …
  • Verificación da integridade do hash... sha256,rsa2048:dev+ Aceptar
    …

Para a falsificación, pódese xerar outro par de claves como se describe na sección 4.1 e usalo para asinar a imaxe FIT. Esta imaxe FIT non se pode arrincar sen intercambiar a clave no U-Boot Devicetree:
## Cargando o núcleo desde a imaxe FIT en 80400000 …

Usando a configuración 'conf-1'
Verificación da integridade do hash... sha256,rsa2048:proba- erro!
Fallou a verificación para ' ' nodo hash no nodo de configuración 'conf-1'
Non se puido verificar a sinatura requirida 'key-dev'
Hash de datos incorrectos
ERRO: non se pode obter a imaxe do núcleo!

Ampliar a cadea de confianza: partición raíz
A cadea de confianza establecida previamente verifica a orixe do kernel de U-Boot e Linux. Cos mecanismos mencionados anteriormente, só o propietario da clave privada xerada pode asinar o seu software e arrincalo no dispositivo. Pódense engadir máis ligazóns á cadea. A seguinte sección describe como se pode protexer a partición raíz contra a manipulación usando dm-verity. Para a implementación real, tamén se mostra como se pode crear a cadea completa co TQ-BSP. Omítese unha guía paso a paso para a protección con dm-verity debido á complexidade dos requisitos.

 Esbozo: Mapeador de dispositivos Verity

  1. Xerar hashes de Verity:
    veritysetup calcula os valores hash e os almacena ao final da partición raíz. A partición raíz pode ser real file ou un dispositivo de bloqueo file (por exemplo, /dev/sdaX).
    • configuración de verdade \
    • –tamaño-do-bloque-de-datos=1024 \
    • –tamaño-do-bloque-hash=4096 \
    • –compensación-hash= \
    • formato \
    • \
    • veritysetup arroxa a seguinte información (con valores correspondentemente diferentes):
    • Información de cabeceira VERITY para data.img
    • UUID: e06ff4cb-6b56-4ad4-bd97-0104505a70a5
    • Tipo de hash: 1
    • Bloques de datos: 204800
    • Tamaño do bloque de datos: 1024
    • Tamaño do bloque hash: 4096
    • Algoritmo hash: sha256
    • Salt: 17328c48990b76fbb3e05d0ebfd236043674cf0d14c278bc875b42693621cc21
    • Root hash: a0e1a449d452f74d041706b955794c0041e3d8ad051068df6589e08485323698
    • O hash raíz é o valor sensible que precisa ser protexido. Se este hash se ve comprometido, por exemplo, se pode ser modificado por unha persoa non autorizada, entón a protección da integridade da partición raíz por dm-verity non ten ningún valor.
  2. Integrar o hash raíz na cadea de confianza
    • O hash raíz xerado anteriormente almacénase na imaxe FIT asinada, o que a protexe contra a manipulación. Para este propósito, engádese un initramfs á imaxe FIT no que o hash raíz se almacena nun file.
    • O nodo de imaxes do ITS file do capítulo 4.2 amplíase, entre outras, coa seguinte sección:
    • disco RAM-1 {
    • descrición = “dm-verity-image-initramfs”;
    • datos = /incbin/(“ ");
    • tipo = "discoRAM";
    • arco = “brazo64”;
    • sistema operativo = “linux”;
    • compresión = "ningunha";
    • carga = <0x98000000>;
    • entrada = <0x98000000>;
    • hash-1 {
    • algo = “sha256”;
    • };
    • };
  3. Comprobar a integridade da partición raíz
    • O ficheiro initramfs contén un script axeitado que xera un mapeador de dispositivos a partir da partición raíz e do hash raíz.
    • configuración de verdade \
    • –tamaño-do-bloque-de-datos=${TAMAÑO_DO_BLOQUE_DE_DATOS} \
    • –hash-offset=${TAMAÑO_DOS_DATOS} \
    • crear rootfs \
    • \
    • \

O mapeador de dispositivos móntase entón:

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

A raíz fileo sistema é de só lectura. Para cambiar á raíz real filesistema, use switch-root.

Creación automatizada con TQ-BSP
En principio, unha imaxe cunha cadea de confianza desde o cargador de arranque ata a partición raíz pódese crear automaticamente co TQ-BSP.
Para TQMa93xx débense engadir as seguintes opcións a local.conf:

  • # As opcións de configuración necesarias para DISTRO_FEATURE son seguras para U-Boot e Kernel
  • CARACTERÍSTICAS_DE_DISTRIBUCIÓN: engadir = "seguro"
  • # Nome da chave usada para asinar o cargador de arranque
  • NOME_CHAVE_IMX_HAB = “ahab”
  • # Activa a sinatura da imaxe FIT no proceso de compilación
  • UBOOT_SIGN_ENABLE = “1”
  • # Esta clase contén a lóxica para crear unha partición raíz protexida
  • CLASES_DE_IMAXE += “dm-verity-img”
  • # Nome da imaxe initramfs para a xestión de dm-verity
  • IMAXE_INITRAMFS = “dm-verity-image-initramfs”
  • # Initramfs almacénase como un artefacto separado na imaxe
  • PAQUETE_DE_IMAXES_INITRAMFS = “0”
  • # Garda a imaxe FIT con initramfs na partición de arranque
  • IMAXE_INICIO_FILES:append = ” fitImage-${INITRAMFS_IMAGE}-${MACHINE}-
  • ${MÁQUINA};fitImage” # Imaxe a protexer con dm-verity
  • # Alternativa: tq-image-weston-debug
  • DM_VERITY_IMAGE = “tq-image-xenérico-debug”
  • # Tipo da imaxe de arriba
  • TIPO_DE_IMAXE_DA_VERDADE_DM = “ext4”

ATENCIÓN: As opcións exactas poden cambiar en versións futuras do BSP. A información máis recente pódese atopar na documentación da capa BSP (https://github.com/tq-systems/meta-tq) en meta-tq/doc.

A imaxe completa créase con bitbake tq-image-generic-debug e despois pódese escribir nunha tarxeta SD, por exemploample.

Verificación
En Linux, pódese usar mount -a para comprobar se o Verity Devicemapper está montado como root. filesistema:

  • # montaxe
  • …
  • /dev/mapper/rootfs activado / tipo ext4 (ro,temporelativo)
  • …
  • Ademais, toda a raíz file o sistema é de só lectura neste caso:
  • # proba táctil
  • toque: non se pode tocar 'proba': Só lectura file sistema

Para a falsificación, a raíz file O sistema pódese modificar sen conexión e o dispositivo reiniciarse. A modificación provoca un hash de raíz diferente e o proceso de arranque abortase: device-mapper: verity: 179:98: o bloque de datos 1 está corrompido

Podes atopar máis información sobre o TQMa93xx na Wiki de soporte de TQ: 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

Preguntas frecuentes

P: É posible reverter o proceso irreversible de configuración dos fusibles mencionado no manual?
R: Non, configurar fusibles é irreversible. Recoméndase usar un patrón de desenvolvemento.

P: Onde podo atopar os códigos fonte necesarios para Linux e U-Boot?

R: Linux:
Repositorio de Linux
U-Boot: U-Boot
Repositorio

Documentos/Recursos

Arranque seguro TQ TQMa93 [pdfGuía do usuario
TQMa93xx, Arranque seguro TQMa93, Arranque seguro, Arranque

Referencias

Deixa un comentario

O teu enderezo de correo electrónico non será publicado. Os campos obrigatorios están marcados *