Pular para o conteúdo principal

Criar BSP DIY do Orin Nano DevKit para reComputer Classic / Super

Este guia mostra como clonar um ambiente de desenvolvimento completo de um NVIDIA Jetson Orin Nano Developer Kit, substituir o firmware da placa pelo da Seeed reComputer, construir um BSP Híbrido e concluir o flash.

São suportadas duas placas de destino:

  • reComputer Classic (J4011/J4012, configuração de placa recomputer-orin-j401)
  • reComputer Super (configuração de placa recomputer-orin-super-j401)

Ambas compartilham a mesma ideia central — manter o APP completo do DevKit, regenerar o QSPI da placa de destino — mas diferem em detalhes de pinmux, overlay de câmera e layout de disco. As diferenças são apresentadas nas abas abaixo; as etapas comuns são escritas uma vez só.

Este fluxo foi validado com JetPack 6.2 / L4T 36.4.3, Orin Nano 8GB (SKU 0005).

Documentos relacionados:

O que você está construindo​

ObjetivoArtefatoFinalidade
A. Clone no mesmo carriermfi_jetson-orin-nano-devkit-nvme.tar.gzRegravar o DevKit com um clone completo do ambiente
B. Pacote de destinomfi_recomputer-orin-j401.tar.gz (Classic)
mfi_recomputer-orin-super-j401.tar.gz (Super)		Gravar a placa de destino: QSPI em nível de placa de destino + APP completo do DevKit (incluindo /home)
C. Retorno seguroBSP oficial + migrar apenas /homeUsar quando os resultados do Híbrido forem anormais
perigo

Não grave o pacote do DevKit mfi_jetson-orin-nano-devkit-nvme diretamente na placa de destino.

Não considere editar um único .dtb dentro do diretório mfi como adaptação de placa.

Não grave um pacote Híbrido Classic em uma Super, ou vice-versa — seus pinmux e overlays de câmera são diferentes.

Pré-requisitos​

Hardware​

  • Origem: Orin Nano Developer Kit (este exemplo usa o módulo SKU 0005 = Orin Nano 8GB, boot por NVMe)
  • Destino: Seeed reComputer Classic J4011/J4012 ou reComputer Super (idealmente o módulo também deve ser 0005)
  • Host: Ubuntu 22.04 x86_64, cabo USB Type-C (porta de flash)
  • Disco: reservar ≥ 100GB de espaço livre (backup + mfi duplo + snapshots)
perigo

A série reComputer Classic não possui refrigeração suficiente para suportar o modo MAXN Super. Se você gravar o JetPack 6.2 em um dispositivo Classic, não ative o MAXN.

Dependências no host​

sudo apt-get update -y
sudo apt-get install -y \
  build-essential flex bison libssl-dev \
  sshpass abootimg nfs-kernel-server \
  libxml2-utils qemu-user-static

Antes do backup/flash:

sudo systemctl stop udisks2.service
sudo service nfs-kernel-server start
lsusb | grep 0955:7523   # must show NVIDIA Corp. APX

Comparação das placas​

ItemDevKitreComputer ClassicreComputer Super
board-namejetson-orin-nano-devkit-nvmerecomputer-orin-j401recomputer-orin-super-j401
Arquivo de configuraçãop3768-0000-p3767-0000-a0-nvme.confrecomputer-orin-j401.confrecomputer-orin-super-j401.conf
PinmuxNVIDIA DevKit (DP)Classic HDMISuper HDMI
Overlay de câmeraNVIDIA dinâmicoSeeed IMX219 duploSeeed IMX219 quádruplo
DTB principal do SKU0005...-0005-nv(-super).dtbAinda usa tegra234-p3768-0000+p3767-0005-nv-super.dtb
mfi finalApenas DevKitApenas ClassicApenas Super

Exemplo de board_spec de backup:

3767-300-0005-V.2-1-1-jetson-orin-nano-devkit-nvme-

1. Preparar o workspace Linux_for_Tegra​

Baixe o pacote de trabalho L4T da Seeed a partir da tabela em Criar um pacote BSP personalizado a partir do ambiente de desenvolvimento Jetson (JetPack 6.2 / L4T 36.4.3 plus neste exemplo).

sudo tar xpf L4T_36.4.3_plus.tar.gz
# Adjust the archive name to match your download

cd Linux_for_Tegra/
sudo ./apply_binaries.sh
cd ..

export ARCH=arm64
export CROSS_COMPILE="$PWD/aarch64--glibc--stable-2022.08-1/bin/aarch64-buildroot-linux-gnu-"
export PATH="$PWD/aarch64--glibc--stable-2022.08-1/bin:$PATH"
export INSTALL_MOD_PATH="$PWD/Linux_for_Tegra/rootfs/"

cd Linux_for_Tegra/source
./nvbuild.sh
./do_copy.sh
./nvbuild.sh -i

Verificação:

test -f Linux_for_Tegra/recomputer-orin-j401.conf
test -f Linux_for_Tegra/jetson-orin-nano-devkit-nvme.conf
ls Linux_for_Tegra/kernel/dtb/tegra234-j401-*-recomputer.dtb
ls Linux_for_Tegra/kernel/dtb/tegra234-dcb-p3767-0000-hdmi.dtbo

2. Fazer backup do ambiente completo do DevKit​

2.1 Colocar o dispositivo de origem em modo Recovery​

Conecte a porta de flash do DevKit ao host com um cabo de dados USB Type-C e entre no modo Recovery. No host, lsusb deve mostrar 0955:7523 APX.

Para as etapas do modo Recovery, consulte: Gravar o JetPack em um produto selecionado

Durante o backup o dispositivo pode alternar brevemente para 0955:7035 (Linux for Tegra / initrd). Isso é normal.

2.2 Comando de backup​

cd Linux_for_Tegra
sudo ./tools/backup_restore/l4t_backup_restore.sh \
  -e nvme0n1 -b -c jetson-orin-nano-devkit-nvme
atenção

Não use o nome da placa de destino para o primeiro backup quando a origem for um DevKit. Isso irá corromper o board_spec e as bases posteriores.

2.3 Verificação​

ls -lah tools/backup_restore/images/
head -5 tools/backup_restore/images/nvpartitionmap.txt

Você deve ver:

  • board_spec contém jetson-orin-nano-devkit-nvme
  • nvme0n1p1.tar.zst (ou o APP grande convertido posteriormente) tem escala de GB
  • QSPI0.img existe (este é o QSPI do DevKit; o Híbrido não deve reutilizá-lo como QSPI da placa de destino)

Recomendado: criar snapshot imediatamente:

sudo cp -a tools/backup_restore/images ~/backup_images_dk_sku0005

3. Construir o BSP DIY de mesmo carrier do DevKit (Opcional)​

Coloque o dispositivo novamente em APX. No host, lsusb deve mostrar 0955:7523 APX:

cd Linux_for_Tegra
sudo ./tools/kernel_flash/l4t_initrd_flash.sh \
  --use-backup-image --no-flash --network usb0 --massflash 5 \
  jetson-orin-nano-devkit-nvme internal

Artefatos:

  • mfi_jetson-orin-nano-devkit-nvme/
  • mfi_jetson-orin-nano-devkit-nvme.tar.gz
perigo

Apenas para regravação do DevKit. Não grave a placa de destino com este pacote.

Seu APP pode ser usado como fonte de dados para o pacote Híbrido, mas seu QSPI não pode ser reutilizado.

4. Leitura obrigatória: a armadilha do QSPI​

Com --use-backup-image, convert_backup_image_to_initrd_flash coloca:

Conteúdo do backupDestino
NVMe / APPtools/kernel_flash/images/external/
QSPI0.img da origemtools/kernel_flash/images/internal/

Portanto:

Abordagem incorretaResultado
Editar apenas mfi/.../rootfs ou um .dtbIneficaz (o que realmente é gravado é o bak / QSPI)
Backup do DevKit, depois trocar diretamente o nome da placa de destino + --use-backup-imageAinda grava o QSPI do DevKit (pinmux DP); HDMI/USB podem ficar incorretos
Alterar o conf, depois --flash-only--flash-only não reconstrói as imagens a partir do conf

O que realmente difere na placa de destino é o pinmux do HDMI + overlay DCB/câmera no conf da placa:

Conteúdos principais de recomputer-orin-j401.conf:

PINMUX_CONFIG="tegra234-mb1-bct-pinmux-p3767-hdmi-a03.dtsi"
PMC_CONFIG="tegra234-mb1-bct-padvoltage-p3767-hdmi-a03.dtsi"
OVERLAY_DTB_FILE+=",tegra234-dcb-p3767-0000-hdmi.dtbo,tegra234-p3767-camera-p3768-imx219-dual-seeed.dtbo"
DCE_OVERLAY_DTB_FILE="tegra234-dcb-p3767-0000-hdmi.dtbo"

Para o SKU 0005, o nome principal do DTB ainda é o *-0005-nv-super.dtb da NVIDIA. Não force a troca para *-0000-recomputer.dtb (esse caminho é para o NX 16GB).

5. BSP Híbrido: Construir o Pacote de Destino​

Ideia principal:

  1. APP: continuar usando o backup do DevKit (ambiente completo do usuário)
  2. QSPI: regenerar com a configuração da placa de destino (sem --use-backup-image)
  3. Montar no mfi da placa de destino
DevKit backup APP  ──►  external/ (nvme0n1p1_bak.img, etc.)
Target conf new QSPI ──►  internal/ (QSPI shards, not DevKit monolithic QSPI0.img)
                     └──► mfi_recomputer-orin-<target>(.tar.gz)

5.1 Preparar somente APP (Remover QSPI do DevKit)​

cd Linux_for_Tegra
sudo cp -a ~/backup_images_dk_sku0005 \
  tools/backup_restore/images_app_only
sudo rm -f tools/backup_restore/images_app_only/QSPI0.img
sudo sed -i '/qspi/Id' tools/backup_restore/images_app_only/nvpartitionmap.txt

Converter somente APP em imagens external de flash initrd (use a etapa de conversão da ferramenta de backup ou reutilize o grande APP já em tools/kernel_flash/images/external/ da etapa de empacotamento do mfi do DevKit).

5.2 Gerar QSPI da Placa de Destino​

O dispositivo deve estar em APX. Os parâmetros do módulo devem corresponder ao backup (neste exemplo: 3767 / 0005 / 300 / V.2):

cd Linux_for_Tegra
sudo BOARDID=3767 BOARDSKU=0005 FAB=300 BOARDREV=V.2 CHIP_SKU=00:00:00:D5 \
  ./tools/kernel_flash/l4t_initrd_flash.sh \
  --external-device nvme0n1p1 \
  -c tools/kernel_flash/flash_l4t_t234_nvme.xml \
  -p "-c bootloader/generic/cfg/flash_t234_qspi.xml --no-systemimg" \
  --no-flash --massflash 5 --showlogs --network usb0 \
  recomputer-orin-j401 internal

Os logs devem mostrar o pinmux HDMI, por exemplo tegra234-mb1-bct-pinmux-p3767-hdmi-a03.

Recomendado: salvar o novo QSPI internal:

sudo cp -a tools/kernel_flash/images/internal ~/j401_qspi_internal_save
info

O QSPI internal (SKU 0005 / L4T 36.4.3) gerado neste guia está disponível para download direto:

wget -O j401_qspi_internal_save.tar.gz \
  https://files.seeedstudio.com/wiki/reComputer-Jetson/FAQ/dk-to-classic/j401_qspi_internal_save.tar.gz
mkdir -p Linux_for_Tegra/tools/kernel_flash/images/internal
tar xpf j401_qspi_internal_save.tar.gz -C Linux_for_Tegra/tools/kernel_flash/images/internal/

Coloque os arquivos baixados em Linux_for_Tegra/tools/kernel_flash/images/internal/ para pular a etapa de geração do QSPI acima.

Pré-requisitos de reutilização: a placa de destino é reComputer Classic J4011/J4012, módulo SKU 0005, L4T 36.4.3. Se qualquer condição não corresponder, regenere o QSPI conforme esta seção.

5.3 Montar o mfi​

O diretório final deve satisfazer:

CaminhoConteúdo
mfi_recomputer-orin-j401/recomputer-orin-j401.confPresente
.../tools/kernel_flash/images/internal/Novo QSPI J401 (sem QSPI0.img monolítico do DevKit, ou hash diferente do DevKit; flash.idx costuma ser fragmentado em várias linhas)
.../tools/kernel_flash/images/external/nvme0n1p1_bak.imgAPP em escala de GB

Arquivo opcional:

cd Linux_for_Tegra
sudo tar czf mfi_recomputer-orin-j401.tar.gz mfi_recomputer-orin-j401

6. Gravar na Placa de Destino​

6.1 Colocar a Placa de Destino em APX​

lsusb → 0955:7523 NVIDIA Corp. APX

6.2 Comando de Gravação​

Se o diretório extraído já existir localmente, não execute tar xpf novamente:

cd Linux_for_Tegra/mfi_recomputer-orin-j401
sudo ./tools/kernel_flash/l4t_initrd_flash.sh \
  --flash-only --massflash 1 --network usb0 --showlogs

Somente quando outro PC tiver apenas o .tar.gz:

sudo tar xpf mfi_recomputer-orin-j401.tar.gz
cd mfi_recomputer-orin-j401
sudo ./tools/kernel_flash/l4t_initrd_flash.sh \
  --flash-only --massflash 1 --network usb0 --showlogs
atenção

Se /mnt/external/...: Permission denied aparecer ao gravar recovery ou APP, isso é um problema de permissão NFS — veja a Nota Técnica B.

6.3 Mensagens Normais Durante a Gravação​

LogSignificado
p3768-0000-p3767-0000-a0.conf: No such file or directoryComum com --flash-only; as imagens já estão pré-compiladas, continue
rpcbind already runningSeguro ignorar
blockdev: cannot open /dev/mmcblk0boot0O Orin Nano não possui essa partição; geralmente inofensivo
RCM-boot + SSH readyEntrada normal de gravação
DTB ...-0005-nv-super.dtbCorreto para SKU0005
Várias linhas internal + Starting to flash to qspiGravando o QSPI da placa de destino
tar ... zstd ... nvme0n1p1_bak.imgRestaurando APP (etapa mais longa; pode levar dezenas de minutos)
Successfully flash the qspiGravação do QSPI concluída
Successfully flash the external deviceGravação do dispositivo externo concluída
Flashing success / Flash is successfulGravação bem-sucedida
atenção

Não desligue a alimentação nem desconecte até ver uma mensagem de conclusão bem-sucedida.

7. Verificações pós-gravação​

Solte o botão ou jumper de Recovery e faça um power cycle após uma gravação bem-sucedida. Se lsusb ainda relatar 0955:7523 APX, o dispositivo permanece em Recovery e não inicializou o Linux.

Após uma inicialização normal, execute:

cat /proc/device-tree/model
ls /boot/kernel_tegra234*.dtb
ls /boot/*.dtbo | grep -E 'hdmi|imx219' || true

# Whether peripherals actually work (more important than model / dtbo filenames)
xrandr 2>/dev/null | head -20
lsusb | head
ip -br link
ls /boot/*.dtbo 2>/dev/null | head -40
sudo dmesg | grep -iE 'dtb|overlay|hdmi|tegra234' | tail -30

# Whether the original DevKit user environment survived (CUDA example)
nvcc --version
info

Sem sudo, dmesg pode relatar Operation not permitted. Isso é um problema de permissões; use sudo.

Como interpretar os resultados (SKU 0005)​

1) /proc/device-tree/model ainda mostra DevKit — normal para SKU 0005

Exemplo:

NVIDIA Jetson Orin Nano Engineering Reference Developer Kit Super

Motivo: a configuração de placa de destino para SKU 0005 seleciona o tegra234-p3768-0000+p3767-0005-nv-super.dtb da NVIDIA. Ela não alterna para tegra234-j401-*-recomputer.dtb, então a string de modelo ainda parece o DevKit oficial. Não conclua “gravei o bundle de DevKit errado” apenas com base nesta linha.

2) Nomes de arquivo DTB em /boot

Comumente visíveis:

/boot/kernel_tegra234-p3768-0000+p3767-0000-nv.dtb
/boot/kernel_tegra234-p3768-0000+p3767-0005-nv.dtb

Você pode não ver um nome de arquivo *-0005-nv-super.dtb; o DTB real de boot é frequentemente escolhido por UEFI/QSPI. A listagem de /boot é apenas de referência.

3) grep hdmi|imx219 vazio — não é falha por si só

Após a gravação Hybrid, /boot/*.dtbo frequentemente ainda contém a lista genérica de overlays do backup do DevKit. Você pode não ver tegra234-dcb-p3767-0000-hdmi.dtbo ou overlays de câmera da Seeed. As configurações de HDMI/câmera da Seeed em sua maioria entram em vigor através do caminho de novo overlay de QSPI / UEFI da placa de destino.

4) Julgue por “está funcionando?”

VerificaçãoExemplo saudável
USBHubs, mouse, Bluetooth, Ethernet USB enumerados (lsusb mostra vários dispositivos)
Ethernet com fioClassic: enP8p1s0 etc. estão UP; Super: veja Tech Note C
Wi‑FiwlP1p1s0 está UP
DisplayDesktop funciona; ou xrandr tem saída
Ambiente do usuárioUsuários, software e dados originais do DevKit permanecem
CUDAnvcc --version funciona (neste exemplo 12.6), indicando que o clone do APP está intacto

Classic deve focar em validar a configuração de câmera dupla (imx219-dual-seeed).

No dispositivo: modelo / DTB

No dispositivo: CUDA instalada no DevKit original ainda funciona

Quando editar extlinux.conf​

Somente se HDMI / USB / boot estiver anormal, tente adicionar sob LABEL primary em /boot/extlinux/extlinux.conf:

FDT /boot/kernel_tegra234-p3768-0000+p3767-0005-nv-super.dtb

(Se esse arquivo estiver ausente em /boot, tente ...-0005-nv.dtb, ou copie primeiro de kernel/dtb/ do BSP.)

sudo reboot

Se ainda estiver anormal, use o fallback da Seção 8.

8. Fallback (caminho oficial)​

Se a gravação Hybrid deixar partições/UEFI/periféricos anormais:

  1. Grave o BSP de placa de destino oficial conforme o fluxo da Seeed (não grave o mfi do DevKit).
  2. Extraia /home do backup (nvme0n1p1.tar.zst) ou siga Migrar dados de /home do Jetson Orin Nano Developer Kit para reComputer.
  3. Restaure /home na placa de destino e reinstale o software em nível de sistema conforme necessário (/usr, /etc, Docker, etc. precisam de tratamento separado).

Prós: firmware de placa mais limpo. Contras: não é um clone completo do disco /.

9. Referência rápida de caminhos principais​

TipoCaminho (sob Linux_for_Tegra/)
DK mfimfi_jetson-orin-nano-devkit-nvme.tar.gz
Classic Bundle mfimfi_recomputer-orin-j401.tar.gz
Super Bundle mfimfi_recomputer-orin-super-j401.tar.gz
Classic confrecomputer-orin-j401.conf
Super confrecomputer-orin-super-j401.conf
HDMI DCBkernel/dtb/tegra234-dcb-p3767-0000-hdmi.dtbo
Classic dual IMX219kernel/dtb/tegra234-p3767-camera-p3768-imx219-dual-seeed.dtbo
Super quad IMX219kernel/dtb/tegra234-p3767-camera-p3768-imx219-quad-seeed.dtbo
J401 DTBkernel/dtb/tegra234-j401-p3768-0000+p3767-*-recomputer.dtb
SKU0005 DTBkernel/dtb/tegra234-p3768-0000+p3767-0005-nv-super.dtb

10. Visão geral do fluxo​

[Host] Extract L4T + apply_binaries + nvbuild
          │
          ▼
[DevKit APX] backup -c jetson-orin-nano-devkit-nvme
          │
          ├─► (optional) --use-backup-image → mfi_jetson-orin-nano-devkit-nvme
          │
          ├─► snapshot backup_images_dk_sku0005
          │         │
          │         ├─ APP-only (remove QSPI)
          │         └─► external APP
          │
          └─► [APX] target board conf → generate QSPI
                    │           │
                    │           ├─ Classic: recomputer-orin-j401 internal
                    │           └─ Super:   recomputer-orin-super-j401-nvme external
                    │
                    ▼
              assemble mfi_recomputer-orin-<target>
                    │
                    ▼
              [target APX] --flash-only
                    │
                    ▼
              check display/USB/NVMe/user environment

11. FAQ​

P: Tanto o diretório quanto o .tar.gz existem — ainda preciso extrair?
R: Não. Se o diretório mfi_recomputer-orin-* existir, faça cd nele e execute --flash-only.

P: O módulo da placa de destino não é 0005?
R: Altere BOARDSKU, escolha o DTB correspondente conforme p3767_super_overlay na configuração da placa de destino e então regenere o QSPI.

P: Quero manter apenas /home, não clonar o disco inteiro?
R: Use o fallback da Seção 8. É mais simples e mais confiável.

P: Posso renomear e gravar o bundle Classic Hybrid em Super?
R: Não. Seus pinmux e overlays de câmera são diferentes. Regenere o QSPI correspondente.

P: Por que não usar --use-backup-image diretamente?
R: Ele também pode reutilizar o QSPI0.img do DevKit. Hybrid deve reutilizar apenas o APP.

P: E se as capacidades das unidades de origem e destino forem diferentes? (Super)
R: Gere a GPT para a unidade de destino e substitua apenas o payload do APP. O APP expandido deve caber na nova partição APP.

P: Por que o exemplo de wiki do BSP DIY usa recomputer-orin-j401?
R: Esse exemplo assume que origem e destino são ambas placas Seeed. Quando a origem é um DevKit oficial, o backup deve primeiro usar jetson-orin-nano-devkit-nvme, depois seguir este tutorial Hybrid para se adaptar à placa de destino.

Notas técnicas​

Tech Note A. Consistência do primeiro boot em Super​

Verifique três requisitos de consistência antes de arquivar:

  1. root=PARTUUID=... em boot.img deve corresponder ao GUID exclusivo da partição APP na GPT externa;
  2. o UUID de /boot/efi no /etc/fstab do APP do DevKit deve corresponder ao UUID FAT do novo esp.img;
  3. se o kernel RT clonado do DevKit travar em lan743x na LAN7430 do Super, pré-instale:
/etc/modprobe.d/blacklist-lan743x-super-hybrid.conf
blacklist lan743x
install lan743x /bin/false

Os dois primeiros desencontros impedem a montagem de root ou levam ao modo de manutenção. Alterar o PARTUUID ativo com sgdisk em um initrd de reparo é uma medida de recuperação, não uma etapa de build reprodutível. Regenere GPT e boot.img juntos e então faça o patch do APP antes de criar o arquivo final.

Tech Note B. NFS Permission Denied​

Se /mnt/external/...: Permission denied aparecer ao gravar recovery ou APP, certifique-se de que o cliente NFS possa atravessar todos os diretórios pai no caminho do mfi.

Por exemplo, se o modo do diretório home do usuário for 750, use temporariamente 751 durante a gravação e restaure-o imediatamente depois:

sudo chmod 751 /home/$USER
# Re-enter APX and flash
sudo chmod 750 /home/$USER

O modo 751 adiciona apenas permissão de travessia; ele não permite que outros usuários listem o diretório. Não use 777.

Tech Note C. Limitação do Ethernet com fio Super lan743x​

O kernel RT clonado do DevKit usado neste teste acionou um Oops de kernel ao carregar lan743x para a LAN7430 do Super. O BSP Hybrid final coloca lan743x na blacklist (veja o item 3 da Tech Note A), portanto o Ethernet com fio onboard fica temporariamente indisponível; o Wi‑Fi não é afetado.

Esta é uma limitação de compatibilidade entre driver de kernel/APP de origem, não uma falha de QSPI ou pinmux do Super. Faça port ou upgrade de um driver compatível e execute testes de estresse antes de depender de Ethernet com fio em produção.

Suporte técnico e discussão de produtos​

Obrigado por escolher nossos produtos! Estamos aqui para fornecer diferentes tipos de suporte para garantir que sua experiência com nossos produtos seja a mais tranquila possível. Oferecemos vários canais de comunicação para atender a diferentes preferências e necessidades.

Loading Comments...