ll_entry_count returns 0 even though the linker list has 5 entries

[Osman]

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?

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
>