Já vi várias postagens de pessoas contornando a variável de ambiente U-Boot bootdelay 0 para acessar a CLI do U-Boot. Um exemplo éaqui. O processo geral, pelo que entendi, é:
- Desolder/chip flash curto para que o U-Boot não possa acessá-lo
- Ligar o dispositivo
O U-Boot não consegue encontrar o chip flash e cai para CLI
eth1 up eth0, eth1 Qualcomm Atheros SPI NAND Driver, Version 0.1 (c) 2014 Qualcomm Atheros Inc. ath_spi_nand_ecc: Couldn't enable internal ECC Setting 0x181162c0 to 0x3061a100 Hit any key to stop autoboot: 0 ** Device 0 not available ath>
Altere bootdelay para um valor diferente de zero:
ath> setenv bootdelay 3 ath> saveenv Saving Environment to Flash... Protect off 9F040000 ... 9F04FFFF Un-Protecting sectors 4..4 in bank 1 Un-Protected 1 sectors Protect off 9F050000 ... 9F05FFFF Un-Protecting sectors 5..5 in bank 1 Un-Protected 1 sectors Erasing Flash... 9F050000 ... 9F05FFFF ...Erasing flash... First 0x5 last 0x5 sector size 0x10000 5 Erased 1 sectors Writing to Flash... 9F050005 ... 9F060000 ...write addr: 9f050000 write addr: 9f040004 done Protecting sectors 5..5 in bank 1 Protected 1 sectors Protecting sectors 4..4 in bank 1 Protected 1 sectors ath>
- Desligue o dispositivo e reconecte o chip flash.
Até onde eu sei, o U-Boot e suas variáveis de ambiente residem no flash. Se o chip flash estiver desconectado da CPU, como o U-Boot é carregado e como a variável bootdelay pode ser salva no armazenamento persistente?
Responder1
Este é um exemplo muito específico. Neste exemplo específico, o que está acontecendo é que o U-Boot reside no flash NOR (um chip) e o kernel do Linux reside no flash NAND (um segundo chip). O guia referenciado faz com que você remova o chip NAND da placa para que a inicialização falhe, vamos para a linha de comando do U-Boot e então você pode alterar e salvar o bootdelay, pois o U-Boot está neste caso configurado para salvar o ambiente no NOR piscar também.