Sono in Uboot e mi chiedevo, come potrei dire quale intervallo di indirizzi RAM viene utilizzato da Uboot.
uboot ha bisogno di memoria per funzionare, quindi potrebbe usare parte della RAM. Voglio evitare di modificare quegli indirizzi RAM.
Come faccio a sapere quale area di memoria è uboot caricata?
Risposte:
La pagina DULG DebuggingUBoot ha questo da dire (il "trasferimento" di cui parla sta copiando se stesso dalla memoria flash alla RAM).
Per il debug di U-Boot dopo il trasferimento, è necessario conoscere l'indirizzo a cui U-Boot si trasferisce. Quando non vengono utilizzate funzionalità esotiche come PRAM, questo indirizzo di solito è - CONFIG_SYS_MONITOR_LEN. Nel nostro esempio con 16 MB di RAM e CONFIG_SYS_MONITOR_LEN = 192 KB questo produce l'indirizzo 0x1000000 - 0x30000 = 0xFD0000.
Un'ulteriore lettura del testo sembra indicare che dipende dal processore o dalla scheda e che potrebbe essere necessario controllare la fonte U-Boot per sapere con certezza.
Per quanto riguarda il Guruplug :
Sul lato RAM, u-Boot ha i primi 8 megabyte riservati. Il resto è gratuito. Alcuni sviluppatori caricheranno kernel e filesystem a 0 × 800000 per la programmazione in flash. Un altro punto comune è al limite di 100 megabyte (o offset 0 × 640000).
A seconda della versione di U-Boot in uso potrebbero essere disponibili comandi per mettere una stringa da qualche parte nella RAM libera e quindi cercare il resto della RAM per quella stringa, rivelando la posizione approssimativa di U-Boot in memoria.
Quando avvio la versione di uboot che sto usando, viene automaticamente visualizzato un "layout di memoria del kernel virtuale".
Memory: 859068k/859068k available, 25668k reserved, 0K highmem
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
DMA : 0xf9e00000 - 0xffe00000 ( 96 MB)
vmalloc : 0xe0800000 - 0xf4000000 ( 312 MB)
lowmem : 0x80000000 - 0xe0000000 (1536 MB)
pkmap : 0x7fe00000 - 0x80000000 ( 2 MB)
modules : 0x7f000000 - 0x7fe00000 ( 14 MB)
.init : 0x80008000 - 0x8004d000 ( 276 kB)
.text : 0x8004d000 - 0x808ad000 (8576 kB)
.data : 0x808ce000 - 0x80937a40 ( 423 kB)
Ho scoperto che era sicuro utilizzare l'area lowmem per vari processi di utilità che volevo eseguire (come caricare file di grandi dimensioni in memoria). Idealmente, penso che tu voglia usare memoria alta per quel tipo di cose, ma non avevo l'opzione (come puoi vedere nel mio output).