+U-Boot Mailing List On Thu, 17 Oct 2024 at 03:03, Osman <[email protected]> wrote: > > Hello Simon, > > The problem is solved after enabling SPL_OPENSBI in my case, it would have > been better if I knew the reason for it but I can't see how the linker list > is related to opensbi configuration. Thank you for your time. > > By the way I made sure to try the spl by only disabling spl_opensbi > configuration to make sure other changes are not affecting it but disabling > really causes it to fail again.
I wonder if this has something to do with alignment? Regards, Simon > > Regards, > > Osman > > Osman <[email protected]>, 15 Eki 2024 Sal, 14:17 tarihinde şunu yazdı: >> >> Hi Simon, >> >> This is a 64 bit RISC-V platform, i don't have LINKER_LIST_ALIGN in my >> defconfig so it should be 4 by default however it's not a problem with >> linker list alignment i suppose. After debugging it in assembly I found out >> that it successfully calculates the length between the start and end of the >> linker list, it just divides incorrectly because the inverse value of the >> size of struct driver is wrong. The rodata section which contains that size >> value is filled with zeros. For reference this is the location it looks for >> the size value: >> >> u-boot-spl.map: >> .rodata.cst8 0x0000000080007eb0 0x8 drivers/core/lists.o >> >> and this is what i see while debugging: >> >> (gdb) x /x 0x0000000080007eb0 >> 0x80007eb0: 0x00000000 >> >> it should be something like 0xEEEEEEEF for it to work correctly. >> Actually there are a lot of spaces that are filled with zeros is this >> normal?: >> >> (gdb) x /64w 0x0000000080007e60 >> 0x80007e60: 0x69797254 0x7420676e 0x6f62206f 0x6620746f >> 0x80007e70: 0x206d6f72 0x000a7325 0x3a4c5053 0x736e5520 >> 0x80007e80: 0x6f707075 0x64657472 0x6f6f4220 0x65442074 >> 0x80007e90: 0x00000000 0x00000000 0x00000000 0x00000000 >> 0x80007ea0: 0x00000000 0x00000000 0x00000000 0x00000000 >> 0x80007eb0: 0x00000000 0x00000000 0x00000000 0x00000000 >> 0x80007ec0: 0x00000000 0x00000000 0x00000000 0x00000000 >> 0x80007ed0: 0x00000000 0x00000000 0x00000000 0x00000000 >> 0x80007ee0: 0x00000000 0x00000000 0x00000000 0x00000000 >> 0x80007ef0: 0x00000000 0x00000000 0x00000000 0x00000000 >> 0x80007f00: 0x00000000 0x00000000 0x00000000 0x00000000 >> 0x80007f10: 0x00000000 0x00000000 0x00000000 0x00000000 >> 0x80007f20: 0x00000000 0x00000000 0x00000000 0x00000000 >> 0x80007f30: 0x00000000 0x00000000 0x00000000 0x00000000 >> 0x80007f40: 0x00000000 0x00000000 0x80007f48 0x00000000 >> 0x80007f50: 0x80007f48 0x00000000 0x80007f48 0x00000000 >> >> u-boot-spl.map: >> .rodata.boot_from_devices.str1.8 >> 0x0000000080007e60 0x39 common/spl/spl.o >> *fill* 0x0000000080007e99 0x7 >> .rodata.cst8 0x0000000080007ea0 0x8 common/spl/spl.o >> .rodata.cst8 0x0000000080007ea8 0x8 lib/tiny-printf.o >> .rodata.cst8 0x0000000080007eb0 0x8 drivers/core/lists.o >> .rodata.devfdt_get_addr_index.str1.8 >> 0x0000000080007eb8 0x4 drivers/core/fdtaddr.o >> .rodata.dm_extended_scan.str1.8 >> 0x0000000080007eb8 0x12 drivers/core/root.o >> 0x1a (size before relaxing) >> *fill* 0x0000000080007eca 0x6 >> .rodata.do_reset.str1.8 >> 0x0000000080007ed0 0x29 arch/riscv/lib/reset.o >> *fill* 0x0000000080007ef9 0x7 >> .rodata.fdt_address_cells.str1.8 >> 0x0000000080007f00 0xf lib/libfdt/fdt_addresses.o >> *fill* 0x0000000080007f0f 0x1 >> .rodata.fdt_find_or_add_subnode.str1.8 >> 0x0000000080007f10 0xc common/fdt_support.o >> *fill* 0x0000000080007f1c 0x4 >> .rodata.fdt_fixup_memory_banks.str1.8 >> 0x0000000080007f20 0x9c common/fdt_support.o >> *fill* 0x0000000080007fbc 0x4 >> .rodata.fdt_get_alias_namelen.str1.8 >> 0x0000000080007fc0 0x9 lib/libfdt/fdt_ro.o >> >> I am not sure what is happening here, is there a way to check how a >> specific rodata region is filled? >> >> Regards, >> >> Osman
