[U-Boot] [PATCH 1/1] cmd/bdinfo: sandbox: print the relocation offset

Heinrich Schuchardt xypron.glpk at gmx.de
Mon Aug 12 11:16:56 UTC 2019


On 8/12/19 6:07 AM, Bin Meng wrote:
> On Sat, Aug 10, 2019 at 5:35 AM Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>>
>> On the sandbox provide the relocation offset. This value can be used for
>> debugging with GDB using the `add-symbol-file u-boot <reloc off>' command.
>>
>> Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
>> ---
>>   cmd/bdinfo.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c
>> index 86c17dc427..560c039d37 100644
>> --- a/cmd/bdinfo.c
>> +++ b/cmd/bdinfo.c
>> @@ -395,6 +395,7 @@ int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
>>
>>          print_bi_boot_params(bd);
>>          print_bi_dram(bd);
>> +       print_num("reloc off", (uintptr_t)(gd->reloc_off + gd->arch.ram_buf));
>
> Shouldn't we print gd->relocaddr directly?

There are three address spaces involved:

* The physical address space that you see on the address lines of the RAM.
* The virtual address space of the process in the operating system which
is mapped by the MMU to the physical address space. This is the address
space from which memory is allocated by calling mmap().
* The virtual address space use for testing by the sandbox.

For debugging with GDB we need the virtual address used by the process
of the operating system as relocation target. This is in the range of
the addresses assigned by calling mmap().

gd->relocaddr is an address in the virtual address space of the sandbox.
It is not an address in the memory space reserved by the mmap() call.

Here is an example:

=> bdinfo
boot_params = 0x0000000000000000
DRAM bank   = 0x0000000000000000
-> start    = 0x0000000000000000
-> size     = 0x0000000008000000
relocaddr   = 0x0000000007e10000 // gd->relocaddr
reloc off   = 0x00005557a047d000 // gd->reloc_off + gd->arch.ram_buf
ethaddr     = 00:00:11:22:33:44
IP addr     = 1.2.3.4

For testing the sandbox here stipulates a virtual address space of
[0x0-0x8000000]. But the addresses the CPU uses in the user process are
0x00005557a047c000 and above as shown by the pmap command:

$ $ pmap 15398 | grep u-boot
15398:   ./u-boot
000055579047c000   1840K r-x-- u-boot
0000555790648000     28K r-x-- u-boot
000055579064f000    108K rwx-- u-boot

Best regards

Heinrich

>
>>          print_eth_ip_addr();
>>
>>   #if defined(CONFIG_LCD) || defined(CONFIG_VIDEO)
>> --
>
> Regards,
> Bin
>



More information about the U-Boot mailing list