[PATCH 1/4] ARM: sunxi_defconfig: Enable AC100 RTC driver

[Rask Ingemann Lambertsen]

Enable the AC100 RTC driver so boards with it can keep track of time.

Signed-off-by: Rask Ingemann Lambertsen <***@formelder.dk>
Acked-by: Chen-Yu Tsai <***@csie.org>
---
arch/arm/configs/sunxi_defconfig | 2 ++
1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index da92c25..5cd5dd70 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -87,6 +87,7 @@ CONFIG_THERMAL_OF=y
CONFIG_CPU_THERMAL=y
CONFIG_WATCHDOG=y
CONFIG_SUNXI_WATCHDOG=y
+CONFIG_MFD_AC100=y
CONFIG_MFD_AXP20X=y
CONFIG_MFD_AXP20X_I2C=y
CONFIG_MFD_AXP20X_RSB=y
@@ -129,6 +130,7 @@ CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
CONFIG_RTC_CLASS=y
# CONFIG_RTC_INTF_SYSFS is not set
# CONFIG_RTC_INTF_PROC is not set
+CONFIG_RTC_DRV_AC100=y
CONFIG_RTC_DRV_SUN6I=y
CONFIG_RTC_DRV_SUNXI=y
CONFIG_DMADEVICES=y

[Rask Ingemann Lambertsen]

Enable the AC100 RTC driver so boards with it can keep track of time.

Signed-off-by: Rask Ingemann Lambertsen <***@formelder.dk>
---
This patch will have no effect if patch 2/4 is not applied.

arch/arm/configs/multi_v7_defconfig | 2 ++
1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index ec3a110..5868186 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -480,6 +480,7 @@ CONFIG_MFD_AS3722=y
CONFIG_MFD_ATMEL_FLEXCOM=y
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
@@ -749,6 +750,7 @@ CONFIG_EDAC_MM_EDAC=y
CONFIG_EDAC_HIGHBANK_MC=y
CONFIG_EDAC_HIGHBANK_L2=y
CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_AC100=y
CONFIG_RTC_DRV_AS3722=y
CONFIG_RTC_DRV_DS1307=y
CONFIG_RTC_DRV_HYM8563=m

[Maxime Ripard]

Post by Rask Ingemann Lambertsen
Enable the AC100 RTC driver so boards with it can keep track of time.

Queued for 4.12.

Thanks!
Maxime

[Rask Ingemann Lambertsen]

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 <***@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(-)

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

[Maxime Ripard]

Post by Rask Ingemann Lambertsen
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.

Queued for 4.12.

Thanks!
Maxime

[Kevin Hilman]

On Fri, Feb 10, 2017 at 12:42 AM, Maxime Ripard

Post by Maxime Ripard

Post by Rask Ingemann Lambertsen
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.

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

[Kevin Hilman]

Post by Kevin Hilman
On Fri, Feb 10, 2017 at 12:42 AM, Maxime Ripard

Post by Maxime Ripard

Post by Rask Ingemann Lambertsen
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.

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

Post by Kevin Hilman
[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
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
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
sun5i: Fix mux width for csi clock
git bisect good b0f0daa8fe9e74b85f6360288d38224ad1c2f2f4
multi_v7_defconfig: Switch AXP20x driver from module to built-in
git bisect bad 7cae7ef89e360cd3dc139eaac2f480c25bc7bfa1
multi_v7_defconfig: Switch sunxi RSB driver from module to built-in
git bisect good 5741e07b465d32458945d363ce87c0e2b7fd028d
multi_v7_defconfig: Enable AC100 RTC driver
git bisect good f48a203cc44f26921f05911c047db49d2864c797
multi_v7_defconfig: Switch AXP20x driver from module to built\
-in

[Maxime Ripard]

Hi Kevin,

Post by Kevin Hilman

Post by Kevin Hilman
On Fri, Feb 10, 2017 at 12:42 AM, Maxime Ripard

Post by Maxime Ripard

Post by Rask Ingemann Lambertsen
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.

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

[Kevin Hilman]

Post by Maxime Ripard
Hi Kevin,

Post by Kevin Hilman

Post by Kevin Hilman
On Fri, Feb 10, 2017 at 12:42 AM, Maxime Ripard

Post by Maxime Ripard

Post by Rask Ingemann Lambertsen
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.

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.

Post by Maxime Ripard
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

[Kevin Hilman]

On Mon, May 22, 2017 at 12:44 AM, Maxime Ripard

Post by Maxime Ripard
Hi Kevin,

Post by Kevin Hilman

Post by Kevin Hilman
On Fri, Feb 10, 2017 at 12:42 AM, Maxime Ripard

Post by Maxime Ripard

Post by Rask Ingemann Lambertsen
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.

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

[Maxime Ripard]

Post by Kevin Hilman
On Mon, May 22, 2017 at 12:44 AM, Maxime Ripard

Post by Maxime Ripard
Hi Kevin,

Post by Kevin Hilman

Post by Kevin Hilman
On Fri, Feb 10, 2017 at 12:42 AM, Maxime Ripard

Post by Maxime Ripard

Post by Rask Ingemann Lambertsen
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.

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

[Kevin Hilman]

Post by Maxime Ripard

Post by Kevin Hilman
On Mon, May 22, 2017 at 12:44 AM, Maxime Ripard

Post by Maxime Ripard
Hi Kevin,

Post by Kevin Hilman

Post by Kevin Hilman
On Fri, Feb 10, 2017 at 12:42 AM, Maxime Ripard

Post by Maxime Ripard

Post by Rask Ingemann Lambertsen
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.

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?

Post by Maxime Ripard
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

[Maxime Ripard]

Post by Kevin Hilman

Post by Maxime Ripard

Post by Kevin Hilman
On Mon, May 22, 2017 at 12:44 AM, Maxime Ripard

Post by Maxime Ripard
Hi Kevin,

Post by Kevin Hilman

Post by Kevin Hilman
On Fri, Feb 10, 2017 at 12:42 AM, Maxime Ripard

Post by Maxime Ripard

Post by Rask Ingemann Lambertsen
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.

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

Post by Kevin Hilman

Post by Maxime Ripard
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]

Hi,

Post by Maxime Ripard

Post by Kevin Hilman

Post by Maxime Ripard

Post by Kevin Hilman
On Mon, May 22, 2017 at 12:44 AM, Maxime Ripard

Post by Maxime Ripard
Hi Kevin,

Post by Kevin Hilman

Post by Kevin Hilman
On Fri, Feb 10, 2017 at 12:42 AM, Maxime Ripard

Post by Maxime Ripard

Post by Rask Ingemann Lambertsen
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.

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

[Kevin Hilman]

Post by Maxime Ripard
Hi,

Post by Maxime Ripard

Post by Kevin Hilman

Post by Maxime Ripard

Post by Kevin Hilman
On Mon, May 22, 2017 at 12:44 AM, Maxime Ripard

Post by Maxime Ripard
Hi Kevin,

Post by Kevin Hilman

Post by Kevin Hilman
On Fri, Feb 10, 2017 at 12:42 AM, Maxime Ripard

Post by Maxime Ripard

Post by Rask Ingemann Lambertsen
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.

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

[Rask Ingemann Lambertsen]

The sunxi RSB bus is used for peripherals like voltage regulators and
real-time clocks which should be available early in the boot process.
As a module, the driver will not be available until the root fs has been
mounted, so build the driver into the kernel.

Signed-off-by: Rask Ingemann Lambertsen <***@formelder.dk>
---
arch/arm/configs/multi_v7_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 028d2b7..ec3a110 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -193,7 +193,7 @@ CONFIG_DMA_CMA=y
CONFIG_CMA_SIZE_MBYTES=64
CONFIG_OMAP_OCP2SCP=y
CONFIG_SIMPLE_PM_BUS=y
-CONFIG_SUNXI_RSB=m
+CONFIG_SUNXI_RSB=y
CONFIG_MTD=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_BLOCK=y

[Maxime Ripard]

Post by Rask Ingemann Lambertsen
The sunxi RSB bus is used for peripherals like voltage regulators and
real-time clocks which should be available early in the boot process.
As a module, the driver will not be available until the root fs has been
mounted, so build the driver into the kernel.

Queued for 4.12.

Thanks!
Maxime

[Maxime Ripard]

Post by Rask Ingemann Lambertsen
Enable the AC100 RTC driver so boards with it can keep track of time.

Queued for 4.12.

Thanks!
Maxime