Hi Osman, On Fri, 18 Oct 2024 at 01:39, Osman <[email protected]> wrote: > > Hello Simon, > > I am not sure, the problem is with the rodata as the linker list looks fine > and execution finds the start and end of the list correctly. The wrong thing > is the size value it uses located at the rodata. This is the region in > u-boot-spl.lds that links the rodata: > > . = ALIGN(4); > .rodata : { > *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) > } > .spl_mem > > I am not sure where it looks for the alignment of this value. Normally the > field which spl looks in rodata should contain the multiplicative inverse of > the size of struct driver and from what i can tell from assembly it is > shifted as well. Where does the linker look for the alignment of a value like > this?
This is something of a mystery to me as well. I did dig into it quite a lot at one point and recall some alignment settings on both input and output sections. But the strange thing about your case is that it seems that ll_entry_start() and ll_entry_end() are correct but ll_entry_count() is not. That is the particular situation that I believe you could debug, to understand what is happening. > > Regards, > Osman > > Simon Glass <[email protected]>, 18 Eki 2024 Cum, 02:18 tarihinde şunu yazdı: >> >> +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
