[linux-sunxi] [RFC PATCH 2/2] clk: sunxi-ng: a64: disable mux and pll notifiers for CPUX reclocking
After the dividers of PLL-CPUX disabled, there's no need for PLL-CPUX to
be gated when tweaking the clock of CPUX, thus reparenting CPUX to
osc24M is also now not needed.
Remove these notifiers.
Preventing reparenting CPUX is said to be able to help solving the issue
that the timer jumps backward according to Ondrej Jirman.
Signed-off-by: Icenowy Zheng
---
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index 6108d150a0e3..67d570efe5bd 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -943,7 +943,6 @@ static int sun50i_a64_ccu_probe(struct platform_device
*pdev)
struct resource *res;
void __iomem *reg;
u32 val;
- int ret;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
reg = devm_ioremap_resource(>dev, res);
@@ -1029,18 +1028,7 @@ static int sun50i_a64_ccu_probe(struct platform_device
*pdev)
writel(val, reg + SUN50I_A64_CPUX_AXI_REG);
}
- ret = sunxi_ccu_probe(pdev->dev.of_node, reg, _a64_ccu_desc);
- if (ret)
- return ret;
-
- /* Gate then ungate PLL CPU after any rate changes */
- ccu_pll_notifier_register(_a64_pll_cpu_nb);
-
- /* Reparent CPU during PLL CPU rate changes */
- ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
- _a64_cpu_nb);
-
- return 0;
+ return sunxi_ccu_probe(pdev->dev.of_node, reg, _a64_ccu_desc);
}
static const struct of_device_id sun50i_a64_ccu_ids[] = {
--
2.28.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/20201109053537.54450-1-icenowy%40aosc.io.
[linux-sunxi] [RFC PATCH 0/2] clk: sunxi-ng: a64: Remove CPUX mux switching
According to Ondrej Jirman, switching of the mux of CPUX clock is one of the sources of timer jumps on A64 (and maybe this will also lead to timer jump on H3). This patchset tries to remove this mux by disabling the dividers in PLL-CPUX. Both the lack of reparent when relocking and the prevention of PLL-CPUX dividers are behaviors of the BSP kernel. Icenowy Zheng (2): clk: sunxi-ng: a64: disable dividers in PLL-CPUX clk: sunxi-ng: a64: disable mux and pll notifiers for CPUX reclocking drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 93 ++- 1 file changed, 78 insertions(+), 15 deletions(-) -- 2.28.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/20201109053358.54220-1-icenowy%40aosc.io.
[linux-sunxi] [RFC PATCH 1/2] clk: sunxi-ng: a64: disable dividers in PLL-CPUX
According to the user manual, PLL-CPUX have two dividers, in which P is
only allowed when the desired rate is less than 240MHz. As the CCU
framework have no such feature yet and the clock rate that allows P is
much lower than where we normally operate, disallow the usage of P
factor now.
M is not restricted in the user manual, however according to the BSP PLL
setup table (see [1]), it's not used at all. To follow what the BSP
does, disable this factor too.
Disabling the dividers will make it possible to remove the need to
switch to osc24M when doing frequency scaling on PLL-CPUX.
In order to prevent boot-time usage of dividers (current known mainline
U-Boot implementation use m = 2), tweaking of the factors are done when
probing CCU driver.
Signed-off-by: Icenowy Zheng
---
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 79 ++-
1 file changed, 77 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index 5f66bf879772..6108d150a0e3 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -4,6 +4,7 @@
*/
#include
+#include
#include
#include
#include
@@ -23,13 +24,14 @@
#include "ccu-sun50i-a64.h"
+#define SUN50I_A64_PLL_CPUX_REG0x000
static struct ccu_nkmp pll_cpux_clk = {
.enable = BIT(31),
.lock = BIT(28),
.n = _SUNXI_CCU_MULT(8, 5),
.k = _SUNXI_CCU_MULT(4, 2),
- .m = _SUNXI_CCU_DIV(0, 2),
- .p = _SUNXI_CCU_DIV_MAX(16, 2, 4),
+ .m = _SUNXI_CCU_DIV_MAX(16, 2, 1),
+ .p = _SUNXI_CCU_DIV_MAX(0, 2, 1),
.common = {
.reg= 0x000,
.hw.init= CLK_HW_INIT("pll-cpux",
@@ -215,6 +217,7 @@ static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_ddr1_clk, "pll-ddr1",
BIT(28), /* lock */
CLK_SET_RATE_UNGATE);
+#define SUN50I_A64_CPUX_AXI_REG0x050
static const char * const cpux_parents[] = { "osc32k", "osc24M",
"pll-cpux", "pll-cpux" };
static SUNXI_CCU_MUX(cpux_clk, "cpux", cpux_parents,
@@ -954,6 +957,78 @@ static int sun50i_a64_ccu_probe(struct platform_device
*pdev)
writel(0x515, reg + SUN50I_A64_PLL_MIPI_REG);
+ /* Disable any possible dividers on PLL-CPUX */
+ val = readl(reg + SUN50I_A64_PLL_CPUX_REG);
+ if (val & (GENMASK(17, 16) | GENMASK(1, 0))) {
+ unsigned int n, k, m, p;
+
+ n = ((val & GENMASK(12, 8)) >> 8) + 1;
+ k = ((val & GENMASK(5, 4)) >> 4) + 1;
+ m = (val & GENMASK(1, 0)) + 1;
+ p = 1 << ((val & GENMASK(17, 16)) >> 16);
+
+ /*
+* Known mainline U-Boot revisions never uses
+* divider p, and it will only use m when k = 3 or 4.
+* Specially judge for these cases, to satisfy
+* what will most possibly happen.
+* For m = 2 and k = 3, fractional change will be
+* applied to n, to mostly keep the clock rate.
+* For m = 2 and k = 4, just change to m = 1 and k = 2.
+* For other cases, just try to divide it from N.
+*/
+ if (p >= 2) {
+ n /= p;
+ p = 1;
+ }
+
+ if (m == 2) {
+ if (k == 3) {
+ k = 2;
+ n = n * 3 / 4;
+ m = 1;
+ }
+ if (k == 4) {
+ k = 2;
+ m = 1;
+ }
+ }
+
+ if (m >= 2) {
+ n /= m;
+ m = 1;
+ }
+
+ /* The user manual constrains n*k >= 10 */
+ if (n * k < 10) {
+ n = 10;
+ k = 1;
+ }
+
+ /* Switch CPUX clock to osc24M temporarily */
+ val = readl(reg + SUN50I_A64_CPUX_AXI_REG);
+ val &= ~GENMASK(17, 16);
+ val |= (1 << 16);
+ writel(val, reg + SUN50I_A64_CPUX_AXI_REG);
+ udelay(1);
+
+ /* Setup PLL-CPUX with new factors */
+ val = ((n - 1) << 8) | ((k - 1) << 4);
+ writel(val, reg + SUN50I_A64_PLL_CPUX_REG);
+ val |= BIT(31);
+ writel(val, reg + SUN50I_A64_PLL_CPUX_REG);
+ do {
+ /* Wait the PLL to lock */
+ val = readl(reg + SUN50I_A64_PLL_CPUX_REG);
+ } while (!(val & BIT(28)));
+
+ /* Switch CPUX clock back to PLL-CPUX
Re: [linux-sunxi] Banana Pi, Kernel 5.9, packet loss and bad network connectivity
For this board, there is another issue regarding regulators. The fix is still being discussed. See https://lore.kernel.org/lkml/20201021183149.GA8436@Red/t/ On Tue, Oct 20, 2020 at 5:22 AM JuanEsf wrote: > > Hi! > In BananaPi-M2 Ultra also the problem occurred when updating to the kernel. > but I can't establish a connection > El lunes, 19 de octubre de 2020 a las 1:14:46 UTC-3, Chen-Yu Tsai escribió: >> >> On Sat, Oct 17, 2020 at 3:08 AM Jernej Škrabec wrote: >> > >> > Dne petek, 16. oktober 2020 ob 20:44:38 CEST je Marc Haber napisal(a): >> > > Hi Jernej, >> > > >> > > On Thu, Oct 15, 2020 at 09:23:37PM +0200, Jernej Škrabec wrote: >> > > > Dne četrtek, 15. oktober 2020 ob 21:11:39 CEST je Marc Haber >> > > > napisal(a): >> > > > > when I boot my Banana Pi (with Debian buster installed) with kernel >> > > > > 5.9, >> > > > > the network interface doesn't work too well. Packet loss of more than >> > > > > 50 %, machine nearly unuseable. Going back to 5.8.13 fixes the issue, >> > > > > going forward to 5.9 again makes the issue reappear. >> > > > > >> > > > > Does anybody have a good guess what to try first before going the >> > > > > "implant 5.8.13 stmmac driver to 5.9, maybe bisect" route? >> > > > >> > > > Try to revert https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/ >> > > > linux.git/commit/?h=v5.9=bbc4d71d63549bcd003a430de18a72a742d8c91e >> > > > >> > > > This commit was found to cause issue on Beelink GS1 (Allwinner H6) >> > > > which >> > > > has RTL8211e PHY. Since Banana Pi have same PHY, it might cause issue >> > > > there too. >> > > Reverting this commit does actually help here. Will there be a fix in >> > > Greg's kernel releases? >> > >> > I have no clue. I don't have any problematic board, I just spotted commit >> > when >> > rebasing my kernel and suggested as a possible reason. I suggest that you >> > contact all people involved in that commit (including relevant mailing >> > lists) >> > and explain the issue. Given that this commit is the fix, it's possible >> > that it >> > just uncovered another issue. >> >> The proper fix now is to check the schematics, and change the phy-mode >> property >> to the correct type. It used to be that we used "rgmii" for all RGMII PHYs. >> >> Turns out there are four modes of RGMII, depending on whether the MAC or PHY >> enable TX / RX signal delays. >> >> Most boards in sunxi are designed so that the PHY is providing both TX and RX >> delays, which is done by pulling up the TXDLY and RXDLY pins at power up. >> >> The commit "net: phy: realtek: fix rtl8211e rx/tx delay config" fixes the PHY >> driver so that it will correctly "reconfigure" the PHY to the requested mode. >> Previously this was not happening due to incorrect register definitions. >> >> To summarize, the PHY driver fix exposes errors in our DTs. >> >> >> Regards >> ChenYu > > -- > 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/83697565-cbff-4198-8a9b-12d2a7fb133en%40googlegroups.com. -- 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/CAGb2v66_fvpFNYDJoaJQCaOuq06dN2om3VMJkBrUheJEF9Y8SA%40mail.gmail.com.
[linux-sunxi] Re: [PATCH 0/5] sunxi: enable automatic eMMC boot partition support
On 08/11/2020 14:59, Peter Robinson wrote: Hi, > On Sun, Nov 8, 2020 at 1:14 PM Andre Przywara wrote: >> >> The eMMC standard describes the concept of boot partitions, consisting >> of two storage areas separate from the main user data partition. >> The Allwinner BootROM supports loading SPL/Boot0 from such a boot >> partition, if that is configured in the eMMC device [1]. >> >> To load U-Boot proper along with the SPL from there, currently this >> requires to enable CONFIG_SUPPORT_EMMC_BOOT, and this means that this >> build won't boot from the normal eMMC user partition anymore. >> Also the raw MMC sector offset needs to be adjusted manually, preventing >> a boot from an SD card. >> >> This series introduces automatic detection of eMMC boot partition boot. >> Patch 3/5 automates the raw MMC sector offset decision, allowing such >> a build to also boot from an SD card. >> Unfortunately the BootROM does not mark an eMMC boot partition boot >> differently from the normal eMMC user data partition boot, so patch 4/5 >> introduces a function that repeats the BootROM algorithm, so that the SPL >> comes to the same conclusion as the BootROM. This allows to build one >> single image that boots from everywhere: eMMC user data, eMMC boot, >> SD card, SPI flash. >> Patch 1/5 contains a bugfix that's needed in a later patch, patch 2/5 >> extends the generic spl_mmc_boot_mode() interface to make 4/5 feasible. >> >> Without enabling CONFIG_SUPPORT_EMMC_BOOT, the AArch64 SPL grows by >> 92 bytes, ARMv7 grows by 36 bytes. With enabling the feature, the size >> goes up by 444 bytes (AArch64) and 260 bytes (ARMv7). >> Even for AArch64 this is still 4.5 KB below the SPL limit, so patch 5/5 >> enables this new mechanism for some boards I could test this on. >> >> Please have a look and test this if you have a board with eMMC. >> I put installation instructions into the linux-sunxi Wiki: >> http://linux-sunxi.org/Bootable_eMMC > > It would probably be good to put that link in the local Allwinner docs > so it's easier for people to find. Yeah, actually as you mention it: There does not seem to be some generic README.sunxi file where this would belong to. Jagan: would it make sense to create one, and describe how to get U-Boot into the devices (SD card, eMMC, SPI flash, FEL)? That could move some parts of README.sunxi64 out of there, since they apply to all Allwinner devices. If people agree that this is the right thing to do, I would be happy to send a patch. Cheers, Andre >> >> [1] http://linux-sunxi.org/Bootable_eMMC#The_BROM_implementation_details >> >> Andre Przywara (5): >> sunxi: Fix is_boot0_magic macro >> spl: mmc: extend spl_mmc_boot_mode() to take mmc argument >> sunxi: Simplify eMMC boot partition booting >> sunxi: eMMC: Add automatic boot detection >> sunxi: defconfig: enable eMMC boot partition support >> >> arch/arm/include/asm/arch-sunxi/spl.h | 2 +- >> arch/arm/mach-imx/spl.c| 2 +- >> arch/arm/mach-k3/am6_init.c| 2 +- >> arch/arm/mach-k3/j721e_init.c | 2 +- >> arch/arm/mach-omap2/boot-common.c | 2 +- >> arch/arm/mach-rockchip/spl.c | 2 +- >> arch/arm/mach-socfpga/spl_a10.c| 2 +- >> arch/arm/mach-socfpga/spl_agilex.c | 2 +- >> arch/arm/mach-socfpga/spl_gen5.c | 2 +- >> arch/arm/mach-socfpga/spl_s10.c| 2 +- >> arch/arm/mach-stm32mp/spl.c| 2 +- >> arch/arm/mach-sunxi/board.c| 94 +- >> arch/arm/mach-uniphier/mmc-boot-mode.c | 5 +- >> common/spl/spl_mmc.c | 4 +- >> configs/bananapi_m64_defconfig | 1 + >> configs/emlid_neutis_n5_devboard_defconfig | 1 + >> configs/pine64-lts_defconfig | 1 + >> configs/pine_h64_defconfig | 1 + >> include/spl.h | 3 +- >> 19 files changed, 113 insertions(+), 19 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/965afbad-61b3-c3f4-8b1f-e3ddba01e79d%40arm.com.
[linux-sunxi] Re: [PATCH 0/5] sunxi: enable automatic eMMC boot partition support
On Sun, Nov 8, 2020 at 1:14 PM Andre Przywara wrote: > > The eMMC standard describes the concept of boot partitions, consisting > of two storage areas separate from the main user data partition. > The Allwinner BootROM supports loading SPL/Boot0 from such a boot > partition, if that is configured in the eMMC device [1]. > > To load U-Boot proper along with the SPL from there, currently this > requires to enable CONFIG_SUPPORT_EMMC_BOOT, and this means that this > build won't boot from the normal eMMC user partition anymore. > Also the raw MMC sector offset needs to be adjusted manually, preventing > a boot from an SD card. > > This series introduces automatic detection of eMMC boot partition boot. > Patch 3/5 automates the raw MMC sector offset decision, allowing such > a build to also boot from an SD card. > Unfortunately the BootROM does not mark an eMMC boot partition boot > differently from the normal eMMC user data partition boot, so patch 4/5 > introduces a function that repeats the BootROM algorithm, so that the SPL > comes to the same conclusion as the BootROM. This allows to build one > single image that boots from everywhere: eMMC user data, eMMC boot, > SD card, SPI flash. > Patch 1/5 contains a bugfix that's needed in a later patch, patch 2/5 > extends the generic spl_mmc_boot_mode() interface to make 4/5 feasible. > > Without enabling CONFIG_SUPPORT_EMMC_BOOT, the AArch64 SPL grows by > 92 bytes, ARMv7 grows by 36 bytes. With enabling the feature, the size > goes up by 444 bytes (AArch64) and 260 bytes (ARMv7). > Even for AArch64 this is still 4.5 KB below the SPL limit, so patch 5/5 > enables this new mechanism for some boards I could test this on. > > Please have a look and test this if you have a board with eMMC. > I put installation instructions into the linux-sunxi Wiki: > http://linux-sunxi.org/Bootable_eMMC It would probably be good to put that link in the local Allwinner docs so it's easier for people to find. Peter > Cheers, > Andre > > [1] http://linux-sunxi.org/Bootable_eMMC#The_BROM_implementation_details > > Andre Przywara (5): > sunxi: Fix is_boot0_magic macro > spl: mmc: extend spl_mmc_boot_mode() to take mmc argument > sunxi: Simplify eMMC boot partition booting > sunxi: eMMC: Add automatic boot detection > sunxi: defconfig: enable eMMC boot partition support > > arch/arm/include/asm/arch-sunxi/spl.h | 2 +- > arch/arm/mach-imx/spl.c| 2 +- > arch/arm/mach-k3/am6_init.c| 2 +- > arch/arm/mach-k3/j721e_init.c | 2 +- > arch/arm/mach-omap2/boot-common.c | 2 +- > arch/arm/mach-rockchip/spl.c | 2 +- > arch/arm/mach-socfpga/spl_a10.c| 2 +- > arch/arm/mach-socfpga/spl_agilex.c | 2 +- > arch/arm/mach-socfpga/spl_gen5.c | 2 +- > arch/arm/mach-socfpga/spl_s10.c| 2 +- > arch/arm/mach-stm32mp/spl.c| 2 +- > arch/arm/mach-sunxi/board.c| 94 +- > arch/arm/mach-uniphier/mmc-boot-mode.c | 5 +- > common/spl/spl_mmc.c | 4 +- > configs/bananapi_m64_defconfig | 1 + > configs/emlid_neutis_n5_devboard_defconfig | 1 + > configs/pine64-lts_defconfig | 1 + > configs/pine_h64_defconfig | 1 + > include/spl.h | 3 +- > 19 files changed, 113 insertions(+), 19 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/CALeDE9Oo8vvwADE5M%2BDz17d5Zf7mTmerC3Lid9%2B-9iTX1nMVdg%40mail.gmail.com.
Re: [linux-sunxi] Banana Pi, Kernel 5.9, packet loss and bad network connectivity
Dne nedelja, 08. november 2020 ob 15:44:54 CET je Marc Haber napisal(a): > On Mon, Oct 19, 2020 at 12:14:29PM +0800, Chen-Yu Tsai wrote: > > The proper fix now is to check the schematics, and change the phy-mode > > property to the correct type. It used to be that we used "rgmii" for all > > RGMII PHYs. > > > > Turns out there are four modes of RGMII, depending on whether the MAC or > > PHY enable TX / RX signal delays. > > > > Most boards in sunxi are designed so that the PHY is providing both TX and > > RX delays, which is done by pulling up the TXDLY and RXDLY pins at power > > up. > > > > The commit "net: phy: realtek: fix rtl8211e rx/tx delay config" fixes the > > PHY driver so that it will correctly "reconfigure" the PHY to the > > requested mode. Previously this was not happening due to incorrect > > register definitions. > > > > To summarize, the PHY driver fix exposes errors in our DTs. > > The Banana Pi still doesn't work properly in kernel 5.9.6. I am not in > a position to check schematics and to fix DTs. Discussion of proper way of handling this breakage is still ongoing between maintainers. > > Look at git log for arch/arm/boot/dts/sun7i-a20-bananapi.dts, that would > be you, Chen-Yu Tsai and Maxime Ripard. > > Is there anything I can do to help debugging? Everything about this issue is known. In the meantime, you can use any of these workarounds/fixes: 1. Apply DT fix: https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/ linux.git/commit/?h=sunxi/fixes- for-5.10=8c9cb4094ccf242eddd140efba13872c55f68a87 2. Revert commit bbc4d71d63549bcd003a430de18a72a742d8c91e 3. disable Realtek PHY driver in your kernel. It should still work trough generic PHY driver. Best regards, Jernej -- 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/3531591.HxRJl5LH01%40jernej-laptop.
Re: [linux-sunxi] Banana Pi, Kernel 5.9, packet loss and bad network connectivity
On Mon, Oct 19, 2020 at 12:14:29PM +0800, Chen-Yu Tsai wrote: > The proper fix now is to check the schematics, and change the phy-mode > property > to the correct type. It used to be that we used "rgmii" for all RGMII PHYs. > > Turns out there are four modes of RGMII, depending on whether the MAC or PHY > enable TX / RX signal delays. > > Most boards in sunxi are designed so that the PHY is providing both TX and RX > delays, which is done by pulling up the TXDLY and RXDLY pins at power up. > > The commit "net: phy: realtek: fix rtl8211e rx/tx delay config" fixes the PHY > driver so that it will correctly "reconfigure" the PHY to the requested mode. > Previously this was not happening due to incorrect register definitions. > > To summarize, the PHY driver fix exposes errors in our DTs. The Banana Pi still doesn't work properly in kernel 5.9.6. I am not in a position to check schematics and to fix DTs. Look at git log for arch/arm/boot/dts/sun7i-a20-bananapi.dts, that would be you, Chen-Yu Tsai and Maxime Ripard. Is there anything I can do to help debugging? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 -- 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/20201108144454.GB12779%40torres.zugschlus.de.
[linux-sunxi] [PATCH 5/5] sunxi: defconfig: enable eMMC boot partition support
Now that the SPL can detect whether it was loaded from an eMMC boot partition or the normal user data partition, let's enable this feature on some boards that feature eMMC storage. That covers the boards where I could test this on. Signed-off-by: Andre Przywara --- configs/bananapi_m64_defconfig | 1 + configs/emlid_neutis_n5_devboard_defconfig | 1 + configs/pine64-lts_defconfig | 1 + configs/pine_h64_defconfig | 1 + 4 files changed, 4 insertions(+) diff --git a/configs/bananapi_m64_defconfig b/configs/bananapi_m64_defconfig index 802f9820d07..f28dd7771b7 100644 --- a/configs/bananapi_m64_defconfig +++ b/configs/bananapi_m64_defconfig @@ -5,6 +5,7 @@ CONFIG_MACH_SUN50I=y CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y CONFIG_MMC0_CD_PIN="PH13" CONFIG_MMC_SUNXI_SLOT_EXTRA=2 +CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-bananapi-m64" # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set CONFIG_SUN8I_EMAC=y diff --git a/configs/emlid_neutis_n5_devboard_defconfig b/configs/emlid_neutis_n5_devboard_defconfig index 0e908c327b1..59062bf8bcc 100644 --- a/configs/emlid_neutis_n5_devboard_defconfig +++ b/configs/emlid_neutis_n5_devboard_defconfig @@ -6,5 +6,6 @@ CONFIG_DRAM_CLK=408 CONFIG_DRAM_ZQ=3881977 # CONFIG_DRAM_ODT_EN is not set CONFIG_MMC_SUNXI_SLOT_EXTRA=2 +CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-emlid-neutis-n5-devboard" # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set diff --git a/configs/pine64-lts_defconfig b/configs/pine64-lts_defconfig index 048b31d73ce..24d479ce5d3 100644 --- a/configs/pine64-lts_defconfig +++ b/configs/pine64-lts_defconfig @@ -7,6 +7,7 @@ CONFIG_DRAM_CLK=552 CONFIG_DRAM_ZQ=3881949 CONFIG_MMC0_CD_PIN="" CONFIG_MMC_SUNXI_SLOT_EXTRA=2 +CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_SPL_SPI_SUNXI=y CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-lts" # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set diff --git a/configs/pine_h64_defconfig b/configs/pine_h64_defconfig index 2fa66f38343..2cfa3df2ff4 100644 --- a/configs/pine_h64_defconfig +++ b/configs/pine_h64_defconfig @@ -6,6 +6,7 @@ CONFIG_SUNXI_DRAM_H6_LPDDR3=y CONFIG_MACPWR="PC16" CONFIG_MMC0_CD_PIN="PF6" CONFIG_MMC_SUNXI_SLOT_EXTRA=2 +CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_USB3_VBUS_PIN="PL5" CONFIG_SPL_SPI_SUNXI=y # CONFIG_PSCI_RESET is not set -- 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/20201108131409.14320-6-andre.przywara%40arm.com.
[linux-sunxi] [PATCH 2/5] spl: mmc: extend spl_mmc_boot_mode() to take mmc argument
Platforms can overwrite the weak definition of spl_mmc_boot_mode() to
determine where to load U-Boot proper from.
For most of them this is a trivial decision based on Kconfig variables,
but it might be desirable the probe the actual device to answer this
question.
Pass the pointer to the mmc struct to that function, so implementations
can make use of them.
Compile-tested for all users changed.
Cc: Stefano Babic
Cc: Fabio Estevam
Cc: NXP i.MX U-Boot Team
Cc: Lokesh Vutla
Cc: Philipp Tomsich
Cc: Kever Yang
Cc: Marek Vasut
Cc: Simon Goldschmidt
Cc: Ley Foon Tan
Cc: Patrick Delaunay
Cc: Patrice Chotard
Signed-off-by: Andre Przywara
---
arch/arm/mach-imx/spl.c| 2 +-
arch/arm/mach-k3/am6_init.c| 2 +-
arch/arm/mach-k3/j721e_init.c | 2 +-
arch/arm/mach-omap2/boot-common.c | 2 +-
arch/arm/mach-rockchip/spl.c | 2 +-
arch/arm/mach-socfpga/spl_a10.c| 2 +-
arch/arm/mach-socfpga/spl_agilex.c | 2 +-
arch/arm/mach-socfpga/spl_gen5.c | 2 +-
arch/arm/mach-socfpga/spl_s10.c| 2 +-
arch/arm/mach-stm32mp/spl.c| 2 +-
arch/arm/mach-uniphier/mmc-boot-mode.c | 5 +
common/spl/spl_mmc.c | 4 ++--
include/spl.h | 3 ++-
13 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index aa2686bb921..2cfedccfaf2 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -197,7 +197,7 @@ int g_dnl_get_board_bcd_device_number(int gcnum)
#if defined(CONFIG_SPL_MMC_SUPPORT)
/* called from spl_mmc to see type of boot mode for storage (RAW or FAT) */
-u32 spl_mmc_boot_mode(const u32 boot_device)
+u32 spl_mmc_boot_mode(struct mmc *mmc, const u32 boot_device)
{
#if defined(CONFIG_MX7) || defined(CONFIG_IMX8M) || defined(CONFIG_IMX8)
switch (get_boot_device()) {
diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c
index 603834e5078..55328757a64 100644
--- a/arch/arm/mach-k3/am6_init.c
+++ b/arch/arm/mach-k3/am6_init.c
@@ -252,7 +252,7 @@ void board_init_f(ulong dummy)
spl_enable_dcache();
}
-u32 spl_mmc_boot_mode(const u32 boot_device)
+u32 spl_mmc_boot_mode(struct mmc *mmc, const u32 boot_device)
{
#if defined(CONFIG_SUPPORT_EMMC_BOOT)
u32 devstat = readl(CTRLMMR_MAIN_DEVSTAT);
diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c
index a36e4ed603b..97818a0be6d 100644
--- a/arch/arm/mach-k3/j721e_init.c
+++ b/arch/arm/mach-k3/j721e_init.c
@@ -220,7 +220,7 @@ void board_init_f(ulong dummy)
spl_enable_dcache();
}
-u32 spl_mmc_boot_mode(const u32 boot_device)
+u32 spl_mmc_boot_mode(struct mmc *mmc, const u32 boot_device)
{
switch (boot_device) {
case BOOT_DEVICE_MMC1:
diff --git a/arch/arm/mach-omap2/boot-common.c
b/arch/arm/mach-omap2/boot-common.c
index cb9d7fdb156..b65827668de 100644
--- a/arch/arm/mach-omap2/boot-common.c
+++ b/arch/arm/mach-omap2/boot-common.c
@@ -188,7 +188,7 @@ u32 spl_boot_device(void)
return gd->arch.omap_boot_device;
}
-u32 spl_mmc_boot_mode(const u32 boot_device)
+u32 spl_mmc_boot_mode(struct mmc *mmc, const u32 boot_device)
{
return gd->arch.omap_boot_mode;
}
diff --git a/arch/arm/mach-rockchip/spl.c b/arch/arm/mach-rockchip/spl.c
index f148d48b6a3..24c5f385e19 100644
--- a/arch/arm/mach-rockchip/spl.c
+++ b/arch/arm/mach-rockchip/spl.c
@@ -64,7 +64,7 @@ u32 spl_boot_device(void)
return boot_device;
}
-u32 spl_mmc_boot_mode(const u32 boot_device)
+u32 spl_mmc_boot_mode(struct mmc *mmc, const u32 boot_device)
{
return MMCSD_MODE_RAW;
}
diff --git a/arch/arm/mach-socfpga/spl_a10.c b/arch/arm/mach-socfpga/spl_a10.c
index 45aea4ab6cc..618ca898dd7 100644
--- a/arch/arm/mach-socfpga/spl_a10.c
+++ b/arch/arm/mach-socfpga/spl_a10.c
@@ -93,7 +93,7 @@ u32 spl_boot_device(void)
}
#ifdef CONFIG_SPL_MMC_SUPPORT
-u32 spl_mmc_boot_mode(const u32 boot_device)
+u32 spl_mmc_boot_mode(struct mmc *mmc, const u32 boot_device)
{
#if defined(CONFIG_SPL_FS_FAT) || defined(CONFIG_SPL_FS_EXT4)
return MMCSD_MODE_FS;
diff --git a/arch/arm/mach-socfpga/spl_agilex.c
b/arch/arm/mach-socfpga/spl_agilex.c
index 78b5d7c8d98..fe4253b8e65 100644
--- a/arch/arm/mach-socfpga/spl_agilex.c
+++ b/arch/arm/mach-socfpga/spl_agilex.c
@@ -30,7 +30,7 @@ u32 spl_boot_device(void)
}
#ifdef CONFIG_SPL_MMC_SUPPORT
-u32 spl_mmc_boot_mode(const u32 boot_device)
+u32 spl_mmc_boot_mode(struct mmc *mmc, const u32 boot_device)
{
#if defined(CONFIG_SPL_FS_FAT) || defined(CONFIG_SPL_FS_EXT4)
return MMCSD_MODE_FS;
diff --git a/arch/arm/mach-socfpga/spl_gen5.c b/arch/arm/mach-socfpga/spl_gen5.c
index 5a7c5ef76d5..e526470aa15 100644
--- a/arch/arm/mach-socfpga/spl_gen5.c
+++ b/arch/arm/mach-socfpga/spl_gen5.c
@@ -52,7 +52,7 @@ u32 spl_boot_device(void)
}
#ifdef CONFIG_SPL_MMC_SUPPORT
-u32 spl_mmc_boot_mode(const u32 boot_device)
+u32 spl_mmc_boot_mode(struct mmc *mmc, const u32
[linux-sunxi] [PATCH 4/5] sunxi: eMMC: Add automatic boot detection
When the Allwinner BROM loads the SPL from an eMMC boot partition, it
sets the boot source byte to the same value as when booting from the
user data partition. This prevents us from easily determining the boot
source to load U-Boot proper from the proper partition.
To learn about the boot source anyway, we repeat the algorithm the BROM
used to select the boot partition in the first place:
- Test EXT_CSD[179] to check if an eMMC boot partition is enabled.
- Test EXT_CSD[177] to check for valid MMC interface settings.
- Check if BOOT_ACK is enabled.
- Check the beginning of the first sector for a valid eGON signature.
- Load the whole SPL (limited to be at most 32KB).
- Recalculate the checksum to verify the SPL is valid.
If one of those steps fails, we bail out and continue loading from the
user data partition. Otherwise we load from the selected boot partition,
automatically adjusting the sector offset accordingly.
Since the boot source is needed twice in the boot process, we cache the
result of this test to avoid doing this costly test multiple times.
This allows the very same image file to be put onto an SD card, into the
eMMC user data partition or into the eMMC boot partition.
CONFIG_SUPPORT_EMMC_BOOT needs still to be enabled to activate this
feature, but it does not force booting from the eMMC boot partition
anymore.
Signed-off-by: Andre Przywara
---
arch/arm/mach-sunxi/board.c | 86 -
1 file changed, 85 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 586af24535d..a141f24acdd 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -291,7 +291,7 @@ unsigned long spl_mmc_get_uboot_raw_sector(struct mmc *mmc)
switch (sunxi_get_boot_source()) {
case SUNXI_BOOTED_FROM_MMC2:
- if (IS_ENABLED(CONFIG_SUPPORT_EMMC_BOOT))
+ if (spl_mmc_boot_mode(mmc, 1) == MMCSD_MODE_EMMCBOOT)
sector -= 8 * 2;
break;
case SUNXI_BOOTED_FROM_MMC0_HIGH:
@@ -310,6 +310,90 @@ u32 spl_boot_device(void)
return sunxi_get_boot_device();
}
+/*
+ * When booting from an eMMC boot partition, the SPL puts the same boot
+ * source code into SRAM A1 as when loading the SPL from the normal
+ * eMMC user data partition: 0x2. So to know where we have been loaded
+ * from, we repeat the BROM algorithm here: checking for a valid eGON boot
+ * image at offset 0 of a (potentially) selected boot partition.
+ * If any of the conditions is not met, it must have been the eMMC user
+ * data partition.
+ */
+static bool sunxi_valid_emmc_boot(struct mmc *mmc)
+{
+ struct blk_desc *bd = mmc_get_blk_desc(mmc);
+ uint32_t *buffer = (void *)(uintptr_t)CONFIG_SYS_TEXT_BASE;
+ int bootpart = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
+ uint32_t spl_size, emmc_checksum, chksum = 0;
+ ulong count;
+
+ /* The BROM requires BOOT_ACK to be enabled. */
+ if (!EXT_CSD_EXTRACT_BOOT_ACK(mmc->part_config))
+ return false;
+
+ /*
+* The BOOT_BUS_CONDITION register must be 4-bit SDR, with (0x09)
+* or without (0x01) high speed timings.
+*/
+ if ((mmc->ext_csd[EXT_CSD_BOOT_BUS_WIDTH] & 0x1b) != 0x01 &&
+ (mmc->ext_csd[EXT_CSD_BOOT_BUS_WIDTH] & 0x1b) != 0x09)
+ return false;
+
+ /* Partition 0 is the user data partition, bootpart must be 1 or 2. */
+ if (bootpart != 1 && bootpart != 2)
+ return false;
+
+ mmc_switch_part(mmc, bootpart);
+
+ /* Read the first block to do some sanity checks on the eGON header. */
+ count = blk_dread(bd, 0, 1, buffer);
+ if (count != 1 || !is_boot0_magic(buffer + 1))
+ return false;
+
+ /* The BROM will only read up to 32KB into SRAM A1. */
+ spl_size = buffer[4];
+ if ((spl_size & 3) || spl_size > 32768)
+ return false;
+
+ /* Read the rest of the SPL now we know it's halfway sane. */
+ count = blk_dread(bd, 1, DIV_ROUND_UP(spl_size, bd->blksz) - 1,
+ buffer + bd->blksz / 4);
+
+ /* Save the checksum and replace it with the "stamp value". */
+ emmc_checksum = buffer[3];
+ buffer[3] = 0x5f0a6c39;
+
+ /* The checksum is a simple ignore-carry addition of all words. */
+ for (count = 0; count < spl_size / 4; count++)
+ chksum += buffer[count];
+
+ debug("eMMC boot part SPL checksum: stored: 0x%08x, computed: 0x%08x\n",
+ emmc_checksum, chksum);
+
+ return emmc_checksum == chksum;
+}
+
+u32 spl_mmc_boot_mode(struct mmc *mmc, const u32 boot_device)
+{
+ static u32 result = ~0;
+
+ if (result != ~0)
+ return result;
+
+ result = MMCSD_MODE_RAW;
+ if (!IS_SD(mmc) && IS_ENABLED(CONFIG_SUPPORT_EMMC_BOOT)) {
+ if (sunxi_valid_emmc_boot(mmc))
+
[linux-sunxi] [PATCH 3/5] sunxi: Simplify eMMC boot partition booting
The Allwinner BROM also supports loading the SPL from the eMMC boot
partition, for this we have to set the CONFIG_SUPPORT_EMMC_BOOT Kconfig
symbol. But on top of that a user has to manually adjust the raw sector
to load U-Boot proper from: CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR.
To simplify this, we adjust the sector offset dynamically, whenever we
find CONFIG_SUPPORT_EMMC_BOOT enabled and are booting from the eMMC.
Unfortunately the BROM sets the same boot source code as for the boot
from the normal eMMC user data partition, so we can't tell those two
cases apart easily (yet).
Signed-off-by: Andre Przywara
---
arch/arm/mach-sunxi/board.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index f40fccd8f8b..586af24535d 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -279,21 +279,29 @@ uint32_t sunxi_get_boot_device(void)
#ifdef CONFIG_SPL_BUILD
/*
* The eGON SPL image can be located at 8KB or at 128KB into an SD card or
- * an eMMC device. The boot source has bit 4 set in the latter case.
+ * an eMMC user partition. The boot source has bit 4 set in the latter case.
* By adding 120KB to the normal offset when booting from a "high" location
* we can support both cases.
+ * In an eMMC boot partition the SPL is located at offset 0, so we subtract
+ * the usual 8K offset.
*/
unsigned long spl_mmc_get_uboot_raw_sector(struct mmc *mmc)
{
unsigned long sector = CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR;
switch (sunxi_get_boot_source()) {
+ case SUNXI_BOOTED_FROM_MMC2:
+ if (IS_ENABLED(CONFIG_SUPPORT_EMMC_BOOT))
+ sector -= 8 * 2;
+ break;
case SUNXI_BOOTED_FROM_MMC0_HIGH:
case SUNXI_BOOTED_FROM_MMC2_HIGH:
sector += (128 - 8) * 2;
break;
}
+ debug("loading U-Boot proper from sector 0x%lx\n", sector);
+
return sector;
}
--
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/20201108131409.14320-4-andre.przywara%40arm.com.
[linux-sunxi] [PATCH 1/5] sunxi: Fix is_boot0_magic macro
The is_boot0_magic macro is missing parentheses around the macro
argument, breaking any usage with a more complex argument.
Signed-off-by: Andre Przywara
---
arch/arm/include/asm/arch-sunxi/spl.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-sunxi/spl.h
b/arch/arm/include/asm/arch-sunxi/spl.h
index 8c916e8c752..6b3566f55e5 100644
--- a/arch/arm/include/asm/arch-sunxi/spl.h
+++ b/arch/arm/include/asm/arch-sunxi/spl.h
@@ -83,7 +83,7 @@ struct boot_file_head {
/* Compile time check to assure proper alignment of structure */
typedef char boot_file_head_not_multiple_of_32[1 - 2*(sizeof(struct
boot_file_head) % 32)];
-#define is_boot0_magic(addr) (memcmp((void *)addr, BOOT0_MAGIC, 8) == 0)
+#define is_boot0_magic(addr) (memcmp((void *)(addr), BOOT0_MAGIC, 8) == 0)
uint32_t sunxi_get_boot_device(void);
--
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/20201108131409.14320-2-andre.przywara%40arm.com.
[linux-sunxi] [PATCH 0/5] sunxi: enable automatic eMMC boot partition support
The eMMC standard describes the concept of boot partitions, consisting of two storage areas separate from the main user data partition. The Allwinner BootROM supports loading SPL/Boot0 from such a boot partition, if that is configured in the eMMC device [1]. To load U-Boot proper along with the SPL from there, currently this requires to enable CONFIG_SUPPORT_EMMC_BOOT, and this means that this build won't boot from the normal eMMC user partition anymore. Also the raw MMC sector offset needs to be adjusted manually, preventing a boot from an SD card. This series introduces automatic detection of eMMC boot partition boot. Patch 3/5 automates the raw MMC sector offset decision, allowing such a build to also boot from an SD card. Unfortunately the BootROM does not mark an eMMC boot partition boot differently from the normal eMMC user data partition boot, so patch 4/5 introduces a function that repeats the BootROM algorithm, so that the SPL comes to the same conclusion as the BootROM. This allows to build one single image that boots from everywhere: eMMC user data, eMMC boot, SD card, SPI flash. Patch 1/5 contains a bugfix that's needed in a later patch, patch 2/5 extends the generic spl_mmc_boot_mode() interface to make 4/5 feasible. Without enabling CONFIG_SUPPORT_EMMC_BOOT, the AArch64 SPL grows by 92 bytes, ARMv7 grows by 36 bytes. With enabling the feature, the size goes up by 444 bytes (AArch64) and 260 bytes (ARMv7). Even for AArch64 this is still 4.5 KB below the SPL limit, so patch 5/5 enables this new mechanism for some boards I could test this on. Please have a look and test this if you have a board with eMMC. I put installation instructions into the linux-sunxi Wiki: http://linux-sunxi.org/Bootable_eMMC Cheers, Andre [1] http://linux-sunxi.org/Bootable_eMMC#The_BROM_implementation_details Andre Przywara (5): sunxi: Fix is_boot0_magic macro spl: mmc: extend spl_mmc_boot_mode() to take mmc argument sunxi: Simplify eMMC boot partition booting sunxi: eMMC: Add automatic boot detection sunxi: defconfig: enable eMMC boot partition support arch/arm/include/asm/arch-sunxi/spl.h | 2 +- arch/arm/mach-imx/spl.c| 2 +- arch/arm/mach-k3/am6_init.c| 2 +- arch/arm/mach-k3/j721e_init.c | 2 +- arch/arm/mach-omap2/boot-common.c | 2 +- arch/arm/mach-rockchip/spl.c | 2 +- arch/arm/mach-socfpga/spl_a10.c| 2 +- arch/arm/mach-socfpga/spl_agilex.c | 2 +- arch/arm/mach-socfpga/spl_gen5.c | 2 +- arch/arm/mach-socfpga/spl_s10.c| 2 +- arch/arm/mach-stm32mp/spl.c| 2 +- arch/arm/mach-sunxi/board.c| 94 +- arch/arm/mach-uniphier/mmc-boot-mode.c | 5 +- common/spl/spl_mmc.c | 4 +- configs/bananapi_m64_defconfig | 1 + configs/emlid_neutis_n5_devboard_defconfig | 1 + configs/pine64-lts_defconfig | 1 + configs/pine_h64_defconfig | 1 + include/spl.h | 3 +- 19 files changed, 113 insertions(+), 19 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/20201108131409.14320-1-andre.przywara%40arm.com.
