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 for Android: free password hash cracker in your pocket

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

Message-ID: <20170614070712.yos54lelz5adrlq6@flea.lan>
Date:   Wed, 14 Jun 2017 09:07:12 +0200
From:   Maxime Ripard <maxime.ripard@...e-electrons.com>
To:     Kevin Hilman <khilman@...libre.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

On Tue, Jun 13, 2017 at 09:14:00AM -0700, Kevin Hilman wrote:
> 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?

It seems to work in our farm.

It's lagging behind at the moment, so it hasn't been published yet,
but here is the last multi_v7 boot.
http://code.bulix.org/a43kkf-147625?raw

> > 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.

Ok, good :)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)