Sì, U-boot copia il blocco di memoria delle variabili di ambiente nella RAM.
La memoria permanente, da cui proviene il blocco, è specifica della piattaforma. Alcune opzioni di storage comune (e file sorgente di movimentazione che l'opzione di archiviazione):
NOR flash common/env_flash.c
SPI flash common/env_sf.c
MMC common/env_mmc.c
definizioni CONFIG_ in include/configs/yourboard.h determinerà i dettagli. Ad esempio, per SPI Flash mappato in cima alla memoria, forse:
#define CONFIG_ENV_IS_IN_SPI_FLASH
#define CONFIG_ENV_SIZE 0x00001000
#define CONFIG_ENV_ADDR 0xFFFFF000
CONFIG_ENV_ADDR è l'indirizzo di ambiente u-boot sezione variabile in Flash.
Si noti che u-boot crea automaticamente un CRC32 su questa sezione durante la scrittura dell'ambiente in memoria permanente. Quel CRC è controllato quando l'ambiente viene letto all'avvio. Se il controllo CRC non passa, l'ambiente memorizzato non viene utilizzato; al suo posto viene utilizzato un nuovo ambiente predefinito codificato nel codice del programma, che è un caso speciale.
Durante l'inizializzazione di U-Boot, le variabili di ambiente vengono importate in una tabella hash. Durante il funzionamento, tutte le operazioni di lettura/scrittura e tutti i comandi "printenv" (variabile di ambiente di visualizzazione) e "setenv" (imposta variabile di ambiente) utilizzano quelle voci di tabella. Qualsiasi modifica non è salvata fino a quando non viene eseguito il comando "saveenv", che scrive nella memoria permanente.
Per ulteriori informazioni, vedere u-boot/common/cmd_nvedit.c righe 14-24 e u-boot/README righe 3474-3881 (i numeri di riga sono per v2013.10).
fonte
2013-12-11 20:11:11
@ Joe Kul, grazie. Se u-boot copia il blocco di memoria delle variabili di ambiente nella RAM. Allora, dove abbiamo definito l'indirizzo di questa sezione nella RAM? Sono sorpreso dal fatto che u-boot non legga e non importi la sua sezione env direttamente dal flash alla ** tabella hash ** ma abbia bisogno di copiare nella RAM e poi importa successivamente? –
U-Boot copia praticamente tutto da flash a RAM. Questo è indicato come "trasferimento".Per ottenere l'indirizzo nella RAM per tutto ciò che proviene dal flash, è possibile aggiungere "Offset relocation" (stampato sulla console) alla posizione flash in u-boot.map. Vedi anche arch/arm/lib/board.c. Ma il trasferimento è un argomento separato. –
@ Joe Kul: non so che u-boot abbia bisogno di una "delocalizzazione". Per il mio sistema, boostrap carica u-boot in RAM, quindi penso che u-boot abbia solo bisogno di leggere i blocchi di variabili d'ambiente ma non c'è bisogno di delocalizzazione. In realtà, il mio u-boot è un'immagine binaria, quindi non può eseguire alcun riposizionamento. Grazie –