linux-kernel - Re: ARM iMX6sx board fails to boot with kernel 6.17

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87a52afkxt.fsf@osv.gnss.ru>
Date: Wed, 01 Oct 2025 23:04:14 +0300
From: Sergey Organov <sorganov@...il.com>
To: Fabio Estevam <festevam@...il.com>
Cc: linux-kernel@...r.kernel.org,  Ulf Hansson <ulf.hansson@...aro.org>,
  Shawn Guo <shawnguo@...nel.org>,  "Rob Herring (Arm)" <robh@...nel.org>
Subject: Re: ARM iMX6sx board fails to boot with kernel 6.17

Hi Fabio,

Fabio Estevam <festevam@...il.com> writes:

> Hi Sergey,
>
> On Tue, Sep 30, 2025 at 12:49 PM Sergey Organov <sorganov@...il.com> wrote:
>>
>> Hello,
>>
>> I'm looking for help with the following issue.
>>
>> I'm trying to upgrade kernel on my custom iMX6sx board from very old
>> 4.9.146 to resent 6.17. The board has eMMC connected to usdhc4, and
>> u-boot happily starts kernel from eMMC. The kernel boot sequence,
>> however, hangs waiting for root file-system as it doesn't see eMMC.
>
> I tried booting 6.17 on an imx6sx-sdb board and it booted
> successfully:

Thank you so much for checking! I think I'll try to compare my build to
this one, as I still have no other idea how to debug my problem. Could
you please send me resulting DTB file as well so that I can check my
build system against yours?

That said,

> Starting kernel ...

[...]

> [    0.032394] /soc/bus@...0000/clock-controller@...4000: Fixed
> dependency cycle(s) with /soc/bus@...0000/gpc@...c000
> [    0.032536] /soc/bus@...0000/gpc@...c000: Fixed dependency cycle(s)
> with /soc/bus@...0000/clock-controller@...4000
> [    0.034758] /soc/bus@...0000/clock-controller@...4000: Fixed
> dependency cycle(s) with /soc/bus@...0000/gpc@...c000
> [    0.034894] /soc/bus@...0000/gpc@...c000: Fixed dependency cycle(s)
> with /soc/bus@...0000/clock-controller@...4000
> [    0.045375] /soc/bus@...0000/gpc@...c000: Fixed dependency cycle(s)
> with /soc/bus@...0000/clock-controller@...4000
> [    0.057574] /soc/bus@...0000/spba-bus@...0000/lcdif@...0000: Fixed
> dependency cycle(s) with /panel
> [    0.057688] /panel: Fixed dependency cycle(s) with
> /soc/bus@...0000/spba-bus@...0000/lcdif@...0000

You have these cycles as well. Is it expected? I fail to see why gpc and
clock-controller end-up being mutually dependent. Besides, they are not
mutually dependent in the hardware, or are they?

I also have a few more doubts about imx6sx.dtsi:

1. Documentation/usage-model.rst suggests "interrupt-parent = <&intc>;"
to be root node property, not of /soc as in imx6sx.dtsi. Is this
essential?

2. intc: in imx6sx.dtsi is interrupt-parent of itself? If it needs to
be, this asks for an explanation in a comment?

                intc: interrupt-controller@...000 {                                                          
                        compatible = "arm,cortex-a9-gic";                                                    
                        #interrupt-cells = <3>;                                                              
                        interrupt-controller;                                                                
                        reg = <0x00a01000 0x1000>,                                                           
                              <0x00a00100 0x100>;                                                            
                        interrupt-parent = <&intc>;                                                          
                };                                                                                           

3. Some nodes have <&intc>, and some <&gpc> as interrupt-parent. Could
somebody please re-check if it makes sense? Besides, "gpc" is not true
interrupt controller, right?

Thanks,
-- Sergey Organov