[Letux-kernel] [PATCH 00/20] A bunch of JZ4730 fixups for letux-kernel
H. Nikolaus Schaller
hns at goldelico.com
Thu Dec 3 10:34:51 CET 2020
Hi Lubomir,
> Am 03.12.2020 um 09:56 schrieb Lubomir Rintel <lkundrak at v3.sk>:
>
> Hello Nikolaus
>
> (also, sorry for botching your name in the branch name in a recent
> message. I was lazy to check and took chances)
No problems. Typos happen.
>
> On Wed, Dec 02, 2020 at 09:45:31PM +0100, H. Nikolaus Schaller wrote:
>> Hi Lubomir,
>>
>>> Am 30.11.2020 um 07:50 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>>>
>>> Hi Lubomir,
>>>
>>>> Am 28.11.2020 um 16:31 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>>>>>
>>>>> Then I checked out your complete tree, copied the .config to the right location and:
>>>>>
>>>>> 2919423 bytes read
>>>>> ## Booting image at 80600000 ...
>>>>> Image Name: Linux-5.10.0-rc5-letux-l400+
>>>>> Image Type: MIPS Linux Kernel Image (gzip compressed)
>>>>> Data Size: 2919359 Bytes = 2.8 MB
>>>>> Load Address: 80100000
>>>>> Entry Point: 8053d0f4
>>>>> Verifying Checksum ... OK
>>>>> Uncompressing Kernel Image ... OK
>>>>>
>>>>> Starting kernel ...
>>>>>
>>>>> [ 0.000000] Linux version 5.10.0-rc5-letux-l400+ (hns at iMac.fritz.box) (mipsel-linux-gnu-gcc (GCC) 4.9.2, GNU ld (GNU Binutils) 2.25) #4026 PREEMPT Sat Nov 28 14:32:55 CET 2020
>>>>> [ 0.000000] CPU0 revision is: 02d0024f (Ingenic XBurst)
>>>>> [ 0.000000] MIPS: machine is letux400,minipc
>>>>> [ 0.000000] earlycon: jz4740_uart0 at MMIO32 0x10030000 (options '115200n8')
>>>>> [ 0.000000] printk: bootconsole [jz4740_uart0] enabled
>>>>> [ 0.000000] printk: debug: ignoring loglevel setting.
>>>>> [ 0.000000] User-defined physical RAM map overwrite
>>>>> [ 0.000000] Initrd not found or empty - disabling initrd
>>>>> [ 0.000000] cma: Reserved 32 MiB at 0x01000000
>>>>> ...
>>>>>
>>>>> So there is a subtle difference between your minimalistic tree and the full letux tree which blows up the uImage by ca. 80% and makes it fail to boot.
>>>>> Have to study this now... But I think we are close.
>>>>
>>>> Seems to be something incompatible in my defconfig.
>>>> If I merge your tree into mine and use your defconfig it works.
>>>> The one that is ok for CI20 (of course after switching to JZ4730) fails.
>>>>
>>>> This is now a bisectable problem...
>>>
>>> Yes, it was - partially - bisectable. But it is not a specific CONFIG.
>>> And not a specific subsystem compiled into the kernel.
>>>
>>> Rather it appears as if there is a limit of ca. 3800000 Bytes for the uImage Data Size.
>>> Above that there is no sign of activity. Below the kernel boots.
>>>
>>> I have cross-checked and the vmlinux.bin is quite exactly 8 MB in that cases which gets
>>> compressed into these ca. 3800000 Bytes.
>>>
>>> So please can you
>>> a) check what happens for your build if you configure for bigger uImage (so that vmlinux.bin is more than 8MB)
>>> (e.g. CONFIG_INET, CONFIG_WIRELESS, CONFIG_POSIX_MQUEUE, CONFIG_CGROUPS, CONFIG_NAMESPACES, CONFIG_KEXEC, CONFIG_SUSPEND)
>>> until your kernel size goes beyond 3.8 MB resp. 8 MB?
>>> b) try to boot my smaller uImage-good and the full uImage [1] and look by JTAG why the uncompression fails for the latter?
>>> (NOTE: it seems to be jz4730 specific since the CI20 has no problems with bigger uImages)
>>> c) have ideas why the appended-DTB search algorithm fails? This would not be used for the CI20.
>>
>> Have you had time to think about this finding?
>
> Not until late last night; but then my IQ dropped to a level I was not
> able to pen a reasonable reply :)
:)
>
> I was able to reproduce your issue. It seems to me that the factory
> U-Boot generally limits the image to 8MB uncompressed, and your raw image
> seems to be about 12 MB:
>
> common/cmd_bootm.c:#define CFG_BOOTM_LEN 0x800000 /* use 8MByte as default max gunzip size */
Ah, damn. So the "Starting Kernel..." is still from U-Boot and there is no warning about a too big uImage.
Sad. My hope was that it is a limit inside the kernel.
>
> I can't see a workaround other than newer U-Boot.
Well, I could change a lot of CONFIGs from =y to =m (for example all networking and display stuff)
but at some point it will not boot because essential modules are missing before they can be loaded from
the SD card.
This would not harm the CI20 (which I want to use almost the same CONFIG for), except that booting
becomes a little slower.
> I've written down some
> documentation about it:
>
> https://projects.goldelico.com/p/letux400/page/UpdateUboot/
>
> If you don't have a JTAG setup and are not comfortable with the idea of
> rewriting the booloader, plase let me know.
Well, the idea of LetuxOS is to provide a booting SD card image for everyone.
So using JTAG tricks is good for lab but not for the target group of LetuxOS.
> The newer U-Boot can also be
> turned into an uImage and chain-booted from the factory loader, but I'd
> have to dig out my notes.
Ok, that sounds a reasonable idea. Another approach would be to use a minimal
uImage and use kexec to load the real thing. This is what the original system
already does if I remember correctly with the initrd and minifs/recover concept [1].
In any case it is quite tricky to setup. At least we have to mangle uImage
file names if they should sit in the same boot partition. E.g. factory U-Boot
loads uImage (being another U-Boot or kernel) and that one loads uImage.bin.
> I left my machine at the hackerspace yesterday
> so I can't try it out at the moment.
Rome wasn't built in a day. And the '400 minibooks were built 12 years ago.
So they can wait some minutes :)
>
> Your kernel loaded fine, but I also left the dmesg on my hackerspace
> machine.
Great. This at least proves and removes any doubt that my build process is good.
> I guess I'll try to follow up with more useful response, also
> addressing the TODOs in the wiki page linked above. But I guess this is
> better than nothing.
Yes, indeed!
>
> Regards
> Lubo
[1] https://git.goldelico.com/?p=l400-rootfs.git;a=blob;f=config/root/mkminifs;h=e175297ec399b90d405632f7fec2d9622b3c8d9d;hb=5c16ddcbd6e7d2a5b93a8f5955ca345d9bc24d66
https://git.goldelico.com/?p=l400-rootfs.git;a=blob;f=config/root/recover;h=3112523de50100ccadeddebf0d2a13951894d459;hb=5c16ddcbd6e7d2a5b93a8f5955ca345d9bc24d66
>
>>
>> BR and thanks,
>> Nikolaus
>>
>>>
>>> BR and thanks,
>>> Nikolaus
>>>
>>> [1]: https://download.goldelico.com/letux-kernel/letux-5.10-rc5-l400/
>>> _______________________________________________
>>> https://projects.goldelico.com/p/gta04-kernel/
>>> Letux-kernel mailing list
>>> Letux-kernel at openphoenux.org
>>> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
More information about the Letux-kernel
mailing list