[Letux-kernel] [PATCH 00/20] A bunch of JZ4730 fixups for letux-kernel

[H. Nikolaus Schaller]

Hi Paul and Lubomir,

> Am 20.11.2020 um 22:15 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> On Friday, 20 November 2020 09:03:15 CET H. Nikolaus Schaller wrote:
>> Hi Paul,
>> 
>>> Am 20.11.2020 um 00:08 schrieb Paul Boddie <paul at boddie.org.uk>:
>>> 
>>> On Wednesday, 18 November 2020 22:04:15 CET Lubomir Rintel wrote:
>>>> Sure. I'm not sure if I made it clear enough though: it doesn't really
>>>> boot -- it gets stuck early because the timer tick is not hooked on.
>>>> It just thought it's a good idea to share what I got as soon as I got
>>>> some output.
>>> 
>>> Following on from my previous mail about timers, there are a couple of
>>> places where they have not been declared, specifically...
>>> 
>>> drivers/clocksource/ingenic-timer.c
>>> drivers/irqchip/irq-ingenic-tcu.c
>>> 
>>> So, I have attached a patch that adds declarations for the JZ4730. Maybe
>>> the dynamic configuration mechanisms will take notice of the timers with
>>> this patch applied.
>>> 
>>> Paul<tcu-20201120.diff>
>> 
>> can you please provide a .patch (e.g. git format-patch NEAD^..HEAD)?
>> This adds description, signed off etc. and is easier to git apply.
> 
> It is now attached.
> 
> Paul<0001-Added-missing-TCU-declarations-for-the-JZ4730.patch>

a little late but you still deserve many thanks!

I have added it but see no difference. I just see Starting Kernel... and then some watchdog
reboots.

What I have done to do some verifications was to try to rebuild our old 2.6.24 kernel [1].

It was not a trivial task because the tree was
a) not based on kernel.org git
b) has some code that could not be compiled with a modern gcc:
 - the most problematic was clear_page() and copy_page()
 - there were problems with 64 bit division
 - modern compilers break with error unless some variables are tagged __maybe_unused
c) my build wrapper asked for makefile targets and features that did not exist (e.g. savedefconfig).

So after fixing these things I could compile and get an uImage [2].

This did initially show the same "Starting Kernel... and then some watchdog reboot".

Next I compared with the old archived kernel uImage [3].

It turned out that the LOADADDR was different. All my builds for CI20 and different
kinds of ARM processors use 0x80008000. But the old build used 0x80010000. And interestingly,
I could boot the newly built old kernel after changing it.

It also did only show  "Starting Kernel..." on the serial console. Bit it did initialize
the frame buffer console and there the boot log continues. Until the kernel panics because
it seems not to find some init process. So this means that my build setup is basically
capable of building a working kernel...

Question: what is the ttyS number for the uart console? Maybe I can change it for the 2.6
kernel.

Unfortunately,for the 5.10 kernel changing the LOADADDR makes no difference.

Questions:
- how do I properly enable and setup earlycon?
- can I check if the appended device tree is found or being loaded (without JTAG)?
- would it help to enable kdb? According to https://elinux.org/KDB#At_boot_time_.28via_kernel_command_line.29 it
should be possible to add a kernel command line option.
- potentially through CONFIG_CMDLINE?

BR and thanks,
Nikolaus

[1]: https://git.goldelico.com/?p=letux-400.git;a=shortlog;h=refs/heads/master
[2]: https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/l400-2.6
[3]: https://download.goldelico.com/letux-400/20110208-lenny400/