ll_entry_count returns 0 even though the linker list has 5 entries

[Simon Glass]

Hi Osman,

On Fri, 18 Oct 2024 at 01:39, Osman <aibaykaro at gmail.com> 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 <sjg at chromium.org>, 18 Eki 2024 Cum, 02:18 tarihinde şunu yazdı:
>>
>> +U-Boot Mailing List
>>
>> On Thu, 17 Oct 2024 at 03:03, Osman <aibaykaro at gmail.com> 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 <aibaykaro at gmail.com>, 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