Re: ll_entry_count returns 0 even though the linker list has 5 entries

18 Oct 2024


      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@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@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@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