Understand des U-Boot-Speichers verstehen
Ich verstehe nicht, was beim Laden von U-Boot im RAM passiert. Ich arbeite an einem Xilinx Zynq ZC702-Evaluierungskit und versuche, mit U-Boot einen Linux-Kernel darauf zu laden. Also habe ich mit dem Xilinx-Tool Vivado und dem SDK eine BOOT.bin-Datei erstellt, die Schritt für Schritt auf eine SD-Karte geschrieben wird:
Erstelle ein HW-Projekt mit Vivado,enerieren Sie FSBL- und FPGA-Bitstream mithilfe des SDErstellen Sie ein Boot-Image mit FSBL + Bitstream + U-Boot (ich habe die U-Boot-Quellen aus dem xilinx Git-Repository heruntergeladen).urz gesagt, ich habe alle auf @ beschriebenen Schritte befolgXilinx Benutzerhandbuch.
Aber jetzt, bevor ich den Kernel lade, wollte ich verstehen, was passiert ist, aber ich kann nicht. Laut Dokumentation kopiert sich U-Boot, wenn es von Flash geladen wird, in den RAM und führt sich von dort aus aus, aber wo?
Ich habe im Web gesucht und festgestellt, dass die Adresse, unter der sich U-Boot selbst extrahiert, in @ definiert is include / configs / zynq-common.h durch CONFIG_SYS_TEXT_BASE, anscheinend 0x400_0000.
Aber auf einer anderen Website habe ich gesehen, dass wir die Relocation-Adresse im Debug-Modus drucken können, also habe ich die Datei @ geänder common / board_r.c und überschrieb die Funktion " initr_announce ", um das" gd-> relocaddr "-Feld. Diesmal scheint U-Boot die Offset-Adresse 0x3FF3_7000 zu verwenden.
Wenn ich den U-Boot-Befehl "md" verwende, um den Speicher zu überprüfen, sehe ich, dass die beiden Offsets verwendet werden, und an beiden Stellen eine Art magische Zahl "be00_00ea":
Xilinx First Stage Boot Loader
Release 2014.4 Feb 8 2016-14:53:56
Devcfg driver initialized
Silicon Version 3.1
Boot mode is SD
SD: rc= 0
SD Init Done
Flash Base Address: 0xE0100000
Reboot status register: 0x60400000
Multiboot Register: 0x0000C000
Image Start Address: 0x00000000
Partition Header Offset:0x00000C80
Partition Count: 3
Partition Number: 1
Header Dump
Image Word Len: 0x000F6EC0
Data Word Len: 0x000F6EC0
Partition Word Len:0x000F6EC0
Load Addr: 0x00000000
Exec Addr: 0x00000000
Partition Start: 0x000065D0
Partition Attr: 0x00000020
Partition Checksum Offset: 0x00000000
Section Count: 0x00000001
Checksum: 0xFFD14B7E
Bitstream
In FsblHookBeforeBitstreamDload function
PCAP:StatusReg = 0x40000A30
PCAP:device ready
PCAP:Clear done
Level Shifter Value = 0xA
Devcfg Status register = 0x40000A30
PCAP:Fabric is Initialized done
PCAP register dump:
PCAP CTRL 0xF8007000: 0x4C00E07F
PCAP LOCK 0xF8007004: 0x0000001A
PCAP CONFIG 0xF8007008: 0x00000508
PCAP ISR 0xF800700C: 0x0802000B
PCAP IMR 0xF8007010: 0xFFFFFFFF
PCAP STATUS 0xF8007014: 0x00000A30
PCAP DMA SRC ADDR 0xF8007018: 0x00100001
PCAP DMA DEST ADDR 0xF800701C: 0xFFFFFFFF
PCAP DMA SRC LEN 0xF8007020: 0x000F6EC0
PCAP DMA DEST LEN 0xF8007024: 0x000F6EC0
PCAP ROM SHADOW CTRL 0xF8007028: 0xFFFFFFFF
PCAP MBOOT 0xF800702C: 0x0000C000
PCAP SW ID 0xF8007030: 0x00000000
PCAP UNLOCK 0xF8007034: 0x757BDF0D
PCAP MCTRL 0xF8007080: 0x30800100
DMA Done !
FPGA Done !
In FsblHookAfterBitstreamDload function
Partition Number: 2
Header Dump
Image Word Len: 0x0001BA12
Data Word Len: 0x0001BA12
Partition Word Len:0x0001BA12
Load Addr: 0x04000000
Exec Addr: 0x04000000
Partition Start: 0x000FD490
Partition Attr: 0x00000010
Partition Checksum Offset: 0x00000000
Section Count: 0x00000001
Checksum: 0xF7EAFAC8
Application
Handoff Address: 0x04000000
In FsblHookBeforeHandoff function
SUCCESSFUL_HANDOFF
FSBL Status = 0x1
U-Boot 2015.07 (Feb 11 2016 - 10:24:28 +0100)
Model: Zynq ZC702 Development Board
I2C: ready
DRAM: ECC disabled 1 GiB
MMC: zynq_sdhci: 0
SF: Detected N25Q128A with page size 256 Bytes, erase size 64 KiB, total 16 MiB
In: serial
Out: serial
Err: serial
Model: Zynq ZC702 Development Board
Net: Gem.e000b000
Hit any key to stop autoboot: 0
zynq-uboot> md 0x4000000
04000000: ea0000be e59ff014 e59ff014 e59ff014 ................
04000010: e59ff014 e59ff014 e59ff014 e59ff014 ................
04000020: 04000060 040000c0 04000120 04000180 `....... .......
04000030: 040001e0 04000240 040002a0 deadbeef ....@...........
04000040: 0badc0de e320f000 e320f000 e320f000 ...... ... ... .
04000050: e320f000 e320f000 e320f000 e320f000 .. ... ... ... .
04000060: e51fd028 e58de000 e14fe000 e58de004 (.........O.....
04000070: e3a0d013 e169f00d e1a0e00f e1b0f00e ......i.........
04000080: e24dd048 e88d1fff e51f2050 e892000c H.M.....P ......
04000090: e28d0048 e28d5034 e1a0100e e885000f H...4P..........
040000a0: e1a0000d eb0005dc e320f000 e320f000 .......... ... .
040000b0: e320f000 e320f000 e320f000 e320f000 .. ... ... ... .
040000c0: e51fd088 e58de000 e14fe000 e58de004 ..........O.....
040000d0: e3a0d013 e169f00d e1a0e00f e1b0f00e ......i.........
040000e0: e24dd048 e88d1fff e51f20b0 e892000c H.M...... ......
040000f0: e28d0048 e28d5034 e1a0100e e885000f H...4P..........
zynq-uboot> md 0x3ff37000
3ff37000: ea0000be e59ff014 e59ff014 e59ff014 ................
3ff37010: e59ff014 e59ff014 e59ff014 e59ff014 ................
3ff37020: 3ff37060 3ff370c0 3ff37120 3ff37180 `p.?.p.? q.?.q.?
3ff37030: 3ff371e0 3ff37240 3ff372a0 deadbeef .q.?@r.?.r.?....
3ff37040: 3f312628 e320f000 e320f000 e320f000 (&1?.. ... ... .
3ff37050: e320f000 e320f000 e320f000 e320f000 .. ... ... ... .
3ff37060: e51fd028 e58de000 e14fe000 e58de004 (.........O.....
3ff37070: e3a0d013 e169f00d e1a0e00f e1b0f00e ......i.........
3ff37080: e24dd048 e88d1fff e51f2050 e892000c H.M.....P ......
3ff37090: e28d0048 e28d5034 e1a0100e e885000f H...4P..........
3ff370a0: e1a0000d eb0005dc e320f000 e320f000 .......... ... .
3ff370b0: e320f000 e320f000 e320f000 e320f000 .. ... ... ... .
3ff370c0: e51fd088 e58de000 e14fe000 e58de004 ..........O.....
3ff370d0: e3a0d013 e169f00d e1a0e00f e1b0f00e ......i.........
3ff370e0: e24dd048 e88d1fff e51f20b0 e892000c H.M...... ......
3ff370f0: e28d0048 e28d5034 e1a0100e e885000f H...4P..........
zynq-uboot>
Warum braucht U-Boot diese beiden Offsets? Und wie sieht der tatsächliche Speicherbedarf von U-Boot aus? Und allgemeiner, wo kann ich meinen Kernel ablegen, um sicherzugehen, dass er etwas nicht überschreibt?