| Message ID | 49ad3e66452bd78da7b9e581129f76633c56e609.1486590875.git.rask@formelder.dk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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. Thanks! Maxime
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. Kevin [1] https://kernelci.org/boot/id/58c2426759b5144a68645535/ [2] $ git bisect log git bisect start # good: [144c7666b535aa5d402bf37db84df90aebf1f563] Merge tag 'pci-v4.11-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git\ /helgaas/pci git bisect good 144c7666b535aa5d402bf37db84df90aebf1f563 # bad: [5be4921c9958ec02a67506bd6f7a52fce663c201] Add linux-next specific files for 20170310 git bisect bad 5be4921c9958ec02a67506bd6f7a52fce663c201 # good: [ea6200e84182989a3cce9687cf79a23ac44ec4db] Merge branch 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/ker\ nel/git/tip/tip git bisect good ea6200e84182989a3cce9687cf79a23ac44ec4db # good: [3bd7db63a841e8c5297bb18ad801df67d5e38ad2] PCI/ASPM: Always set link->downstream to avoid NULL dereference on remove git bisect good 3bd7db63a841e8c5297bb18ad801df67d5e38ad2 # good: [8c71fff434e5ecf5ff27bd61db1bc9ac4c2b2a1b] [media] v4l: vsp1: Adapt vsp1_du_setup_lif() interface to use a structure git bisect good 8c71fff434e5ecf5ff27bd61db1bc9ac4c2b2a1b # good: [d825adb48cf9bf9e3f5cb1d927e2827f8c2abee4] xenbus: Remove duplicate inclusion of linux/init.h git bisect good d825adb48cf9bf9e3f5cb1d927e2827f8c2abee4 # good: [b600dc879ee45d52a4d4c50c4efb9c0f63495284] Merge remote-tracking branch 'drm/drm-next' git bisect good b600dc879ee45d52a4d4c50c4efb9c0f63495284 # bad: [8004c75027be90f2f1b2956f99b2709aa78a8fdb] Merge remote-tracking branch 'extcon/extcon-next' git bisect bad 8004c75027be90f2f1b2956f99b2709aa78a8fdb # bad: [e04b073635205c983891d0d70fb854c7b1871d89] Merge remote-tracking branch 'input/next' git bisect bad e04b073635205c983891d0d70fb854c7b1871d89 # bad: [d1ae62f438f26ecf256e5e4dd7cb53884c7dd3ab] Merge remote-tracking branch 'sunxi/sunxi/for-next' git bisect bad d1ae62f438f26ecf256e5e4dd7cb53884c7dd3ab # good: [5956fb6486d7bd2467fe6282a784af4f1cf67bef] Merge remote-tracking branch 'drm-misc/for-linux-next' git bisect good 5956fb6486d7bd2467fe6282a784af4f1cf67bef # good: [a0a68fb6872f545acd49035ea17c52a9f30d07dc] drm/sun4i: Pass pointer for underlying backend into layer init git bisect good a0a68fb6872f545acd49035ea17c52a9f30d07dc # good: [7d55034799cdc9945ce7975d690f944575376e34] ARM: dts: sunxi: Remove no longer used pinctrl/sun4i-a10.h header git bisect good 7d55034799cdc9945ce7975d690f944575376e34 # bad: [681cc0445e24fe5cb4e7de960947443de592621c] Merge branches 'sunxi/clk-for-4.12', 'sunxi/core-for-4.12', 'sunxi/defconfig-fo\ r-4.12', 'sunxi/drm-for-4.12' and 'sunxi/dt-for-4.12' into sunxi/for-next git bisect bad 681cc0445e24fe5cb4e7de960947443de592621c # good: [b0f0daa8fe9e74b85f6360288d38224ad1c2f2f4] clk: sunxi-ng: sun5i: Fix mux width for csi clock git bisect good b0f0daa8fe9e74b85f6360288d38224ad1c2f2f4 # bad: [7cae7ef89e360cd3dc139eaac2f480c25bc7bfa1] ARM: multi_v7_defconfig: Switch AXP20x driver from module to built-in git bisect bad 7cae7ef89e360cd3dc139eaac2f480c25bc7bfa1 # good: [5741e07b465d32458945d363ce87c0e2b7fd028d] ARM: multi_v7_defconfig: Switch sunxi RSB driver from module to built-in git bisect good 5741e07b465d32458945d363ce87c0e2b7fd028d # good: [f48a203cc44f26921f05911c047db49d2864c797] ARM: multi_v7_defconfig: Enable AC100 RTC driver git bisect good f48a203cc44f26921f05911c047db49d2864c797 # first bad commit: [7cae7ef89e360cd3dc139eaac2f480c25bc7bfa1] ARM: multi_v7_defconfig: Switch AXP20x driver from module to built\ -in
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? Kevin > [1] https://kernelci.org/boot/id/58c2426759b5144a68645535/ > [2] > $ git bisect log > git bisect start > # good: [144c7666b535aa5d402bf37db84df90aebf1f563] Merge tag > 'pci-v4.11-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git\ > /helgaas/pci > git bisect good 144c7666b535aa5d402bf37db84df90aebf1f563 > # bad: [5be4921c9958ec02a67506bd6f7a52fce663c201] Add linux-next > specific files for 20170310 > git bisect bad 5be4921c9958ec02a67506bd6f7a52fce663c201 > # good: [ea6200e84182989a3cce9687cf79a23ac44ec4db] Merge branch > 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/ker\ > nel/git/tip/tip > git bisect good ea6200e84182989a3cce9687cf79a23ac44ec4db > # good: [3bd7db63a841e8c5297bb18ad801df67d5e38ad2] PCI/ASPM: Always > set link->downstream to avoid NULL dereference on remove > git bisect good 3bd7db63a841e8c5297bb18ad801df67d5e38ad2 > # good: [8c71fff434e5ecf5ff27bd61db1bc9ac4c2b2a1b] [media] v4l: vsp1: > Adapt vsp1_du_setup_lif() interface to use a structure > git bisect good 8c71fff434e5ecf5ff27bd61db1bc9ac4c2b2a1b > # good: [d825adb48cf9bf9e3f5cb1d927e2827f8c2abee4] xenbus: Remove > duplicate inclusion of linux/init.h > git bisect good d825adb48cf9bf9e3f5cb1d927e2827f8c2abee4 > # good: [b600dc879ee45d52a4d4c50c4efb9c0f63495284] Merge > remote-tracking branch 'drm/drm-next' > git bisect good b600dc879ee45d52a4d4c50c4efb9c0f63495284 > # bad: [8004c75027be90f2f1b2956f99b2709aa78a8fdb] Merge > remote-tracking branch 'extcon/extcon-next' > git bisect bad 8004c75027be90f2f1b2956f99b2709aa78a8fdb > # bad: [e04b073635205c983891d0d70fb854c7b1871d89] Merge > remote-tracking branch 'input/next' > git bisect bad e04b073635205c983891d0d70fb854c7b1871d89 > # bad: [d1ae62f438f26ecf256e5e4dd7cb53884c7dd3ab] Merge > remote-tracking branch 'sunxi/sunxi/for-next' > git bisect bad d1ae62f438f26ecf256e5e4dd7cb53884c7dd3ab > # good: [5956fb6486d7bd2467fe6282a784af4f1cf67bef] Merge > remote-tracking branch 'drm-misc/for-linux-next' > git bisect good 5956fb6486d7bd2467fe6282a784af4f1cf67bef > # good: [a0a68fb6872f545acd49035ea17c52a9f30d07dc] drm/sun4i: Pass > pointer for underlying backend into layer init > git bisect good a0a68fb6872f545acd49035ea17c52a9f30d07dc > # good: [7d55034799cdc9945ce7975d690f944575376e34] ARM: dts: sunxi: > Remove no longer used pinctrl/sun4i-a10.h header > git bisect good 7d55034799cdc9945ce7975d690f944575376e34 > # bad: [681cc0445e24fe5cb4e7de960947443de592621c] Merge branches > 'sunxi/clk-for-4.12', 'sunxi/core-for-4.12', 'sunxi/defconfig-fo\ > r-4.12', 'sunxi/drm-for-4.12' and 'sunxi/dt-for-4.12' into sunxi/for-next > git bisect bad 681cc0445e24fe5cb4e7de960947443de592621c > # good: [b0f0daa8fe9e74b85f6360288d38224ad1c2f2f4] clk: sunxi-ng: > sun5i: Fix mux width for csi clock > git bisect good b0f0daa8fe9e74b85f6360288d38224ad1c2f2f4 > # bad: [7cae7ef89e360cd3dc139eaac2f480c25bc7bfa1] ARM: > multi_v7_defconfig: Switch AXP20x driver from module to built-in > git bisect bad 7cae7ef89e360cd3dc139eaac2f480c25bc7bfa1 > # good: [5741e07b465d32458945d363ce87c0e2b7fd028d] ARM: > multi_v7_defconfig: Switch sunxi RSB driver from module to built-in > git bisect good 5741e07b465d32458945d363ce87c0e2b7fd028d > # good: [f48a203cc44f26921f05911c047db49d2864c797] ARM: > multi_v7_defconfig: Enable AC100 RTC driver > git bisect good f48a203cc44f26921f05911c047db49d2864c797 > # first bad commit: [7cae7ef89e360cd3dc139eaac2f480c25bc7bfa1] ARM: > multi_v7_defconfig: Switch AXP20x driver from module to built\ > -in
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. Maxime
Maxime Ripard <maxime.ripard@free-electrons.com> writes: > 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. How recent of a mainline u-boot do I need? I'm currently running v2016.01. > 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. OK, I can look into powering via 5V input also. Just curious: which of the above methods are you using? Kevin
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. Kevin
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 <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
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
Hi, On Wed, Jun 14, 2017 at 09:07:12AM +0200, Maxime Ripard wrote: > 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 A bit of an update for that. It turned out that our farm also had this issue. We tried to power it through the 5V plug, and it didn't change anything. After wasting way too much time on this, we started digging into it today with Chen-Yu. We found out after enabling DEBUG_DRIVER that the last line was always a cpufreq rate change. Removing the handle on the CPU regulator wasn't changing anything, which left us with the other option: the clocks. It turns out that in 4.12 we also switched to a new clock framework for the sun5i family. A few printk down the line, the clock calculation were not propagated to the PLL, resulting in a CPU crash. Now, you might ask why it was crashing in multi_v7, and not in sunxi_defconfig. The default governor in multi_v7 is ondemand, the one in sunxi is performance, and therefore it never changes the CPU clock rate. And I guess reverting the regulator option patch just prevented the cpufreq-dt from probing since it was missing the CPU regulator described in DT. I'll send a patch addressing this, cc'd to stable. Maxime
Maxime Ripard <maxime.ripard@free-electrons.com> writes: > Hi, > > On Wed, Jun 14, 2017 at 09:07:12AM +0200, Maxime Ripard wrote: >> 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 > > A bit of an update for that. It turned out that our farm also had this > issue. We tried to power it through the 5V plug, and it didn't change > anything. > > After wasting way too much time on this, we started digging into it > today with Chen-Yu. > > We found out after enabling DEBUG_DRIVER that the last line was always > a cpufreq rate change. Removing the handle on the CPU regulator wasn't > changing anything, which left us with the other option: the clocks. > > It turns out that in 4.12 we also switched to a new clock framework > for the sun5i family. A few printk down the line, the clock > calculation were not propagated to the PLL, resulting in a CPU crash. > > Now, you might ask why it was crashing in multi_v7, and not in > sunxi_defconfig. The default governor in multi_v7 is ondemand, the one > in sunxi is performance, and therefore it never changes the CPU clock > rate. > > And I guess reverting the regulator option patch just prevented the > cpufreq-dt from probing since it was missing the CPU regulator > described in DT. > > I'll send a patch addressing this, cc'd to stable. Yay, thanks spending the extra time to dig into it. Kevin
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 5868186..cc071a0 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -482,8 +482,8 @@ CONFIG_MFD_ATMEL_HLCDC=m CONFIG_MFD_BCM590XX=y CONFIG_MFD_AC100=y CONFIG_MFD_AXP20X=y -CONFIG_MFD_AXP20X_I2C=m -CONFIG_MFD_AXP20X_RSB=m +CONFIG_MFD_AXP20X_I2C=y +CONFIG_MFD_AXP20X_RSB=y CONFIG_MFD_CROS_EC=m CONFIG_MFD_CROS_EC_I2C=m CONFIG_MFD_CROS_EC_SPI=m @@ -512,7 +512,7 @@ CONFIG_REGULATOR_ACT8865=y CONFIG_REGULATOR_ANATOP=y CONFIG_REGULATOR_AS3711=y CONFIG_REGULATOR_AS3722=y -CONFIG_REGULATOR_AXP20X=m +CONFIG_REGULATOR_AXP20X=y CONFIG_REGULATOR_BCM590XX=y CONFIG_REGULATOR_DA9210=y CONFIG_REGULATOR_FAN53555=y
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> --- This patch will have no effect if patch 2/4 is not applied. It will also not apply cleanly without patch 3/4. arch/arm/configs/multi_v7_defconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)