[Letux-kernel] jz4780 CI20 v5.8 (was jz4730)

H. Nikolaus Schaller hns at goldelico.com
Sun Jul 5 19:35:03 CEST 2020

Hi Paul,

> Am 05.07.2020 um 19:11 schrieb Paul Boddie <paul at boddie.org.uk>:
> On Sunday, 5 July 2020 17:41:53 CEST H. Nikolaus Schaller wrote:
>>> Am 05.07.2020 um 16:17 schrieb Paul Boddie <paul at boddie.org.uk>:
>>> Replying to this again specifically, I found that the DRM/HDMI patches
>>> based on letux-5.8-rc3 will not yield a bootable kernel, but by disabling
>>> SMP in the configuration it would boot.
>> I already had this idea, but haven't tried.
>> So the SMP patches are no longer compatible. I have to check if the original
>> author has submitted something new or if we can backport something from
>> linux-next (if it is there).
>> Otherwise we should ask the LKML about the status of merging JZ4780 SMP
>> support.
> I might have a look at the relevant code, but it would involve some study 
> first.

I think I have it here:


It looks as if I have applied some compile issue fix. But that may be wrong.

Other ideas: the hight resolution timer may be broken.

There may also be a general MIPS bug wich has been fixed/accepted for mips-fixes:

"[PATCH] MIPS: Do not use smp_processor_id() in preemptible code"

BTW: interesting is also a proposed "[PATCH] MIPS: CI20: DTS: Correcting IW8103 Wifi binding"

>>> So that is probably a significant factor.
>>> Unfortunately, I did not manage to get a usable signal via HDMI ("Input
>>> not supported"), but the DRM driver is operational.
>> So we are not worse than before :)
> Not really, no. All I can say is that with the extra setting of the bus format 
> in the HDMI driver, vblank interrupts are produced and serviced by the DRM 
> driver.
>>> One strange complication I now
>>> get when I unplug the HDMI cable (to get my monitor to switch back to the
>>> VGA input, since the menu won't respond) is this kernel panic:
>>> CPU 0 Unable to handle kernel paging request at virtual address 00000030,
>>> epc == c025ee10, ra == c022fc08
>>> ingenic_drm_crtc_atomic_flush+0x8c/0x3ac [ingenic_drm]
>>> drm_atomic_helper_commit_planes+0x254/0x25c [drm_kms_helper]
>>> drm_atomic_helper_commit_tail+0x44/0xb0 [drm_kms_helper]
>>> commit_tail+0x1f0/0x1f8 [drm_kms_helper]
>>> drm_atomic_helper_commit+0x17c/0x184 [drm_kms_helper]
>>> drm_client_modeset_commit_atomic+0xdc/0x2a8 [drm]
>>> drm_client_modeset_commit_locked+0x6c/0x1b8 [drm]
>>> drm_client_modeset_commit+0x44/0x74 [drm]
>>> __drm_fb_helper_restore_fbdev_mode_unlocked+0x74/0xd8 [drm_kms_helper]
>>> drm_fb_helper_set_par+0x74/0x84 [drm_kms_helper]
>>> drm_fb_helper_hotplug_event+0x170/0x190 [drm_kms_helper]
>>> drm_kms_helper_hotplug_event+0x34/0x50 [drm_kms_helper]
>>> drm_helper_hpd_irq_event+0xcc/0x1a0 [drm_kms_helper]
>>> dw_hdmi_irq+0x12c/0x178 [dw_hdmi]
>>> irq_thread_fn+0x2c/0x6c
>>> irq_thread+0xe4/0x204
>>> kthread+0x148/0x150
>>> ret_from_kernel_thread+0x14/0x1c
>>> So, upon receiving the hotplug event (in dw_hdmi_irq), the attempt to
>>> configure the LCD controller fails (in ingenic_drm_crtc_atomic_flush) due
>>> to an inappropriate access.
>> Ok, that should be possible to identify. Maybe an uninitialized or
>> overwritten variable.
> It happens only when unplugging, in fact. So, maybe some state is thrown away 
> and then the DRM system tries to update the missing state.

Yes, could be a simple free before use issue.
>> Do you have your code in some git repo?
> I have a clone of the letux-kernel repository with my code on a branch from 
> origin/letux-5.8-rc3. So if I might push that somewhere, you would get to see 
> it.

Great. I think it looks as if you are registered at https://projects.goldelico.com/p/gta04-kernel/
as member of the "Happy Crew". So you should already be able to push (if you
have ssh://_git@git.goldelico.com/letux-kernel.git as your remote).

Please choose a unique branch name like "paulb-jz4780-hdmi" or similar.

>>> One positive observation is that shutdown appears to power the device off.
>> Yes, we made this working a while ago. Only reboot failed if I remember
>> correctly. Or was it vice versa?
> We struggled with power off but it seems to be happy now. The RTC is not set, 
> but maybe the driver for the PCF8563 isn't getting activated correctly.
>>> One negative observation is that networking doesn't seem to work any more,
>>> although this might be a user space incompatibility.
>> Yes, I have seen that as well. In general the CI20 is quite broken by
>> v5.8-rc...
> Maybe there is a simple remedy, but again, I'd need to study the situation 
> first.
>> And I am still hunting upstream induced display problems on several
>> devices. The first I fixed was the Letux 3704. Next I fixed the PinePhone.
>> And the Pyra omapdrm doesn't work since v5.7-rc1. I already found one
>> issue coming from upstream.
>> So the CI20 is still waiting in the to-be-serviced queue...
> Well, I thought I'd keep you updated. If you enable pushing to the letux-
> kernel repository or have another suggestion, I can share my patches without 
> problems applying them.

Should already be possible - unless something is broken (e.g. ssh key lost).
If not, please try to debug ssh with GIT_TRACE_true as described here:



More information about the Letux-kernel mailing list