[Letux-kernel] jz4730-i2c - clocksource

[H. Nikolaus Schaller]

> Am 07.03.2021 um 21:49 schrieb Andreas Kemnade <andreas at kemnade.info>:
> 
> On Sun, 7 Mar 2021 19:54:54 +0100
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
> 
>> Hi Paul,
>> 
>>> Am 07.03.2021 um 19:22 schrieb Paul Boddie <paul at boddie.org.uk>:
>>> 
>>> On Sunday, 7 March 2021 18:11:42 CET H. Nikolaus Schaller wrote:  
>>>> 
>>>> Ah, I see. The legacy u-boot does neither support loading DTB nor is it able
>>>> to uncompress bigger uImages.  
>>> 
> Hmm, does the u-boot really uncompress images here?

AFAIR there is a flag in the uImage header. And AFAIR MIPS has no self-uncompress.

> letux_mipsbook_defconfig has CONFIG_KERNEL_GZIP=y. That looks like a
> self-compressed kernel.

That is for the second stage u-boot...

> Would be interesting to try with CONFIG_KERNEL_LZMA=y Well, it take a
> bit longer to decompress.

I think the legacy u-boot (from 2008 or so) does not even understand LZMA.
But there was IMHO another issue I do not remember.

> 
>>> I tried to configure the kernel to do something sensible with appended DTB 
>>> files, but that didn't make any difference.  
>> 
>> This didn't work either for me... And it makes the uncompress size limit even
>> a bigger problem.
>> 
> hmm, was the dtb appended correctly?

Yes. It worked if I removed most kernel modules from the uImage and the total
image became small enough.

> I think it has to be appended to
> the zImage and then a uImage has to be created out of that.

Yes. But if it is too big it remains too big :)

And with the chained u-boot we do not need appended DTBs any more which
is much easier to mix with other boards that don't have one as well.

Appended DTBs are only good if you have a defconfig and individual
uImage for every board. But generally they should be avoided.

There is of course another reason: there is no generic board so far
and we need to choose JZ4730 or JZ4780 explicitly. There is some code
in the tree but last time I checked it was not yet general enough.

If it were, we would only have a single letux_defconfig for everything,
like for ARM.

So at the moment the kernel build process and the result structure are
almost the same for CI20 and Letux 400. And the limitations of the legacy
u-boot (in NAND) are hidden completely by the second stage U-Boot on
the SD card.

From a kernel developer's view there is nothing special consideration
with the boot process.

IMHO here is no problem to be solved because it works when using makesd.
it is only not well documented for doing the same manually.

BR,
Nikolaus