Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1662983 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 4/4] ARM: multi_v7_defconfig: Switch AXP20x driver from  module to built-in Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-06-10 18:20 +0200
    Re: [PATCH 4/4] ARM: multi_v7_defconfig: Switch AXP20x driver from module to built-in Kevin Hilman <khilman@baylibre.com> - 2017-06-13 18:20 +0200
      Re: [PATCH 4/4] ARM: multi_v7_defconfig: Switch AXP20x driver from  module to built-in Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-06-14 09:10 +0200

#1662983 — Re: [PATCH 4/4] ARM: multi_v7_defconfig: Switch AXP20x driver from module to built-in

[Multipart message — attachments visible in raw view] — view raw

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@free-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@baylibre.com> wrote:
> >> > On Fri, Feb 10, 2017 at 12:42 AM, Maxime Ripard
> >> > <maxime.ripard@free-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@formelder.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.

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.

Maxime

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

[toc] | [next] | [standalone]

#1664986 — Re: [PATCH 4/4] ARM: multi_v7_defconfig: Switch AXP20x driver from module to built-in

Maxime Ripard <maxime.ripard@free-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@free-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@baylibre.com> wrote:
>> >> > On Fri, Feb 10, 2017 at 12:42 AM, Maxime Ripard
>> >> > <maxime.ripard@free-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@formelder.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

[toc] | [prev] | [next] | [standalone]

#1665492

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jun 13, 2017 at 09:14:00AM -0700, Kevin Hilman wrote:
> Maxime Ripard <maxime.ripard@free-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@free-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@baylibre.com> wrote:
> >> >> > On Fri, Feb 10, 2017 at 12:42 AM, Maxime Ripard
> >> >> > <maxime.ripard@free-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@formelder.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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web