Messages in this thread | | | Date | Wed, 03 Apr 2024 15:51:28 +0200 | From | Dragan Simic <> | Subject | Re: Fixing the devicetree of Rock 5 Model B (and possibly others) |
| |
Hello Pratham,
On 2024-04-03 01:32, Pratham Patel wrote: > On Tue Apr 2, 2024 at 4:54 AM IST, Saravana Kannan wrote: >> On Sat, Mar 23, 2024 at 10:10 AM Dragan Simic <dsimic@manjaro.org> >> wrote: >> > On 2024-03-23 18:02, Pratham Patel wrote: >> > > I looked at the patch and tried several things, neither resulted in >> > > anything that would point me to the core issue. Then I tried this: >> > >> > Could you, please, clarify a bit what's the actual issue you're >> > experiencing on your Rock 5B? >> >> Pratham, can you reply to this please? I don't really understand what >> your issue is for me to be able to help. > > I apologize for not replying. Somehow, I did not notice the reply from > Dragan. :(
No worries, I saw the serial console log file in one of your messages, which actually provided the answer to my question. :)
> Since this patch was applied, an issue in the Rock 5B's DT has been > unearthed which now results in the kernel being unable to boot > properly. > > Following is the relevant call trace from the UART capture: > > [ 21.595068] Call trace: > [ 21.595288] smp_call_function_many_cond+0x174/0x5f8 > [ 21.595728] on_each_cpu_cond_mask+0x2c/0x40 > [ 21.596109] cpuidle_register_driver+0x294/0x318 > [ 21.596524] cpuidle_register+0x24/0x100 > [ 21.596875] psci_cpuidle_probe+0x2e4/0x490 > [ 21.597247] platform_probe+0x70/0xd0 > [ 21.597575] really_probe+0x18c/0x3d8 > [ 21.597905] __driver_probe_device+0x84/0x180 > [ 21.598294] driver_probe_device+0x44/0x120 > [ 21.598669] __device_attach_driver+0xc4/0x168 > [ 21.599063] bus_for_each_drv+0x8c/0xf0 > [ 21.599408] __device_attach+0xa4/0x1c0 > [ 21.599748] device_initial_probe+0x1c/0x30 > [ 21.600118] bus_probe_device+0xb4/0xc0 > [ 21.600462] device_add+0x68c/0x888 > [ 21.600775] platform_device_add+0x19c/0x270 > [ 21.601154] platform_device_register_full+0xdc/0x178 > [ 21.601602] psci_idle_init+0xa0/0xc8 > [ 21.601934] do_one_initcall+0x60/0x290 > [ 21.602275] kernel_init_freeable+0x20c/0x3e0 > [ 21.602664] kernel_init+0x2c/0x1f8 > [ 21.602979] ret_from_fork+0x10/0x20 > >> Also, can you give the output of <debugfs>/devices_deferred for the >> good vs bad case? > > I can't provide you with requested output from the bad case, since the > kernel never moves past this to an initramfs rescue shell, but > following > is the output from v6.8.1 (**with aforementioned patch reverted**). > > # cat /sys/kernel/debug/devices_deferred > fc400000.usb platform: wait for supplier /phy@fed90000/usb3-port > 1-0022 typec_fusb302: cannot register tcpm port > fc000000.usb platform: wait for supplier /phy@fed80000/usb3-port > > It seems that v6.8.2 works _without needing to revert the patch_. I > will > have to look into this sometime this week but it seems like > a8037ceb8964 (arm64: dts: rockchip: drop rockchip,trcm-sync-tx-only > from rk3588 i2s) > seems to be the one that fixed the root issue. I will have to test it > sometime later this week.
| |