In previous chapter we got U-boot debuggable. Partially debuggable as we turned out. The thing we missed is relocation. The workaround provided in that document is simple enough but not might be comfortable. Here suggested workaround adopted to NetSoM to get fully functional u-boot debugging procedure.
Command line mode debugging
- Start GDB server:
- Start GDB session:
that command has to be called from U-boot folder (build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/u-boot-wirelessroad_ecspi3/u-boot-2017.07 in our case) with u-boot image compiled with debugging symbols
- Connect to target device and load image:
check that program counter set correctly:
here 0x87800000 is starting address u-boot image is placed.
- Restore device tree binary blob:
That address here is the end address of image. It need to be done as in production mode (without debugger) U-boot checks for device tree binary blob at the address placed right after image:
here you see size of u-boot-nodtb.bin (u-boot image without dtb appended to the end) = 535912 = 0x82D68.
So if you will add it to the starting address of u-boot being placed: 0x82D68 + 0x87800000 = 0x87882D688 you will get it. Binary blob of dts – u-boot.dtb has size 26579. Being appended to u-boot-nodtb.bin (size 535912) gives you u-boot-dtb.bin (size 562491).
Another way to get this address – you can check for value of __end address in u-boot.map file:
- Set breakpoint at relocate_code to prevent jumping to unprepared memory area and start execution:
at this moment program counter passed for board_init_f initialization procedure so we can place symbol file at target memory area program counter going to jump:
without it you can continue executeion. Nothing brakes but you will not be able to set breakpoints as they will be placed in memory area starting from 0x87800000 u-boot image place initially while actual execution will be at relocated area starting from 0x8FF2B000. So by adding debugging symbols by new address you will get duplicated addresses for each debugging symbol:
and now is time for controlled jump:
here we check for program counter before relocate_code function being executed – 0x87802db4 and after – 0x8ff2d8cc. As you see we jumped to new memory area. Continue execution:
Still able to catch PC by breakpoints.
How to determine relocation address? Explained in same document mentioned above. You can check it by typing bdinfo command in u-boot console:
here relocaddr is memory address u-boot going to relocate itself and fdt_blob – address device tree binary blob to be found. Another way to get relocation address is interrupt execution of u-boot under debugger and type following:
Doing same in Eclipse.
in eclipse we have to provide same commands to load dtb blob, to set breakpoint:
Then we have to start execution:
it should stop at relocate_code function. Same commands we entered to load debugging symbols to relocation are to be entered here in Debugger console:
Continue execution and it will stop at board_init_r function.
So, finally we got fully debuggable and controllable u-boot. Next time we will pass u-boot initialization procedure from start till the end to learn how it is.
U-boot initialization sequence