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] [day] [month] [year] [list]

Message-ID: <87v7k06ppg.fsf@osv.gnss.ru>
Date: Mon, 27 Oct 2025 17:39:59 +0300
From: Sergey Organov <sorganov@...il.com>
To: Fabio Estevam <festevam@...il.com>
Cc: linux-kernel@...r.kernel.org,  Russell King <linux@...linux.org.uk>,
  Ulf Hansson <ulf.hansson@...aro.org>,  Shawn Guo <shawnguo@...nel.org>,
  "Rob Herring (Arm)" <robh@...nel.org>,  Angelo Dureghello
 <angelo@...nel-space.org>
Subject: Re: ARM iMX6sx board fails to boot with kernel 6.17

Hi Fabio,

Sergey Organov <sorganov@...il.com> writes:

> Hi Fabio,
>
> Fabio Estevam <festevam@...il.com> writes:
>
>> Hi Sergey,
>>
>> On Sat, Oct 11, 2025 at 5:57 PM Sergey Organov <sorganov@...il.com>
>> wrote:
>>
>>> I'm not familiar with the code and can't figure what exactly I'm
>>> expected to check. Could you please prepare a patch, and I'll be
>>> happy to apply and check it.
>>
>> Here is a patch you can try.
>>
>> It's not a formal patch yet, as it needs to be split.
>
> No, this patch doesn't help.

[...]

> I'm going to dig into imx_4.9.11_1.0.0_ga branch again more carefully to
> try to figure what's going on, and what actually either fixes or
> work-arounds the problem at hand.

Well, that activity ended up being almost useless. Even though I've
found yet another patch that "fixes" the build for my board in
imx_4.9.11_1.0.0_ga branch, it happens to cure neither latest mainstream
kernel nor NXP lf-6.12.y branch.

For reference, the patch is:

https://github.com/nxp-imx/linux-imx/commit/fe3aca041b0b8042d59bcf1d9169109c9220e783

I figure the only sensible option that is left is to try to actually
debug the issue on my board using either the latest mainstream kernel,
or lf-6.12.y by NXP (which one is more promising BTW?), but right
now I have no idea where to start. Any hints?

Also, could you please comment on the issues I've raised earlier, to help
me better understand the state of iMX6SX support:

1. Documentation/usage-model.rst suggests "interrupt-parent = <&intc>;"
to be root node property, not of /soc as in imx6sx.dtsi. Is this
essential? Anyway, shouldn't either documentation or implementation be
fixed to agree on this?

2. intc: in imx6sx.dtsi is interrupt-parent of itself? Is it a mistake?
If not, 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, so what's the matter of having it as
interrupt-parent for some nodes?

4. Suspect cycles in DTS:

/soc/bus@...0000/clock-controller@...4000: Fixed dependency cycle(s) with /soc/bus@...0000/gpc@...c000
/soc/bus@...0000/gpc@...c000: Fixed dependency cycle(s) with /soc/bus@...0000/clock-controller@...4000
/soc/bus@...0000/clock-controller@...4000: Fixed dependency cycle(s) with /soc/bus@...0000/gpc@...c000
/soc/bus@...0000/gpc@...c000: Fixed dependency cycle(s) with /soc/bus@...0000/clock-controller@...4000
/soc/bus@...0000/gpc@...c000: Fixed dependency cycle(s) with /soc/bus@...0000/clock-controller@...4000

Are they to better be manually fixed?

Thanks,
-- Sergey Organov