He visto varias publicaciones de blog de personas que sortean la variable de entorno U-Boot bootdelay 0 para acceder a la CLI de U-Boot. Un ejemplo esaquí. El proceso general, según tengo entendido, es:
- Desoldar/chip flash corto para que U-Boot no pueda acceder a él
- Encender el dispositivo
U-Boot no puede encontrar el chip flash y accede a 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>
Cambie el retardo de arranque a un valor distinto de cero:
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>
- Apague el dispositivo y vuelva a conectar el chip flash.
Hasta donde yo sé, U-Boot y sus variables de entorno residen en flash. Si el chip flash se desconecta de la CPU, ¿cómo se carga U-Boot y cómo se puede guardar la variable bootdelay en un almacenamiento persistente?
Respuesta1
Este es un ejemplo muy específico. En este ejemplo específico, lo que sucede es que U-Boot reside en NOR flash (un chip) y el kernel de Linux reside en NAND flash (un segundo chip). La guía a la que se hace referencia le pide que retire el chip NAND de la placa para que el arranque falle, vamos a la línea de comando de U-Boot y luego puede cambiar y guardar el retardo de arranque, ya que en este caso U-Boot está configurado para guardar el entorno en NOR. parpadea también.