[Letux-kernel] jz4730-i2c - clocksource

[Paul Boddie]

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.

I tried to configure the kernel to do something sensible with appended DTB 
files, but that didn't make any difference.

> This is why I use the two-staged approach where legacy u-boot loads the
> new u-boot by Ludomir which then can do everything. Loading bootargs.scr
> is done by a boot.scr that I provide.
> 
> I think this is the reason why I have named it "Image". Because
> legacy-u-boot has hard-coded to load an "uImage". So the second phase
> u-boot is called "uImage" and that it does not try to load itself the
> kernel is named "Image".

That would make sense. How do you build U-Boot for SD card deployment? I only 
see a configuration for NAND:

configs/alpha400_nand_defconfig

[...]

> Ah, sorry.
> 
> That was an older /boot without having mounted the FAT
> partition. The FAT partition looks like:
> 
> root at letux:~# ls -lR /boot
> /boot:
> total 5880
> -rwxr-xr-x 1 root root 5233921 Mar  7  2021 Image
> -rwxr-xr-x 1 root root      79 Mar  7  2021 Image.info
> -rwxr-xr-x 1 root root    2156 Jan 31  2021 boot.scr
> -rwxr-xr-x 1 root root    2108 Mar  7  2021 bootargs.scr
> drwxr-xr-x 2 root root    8192 Mar  7  2021 ingenic
> -rwxr-xr-x 1 root root     843 Jan 31  2021 makesd.info
> -rwxr-xr-x 1 root root  500979 Jan 31  2021 u-boot.bin
> -rwxr-xr-x 1 root root  234810 Jan 31  2021 uImage

OK, this makes more sense now.

> /boot/ingenic:
> total 16
> -rwxr-xr-x 1 root root 12078 Mar  7  2021 alpha400.dtb
> root at letux:~#
> 
> here we see that both, uImage and Image exist plus
> the u-boot.bin for the second phase U-Boot.
> 
> And I have a boot.scr (for the second phase u-boot)
> which loads DTB and Image and runs bootargs.scr before
> starting the kernel:
> 
> 	https://download.goldelico.com/letux-u-boot/Mipsbook400/latest/

I guess I could use the CONFIG provided here to reproduce the build.

> I have developed that once last year and the boot process
> is a "never touch a running system unless absolutely necessary"
> thing for me :)

Sure. That is why I had been hoping to use the existing U-Boot, which I guess 
I still can, but now with another U-Boot to actually load the kernel.

> What you can also see is that my installation process
> has updated Image (+.info), bootargs.scr and ingenic/alpha400.dtb
> from my kernel build today. The others are untouched.
> 
> Hope this is helpful.

Yes, thanks.

Paul