[linux-sunxi] [PATCH] arm64: dts: allwinner: h6: beelink-gs1: Remove ext. 32 kHz osc reference
Although every Beelink GS1 seems to have external 32768 Hz oscillator,
it works only on one from four tested. There are more reports of RTC
issues elsewhere, like Armbian forum.
One Beelink GS1 owner read RTC osc status register on Android which
shipped with the box. Reported value indicated problems with external
oscillator.
In order to fix RTC and related issues (HDMI-CEC and suspend/resume with
Crust) on all boards, switch to internal oscillator.
Fixes: 32507b868119 ("arm64: dts: allwinner: h6: Move ext. oscillator to board
DTs")
Signed-off-by: Jernej Skrabec
---
arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
index 669d39fc716a..6249e9e02928 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
@@ -289,10 +289,6 @@ sw {
};
};
- {
- clocks = <_osc32k>;
-};
-
{
status = "okay";
};
--
2.31.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20210330184218.279738-1-jernej.skrabec%40siol.net.
[linux-sunxi] Re: [PATCH 2/2] sunxi: dts: H616: Drop reserved-memory node
On Tue, 30 Mar 2021 18:58:23 +0530
Jagan Teki wrote:
Hi Jagan,
> On Tue, Mar 30, 2021 at 6:31 PM Andre Przywara wrote:
> >
> > Trusted Firmware now adds the /reserved-memory subnode to the DT at
> > runtime[1], putting in the right values.
> >
> > Drop our hard-coded version, as this might clash with the actual values
> > (which have also changed), and rely on TF-A to add the node.
> >
> > [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7770
> >
> > Signed-off-by: Andre Przywara
> > ---
> > arch/arm/dts/sun50i-h616.dtsi | 12
> > 1 file changed, 12 deletions(-)
> >
> > diff --git a/arch/arm/dts/sun50i-h616.dtsi b/arch/arm/dts/sun50i-h616.dtsi
> > index 953e8fac20f..dd4d2f3 100644
> > --- a/arch/arm/dts/sun50i-h616.dtsi
> > +++ b/arch/arm/dts/sun50i-h616.dtsi
> > @@ -51,18 +51,6 @@
> > };
> > };
> >
> > - reserved-memory {
> > - #address-cells = <2>;
> > - #size-cells = <2>;
> > - ranges;
> > -
> > - /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> > - secmon_reserved: secmon@4000 {
> > - reg = <0x0 0x4000 0x0 0x8>;
> > - no-map;
> > - };
> > - };
> > -
>
> As said always. it's better to not touch Linux dts files. If the same
> fix same available in Linux add SHA1 on the commit message otherwise
> keep /delete-node on -u-boot.dtsi. This how we are maintaining sofar
> at least on sunxi.
this DT is not in Linux yet.
As this is a new SoC, we have to start at some point, and getting TF-A,
Linux and U-Boot patches merged at the same time is virtually
impossible. Ideally we have some bootloader support first, so that
people can test the kernel patches, for instance.
So this DT is a tentative one, just here to make U-Boot happy. It is
expected to change, and will be synced once it's merged into Linux.
As mentioned, the TF-A patches were changed after the U-Boot patches
were merged, so this node was needed back then, but is obsolete now.
Cheers,
Andre
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20210330151328.661324b7%40slackpad.fritz.box.
[linux-sunxi] Re: [PATCH 2/2] sunxi: dts: H616: Drop reserved-memory node
On Tue, Mar 30, 2021 at 7:21 PM Samuel Holland wrote:
>
> On 3/30/21 8:28 AM, Jagan Teki wrote:
> > On Tue, Mar 30, 2021 at 6:31 PM Andre Przywara
> > wrote:
> >>
> >> Trusted Firmware now adds the /reserved-memory subnode to the DT at
> >> runtime[1], putting in the right values.
> >>
> >> Drop our hard-coded version, as this might clash with the actual values
> >> (which have also changed), and rely on TF-A to add the node.
> >>
> >> [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7770
> >>
> >> Signed-off-by: Andre Przywara
>
> Reviewed-by: Samuel Holland
>
> >> ---
> >> arch/arm/dts/sun50i-h616.dtsi | 12
> >> 1 file changed, 12 deletions(-)
> >>
> >> diff --git a/arch/arm/dts/sun50i-h616.dtsi b/arch/arm/dts/sun50i-h616.dtsi
> >> index 953e8fac20f..dd4d2f3 100644
> >> --- a/arch/arm/dts/sun50i-h616.dtsi
> >> +++ b/arch/arm/dts/sun50i-h616.dtsi
> >> @@ -51,18 +51,6 @@
> >> };
> >> };
> >>
> >> - reserved-memory {
> >> - #address-cells = <2>;
> >> - #size-cells = <2>;
> >> - ranges;
> >> -
> >> - /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> >> - secmon_reserved: secmon@4000 {
> >> - reg = <0x0 0x4000 0x0 0x8>;
> >> - no-map;
> >> - };
> >> - };
> >> -
> >
> > As said always. it's better to not touch Linux dts files. If the same
> > fix same available in Linux add SHA1 on the commit message otherwise
> > keep /delete-node on -u-boot.dtsi. This how we are maintaining sofar
> > at least on sunxi.
>
> This file has not yet been added to the Linux tree, so that rule does not
> apply
> in this case.
Reviewed-by: Jagan Teki
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/CAMty3ZDLJHgaj0CHbo6rpb3%2B1-Qz%2Bz1fPiBzkBub9ZDC4mdoJw%40mail.gmail.com.
[linux-sunxi] Re: [PATCH 2/2] sunxi: dts: H616: Drop reserved-memory node
On 3/30/21 8:28 AM, Jagan Teki wrote:
> On Tue, Mar 30, 2021 at 6:31 PM Andre Przywara wrote:
>>
>> Trusted Firmware now adds the /reserved-memory subnode to the DT at
>> runtime[1], putting in the right values.
>>
>> Drop our hard-coded version, as this might clash with the actual values
>> (which have also changed), and rely on TF-A to add the node.
>>
>> [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7770
>>
>> Signed-off-by: Andre Przywara
Reviewed-by: Samuel Holland
>> ---
>> arch/arm/dts/sun50i-h616.dtsi | 12
>> 1 file changed, 12 deletions(-)
>>
>> diff --git a/arch/arm/dts/sun50i-h616.dtsi b/arch/arm/dts/sun50i-h616.dtsi
>> index 953e8fac20f..dd4d2f3 100644
>> --- a/arch/arm/dts/sun50i-h616.dtsi
>> +++ b/arch/arm/dts/sun50i-h616.dtsi
>> @@ -51,18 +51,6 @@
>> };
>> };
>>
>> - reserved-memory {
>> - #address-cells = <2>;
>> - #size-cells = <2>;
>> - ranges;
>> -
>> - /* 512KiB reserved for ARM Trusted Firmware (BL31) */
>> - secmon_reserved: secmon@4000 {
>> - reg = <0x0 0x4000 0x0 0x8>;
>> - no-map;
>> - };
>> - };
>> -
>
> As said always. it's better to not touch Linux dts files. If the same
> fix same available in Linux add SHA1 on the commit message otherwise
> keep /delete-node on -u-boot.dtsi. This how we are maintaining sofar
> at least on sunxi.
This file has not yet been added to the Linux tree, so that rule does not apply
in this case.
Cheers,
Samuel
> Jagan.
>
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/912b7c69-fdac-8e2d-9d52-b28141beb299%40sholland.org.
[linux-sunxi] Re: [PATCH 1/2] sunxi: H616: Change TF-A load address to beginning of DRAM
On 3/30/21 8:01 AM, Andre Przywara wrote: > Loading Trusted-Firmware's BL31 at 16KB into DRAM was originally a hack > to allow sharing more code with the other SoCs (which use this offset > in SRAM). However there is no longer a reason for that, as the > problematic macros have been properly separated there. > > The latest (and hopefully final) TF-A code drop now changes the load > address to the beginning of DRAM, which is also more easily protected > by the Trustzone memory controller (code to be done). > > Adjust the load address of BL31 now, to avoid any issues with > incompatible versions later on (the TF-A patches are about to be merged). > > Signed-off-by: Andre Przywara Reviewed-by: Samuel Holland > --- > arch/arm/dts/sunxi-u-boot.dtsi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-boot.dtsi > index abe629c55e5..cd096bf2a06 100644 > --- a/arch/arm/dts/sunxi-u-boot.dtsi > +++ b/arch/arm/dts/sunxi-u-boot.dtsi > @@ -4,7 +4,7 @@ > #define BL31_ADDR 0x104000 > #define SCP_ADDR 0x114000 > #elif defined(CONFIG_MACH_SUN50I_H616) > -#define BL31_ADDR 0x40004000 > +#define BL31_ADDR 0x4000 > #else > #define BL31_ADDR 0x44000 > #define SCP_ADDR 0x5 > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/cb8f6c4d-6a1f-d3ca-ae96-af96ece58889%40sholland.org.
[linux-sunxi] Re: [PATCH 2/2] sunxi: dts: H616: Drop reserved-memory node
On Tue, Mar 30, 2021 at 6:31 PM Andre Przywara wrote:
>
> Trusted Firmware now adds the /reserved-memory subnode to the DT at
> runtime[1], putting in the right values.
>
> Drop our hard-coded version, as this might clash with the actual values
> (which have also changed), and rely on TF-A to add the node.
>
> [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7770
>
> Signed-off-by: Andre Przywara
> ---
> arch/arm/dts/sun50i-h616.dtsi | 12
> 1 file changed, 12 deletions(-)
>
> diff --git a/arch/arm/dts/sun50i-h616.dtsi b/arch/arm/dts/sun50i-h616.dtsi
> index 953e8fac20f..dd4d2f3 100644
> --- a/arch/arm/dts/sun50i-h616.dtsi
> +++ b/arch/arm/dts/sun50i-h616.dtsi
> @@ -51,18 +51,6 @@
> };
> };
>
> - reserved-memory {
> - #address-cells = <2>;
> - #size-cells = <2>;
> - ranges;
> -
> - /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> - secmon_reserved: secmon@4000 {
> - reg = <0x0 0x4000 0x0 0x8>;
> - no-map;
> - };
> - };
> -
As said always. it's better to not touch Linux dts files. If the same
fix same available in Linux add SHA1 on the commit message otherwise
keep /delete-node on -u-boot.dtsi. This how we are maintaining sofar
at least on sunxi.
Jagan.
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/CAMty3ZDpETzmE%3D1CRo2d3yT4FN0nSi7p%2Bpvf8cLjBSwfu7Kpkg%40mail.gmail.com.
[linux-sunxi] [PATCH 1/2] sunxi: H616: Change TF-A load address to beginning of DRAM
Loading Trusted-Firmware's BL31 at 16KB into DRAM was originally a hack to allow sharing more code with the other SoCs (which use this offset in SRAM). However there is no longer a reason for that, as the problematic macros have been properly separated there. The latest (and hopefully final) TF-A code drop now changes the load address to the beginning of DRAM, which is also more easily protected by the Trustzone memory controller (code to be done). Adjust the load address of BL31 now, to avoid any issues with incompatible versions later on (the TF-A patches are about to be merged). Signed-off-by: Andre Przywara --- arch/arm/dts/sunxi-u-boot.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-boot.dtsi index abe629c55e5..cd096bf2a06 100644 --- a/arch/arm/dts/sunxi-u-boot.dtsi +++ b/arch/arm/dts/sunxi-u-boot.dtsi @@ -4,7 +4,7 @@ #define BL31_ADDR 0x104000 #define SCP_ADDR 0x114000 #elif defined(CONFIG_MACH_SUN50I_H616) -#define BL31_ADDR 0x40004000 +#define BL31_ADDR 0x4000 #else #define BL31_ADDR 0x44000 #define SCP_ADDR 0x5 -- 2.17.5 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20210330130122.3915-2-andre.przywara%40arm.com.
[linux-sunxi] [PATCH 2/2] sunxi: dts: H616: Drop reserved-memory node
Trusted Firmware now adds the /reserved-memory subnode to the DT at
runtime[1], putting in the right values.
Drop our hard-coded version, as this might clash with the actual values
(which have also changed), and rely on TF-A to add the node.
[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7770
Signed-off-by: Andre Przywara
---
arch/arm/dts/sun50i-h616.dtsi | 12
1 file changed, 12 deletions(-)
diff --git a/arch/arm/dts/sun50i-h616.dtsi b/arch/arm/dts/sun50i-h616.dtsi
index 953e8fac20f..dd4d2f3 100644
--- a/arch/arm/dts/sun50i-h616.dtsi
+++ b/arch/arm/dts/sun50i-h616.dtsi
@@ -51,18 +51,6 @@
};
};
- reserved-memory {
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
-
- /* 512KiB reserved for ARM Trusted Firmware (BL31) */
- secmon_reserved: secmon@4000 {
- reg = <0x0 0x4000 0x0 0x8>;
- no-map;
- };
- };
-
osc24M: osc24M_clk {
#clock-cells = <0>;
compatible = "fixed-clock";
--
2.17.5
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20210330130122.3915-3-andre.przywara%40arm.com.
[linux-sunxi] [For v2021.04] [PATCH 0/2] sunxi: last-minute H616 fixes
The link address of the BL31 Trusted Firmware code has changed during the development, so we need to fix the load address in our FIT image template accordingly. The H616 TF-A patches are about to be merged now: https://review.trustedfirmware.org/q/topic:%22allwinner_h616%22+(status:open%20OR%20status:merged) Since H616 support was introduced in this cycle's merge window, we should merge those fixes before the release, to avoid compatiblity issues. The second patch defers to TF-A to add the reserved memory node, we didn't have this code in the TF-A series initially. Having two conflicting reserved memory locations doesn't fly very well, so this one drops our hardcoded version. Thanks! Andre Andre Przywara (2): sunxi: H616: Change TF-A load address to beginning of DRAM sunxi: dts: H616: Drop reserved-memory node arch/arm/dts/sun50i-h616.dtsi | 12 arch/arm/dts/sunxi-u-boot.dtsi | 2 +- 2 files changed, 1 insertion(+), 13 deletions(-) -- 2.17.5 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20210330130122.3915-1-andre.przywara%40arm.com.
[linux-sunxi] Re: [RFC PATCH] arm64: dts: allwinner: a64/h5: Add CPU idle states
Hi Samuel, On Tue, Mar 23, 2021 at 11:44:50PM -0500, Samuel Holland wrote: > On 3/22/21 8:56 PM, Andre Przywara wrote: > >> I'm sending this patch as an RFC because it raises questions about how > >> we handle firmware versioning. How far back does (or should) our support > >> for old TF-A and Crust versions go? > >> > >> cpuidle has a problem that without working firmware support, CPUs will > >> enter idle states and be unable to wake up. As a result, the system will > >> hang at some point during boot, usually before getting to userspace. > >> > >> For over a year[0], TF-A has exposed the PSCI CPU_SUSPEND function when > >> a SCPI implementation is present[1]. Implementing CPU_SUSPEND is > >> required for implementing SYSTEM_SUSPEND[2], even if CPU_SUSPEND is not > >> itself used for anything. > >> > >> However, there was no code to actually wake up a CPU once it called the > >> CPU_SUSPEND function, because I could not find the register providing > >> the necessary information. The fact that CPU_SUSPEND was broken affected > >> nobody, because nothing ever called it -- there were no idle states in > >> the DTS. In hindsight, what I should have done was always return failure > >> from sunxi_validate_power_state(), but that ship has long sailed. > >> > >> I finally found the elusive register and implemented the wakeup code > >> earlier this month[3]. So now, CPU_SUSPEND actually works, if all of > >> your firmware is up to date, and cpuidle works if you add the states in > >> your device tree. > >> > >> Unfortunately, there is currently nothing verifying that compatibility. > >> So you can get into four possible scenarios: > >> 1) No idle states in DTS, any firmware => Linux works, with baseline > >> power consumption. > >> 2) Idle states added to DTS, no Crust/SCPI => Linux works, but every > >> attempt to enter an idle state is rejected because CPU_SUSPEND is > >> not hooked up. So power consumption increases by a sizable amount. > >> 3) Idle states added to DTS, "old" Crust/SCPI (before [3]) => Linux > >> fails to boot, because CPUs never return from idle states. > >> 4) Idle states added to DTS, "new" Crust/SCPI (after [3]) => Linux > >> works, with improved power consumption compared to the baseline. > >> > >> Obviously, we want to prevent scenario 3 if possible. > > > > So I think the core of the problem is that the DT describes some > > firmware feature, but we have the DT bundled with the kernel, not the > > firmware. > > I would say the core problem is that the firmware lies about supporting > PSCI CPU_SUSPEND. Linux shouldn't be calling CPU_SUSPEND if the firmware > declares it as unavailable, regardless of what is in the DTS. I would say we have two core problems :) > (Technically, per the PSCI standard, CPU_SUSPEND is a mandatory > function, but a quick survey of the TF-A platforms shows it is far from > universally implemented.) U-boot also implements CPU_SUSPEND but will return -1 if you don't have an implementation. I guess that at the moment we shouldn't be reporting it as supported if we don't But I also agree with Andre here, we shouldn't list cpuidles capabilities in the DTS if we don't always have them either. > > So is there any way we can detect an older crust version in U-Boot, > > then remove any potential idle states from the DT? > > Let's assume that we are using a functioning SoC (H3) or the secure fuse > is blown (A64) and therefore U-Boot cannot access SRAM A2. I can think > of three ways it can learn about crust: > > a) PSCI_FEATURES (e.g. is CPU_SUSPEND supported) > b) Metadata in the FIT image > c) Custom SMCs > > TF-A has some additional methods available: > > d) The SCPI-reported firmware version > e) The magic number at the beginning of the firmware binary > > > Granted, this requires recent U-Boot as well, but at least we could try > > to mitigate the worst case a bit? > > If we're okay with modifying firmware to solve this problem, then I > propose the following solution: > > 1) Version bump crust or change its magic number. > 2) Modify TF-A to only report CPU_SUSPEND as available if it detects the >new crust version. This would involve conditionally setting >sunxi_scpi_psci_ops.validate_power_state, and updating psci_setup.c >to also check for .validate_power_state when setting psci_caps. > 3) Modify the Linux PSCI client to respect PSCI_FEATURES when setting >psci_ops.cpu_suspend. cpuidle-psci checks for this function before >setting up idle states. > 4) Finally, after some time, add the idle states to the DTS. > > In fact, this solution solves both scenarios 2 and 3, because it also > takes care of the native PM implementation, which doesn't implement > CPU_SUSPEND at all. > > Does that sound workable? If we can add the DT node at boot in crust (or in TF-A), then we don't really need PSCI_FEATURES, and it would magically work once the firmware is updated. It looks like a solid plan otherwise
