linux-kernel - Re: [PATCH 4/4] ARM: multi_v7_defconfig: Switch AXP20x driver from module to built-in

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]

Date:   Tue, 13 Jun 2017 09:14:00 -0700
From:   Kevin Hilman <khilman@...libre.com>
To:     Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc:     Rask Ingemann Lambertsen <rask@...melder.dk>,
        Chen-Yu Tsai <wens@...e.org>,
        Russell King <linux@...linux.org.uk>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/4] ARM: multi_v7_defconfig: Switch AXP20x driver from module to built-in

Maxime Ripard <maxime.ripard@...e-electrons.com> writes:

> On Tue, Jun 06, 2017 at 12:45:17PM -0700, Kevin Hilman wrote:
>> On Mon, May 22, 2017 at 12:44 AM, Maxime Ripard
>> <maxime.ripard@...e-electrons.com> wrote:
>> > Hi Kevin,
>> >
>> > On Thu, May 18, 2017 at 11:59:50AM -0700, Kevin Hilman wrote:
>> >> On Fri, Mar 17, 2017 at 10:39 AM, Kevin Hilman <khilman@...libre.com> wrote:
>> >> > On Fri, Feb 10, 2017 at 12:42 AM, Maxime Ripard
>> >> > <maxime.ripard@...e-electrons.com> wrote:
>> >> >> On Wed, Feb 08, 2017 at 11:09:31PM +0100, Rask Ingemann Lambertsen wrote:
>> >> >>> The AXP20X regulator support is currently built as a module, which means
>> >> >>> it's not available until the root fs has been mounted, but the boot loader
>> >> >>> might not have enabled the required regulators, so build their drivers
>> >> >>> into the kernel.
>> >> >>>
>> >> >>> Signed-off-by: Rask Ingemann Lambertsen <rask@...melder.dk>
>> >> >>
>> >> >> Queued for 4.12.
>> >> >
>> >> > Hello, kernelci.org is reporting boot failures on sun5i-r8-chip in
>> >> > linux-next[1]  for a few days and with a variety of defconfigs. I
>> >> > bisected it[2] down to this patch.
>> >> >
>> >> > I verified that reverting this patch on top of next-20170310 makes my
>> >> > chip board boot again.
>> >>
>> >> FYI... this board is still broken in linux-next (and now in mainline),
>> >> and reverting $SUBJECT patch still makes it work.
>> >>
>> >> Is nobody else using mainline on this board?
>> >
>> > I thought about that during the weekend, and it might just be a
>> > symptom.
>> >
>> > The CHIP has brown out issues, especially when you enable the WiFi
>> > chip, which should happen around the time of the failure when the PMIC
>> > regulator support is compiled as a module.
>> >
>> > We mitigate that in upstream's U-Boot by enabling the two regulators
>> > for the WiFi chip in U-boot, which levels a bit the current over the
>> > boot.
>> >
>> > You have a few ways to prevent that from happening. Having a better
>> > power supply / cable will help, I'm not sure how reasonable that is.
>> >
>> > Another thing that can work is, if your USB plugs can take it, to
>> > increase the overcurrent trigger in the PMIC, ideally in U-Boot.
>> >
>> > The last, and probably cleaner one, would be to just power it through
>> > the 5v input on its header, and not the USB. There's not current
>> > limitation there, so it shouldn't cause any problems anymore.
>> 
>> I'm now powering the board via the header (5V to the CHG-IN pin) and
>> it doesn't change anything.  Still fails in the same way, and
>> reverting $SUBJECT defconfig patch makes it work again.
>
> I tried it today with sunxi_defconfig that has AXP20X_REGULATOR
> built-in as well. It can boot fine on my CHIP here.

What about multi_v7_defconfig?

> After looking at your failed boot example (1), I'm a bit
> puzzled. Where is supposed to be your filesystem?
>
> You have a ubi rootfs, but we don't have the NAND enabled in mainline,
> so that cannot work. And you seem to load an initramfs earlier in
> U-Boot, but you don't pass it is your bootz call.

Ah, I suppose that isn't terribly clear from the log.

My scripts don't rely on uboot for the ramdisk because because (believe
it or not) many vendor uboots don't enable the ATAGs for initrd in
uboot.

So, I modify the DT to add the linux,initrd-start and linux,initrd-end
properties to the chosen node poining to where the initrd is loaded in
memory.  This also avoids the need to add a uimage header to the ramdisk.

Kevin