Hallo,
Is it possible to debug u-boot using jtag? The images I need to debug are MLO (to boot from SD) and u-boot.min.spi (to boot from SPI NOR).
Both those images are less than 128KB to be executed from internal SRAM.
which gel file do I need (if I need one)? Does the BTMODE pin have a special configuration or I can leave them untouched? Reading the u-boot elf file it seems that whole image is placed at 0x80000000 that aren't addresses in SRAM, so how can I load the elf file?
best regards
Max
Ok, Pavel,
I changed Makefile, and now I can successfully debug, but when I try to execute without debug it seems to hang. Is it possible that setup for debug conflicts with setup for normal run?
Another question: why do I need to set the TEXT_BASE to 0x40410000 and not 0x40400000 as I expect?
I mean, reading the reference manual I find:
And the mkimage is invoked with:
$ tools/mkimage -T tiimage -e 0x40400000 -n ti81xx -d u-boot.bin u-boot.min.sd Image Type: Texas Instruments ti81xx Boot Image Image Size: 93548 Bytes = 91.36 kB = 0.09 MB Load Address: 40400000 Entry Point: 40400000
It seems that the actual load address is 0x40400000.
Please note that If I remove the two lines from Makefile it works again (but again I cannot debug)
best regards
Max
mastupristi said:why u-boot needs to be copied from TI_LOAD_ADDR to TEXT_BASE? Both are adresses into internal RAM.
No, by default TEXT_BASE is not addr into internal RAM. TEXT_BASE is addr from external DDR3 memory (0x80700000).
See also the below wike page:
mastupristi said:My include/configs/ti8168.h doesn't define CONFIG_SKIP_RELOCATE_UBOOT. Can I assume that rom code load correctly u-boot into RAM at TI_LOAD_ADDR?
Yes
mastupristi said:In this case I could define the symbol CONFIG_SKIP_RELOCATE_UBOOT to avoid the copy. there are som pitfull with that?
See the below e2e thread:
See also u-boot/README
Regards,
Pavel
Pavel Botev said:When you build the 1st stage bootloader, you have these files:
u-boot.min.sd - stripped binary 1st stage image that can fit into the internal memory
u-boot - Full 1st stage image containing all debug symbols. Too big for internal memory but can be used to load the symbols
You are debugging u-boot.min.sd, u-boot is used only for loading the symbols
Is it clear now?
yes, Pavel,
here is depicted my understanding of compile stage:
the file elf contains both binary and debug info.
the binary file is extracted from elf.
The image is done from binary.
When I debug with jtag I use binary+elf (or only elf). When I execute normally (boot from SD or NOR) i use the image. But the binary executed in both cases is the same, same instractions, same addresses.
Is that right?
best regards
Max
Hi Pavel,
I tried to disable relocation in MLO but it doesn't works. I read the post and now I know that is necessary to relocate in case of SD booting.
I understood that binary executable is excracted from MLO on SD card by rom code. This binary is placed at 0x40400000, then it jumps to 0x40400000.
u-boot do a number of initializations, including ddr. and then it relocate himself to ddr.
Now my issue is to validate ddr calibration, that happens when it run in OCMC RAM. I tried to read DDR PHY registers and it seems that all values are all 0.
In other words I need to debug MLO when it is placed in OCMC RAM. I cannot use directly elf because it has final address reference (in ddr)
my hope is the chance to modify code and data offset
maybe i can "modify" the elf address reference, but I don;t know how. Which values do I neet to set?
I read this
but it seems to me that it doesn't match my case.
After that I will analyze spi 1st stage u-boot. My hope for that is to avoid relocation.
best regards
Max
mastupristi said:In other words I need to debug MLO when it is placed in OCMC RAM.
I already provided the steps needed to create MLO (and u-boot ELF) for OCMC RAM only. For your convenience, I am giving the links again:
Regards,
Pavel
Max,
mastupristi said:_TEXT_BASE is 0x40400000, and then subracting MALLOC_LEN, DATA_SIZE, etc. the stack pointer goes out of OCMC RAM (something like 0x402ff000).
Then you can calculate how much size you need for malloc, data_size, etc and adjust the TEXT_BASE, thus when subtracting you will go to 0x40400000. You need to set up TEXT_BASE = 0x40400000 + MALLOC + DATA_SIZE + etc. All this might result to TEXT_BASE = 0x40410000, what was the initial proposed value.
Another approach can be to remove or reduce the size of malloc, data_size, etc.
Have you also tried to reduce the size of the u-boot? See the below links
mastupristi said:I cannot figure out how your setup can works. Which u-boot target is configured? What do you mean with "works fine"? How do you tried it? via jtag or booting from SD?
I build u-boot with u-boot.min.uart (TI_LOAD_ADDR=TEXT_BASE=0x40300000). Then I load successfully the u-boot.min.uart on the DM814x TI EVM, I see all the boot messages and go into the u-boot min prompt (TI-MIN#). I am not using SD neither JTAG, I am using UART.
I made the below modification in u-boot/arch/arm/cpu/arm_cortexa8/start.S
/*#ifndef CONFIG_SKIP_RELOCATE_UBOOT
relocate: @ relocate U-Boot to RAM
adr r0, _start @ r0 <- current position of code
ldr r1, _TEXT_BASE @ test if we run from flash or RAM
cmp r0, r1 @ don't reloc during debug
beq stack_setup
ldr r2, _armboot_start
ldr r3, _bss_start
sub r2, r3, r2 @ r2 <- size of armboot
add r2, r0, r2 @ r2 <- source end address
copy_loop: @ copy 32 bytes at a time
ldmia r0!, {r3 - r10} @ copy from source address [r0]
stmia r1!, {r3 - r10} @ copy to target address [r1]
cmp r0, r2 @ until source end addreee [r2]
ble copy_loop
#endif */ /* CONFIG_SKIP_RELOCATE_UBOOT */
Pavel Botev said:Then you can calculate how much size you need for malloc, data_size, etc and adjust the TEXT_BASE, thus when subtracting you will go to 0x40400000. You need to set up TEXT_BASE = 0x40400000 + MALLOC + DATA_SIZE + etc. All this might result to TEXT_BASE = 0x40410000, what was the initial proposed value.
Another approach can be to remove or reduce the size of malloc, data_size, etc.
I tried to change both TI_LOAD_ADDR and TEXT_BASE to 0x40410000, then I defined CONFIG_SKIP_RELOCATE_UBOOT and I reduced CONFIG_SYS_MALLOC_LEN to fit the RAM size.
Now I have a problem in clear_bss: I have _bss_start set to 0x4042BE0C and _bss_end 0x4045CC80, so it is out of the OCMC RAM.
linker file I use is:
OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS
{
. = 0x00000000;
. = ALIGN(4);
.text :
{
arch/arm/cpu/arm_cortexa8/start.o (.text)
arch/arm/cpu/arm_cortexa8/ti81xx/lowlevel_init.o (.text)
*(.text)
}
. = ALIGN(4);
.rodata : { *(.rodata) }
. = ALIGN(4);
.data : { *(.data) }
. = ALIGN(4);
.got : { *(.got) }
. = .;
__u_boot_cmd_start = .;
.u_boot_cmd : { *(.u_boot_cmd) }
__u_boot_cmd_end = .;
. = ALIGN(4);
__bss_start = .;
.bss (NOLOAD) : { *(.bss) . = ALIGN(4); }
_end = .;
}
here is the map file:
it seems that fat support needs very much bss:
.bss 0x4042ca54 0x0 arch/arm/lib/libarm.a(reset.o)
.bss 0x4042ca54 0x30008 fs/fat/libfat.a(fat.o)
0x4044ca5c do_fat_read_block
0x4043ca5c get_dentfromdir_block
0x4042ca5c get_vfatname_block
.bss 0x4045ca5c 0x0 disk/libdisk.a(part.o)
.bss 0x4045ca5c 0x0 disk/libdisk.a(part_dos.o)
.bss 0x4045ca60 0x220 drivers/mmc/libmmc.a(omap_hsmmc.o)
unfortunately fat is needed to boot the 2nd stage u-boot.
it only remains to be seen whether, and how, to use static variables in very early u-boot execution.
Pavel Botev said:Have you also tried to reduce the size of the u-boot? See the below links
The link doesn't works, it seems that the site has a invalid security certificate.
best regards
Max
