2013-12-11 18 views
9
  • Come il bootloader di u-boot legge/salva il proprio ambiente Variabili?
  • Come si dichiara l'indirizzo della sezione Variabile di ambiente u-boot in Flash?Come il bootloader di u-boot legge/salva il proprio ambiente Variabili?

  • Dalla descrizione a here: L'ambiente U-Boot è un blocco di memoria che viene mantenuto nella memoria permanente e copiato nella RAM all'avvio di U-Boot.

Che significato di "copiato in RAM"?

U-boot copia il blocco di memoria delle variabili di ambiente nella RAM?

Grazie

risposta

5

L'indirizzo e le dimensioni delle variabili env blocco sarà definite nel file header di bordo. See include/configs/am3517_evm.h per esempio:

#define CONFIG_SYS_ENV_SECT_SIZE  (128 << 10)  /* 128 KiB */ 
#define CONFIG_ENV_OFFSET    SMNAND_ENV_OFFSET 
#define CONFIG_ENV_ADDR     SMNAND_ENV_OFFSET 

carichi u-boot CONFIG_SYS_ENV_SECT_SIZE da SMNAND_ENV_OFFSET. È possibile modificare i valori e quindi salvarli tramite saveenv.

8

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).

+0

@ 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? –

+0

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. –

+0

@ 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 –