[Letux-kernel] X1600 / LX16 support - here: fw_getenv() issue

[H. Nikolaus Schaller]

Hi all,

> Am 06.02.2024 um 19:24 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> 
> 
>> Am 06.02.2024 um 17:15 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>> 
>> 
>> 
>>> Am 06.02.2024 um 09:28 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>>> 
>>> So I added some more ll_printk() and it appears as if the _fw_argv processing is ok,
>>> but someone overwrites some pointers of the _fw_envp so that scanning for env strings
>>> fails.
>>> 
>>> The values overwriting the pointers look like ASCII characters "3=me" and "0 at M2".
>>> 
>>> Next I'll check values at the beginning of the initialization,right after kernel_entry
>>> in start_kernel. Maybe it is possible to "bisect" the code location where these pointers
>>> are overwritten.
>> 
>> First analysis results indicate that the env string pointers are already damaged when
>> start_kernel() is called.
>> 
>> Next, I plan to do comparable tests on the letux-5.10.y-lx16 tests (which is a little
>> difficult as we can't printk() so early in kernel startup).
>> 
>> One new hypothesis comes to my mind: the new kernel is bigger than the letux-5.10.y-lx16
>> kernel. So loading the kernel may overwrite something which U-Boot assumes to be safe.
> 
> v6.8: 4.8 MB
>   Data Size:    5024758 Bytes = 4.8 MiB
>   Load Address: 80010000
>   Entry Point:  80848e0c
> 
> v5.10: 4.2 MB
>   Data Size:    4419937 Bytes = 4.2 MiB
>   Load Address: 80010000
>   Entry Point:  806d88b0
> 
> On the other hand, the env strings are stored at 0xa1fxxxxx addresses which should not
> overlap. But... We only have 32 MB of RAM... So some address bits are don't care
> anyways.
> 
>> 
>> Another hypothesis is that it is compiler dependent. At least on my setup - but Paul
>> has the same issue. I compile the 5.10 kernels with gcc 4.9.2 and the 6.8 kernel with
>> gcc 6.3.0. That is not a big deal to test.
> 
> There is only a small difference in uImage size and the entry point moves a little.
> But no functional difference. At least with 5.10.y. 6.8 requires at least gcc 5.1.0.
> 
> What I can't exclude so far is that the bug is also in letux-5.10.y-lx16 but does
> not make the kernel boot hang, because the "damaging" of the environment variables
> has a different result.
> 
> So maybe I should try to backport the ll_printk stuff to the 5.10.y kernel and try
> to look what it is doing differently at start_kernel().

I've done this and this is what I see at the beginning of start_kernel

v6.8-rc:

Starting kernel ...

start_kernel: fw_arg1=a1f64000 fw_arg2=a1f64440 fw_arg3=00000000
start_kernel: fw_arg1[0] 00000000
start_kernel: fw_arg1[1] a1f64400
start_kernel: fw_arg1[2] a1f64417
start_kernel: fw_arg1[3] a1f64418
start_kernel: fw_arg2[0] 333d6d65
start_kernel: fw_arg2[1] 30404d32
start_kernel: fw_arg2[2] a1003078
start_kernel: fw_arg2[3] a1f64873
start_kernel: start

now with v5.10.y:

Starting kernel ...

start_kernel: fw_arg1=a1f64000 fw_arg2=a1f64440 fw_arg3=00000000
start_kernel: fw_arg1[0] 00000000
start_kernel: fw_arg1[1] a1f64400
start_kernel: fw_arg1[2] a1f64417
start_kernel: fw_arg1[3] a1f64418
start_kernel: fw_arg2[0] 333d6d65 <- this should be a char * for the first env string
start_kernel: fw_arg2[1] 30404d32
start_kernel: fw_arg2[2] a1003078
start_kernel: fw_arg2[3] a1f64873
start_kernel: start
[    0.000000] Linux version 5.10.209-letux-lx16+ (hns at iMac.local) (mipsel-linux-gnu-gcc (GCC) 4.9.2, GNU ld (GNU Binutils) 2.25) #16447 PREEMPT Tue Feb 6 19:44:17 CET 2024

So it is unexpectedly the same! So it may indeed be a bug between U-Boot
start and kernel which for unknown reasons is harmless on 5.10.y.

(as bootloader I use: U-Boot 2013.07-00324-g0ecd9f212b-dirty (Jul 15 2023 - 15:02:47)
but don't remember if it was self-compiled or taken from the vendor samples)

I think I should also print a hexdump of the first 8 bytes at fw_arg*[1]
unless it is NULL...

All this does not fit to copying fw_arg2 to _fw_envp in fw_init_cmdline()
and starting to scan at index 0 in fw_getenv().

Here is a hint on what U-Boot bootm is doing:

https://docs.u-boot.org/en/stable/usage/cmd/bootm.html?highlight=bootm

If I read correctly there are two different formats. And, the second parameter
is NOT a list of some environment variables but the start address of a RAMDISK?

But what is then the story behind fw_getenv() at all?

And U-Boot starts the kernel by

bootcmd=fatload mmc 0 0x80a00000 /uImage; bootm 0x80a00000

I.e. there is no second parameter???

BR,
Nikolaus