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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87zfa1z5ob.fsf@osv.gnss.ru>
Date: Wed, 08 Oct 2025 20:04:04 +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

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

> Hi Sergey,
>
> On Tue, Oct 7, 2025 at 6:17 PM Sergey Organov <sorganov@...il.com> wrote:
>>
>> Please see attached minimum DTS. Maybe it misses something? Shouldn't
>> DTS describe how eMMC chip is powered, provided it's powered from NXP
>> MMPF0100F6ANES PMIC? I didn't find any hints in other DTS'es.
>
> Yes, the dts should describe the eMMC power supplies.
>
> The properties are: vmmc-supply and vqmmc-supply.
>
> Check arch/arm/boot/dts/nxp/imx/imx6qdl-colibri.dtsi for reference.

This uses:

        pmic: pmic@8 {                                                                                
                compatible = "fsl,pfuze100";                                                          

that doesn't look like the one I need, and I don't see anything among
Documentation/devicetree/bindings/regulator/* for the NXP MMPF0100F6ANES
PMIC that is used on my board.

Does it mean that this regulator is unsupported? If so, doesn't it mean
that kernel simply won't touch it, and thus it can't be the cause of the
hang?

Anyway, I added naive fixed regulators (see attached modified DTS), but
it didn't change the outcome.

>
>> The point of hang is not entirely deterministic either, that suggests
>> it's some power problem indeed. It may hang after random line among the
>> following depending on exact build and sometimes even from run-to-run:
>>
>> ...
>> mmc0: SDHCI controller on 219c000.mmc [219c000.mmc] using ADMA
>> Loading compiled-in X.509 certificates
>> clk: Disabling unused clocks
>> PM: genpd: Disabling unused power domains
>
> Does it hang if you pass "pm_genpd_ignore_unused" and
> "clk_ignore_unused" in the kernel command line?

Yep, it still hangs (it's pd_ignore_unused, not pm_genpd_ignore_unused,
btw):

clk: Not disabling unused clocks                   
PM: genpd: Not disabling unused power domains      
check access for rdinit=/init failed: -2, ignoring 
Waiting for root device /dev/mmcblk0p3...

and I recall I've already tried it first thing to disable this right in
the code to no avail either.

>
>> check access for rdinit=/init failed: -2, ignoring
>> Waiting for root device /dev/mmcblk0p2...
>>
>> Also, I just tried to compile entire kernel with -DDEBUG, and it starts
>> to see the eMMC, though still hangs not ever mounting the root FS:
>
> I saw Ulf's response about a potential regression in 6.17.
>
> Do you see the hang with 6.16?

Yep, 6.16 still hangs for me the same way.

-- Sergey Organov


View attachment "javad-minimum.dts" of type "text/plain" (1918 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ