Hi Osman, I'm adding Heinrich as he knows about RISC-V. This is a mystery to me.
Regards, Simon On Mon, 21 Oct 2024 at 08:56, Osman <[email protected]> wrote: > > Hi Simon, > > I have digged on this a bit while debugging and this is the disassembled > version of the ll_entry_count: > > 1 auipc s1,0x4 > 2 addi s1,s1,-436 > 3 sub s1,s1,s2 > 4 srai s1,s1,0x3 > 5 auipc a5,0x2 > 6 ld a5,-228(a5) > 7 mulw s1,s1,a5 > > For explanation s2 contains the start of the linker list and the s1 contains > the end of it so at line 3 it calculates the end-start as 0x258 which is > correct in my case (0x80006620 − 0x800063c8). From there it gets a bit > interesting cause it shifts that value to right by 3 in line 4, from there it > makes a load operation (line 5-6) at 0x80005768 which corresponds to this > location in generated .map file: > > .rodata.cst8 0x0000000080005768 0x8 drivers/core/lists.o > > Since i know the size of the linker list by looking at the .map file i made > the calculation myself, 0x258 shifted right 3 times becomes 0x4b and to make > the calculation correct size of the struct driver must be shifted as well > which is 0x78>>3 = F. Since this is the multiplicative inverse the final > value should be something like 0xeeeeeeeeeeeeeeef but the value in that > section was just 0x0. From there i was a bit clueless to be honest i am not > sure what makes it filled with zeros instead of the actual number, i made a > simple c code to test it out myself but it didn't generate the same assembly > lines. I know that declaring CONFIG_SPL_OPENSBI just adds the spl_opensbi.c > file but I couldn't figure out how it is related to this, that file doesn't > even use linker_lists.h. In the end I left it at that since there weren't any > more clues. By the way, I looked at the .map file to see what adding opensbi > adds to the symbols but those symbols are after the address in question so I > couldn't make much sense of it. So that's it, thank you for your time and > have a nice day. > > Best Regards, > > Osman > > > Simon Glass <[email protected]>, 18 Eki 2024 Cum, 17:55 tarihinde şunu yazdı: >> >> 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
