Re: Fixing the devicetree of Rock 5 Model B (and possibly others)

[Pratham Patel]

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@manjaroorg> 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