Question

我不了解加载U-Boot时RAM中发生了什么。我正在使用Xilinx Zynq ZC702评估套件，并尝试使用U-Boot在其上加载Linux内核。所以我使用Xilinx工具Vivado和SDK来生成一个逐步写在SD卡上的BOOT.bin文件：

使用Vivado创建一个HW项目，
使用SDK生成FSBL和FPGA比特流，
创建包含FSBL +比特流+ U-Boot的启动映像（我从xilinx Git存储库下载了U-Boot源代码）。

简而言之，我遵循了Xilinx User Guide中描述的所有步骤。

但是现在，在加载内核之前，我想了解发生了什么，但我不能。根据文档，如果从闪存加载，U-Boot将自身复制到RAM中，并从那里执行，但在哪里？

我在网上搜索，发现U-Boot提取自身的地址在 include / configs / zynq-common.h 中由 CONFIG_SYS_TEXT_BASE ，似乎是0x400_0000。

但是在其他网站上我看到我们可以在调试模式下打印重定位地址，所以我修改了文件 common / board_r.c 并覆盖了函数＆＃34; initr_announce ＆＃34;打印＆＃34; gd-＆gt; relocaddr ＆＃34;领域。这次看起来U-Boot使用偏移地址0x3FF3_7000。

当我使用U-Boot命令＆＃34; md＆＃34;检查内存我发现使用了两个偏移，我看到了一个神奇的数字＆＃34; be00_00ea＆＃34;在这两个地方：

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>

为什么U-Boot需要这两个偏移？ U-Boot的实际内存占用量是多少？更一般地说，我可以在哪里放置内核以确保它不会覆盖某些内容？

Answer 1

ARM体系结构上的u-boot重定位

这是两阶段启动过程的整个序列：

ROM代码将SPL（从SD卡上的MLO文件）读取到CONFIG_SPL_TEXT_BASE地址。该地址通常位于SRAM中，不需要初始化即可正常工作（与RAM相对）。 ROM代码跳转到SPL代码。
SPL配置RAM，然后读取u-boot（从SD卡上的u-boot.img文件）到CONFIG_SYS_TEXT_BASE RAM地址（通常在RAM的开头）并运行它
u-boot将自身重定位到gd->relocaddr RAM地址（通常位于RAM的末尾）并跳转到重定位代码
现在我们已准备好启动内核

对于单阶段启动，您没有SPL，通常只使用u-boot.bin文件。在这种情况下，您只有步骤3和4。

关于重定位有两种情况（如doc/README.arm-relocation中所述）：

CONFIG_SYS_TEXT_BASE != gd->relocaddr：将执行重新定位
CONFIG_SYS_TEXT_BASE == gd->relocaddr：不会执行重定位

在您的情况下，您会看到已执行重定位（为CONFIG_SYS_TEXT_BASE != gd->relocaddr）。

所以，解决你的问题：

为什么U-Boot需要这两个偏移？

u-boot ARM relocation task：

... 我们可以测量板上存在的实际内存大小，然后将U-Boot重新定位到RAM的最末端，几乎可以将整个RAM用作＆＃的一个大的连续区域34;应用＆＃34;比如加载Linux内核，ramdisk等

实际上，如果您查看代码，您可以看到gd->relocaddr是RAM的结尾减去监视器代码（U-Boot）大小：

gd->relocaddr = gd->ram_top;
...
gd->relocaddr -= gd->mon_len;

还可以执行一些额外的内存保留。例如，在我的平台（TI DRA7XX EVM）上，我可以看到下一个函数叫做：

setup_dest_addr()
reserve_round_4k()
reserve_mmu()
reserve_uboot()

实际的重新定位是在board_init_f()调用之后完成的。

<强>拱/臂/ LIB / crt0.s中：

bl board_init_f
...
b relocate_code

<强>拱/臂/ LIB / relocate.S ：

ENTRY(relocate_code)

现在您可以轻松回答下一个问题：

U-Boot的实际内存占用量是多少？

在重定位之前，U-Boot驻留在CONFIG_SYS_TEXT_BASE。重定位后，U-Boot驻留在gs->relocaddr。

关于你的上一个问题：

我可以在哪里放置内核以确保它不会覆盖某些内容？

由于U-Boot被重新定位到RAM的末尾，理论上可以使用任何RAM地址来放置内核。但请查看CONFIG_EXTRA_ENV_SETTINGS中的include/configs/zynq-common.h定义：

"sdboot=if mmcinfo; then " \
        "run uenvboot; " \
        "echo Copying Linux from SD to RAM... && " \
        "load mmc 0 ${kernel_load_address} ${kernel_image} && " \
        "load mmc 0 ${devicetree_load_address} ${devicetree_image} && " \
        "load mmc 0 ${ramdisk_load_address} ${ramdisk_image} && " \
        "bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}; " \
    "fi\0" \

从那里你可以看到你应该将内核加载到${kernel_load_address}，0x2080000：

"kernel_load_address=0x2080000\0" \

其他常量请参见该定义的其余部分。

bdinfo命令

您可以找到有用的bdinfo命令：可以使用U-Boot shell中的bdinfo命令找到重定位地址以及其他有用信息。例如，对于DRA7XX EVM：

=> bdinfo

DRAM bank   = 0x00000000
-> start    = 0x80000000
-> size     = 0x60000000
TLB addr    = 0xDFFF0000
relocaddr   = 0xDFF5D000
reloc off   = 0x5F75D000
irq_sp      = 0xDEF3CEE0
sp start    = 0xDEF3CED0

从这里你可以看到：

RAM从0x80000000
RAM大小为0x60000000
...所以RAM结束（gd->ram_top）是0x80000000 + 0x60000000 = 0xE0000000
重定位地址为0xDFF5D000
重定位的保留内存为0xE0000000 - 0xDFF5D000 = 652 KB
monitor（U-Boot）大小约为TLB addr - relocaddr = 0xDFFF0000 - 0xDFF5D000 = 588 KB

另见：

[1] u-boot : Relocation

[2] what is the use of SPL (secondary program loader)

[3] commit that adds ARM relocation support to u-boot

了解U-Boot内存占用

1 个答案:

ARM体系结构上的u-boot重定位

bdinfo命令