On Wed Apr 3, 2024 at 6:16 AM IST, Saravana Kannan wrote: > On Tue, Apr 2, 2024 at 4:32 PM Pratham Patel > <prathampatel@xxxxxxxxxxxxxx> 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@xxxxxxxxxxx> wrote: > > > > > > > > Hello Pratham, > > > > > > > > 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. > > > > Hi, > > > > I apologize for not replying. Somehow, I did not notice the reply from > > Dragan. :( > > > > 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 > > This doesn't make a lot of sense. "remote-endpoint" shouldn't be > related to anything to do with psci cpuidle. I'm guessing something > else is failing much earlier in boot that's indirectly causing this > somehow? Can you please take a look at what's failing earlier and let > us know? Or see what driver probe is failing up to this point but used > to work in the good case. I'm pretty new to this, "just starting". I'm not sure how to do that, since the kernel doesn't really "move forward". I will verify if a8037ceb8964 fixes it or not and get back by the end of this week. > Also, where is the dts file that corresponds to this board in upstream? Is it > arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts Yes. > > > > > 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. > > Ok, once you find the patch that fixes things, let me know too. Will do! -- Pratham Patel
