lkml.org 
[lkml]   [2024]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Fixing the devicetree of Rock 5 Model B (and possibly others)
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@thefossguy.com> 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


\
 
 \ /
  Last update: 2024-04-03 03:03    [W:1.306 / U:0.632 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site