[Letux-kernel] LX20 prototype is booting

H. Nikolaus Schaller hns at goldelico.com
Thu May 1 15:50:19 CEST 2025


Hi all,


> Am 30.04.2025 um 21:05 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> 
> It doesn't yet show timer activity but by drilling deeper into ingenic_ost_init() and
> ingenic_ost_probe() I have got an "Unable to request IRQ 4" for node ingenic,x2000-ost32
> 
> The reason is that there is an irq descriptor translated within __request_percpu_irq()
> but the condition
> 
> if (!desc || !irq_settings_can_request(desc) ||
>    !irq_settings_is_per_cpu_devid(desc))
> 
> (https://elixir.bootlin.com/linux/v6.15-rc4/source/kernel/irq/manage.c#L2608)
> fails. So something in the IRQ subsystem needs to be patched to make OST work...
> 
> 
> Maybe searching the code for (_)IRQ_PER_CPU_DEVID or (_)IRQ_NOREQUEST could give some
> hints where they are used specific to the x2000 and what differs between the kernels.

It turned out to be very difficult to trace what works and what doesn't.

Finally I hacked an ll_printk into dump_stack to see how irq_set_percpu_devid_flags()
is called in the sudmaker-6.1.28 kernel.

Maybe it would have been easier to not use some ll_printk() at all but hack the direct UART
transmission into standard printk() to make it independent of the printk buffers and uart drivers
working and console= and earlycon. Sort of private very low level console driver...

Anyways, I finally found what is missing: sudomaker comes with a patch called
"irqchip: Ingenic: Add percpu IRQ support for irq driver" which I had not forward-ported to the
Letux kernel. It does special checks for current_cpu_type() == CPU_XBURST2 to handle the x2000.

IMHO this is not the right way to detect that, but it now works beyond the boot blocking point :)

I did not think that we need such a patch since the jz4780 is also dual core and I had
simply assumed that everything is already there and the x2000 doesn't need special code
beyond a different dtsi.

So in summary I had to forward-port (and adjust a little to get it compiled):
- clocksource: Ingenic: Add SMP/SMT support for sysost driver
- irqchip: Ingenic: Add percpu IRQ support for irq driver.

Interestingly they say in the commit message that I have tested the second patch...
But likely they simply claimed authorship from the jz4780 series by Zhou Yanjie which I
had tested and they made their own modifications but did not update the commit message.

The resulting code is here:

	https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/work-x2000-sudomaker

Now I can boot up to:

schedule: start: task = 81855120 pid=12 cmd=kworker/u4:0
schedule: before sched_submit_work
schedule: after sched_submit_work
schedule: after __schedule_loop
schedule: after sched_update_worker
schedule: start: task = 81855fe0 pid=14 cmd=kworker/u4:1
schedule: before sched_submit_work
schedule: after sched_submit_work
schedule: after __schedule_loop
schedule: after sched_update_worker
__driver_attach: -> driver_probe_device
__driver_probe_device
really_probe: driver: gpio-keys
really_probe: re_probe
irq_domain_associate_locked: irq=31 hw=31
irq_domain_associate_locked: domain->ops->map=8052d6cc
irq_domain_associate_locked: ret=0
irq_domain_associate_locked: irq=28 hw=26
irq_domain_associate_locked: domain->ops->map=8052d6cc
irq_domain_associate_locked: ret=0

BTW: this is the same where the sudomaker kernel is finally stuck.
But with one lED being turned on (and not blinking).

So the status is:
+ we have an u-boot
	+ passes device tree and memory size
	+ uses UART2
	- is slow when reading µSD

+ we have a 6.15 based kernel + DTB
	+ initializes x2000 CPU
	+ initializes memory and interrupts
	+ initializes timers
	+ schedules kernel threads
	+ probes drivers
	- does not support UART2 as console/printk buffered output
	- is stuck when (or after) probing gpio-keys
	? can control LEDs (GPIOs)
	? can access µSD
	? boots to a login:
	? USB
	? second µSD

I think I need a break to reason about which of the topics to
tackle next (a working console/printk woould be nice to have, since
it helps debugging the other topics...).

BR,
Nikolaus



More information about the Letux-kernel mailing list