[U-Boot] [PATCH 1/2] rockchip: rk3399: fix force power on reset

[U-Boot] [PATCH 1/2] rockchip: rk3399: fix force power on reset

[Vasily Khoruzhick]

Currently code doesn't even compile since it uses wrong
define for ifdef. Fix that and also add missing include

Fixes: 07586ee4322a ("rockchip: rk3399: Support common spl_board_init")
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
 arch/arm/mach-rockchip/rk3399/rk3399.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c
index 863024d071..eeb99dd11b 100644
--- a/arch/arm/mach-rockchip/rk3399/rk3399.c
+++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
@@ -11,6 +11,7 @@
 #include <asm/io.h>
 #include <asm/arch-rockchip/bootrom.h>
 #include <asm/arch-rockchip/clock.h>
+#include <asm/arch-rockchip/cru_rk3399.h>
 #include <asm/arch-rockchip/gpio.h>
 #include <asm/arch-rockchip/grf_rk3399.h>
 #include <asm/arch-rockchip/hardware.h>
@@ -213,7 +214,7 @@ void spl_perform_fixups(struct spl_image_info *spl_image)
 			   "u-boot,spl-boot-device", boot_ofpath);
 }
 
-#if defined(SPL_GPIO_SUPPORT)
+#if defined(CONFIG_SPL_GPIO_SUPPORT)
 static void rk3399_force_power_on_reset(void)
 {
 	ofnode node;
@@ -239,7 +240,7 @@ static void rk3399_force_power_on_reset(void)
 
 void spl_board_init(void)
 {
-#if defined(SPL_GPIO_SUPPORT)
+#if defined(CONFIG_SPL_GPIO_SUPPORT)
 	struct rk3399_cru *cru = rockchip_get_cru();
 
 	/*
-- 
2.24.0

[U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround

[Vasily Khoruzhick]

Rockpro64 doesn't boot reliably after soft reset, so let's force power on
reset by asserting sysreset pin if we detected soft reset.

Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
 arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 8 ++++++++
 configs/rockpro64-rk3399_defconfig        | 1 +
 2 files changed, 9 insertions(+)

diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
index 4648513ea9..bb94bcf7be 100644
--- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
@@ -6,11 +6,19 @@
 #include "rk3399-u-boot.dtsi"
 #include "rk3399-sdram-lpddr4-100.dtsi"
 / {
+	config {
+		sysreset-gpio = <&gpio1 RK_PA6 GPIO_ACTIVE_HIGH>;
+	};
+
 	chosen {
 		u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci;
 	};
 };
 
+&gpio1  {
+	u-boot,dm-pre-reloc;
+};
+
 &vdd_center {
 	regulator-min-microvolt = <950000>;
 	regulator-max-microvolt = <950000>;
diff --git a/configs/rockpro64-rk3399_defconfig b/configs/rockpro64-rk3399_defconfig
index 49e27c91cb..d153ac5485 100644
--- a/configs/rockpro64-rk3399_defconfig
+++ b/configs/rockpro64-rk3399_defconfig
@@ -1,6 +1,7 @@
 CONFIG_ARM=y
 CONFIG_ARCH_ROCKCHIP=y
 CONFIG_SYS_TEXT_BASE=0x00200000
+CONFIG_SPL_GPIO_SUPPORT=y
 CONFIG_ROCKCHIP_RK3399=y
 CONFIG_ENV_OFFSET=0x3F8000
 CONFIG_TARGET_ROCKPRO64_RK3399=y
-- 
2.24.0

[U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround

[Kever Yang]

Hi Vasily,

     I think this should not be needed, see comments below.


Hi Philipp, Klaus and Christoph:

     Could you help to check why do you need below patch for your board?

ae0d33a729 rockchip: rk3399-puma: add code to allow forcing a power-on reset


     I think we don't need this workaround for rk3399 CPU_B voltage 
supply, and
here is what I got:
- rockchip use cru glb_rst_1 for reboot in kernel;
- the glb_rst_1 will reset all the GPIO logic to default state;
- the cpu_b voltage supplier syr83x have a VSEL connect to rk3399, which 
may be
    a pull up/down IO,
- the syr83x output with the hardware default state of the VSEL(with 
RK3399 default IO output)
   should be normal output(1.0V), and another state output for 
suspend(disabled),
- In order to make the syr83x works as expected, the kernel setting of 
syr83x should be correct,
   check property:
     fcs,suspend-voltage-selector = <1>;
    This is correct for rockpro64(vsel connect to a gpio with default 
pull down) on upstream,
     but I don't have a puma schematic, so I don't know if this is 
correct for puma.
- With correct setting in syr83x, the cpu_b should always have power 
supply after reboot/reset with
   cru glb_rst_1 reg.
So no workaround is needed in U-Boot, please correct me if anything is 
missing.

Thanks,
- Kever
On 2019/11/28 下午2:14, Vasily Khoruzhick wrote:
> Rockpro64 doesn't boot reliably after soft reset, so let's force power on
> reset by asserting sysreset pin if we detected soft reset.
>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
>   arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 8 ++++++++
>   configs/rockpro64-rk3399_defconfig        | 1 +
>   2 files changed, 9 insertions(+)
>
> diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> index 4648513ea9..bb94bcf7be 100644
> --- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> @@ -6,11 +6,19 @@
>   #include "rk3399-u-boot.dtsi"
>   #include "rk3399-sdram-lpddr4-100.dtsi"
>   / {
> +	config {
> +		sysreset-gpio = <&gpio1 RK_PA6 GPIO_ACTIVE_HIGH>;
> +	};
> +
>   	chosen {
>   		u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci;
>   	};
>   };
>   
> +&gpio1  {
> +	u-boot,dm-pre-reloc;
> +};
> +
>   &vdd_center {
>   	regulator-min-microvolt = <950000>;
>   	regulator-max-microvolt = <950000>;
> diff --git a/configs/rockpro64-rk3399_defconfig b/configs/rockpro64-rk3399_defconfig
> index 49e27c91cb..d153ac5485 100644
> --- a/configs/rockpro64-rk3399_defconfig
> +++ b/configs/rockpro64-rk3399_defconfig
> @@ -1,6 +1,7 @@
>   CONFIG_ARM=y
>   CONFIG_ARCH_ROCKCHIP=y
>   CONFIG_SYS_TEXT_BASE=0x00200000
> +CONFIG_SPL_GPIO_SUPPORT=y
>   CONFIG_ROCKCHIP_RK3399=y
>   CONFIG_ENV_OFFSET=0x3F8000
>   CONFIG_TARGET_ROCKPRO64_RK3399=y

[U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround

[Vasily Khoruzhick]

On Thu, Nov 28, 2019 at 1:23 AM Kever Yang <kever.yang@rock-chips.com> wrote:
>
> Hi Vasily,
>
>      I think this should not be needed, see comments below.

Hi Kever,

I've spent 2 weeks of my evenings debugging this issue but
unfortunately I don't have a proper fix. This is the only solution
that makes my rockpro64 reboot reliably with mainline u-boot and ATF.
See my comments below.

> Hi Philipp, Klaus and Christoph:
>
>      Could you help to check why do you need below patch for your board?
>
> ae0d33a729 rockchip: rk3399-puma: add code to allow forcing a power-on reset
>
>
>      I think we don't need this workaround for rk3399 CPU_B voltage
> supply, and
> here is what I got:
> - rockchip use cru glb_rst_1 for reboot in kernel;
> - the glb_rst_1 will reset all the GPIO logic to default state;
> - the cpu_b voltage supplier syr83x have a VSEL connect to rk3399, which
> may be
>     a pull up/down IO,
> - the syr83x output with the hardware default state of the VSEL(with
> RK3399 default IO output)
>    should be normal output(1.0V), and another state output for
> suspend(disabled),
> - In order to make the syr83x works as expected, the kernel setting of
> syr83x should be correct,
>    check property:
>      fcs,suspend-voltage-selector = <1>;
>     This is correct for rockpro64(vsel connect to a gpio with default
> pull down) on upstream,
>      but I don't have a puma schematic, so I don't know if this is
> correct for puma.
> - With correct setting in syr83x, the cpu_b should always have power
> supply after reboot/reset with
>    cru glb_rst_1 reg.
> So no workaround is needed in U-Boot, please correct me if anything is
> missing.

I already tried re-initializing SYR83x, see [1] (and thus fixed couple
of the bugs in FAN53555 driver which has been broken since it was
merged into u-boot) but it doesn't help with reboot issue on
RockPro64. I checked VSEL gpio status and it's identical on cold boot
and on soft reboot, so I doubt SYR83X settings are related since I
checked regulators settings and they're correct.

I tried to boot with CPUFREQ disabled - that didn't help, linux hangs
when booted after soft reset.

Also tried to boot with big cluster disabled - that didn't help either.

So could you merge this patch please unless someone else wants to work
on this issue?

Thanks,
Vasily.

[1] https://github.com/anarsoul/u-boot-pine64/commit/7a50e58f09c68efe08f0b9912805fb9b3c985751

> Thanks,
> - Kever
> On 2019/11/28 下午2:14, Vasily Khoruzhick wrote:
> > Rockpro64 doesn't boot reliably after soft reset, so let's force power on
> > reset by asserting sysreset pin if we detected soft reset.
> >
> > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> > ---
> >   arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 8 ++++++++
> >   configs/rockpro64-rk3399_defconfig        | 1 +
> >   2 files changed, 9 insertions(+)
> >
> > diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> > index 4648513ea9..bb94bcf7be 100644
> > --- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> > +++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> > @@ -6,11 +6,19 @@
> >   #include "rk3399-u-boot.dtsi"
> >   #include "rk3399-sdram-lpddr4-100.dtsi"
> >   / {
> > +     config {
> > +             sysreset-gpio = <&gpio1 RK_PA6 GPIO_ACTIVE_HIGH>;
> > +     };
> > +
> >       chosen {
> >               u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci;
> >       };
> >   };
> >
> > +&gpio1  {
> > +     u-boot,dm-pre-reloc;
> > +};
> > +
> >   &vdd_center {
> >       regulator-min-microvolt = <950000>;
> >       regulator-max-microvolt = <950000>;
> > diff --git a/configs/rockpro64-rk3399_defconfig b/configs/rockpro64-rk3399_defconfig
> > index 49e27c91cb..d153ac5485 100644
> > --- a/configs/rockpro64-rk3399_defconfig
> > +++ b/configs/rockpro64-rk3399_defconfig
> > @@ -1,6 +1,7 @@
> >   CONFIG_ARM=y
> >   CONFIG_ARCH_ROCKCHIP=y
> >   CONFIG_SYS_TEXT_BASE=0x00200000
> > +CONFIG_SPL_GPIO_SUPPORT=y
> >   CONFIG_ROCKCHIP_RK3399=y
> >   CONFIG_ENV_OFFSET=0x3F8000
> >   CONFIG_TARGET_ROCKPRO64_RK3399=y
>
>

[U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround

[Kever Yang]

Hi Vasily,

On 2019/11/28 下午11:51, Vasily Khoruzhick wrote:
> On Thu, Nov 28, 2019 at 1:23 AM Kever Yang <kever.yang@rock-chips.com> wrote:
>> Hi Vasily,
>>
>>       I think this should not be needed, see comments below.
> Hi Kever,
>
> I've spent 2 weeks of my evenings debugging this issue but

I can understand you work pretty hard on make it work, it's not so easy 
to identify the root cause

some times, thanks very much for working on this.

> unfortunately I don't have a proper fix. This is the only solution
> that makes my rockpro64 reboot reliably with mainline u-boot and ATF.
> See my comments below.
>
>> Hi Philipp, Klaus and Christoph:
>>
>>       Could you help to check why do you need below patch for your board?
>>
>> ae0d33a729 rockchip: rk3399-puma: add code to allow forcing a power-on reset
>>
>>
>>       I think we don't need this workaround for rk3399 CPU_B voltage
>> supply, and
>> here is what I got:
>> - rockchip use cru glb_rst_1 for reboot in kernel;
>> - the glb_rst_1 will reset all the GPIO logic to default state;
>> - the cpu_b voltage supplier syr83x have a VSEL connect to rk3399, which
>> may be
>>      a pull up/down IO,
>> - the syr83x output with the hardware default state of the VSEL(with
>> RK3399 default IO output)
>>     should be normal output(1.0V), and another state output for
>> suspend(disabled),
>> - In order to make the syr83x works as expected, the kernel setting of
>> syr83x should be correct,
>>     check property:
>>       fcs,suspend-voltage-selector = <1>;
>>      This is correct for rockpro64(vsel connect to a gpio with default
>> pull down) on upstream,
>>       but I don't have a puma schematic, so I don't know if this is
>> correct for puma.
>> - With correct setting in syr83x, the cpu_b should always have power
>> supply after reboot/reset with
>>     cru glb_rst_1 reg.
>> So no workaround is needed in U-Boot, please correct me if anything is
>> missing.
> I already tried re-initializing SYR83x, see [1] (and thus fixed couple
> of the bugs in FAN53555 driver which has been broken since it was
> merged into u-boot) but it doesn't help with reboot issue on
> RockPro64. I checked VSEL gpio status and it's identical on cold boot
> and on soft reboot, so I doubt SYR83X settings are related since I
> checked regulators settings and they're correct.

Could you help to provide some more info?

- For code boot, syr83x VSEL is low, and what is its output voltage?

- For reboot, syr83x VSEL is low, what is its output voltage?

- For reboot, after this patch, the syr83x VSEL is high, what is its 
output voltage?

I think the setting of syr83x is wrong if the output voltage is not the 
same for code  boot and reboot.

>
> I tried to boot with CPUFREQ disabled - that didn't help, linux hangs
> when booted after soft reset.
>
> Also tried to boot with big cluster disabled - that didn't help either.

This is strange, this patch only affects the big cluster CPU, if big 
cluster is disabled, then there is

no reason this patch can work. Have you double check the big cluster is 
truly _DISABLED_?


Thanks,

- Kever

>
> So could you merge this patch please unless someone else wants to work
> on this issue?
>
> Thanks,
> Vasily.
>
> [1] https://github.com/anarsoul/u-boot-pine64/commit/7a50e58f09c68efe08f0b9912805fb9b3c985751
>
>> Thanks,
>> - Kever
>> On 2019/11/28 下午2:14, Vasily Khoruzhick wrote:
>>> Rockpro64 doesn't boot reliably after soft reset, so let's force power on
>>> reset by asserting sysreset pin if we detected soft reset.
>>>
>>> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
>>> ---
>>>    arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 8 ++++++++
>>>    configs/rockpro64-rk3399_defconfig        | 1 +
>>>    2 files changed, 9 insertions(+)
>>>
>>> diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
>>> index 4648513ea9..bb94bcf7be 100644
>>> --- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
>>> +++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
>>> @@ -6,11 +6,19 @@
>>>    #include "rk3399-u-boot.dtsi"
>>>    #include "rk3399-sdram-lpddr4-100.dtsi"
>>>    / {
>>> +     config {
>>> +             sysreset-gpio = <&gpio1 RK_PA6 GPIO_ACTIVE_HIGH>;
>>> +     };
>>> +
>>>        chosen {
>>>                u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci;
>>>        };
>>>    };
>>>
>>> +&gpio1  {
>>> +     u-boot,dm-pre-reloc;
>>> +};
>>> +
>>>    &vdd_center {
>>>        regulator-min-microvolt = <950000>;
>>>        regulator-max-microvolt = <950000>;
>>> diff --git a/configs/rockpro64-rk3399_defconfig b/configs/rockpro64-rk3399_defconfig
>>> index 49e27c91cb..d153ac5485 100644
>>> --- a/configs/rockpro64-rk3399_defconfig
>>> +++ b/configs/rockpro64-rk3399_defconfig
>>> @@ -1,6 +1,7 @@
>>>    CONFIG_ARM=y
>>>    CONFIG_ARCH_ROCKCHIP=y
>>>    CONFIG_SYS_TEXT_BASE=0x00200000
>>> +CONFIG_SPL_GPIO_SUPPORT=y
>>>    CONFIG_ROCKCHIP_RK3399=y
>>>    CONFIG_ENV_OFFSET=0x3F8000
>>>    CONFIG_TARGET_ROCKPRO64_RK3399=y
>>

[U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround

[Vasily Khoruzhick]

On Thu, Nov 28, 2019 at 4:59 PM Kever Yang <kever.yang@rock-chips.com> wrote:
>
> Hi Vasily,
>
> On 2019/11/28 下午11:51, Vasily Khoruzhick wrote:
> > On Thu, Nov 28, 2019 at 1:23 AM Kever Yang <kever.yang@rock-chips.com> wrote:
> >> Hi Vasily,
> >>
> >>       I think this should not be needed, see comments below.
> > Hi Kever,
> >
> > I've spent 2 weeks of my evenings debugging this issue but
>
> I can understand you work pretty hard on make it work, it's not so easy
> to identify the root cause
>
> some times, thanks very much for working on this.
>
> > unfortunately I don't have a proper fix. This is the only solution
> > that makes my rockpro64 reboot reliably with mainline u-boot and ATF.
> > See my comments below.
> >
> >> Hi Philipp, Klaus and Christoph:
> >>
> >>       Could you help to check why do you need below patch for your board?
> >>
> >> ae0d33a729 rockchip: rk3399-puma: add code to allow forcing a power-on reset
> >>
> >>
> >>       I think we don't need this workaround for rk3399 CPU_B voltage
> >> supply, and
> >> here is what I got:
> >> - rockchip use cru glb_rst_1 for reboot in kernel;
> >> - the glb_rst_1 will reset all the GPIO logic to default state;
> >> - the cpu_b voltage supplier syr83x have a VSEL connect to rk3399, which
> >> may be
> >>      a pull up/down IO,
> >> - the syr83x output with the hardware default state of the VSEL(with
> >> RK3399 default IO output)
> >>     should be normal output(1.0V), and another state output for
> >> suspend(disabled),
> >> - In order to make the syr83x works as expected, the kernel setting of
> >> syr83x should be correct,
> >>     check property:
> >>       fcs,suspend-voltage-selector = <1>;
> >>      This is correct for rockpro64(vsel connect to a gpio with default
> >> pull down) on upstream,
> >>       but I don't have a puma schematic, so I don't know if this is
> >> correct for puma.
> >> - With correct setting in syr83x, the cpu_b should always have power
> >> supply after reboot/reset with
> >>     cru glb_rst_1 reg.
> >> So no workaround is needed in U-Boot, please correct me if anything is
> >> missing.
> > I already tried re-initializing SYR83x, see [1] (and thus fixed couple
> > of the bugs in FAN53555 driver which has been broken since it was
> > merged into u-boot) but it doesn't help with reboot issue on
> > RockPro64. I checked VSEL gpio status and it's identical on cold boot
> > and on soft reboot, so I doubt SYR83X settings are related since I
> > checked regulators settings and they're correct.
>
> Could you help to provide some more info?
>
> - For code boot, syr83x VSEL is low, and what is its output voltage?
>
> - For reboot, syr83x VSEL is low, what is its output voltage?

I'll double check later tonight.

> - For reboot, after this patch, the syr83x VSEL is high, what is its
> output voltage?

This patch doesn't touch VSEL. It sets OTP_OUT to 1, see [1]
"Over-Temperature Protection" and thus forces board reset.

OTP_OUT is GPIO1 A6.

VSEL (or rather CPU_B_SLEEP_H) is different pin, it's wired to GPIO1 C1

http://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf

> I think the setting of syr83x is wrong if the output voltage is not the
> same for code  boot and reboot.
>
> >
> > I tried to boot with CPUFREQ disabled - that didn't help, linux hangs
> > when booted after soft reset.
> >
> > Also tried to boot with big cluster disabled - that didn't help either.
>
> This is strange, this patch only affects the big cluster CPU, if big
> cluster is disabled, then there is
>
> no reason this patch can work. Have you double check the big cluster is
> truly _DISABLED_?

See explanation above.

>
> Thanks,
>
> - Kever
>
> >
> > So could you merge this patch please unless someone else wants to work
> > on this issue?
> >
> > Thanks,
> > Vasily.
> >
> > [1] https://github.com/anarsoul/u-boot-pine64/commit/7a50e58f09c68efe08f0b9912805fb9b3c985751
> >
> >> Thanks,
> >> - Kever
> >> On 2019/11/28 下午2:14, Vasily Khoruzhick wrote:
> >>> Rockpro64 doesn't boot reliably after soft reset, so let's force power on
> >>> reset by asserting sysreset pin if we detected soft reset.
> >>>
> >>> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> >>> ---
> >>>    arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 8 ++++++++
> >>>    configs/rockpro64-rk3399_defconfig        | 1 +
> >>>    2 files changed, 9 insertions(+)
> >>>
> >>> diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> >>> index 4648513ea9..bb94bcf7be 100644
> >>> --- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> >>> +++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> >>> @@ -6,11 +6,19 @@
> >>>    #include "rk3399-u-boot.dtsi"
> >>>    #include "rk3399-sdram-lpddr4-100.dtsi"
> >>>    / {
> >>> +     config {
> >>> +             sysreset-gpio = <&gpio1 RK_PA6 GPIO_ACTIVE_HIGH>;
> >>> +     };
> >>> +
> >>>        chosen {
> >>>                u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci;
> >>>        };
> >>>    };
> >>>
> >>> +&gpio1  {
> >>> +     u-boot,dm-pre-reloc;
> >>> +};
> >>> +
> >>>    &vdd_center {
> >>>        regulator-min-microvolt = <950000>;
> >>>        regulator-max-microvolt = <950000>;
> >>> diff --git a/configs/rockpro64-rk3399_defconfig b/configs/rockpro64-rk3399_defconfig
> >>> index 49e27c91cb..d153ac5485 100644
> >>> --- a/configs/rockpro64-rk3399_defconfig
> >>> +++ b/configs/rockpro64-rk3399_defconfig
> >>> @@ -1,6 +1,7 @@
> >>>    CONFIG_ARM=y
> >>>    CONFIG_ARCH_ROCKCHIP=y
> >>>    CONFIG_SYS_TEXT_BASE=0x00200000
> >>> +CONFIG_SPL_GPIO_SUPPORT=y
> >>>    CONFIG_ROCKCHIP_RK3399=y
> >>>    CONFIG_ENV_OFFSET=0x3F8000
> >>>    CONFIG_TARGET_ROCKPRO64_RK3399=y
> >>
>
>

[U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround

[Hugh Cole-Baker]

Hi Vasily,

> On 29 Nov 2019, at 01:06, Vasily Khoruzhick <anarsoul@gmail.com> wrote:
> 
> On Thu, Nov 28, 2019 at 4:59 PM Kever Yang <kever.yang@rock-chips.com> wrote:
>> 
>> Hi Vasily,
>> 
>> On 2019/11/28 下午11:51, Vasily Khoruzhick wrote:
>>> On Thu, Nov 28, 2019 at 1:23 AM Kever Yang <kever.yang@rock-chips.com> wrote:
>>>> Hi Vasily,
>>>> 
>>>>      I think this should not be needed, see comments below.
>>> Hi Kever,
>>> 
>>> I've spent 2 weeks of my evenings debugging this issue but
>> 
>> I can understand you work pretty hard on make it work, it's not so easy
>> to identify the root cause
>> 
>> some times, thanks very much for working on this.
>> 
>>> unfortunately I don't have a proper fix. This is the only solution
>>> that makes my rockpro64 reboot reliably with mainline u-boot and ATF.
>>> See my comments below.

I also had a problem where Linux would hang or panic after rebooting, with
mainline u-boot and ATF on a rockpro64. This patch does fix the issue for me,
I have tested it by performing 10 reboots from Linux in a row and I've seen
no hangs or panics.

I noticed the Armbian project have recently included a patch to ATF [1] which
switches all power domains on before ATF performs a soft reset. I have also
tested using u-boot mainline, without any patches to u-boot, but including ATF
patched with your reset fix [2] and the Armbian power domains patch [1]. This
also fixes the same hanging on reboot issue for me without modifications to
u-boot, I've also tested 10 reboots in a row with this ATF and seen no hangs.

So this u-boot patch may not be needed if ATF is patched instead to switch
power domains on before soft reset.

FWIW, when I was able to see panic messages from Linux when it panicked on
boot, the call trace always seemed to include rockchip_pd_power_off() [3].

[1] https://github.com/armbian/build/blob/master/patch/atf/atf-rk3399/switch-power-domains-on-before-reset.patch
[2] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2512
[3] https://gist.github.com/sigmaris/c0e155c8cb0a325d84f549185f9a568c

>>> 
>>>> Hi Philipp, Klaus and Christoph:
>>>> 
>>>>      Could you help to check why do you need below patch for your board?
>>>> 
>>>> ae0d33a729 rockchip: rk3399-puma: add code to allow forcing a power-on reset
>>>> 
>>>> 
>>>>      I think we don't need this workaround for rk3399 CPU_B voltage
>>>> supply, and
>>>> here is what I got:
>>>> - rockchip use cru glb_rst_1 for reboot in kernel;
>>>> - the glb_rst_1 will reset all the GPIO logic to default state;
>>>> - the cpu_b voltage supplier syr83x have a VSEL connect to rk3399, which
>>>> may be
>>>>     a pull up/down IO,
>>>> - the syr83x output with the hardware default state of the VSEL(with
>>>> RK3399 default IO output)
>>>>    should be normal output(1.0V), and another state output for
>>>> suspend(disabled),
>>>> - In order to make the syr83x works as expected, the kernel setting of
>>>> syr83x should be correct,
>>>>    check property:
>>>>      fcs,suspend-voltage-selector = <1>;
>>>>     This is correct for rockpro64(vsel connect to a gpio with default
>>>> pull down) on upstream,
>>>>      but I don't have a puma schematic, so I don't know if this is
>>>> correct for puma.
>>>> - With correct setting in syr83x, the cpu_b should always have power
>>>> supply after reboot/reset with
>>>>    cru glb_rst_1 reg.
>>>> So no workaround is needed in U-Boot, please correct me if anything is
>>>> missing.
>>> I already tried re-initializing SYR83x, see [1] (and thus fixed couple
>>> of the bugs in FAN53555 driver which has been broken since it was
>>> merged into u-boot) but it doesn't help with reboot issue on
>>> RockPro64. I checked VSEL gpio status and it's identical on cold boot
>>> and on soft reboot, so I doubt SYR83X settings are related since I
>>> checked regulators settings and they're correct.
>> 
>> Could you help to provide some more info?
>> 
>> - For code boot, syr83x VSEL is low, and what is its output voltage?
>> 
>> - For reboot, syr83x VSEL is low, what is its output voltage?
> 
> I'll double check later tonight.
> 
>> - For reboot, after this patch, the syr83x VSEL is high, what is its
>> output voltage?
> 
> This patch doesn't touch VSEL. It sets OTP_OUT to 1, see [1]
> "Over-Temperature Protection" and thus forces board reset.
> 
> OTP_OUT is GPIO1 A6.
> 
> VSEL (or rather CPU_B_SLEEP_H) is different pin, it's wired to GPIO1 C1
> 
> http://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf
> 
>> I think the setting of syr83x is wrong if the output voltage is not the
>> same for code  boot and reboot.
>> 
>>> 
>>> I tried to boot with CPUFREQ disabled - that didn't help, linux hangs
>>> when booted after soft reset.
>>> 
>>> Also tried to boot with big cluster disabled - that didn't help either.
>> 
>> This is strange, this patch only affects the big cluster CPU, if big
>> cluster is disabled, then there is
>> 
>> no reason this patch can work. Have you double check the big cluster is
>> truly _DISABLED_?
> 
> See explanation above.
> 
>> 
>> Thanks,
>> 
>> - Kever
>> 
>>> 
>>> So could you merge this patch please unless someone else wants to work
>>> on this issue?
>>> 
>>> Thanks,
>>> Vasily.
>>> 
>>> [1] https://github.com/anarsoul/u-boot-pine64/commit/7a50e58f09c68efe08f0b9912805fb9b3c985751
>>> 
>>>> Thanks,
>>>> - Kever
>>>> On 2019/11/28 下午2:14, Vasily Khoruzhick wrote:
>>>>> Rockpro64 doesn't boot reliably after soft reset, so let's force power on
>>>>> reset by asserting sysreset pin if we detected soft reset.
>>>>> 
>>>>> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
>>>>> ---
>>>>>   arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 8 ++++++++
>>>>>   configs/rockpro64-rk3399_defconfig        | 1 +
>>>>>   2 files changed, 9 insertions(+)
>>>>> 
>>>>> diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
>>>>> index 4648513ea9..bb94bcf7be 100644
>>>>> --- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
>>>>> +++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
>>>>> @@ -6,11 +6,19 @@
>>>>>   #include "rk3399-u-boot.dtsi"
>>>>>   #include "rk3399-sdram-lpddr4-100.dtsi"
>>>>>   / {
>>>>> +     config {
>>>>> +             sysreset-gpio = <&gpio1 RK_PA6 GPIO_ACTIVE_HIGH>;
>>>>> +     };
>>>>> +
>>>>>       chosen {
>>>>>               u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci;
>>>>>       };
>>>>>   };
>>>>> 
>>>>> +&gpio1  {
>>>>> +     u-boot,dm-pre-reloc;
>>>>> +};
>>>>> +
>>>>>   &vdd_center {
>>>>>       regulator-min-microvolt = <950000>;
>>>>>       regulator-max-microvolt = <950000>;
>>>>> diff --git a/configs/rockpro64-rk3399_defconfig b/configs/rockpro64-rk3399_defconfig
>>>>> index 49e27c91cb..d153ac5485 100644
>>>>> --- a/configs/rockpro64-rk3399_defconfig
>>>>> +++ b/configs/rockpro64-rk3399_defconfig
>>>>> @@ -1,6 +1,7 @@
>>>>>   CONFIG_ARM=y
>>>>>   CONFIG_ARCH_ROCKCHIP=y
>>>>>   CONFIG_SYS_TEXT_BASE=0x00200000
>>>>> +CONFIG_SPL_GPIO_SUPPORT=y
>>>>>   CONFIG_ROCKCHIP_RK3399=y
>>>>>   CONFIG_ENV_OFFSET=0x3F8000
>>>>>   CONFIG_TARGET_ROCKPRO64_RK3399=y
>>>> 
>> 
>> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround

[Kever Yang]

Hi Huge Cole-Baker,

On 2019/12/1 下午10:12, Hugh Cole-Baker wrote:
> Hi Vasily,
>
>> On 29 Nov 2019, at 01:06, Vasily Khoruzhick <anarsoul@gmail.com> wrote:
>>
>> On Thu, Nov 28, 2019 at 4:59 PM Kever Yang <kever.yang@rock-chips.com> wrote:
>>> Hi Vasily,
>>>
>>> On 2019/11/28 下午11:51, Vasily Khoruzhick wrote:
>>>> On Thu, Nov 28, 2019 at 1:23 AM Kever Yang <kever.yang@rock-chips.com> wrote:
>>>>> Hi Vasily,
>>>>>
>>>>>       I think this should not be needed, see comments below.
>>>> Hi Kever,
>>>>
>>>> I've spent 2 weeks of my evenings debugging this issue but
>>> I can understand you work pretty hard on make it work, it's not so easy
>>> to identify the root cause
>>>
>>> some times, thanks very much for working on this.
>>>
>>>> unfortunately I don't have a proper fix. This is the only solution
>>>> that makes my rockpro64 reboot reliably with mainline u-boot and ATF.
>>>> See my comments below.
> I also had a problem where Linux would hang or panic after rebooting, with
> mainline u-boot and ATF on a rockpro64. This patch does fix the issue for me,
> I have tested it by performing 10 reboots from Linux in a row and I've seen
> no hangs or panics.
>
> I noticed the Armbian project have recently included a patch to ATF [1] which
> switches all power domains on before ATF performs a soft reset. I have also
> tested using u-boot mainline, without any patches to u-boot, but including ATF
> patched with your reset fix [2] and the Armbian power domains patch [1]. This
> also fixes the same hanging on reboot issue for me without modifications to
> u-boot, I've also tested 10 reboots in a row with this ATF and seen no hangs.
>
> So this u-boot patch may not be needed if ATF is patched instead to switch
> power domains on before soft reset.
>
> FWIW, when I was able to see panic messages from Linux when it panicked on
> boot, the call trace always seemed to include rockchip_pd_power_off() [3].

Thanks very much for your detail info about this issue,  I have sync 
with my colleague,
rockchip bl31.elf in rkbin do open all the power domain before reboot, 
so I believe this would be a
better solution in ATF for it can resolve issue on all the rk3399 boards 
instead of add one by one in U-Boot.
Does any one of you would like to upstream the patch in ATF?

Thanks,

- Kever

>
> [1] https://github.com/armbian/build/blob/master/patch/atf/atf-rk3399/switch-power-domains-on-before-reset.patch
> [2] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2512
> [3] https://gist.github.com/sigmaris/c0e155c8cb0a325d84f549185f9a568c
>
>>>>> Hi Philipp, Klaus and Christoph:
>>>>>
>>>>>       Could you help to check why do you need below patch for your board?
>>>>>
>>>>> ae0d33a729 rockchip: rk3399-puma: add code to allow forcing a power-on reset
>>>>>
>>>>>
>>>>>       I think we don't need this workaround for rk3399 CPU_B voltage
>>>>> supply, and
>>>>> here is what I got:
>>>>> - rockchip use cru glb_rst_1 for reboot in kernel;
>>>>> - the glb_rst_1 will reset all the GPIO logic to default state;
>>>>> - the cpu_b voltage supplier syr83x have a VSEL connect to rk3399, which
>>>>> may be
>>>>>      a pull up/down IO,
>>>>> - the syr83x output with the hardware default state of the VSEL(with
>>>>> RK3399 default IO output)
>>>>>     should be normal output(1.0V), and another state output for
>>>>> suspend(disabled),
>>>>> - In order to make the syr83x works as expected, the kernel setting of
>>>>> syr83x should be correct,
>>>>>     check property:
>>>>>       fcs,suspend-voltage-selector = <1>;
>>>>>      This is correct for rockpro64(vsel connect to a gpio with default
>>>>> pull down) on upstream,
>>>>>       but I don't have a puma schematic, so I don't know if this is
>>>>> correct for puma.
>>>>> - With correct setting in syr83x, the cpu_b should always have power
>>>>> supply after reboot/reset with
>>>>>     cru glb_rst_1 reg.
>>>>> So no workaround is needed in U-Boot, please correct me if anything is
>>>>> missing.
>>>> I already tried re-initializing SYR83x, see [1] (and thus fixed couple
>>>> of the bugs in FAN53555 driver which has been broken since it was
>>>> merged into u-boot) but it doesn't help with reboot issue on
>>>> RockPro64. I checked VSEL gpio status and it's identical on cold boot
>>>> and on soft reboot, so I doubt SYR83X settings are related since I
>>>> checked regulators settings and they're correct.
>>> Could you help to provide some more info?
>>>
>>> - For code boot, syr83x VSEL is low, and what is its output voltage?
>>>
>>> - For reboot, syr83x VSEL is low, what is its output voltage?
>> I'll double check later tonight.
>>
>>> - For reboot, after this patch, the syr83x VSEL is high, what is its
>>> output voltage?
>> This patch doesn't touch VSEL. It sets OTP_OUT to 1, see [1]
>> "Over-Temperature Protection" and thus forces board reset.
>>
>> OTP_OUT is GPIO1 A6.
>>
>> VSEL (or rather CPU_B_SLEEP_H) is different pin, it's wired to GPIO1 C1
>>
>> http://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf
>>
>>> I think the setting of syr83x is wrong if the output voltage is not the
>>> same for code  boot and reboot.
>>>
>>>> I tried to boot with CPUFREQ disabled - that didn't help, linux hangs
>>>> when booted after soft reset.
>>>>
>>>> Also tried to boot with big cluster disabled - that didn't help either.
>>> This is strange, this patch only affects the big cluster CPU, if big
>>> cluster is disabled, then there is
>>>
>>> no reason this patch can work. Have you double check the big cluster is
>>> truly _DISABLED_?
>> See explanation above.
>>
>>> Thanks,
>>>
>>> - Kever
>>>
>>>> So could you merge this patch please unless someone else wants to work
>>>> on this issue?
>>>>
>>>> Thanks,
>>>> Vasily.
>>>>
>>>> [1] https://github.com/anarsoul/u-boot-pine64/commit/7a50e58f09c68efe08f0b9912805fb9b3c985751
>>>>
>>>>> Thanks,
>>>>> - Kever
>>>>> On 2019/11/28 下午2:14, Vasily Khoruzhick wrote:
>>>>>> Rockpro64 doesn't boot reliably after soft reset, so let's force power on
>>>>>> reset by asserting sysreset pin if we detected soft reset.
>>>>>>
>>>>>> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
>>>>>> ---
>>>>>>    arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 8 ++++++++
>>>>>>    configs/rockpro64-rk3399_defconfig        | 1 +
>>>>>>    2 files changed, 9 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
>>>>>> index 4648513ea9..bb94bcf7be 100644
>>>>>> --- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
>>>>>> +++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
>>>>>> @@ -6,11 +6,19 @@
>>>>>>    #include "rk3399-u-boot.dtsi"
>>>>>>    #include "rk3399-sdram-lpddr4-100.dtsi"
>>>>>>    / {
>>>>>> +     config {
>>>>>> +             sysreset-gpio = <&gpio1 RK_PA6 GPIO_ACTIVE_HIGH>;
>>>>>> +     };
>>>>>> +
>>>>>>        chosen {
>>>>>>                u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci;
>>>>>>        };
>>>>>>    };
>>>>>>
>>>>>> +&gpio1  {
>>>>>> +     u-boot,dm-pre-reloc;
>>>>>> +};
>>>>>> +
>>>>>>    &vdd_center {
>>>>>>        regulator-min-microvolt = <950000>;
>>>>>>        regulator-max-microvolt = <950000>;
>>>>>> diff --git a/configs/rockpro64-rk3399_defconfig b/configs/rockpro64-rk3399_defconfig
>>>>>> index 49e27c91cb..d153ac5485 100644
>>>>>> --- a/configs/rockpro64-rk3399_defconfig
>>>>>> +++ b/configs/rockpro64-rk3399_defconfig
>>>>>> @@ -1,6 +1,7 @@
>>>>>>    CONFIG_ARM=y
>>>>>>    CONFIG_ARCH_ROCKCHIP=y
>>>>>>    CONFIG_SYS_TEXT_BASE=0x00200000
>>>>>> +CONFIG_SPL_GPIO_SUPPORT=y
>>>>>>    CONFIG_ROCKCHIP_RK3399=y
>>>>>>    CONFIG_ENV_OFFSET=0x3F8000
>>>>>>    CONFIG_TARGET_ROCKPRO64_RK3399=y
>>>
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround

[Lee Jones]

Looping int a few relevant/active kernel people/lists for full coverage.

On Sun, 01 Dec 2019, Hugh Cole-Baker wrote:
> > On 29 Nov 2019, at 01:06, Vasily Khoruzhick <anarsoul@gmail.com> wrote:
> > On Thu, Nov 28, 2019 at 4:59 PM Kever Yang <kever.yang@rock-chips.com> wrote:
> >> 
> >> Hi Vasily,
> >> 
> >> On 2019/11/28 下午11:51, Vasily Khoruzhick wrote:
> >>> On Thu, Nov 28, 2019 at 1:23 AM Kever Yang <kever.yang@rock-chips.com> wrote:
> >>>> Hi Vasily,
> >>>> 
> >>>>      I think this should not be needed, see comments below.
> >>> Hi Kever,
> >>> 
> >>> I've spent 2 weeks of my evenings debugging this issue but
> >> 
> >> I can understand you work pretty hard on make it work, it's not so easy
> >> to identify the root cause
> >> 
> >> some times, thanks very much for working on this.
> >> 
> >>> unfortunately I don't have a proper fix. This is the only solution
> >>> that makes my rockpro64 reboot reliably with mainline u-boot and ATF.
> >>> See my comments below.
> 
> I also had a problem where Linux would hang or panic after rebooting, with
> mainline u-boot and ATF on a rockpro64. This patch does fix the issue for me,
> I have tested it by performing 10 reboots from Linux in a row and I've seen
> no hangs or panics.
> 
> I noticed the Armbian project have recently included a patch to ATF [1] which
> switches all power domains on before ATF performs a soft reset. I have also
> tested using u-boot mainline, without any patches to u-boot, but including ATF
> patched with your reset fix [2] and the Armbian power domains patch [1]. This
> also fixes the same hanging on reboot issue for me without modifications to
> u-boot, I've also tested 10 reboots in a row with this ATF and seen no hangs.
> 
> So this u-boot patch may not be needed if ATF is patched instead to switch
> power domains on before soft reset.
> 
> FWIW, when I was able to see panic messages from Linux when it panicked on
> boot, the call trace always seemed to include rockchip_pd_power_off() [3].
> 
> [1] https://github.com/armbian/build/blob/master/patch/atf/atf-rk3399/switch-power-domains-on-before-reset.patch
> [2] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2512
> [3] https://gist.github.com/sigmaris/c0e155c8cb0a325d84f549185f9a568c

This last paste looks remarkably similar to an issue currently seen on
the Radxa ROCK Pi 4B (RK3399) during power-up after a soft reboot
(`sudo reboot`) is issued.  We're presently running v5.15.35 [0].

It's not clear how this issue (present 3 years ago) was finally
resolved.  From the thread, it looks as if the fix might have made its
way into ATF, but I'm 87.6% sure ATF is not running on this platform
(yet).

Note that the u-boot we're using is also quite old:

  U-Boot 2019.10-09248-g8511c75bb4 (Jan 08 2020 - 17:13:03 -0800)

... so this could easily be the root cause.  The current plan is to
try to update this ASAP.  However early attempts are yet to result in
a successful boot.

I see that Brian recently added a few patches related to PD/DVFS, but
again, these appear to be ATF related.

Would anyone be able to shed some light onto this for me please?

As always, any help would be gratefully received.

Kind regards,
Lee

[0]
Full reboot log can be seen at: https://pastebin.ubuntu.com/p/MjZP2V6kQ3/

[    0.699736][    T1] initcall __initstub__kmod_iommu__362_155_iommu_subsys_init4+0x0/0x8 returned 0 after 0 usecs
[    0.700737][    T1] calling  __initstub__kmod_rockchip_iommu__348_1415_rk_iommu_init4+0x0/0x8 @ 1
[    0.702238][    C5] SError Interrupt on CPU5, code 0xbf000002 -- SError
[    0.702248][    C5] CPU: 5 PID: 48 Comm: kworker/5:1 Not tainted 5.15.35-android13-5-00092-g525d77310a20 #1
[    0.702261][    C5] Hardware name: Radxa ROCK Pi 4B (DT)
[    0.702266][    C5] Workqueue: pm genpd_power_off_work_fn.cfi_jt
[    0.702289][    C5] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    0.702301][    C5] pc : regmap_mmio_read32le+0x14/0x2c
[    0.702318][    C5] lr : regmap_mmio_read+0x68/0xd0
[    0.702331][    C5] sp : ffffffc00b6d3b40
[    0.702335][    C5] x29: ffffffc00b6d3b40 x28: 0000000000000000 x27: 0000000000000000
[    0.702351][    C5] x26: ffffff8000923680 x25: ffffffc009abc2a0 x24: ffffff8000930c00
[    0.702364][    C5] x23: 0000000000000014 x22: ffffff8000930c00 x21: 0000000000000008
[    0.702378][    C5] x20: ffffff8000922300 x19: ffffff8000923680 x18: ffffffc00b66d058
[    0.702391][    C5] x17: 000000000000ba7e x16: ffffffc00a4dee04 x15: 000000000000b67e
[    0.702405][    C5] x14: 00000000028dd7a0 x13: 0000000000000040 x12: 0000000000000000
[    0.702419][    C5] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000005
[    0.702432][    C5] x8 : 0000000000000000 x7 : 00756d6d6f692e30 x6 : 3030383035366666
[    0.702445][    C5] x5 : 0000000000000001 x4 : 028dea248fba33d6 x3 : 0000000000000000
[    0.702457][    C5] x2 : ffffff8000923680 x1 : 0000000000000008 x0 : 0000000000000000
[    0.702472][    C5] Kernel panic - not syncing: Asynchronous SError Interrupt
[    0.702477][    C5] CPU: 5 PID: 48 Comm: kworker/5:1 Not tainted 5.15.35-android13-5-00092-g525d77310a20 #1
[    0.702487][    C5] Hardware name: Radxa ROCK Pi 4B (DT)
[    0.702492][    C5] Workqueue: pm genpd_power_off_work_fn.cfi_jt
[    0.702506][    C5] Call trace:
[    0.702508][    C5]  dump_backtrace.cfi_jt+0x0/0x8
[    0.702525][    C5]  dump_stack_lvl+0x80/0xb8
[    0.702536][    C5]  panic+0x180/0x444
[    0.702547][    C5]  arm64_serror_panic+0x1c0/0x210
[    0.702561][    C5]  do_serror+0x17c/0x218
[    0.702572][    C5]  el1h_64_error_handler+0x38/0x50
[    0.702581][    C5]  el1h_64_error+0x7c/0x80
[    0.702589][    C5]  regmap_mmio_read32le+0x14/0x2c
[    0.702603][    C5]  _regmap_bus_reg_read+0x3c/0x90
[    0.702614][    C5]  _regmap_read+0xb0/0x24c
[    0.702623][    C5]  rockchip_pd_power+0x6c4/0xbc0
[    0.702638][    C5]  rockchip_pd_power_off+0x18/0x28
[    0.702652][    C5]  _genpd_power_off+0x178/0x388
[    0.702663][    C5]  genpd_power_off+0x188/0x2e4
[    0.702673][    C5]  genpd_power_off_work_fn+0x54/0xe4
[    0.702683][    C5]  process_one_work+0x254/0x5a0
[    0.702696][    C5]  worker_thread+0x3ec/0x920
[    0.702707][    C5]  kthread+0x168/0x1dc
[    0.702716][    C5]  ret_from_fork+0x10/0x20
[    0.702726][    C5] SMP: stopping secondary CPUs

-- 
Lee Jones [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround

[Peter Geis]

On Wed, May 18, 2022 at 7:56 AM Lee Jones <lee.jones@linaro.org> wrote:
>
> Looping int a few relevant/active kernel people/lists for full coverage.
>
> On Sun, 01 Dec 2019, Hugh Cole-Baker wrote:
> > > On 29 Nov 2019, at 01:06, Vasily Khoruzhick <anarsoul@gmail.com> wrote:
> > > On Thu, Nov 28, 2019 at 4:59 PM Kever Yang <kever.yang@rock-chips.com> wrote:
> > >>
> > >> Hi Vasily,
> > >>
> > >> On 2019/11/28 下午11:51, Vasily Khoruzhick wrote:
> > >>> On Thu, Nov 28, 2019 at 1:23 AM Kever Yang <kever.yang@rock-chips.com> wrote:
> > >>>> Hi Vasily,
> > >>>>
> > >>>>      I think this should not be needed, see comments below.
> > >>> Hi Kever,
> > >>>
> > >>> I've spent 2 weeks of my evenings debugging this issue but
> > >>
> > >> I can understand you work pretty hard on make it work, it's not so easy
> > >> to identify the root cause
> > >>
> > >> some times, thanks very much for working on this.
> > >>
> > >>> unfortunately I don't have a proper fix. This is the only solution
> > >>> that makes my rockpro64 reboot reliably with mainline u-boot and ATF.
> > >>> See my comments below.
> >
> > I also had a problem where Linux would hang or panic after rebooting, with
> > mainline u-boot and ATF on a rockpro64. This patch does fix the issue for me,
> > I have tested it by performing 10 reboots from Linux in a row and I've seen
> > no hangs or panics.
> >
> > I noticed the Armbian project have recently included a patch to ATF [1] which
> > switches all power domains on before ATF performs a soft reset. I have also
> > tested using u-boot mainline, without any patches to u-boot, but including ATF
> > patched with your reset fix [2] and the Armbian power domains patch [1]. This
> > also fixes the same hanging on reboot issue for me without modifications to
> > u-boot, I've also tested 10 reboots in a row with this ATF and seen no hangs.
> >
> > So this u-boot patch may not be needed if ATF is patched instead to switch
> > power domains on before soft reset.
> >
> > FWIW, when I was able to see panic messages from Linux when it panicked on
> > boot, the call trace always seemed to include rockchip_pd_power_off() [3].
> >
> > [1] https://github.com/armbian/build/blob/master/patch/atf/atf-rk3399/switch-power-domains-on-before-reset.patch
> > [2] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2512
> > [3] https://gist.github.com/sigmaris/c0e155c8cb0a325d84f549185f9a568c
>
> This last paste looks remarkably similar to an issue currently seen on
> the Radxa ROCK Pi 4B (RK3399) during power-up after a soft reboot
> (`sudo reboot`) is issued.  We're presently running v5.15.35 [0].

Good Evening,

That's definitely not stock v5.15.35, it's been tagged as an android kernel.
5.15.35-android13-5-00092-g525d77310a20

>
> It's not clear how this issue (present 3 years ago) was finally
> resolved.  From the thread, it looks as if the fix might have made its
> way into ATF, but I'm 87.6% sure ATF is not running on this platform
> (yet).

The rk3399 SoC has a hardware bug where the power domains are not
reset upon a soft reset. This leads to situations like this one where
power domains are shut down during shutdown but aren't restored on
reboot. Mainline TF-A was patched to force all power domains online
when a soft reboot is triggered, which solved that issue. What
particular issues are you having initializing modern u-boot on this
device? Is there a particular reason it isn't using Mainline TF-A?

I've also run into issues on rk356x where the regulator powering a
power domain isn't powered due to a soft reset, which also causes
faults like this. Set your main regulators to always-on and see if it
helps with the issue.

Very Respectfully,
Peter Geis

>
> Note that the u-boot we're using is also quite old:
>
>   U-Boot 2019.10-09248-g8511c75bb4 (Jan 08 2020 - 17:13:03 -0800)
>
> ... so this could easily be the root cause.  The current plan is to
> try to update this ASAP.  However early attempts are yet to result in
> a successful boot.
>
> I see that Brian recently added a few patches related to PD/DVFS, but
> again, these appear to be ATF related.
>
> Would anyone be able to shed some light onto this for me please?
>
> As always, any help would be gratefully received.
>
> Kind regards,
> Lee
>
> [0]
> Full reboot log can be seen at: https://pastebin.ubuntu.com/p/MjZP2V6kQ3/
>
> [    0.699736][    T1] initcall __initstub__kmod_iommu__362_155_iommu_subsys_init4+0x0/0x8 returned 0 after 0 usecs
> [    0.700737][    T1] calling  __initstub__kmod_rockchip_iommu__348_1415_rk_iommu_init4+0x0/0x8 @ 1
> [    0.702238][    C5] SError Interrupt on CPU5, code 0xbf000002 -- SError
> [    0.702248][    C5] CPU: 5 PID: 48 Comm: kworker/5:1 Not tainted 5.15.35-android13-5-00092-g525d77310a20 #1
> [    0.702261][    C5] Hardware name: Radxa ROCK Pi 4B (DT)
> [    0.702266][    C5] Workqueue: pm genpd_power_off_work_fn.cfi_jt
> [    0.702289][    C5] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [    0.702301][    C5] pc : regmap_mmio_read32le+0x14/0x2c
> [    0.702318][    C5] lr : regmap_mmio_read+0x68/0xd0
> [    0.702331][    C5] sp : ffffffc00b6d3b40
> [    0.702335][    C5] x29: ffffffc00b6d3b40 x28: 0000000000000000 x27: 0000000000000000
> [    0.702351][    C5] x26: ffffff8000923680 x25: ffffffc009abc2a0 x24: ffffff8000930c00
> [    0.702364][    C5] x23: 0000000000000014 x22: ffffff8000930c00 x21: 0000000000000008
> [    0.702378][    C5] x20: ffffff8000922300 x19: ffffff8000923680 x18: ffffffc00b66d058
> [    0.702391][    C5] x17: 000000000000ba7e x16: ffffffc00a4dee04 x15: 000000000000b67e
> [    0.702405][    C5] x14: 00000000028dd7a0 x13: 0000000000000040 x12: 0000000000000000
> [    0.702419][    C5] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000005
> [    0.702432][    C5] x8 : 0000000000000000 x7 : 00756d6d6f692e30 x6 : 3030383035366666
> [    0.702445][    C5] x5 : 0000000000000001 x4 : 028dea248fba33d6 x3 : 0000000000000000
> [    0.702457][    C5] x2 : ffffff8000923680 x1 : 0000000000000008 x0 : 0000000000000000
> [    0.702472][    C5] Kernel panic - not syncing: Asynchronous SError Interrupt
> [    0.702477][    C5] CPU: 5 PID: 48 Comm: kworker/5:1 Not tainted 5.15.35-android13-5-00092-g525d77310a20 #1
> [    0.702487][    C5] Hardware name: Radxa ROCK Pi 4B (DT)
> [    0.702492][    C5] Workqueue: pm genpd_power_off_work_fn.cfi_jt
> [    0.702506][    C5] Call trace:
> [    0.702508][    C5]  dump_backtrace.cfi_jt+0x0/0x8
> [    0.702525][    C5]  dump_stack_lvl+0x80/0xb8
> [    0.702536][    C5]  panic+0x180/0x444
> [    0.702547][    C5]  arm64_serror_panic+0x1c0/0x210
> [    0.702561][    C5]  do_serror+0x17c/0x218
> [    0.702572][    C5]  el1h_64_error_handler+0x38/0x50
> [    0.702581][    C5]  el1h_64_error+0x7c/0x80
> [    0.702589][    C5]  regmap_mmio_read32le+0x14/0x2c
> [    0.702603][    C5]  _regmap_bus_reg_read+0x3c/0x90
> [    0.702614][    C5]  _regmap_read+0xb0/0x24c
> [    0.702623][    C5]  rockchip_pd_power+0x6c4/0xbc0
> [    0.702638][    C5]  rockchip_pd_power_off+0x18/0x28
> [    0.702652][    C5]  _genpd_power_off+0x178/0x388
> [    0.702663][    C5]  genpd_power_off+0x188/0x2e4
> [    0.702673][    C5]  genpd_power_off_work_fn+0x54/0xe4
> [    0.702683][    C5]  process_one_work+0x254/0x5a0
> [    0.702696][    C5]  worker_thread+0x3ec/0x920
> [    0.702707][    C5]  kthread+0x168/0x1dc
> [    0.702716][    C5]  ret_from_fork+0x10/0x20
> [    0.702726][    C5] SMP: stopping secondary CPUs
>
> --
> Lee Jones [李琼斯]
> Principal Technical Lead - Developer Services
> Linaro.org │ Open source software for Arm SoCs
> Follow Linaro: Facebook | Twitter | Blog
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround

[Lee Jones]

On Wed, 18 May 2022, Peter Geis wrote:
> On Wed, May 18, 2022 at 7:56 AM Lee Jones <lee.jones@linaro.org> wrote:
> >
> > Looping int a few relevant/active kernel people/lists for full coverage.
> >
> > On Sun, 01 Dec 2019, Hugh Cole-Baker wrote:
> > > > On 29 Nov 2019, at 01:06, Vasily Khoruzhick <anarsoul@gmail.com> wrote:
> > > > On Thu, Nov 28, 2019 at 4:59 PM Kever Yang <kever.yang@rock-chips.com> wrote:
> > > >>
> > > >> Hi Vasily,
> > > >>
> > > >> On 2019/11/28 下午11:51, Vasily Khoruzhick wrote:
> > > >>> On Thu, Nov 28, 2019 at 1:23 AM Kever Yang <kever.yang@rock-chips.com> wrote:
> > > >>>> Hi Vasily,
> > > >>>>
> > > >>>>      I think this should not be needed, see comments below.
> > > >>> Hi Kever,
> > > >>>
> > > >>> I've spent 2 weeks of my evenings debugging this issue but
> > > >>
> > > >> I can understand you work pretty hard on make it work, it's not so easy
> > > >> to identify the root cause
> > > >>
> > > >> some times, thanks very much for working on this.
> > > >>
> > > >>> unfortunately I don't have a proper fix. This is the only solution
> > > >>> that makes my rockpro64 reboot reliably with mainline u-boot and ATF.
> > > >>> See my comments below.
> > >
> > > I also had a problem where Linux would hang or panic after rebooting, with
> > > mainline u-boot and ATF on a rockpro64. This patch does fix the issue for me,
> > > I have tested it by performing 10 reboots from Linux in a row and I've seen
> > > no hangs or panics.
> > >
> > > I noticed the Armbian project have recently included a patch to ATF [1] which
> > > switches all power domains on before ATF performs a soft reset. I have also
> > > tested using u-boot mainline, without any patches to u-boot, but including ATF
> > > patched with your reset fix [2] and the Armbian power domains patch [1]. This
> > > also fixes the same hanging on reboot issue for me without modifications to
> > > u-boot, I've also tested 10 reboots in a row with this ATF and seen no hangs.
> > >
> > > So this u-boot patch may not be needed if ATF is patched instead to switch
> > > power domains on before soft reset.
> > >
> > > FWIW, when I was able to see panic messages from Linux when it panicked on
> > > boot, the call trace always seemed to include rockchip_pd_power_off() [3].
> > >
> > > [1] https://github.com/armbian/build/blob/master/patch/atf/atf-rk3399/switch-power-domains-on-before-reset.patch
> > > [2] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2512
> > > [3] https://gist.github.com/sigmaris/c0e155c8cb0a325d84f549185f9a568c
> >
> > This last paste looks remarkably similar to an issue currently seen on
> > the Radxa ROCK Pi 4B (RK3399) during power-up after a soft reboot
> > (`sudo reboot`) is issued.  We're presently running v5.15.35 [0].
> 
> Good Evening,

Hi, Peter,

Thank you so much for your reply.

> That's definitely not stock v5.15.35, it's been tagged as an android kernel.
> 5.15.35-android13-5-00092-g525d77310a20

It's not stock, no.

Although the differences from RockPi's perspective are minimal.

The main difference is the way the kernel is configured.

It's GKI:

  https://android.googlesource.com/kernel/common/+/refs/heads/android13-5.15/arch/arm64/configs/gki_defconfig

Plus a few non-GKI specifics:

  https://android.googlesource.com/kernel/common/+/refs/heads/android13-5.15/arch/arm64/configs/rockpi4_gki.fragment

> > It's not clear how this issue (present 3 years ago) was finally
> > resolved.  From the thread, it looks as if the fix might have made its
> > way into ATF, but I'm 87.6% sure ATF is not running on this platform
> > (yet).
> 
> The rk3399 SoC has a hardware bug where the power domains are not
> reset upon a soft reset. This leads to situations like this one where
> power domains are shut down during shutdown but aren't restored on
> reboot.

I assume this isn't something we can patch in the kernel driver?

> Mainline TF-A was patched to force all power domains online
> when a soft reboot is triggered, which solved that issue.

Okay, this is what I figured.

> What particular issues are you having initializing modern u-boot on
> this device?

This is the output: https://pastebin.ubuntu.com/p/d5DmsSBnrR/

Speaking with one of the guys who supports RockPi 4 in AOSP, he
suspects the DDR settings.  Apparently settings for older SoCs
sometimes get clobbered when support for newer SoCs is added.

I am yet to investigate the u-boot story in any detail.

It's on my TODO list for today.

> Is there a particular reason it isn't using Mainline TF-A?

We're not using Trusted Firmware yet.

Although I'm starting to think this should be re-prioritised.

> I've also run into issues on rk356x where the regulator powering a
> power domain isn't powered due to a soft reset, which also causes
> faults like this. Set your main regulators to always-on and see if it
> helps with the issue.

I'll do that.  Thanks for the tip.

Our main issue currently is an RCU-lock-up, again on soft reboot:

[   21.226951][    C0] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[   21.227637][    C0] rcu:     5-...!: (1 GPs behind) idle=3de/1/0x4000000000000000 softirq=9/10 fqs=3 last_accelerate: 0000/efb9 dyntick_enabled: 0
[   21.228890][    C0]  (detected by 0, t=5252 jiffies, g=-1167, q=46)

Do you think these issues could all be related?

Thanks ever so much for your reply Peter.

You've potentially saved us hours and hours of debugging.

Kind regards,
Lee

> > Note that the u-boot we're using is also quite old:
> >
> >   U-Boot 2019.10-09248-g8511c75bb4 (Jan 08 2020 - 17:13:03 -0800)
> >
> > ... so this could easily be the root cause.  The current plan is to
> > try to update this ASAP.  However early attempts are yet to result in
> > a successful boot.
> >
> > I see that Brian recently added a few patches related to PD/DVFS, but
> > again, these appear to be ATF related.
> >
> > Would anyone be able to shed some light onto this for me please?
> >
> > As always, any help would be gratefully received.
> >
> > Kind regards,
> > Lee
> >
> > [0]
> > Full reboot log can be seen at: https://pastebin.ubuntu.com/p/MjZP2V6kQ3/
> >
> > [    0.699736][    T1] initcall __initstub__kmod_iommu__362_155_iommu_subsys_init4+0x0/0x8 returned 0 after 0 usecs
> > [    0.700737][    T1] calling  __initstub__kmod_rockchip_iommu__348_1415_rk_iommu_init4+0x0/0x8 @ 1
> > [    0.702238][    C5] SError Interrupt on CPU5, code 0xbf000002 -- SError
> > [    0.702248][    C5] CPU: 5 PID: 48 Comm: kworker/5:1 Not tainted 5.15.35-android13-5-00092-g525d77310a20 #1
> > [    0.702261][    C5] Hardware name: Radxa ROCK Pi 4B (DT)
> > [    0.702266][    C5] Workqueue: pm genpd_power_off_work_fn.cfi_jt
> > [    0.702289][    C5] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > [    0.702301][    C5] pc : regmap_mmio_read32le+0x14/0x2c
> > [    0.702318][    C5] lr : regmap_mmio_read+0x68/0xd0
> > [    0.702331][    C5] sp : ffffffc00b6d3b40
> > [    0.702335][    C5] x29: ffffffc00b6d3b40 x28: 0000000000000000 x27: 0000000000000000
> > [    0.702351][    C5] x26: ffffff8000923680 x25: ffffffc009abc2a0 x24: ffffff8000930c00
> > [    0.702364][    C5] x23: 0000000000000014 x22: ffffff8000930c00 x21: 0000000000000008
> > [    0.702378][    C5] x20: ffffff8000922300 x19: ffffff8000923680 x18: ffffffc00b66d058
> > [    0.702391][    C5] x17: 000000000000ba7e x16: ffffffc00a4dee04 x15: 000000000000b67e
> > [    0.702405][    C5] x14: 00000000028dd7a0 x13: 0000000000000040 x12: 0000000000000000
> > [    0.702419][    C5] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000005
> > [    0.702432][    C5] x8 : 0000000000000000 x7 : 00756d6d6f692e30 x6 : 3030383035366666
> > [    0.702445][    C5] x5 : 0000000000000001 x4 : 028dea248fba33d6 x3 : 0000000000000000
> > [    0.702457][    C5] x2 : ffffff8000923680 x1 : 0000000000000008 x0 : 0000000000000000
> > [    0.702472][    C5] Kernel panic - not syncing: Asynchronous SError Interrupt
> > [    0.702477][    C5] CPU: 5 PID: 48 Comm: kworker/5:1 Not tainted 5.15.35-android13-5-00092-g525d77310a20 #1
> > [    0.702487][    C5] Hardware name: Radxa ROCK Pi 4B (DT)
> > [    0.702492][    C5] Workqueue: pm genpd_power_off_work_fn.cfi_jt
> > [    0.702506][    C5] Call trace:
> > [    0.702508][    C5]  dump_backtrace.cfi_jt+0x0/0x8
> > [    0.702525][    C5]  dump_stack_lvl+0x80/0xb8
> > [    0.702536][    C5]  panic+0x180/0x444
> > [    0.702547][    C5]  arm64_serror_panic+0x1c0/0x210
> > [    0.702561][    C5]  do_serror+0x17c/0x218
> > [    0.702572][    C5]  el1h_64_error_handler+0x38/0x50
> > [    0.702581][    C5]  el1h_64_error+0x7c/0x80
> > [    0.702589][    C5]  regmap_mmio_read32le+0x14/0x2c
> > [    0.702603][    C5]  _regmap_bus_reg_read+0x3c/0x90
> > [    0.702614][    C5]  _regmap_read+0xb0/0x24c
> > [    0.702623][    C5]  rockchip_pd_power+0x6c4/0xbc0
> > [    0.702638][    C5]  rockchip_pd_power_off+0x18/0x28
> > [    0.702652][    C5]  _genpd_power_off+0x178/0x388
> > [    0.702663][    C5]  genpd_power_off+0x188/0x2e4
> > [    0.702673][    C5]  genpd_power_off_work_fn+0x54/0xe4
> > [    0.702683][    C5]  process_one_work+0x254/0x5a0
> > [    0.702696][    C5]  worker_thread+0x3ec/0x920
> > [    0.702707][    C5]  kthread+0x168/0x1dc
> > [    0.702716][    C5]  ret_from_fork+0x10/0x20
> > [    0.702726][    C5] SMP: stopping secondary CPUs
> >
> >
> > _______________________________________________
> > Linux-rockchip mailing list
> > Linux-rockchip@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-rockchip

-- 
Lee Jones [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround

[Peter Geis]

On Thu, May 19, 2022 at 4:17 AM Lee Jones <lee.jones@linaro.org> wrote:
>
> On Wed, 18 May 2022, Peter Geis wrote:
> > On Wed, May 18, 2022 at 7:56 AM Lee Jones <lee.jones@linaro.org> wrote:
> > >
> > > Looping int a few relevant/active kernel people/lists for full coverage.
> > >
> > > On Sun, 01 Dec 2019, Hugh Cole-Baker wrote:
> > > > > On 29 Nov 2019, at 01:06, Vasily Khoruzhick <anarsoul@gmail.com> wrote:
> > > > > On Thu, Nov 28, 2019 at 4:59 PM Kever Yang <kever.yang@rock-chips.com> wrote:
> > > > >>
> > > > >> Hi Vasily,
> > > > >>
> > > > >> On 2019/11/28 下午11:51, Vasily Khoruzhick wrote:
> > > > >>> On Thu, Nov 28, 2019 at 1:23 AM Kever Yang <kever.yang@rock-chips.com> wrote:
> > > > >>>> Hi Vasily,
> > > > >>>>
> > > > >>>>      I think this should not be needed, see comments below.
> > > > >>> Hi Kever,
> > > > >>>
> > > > >>> I've spent 2 weeks of my evenings debugging this issue but
> > > > >>
> > > > >> I can understand you work pretty hard on make it work, it's not so easy
> > > > >> to identify the root cause
> > > > >>
> > > > >> some times, thanks very much for working on this.
> > > > >>
> > > > >>> unfortunately I don't have a proper fix. This is the only solution
> > > > >>> that makes my rockpro64 reboot reliably with mainline u-boot and ATF.
> > > > >>> See my comments below.
> > > >
> > > > I also had a problem where Linux would hang or panic after rebooting, with
> > > > mainline u-boot and ATF on a rockpro64. This patch does fix the issue for me,
> > > > I have tested it by performing 10 reboots from Linux in a row and I've seen
> > > > no hangs or panics.
> > > >
> > > > I noticed the Armbian project have recently included a patch to ATF [1] which
> > > > switches all power domains on before ATF performs a soft reset. I have also
> > > > tested using u-boot mainline, without any patches to u-boot, but including ATF
> > > > patched with your reset fix [2] and the Armbian power domains patch [1]. This
> > > > also fixes the same hanging on reboot issue for me without modifications to
> > > > u-boot, I've also tested 10 reboots in a row with this ATF and seen no hangs.
> > > >
> > > > So this u-boot patch may not be needed if ATF is patched instead to switch
> > > > power domains on before soft reset.
> > > >
> > > > FWIW, when I was able to see panic messages from Linux when it panicked on
> > > > boot, the call trace always seemed to include rockchip_pd_power_off() [3].
> > > >
> > > > [1] https://github.com/armbian/build/blob/master/patch/atf/atf-rk3399/switch-power-domains-on-before-reset.patch
> > > > [2] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2512
> > > > [3] https://gist.github.com/sigmaris/c0e155c8cb0a325d84f549185f9a568c
> > >
> > > This last paste looks remarkably similar to an issue currently seen on
> > > the Radxa ROCK Pi 4B (RK3399) during power-up after a soft reboot
> > > (`sudo reboot`) is issued.  We're presently running v5.15.35 [0].
> >
> > Good Evening,
>
> Hi, Peter,
>
> Thank you so much for your reply.
>
> > That's definitely not stock v5.15.35, it's been tagged as an android kernel.
> > 5.15.35-android13-5-00092-g525d77310a20
>
> It's not stock, no.
>
> Although the differences from RockPi's perspective are minimal.
>
> The main difference is the way the kernel is configured.
>
> It's GKI:
>
>   https://android.googlesource.com/kernel/common/+/refs/heads/android13-5.15/arch/arm64/configs/gki_defconfig
>
> Plus a few non-GKI specifics:
>
>   https://android.googlesource.com/kernel/common/+/refs/heads/android13-5.15/arch/arm64/configs/rockpi4_gki.fragment

Ah, so close enough to not matter much.

>
> > > It's not clear how this issue (present 3 years ago) was finally
> > > resolved.  From the thread, it looks as if the fix might have made its
> > > way into ATF, but I'm 87.6% sure ATF is not running on this platform
> > > (yet).
> >
> > The rk3399 SoC has a hardware bug where the power domains are not
> > reset upon a soft reset. This leads to situations like this one where
> > power domains are shut down during shutdown but aren't restored on
> > reboot.
>
> I assume this isn't something we can patch in the kernel driver?

As far as I know it's being worked on by others, I have some ideas for
this as well but I've been focused on rk356x lately.

>
> > Mainline TF-A was patched to force all power domains online
> > when a soft reboot is triggered, which solved that issue.
>
> Okay, this is what I figured.
>
> > What particular issues are you having initializing modern u-boot on
> > this device?
>
> This is the output: https://pastebin.ubuntu.com/p/d5DmsSBnrR/
>
> Speaking with one of the guys who supports RockPi 4 in AOSP, he
> suspects the DDR settings.  Apparently settings for older SoCs
> sometimes get clobbered when support for newer SoCs is added.

The rk3399 TPL code is specific to the rk3399 and it really hasn't
been touched much recently. I'm using the latest Mainline U-Boot on
both my Rockpro64 and Pinephone-Pro. I don't see TF-A being loaded,
which should happen between:

Trying to boot from BOOTROM
Returning to boot ROM...

Otherwise it just looks like the TPL code doesn't like being in a
single channel configuration. Does the 2GB model just forgo the second
ram chip? Or is this actually a 4GB model and it isn't detecting the
second chip in both downstream and mainline? Could you include the
TPL/SPL portion of downstream's output?

>
> I am yet to investigate the u-boot story in any detail.
>
> It's on my TODO list for today.
>
> > Is there a particular reason it isn't using Mainline TF-A?
>
> We're not using Trusted Firmware yet.

This platform does not work at all without TF-A. Optee is optional.
Either you are using the downstream blob from Rockchip or Mainline
built yourself. Personally I prefer using Mainline everything. If you
build Mainline U-Boot without TF-A it will throw a warning at the end
that says the created binary is non-functional.

>
> Although I'm starting to think this should be re-prioritised.
>
> > I've also run into issues on rk356x where the regulator powering a
> > power domain isn't powered due to a soft reset, which also causes
> > faults like this. Set your main regulators to always-on and see if it
> > helps with the issue.
>
> I'll do that.  Thanks for the tip.
>
> Our main issue currently is an RCU-lock-up, again on soft reboot:
>
> [   21.226951][    C0] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
> [   21.227637][    C0] rcu:     5-...!: (1 GPs behind) idle=3de/1/0x4000000000000000 softirq=9/10 fqs=3 last_accelerate: 0000/efb9 dyntick_enabled: 0
> [   21.228890][    C0]  (detected by 0, t=5252 jiffies, g=-1167, q=46)
>
> Do you think these issues could all be related?

If you've powered down a minor power domain while a driver was still
active, sure.

>
> Thanks ever so much for your reply Peter.
>
> You've potentially saved us hours and hours of debugging.

Not a problem!

>
> Kind regards,
> Lee
>
> > > Note that the u-boot we're using is also quite old:
> > >
> > >   U-Boot 2019.10-09248-g8511c75bb4 (Jan 08 2020 - 17:13:03 -0800)
> > >
> > > ... so this could easily be the root cause.  The current plan is to
> > > try to update this ASAP.  However early attempts are yet to result in
> > > a successful boot.
> > >
> > > I see that Brian recently added a few patches related to PD/DVFS, but
> > > again, these appear to be ATF related.
> > >
> > > Would anyone be able to shed some light onto this for me please?
> > >
> > > As always, any help would be gratefully received.
> > >
> > > Kind regards,
> > > Lee
> > >
> > > [0]
> > > Full reboot log can be seen at: https://pastebin.ubuntu.com/p/MjZP2V6kQ3/
> > >
> > > [    0.699736][    T1] initcall __initstub__kmod_iommu__362_155_iommu_subsys_init4+0x0/0x8 returned 0 after 0 usecs
> > > [    0.700737][    T1] calling  __initstub__kmod_rockchip_iommu__348_1415_rk_iommu_init4+0x0/0x8 @ 1
> > > [    0.702238][    C5] SError Interrupt on CPU5, code 0xbf000002 -- SError
> > > [    0.702248][    C5] CPU: 5 PID: 48 Comm: kworker/5:1 Not tainted 5.15.35-android13-5-00092-g525d77310a20 #1
> > > [    0.702261][    C5] Hardware name: Radxa ROCK Pi 4B (DT)
> > > [    0.702266][    C5] Workqueue: pm genpd_power_off_work_fn.cfi_jt
> > > [    0.702289][    C5] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > > [    0.702301][    C5] pc : regmap_mmio_read32le+0x14/0x2c
> > > [    0.702318][    C5] lr : regmap_mmio_read+0x68/0xd0
> > > [    0.702331][    C5] sp : ffffffc00b6d3b40
> > > [    0.702335][    C5] x29: ffffffc00b6d3b40 x28: 0000000000000000 x27: 0000000000000000
> > > [    0.702351][    C5] x26: ffffff8000923680 x25: ffffffc009abc2a0 x24: ffffff8000930c00
> > > [    0.702364][    C5] x23: 0000000000000014 x22: ffffff8000930c00 x21: 0000000000000008
> > > [    0.702378][    C5] x20: ffffff8000922300 x19: ffffff8000923680 x18: ffffffc00b66d058
> > > [    0.702391][    C5] x17: 000000000000ba7e x16: ffffffc00a4dee04 x15: 000000000000b67e
> > > [    0.702405][    C5] x14: 00000000028dd7a0 x13: 0000000000000040 x12: 0000000000000000
> > > [    0.702419][    C5] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000005
> > > [    0.702432][    C5] x8 : 0000000000000000 x7 : 00756d6d6f692e30 x6 : 3030383035366666
> > > [    0.702445][    C5] x5 : 0000000000000001 x4 : 028dea248fba33d6 x3 : 0000000000000000
> > > [    0.702457][    C5] x2 : ffffff8000923680 x1 : 0000000000000008 x0 : 0000000000000000
> > > [    0.702472][    C5] Kernel panic - not syncing: Asynchronous SError Interrupt
> > > [    0.702477][    C5] CPU: 5 PID: 48 Comm: kworker/5:1 Not tainted 5.15.35-android13-5-00092-g525d77310a20 #1
> > > [    0.702487][    C5] Hardware name: Radxa ROCK Pi 4B (DT)
> > > [    0.702492][    C5] Workqueue: pm genpd_power_off_work_fn.cfi_jt
> > > [    0.702506][    C5] Call trace:
> > > [    0.702508][    C5]  dump_backtrace.cfi_jt+0x0/0x8
> > > [    0.702525][    C5]  dump_stack_lvl+0x80/0xb8
> > > [    0.702536][    C5]  panic+0x180/0x444
> > > [    0.702547][    C5]  arm64_serror_panic+0x1c0/0x210
> > > [    0.702561][    C5]  do_serror+0x17c/0x218
> > > [    0.702572][    C5]  el1h_64_error_handler+0x38/0x50
> > > [    0.702581][    C5]  el1h_64_error+0x7c/0x80
> > > [    0.702589][    C5]  regmap_mmio_read32le+0x14/0x2c
> > > [    0.702603][    C5]  _regmap_bus_reg_read+0x3c/0x90
> > > [    0.702614][    C5]  _regmap_read+0xb0/0x24c
> > > [    0.702623][    C5]  rockchip_pd_power+0x6c4/0xbc0
> > > [    0.702638][    C5]  rockchip_pd_power_off+0x18/0x28
> > > [    0.702652][    C5]  _genpd_power_off+0x178/0x388
> > > [    0.702663][    C5]  genpd_power_off+0x188/0x2e4
> > > [    0.702673][    C5]  genpd_power_off_work_fn+0x54/0xe4
> > > [    0.702683][    C5]  process_one_work+0x254/0x5a0
> > > [    0.702696][    C5]  worker_thread+0x3ec/0x920
> > > [    0.702707][    C5]  kthread+0x168/0x1dc
> > > [    0.702716][    C5]  ret_from_fork+0x10/0x20
> > > [    0.702726][    C5] SMP: stopping secondary CPUs
> > >
> > >
> > > _______________________________________________
> > > Linux-rockchip mailing list
> > > Linux-rockchip@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-rockchip
>
> --
> Lee Jones [李琼斯]
> Principal Technical Lead - Developer Services
> Linaro.org │ Open source software for Arm SoCs
> Follow Linaro: Facebook | Twitter | Blog

Re: [U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround

[Lee Jones]

> > > > It's not clear how this issue (present 3 years ago) was finally
> > > > resolved.  From the thread, it looks as if the fix might have made its
> > > > way into ATF, but I'm 87.6% sure ATF is not running on this platform
> > > > (yet).
> > >
> > > The rk3399 SoC has a hardware bug where the power domains are not
> > > reset upon a soft reset. This leads to situations like this one where
> > > power domains are shut down during shutdown but aren't restored on
> > > reboot.
> >
> > I assume this isn't something we can patch in the kernel driver?
> 
> As far as I know it's being worked on by others, I have some ideas for
> this as well but I've been focused on rk356x lately.

Thanks for the update.

> > > Mainline TF-A was patched to force all power domains online
> > > when a soft reboot is triggered, which solved that issue.
> >
> > Okay, this is what I figured.
> >
> > > What particular issues are you having initializing modern u-boot on
> > > this device?
> >
> > This is the output: https://pastebin.ubuntu.com/p/d5DmsSBnrR/
> >
> > Speaking with one of the guys who supports RockPi 4 in AOSP, he
> > suspects the DDR settings.  Apparently settings for older SoCs
> > sometimes get clobbered when support for newer SoCs is added.
> 
> The rk3399 TPL code is specific to the rk3399 and it really hasn't
> been touched much recently. I'm using the latest Mainline U-Boot on
> both my Rockpro64 and Pinephone-Pro. I don't see TF-A being loaded,
> which should happen between:
> 
> Trying to boot from BOOTROM
> Returning to boot ROM...
> 
> Otherwise it just looks like the TPL code doesn't like being in a
> single channel configuration. Does the 2GB model just forgo the second
> ram chip? Or is this actually a 4GB model and it isn't detecting the
> second chip in both downstream and mainline? Could you include the
> TPL/SPL portion of downstream's output?

TPL/SPL are mostly silent on the downstream build:

https://pastebin.ubuntu.com/p/m2bBdjF8Wq/

Not sure if it helps at all, but ArmBian is pretty noisy:

https://pastebin.ubuntu.com/p/fdPjmmqBDM/

> > I am yet to investigate the u-boot story in any detail.
> >
> > It's on my TODO list for today.
> >
> > > Is there a particular reason it isn't using Mainline TF-A?
> >
> > We're not using Trusted Firmware yet.
> 
> This platform does not work at all without TF-A. Optee is optional.
> Either you are using the downstream blob from Rockchip or Mainline
> built yourself. Personally I prefer using Mainline everything. If you
> build Mainline U-Boot without TF-A it will throw a warning at the end
> that says the created binary is non-functional.

Right.  Played a lot with this today.

Our build was using TF-A which was built-in to the primary loader.

I had 2 interesting results today.  No idea how to explain them.

First one was with Mainline u-boot and Mainline TF-A, which found, but
was seemingly unable to boot the kernel:

https://pastebin.ubuntu.com/p/9HRhPyfjYK/

The second interesting result I had was using our downstream u-boot
with Mainline TF-A.  It booted perfectly from cold, but managed to get
stuck in the TPL on soft reboot in a very similar way to the one I
reported earlier when not booting with TF-A ("Channel 1: col error"):

https://pastebin.ubuntu.com/p/hwmBzxDBgc/

Thanks again for your insight.

Kind regards,
Lee

-- 
Lee Jones [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround

[Peter Geis]

On Thu, May 19, 2022 at 10:56 AM Lee Jones <lee.jones@linaro.org> wrote:
>
> > > > > It's not clear how this issue (present 3 years ago) was finally
> > > > > resolved.  From the thread, it looks as if the fix might have made its
> > > > > way into ATF, but I'm 87.6% sure ATF is not running on this platform
> > > > > (yet).
> > > >
> > > > The rk3399 SoC has a hardware bug where the power domains are not
> > > > reset upon a soft reset. This leads to situations like this one where
> > > > power domains are shut down during shutdown but aren't restored on
> > > > reboot.
> > >
> > > I assume this isn't something we can patch in the kernel driver?
> >
> > As far as I know it's being worked on by others, I have some ideas for
> > this as well but I've been focused on rk356x lately.
>
> Thanks for the update.
>
> > > > Mainline TF-A was patched to force all power domains online
> > > > when a soft reboot is triggered, which solved that issue.
> > >
> > > Okay, this is what I figured.
> > >
> > > > What particular issues are you having initializing modern u-boot on
> > > > this device?
> > >
> > > This is the output: https://pastebin.ubuntu.com/p/d5DmsSBnrR/
> > >
> > > Speaking with one of the guys who supports RockPi 4 in AOSP, he
> > > suspects the DDR settings.  Apparently settings for older SoCs
> > > sometimes get clobbered when support for newer SoCs is added.
> >
> > The rk3399 TPL code is specific to the rk3399 and it really hasn't
> > been touched much recently. I'm using the latest Mainline U-Boot on
> > both my Rockpro64 and Pinephone-Pro. I don't see TF-A being loaded,
> > which should happen between:
> >
> > Trying to boot from BOOTROM
> > Returning to boot ROM...
> >
> > Otherwise it just looks like the TPL code doesn't like being in a
> > single channel configuration. Does the 2GB model just forgo the second
> > ram chip? Or is this actually a 4GB model and it isn't detecting the
> > second chip in both downstream and mainline? Could you include the
> > TPL/SPL portion of downstream's output?
>
> TPL/SPL are mostly silent on the downstream build:
>
> https://pastebin.ubuntu.com/p/m2bBdjF8Wq/
>
> Not sure if it helps at all, but ArmBian is pretty noisy:
>
> https://pastebin.ubuntu.com/p/fdPjmmqBDM/

Weird that downstream and mainline are being built with none of the
debug stuff enabled. Armbian clearly shows the initial setup occuring
correctly, and that it's a 4GB board. It's using both the Rockchip
miniloader with a Rockchip TF-A blob as well.

>
> > > I am yet to investigate the u-boot story in any detail.
> > >
> > > It's on my TODO list for today.
> > >
> > > > Is there a particular reason it isn't using Mainline TF-A?
> > >
> > > We're not using Trusted Firmware yet.
> >
> > This platform does not work at all without TF-A. Optee is optional.
> > Either you are using the downstream blob from Rockchip or Mainline
> > built yourself. Personally I prefer using Mainline everything. If you
> > build Mainline U-Boot without TF-A it will throw a warning at the end
> > that says the created binary is non-functional.
>
> Right.  Played a lot with this today.
>
> Our build was using TF-A which was built-in to the primary loader.
>
> I had 2 interesting results today.  No idea how to explain them.
>
> First one was with Mainline u-boot and Mainline TF-A, which found, but
> was seemingly unable to boot the kernel:
>
> https://pastebin.ubuntu.com/p/9HRhPyfjYK/
>
> The second interesting result I had was using our downstream u-boot
> with Mainline TF-A.  It booted perfectly from cold, but managed to get
> stuck in the TPL on soft reboot in a very similar way to the one I
> reported earlier when not booting with TF-A ("Channel 1: col error"):


Mainline TF-A defaults to 115200 for its uart messages, so you need to
either A. pass the uart config from U-Boot to TF-A with a platform
config option (unreliable in my experience), B. change U-Boot to
115200, or C. change TF-A to 1.5M (the path I take). Your mainline
hang is exactly where you expect to hang with a non-functional TF-A. I
enable some additional prints in my U-Boot tree to know exactly what
gets loaded during SPL. There are also debug prints you can enable in
TPL to get the setup results.

Would you be willing to run make savedefconfig from your mainline
setup and share the result?

>
> https://pastebin.ubuntu.com/p/hwmBzxDBgc/
>
> Thanks again for your insight.
>
> Kind regards,
> Lee
>
> --
> Lee Jones [李琼斯]
> Principal Technical Lead - Developer Services
> Linaro.org │ Open source software for Arm SoCs
> Follow Linaro: Facebook | Twitter | Blog

Re: [U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround

[Lee Jones]

On Thu, 19 May 2022, Peter Geis wrote:

> On Thu, May 19, 2022 at 10:56 AM Lee Jones <lee.jones@linaro.org> wrote:
> >
> > > > > > It's not clear how this issue (present 3 years ago) was finally
> > > > > > resolved.  From the thread, it looks as if the fix might have made its
> > > > > > way into ATF, but I'm 87.6% sure ATF is not running on this platform
> > > > > > (yet).
> > > > >
> > > > > The rk3399 SoC has a hardware bug where the power domains are not
> > > > > reset upon a soft reset. This leads to situations like this one where
> > > > > power domains are shut down during shutdown but aren't restored on
> > > > > reboot.
> > > >
> > > > I assume this isn't something we can patch in the kernel driver?
> > >
> > > As far as I know it's being worked on by others, I have some ideas for
> > > this as well but I've been focused on rk356x lately.
> >
> > Thanks for the update.
> >
> > > > > Mainline TF-A was patched to force all power domains online
> > > > > when a soft reboot is triggered, which solved that issue.
> > > >
> > > > Okay, this is what I figured.
> > > >
> > > > > What particular issues are you having initializing modern u-boot on
> > > > > this device?
> > > >
> > > > This is the output: https://pastebin.ubuntu.com/p/d5DmsSBnrR/
> > > >
> > > > Speaking with one of the guys who supports RockPi 4 in AOSP, he
> > > > suspects the DDR settings.  Apparently settings for older SoCs
> > > > sometimes get clobbered when support for newer SoCs is added.
> > >
> > > The rk3399 TPL code is specific to the rk3399 and it really hasn't
> > > been touched much recently. I'm using the latest Mainline U-Boot on
> > > both my Rockpro64 and Pinephone-Pro. I don't see TF-A being loaded,
> > > which should happen between:
> > >
> > > Trying to boot from BOOTROM
> > > Returning to boot ROM...
> > >
> > > Otherwise it just looks like the TPL code doesn't like being in a
> > > single channel configuration. Does the 2GB model just forgo the second
> > > ram chip? Or is this actually a 4GB model and it isn't detecting the
> > > second chip in both downstream and mainline? Could you include the
> > > TPL/SPL portion of downstream's output?
> >
> > TPL/SPL are mostly silent on the downstream build:
> >
> > https://pastebin.ubuntu.com/p/m2bBdjF8Wq/
> >
> > Not sure if it helps at all, but ArmBian is pretty noisy:
> >
> > https://pastebin.ubuntu.com/p/fdPjmmqBDM/
> 
> Weird that downstream and mainline are being built with none of the
> debug stuff enabled. Armbian clearly shows the initial setup occuring
> correctly, and that it's a 4GB board. It's using both the Rockchip
> miniloader with a Rockchip TF-A blob as well.
> 
> >
> > > > I am yet to investigate the u-boot story in any detail.
> > > >
> > > > It's on my TODO list for today.
> > > >
> > > > > Is there a particular reason it isn't using Mainline TF-A?
> > > >
> > > > We're not using Trusted Firmware yet.
> > >
> > > This platform does not work at all without TF-A. Optee is optional.
> > > Either you are using the downstream blob from Rockchip or Mainline
> > > built yourself. Personally I prefer using Mainline everything. If you
> > > build Mainline U-Boot without TF-A it will throw a warning at the end
> > > that says the created binary is non-functional.
> >
> > Right.  Played a lot with this today.
> >
> > Our build was using TF-A which was built-in to the primary loader.
> >
> > I had 2 interesting results today.  No idea how to explain them.
> >
> > First one was with Mainline u-boot and Mainline TF-A, which found, but
> > was seemingly unable to boot the kernel:
> >
> > https://pastebin.ubuntu.com/p/9HRhPyfjYK/
> >
> > The second interesting result I had was using our downstream u-boot
> > with Mainline TF-A.  It booted perfectly from cold, but managed to get
> > stuck in the TPL on soft reboot in a very similar way to the one I
> > reported earlier when not booting with TF-A ("Channel 1: col error"):
> 
> 
> Mainline TF-A defaults to 115200 for its uart messages, so you need to
> either A. pass the uart config from U-Boot to TF-A with a platform
> config option (unreliable in my experience), B. change U-Boot to
> 115200, or C. change TF-A to 1.5M (the path I take). Your mainline

Hopefully this is enough:

diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
index ba83242eb..24ad94ae7 100644
--- a/plat/rockchip/rk3399/rk3399_def.h
+++ b/plat/rockchip/rk3399/rk3399_def.h
@@ -17,7 +17,8 @@
 /**************************************************************************
  * UART related constants
  **************************************************************************/
-#define RK3399_BAUDRATE                        115200
+//#define RK3399_BAUDRATE                      115200
+#define RK3399_BAUDRATE                        1500000
 #define RK3399_UART_CLOCK              24000000
 
 /******************************************************************************

> hang is exactly where you expect to hang with a non-functional TF-A. I
> enable some additional prints in my U-Boot tree to know exactly what
> gets loaded during SPL. There are also debug prints you can enable in
> TPL to get the setup results.

Would you be kind enough to point me to the u-boot/TF-A prints please?

> Would you be willing to run make savedefconfig from your mainline
> setup and share the result?

u-boot or TF-A?

> > https://pastebin.ubuntu.com/p/hwmBzxDBgc/
> >
> > Thanks again for your insight.
> >
> > Kind regards,
> > Lee
> >

-- 
Lee Jones [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround

[Lee Jones]

On Thu, 19 May 2022, Lee Jones wrote:

> On Thu, 19 May 2022, Peter Geis wrote:
> 
> > On Thu, May 19, 2022 at 10:56 AM Lee Jones <lee.jones@linaro.org> wrote:
> > >
> > > > > > > It's not clear how this issue (present 3 years ago) was finally
> > > > > > > resolved.  From the thread, it looks as if the fix might have made its
> > > > > > > way into ATF, but I'm 87.6% sure ATF is not running on this platform
> > > > > > > (yet).
> > > > > >
> > > > > > The rk3399 SoC has a hardware bug where the power domains are not
> > > > > > reset upon a soft reset. This leads to situations like this one where
> > > > > > power domains are shut down during shutdown but aren't restored on
> > > > > > reboot.
> > > > >
> > > > > I assume this isn't something we can patch in the kernel driver?
> > > >
> > > > As far as I know it's being worked on by others, I have some ideas for
> > > > this as well but I've been focused on rk356x lately.
> > >
> > > Thanks for the update.
> > >
> > > > > > Mainline TF-A was patched to force all power domains online
> > > > > > when a soft reboot is triggered, which solved that issue.
> > > > >
> > > > > Okay, this is what I figured.
> > > > >
> > > > > > What particular issues are you having initializing modern u-boot on
> > > > > > this device?
> > > > >
> > > > > This is the output: https://pastebin.ubuntu.com/p/d5DmsSBnrR/
> > > > >
> > > > > Speaking with one of the guys who supports RockPi 4 in AOSP, he
> > > > > suspects the DDR settings.  Apparently settings for older SoCs
> > > > > sometimes get clobbered when support for newer SoCs is added.
> > > >
> > > > The rk3399 TPL code is specific to the rk3399 and it really hasn't
> > > > been touched much recently. I'm using the latest Mainline U-Boot on
> > > > both my Rockpro64 and Pinephone-Pro. I don't see TF-A being loaded,
> > > > which should happen between:
> > > >
> > > > Trying to boot from BOOTROM
> > > > Returning to boot ROM...
> > > >
> > > > Otherwise it just looks like the TPL code doesn't like being in a
> > > > single channel configuration. Does the 2GB model just forgo the second
> > > > ram chip? Or is this actually a 4GB model and it isn't detecting the
> > > > second chip in both downstream and mainline? Could you include the
> > > > TPL/SPL portion of downstream's output?
> > >
> > > TPL/SPL are mostly silent on the downstream build:
> > >
> > > https://pastebin.ubuntu.com/p/m2bBdjF8Wq/
> > >
> > > Not sure if it helps at all, but ArmBian is pretty noisy:
> > >
> > > https://pastebin.ubuntu.com/p/fdPjmmqBDM/
> > 
> > Weird that downstream and mainline are being built with none of the
> > debug stuff enabled. Armbian clearly shows the initial setup occuring
> > correctly, and that it's a 4GB board. It's using both the Rockchip
> > miniloader with a Rockchip TF-A blob as well.
> > 
> > >
> > > > > I am yet to investigate the u-boot story in any detail.
> > > > >
> > > > > It's on my TODO list for today.
> > > > >
> > > > > > Is there a particular reason it isn't using Mainline TF-A?
> > > > >
> > > > > We're not using Trusted Firmware yet.
> > > >
> > > > This platform does not work at all without TF-A. Optee is optional.
> > > > Either you are using the downstream blob from Rockchip or Mainline
> > > > built yourself. Personally I prefer using Mainline everything. If you
> > > > build Mainline U-Boot without TF-A it will throw a warning at the end
> > > > that says the created binary is non-functional.
> > >
> > > Right.  Played a lot with this today.
> > >
> > > Our build was using TF-A which was built-in to the primary loader.
> > >
> > > I had 2 interesting results today.  No idea how to explain them.
> > >
> > > First one was with Mainline u-boot and Mainline TF-A, which found, but
> > > was seemingly unable to boot the kernel:
> > >
> > > https://pastebin.ubuntu.com/p/9HRhPyfjYK/
> > >
> > > The second interesting result I had was using our downstream u-boot
> > > with Mainline TF-A.  It booted perfectly from cold, but managed to get
> > > stuck in the TPL on soft reboot in a very similar way to the one I
> > > reported earlier when not booting with TF-A ("Channel 1: col error"):
> > 
> > 
> > Mainline TF-A defaults to 115200 for its uart messages, so you need to
> > either A. pass the uart config from U-Boot to TF-A with a platform
> > config option (unreliable in my experience), B. change U-Boot to
> > 115200, or C. change TF-A to 1.5M (the path I take). Your mainline
> 
> Hopefully this is enough:
> 
> diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
> index ba83242eb..24ad94ae7 100644
> --- a/plat/rockchip/rk3399/rk3399_def.h
> +++ b/plat/rockchip/rk3399/rk3399_def.h
> @@ -17,7 +17,8 @@
>  /**************************************************************************
>   * UART related constants
>   **************************************************************************/
> -#define RK3399_BAUDRATE                        115200
> +//#define RK3399_BAUDRATE                      115200
> +#define RK3399_BAUDRATE                        1500000
>  #define RK3399_UART_CLOCK              24000000
>  
>  /******************************************************************************
> 
> > hang is exactly where you expect to hang with a non-functional TF-A. I
> > enable some additional prints in my U-Boot tree to know exactly what
> > gets loaded during SPL. There are also debug prints you can enable in
> > TPL to get the setup results.
> 
> Would you be kind enough to point me to the u-boot/TF-A prints please?
> 
> > Would you be willing to run make savedefconfig from your mainline
> > setup and share the result?
> 
> u-boot or TF-A?

Looks as though savedefconfig aren't u-boot or TF-A commands, so I'm
guessing you mean kernel:

https://termbin.com/rtr2

-- 
Lee Jones [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround

[Peter Geis]

On Thu, May 19, 2022 at 11:47 AM Lee Jones <lee.jones@linaro.org> wrote:
>
> On Thu, 19 May 2022, Lee Jones wrote:
>
> > On Thu, 19 May 2022, Peter Geis wrote:
> >
> > > On Thu, May 19, 2022 at 10:56 AM Lee Jones <lee.jones@linaro.org> wrote:
> > > >
> > > > > > > > It's not clear how this issue (present 3 years ago) was finally
> > > > > > > > resolved.  From the thread, it looks as if the fix might have made its
> > > > > > > > way into ATF, but I'm 87.6% sure ATF is not running on this platform
> > > > > > > > (yet).
> > > > > > >
> > > > > > > The rk3399 SoC has a hardware bug where the power domains are not
> > > > > > > reset upon a soft reset. This leads to situations like this one where
> > > > > > > power domains are shut down during shutdown but aren't restored on
> > > > > > > reboot.
> > > > > >
> > > > > > I assume this isn't something we can patch in the kernel driver?
> > > > >
> > > > > As far as I know it's being worked on by others, I have some ideas for
> > > > > this as well but I've been focused on rk356x lately.
> > > >
> > > > Thanks for the update.
> > > >
> > > > > > > Mainline TF-A was patched to force all power domains online
> > > > > > > when a soft reboot is triggered, which solved that issue.
> > > > > >
> > > > > > Okay, this is what I figured.
> > > > > >
> > > > > > > What particular issues are you having initializing modern u-boot on
> > > > > > > this device?
> > > > > >
> > > > > > This is the output: https://pastebin.ubuntu.com/p/d5DmsSBnrR/
> > > > > >
> > > > > > Speaking with one of the guys who supports RockPi 4 in AOSP, he
> > > > > > suspects the DDR settings.  Apparently settings for older SoCs
> > > > > > sometimes get clobbered when support for newer SoCs is added.
> > > > >
> > > > > The rk3399 TPL code is specific to the rk3399 and it really hasn't
> > > > > been touched much recently. I'm using the latest Mainline U-Boot on
> > > > > both my Rockpro64 and Pinephone-Pro. I don't see TF-A being loaded,
> > > > > which should happen between:
> > > > >
> > > > > Trying to boot from BOOTROM
> > > > > Returning to boot ROM...
> > > > >
> > > > > Otherwise it just looks like the TPL code doesn't like being in a
> > > > > single channel configuration. Does the 2GB model just forgo the second
> > > > > ram chip? Or is this actually a 4GB model and it isn't detecting the
> > > > > second chip in both downstream and mainline? Could you include the
> > > > > TPL/SPL portion of downstream's output?
> > > >
> > > > TPL/SPL are mostly silent on the downstream build:
> > > >
> > > > https://pastebin.ubuntu.com/p/m2bBdjF8Wq/
> > > >
> > > > Not sure if it helps at all, but ArmBian is pretty noisy:
> > > >
> > > > https://pastebin.ubuntu.com/p/fdPjmmqBDM/
> > >
> > > Weird that downstream and mainline are being built with none of the
> > > debug stuff enabled. Armbian clearly shows the initial setup occuring
> > > correctly, and that it's a 4GB board. It's using both the Rockchip
> > > miniloader with a Rockchip TF-A blob as well.
> > >
> > > >
> > > > > > I am yet to investigate the u-boot story in any detail.
> > > > > >
> > > > > > It's on my TODO list for today.
> > > > > >
> > > > > > > Is there a particular reason it isn't using Mainline TF-A?
> > > > > >
> > > > > > We're not using Trusted Firmware yet.
> > > > >
> > > > > This platform does not work at all without TF-A. Optee is optional.
> > > > > Either you are using the downstream blob from Rockchip or Mainline
> > > > > built yourself. Personally I prefer using Mainline everything. If you
> > > > > build Mainline U-Boot without TF-A it will throw a warning at the end
> > > > > that says the created binary is non-functional.
> > > >
> > > > Right.  Played a lot with this today.
> > > >
> > > > Our build was using TF-A which was built-in to the primary loader.
> > > >
> > > > I had 2 interesting results today.  No idea how to explain them.
> > > >
> > > > First one was with Mainline u-boot and Mainline TF-A, which found, but
> > > > was seemingly unable to boot the kernel:
> > > >
> > > > https://pastebin.ubuntu.com/p/9HRhPyfjYK/
> > > >
> > > > The second interesting result I had was using our downstream u-boot
> > > > with Mainline TF-A.  It booted perfectly from cold, but managed to get
> > > > stuck in the TPL on soft reboot in a very similar way to the one I
> > > > reported earlier when not booting with TF-A ("Channel 1: col error"):
> > >
> > >
> > > Mainline TF-A defaults to 115200 for its uart messages, so you need to
> > > either A. pass the uart config from U-Boot to TF-A with a platform
> > > config option (unreliable in my experience), B. change U-Boot to
> > > 115200, or C. change TF-A to 1.5M (the path I take). Your mainline
> >
> > Hopefully this is enough:
> >
> > diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
> > index ba83242eb..24ad94ae7 100644
> > --- a/plat/rockchip/rk3399/rk3399_def.h
> > +++ b/plat/rockchip/rk3399/rk3399_def.h
> > @@ -17,7 +17,8 @@
> >  /**************************************************************************
> >   * UART related constants
> >   **************************************************************************/
> > -#define RK3399_BAUDRATE                        115200
> > +//#define RK3399_BAUDRATE                      115200
> > +#define RK3399_BAUDRATE                        1500000
> >  #define RK3399_UART_CLOCK              24000000
> >
> >  /******************************************************************************

Yes, that is sufficient.

> >
> > > hang is exactly where you expect to hang with a non-functional TF-A. I
> > > enable some additional prints in my U-Boot tree to know exactly what
> > > gets loaded during SPL. There are also debug prints you can enable in
> > > TPL to get the setup results.
> >
> > Would you be kind enough to point me to the u-boot/TF-A prints please?
> >
> > > Would you be willing to run make savedefconfig from your mainline
> > > setup and share the result?
> >
> > u-boot or TF-A?
>
> Looks as though savedefconfig aren't u-boot or TF-A commands, so I'm
> guessing you mean kernel:
>
> https://termbin.com/rtr2

make savedefconfig causes the make system to output a defconfig file
in your current tree directory. It's a part of the kernel make system,
which also works in U-Boot mainline since it utilizes the same system.
It's how the configs in configs/ are generated. I can use that
simplified config to examine your current setup.

Or if you want to just host a git repository of your current U-Boot
mainline tree with an intact .config, that works as well.

>
> --
> Lee Jones [李琼斯]
> Principal Technical Lead - Developer Services
> Linaro.org │ Open source software for Arm SoCs
> Follow Linaro: Facebook | Twitter | Blog

Re: [U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround

[Lee Jones]

On Thu, 19 May 2022, Peter Geis wrote:

> On Thu, May 19, 2022 at 11:47 AM Lee Jones <lee.jones@linaro.org> wrote:
> >
> > On Thu, 19 May 2022, Lee Jones wrote:
> >
> > > On Thu, 19 May 2022, Peter Geis wrote:
> > >
> > > > On Thu, May 19, 2022 at 10:56 AM Lee Jones <lee.jones@linaro.org> wrote:
> > > > >
> > > > > > > > > It's not clear how this issue (present 3 years ago) was finally
> > > > > > > > > resolved.  From the thread, it looks as if the fix might have made its
> > > > > > > > > way into ATF, but I'm 87.6% sure ATF is not running on this platform
> > > > > > > > > (yet).
> > > > > > > >
> > > > > > > > The rk3399 SoC has a hardware bug where the power domains are not
> > > > > > > > reset upon a soft reset. This leads to situations like this one where
> > > > > > > > power domains are shut down during shutdown but aren't restored on
> > > > > > > > reboot.
> > > > > > >
> > > > > > > I assume this isn't something we can patch in the kernel driver?
> > > > > >
> > > > > > As far as I know it's being worked on by others, I have some ideas for
> > > > > > this as well but I've been focused on rk356x lately.
> > > > >
> > > > > Thanks for the update.
> > > > >
> > > > > > > > Mainline TF-A was patched to force all power domains online
> > > > > > > > when a soft reboot is triggered, which solved that issue.
> > > > > > >
> > > > > > > Okay, this is what I figured.
> > > > > > >
> > > > > > > > What particular issues are you having initializing modern u-boot on
> > > > > > > > this device?
> > > > > > >
> > > > > > > This is the output: https://pastebin.ubuntu.com/p/d5DmsSBnrR/
> > > > > > >
> > > > > > > Speaking with one of the guys who supports RockPi 4 in AOSP, he
> > > > > > > suspects the DDR settings.  Apparently settings for older SoCs
> > > > > > > sometimes get clobbered when support for newer SoCs is added.
> > > > > >
> > > > > > The rk3399 TPL code is specific to the rk3399 and it really hasn't
> > > > > > been touched much recently. I'm using the latest Mainline U-Boot on
> > > > > > both my Rockpro64 and Pinephone-Pro. I don't see TF-A being loaded,
> > > > > > which should happen between:
> > > > > >
> > > > > > Trying to boot from BOOTROM
> > > > > > Returning to boot ROM...
> > > > > >
> > > > > > Otherwise it just looks like the TPL code doesn't like being in a
> > > > > > single channel configuration. Does the 2GB model just forgo the second
> > > > > > ram chip? Or is this actually a 4GB model and it isn't detecting the
> > > > > > second chip in both downstream and mainline? Could you include the
> > > > > > TPL/SPL portion of downstream's output?
> > > > >
> > > > > TPL/SPL are mostly silent on the downstream build:
> > > > >
> > > > > https://pastebin.ubuntu.com/p/m2bBdjF8Wq/
> > > > >
> > > > > Not sure if it helps at all, but ArmBian is pretty noisy:
> > > > >
> > > > > https://pastebin.ubuntu.com/p/fdPjmmqBDM/
> > > >
> > > > Weird that downstream and mainline are being built with none of the
> > > > debug stuff enabled. Armbian clearly shows the initial setup occuring
> > > > correctly, and that it's a 4GB board. It's using both the Rockchip
> > > > miniloader with a Rockchip TF-A blob as well.
> > > >
> > > > >
> > > > > > > I am yet to investigate the u-boot story in any detail.
> > > > > > >
> > > > > > > It's on my TODO list for today.
> > > > > > >
> > > > > > > > Is there a particular reason it isn't using Mainline TF-A?
> > > > > > >
> > > > > > > We're not using Trusted Firmware yet.
> > > > > >
> > > > > > This platform does not work at all without TF-A. Optee is optional.
> > > > > > Either you are using the downstream blob from Rockchip or Mainline
> > > > > > built yourself. Personally I prefer using Mainline everything. If you
> > > > > > build Mainline U-Boot without TF-A it will throw a warning at the end
> > > > > > that says the created binary is non-functional.
> > > > >
> > > > > Right.  Played a lot with this today.
> > > > >
> > > > > Our build was using TF-A which was built-in to the primary loader.
> > > > >
> > > > > I had 2 interesting results today.  No idea how to explain them.
> > > > >
> > > > > First one was with Mainline u-boot and Mainline TF-A, which found, but
> > > > > was seemingly unable to boot the kernel:
> > > > >
> > > > > https://pastebin.ubuntu.com/p/9HRhPyfjYK/
> > > > >
> > > > > The second interesting result I had was using our downstream u-boot
> > > > > with Mainline TF-A.  It booted perfectly from cold, but managed to get
> > > > > stuck in the TPL on soft reboot in a very similar way to the one I
> > > > > reported earlier when not booting with TF-A ("Channel 1: col error"):
> > > >
> > > >
> > > > Mainline TF-A defaults to 115200 for its uart messages, so you need to
> > > > either A. pass the uart config from U-Boot to TF-A with a platform
> > > > config option (unreliable in my experience), B. change U-Boot to
> > > > 115200, or C. change TF-A to 1.5M (the path I take). Your mainline
> > >
> > > Hopefully this is enough:
> > >
> > > diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
> > > index ba83242eb..24ad94ae7 100644
> > > --- a/plat/rockchip/rk3399/rk3399_def.h
> > > +++ b/plat/rockchip/rk3399/rk3399_def.h
> > > @@ -17,7 +17,8 @@
> > >  /**************************************************************************
> > >   * UART related constants
> > >   **************************************************************************/
> > > -#define RK3399_BAUDRATE                        115200
> > > +//#define RK3399_BAUDRATE                      115200
> > > +#define RK3399_BAUDRATE                        1500000
> > >  #define RK3399_UART_CLOCK              24000000
> > >
> > >  /******************************************************************************
> 
> Yes, that is sufficient.
> 
> > >
> > > > hang is exactly where you expect to hang with a non-functional TF-A. I
> > > > enable some additional prints in my U-Boot tree to know exactly what
> > > > gets loaded during SPL. There are also debug prints you can enable in
> > > > TPL to get the setup results.
> > >
> > > Would you be kind enough to point me to the u-boot/TF-A prints please?
> > >
> > > > Would you be willing to run make savedefconfig from your mainline
> > > > setup and share the result?
> > >
> > > u-boot or TF-A?
> >
> > Looks as though savedefconfig aren't u-boot or TF-A commands, so I'm
> > guessing you mean kernel:
> >
> > https://termbin.com/rtr2
> 
> make savedefconfig causes the make system to output a defconfig file
> in your current tree directory. It's a part of the kernel make system,
> which also works in U-Boot mainline since it utilizes the same system.
> It's how the configs in configs/ are generated.

Yes, I know what savedefconfig does. :)

> I can use that simplified config to examine your current setup.

I'm afraid it's not as easy as that.  The build system I'm using is
wrapped up in Android build-system-ness.  I'll have a look to see if I
can roll a defconfig by hand some how.

> Or if you want to just host a git repository of your current U-Boot
> mainline tree with an intact .config, that works as well.

Okay, so it's the u-boot defconfig you're after.

And Mainline, right, not our Android one?

-- 
Lee Jones [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround

[Lee Jones]

On Thu, 19 May 2022, Lee Jones wrote:

> On Thu, 19 May 2022, Peter Geis wrote:
> 
> > On Thu, May 19, 2022 at 11:47 AM Lee Jones <lee.jones@linaro.org> wrote:
> > >
> > > On Thu, 19 May 2022, Lee Jones wrote:
> > >
> > > > On Thu, 19 May 2022, Peter Geis wrote:
> > > >
> > > > > On Thu, May 19, 2022 at 10:56 AM Lee Jones <lee.jones@linaro.org> wrote:
> > > > > >
> > > > > > > > > > It's not clear how this issue (present 3 years ago) was finally
> > > > > > > > > > resolved.  From the thread, it looks as if the fix might have made its
> > > > > > > > > > way into ATF, but I'm 87.6% sure ATF is not running on this platform
> > > > > > > > > > (yet).
> > > > > > > > >
> > > > > > > > > The rk3399 SoC has a hardware bug where the power domains are not
> > > > > > > > > reset upon a soft reset. This leads to situations like this one where
> > > > > > > > > power domains are shut down during shutdown but aren't restored on
> > > > > > > > > reboot.
> > > > > > > >
> > > > > > > > I assume this isn't something we can patch in the kernel driver?
> > > > > > >
> > > > > > > As far as I know it's being worked on by others, I have some ideas for
> > > > > > > this as well but I've been focused on rk356x lately.
> > > > > >
> > > > > > Thanks for the update.
> > > > > >
> > > > > > > > > Mainline TF-A was patched to force all power domains online
> > > > > > > > > when a soft reboot is triggered, which solved that issue.
> > > > > > > >
> > > > > > > > Okay, this is what I figured.
> > > > > > > >
> > > > > > > > > What particular issues are you having initializing modern u-boot on
> > > > > > > > > this device?
> > > > > > > >
> > > > > > > > This is the output: https://pastebin.ubuntu.com/p/d5DmsSBnrR/
> > > > > > > >
> > > > > > > > Speaking with one of the guys who supports RockPi 4 in AOSP, he
> > > > > > > > suspects the DDR settings.  Apparently settings for older SoCs
> > > > > > > > sometimes get clobbered when support for newer SoCs is added.
> > > > > > >
> > > > > > > The rk3399 TPL code is specific to the rk3399 and it really hasn't
> > > > > > > been touched much recently. I'm using the latest Mainline U-Boot on
> > > > > > > both my Rockpro64 and Pinephone-Pro. I don't see TF-A being loaded,
> > > > > > > which should happen between:
> > > > > > >
> > > > > > > Trying to boot from BOOTROM
> > > > > > > Returning to boot ROM...
> > > > > > >
> > > > > > > Otherwise it just looks like the TPL code doesn't like being in a
> > > > > > > single channel configuration. Does the 2GB model just forgo the second
> > > > > > > ram chip? Or is this actually a 4GB model and it isn't detecting the
> > > > > > > second chip in both downstream and mainline? Could you include the
> > > > > > > TPL/SPL portion of downstream's output?
> > > > > >
> > > > > > TPL/SPL are mostly silent on the downstream build:
> > > > > >
> > > > > > https://pastebin.ubuntu.com/p/m2bBdjF8Wq/
> > > > > >
> > > > > > Not sure if it helps at all, but ArmBian is pretty noisy:
> > > > > >
> > > > > > https://pastebin.ubuntu.com/p/fdPjmmqBDM/
> > > > >
> > > > > Weird that downstream and mainline are being built with none of the
> > > > > debug stuff enabled. Armbian clearly shows the initial setup occuring
> > > > > correctly, and that it's a 4GB board. It's using both the Rockchip
> > > > > miniloader with a Rockchip TF-A blob as well.
> > > > >
> > > > > >
> > > > > > > > I am yet to investigate the u-boot story in any detail.
> > > > > > > >
> > > > > > > > It's on my TODO list for today.
> > > > > > > >
> > > > > > > > > Is there a particular reason it isn't using Mainline TF-A?
> > > > > > > >
> > > > > > > > We're not using Trusted Firmware yet.
> > > > > > >
> > > > > > > This platform does not work at all without TF-A. Optee is optional.
> > > > > > > Either you are using the downstream blob from Rockchip or Mainline
> > > > > > > built yourself. Personally I prefer using Mainline everything. If you
> > > > > > > build Mainline U-Boot without TF-A it will throw a warning at the end
> > > > > > > that says the created binary is non-functional.
> > > > > >
> > > > > > Right.  Played a lot with this today.
> > > > > >
> > > > > > Our build was using TF-A which was built-in to the primary loader.
> > > > > >
> > > > > > I had 2 interesting results today.  No idea how to explain them.
> > > > > >
> > > > > > First one was with Mainline u-boot and Mainline TF-A, which found, but
> > > > > > was seemingly unable to boot the kernel:
> > > > > >
> > > > > > https://pastebin.ubuntu.com/p/9HRhPyfjYK/
> > > > > >
> > > > > > The second interesting result I had was using our downstream u-boot
> > > > > > with Mainline TF-A.  It booted perfectly from cold, but managed to get
> > > > > > stuck in the TPL on soft reboot in a very similar way to the one I
> > > > > > reported earlier when not booting with TF-A ("Channel 1: col error"):
> > > > >
> > > > >
> > > > > Mainline TF-A defaults to 115200 for its uart messages, so you need to
> > > > > either A. pass the uart config from U-Boot to TF-A with a platform
> > > > > config option (unreliable in my experience), B. change U-Boot to
> > > > > 115200, or C. change TF-A to 1.5M (the path I take). Your mainline
> > > >
> > > > Hopefully this is enough:
> > > >
> > > > diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
> > > > index ba83242eb..24ad94ae7 100644
> > > > --- a/plat/rockchip/rk3399/rk3399_def.h
> > > > +++ b/plat/rockchip/rk3399/rk3399_def.h
> > > > @@ -17,7 +17,8 @@
> > > >  /**************************************************************************
> > > >   * UART related constants
> > > >   **************************************************************************/
> > > > -#define RK3399_BAUDRATE                        115200
> > > > +//#define RK3399_BAUDRATE                      115200
> > > > +#define RK3399_BAUDRATE                        1500000
> > > >  #define RK3399_UART_CLOCK              24000000
> > > >
> > > >  /******************************************************************************
> > 
> > Yes, that is sufficient.

That's interesting.  Would this change result in me now being able to
see the console output from this (apparently) failed attempt:

https://pastebin.ubuntu.com/p/9HRhPyfjYK/

However the result is the same as the downstream kernel where it
fails in the TPL on soft reboot:

https://pastebin.ubuntu.com/p/TZBYqTMCnN/

No TF-A messages seen though still.

Is it possible that u-boot only runs TF-A on cold boot?  Seems odd.

What was the extra logging you mentioned before?

-- 
Lee Jones [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround

[Peter Geis]

On Thu, May 19, 2022 at 1:23 PM Lee Jones <lee.jones@linaro.org> wrote:
>
> On Thu, 19 May 2022, Lee Jones wrote:
>
> > On Thu, 19 May 2022, Peter Geis wrote:
> >
> > > On Thu, May 19, 2022 at 11:47 AM Lee Jones <lee.jones@linaro.org> wrote:
> > > >
> > > > On Thu, 19 May 2022, Lee Jones wrote:
> > > >
> > > > > On Thu, 19 May 2022, Peter Geis wrote:
> > > > >
> > > > > > On Thu, May 19, 2022 at 10:56 AM Lee Jones <lee.jones@linaro.org> wrote:
> > > > > > >
> > > > > > > > > > > It's not clear how this issue (present 3 years ago) was finally
> > > > > > > > > > > resolved.  From the thread, it looks as if the fix might have made its
> > > > > > > > > > > way into ATF, but I'm 87.6% sure ATF is not running on this platform
> > > > > > > > > > > (yet).
> > > > > > > > > >
> > > > > > > > > > The rk3399 SoC has a hardware bug where the power domains are not
> > > > > > > > > > reset upon a soft reset. This leads to situations like this one where
> > > > > > > > > > power domains are shut down during shutdown but aren't restored on
> > > > > > > > > > reboot.
> > > > > > > > >
> > > > > > > > > I assume this isn't something we can patch in the kernel driver?
> > > > > > > >
> > > > > > > > As far as I know it's being worked on by others, I have some ideas for
> > > > > > > > this as well but I've been focused on rk356x lately.
> > > > > > >
> > > > > > > Thanks for the update.
> > > > > > >
> > > > > > > > > > Mainline TF-A was patched to force all power domains online
> > > > > > > > > > when a soft reboot is triggered, which solved that issue.
> > > > > > > > >
> > > > > > > > > Okay, this is what I figured.
> > > > > > > > >
> > > > > > > > > > What particular issues are you having initializing modern u-boot on
> > > > > > > > > > this device?
> > > > > > > > >
> > > > > > > > > This is the output: https://pastebin.ubuntu.com/p/d5DmsSBnrR/
> > > > > > > > >
> > > > > > > > > Speaking with one of the guys who supports RockPi 4 in AOSP, he
> > > > > > > > > suspects the DDR settings.  Apparently settings for older SoCs
> > > > > > > > > sometimes get clobbered when support for newer SoCs is added.
> > > > > > > >
> > > > > > > > The rk3399 TPL code is specific to the rk3399 and it really hasn't
> > > > > > > > been touched much recently. I'm using the latest Mainline U-Boot on
> > > > > > > > both my Rockpro64 and Pinephone-Pro. I don't see TF-A being loaded,
> > > > > > > > which should happen between:
> > > > > > > >
> > > > > > > > Trying to boot from BOOTROM
> > > > > > > > Returning to boot ROM...
> > > > > > > >
> > > > > > > > Otherwise it just looks like the TPL code doesn't like being in a
> > > > > > > > single channel configuration. Does the 2GB model just forgo the second
> > > > > > > > ram chip? Or is this actually a 4GB model and it isn't detecting the
> > > > > > > > second chip in both downstream and mainline? Could you include the
> > > > > > > > TPL/SPL portion of downstream's output?
> > > > > > >
> > > > > > > TPL/SPL are mostly silent on the downstream build:
> > > > > > >
> > > > > > > https://pastebin.ubuntu.com/p/m2bBdjF8Wq/
> > > > > > >
> > > > > > > Not sure if it helps at all, but ArmBian is pretty noisy:
> > > > > > >
> > > > > > > https://pastebin.ubuntu.com/p/fdPjmmqBDM/
> > > > > >
> > > > > > Weird that downstream and mainline are being built with none of the
> > > > > > debug stuff enabled. Armbian clearly shows the initial setup occuring
> > > > > > correctly, and that it's a 4GB board. It's using both the Rockchip
> > > > > > miniloader with a Rockchip TF-A blob as well.
> > > > > >
> > > > > > >
> > > > > > > > > I am yet to investigate the u-boot story in any detail.
> > > > > > > > >
> > > > > > > > > It's on my TODO list for today.
> > > > > > > > >
> > > > > > > > > > Is there a particular reason it isn't using Mainline TF-A?
> > > > > > > > >
> > > > > > > > > We're not using Trusted Firmware yet.
> > > > > > > >
> > > > > > > > This platform does not work at all without TF-A. Optee is optional.
> > > > > > > > Either you are using the downstream blob from Rockchip or Mainline
> > > > > > > > built yourself. Personally I prefer using Mainline everything. If you
> > > > > > > > build Mainline U-Boot without TF-A it will throw a warning at the end
> > > > > > > > that says the created binary is non-functional.
> > > > > > >
> > > > > > > Right.  Played a lot with this today.
> > > > > > >
> > > > > > > Our build was using TF-A which was built-in to the primary loader.
> > > > > > >
> > > > > > > I had 2 interesting results today.  No idea how to explain them.
> > > > > > >
> > > > > > > First one was with Mainline u-boot and Mainline TF-A, which found, but
> > > > > > > was seemingly unable to boot the kernel:
> > > > > > >
> > > > > > > https://pastebin.ubuntu.com/p/9HRhPyfjYK/
> > > > > > >
> > > > > > > The second interesting result I had was using our downstream u-boot
> > > > > > > with Mainline TF-A.  It booted perfectly from cold, but managed to get
> > > > > > > stuck in the TPL on soft reboot in a very similar way to the one I
> > > > > > > reported earlier when not booting with TF-A ("Channel 1: col error"):
> > > > > >
> > > > > >
> > > > > > Mainline TF-A defaults to 115200 for its uart messages, so you need to
> > > > > > either A. pass the uart config from U-Boot to TF-A with a platform
> > > > > > config option (unreliable in my experience), B. change U-Boot to
> > > > > > 115200, or C. change TF-A to 1.5M (the path I take). Your mainline
> > > > >
> > > > > Hopefully this is enough:
> > > > >
> > > > > diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
> > > > > index ba83242eb..24ad94ae7 100644
> > > > > --- a/plat/rockchip/rk3399/rk3399_def.h
> > > > > +++ b/plat/rockchip/rk3399/rk3399_def.h
> > > > > @@ -17,7 +17,8 @@
> > > > >  /**************************************************************************
> > > > >   * UART related constants
> > > > >   **************************************************************************/
> > > > > -#define RK3399_BAUDRATE                        115200
> > > > > +//#define RK3399_BAUDRATE                      115200
> > > > > +#define RK3399_BAUDRATE                        1500000
> > > > >  #define RK3399_UART_CLOCK              24000000
> > > > >
> > > > >  /******************************************************************************
> > >
> > > Yes, that is sufficient.
>
> That's interesting.  Would this change result in me now being able to
> see the console output from this (apparently) failed attempt:
>
> https://pastebin.ubuntu.com/p/9HRhPyfjYK/
>
> However the result is the same as the downstream kernel where it
> fails in the TPL on soft reboot:
>
> https://pastebin.ubuntu.com/p/TZBYqTMCnN/
>
> No TF-A messages seen though still.
>
> Is it possible that u-boot only runs TF-A on cold boot?  Seems odd.

I'm convinced that TF-A is not functional on your mainline config. No,
TF-A will execute on any reset that triggers SPL, as SPL loads TF-A
and jumps to it as part of the FIT load.

>
> What was the extra logging you mentioned before?

This is what my rockpro64 looks like with TF-A executing. Note I've
enabled a bit of extra TF-A debugging, normally it just prints out the
TF-A version number. TF-A reports itself as BL31.

U-Boot TPL 2022.04-rc2-00234-g017a8901ae3a-dirty (Mar 02 2022 - 18:36:55)
Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
Channel 1: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
256B stride
lpddr4_set_rate: change freq to 400000000 mhz 0, 1
lpddr4_set_rate: change freq to 800000000 mhz 1, 0
Trying to boot from BOOTROM
Returning to boot ROM...
rockchip_sdram_size ff320308 32c1f2c1
rank 1 cs0_col 10 bk 3 cs0_row 16 bw 2 row_3_4 0
rank 1 cs0_col 10 bk 3 cs0_row 16 bw 2 row_3_4 0
SDRAM base=0, size=100000000

U-Boot SPL 2022.04-rc2-00234-g017a8901ae3a-dirty (Mar 02 2022 - 18:36:55 -0500)
Trying to boot from MMC2
NOTICE:  BL31: v2.6(release):v2.6-138-g929f064f69d0-dirty
NOTICE:  BL31: Built : 11:27:48, Feb  2 2022
INFO:    GICv3 with legacy support detected.
INFO:    ARM GICv3 driver initialized in EL3
INFO:    Maximum SPI INTID supported: 287
INFO:    plat_rockchip_pmu_init(1710): pd status 3e
INFO:    BL31: Initializing runtime services
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x200000
INFO:    SPSR = 0x3c9


U-Boot 2022.04-rc2-00234-g017a8901ae3a-dirty (Mar 02 2022 - 18:36:55 -0500)

SoC: Rockchip rk3399
Reset cause: POR
Model: Pine64 RockPro64 v2.1
DRAM:  rockchip_sdram_size ff320308 32c1f2c1
rank 1 cs0_col 10 bk 3 cs0_row 16 bw 2 row_3_4 0
rank 1 cs0_col 10 bk 3 cs0_row 16 bw 2 row_3_4 0
SDRAM base=0, size=100000000
3.9 GiB
PMIC:  RK808
Core:  292 devices, 29 uclasses, devicetree: separate
MMC:   mmc@fe310000: 3, mmc@fe320000: 1, mmc@fe330000: 0
Loading Environment from SPIFlash... SF: Detected gd25q128 with page
size 256 Bytes, erase size 4 KiB, total 16 MiB
*** Warning - bad CRC, using default environment

I'm currently pulling the rk3399-rock-pi-4b.dts that's in mainline
linux to build a quick image for you, if you're interested.

>
> --
> Lee Jones [李琼斯]
> Principal Technical Lead - Developer Services
> Linaro.org │ Open source software for Arm SoCs
> Follow Linaro: Facebook | Twitter | Blog

Re: [U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround

[Peter Geis]

On Thu, May 19, 2022 at 1:36 PM Peter Geis <pgwipeout@gmail.com> wrote:
>
> On Thu, May 19, 2022 at 1:23 PM Lee Jones <lee.jones@linaro.org> wrote:
> >
> > On Thu, 19 May 2022, Lee Jones wrote:
> >
> > > On Thu, 19 May 2022, Peter Geis wrote:
> > >
> > > > On Thu, May 19, 2022 at 11:47 AM Lee Jones <lee.jones@linaro.org> wrote:
> > > > >
> > > > > On Thu, 19 May 2022, Lee Jones wrote:
> > > > >
> > > > > > On Thu, 19 May 2022, Peter Geis wrote:
> > > > > >
> > > > > > > On Thu, May 19, 2022 at 10:56 AM Lee Jones <lee.jones@linaro.org> wrote:
> > > > > > > >
> > > > > > > > > > > > It's not clear how this issue (present 3 years ago) was finally
> > > > > > > > > > > > resolved.  From the thread, it looks as if the fix might have made its
> > > > > > > > > > > > way into ATF, but I'm 87.6% sure ATF is not running on this platform
> > > > > > > > > > > > (yet).
> > > > > > > > > > >
> > > > > > > > > > > The rk3399 SoC has a hardware bug where the power domains are not
> > > > > > > > > > > reset upon a soft reset. This leads to situations like this one where
> > > > > > > > > > > power domains are shut down during shutdown but aren't restored on
> > > > > > > > > > > reboot.
> > > > > > > > > >
> > > > > > > > > > I assume this isn't something we can patch in the kernel driver?
> > > > > > > > >
> > > > > > > > > As far as I know it's being worked on by others, I have some ideas for
> > > > > > > > > this as well but I've been focused on rk356x lately.
> > > > > > > >
> > > > > > > > Thanks for the update.
> > > > > > > >
> > > > > > > > > > > Mainline TF-A was patched to force all power domains online
> > > > > > > > > > > when a soft reboot is triggered, which solved that issue.
> > > > > > > > > >
> > > > > > > > > > Okay, this is what I figured.
> > > > > > > > > >
> > > > > > > > > > > What particular issues are you having initializing modern u-boot on
> > > > > > > > > > > this device?
> > > > > > > > > >
> > > > > > > > > > This is the output: https://pastebin.ubuntu.com/p/d5DmsSBnrR/
> > > > > > > > > >
> > > > > > > > > > Speaking with one of the guys who supports RockPi 4 in AOSP, he
> > > > > > > > > > suspects the DDR settings.  Apparently settings for older SoCs
> > > > > > > > > > sometimes get clobbered when support for newer SoCs is added.
> > > > > > > > >
> > > > > > > > > The rk3399 TPL code is specific to the rk3399 and it really hasn't
> > > > > > > > > been touched much recently. I'm using the latest Mainline U-Boot on
> > > > > > > > > both my Rockpro64 and Pinephone-Pro. I don't see TF-A being loaded,
> > > > > > > > > which should happen between:
> > > > > > > > >
> > > > > > > > > Trying to boot from BOOTROM
> > > > > > > > > Returning to boot ROM...
> > > > > > > > >
> > > > > > > > > Otherwise it just looks like the TPL code doesn't like being in a
> > > > > > > > > single channel configuration. Does the 2GB model just forgo the second
> > > > > > > > > ram chip? Or is this actually a 4GB model and it isn't detecting the
> > > > > > > > > second chip in both downstream and mainline? Could you include the
> > > > > > > > > TPL/SPL portion of downstream's output?
> > > > > > > >
> > > > > > > > TPL/SPL are mostly silent on the downstream build:
> > > > > > > >
> > > > > > > > https://pastebin.ubuntu.com/p/m2bBdjF8Wq/
> > > > > > > >
> > > > > > > > Not sure if it helps at all, but ArmBian is pretty noisy:
> > > > > > > >
> > > > > > > > https://pastebin.ubuntu.com/p/fdPjmmqBDM/
> > > > > > >
> > > > > > > Weird that downstream and mainline are being built with none of the
> > > > > > > debug stuff enabled. Armbian clearly shows the initial setup occuring
> > > > > > > correctly, and that it's a 4GB board. It's using both the Rockchip
> > > > > > > miniloader with a Rockchip TF-A blob as well.
> > > > > > >
> > > > > > > >
> > > > > > > > > > I am yet to investigate the u-boot story in any detail.
> > > > > > > > > >
> > > > > > > > > > It's on my TODO list for today.
> > > > > > > > > >
> > > > > > > > > > > Is there a particular reason it isn't using Mainline TF-A?
> > > > > > > > > >
> > > > > > > > > > We're not using Trusted Firmware yet.
> > > > > > > > >
> > > > > > > > > This platform does not work at all without TF-A. Optee is optional.
> > > > > > > > > Either you are using the downstream blob from Rockchip or Mainline
> > > > > > > > > built yourself. Personally I prefer using Mainline everything. If you
> > > > > > > > > build Mainline U-Boot without TF-A it will throw a warning at the end
> > > > > > > > > that says the created binary is non-functional.
> > > > > > > >
> > > > > > > > Right.  Played a lot with this today.
> > > > > > > >
> > > > > > > > Our build was using TF-A which was built-in to the primary loader.
> > > > > > > >
> > > > > > > > I had 2 interesting results today.  No idea how to explain them.
> > > > > > > >
> > > > > > > > First one was with Mainline u-boot and Mainline TF-A, which found, but
> > > > > > > > was seemingly unable to boot the kernel:
> > > > > > > >
> > > > > > > > https://pastebin.ubuntu.com/p/9HRhPyfjYK/
> > > > > > > >
> > > > > > > > The second interesting result I had was using our downstream u-boot
> > > > > > > > with Mainline TF-A.  It booted perfectly from cold, but managed to get
> > > > > > > > stuck in the TPL on soft reboot in a very similar way to the one I
> > > > > > > > reported earlier when not booting with TF-A ("Channel 1: col error"):
> > > > > > >
> > > > > > >
> > > > > > > Mainline TF-A defaults to 115200 for its uart messages, so you need to
> > > > > > > either A. pass the uart config from U-Boot to TF-A with a platform
> > > > > > > config option (unreliable in my experience), B. change U-Boot to
> > > > > > > 115200, or C. change TF-A to 1.5M (the path I take). Your mainline
> > > > > >
> > > > > > Hopefully this is enough:
> > > > > >
> > > > > > diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
> > > > > > index ba83242eb..24ad94ae7 100644
> > > > > > --- a/plat/rockchip/rk3399/rk3399_def.h
> > > > > > +++ b/plat/rockchip/rk3399/rk3399_def.h
> > > > > > @@ -17,7 +17,8 @@
> > > > > >  /**************************************************************************
> > > > > >   * UART related constants
> > > > > >   **************************************************************************/
> > > > > > -#define RK3399_BAUDRATE                        115200
> > > > > > +//#define RK3399_BAUDRATE                      115200
> > > > > > +#define RK3399_BAUDRATE                        1500000
> > > > > >  #define RK3399_UART_CLOCK              24000000
> > > > > >
> > > > > >  /******************************************************************************
> > > >
> > > > Yes, that is sufficient.
> >
> > That's interesting.  Would this change result in me now being able to
> > see the console output from this (apparently) failed attempt:
> >
> > https://pastebin.ubuntu.com/p/9HRhPyfjYK/
> >
> > However the result is the same as the downstream kernel where it
> > fails in the TPL on soft reboot:
> >
> > https://pastebin.ubuntu.com/p/TZBYqTMCnN/
> >
> > No TF-A messages seen though still.
> >
> > Is it possible that u-boot only runs TF-A on cold boot?  Seems odd.
>
> I'm convinced that TF-A is not functional on your mainline config. No,
> TF-A will execute on any reset that triggers SPL, as SPL loads TF-A
> and jumps to it as part of the FIT load.
>
> >
> > What was the extra logging you mentioned before?
>
> This is what my rockpro64 looks like with TF-A executing. Note I've
> enabled a bit of extra TF-A debugging, normally it just prints out the
> TF-A version number. TF-A reports itself as BL31.
>
> U-Boot TPL 2022.04-rc2-00234-g017a8901ae3a-dirty (Mar 02 2022 - 18:36:55)
> Channel 0: LPDDR4, 50MHz
> BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
> Channel 1: LPDDR4, 50MHz
> BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
> 256B stride
> lpddr4_set_rate: change freq to 400000000 mhz 0, 1
> lpddr4_set_rate: change freq to 800000000 mhz 1, 0
> Trying to boot from BOOTROM
> Returning to boot ROM...
> rockchip_sdram_size ff320308 32c1f2c1
> rank 1 cs0_col 10 bk 3 cs0_row 16 bw 2 row_3_4 0
> rank 1 cs0_col 10 bk 3 cs0_row 16 bw 2 row_3_4 0
> SDRAM base=0, size=100000000
>
> U-Boot SPL 2022.04-rc2-00234-g017a8901ae3a-dirty (Mar 02 2022 - 18:36:55 -0500)
> Trying to boot from MMC2
> NOTICE:  BL31: v2.6(release):v2.6-138-g929f064f69d0-dirty
> NOTICE:  BL31: Built : 11:27:48, Feb  2 2022
> INFO:    GICv3 with legacy support detected.
> INFO:    ARM GICv3 driver initialized in EL3
> INFO:    Maximum SPI INTID supported: 287
> INFO:    plat_rockchip_pmu_init(1710): pd status 3e
> INFO:    BL31: Initializing runtime services
> INFO:    BL31: Preparing for EL3 exit to normal world
> INFO:    Entry point address = 0x200000
> INFO:    SPSR = 0x3c9
>
>
> U-Boot 2022.04-rc2-00234-g017a8901ae3a-dirty (Mar 02 2022 - 18:36:55 -0500)
>
> SoC: Rockchip rk3399
> Reset cause: POR
> Model: Pine64 RockPro64 v2.1
> DRAM:  rockchip_sdram_size ff320308 32c1f2c1
> rank 1 cs0_col 10 bk 3 cs0_row 16 bw 2 row_3_4 0
> rank 1 cs0_col 10 bk 3 cs0_row 16 bw 2 row_3_4 0
> SDRAM base=0, size=100000000
> 3.9 GiB
> PMIC:  RK808
> Core:  292 devices, 29 uclasses, devicetree: separate
> MMC:   mmc@fe310000: 3, mmc@fe320000: 1, mmc@fe330000: 0
> Loading Environment from SPIFlash... SF: Detected gd25q128 with page
> size 256 Bytes, erase size 4 KiB, total 16 MiB
> *** Warning - bad CRC, using default environment
>
> I'm currently pulling the rk3399-rock-pi-4b.dts that's in mainline
> linux to build a quick image for you, if you're interested.

I see that mainline U-Boot has support already for this device. So I'm
building a debug image for you with that.

>
> >
> > --
> > Lee Jones [李琼斯]
> > Principal Technical Lead - Developer Services
> > Linaro.org │ Open source software for Arm SoCs
> > Follow Linaro: Facebook | Twitter | Blog

Re: [U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround

[Lee Jones]

On Thu, 19 May 2022, Peter Geis wrote:

> On Thu, May 19, 2022 at 1:36 PM Peter Geis <pgwipeout@gmail.com> wrote:
> >
> > On Thu, May 19, 2022 at 1:23 PM Lee Jones <lee.jones@linaro.org> wrote:
> > >
> > > On Thu, 19 May 2022, Lee Jones wrote:
> > >
> > > > On Thu, 19 May 2022, Peter Geis wrote:
> > > >
> > > > > On Thu, May 19, 2022 at 11:47 AM Lee Jones <lee.jones@linaro.org> wrote:
> > > > > >
> > > > > > On Thu, 19 May 2022, Lee Jones wrote:
> > > > > >
> > > > > > > On Thu, 19 May 2022, Peter Geis wrote:
> > > > > > >
> > > > > > > > On Thu, May 19, 2022 at 10:56 AM Lee Jones <lee.jones@linaro.org> wrote:
> > > > > > > > >
> > > > > > > > > > > > > It's not clear how this issue (present 3 years ago) was finally
> > > > > > > > > > > > > resolved.  From the thread, it looks as if the fix might have made its
> > > > > > > > > > > > > way into ATF, but I'm 87.6% sure ATF is not running on this platform
> > > > > > > > > > > > > (yet).
> > > > > > > > > > > >
> > > > > > > > > > > > The rk3399 SoC has a hardware bug where the power domains are not
> > > > > > > > > > > > reset upon a soft reset. This leads to situations like this one where
> > > > > > > > > > > > power domains are shut down during shutdown but aren't restored on
> > > > > > > > > > > > reboot.
> > > > > > > > > > >
> > > > > > > > > > > I assume this isn't something we can patch in the kernel driver?
> > > > > > > > > >
> > > > > > > > > > As far as I know it's being worked on by others, I have some ideas for
> > > > > > > > > > this as well but I've been focused on rk356x lately.
> > > > > > > > >
> > > > > > > > > Thanks for the update.
> > > > > > > > >
> > > > > > > > > > > > Mainline TF-A was patched to force all power domains online
> > > > > > > > > > > > when a soft reboot is triggered, which solved that issue.
> > > > > > > > > > >
> > > > > > > > > > > Okay, this is what I figured.
> > > > > > > > > > >
> > > > > > > > > > > > What particular issues are you having initializing modern u-boot on
> > > > > > > > > > > > this device?
> > > > > > > > > > >
> > > > > > > > > > > This is the output: https://pastebin.ubuntu.com/p/d5DmsSBnrR/
> > > > > > > > > > >
> > > > > > > > > > > Speaking with one of the guys who supports RockPi 4 in AOSP, he
> > > > > > > > > > > suspects the DDR settings.  Apparently settings for older SoCs
> > > > > > > > > > > sometimes get clobbered when support for newer SoCs is added.
> > > > > > > > > >
> > > > > > > > > > The rk3399 TPL code is specific to the rk3399 and it really hasn't
> > > > > > > > > > been touched much recently. I'm using the latest Mainline U-Boot on
> > > > > > > > > > both my Rockpro64 and Pinephone-Pro. I don't see TF-A being loaded,
> > > > > > > > > > which should happen between:
> > > > > > > > > >
> > > > > > > > > > Trying to boot from BOOTROM
> > > > > > > > > > Returning to boot ROM...
> > > > > > > > > >
> > > > > > > > > > Otherwise it just looks like the TPL code doesn't like being in a
> > > > > > > > > > single channel configuration. Does the 2GB model just forgo the second
> > > > > > > > > > ram chip? Or is this actually a 4GB model and it isn't detecting the
> > > > > > > > > > second chip in both downstream and mainline? Could you include the
> > > > > > > > > > TPL/SPL portion of downstream's output?
> > > > > > > > >
> > > > > > > > > TPL/SPL are mostly silent on the downstream build:
> > > > > > > > >
> > > > > > > > > https://pastebin.ubuntu.com/p/m2bBdjF8Wq/
> > > > > > > > >
> > > > > > > > > Not sure if it helps at all, but ArmBian is pretty noisy:
> > > > > > > > >
> > > > > > > > > https://pastebin.ubuntu.com/p/fdPjmmqBDM/
> > > > > > > >
> > > > > > > > Weird that downstream and mainline are being built with none of the
> > > > > > > > debug stuff enabled. Armbian clearly shows the initial setup occuring
> > > > > > > > correctly, and that it's a 4GB board. It's using both the Rockchip
> > > > > > > > miniloader with a Rockchip TF-A blob as well.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > > I am yet to investigate the u-boot story in any detail.
> > > > > > > > > > >
> > > > > > > > > > > It's on my TODO list for today.
> > > > > > > > > > >
> > > > > > > > > > > > Is there a particular reason it isn't using Mainline TF-A?
> > > > > > > > > > >
> > > > > > > > > > > We're not using Trusted Firmware yet.
> > > > > > > > > >
> > > > > > > > > > This platform does not work at all without TF-A. Optee is optional.
> > > > > > > > > > Either you are using the downstream blob from Rockchip or Mainline
> > > > > > > > > > built yourself. Personally I prefer using Mainline everything. If you
> > > > > > > > > > build Mainline U-Boot without TF-A it will throw a warning at the end
> > > > > > > > > > that says the created binary is non-functional.
> > > > > > > > >
> > > > > > > > > Right.  Played a lot with this today.
> > > > > > > > >
> > > > > > > > > Our build was using TF-A which was built-in to the primary loader.
> > > > > > > > >
> > > > > > > > > I had 2 interesting results today.  No idea how to explain them.
> > > > > > > > >
> > > > > > > > > First one was with Mainline u-boot and Mainline TF-A, which found, but
> > > > > > > > > was seemingly unable to boot the kernel:
> > > > > > > > >
> > > > > > > > > https://pastebin.ubuntu.com/p/9HRhPyfjYK/
> > > > > > > > >
> > > > > > > > > The second interesting result I had was using our downstream u-boot
> > > > > > > > > with Mainline TF-A.  It booted perfectly from cold, but managed to get
> > > > > > > > > stuck in the TPL on soft reboot in a very similar way to the one I
> > > > > > > > > reported earlier when not booting with TF-A ("Channel 1: col error"):
> > > > > > > >
> > > > > > > >
> > > > > > > > Mainline TF-A defaults to 115200 for its uart messages, so you need to
> > > > > > > > either A. pass the uart config from U-Boot to TF-A with a platform
> > > > > > > > config option (unreliable in my experience), B. change U-Boot to
> > > > > > > > 115200, or C. change TF-A to 1.5M (the path I take). Your mainline
> > > > > > >
> > > > > > > Hopefully this is enough:
> > > > > > >
> > > > > > > diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
> > > > > > > index ba83242eb..24ad94ae7 100644
> > > > > > > --- a/plat/rockchip/rk3399/rk3399_def.h
> > > > > > > +++ b/plat/rockchip/rk3399/rk3399_def.h
> > > > > > > @@ -17,7 +17,8 @@
> > > > > > >  /**************************************************************************
> > > > > > >   * UART related constants
> > > > > > >   **************************************************************************/
> > > > > > > -#define RK3399_BAUDRATE                        115200
> > > > > > > +//#define RK3399_BAUDRATE                      115200
> > > > > > > +#define RK3399_BAUDRATE                        1500000
> > > > > > >  #define RK3399_UART_CLOCK              24000000
> > > > > > >
> > > > > > >  /******************************************************************************
> > > > >
> > > > > Yes, that is sufficient.
> > >
> > > That's interesting.  Would this change result in me now being able to
> > > see the console output from this (apparently) failed attempt:
> > >
> > > https://pastebin.ubuntu.com/p/9HRhPyfjYK/
> > >
> > > However the result is the same as the downstream kernel where it
> > > fails in the TPL on soft reboot:
> > >
> > > https://pastebin.ubuntu.com/p/TZBYqTMCnN/
> > >
> > > No TF-A messages seen though still.
> > >
> > > Is it possible that u-boot only runs TF-A on cold boot?  Seems odd.
> >
> > I'm convinced that TF-A is not functional on your mainline config. No,
> > TF-A will execute on any reset that triggers SPL, as SPL loads TF-A
> > and jumps to it as part of the FIT load.
> >
> > >
> > > What was the extra logging you mentioned before?
> >
> > This is what my rockpro64 looks like with TF-A executing. Note I've
> > enabled a bit of extra TF-A debugging, normally it just prints out the
> > TF-A version number. TF-A reports itself as BL31.
> >
> > U-Boot TPL 2022.04-rc2-00234-g017a8901ae3a-dirty (Mar 02 2022 - 18:36:55)
> > Channel 0: LPDDR4, 50MHz
> > BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
> > Channel 1: LPDDR4, 50MHz
> > BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
> > 256B stride
> > lpddr4_set_rate: change freq to 400000000 mhz 0, 1
> > lpddr4_set_rate: change freq to 800000000 mhz 1, 0
> > Trying to boot from BOOTROM
> > Returning to boot ROM...
> > rockchip_sdram_size ff320308 32c1f2c1
> > rank 1 cs0_col 10 bk 3 cs0_row 16 bw 2 row_3_4 0
> > rank 1 cs0_col 10 bk 3 cs0_row 16 bw 2 row_3_4 0
> > SDRAM base=0, size=100000000
> >
> > U-Boot SPL 2022.04-rc2-00234-g017a8901ae3a-dirty (Mar 02 2022 - 18:36:55 -0500)
> > Trying to boot from MMC2
> > NOTICE:  BL31: v2.6(release):v2.6-138-g929f064f69d0-dirty
> > NOTICE:  BL31: Built : 11:27:48, Feb  2 2022
> > INFO:    GICv3 with legacy support detected.
> > INFO:    ARM GICv3 driver initialized in EL3
> > INFO:    Maximum SPI INTID supported: 287
> > INFO:    plat_rockchip_pmu_init(1710): pd status 3e
> > INFO:    BL31: Initializing runtime services
> > INFO:    BL31: Preparing for EL3 exit to normal world
> > INFO:    Entry point address = 0x200000
> > INFO:    SPSR = 0x3c9
> >
> >
> > U-Boot 2022.04-rc2-00234-g017a8901ae3a-dirty (Mar 02 2022 - 18:36:55 -0500)
> >
> > SoC: Rockchip rk3399
> > Reset cause: POR
> > Model: Pine64 RockPro64 v2.1
> > DRAM:  rockchip_sdram_size ff320308 32c1f2c1
> > rank 1 cs0_col 10 bk 3 cs0_row 16 bw 2 row_3_4 0
> > rank 1 cs0_col 10 bk 3 cs0_row 16 bw 2 row_3_4 0
> > SDRAM base=0, size=100000000
> > 3.9 GiB
> > PMIC:  RK808
> > Core:  292 devices, 29 uclasses, devicetree: separate
> > MMC:   mmc@fe310000: 3, mmc@fe320000: 1, mmc@fe330000: 0
> > Loading Environment from SPIFlash... SF: Detected gd25q128 with page
> > size 256 Bytes, erase size 4 KiB, total 16 MiB
> > *** Warning - bad CRC, using default environment
> >
> > I'm currently pulling the rk3399-rock-pi-4b.dts that's in mainline
> > linux to build a quick image for you, if you're interested.

Yes, very interested, thank you.

> I see that mainline U-Boot has support already for this device. So I'm
> building a debug image for you with that.

Yes, that's what I'm using.

Just the default config with BL31 exported.

  BL31=<PROJECTS>/rockpi/arm-trusted-firmware/build/rk3399/release/bl31/bl31.elf

-- 
Lee Jones [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

[U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround

[Kever Yang]

On 2019/11/28 下午2:14, Vasily Khoruzhick wrote:
> Rockpro64 doesn't boot reliably after soft reset, so let's force power on
> reset by asserting sysreset pin if we detected soft reset.
>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Thanks,
- Kever
> ---
>   arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 8 ++++++++
>   configs/rockpro64-rk3399_defconfig        | 1 +
>   2 files changed, 9 insertions(+)
>
> diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> index 4648513ea9..bb94bcf7be 100644
> --- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> @@ -6,11 +6,19 @@
>   #include "rk3399-u-boot.dtsi"
>   #include "rk3399-sdram-lpddr4-100.dtsi"
>   / {
> +	config {
> +		sysreset-gpio = <&gpio1 RK_PA6 GPIO_ACTIVE_HIGH>;
> +	};
> +
>   	chosen {
>   		u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci;
>   	};
>   };
>   
> +&gpio1  {
> +	u-boot,dm-pre-reloc;
> +};
> +
>   &vdd_center {
>   	regulator-min-microvolt = <950000>;
>   	regulator-max-microvolt = <950000>;
> diff --git a/configs/rockpro64-rk3399_defconfig b/configs/rockpro64-rk3399_defconfig
> index 49e27c91cb..d153ac5485 100644
> --- a/configs/rockpro64-rk3399_defconfig
> +++ b/configs/rockpro64-rk3399_defconfig
> @@ -1,6 +1,7 @@
>   CONFIG_ARM=y
>   CONFIG_ARCH_ROCKCHIP=y
>   CONFIG_SYS_TEXT_BASE=0x00200000
> +CONFIG_SPL_GPIO_SUPPORT=y
>   CONFIG_ROCKCHIP_RK3399=y
>   CONFIG_ENV_OFFSET=0x3F8000
>   CONFIG_TARGET_ROCKPRO64_RK3399=y

[U-Boot] [PATCH 1/2] rockchip: rk3399: fix force power on reset

[Kever Yang]

On 2019/11/28 下午2:14, Vasily Khoruzhick wrote:
> Currently code doesn't even compile since it uses wrong
> define for ifdef. Fix that and also add missing include
>
> Fixes: 07586ee4322a ("rockchip: rk3399: Support common spl_board_init")
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Thanks,
- Kever
> ---
>   arch/arm/mach-rockchip/rk3399/rk3399.c | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c
> index 863024d071..eeb99dd11b 100644
> --- a/arch/arm/mach-rockchip/rk3399/rk3399.c
> +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
> @@ -11,6 +11,7 @@
>   #include <asm/io.h>
>   #include <asm/arch-rockchip/bootrom.h>
>   #include <asm/arch-rockchip/clock.h>
> +#include <asm/arch-rockchip/cru_rk3399.h>
>   #include <asm/arch-rockchip/gpio.h>
>   #include <asm/arch-rockchip/grf_rk3399.h>
>   #include <asm/arch-rockchip/hardware.h>
> @@ -213,7 +214,7 @@ void spl_perform_fixups(struct spl_image_info *spl_image)
>   			   "u-boot,spl-boot-device", boot_ofpath);
>   }
>   
> -#if defined(SPL_GPIO_SUPPORT)
> +#if defined(CONFIG_SPL_GPIO_SUPPORT)
>   static void rk3399_force_power_on_reset(void)
>   {
>   	ofnode node;
> @@ -239,7 +240,7 @@ static void rk3399_force_power_on_reset(void)
>   
>   void spl_board_init(void)
>   {
> -#if defined(SPL_GPIO_SUPPORT)
> +#if defined(CONFIG_SPL_GPIO_SUPPORT)
>   	struct rk3399_cru *cru = rockchip_get_cru();
>   
>   	/*