Ich habe mehrere Blogbeiträge von Leuten gesehen, die die Umgebungsvariable U-Boot bootdelay 0 umgehen, um zur U-Boot-CLI zu gelangen. Ein Beispiel istHier. Der allgemeine Prozess ist, wie ich ihn verstehe:
- Flash-Chip auslöten/kurzschließen, damit U-Boot nicht darauf zugreifen kann
- Gerät einschalten
U-Boot kann den Flash-Chip nicht finden und wechselt zur 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>
Ändern Sie die Bootverzögerung auf einen Wert ungleich Null:
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>
- Schalten Sie das Gerät aus und schließen Sie den Flash-Chip erneut an.
Soweit ich weiß, befinden sich U-Boot und seine Umgebungsvariablen im Flash. Wenn der Flash-Chip von der CPU getrennt ist, wie wird U-Boot dann überhaupt geladen und wie kann die Bootdelay-Variable im permanenten Speicher gespeichert werden?
Antwort1
Dies ist ein sehr spezielles Beispiel. In diesem speziellen Beispiel ist U-Boot im NOR-Flash (ein Chip) und der Linux-Kernel im NAND-Flash (ein zweiter Chip) untergebracht. In der referenzierten Anleitung wird der NAND-Chip von der Platine entfernt, damit der Bootvorgang fehlschlägt. Wir wechseln zur U-Boot-Befehlszeile und können dann die Bootverzögerung ändern und speichern, da U-Boot in diesem Fall so konfiguriert ist, dass die Umgebung auch im NOR-Flash gespeichert wird.