Re: ARM iMX6sx board fails to boot with kernel 6.17

[Sergey Organov <sorganov@gmail.com>]

Hi Fabio,

Sergey Organov <sorganov@gmail.com> writes:

> Hi Fabio,
>
> Fabio Estevam <festevam@gmail.com> writes:
>
>> Hi Sergey,
>>
>> On Sat, Oct 11, 2025 at 5:57 PM Sergey Organov <sorganov@gmail.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@a01000 {                                                          
                        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@2000000/clock-controller@20c4000: Fixed dependency cycle(s) with /soc/bus@2000000/gpc@20dc000
/soc/bus@2000000/gpc@20dc000: Fixed dependency cycle(s) with /soc/bus@2000000/clock-controller@20c4000
/soc/bus@2000000/clock-controller@20c4000: Fixed dependency cycle(s) with /soc/bus@2000000/gpc@20dc000
/soc/bus@2000000/gpc@20dc000: Fixed dependency cycle(s) with /soc/bus@2000000/clock-controller@20c4000
/soc/bus@2000000/gpc@20dc000: Fixed dependency cycle(s) with /soc/bus@2000000/clock-controller@20c4000

Are they to better be manually fixed?

Thanks,
-- Sergey Organov