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

[Lubomir Rintel]

On Fri, Nov 27, 2020 at 01:45:43PM +0100, H. Nikolaus Schaller wrote:
> 
> > Am 27.11.2020 um 13:41 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> > 
> > Hi Lubomir,
> > 
> >> Am 27.11.2020 um 04:13 schrieb Lubomir Rintel <lkundrak at v3.sk>:
> >> 
> >> On Thu, Nov 26, 2020 at 11:22:56PM +0100, Paul Boddie wrote:
> >>> On Thursday, 26 November 2020 20:06:12 CET H. Nikolaus Schaller wrote:
> >>>> Hi Paul and Lubomir,
> >>>> 
> >>>>> 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.
> >>> 
> >>> One thing that may be different, at least when you can monitor the log, is the 
> >>> following line:
> >>> 
> >>> [    0.000000] timer_probe: no matching timers found
> >>> 
> >>> Then again, searching for any reports about this leaves me unconvinced that it 
> >>> might be a problem. In Lubomir's log output, the next line is this...
> >>> 
> >>> [    0.000000] sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps 
> >>> every 21474836475000000ns
> >>> 
> >>> Maybe this indicates that the lack of timer assignments won't be a problem 
> >>> because scheduling is done using other timers.
> >> 
> >> Thank you. With a little more patching I got a more respectable panic
> >> now. I'll follow up with the patches.
> >> 
> >> The configuration [1] and dmesg [2] are here:
> >> 
> >> [1] https://people.freedesktop.org/~lkundrak/jz4730/config-20201127.txt
> > 
> > I have tried your config and found some issue in my wrapper script.
> > But still no dmesg or anything besides "Starting Kernel..." from U-Boot.
> > 
> > 5218787 bytes read
> > ## Booting image at 80600000 ...
> >   Image Name:   Linux-5.10.0-rc5+
> >   Image Type:   MIPS Linux Kernel Image (gzip compressed)
> >   Data Size:    5218723 Bytes =  5 MB
> >   Load Address: 80100000
> >   Entry Point:  8053f5b4
> >   Verifying Checksum ... OK
> >   Uncompressing Kernel Image ... OK
> > 
> > Starting kernel ...
> > 
> > What I have not yet tried is to apply your latest set of patches.
> > 
> >> [2] https://people.freedesktop.org/~lkundrak/jz4730/dmesg-20201127.txt
> > 
> > Yours isn't much different:
> > 
> > Bytes transferred = 2849103 (2b794f hex)
> > ## Booting kernel from Legacy Image at 81000000 ...
> >   Image Name:   Linux-5.9.0-rc1-letux-l400+
> >   Image Type:   MIPS Linux Kernel Image (gzip compressed)
> >   Data Size:    2849039 Bytes = 2.7 MiB
> >   Load Address: 80100000
> >   Entry Point:  80523aa0
> >   Verifying Checksum ... OK
> >   Uncompressing Kernel Image
> > [    0.000000] Linux version 5.10.0-rc4+ (lkundrak at demiurge.local) (mips64-linux-gnu-gcc (GCC) 10.2.1 
> > 
> > Now I wonder how we come to so much different kernel image sizes.
> 
> Maybe can you send me your uImage binary for comparison and trying to boot that one?

Yes. Here's a branch [1] you've requested elsewhere in this thread, with
the last commit containing the build script and a built uImage:

  git pull git://git.kernel.org/pub/scm/linux/kernel/git/lkundrak/linux.git lr/alpha400-for-nicholas

[1] https://git.kernel.org/pub/scm/linux/kernel/git/lkundrak/linux.git/log/?h=lr/alpha400-for-nicholas

Lubo

> 
> > 
> >> 
> >> 1.) I'm using clk_ignore_unused because disabling of the dma clock seems
> >>   to make the cpu grind to a halt (not even jtag works at that point).
> >>   Also, if dma clock is kept enabled, disabling of some other clock
> >>   (no idea which one yet) makes things go very slow.
> >> 
> >> 2.) I'm using clocksource=jiffies because switch to ingenic-timer makes
> >>   the scheduler clock poll callback not fire and thus the clock ends
> >>   up loop aroud in 65535 ticks.
> >> 
> >> 3.) The scheduler clock poll doesn't probably run often enough because
> >>   the clock seems overflow and go backwards sometimes.
> >> 
> >> 4.) Some errors in LCD and DMA DT notes are now apparent and the MMC
> >>   doesn't work. I guess there might be more driver issues.
> >> 
> >> I'll be looking into above as time permits, but would be thankful for
> >> hints.
> > 
> > Well, as long as I don't see a dmesg I can't help much...
> > 
> > BR,
> > Nikolaus
> > 
>