Re: Pull request tpm-03092022
On Sat, Sep 03, 2022 at 07:42:47PM +0300, Ilias Apalodimas wrote: > Hi Tom, > > The following changes since commit 67fe8cc0016756f3479288b3f67d59a517e512d5: > > Merge tag 'efi-2022-10-rc4' of > https://source.denx.de/u-boot/custodians/u-boot-efi (2022-09-02 09:09:47 > -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-tpm/ tags/tpm-03092022 > > for you to fetch changes up to 5208ed187cb6314dc64657802e8e5bb5a5e3a7fb: > > tpm: Allow committing non-volatile data (2022-09-03 16:59:05 +0300) > > CI: > https://source.denx.de/u-boot/custodians/u-boot-tpm/-/commit/5208ed187cb6314dc64657802e8e5bb5a5e3a7fb > > Please pull > > Thanks > /Ilias > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-sh/master
On Sat, Sep 03, 2022 at 04:32:18PM +0200, Marek Vasut wrote: > The following changes since commit 4e10c1227aa879af809b3073bf917289f23e17d7: > > Merge branch '2022-08-31-assorted-fixes' (2022-08-31 19:32:31 -0400) > > are available in the Git repository at: > > git://source.denx.de/u-boot-sh.git master > > for you to fetch changes up to 68083b897b57309c29039b27d2580e4eb9c6e455: > > renesas: Fix RPC-IF compatible values (2022-09-02 13:25:01 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-usb/master
On Sat, Sep 03, 2022 at 04:31:43PM +0200, Marek Vasut wrote: > The following changes since commit 4e10c1227aa879af809b3073bf917289f23e17d7: > > Merge branch '2022-08-31-assorted-fixes' (2022-08-31 19:32:31 -0400) > > are available in the Git repository at: > > git://source.denx.de/u-boot-usb.git master > > for you to fetch changes up to 2522bd3ea67d6e22259cf363eeb3822a358b50d6: > > drivers: usb: fastboot: Fix full-speed usb descriptor (2022-09-02 13:26:58 > +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Pull request: u-boot-rockchip-20220905
Hi Tom, Please pull the rockchip fixes if possible: - migrate to use binman for U-Boot image generate on rockchip platform; - Some fixes for rk3399 and rk3308; Gitlab ci: https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip/pipelines/13334 Thanks, - Kever The following changes since commit 8710676635574bb457159fd6fa1c92d065ddb144: Merge tag 'efi-2022-10-rc4-2' of https://source.denx.de/u-boot/custodians/u-boot-efi (2022-09-03 07:44:22 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-rockchip.git tags/u-boot-rockchip-20220905 for you to fetch changes up to f103c112660217f8875398435e47d545ba934a5c: clk: rockchip: rk3399: Fix Unknown clock 77 on mmc@fe31 (2022-09-04 20:00:39 +0800) Han Pengfei (1): drivers: ram: rockchip: Fix dram channels calculation for rk3399 Johan Jonker (1): arm: dts: rockchip: rk3288: rename mmc nodenames John Keeping (2): rockchip: rk3308: fix rockchip_dnl_key_pressed() on roc-cc rockchip: rk3308: fix same-as-spl boot order Lee Jones (3): ram: rk3399: Fix .set_rate_index() error handling ram: rk3399: Fix faulty frequency change reports ram: rk3399: Conduct memory training at 400MHz Michal Suchanek (1): clk: rockchip: rk3399: Fix Unknown clock 77 on mmc@fe31 Quentin Schulz (11): rockchip: rk3399: boot_devices: fix eMMC node name rockchip: rk3399: fix incorrect boot-device in u-boot, spl-boot-device rockchip: rk3399: sync spl_boot_devices_tbl and boot_devices node paths binman: add support for skipping file concatenation for mkimage binman: allow user-defined filenames for mkimage entry rockchip: remove binman temporary files when cleaning rockchip: generate idbloader.img content for u-boot-rockchip.bin with binman for ARM rockchip: generate u-boot-rockchip.bin with binman for ARM64 boards rockchip: simplify binman image dependencies addition to INPUTS rockchip: allow to build SPI images even without HAS_ROM option rockchip: add u-boot-rockchip-spi.bin image for booting from SPI-NOR flash Makefile | 41 +++--- arch/arm/Kconfig | 2 +- arch/arm/dts/px30-u-boot.dtsi | 2 + arch/arm/dts/rk3288-u-boot.dtsi | 2 +- arch/arm/dts/rk3288.dtsi | 16 +++--- arch/arm/dts/rk3308-u-boot.dtsi | 2 + arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi| 2 + arch/arm/dts/rk3328-u-boot.dtsi | 2 + arch/arm/dts/rk3368-u-boot.dtsi | 1 + arch/arm/dts/rk3399-u-boot.dtsi | 2 +- arch/arm/dts/rk3568-u-boot.dtsi | 2 + arch/arm/dts/rockchip-u-boot.dtsi | 46 +++- arch/arm/mach-rockchip/Kconfig| 6 +-- arch/arm/mach-rockchip/rk3308/rk3308.c| 6 +++ arch/arm/mach-rockchip/rk3399/rk3399.c| 8 +-- board/firefly/firefly-rk3308/roc_cc_rk3308.c | 2 +- drivers/clk/rockchip/clk_rk3399.c | 66 +++ drivers/ram/rockchip/sdram_rk3399.c | 42 +-- tools/binman/entries.rst | 22 tools/binman/etype/mkimage.py | 52 +++--- tools/binman/ftest.py | 30 +++ tools/binman/test/252_mkimage_mult_data.dts | 21 tools/binman/test/253_mkimage_mult_no_content.dts | 22 tools/binman/test/254_mkimage_filename.dts| 18 +++ 24 files changed, 313 insertions(+), 102 deletions(-) create mode 100644 tools/binman/test/252_mkimage_mult_data.dts create mode 100644 tools/binman/test/253_mkimage_mult_no_content.dts create mode 100644 tools/binman/test/254_mkimage_filename.dts
Re: [PATCH] mmc: ftsdc010: make command timeout 250 ms as in the comment
> From: Sergei Antonov > Sent: Friday, September 02, 2022 3:40 PM > To: u-boot@lists.denx.de > Cc: jh80.ch...@samsung.com; peng@nxp.com; yamada.masah...@socionext.com; > s...@chromium.org; Rick Jian-Zhi Chen(陳建志) ; Sergei > Antonov > Subject: [PATCH] mmc: ftsdc010: make command timeout 250 ms as in the comment > > Get rid of discrepancy beween comment /* 250 ms */ and code which shifts by 4 > thus dividing by 16. > So change code to shift by 2 and make the timeout value 250 ms. > > Signed-off-by: Sergei Antonov > --- > drivers/mmc/ftsdc010_mci.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mmc/ftsdc010_mci.c b/drivers/mmc/ftsdc010_mci.c index > 570d54cf9d8f..cabb747fbbdb 100644 > --- a/drivers/mmc/ftsdc010_mci.c > +++ b/drivers/mmc/ftsdc010_mci.c > @@ -30,7 +30,7 @@ > #include > #include > > -#define CFG_CMD_TIMEOUT (CONFIG_SYS_HZ >> 4) /* 250 ms */ > +#define CFG_CMD_TIMEOUT (CONFIG_SYS_HZ >> 2) /* 250 ms */ Reviewed-by: Rick Chen
Re: [PATCH 0/9] Nokia RX-51: Small cleanups and UBI boot test case
On Sunday 04 September 2022 22:58:19 Daniel Golle wrote: > On Sun, Sep 04, 2022 at 12:28:24PM -0700, Tony Dinh wrote: > > Hi Pali, > > > > On Sun, Sep 4, 2022 at 2:37 AM Pali Rohár wrote: > > > > > > On Saturday 03 September 2022 20:01:45 Tony Dinh wrote: > > > > Hi Pali, > > > > > > > > On Sat, Sep 3, 2022 at 6:29 PM Pali Rohár wrote: > > > > > > > > > > Do various small fixup/cleanups and extend test script to boot kernel > > > > > image from UBI volume. This test verifies that U-Boot UBI > > > > > implementation > > > > > is working and U-Boot can read volume with bootable kernel code > > > > > correctly. And therefore CI prevents UBI breakage. > > > > > > > > > > Note that U-Boot UBIFS code on ARM is currently somehow broken and > > > > > trying to mount UBIFS from UBI volume fails :-( I have already tried > > > > > to > > > > > debug this issue but I have no idea why it is failing. > > > > > > > > I've recently implemented UBI distro boot on a pair of Kirkwood boards > > > > (Pogo V4 and NSA310s) successfully. I created the UBI partition and > > > > formatted it in Debian 11.x, Linux kernel 5.19.x. I could let the > > > > u-boot distro boot scan the UBI partition to find the boot script > > > > boot.scr. And also mount it manually to look at the file system. > > > > > > Hello! I think you mean UBIFS on UBI, right? > > > > Yes. UBIFS on UBI. > > > > > > > > > An observation: I cannot mount OpenWrt rootfs in u-boot, since it is > > > > an UBIFS volume overlay on squashfs. But creating my own UBIFS volume > > > > allowed me to mount it in the u-boot command line. I think squashfs is > > > > incomplete in u-boot, at the moment. > > > > > > UBIFS on squashfs? This looks strange. AFAIK UBIFS (also on linux) works > > > only on UBI. I guess you could have squashfs on UBI, but on linux this > > > requires mtdblock, hence it is squashfs on mtdblock on UBI. > > > > I meant that (the rootfs) is a squashfs inside an UBIFS volume. And > > the system running with another UBIFS volume overlaid on top of that. > > Just to clarify: OpenWrt uses squashfs in UBI volumes for the compressed > rootfs. In Linux, ubiblock is used to mount them. That is what I thought. squashfs on ubiblock. IIRC U-Boot does not implement neither mtdblock (block device on mtd) nor ubiblock (block device on top of ubi volume). So mounting squashfs (which is block based filesystem) from ubi volume does not work in u-boot. I think implementation should not be such hard, this sounds like and interesting exercise. But I'm more interested to figure out why UBIFS does not want to work on ARM Omap3 Nokia N900, but works fine on PowerPC Freescale P2020 > We also usually don't store the kernel in a filesystem but just use a > bare UBI volume to directly store the uImage.FIT to be booted, for both > simplicity and robustness reasons. > On devices with recent enough U-Boot we can use a 'filesystem'-type > sub-image of a uImage.FIT for squashfs and mount that in Linux. > > > > > Best, > > Tony > > > > > > > > > Best, > > > > Tony > > > > > > > > > > > > > Function > > > > > check_lpt_crc in unpack_ltab is failing. Volume is for sure correct > > > > > and > > > > > valid because Linux kernel can successfully mount it. And to make it > > > > > more suspicious, U-Boot UBIFS is working fine on big endian powerpc > > > > > platform. So UBIFS issue is probably endian or arch specific. > > > > > (This is UBIFS related, not UBI related.) > > > > > > > > > > Pali Rohár (9): > > > > > Nokia RX-51: Remove label copy_kernel_start from lowlevel_init.S > > > > > Nokia RX-51: Do not clear unknown memory in lowlevel_init.S > > > > > Nokia RX-51: Set default SYS_LOAD_ADDR to 0x80008000 > > > > > Nokia RX-51: Change UBIFS volume size to 1870 LEBs in test script > > > > > Nokia RX-51: Call bootm in test script only when image is valid > > > > > Nokia RX-51: Fix documentation how to enable UBI support > > > > > Nokia RX-51: Do not set useless ARCH= in test script > > > > > Nokia RX-51: Add comment describing kernel image type into test > > > > > script > > > > > Nokia RX-51: Add booting from UBI into test script > > > > > > > > > > board/nokia/rx51/lowlevel_init.S | 7 +-- > > > > > configs/nokia_rx51_defconfig | 2 +- > > > > > doc/board/nokia/rx51.rst | 3 +- > > > > > test/nokia_rx51_test.sh | 97 > > > > > +--- > > > > > 4 files changed, 82 insertions(+), 27 deletions(-) > > > > > > > > > > -- > > > > > 2.20.1 > > > > >
Re: [PATCH 0/9] Nokia RX-51: Small cleanups and UBI boot test case
On Sun, Sep 04, 2022 at 12:28:24PM -0700, Tony Dinh wrote: > Hi Pali, > > On Sun, Sep 4, 2022 at 2:37 AM Pali Rohár wrote: > > > > On Saturday 03 September 2022 20:01:45 Tony Dinh wrote: > > > Hi Pali, > > > > > > On Sat, Sep 3, 2022 at 6:29 PM Pali Rohár wrote: > > > > > > > > Do various small fixup/cleanups and extend test script to boot kernel > > > > image from UBI volume. This test verifies that U-Boot UBI implementation > > > > is working and U-Boot can read volume with bootable kernel code > > > > correctly. And therefore CI prevents UBI breakage. > > > > > > > > Note that U-Boot UBIFS code on ARM is currently somehow broken and > > > > trying to mount UBIFS from UBI volume fails :-( I have already tried to > > > > debug this issue but I have no idea why it is failing. > > > > > > I've recently implemented UBI distro boot on a pair of Kirkwood boards > > > (Pogo V4 and NSA310s) successfully. I created the UBI partition and > > > formatted it in Debian 11.x, Linux kernel 5.19.x. I could let the > > > u-boot distro boot scan the UBI partition to find the boot script > > > boot.scr. And also mount it manually to look at the file system. > > > > Hello! I think you mean UBIFS on UBI, right? > > Yes. UBIFS on UBI. > > > > > > An observation: I cannot mount OpenWrt rootfs in u-boot, since it is > > > an UBIFS volume overlay on squashfs. But creating my own UBIFS volume > > > allowed me to mount it in the u-boot command line. I think squashfs is > > > incomplete in u-boot, at the moment. > > > > UBIFS on squashfs? This looks strange. AFAIK UBIFS (also on linux) works > > only on UBI. I guess you could have squashfs on UBI, but on linux this > > requires mtdblock, hence it is squashfs on mtdblock on UBI. > > I meant that (the rootfs) is a squashfs inside an UBIFS volume. And > the system running with another UBIFS volume overlaid on top of that. Just to clarify: OpenWrt uses squashfs in UBI volumes for the compressed rootfs. In Linux, ubiblock is used to mount them. We also usually don't store the kernel in a filesystem but just use a bare UBI volume to directly store the uImage.FIT to be booted, for both simplicity and robustness reasons. On devices with recent enough U-Boot we can use a 'filesystem'-type sub-image of a uImage.FIT for squashfs and mount that in Linux. > > Best, > Tony > > > > > > Best, > > > Tony > > > > > > > > > > Function > > > > check_lpt_crc in unpack_ltab is failing. Volume is for sure correct and > > > > valid because Linux kernel can successfully mount it. And to make it > > > > more suspicious, U-Boot UBIFS is working fine on big endian powerpc > > > > platform. So UBIFS issue is probably endian or arch specific. > > > > (This is UBIFS related, not UBI related.) > > > > > > > > Pali Rohár (9): > > > > Nokia RX-51: Remove label copy_kernel_start from lowlevel_init.S > > > > Nokia RX-51: Do not clear unknown memory in lowlevel_init.S > > > > Nokia RX-51: Set default SYS_LOAD_ADDR to 0x80008000 > > > > Nokia RX-51: Change UBIFS volume size to 1870 LEBs in test script > > > > Nokia RX-51: Call bootm in test script only when image is valid > > > > Nokia RX-51: Fix documentation how to enable UBI support > > > > Nokia RX-51: Do not set useless ARCH= in test script > > > > Nokia RX-51: Add comment describing kernel image type into test script > > > > Nokia RX-51: Add booting from UBI into test script > > > > > > > > board/nokia/rx51/lowlevel_init.S | 7 +-- > > > > configs/nokia_rx51_defconfig | 2 +- > > > > doc/board/nokia/rx51.rst | 3 +- > > > > test/nokia_rx51_test.sh | 97 +--- > > > > 4 files changed, 82 insertions(+), 27 deletions(-) > > > > > > > > -- > > > > 2.20.1 > > > >
[PATCH v1] arm: dts: rockchip: rk3128: fix DT node names
The rk3128 DT node names should be generic.
Rename them to the pattern defined in the DT bindings.
Signed-off-by: Johan Jonker
---
arch/arm/dts/rk3128-evb.dts | 5 +++
arch/arm/dts/rk3128.dtsi| 62 +
2 files changed, 33 insertions(+), 34 deletions(-)
diff --git a/arch/arm/dts/rk3128-evb.dts b/arch/arm/dts/rk3128-evb.dts
index e7d8f7c9..93291d78 100644
--- a/arch/arm/dts/rk3128-evb.dts
+++ b/arch/arm/dts/rk3128-evb.dts
@@ -15,6 +15,11 @@
stdout-path =
};
+ memory@6000 {
+ device_type = "memory";
+ reg = <0x6000 0x4000>;
+ };
+
vcc5v0_otg: vcc5v0-otg-drv {
compatible = "regulator-fixed";
regulator-name = "vcc5v0_otg";
diff --git a/arch/arm/dts/rk3128.dtsi b/arch/arm/dts/rk3128.dtsi
index 589818da..f66efde3 100644
--- a/arch/arm/dts/rk3128.dtsi
+++ b/arch/arm/dts/rk3128.dtsi
@@ -8,7 +8,6 @@
#include
#include
#include
-#include "skeleton.dtsi"
/ {
compatible = "rockchip,rk3128";
@@ -34,11 +33,6 @@
mmc1 =
};
- memory {
- device_type = "memory";
- reg = <0x6000 0x4000>;
- };
-
arm-pmu {
compatible = "arm,cortex-a7-pmu";
interrupts = ,
@@ -52,10 +46,10 @@
#size-cells = <0>;
enable-method = "rockchip,rk3128-smp";
- cpu0:cpu@0x000 {
+ cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a7";
- reg = <0x000>;
+ reg = <0x0>;
operating-points = <
/* KHzuV */
816000 100
@@ -65,22 +59,22 @@
clocks = < ARMCLK>;
};
- cpu1:cpu@0x001 {
+ cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a7";
- reg = <0x001>;
+ reg = <0x1>;
};
- cpu2:cpu@0x002 {
+ cpu2: cpu@2 {
device_type = "cpu";
compatible = "arm,cortex-a7";
- reg = <0x002>;
+ reg = <0x2>;
};
- cpu3:cpu@0x003 {
+ cpu3: cpu@3 {
device_type = "cpu";
compatible = "arm,cortex-a7";
- reg = <0x003>;
+ reg = <0x3>;
};
};
@@ -165,7 +159,7 @@
interrupt-parent = <>;
ranges;
- pdma: pdma@20078000 {
+ pdma: dma-controller@20078000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x20078000 0x4000>;
arm,pl330-broken-no-flushp;//2
@@ -207,7 +201,7 @@
rockchip,broadcast = <1>;
};
- watchdog: wdt@2004c000 {
+ watchdog: watchdog@2004c000 {
compatible = "rockchip,watch dog";
reg = <0x2004c000 0x100>;
clock-names = "pclk_wdt";
@@ -224,7 +218,7 @@
#reset-cells = <1>;
};
- nandc: nandc@1050 {
+ nandc: nand-controller@1050 {
compatible = "rockchip,rk-nandc";
reg = <0x1050 0x4000>;
interrupts = ;
@@ -247,7 +241,7 @@
assigned-clock-rates = <59400>;
};
- uart0: serial0@2006 {
+ uart0: serial@2006 {
compatible = "rockchip,rk3128-uart", "snps,dw-apb-uart";
reg = <0x2006 0x100>;
interrupts = ;
@@ -262,7 +256,7 @@
#dma-cells = <2>;
};
- uart1: serial1@20064000 {
+ uart1: serial@20064000 {
compatible = "rockchip,rk3128-uart", "snps,dw-apb-uart";
reg = <0x20064000 0x100>;
interrupts = ;
@@ -277,7 +271,7 @@
#dma-cells = <2>;
};
- uart2: serial2@20068000 {
+ uart2: serial@20068000 {
compatible = "rockchip,rk3128-uart", "snps,dw-apb-uart";
reg = <0x20068000 0x100>;
interrupts = ;
@@ -304,7 +298,7 @@
status = "disabled";
};
- pwm0: pwm0@2005 {
+ pwm0: pwm@2005 {
compatible = "rockchip,rk3128-pwm", "rockchip,rk3288-pwm";
reg = <0x2005 0x10>;
#pwm-cells = <3>;
@@ -314,7 +308,7 @@
clock-names = "pwm";
};
- pwm1: pwm1@20050010 {
+ pwm1: pwm@20050010 {
compatible = "rockchip,rk3128-pwm", "rockchip,rk3288-pwm";
reg = <0x20050010 0x10>;
Re: [PATCH 0/9] Nokia RX-51: Small cleanups and UBI boot test case
On Sun, Sep 4, 2022 at 12:28 PM Tony Dinh wrote: > > Hi Pali, > > On Sun, Sep 4, 2022 at 2:37 AM Pali Rohár wrote: > > > > On Saturday 03 September 2022 20:01:45 Tony Dinh wrote: > > > Hi Pali, > > > > > > On Sat, Sep 3, 2022 at 6:29 PM Pali Rohár wrote: > > > > > > > > Do various small fixup/cleanups and extend test script to boot kernel > > > > image from UBI volume. This test verifies that U-Boot UBI implementation > > > > is working and U-Boot can read volume with bootable kernel code > > > > correctly. And therefore CI prevents UBI breakage. > > > > > > > > Note that U-Boot UBIFS code on ARM is currently somehow broken and > > > > trying to mount UBIFS from UBI volume fails :-( I have already tried to > > > > debug this issue but I have no idea why it is failing. > > > > > > I've recently implemented UBI distro boot on a pair of Kirkwood boards > > > (Pogo V4 and NSA310s) successfully. I created the UBI partition and > > > formatted it in Debian 11.x, Linux kernel 5.19.x. I could let the > > > u-boot distro boot scan the UBI partition to find the boot script > > > boot.scr. And also mount it manually to look at the file system. > > > > Hello! I think you mean UBIFS on UBI, right? > > Yes. UBIFS on UBI. > > > > > > An observation: I cannot mount OpenWrt rootfs in u-boot, since it is > > > an UBIFS volume overlay on squashfs. But creating my own UBIFS volume > > > allowed me to mount it in the u-boot command line. I think squashfs is > > > incomplete in u-boot, at the moment. > > > > UBIFS on squashfs? This looks strange. AFAIK UBIFS (also on linux) works > > only on UBI. I guess you could have squashfs on UBI, but on linux this > > requires mtdblock, hence it is squashfs on mtdblock on UBI. > > I meant that (the rootfs) is a squashfs inside an UBIFS volume. And > the system running with another UBIFS volume overlaid on top of that. I should say "UBI volume" above. > > Best, > Tony > > > > > > Best, > > > Tony > > > > > > > > > > Function > > > > check_lpt_crc in unpack_ltab is failing. Volume is for sure correct and > > > > valid because Linux kernel can successfully mount it. And to make it > > > > more suspicious, U-Boot UBIFS is working fine on big endian powerpc > > > > platform. So UBIFS issue is probably endian or arch specific. > > > > (This is UBIFS related, not UBI related.) > > > > > > > > Pali Rohár (9): > > > > Nokia RX-51: Remove label copy_kernel_start from lowlevel_init.S > > > > Nokia RX-51: Do not clear unknown memory in lowlevel_init.S > > > > Nokia RX-51: Set default SYS_LOAD_ADDR to 0x80008000 > > > > Nokia RX-51: Change UBIFS volume size to 1870 LEBs in test script > > > > Nokia RX-51: Call bootm in test script only when image is valid > > > > Nokia RX-51: Fix documentation how to enable UBI support > > > > Nokia RX-51: Do not set useless ARCH= in test script > > > > Nokia RX-51: Add comment describing kernel image type into test script > > > > Nokia RX-51: Add booting from UBI into test script > > > > > > > > board/nokia/rx51/lowlevel_init.S | 7 +-- > > > > configs/nokia_rx51_defconfig | 2 +- > > > > doc/board/nokia/rx51.rst | 3 +- > > > > test/nokia_rx51_test.sh | 97 +--- > > > > 4 files changed, 82 insertions(+), 27 deletions(-) > > > > > > > > -- > > > > 2.20.1 > > > >
Re: [PATCH v2 3/8] timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support
Hi Michael, On Sun, Sep 4, 2022 at 1:54 AM Michael Walle wrote: > > Am 2022-09-04 02:02, schrieb Tony Dinh: > > Hi Stefan, > > > > Sorry, that message was prematurely sent (fat finger). Please see the > > continuation below. > > > > On Sat, Sep 3, 2022 at 4:43 PM Tony Dinh wrote: > >> > >> Hi Stefan, > >> > >> On Sat, Sep 3, 2022 at 3:44 AM Stefan Roese wrote: > >> > > >> > Hi Tony, > >> > > >> > On 03.09.22 11:44, Tony Dinh wrote: > >> > > Hi Stefan, > >> > > > >> > > On Thu, Sep 1, 2022 at 11:25 PM Stefan Roese wrote: > >> > >> > >> > >> Add timer_get_boot_us() to support boards, that have CONFIG_BOOTSTAGE > >> > >> enabled, like pogo_v4. > >> > >> > >> > >> Signed-off-by: Stefan Roese > >> > >> --- > >> > >> v2: > >> > >> - Change timer_get_boot_us() to use the timer_early functions > >> > >> - Remove #if CONFIG_IS_ENABLED(BOOTSTAGE) > >> > >> > >> > >> Simon, I'm currently looking into this timer_get_boot_us() to using > >> > >> timer_early_get_count() etc consolidation. > >> > > > >> > > Indeed, as you've mentioned above, I think timer_early_get_count() and > >> > > timer_early_get_rate() do need to take into consideration what the > >> > > input_clock_type is for Kirkwood boards with CONFIG_BOOTSTAGE such as > >> > > the Pogo V4. > >> > > > >> > > I'm seeing on the Pogo V4 test, the timer command reports time about 6 > >> > > times slower than it should. It does seem to jive with the fact that > >> > > the Pogo V4 CONFIG_SYS_TCLK is 166Mhz, versus MVEBU 25MHz clock rate. > >> > > >> > Ah, I've missing updating the early functions to also differentiate > >> > between fixed clocks and TCLK timer. > >> > > >> > Please give the attached patch a try - should be applied on top of this > >> > latest patchset. > >> > > > > That looks promising, but I think we are still missing something. > > After applying the attached patch, I ran the test again and it behaved > > the same way (clock rate 6 times slower). So I did another test. > > > > --- Test 1 > > Pogo_V4> timer start; sleep 60; timer get; sleep 30; timer get > > 60.000 > > 90.000 > > > > So apparently the sleep cmd has reset the correct clock rate. > > > > --- Test 2 > > > > Pogo_V4> timer start; sleep 30; timer get; sleep 30; timer get > > 30.000 > > 60.000 > > > > And then wait for 30 seconds, do another "timer get" (I expected to > > see about 90 to 95 seconds). > > > > Pogo_V4> timer get > > 66.237 > > I've did the same test and can confirm it. But I think that is > a drawback from the timer command. With a 32bit timer and a > TCLK of 166MHz (on my board), the timer will wrap around about > every 26s. So if you don't do a get_timer() call for that whole > period, the overflow won't be counted in timer_conv_64(). > > For the sleep command it works correctly, because it will > poll get_timer() every 100us. > > In summary, you cannot expect a "timer get" on the console > to work if you cannot make sure, the you call it at least > every "2^32 / TCLK" seconds. > > -michael Thanks for confirming that and the explanation. It makes perfect sense! I think I got side tracked and never noticed that it is a 32-bit timer wrap- around :) All the best, Tony
Re: [PATCH 0/9] Nokia RX-51: Small cleanups and UBI boot test case
Hi Pali, On Sun, Sep 4, 2022 at 2:37 AM Pali Rohár wrote: > > On Saturday 03 September 2022 20:01:45 Tony Dinh wrote: > > Hi Pali, > > > > On Sat, Sep 3, 2022 at 6:29 PM Pali Rohár wrote: > > > > > > Do various small fixup/cleanups and extend test script to boot kernel > > > image from UBI volume. This test verifies that U-Boot UBI implementation > > > is working and U-Boot can read volume with bootable kernel code > > > correctly. And therefore CI prevents UBI breakage. > > > > > > Note that U-Boot UBIFS code on ARM is currently somehow broken and > > > trying to mount UBIFS from UBI volume fails :-( I have already tried to > > > debug this issue but I have no idea why it is failing. > > > > I've recently implemented UBI distro boot on a pair of Kirkwood boards > > (Pogo V4 and NSA310s) successfully. I created the UBI partition and > > formatted it in Debian 11.x, Linux kernel 5.19.x. I could let the > > u-boot distro boot scan the UBI partition to find the boot script > > boot.scr. And also mount it manually to look at the file system. > > Hello! I think you mean UBIFS on UBI, right? Yes. UBIFS on UBI. > > > An observation: I cannot mount OpenWrt rootfs in u-boot, since it is > > an UBIFS volume overlay on squashfs. But creating my own UBIFS volume > > allowed me to mount it in the u-boot command line. I think squashfs is > > incomplete in u-boot, at the moment. > > UBIFS on squashfs? This looks strange. AFAIK UBIFS (also on linux) works > only on UBI. I guess you could have squashfs on UBI, but on linux this > requires mtdblock, hence it is squashfs on mtdblock on UBI. I meant that (the rootfs) is a squashfs inside an UBIFS volume. And the system running with another UBIFS volume overlaid on top of that. Best, Tony > > > Best, > > Tony > > > > > > > Function > > > check_lpt_crc in unpack_ltab is failing. Volume is for sure correct and > > > valid because Linux kernel can successfully mount it. And to make it > > > more suspicious, U-Boot UBIFS is working fine on big endian powerpc > > > platform. So UBIFS issue is probably endian or arch specific. > > > (This is UBIFS related, not UBI related.) > > > > > > Pali Rohár (9): > > > Nokia RX-51: Remove label copy_kernel_start from lowlevel_init.S > > > Nokia RX-51: Do not clear unknown memory in lowlevel_init.S > > > Nokia RX-51: Set default SYS_LOAD_ADDR to 0x80008000 > > > Nokia RX-51: Change UBIFS volume size to 1870 LEBs in test script > > > Nokia RX-51: Call bootm in test script only when image is valid > > > Nokia RX-51: Fix documentation how to enable UBI support > > > Nokia RX-51: Do not set useless ARCH= in test script > > > Nokia RX-51: Add comment describing kernel image type into test script > > > Nokia RX-51: Add booting from UBI into test script > > > > > > board/nokia/rx51/lowlevel_init.S | 7 +-- > > > configs/nokia_rx51_defconfig | 2 +- > > > doc/board/nokia/rx51.rst | 3 +- > > > test/nokia_rx51_test.sh | 97 +--- > > > 4 files changed, 82 insertions(+), 27 deletions(-) > > > > > > -- > > > 2.20.1 > > >
Re: [PATCH v2 2/2] efi_selftest: unit test for EFI Conformance Profile Table
On Sun, Sep 04, 2022 at 09:53:03AM +0200, Heinrich Schuchardt wrote:
>
>
> On 9/4/22 07:08, Ilias Apalodimas wrote:
> > Hi Heinrich,
> >
> > [...]
> >
> > > + */
> > > +static int ecpt_find_guid(struct efi_conformance_profiles_table *ecpt,
> > > + const efi_guid_t *guid) {
> > > + int i;
> > > +
> > > + for (i = 0; i < ecpt->number_of_profiles; ++i) {
> > > + if (!memcmp(>conformance_profiles[i], guid, 16))
> > > + return EFI_ST_SUCCESS;
> >
> > Can't we use guidcmp here?
>
> I would prefer to keep the unit tests independent of U-Boot's library
> functions so that we can opt to compile them as freestanding UEFI
> application.
>
> Best regards
Fair enough,
Reviewed-by: Ilias Apalodimas
>
> Heinrich
>
> >
> > > + }
> > > + efi_st_error("GUID %pU not found\n", guid);
> > > + return EFI_ST_FAILURE;
> > > +}
> > > +
> > > +/*
> > [...]
> >
> > Thanks
> > /Ilias
Re: [PATCH] scripts: config_whitelist: CONFIG_SYS_FLASH_AUTOPROTECT_LIST
On Sun, 4 Sept 2022 at 18:30, Tom Rini wrote:
>
> On Sun, Sep 04, 2022 at 06:28:56PM +0300, Sergei Antonov wrote:
> > On Sun, 4 Sept 2022 at 18:23, Tom Rini wrote:
> > > > > > > What type must it be in Kconfig? Note, it is an array initializer
> > > > > > > similar to CONFIG_SYS_BAUDRATE_TABLE.
> > > > > >
> > > > > > Ah, ugh. So, it's also currently unused code, what does it look
> > > > > > like in
> > > > > > the platform you're making use of this on?
> > > > >
> > > > > In my _defconfig I use this line:
> > > > > CONFIG_SYS_FLASH_AUTOPROTECT_LIST="{{0x8000, 0x4}}"
> > > > > To protect the first 256 KB of flash memory.
> > > >
> > > > Please, disregard the previous message. I was too hasty to reply.
> > > >
> > > > I have include/configs/myplatform.h file which contains this line:
> > > > #define CONFIG_SYS_FLASH_AUTOPROTECT_LIST {{0x8000, 0x4}}
> > > >
> > > > And I could not convert it to Kconfig string parameter.
> > >
> > > Can this information be obtained from an existing device tree binding on
> > > the platform?
> >
> > Device tree exists. No, DT does not currently contain this
> > information. But it can be added.
>
> OK. But, is there an existing binding, or would it be a new one?
I am using an existing "cfi-flash" driver:
nor@8000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "cfi-flash";
reg = <0x8000 0x0>;
...
}
Re: [PATCH] scripts: config_whitelist: CONFIG_SYS_FLASH_AUTOPROTECT_LIST
On Sun, Sep 04, 2022 at 06:28:56PM +0300, Sergei Antonov wrote:
> On Sun, 4 Sept 2022 at 18:23, Tom Rini wrote:
> > > > > > What type must it be in Kconfig? Note, it is an array initializer
> > > > > > similar to CONFIG_SYS_BAUDRATE_TABLE.
> > > > >
> > > > > Ah, ugh. So, it's also currently unused code, what does it look like
> > > > > in
> > > > > the platform you're making use of this on?
> > > >
> > > > In my _defconfig I use this line:
> > > > CONFIG_SYS_FLASH_AUTOPROTECT_LIST="{{0x8000, 0x4}}"
> > > > To protect the first 256 KB of flash memory.
> > >
> > > Please, disregard the previous message. I was too hasty to reply.
> > >
> > > I have include/configs/myplatform.h file which contains this line:
> > > #define CONFIG_SYS_FLASH_AUTOPROTECT_LIST {{0x8000, 0x4}}
> > >
> > > And I could not convert it to Kconfig string parameter.
> >
> > Can this information be obtained from an existing device tree binding on
> > the platform?
>
> Device tree exists. No, DT does not currently contain this
> information. But it can be added.
OK. But, is there an existing binding, or would it be a new one? I'm
wary of adding and upstreaming a new binding here, as the next option
would be to rename this to CFG_SYS_FLASH_AUTOPROTECT_LIST and continue
to #define it.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] scripts: config_whitelist: CONFIG_SYS_FLASH_AUTOPROTECT_LIST
On Sun, 4 Sept 2022 at 18:23, Tom Rini wrote:
> > > > > What type must it be in Kconfig? Note, it is an array initializer
> > > > > similar to CONFIG_SYS_BAUDRATE_TABLE.
> > > >
> > > > Ah, ugh. So, it's also currently unused code, what does it look like in
> > > > the platform you're making use of this on?
> > >
> > > In my _defconfig I use this line:
> > > CONFIG_SYS_FLASH_AUTOPROTECT_LIST="{{0x8000, 0x4}}"
> > > To protect the first 256 KB of flash memory.
> >
> > Please, disregard the previous message. I was too hasty to reply.
> >
> > I have include/configs/myplatform.h file which contains this line:
> > #define CONFIG_SYS_FLASH_AUTOPROTECT_LIST {{0x8000, 0x4}}
> >
> > And I could not convert it to Kconfig string parameter.
>
> Can this information be obtained from an existing device tree binding on
> the platform?
Device tree exists. No, DT does not currently contain this
information. But it can be added.
Re: [PATCH] scripts: config_whitelist: CONFIG_SYS_FLASH_AUTOPROTECT_LIST
On Sun, Sep 04, 2022 at 12:26:04PM +0300, Sergei Antonov wrote:
> On Sun, 4 Sept 2022 at 12:23, Sergei Antonov wrote:
> >
> > On Sat, 3 Sept 2022 at 19:16, Tom Rini wrote:
> > >
> > > On Sat, Sep 03, 2022 at 05:49:50PM +0300, Sergei Antonov wrote:
> > > > On Sat, 3 Sept 2022 at 17:31, Tom Rini wrote:
> > > > >
> > > > > On Sat, Sep 03, 2022 at 05:30:30PM +0300, Sergei Antonov wrote:
> > > > >
> > > > > > CONFIG_SYS_FLASH_AUTOPROTECT_LIST is a feature of
> > > > > > drivers/mtd/cfi_flash.c
> > > > > > driver. It allows to specify a range of protected eraseblocks on
> > > > > > flash memory.
> > > > > >
> > > > > > Fixes build error:
> > > > > > Error: You must add new CONFIG options using Kconfig
> > > > > > The following new ad-hoc CONFIG options were detected:
> > > > > > CONFIG_SYS_FLASH_AUTOPROTECT_LIST
> > > > > >
> > > > > > Signed-off-by: Sergei Antonov
> > > > > > ---
> > > > > > scripts/config_whitelist.txt | 1 +
> > > > > > 1 file changed, 1 insertion(+)
> > > > >
> > > > > Please move this to Kconfig so that it can be enabled, thanks.
> > > >
> > > > What type must it be in Kconfig? Note, it is an array initializer
> > > > similar to CONFIG_SYS_BAUDRATE_TABLE.
> > >
> > > Ah, ugh. So, it's also currently unused code, what does it look like in
> > > the platform you're making use of this on?
> >
> > In my _defconfig I use this line:
> > CONFIG_SYS_FLASH_AUTOPROTECT_LIST="{{0x8000, 0x4}}"
> > To protect the first 256 KB of flash memory.
>
> Please, disregard the previous message. I was too hasty to reply.
>
> I have include/configs/myplatform.h file which contains this line:
> #define CONFIG_SYS_FLASH_AUTOPROTECT_LIST {{0x8000, 0x4}}
>
> And I could not convert it to Kconfig string parameter.
Can this information be obtained from an existing device tree binding on
the platform?
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 09/12] rockchip: puma-rk3399: migrate to TPL
Hi Quentin,
I got below error when apply this patch, please rebase this patch set.
Applying: rockchip: puma-rk3399: migrate to TPL
error: sha1 information is lacking or useless
(configs/puma-rk3399_defconfig).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch' to see the failed patch
Patch failed at 0009 rockchip: puma-rk3399: migrate to TPL
Thanks,
- Kever
On 2022/7/23 00:06, Quentin Schulz wrote:
From: Quentin Schulz
Depending on the toolchain used to compile the SPL for Puma RK3399-Q7
module, the board does not boot because the resulting binary is too big
to fit in SRAM.
Let's add a TPL so that there's no need to fiddle with or hack the
defconfig to have a working bootloader.
This follows what's been done for the majority of other RK3399-based
boards.
See the original commit for the first migrations:
bdc00080111f "rockchip: rk3399: update defconfig for TPL"
Unfortunately, the offset in SPI-NOR for U-Boot proper needs to be
modified, since the move from SPL to TPL+SPL for idbloader.img (and the
"only the first 2KB per 4KB blocks are written" "hack" for rkspi format)
increased the size above 256KB. Let's move it to 512KB to, hopefully, be
safe.
Cc: Quentin Schulz
Signed-off-by: Quentin Schulz
---
arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi | 2 +-
board/theobroma-systems/puma_rk3399/README | 8
configs/puma-rk3399_defconfig | 4 ++--
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
index 5dc345bbe8..27a792fe6d 100644
--- a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
@@ -14,7 +14,7 @@
/ {
config {
- u-boot,spl-payload-offset = <0x4>; /* @ 256KB */
+ u-boot,spl-payload-offset = <0x8>; /* @ 512KB */
u-boot,mmc-env-offset = <0x4000>; /* @ 16KB */
u-boot,efi-partition-entries-offset = <0x20>; /* 2MB */
u-boot,boot-led = "module_led";
diff --git a/board/theobroma-systems/puma_rk3399/README
b/board/theobroma-systems/puma_rk3399/README
index 254c3bbe96..550bdfb1f4 100644
--- a/board/theobroma-systems/puma_rk3399/README
+++ b/board/theobroma-systems/puma_rk3399/README
@@ -51,13 +51,13 @@ The SPL image for SD-Card/eMMC is readily available in
idbloader.img at the
root of U-Boot after compilation.
Creating an SPL image for SPI-NOR:
- > tools/mkimage -n rk3399 -T rkspi -d spl/u-boot-spl.bin idbloader-spi.img
+ > tools/mkimage -n rk3399 -T rkspi -d tpl/u-boot-tpl.bin:spl/u-boot-spl.bin
idbloader-spi.img
Flash the image
===
-Copy the SPL to offset 32k for SD/eMMC, offset 0 for NOR-Flash and the FIT
-image to offset 256k.
+Copy the SPL to offset 32k and the FIT image to offset 256k for SD/eMMC.
+Copy the SPL to offset 0 and the FIT image to offset 512k for NOR-Flash.
SD-Card
---
@@ -98,4 +98,4 @@ help of the Rockchip loader binary.
> ./rkdeveloptool db rkbin/rk3399_loader_spinor_v1.25.114.bin
> ./rkdeveloptool ef
> ./rkdeveloptool wl 0 ../idbloader-spi.img
- > ./rkdeveloptool wl 512 ../u-boot.itb
+ > ./rkdeveloptool wl 1024 ../u-boot.itb
diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
index 3567cd078b..c70dbe9ed5 100644
--- a/configs/puma-rk3399_defconfig
+++ b/configs/puma-rk3399_defconfig
@@ -7,7 +7,6 @@ CONFIG_SPL_GPIO=y
CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_OFFSET=0x3F8000
CONFIG_DEFAULT_DEVICE_TREE="rk3399-puma-haikou"
-CONFIG_SPL_TEXT_BASE=0xff8c2000
CONFIG_ROCKCHIP_RK3399=y
CONFIG_ROCKCHIP_BOOT_MODE_REG=0x0
CONFIG_TARGET_PUMA_RK3399=y
@@ -22,11 +21,12 @@ CONFIG_DISPLAY_BOARDINFO_LATE=y
CONFIG_MISC_INIT_R=y
# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
CONFIG_SPL_STACK_R=y
-CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x200
CONFIG_SPL_I2C=y
CONFIG_SPL_POWER=y
CONFIG_SPL_SPI_LOAD=y
+CONFIG_TPL=y
CONFIG_CMD_BOOTZ=y
CONFIG_CMD_GPT=y
CONFIG_CMD_I2C=y
Re: [PATCH 07/12] rockchip: puma-rk3399: load environment from same medium as one used to load U-Boot proper
Hi Quentin,
The Kconfig from env/Kconfig
config ENV_IS_NOWHERE
bool "Environment is not stored"
default y if !ENV_IS_IN_EEPROM && !ENV_IS_IN_EXT4 && \
!ENV_IS_IN_FAT && !ENV_IS_IN_FLASH && \
!ENV_IS_IN_MMC && !ENV_IS_IN_NAND && \
!ENV_IS_IN_NVRAM && !ENV_IS_IN_ONENAND && \
!ENV_IS_IN_REMOTE && !ENV_IS_IN_SPI_FLASH && \
!ENV_IS_IN_UBI
I think the logic is the env parameter is stored on some kind of
storage, or NOWHERE.
And what you want to do is to load from the same medium as SPL boot
device(location of U-Boot proper),
this could not be NOWHERE.
Thanks,
- Kever
On 2022/9/1 21:13, Quentin Schulz wrote:
Hi Kever
On 9/1/22 15:03, Kever Yang wrote:
Hi Quentin,
On 2022/7/23 00:06, Quentin Schulz wrote:
From: Quentin Schulz
Chances are when one boots U-Boot proper from a given storage medium,
they want the same medium to be used to load and store the environment.
This basically allows to have completely separate U-Boot
(TPL/SPL/U-Boot
proper/environment) per storage medium which is convenient when working
with recovery from SD-Card as one would just need to insert a properly
configured SD-Card into the device to have access to their whole debug
setup.
No fallback mechanism is provided as to not dirty other storage medium
environment by mistake. However, since arch_env_get_location() is
called
by env_init() which is part of the pre-relocation process, a valid,
non-ENVL_UNKNOWN, value shall be returned otherwise the relocation
fails
with the following message:
initcall sequence 002866c0 failed at call 00256b34
(err=-19)
This valid, non-ENVL_UNKNOWN, value is ENVL_NOWHERE which requires to
always select CONFIG_ENV_IS_NOWHERE otherwise this work-around does not
work.
Cc: Quentin Schulz
Signed-off-by: Quentin Schulz
---
Depends on
https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_u-2Dboot_20220715151552.953654-2D1-2Dfoss-2Buboot-400leil.net_=DwIDaQ=_sEr5x9kUWhuk4_nFwjJtA=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t=TZndtGz1ePTd2Il6YcEjqzo9oXv73RCWHIRVSiFVsnp2OzyCJEDzZ2KPz56AcWdn=wgEMbr3EjeCtvcWU_UoXqNOwQulaVN-0Qb2yL2ysaOs=
https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_u-2Dboot_20220715151552.953654-2D2-2Dfoss-2Buboot-400leil.net_=DwIDaQ=_sEr5x9kUWhuk4_nFwjJtA=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t=TZndtGz1ePTd2Il6YcEjqzo9oXv73RCWHIRVSiFVsnp2OzyCJEDzZ2KPz56AcWdn=PKwYBMB7r8ekIPV1ZG7xkj7vF60YNFlYXQRrvaVgJR8=
.../puma_rk3399/puma-rk3399.c | 37
+++
configs/puma-rk3399_defconfig | 1 +
2 files changed, 38 insertions(+)
diff --git a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
index 5e5e58c88e..7ef4bac24b 100644
--- a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
+++ b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -135,6 +136,42 @@ int mmc_get_env_dev(void)
return CONFIG_SYS_MMC_ENV_DEV;
}
+#if !IS_ENABLED(CONFIG_ENV_IS_NOWHERE)
+#error Please enable CONFIG_ENV_IS_NOWHERE
+#endif
+
+enum env_location arch_env_get_location(enum env_operation op, int
prio)
+{
+ const char *boot_device =
+ ofnode_read_chosen_string("u-boot,spl-boot-device");
+
+ if (prio > 0)
+ return ENVL_UNKNOWN;
+
+ if (!boot_device) {
+ debug("%s: /chosen/u-boot,spl-boot-device not set\n",
+ __func__);
+ return ENVL_NOWHERE;
+ }
+
+ debug("%s: booted from %s\n", __func__, boot_device);
+
+ if (IS_ENABLED(CONFIG_ENV_IS_IN_SPI_FLASH) &&
+ !strcmp(boot_device, "/spi@ff1d/flash@0"))
+ return ENVL_SPI_FLASH;
+
+ if (IS_ENABLED(CONFIG_ENV_IS_IN_MMC) &&
+ (!strcmp(boot_device, "/mmc@fe32") ||
+ !strcmp(boot_device, "/mmc@fe33")))
+ return ENVL_MMC;
+
+ printf("%s: No environment available: booted from %s but U-Boot "
+ "config does not allow loading environment from it.",
+ __func__, boot_device);
+
+ return ENVL_NOWHERE;
+}
+
int misc_init_r(void)
{
const u32 cpuid_offset = 0x7;
diff --git a/configs/puma-rk3399_defconfig
b/configs/puma-rk3399_defconfig
index 87d7e4f57c..e218532d70 100644
--- a/configs/puma-rk3399_defconfig
+++ b/configs/puma-rk3399_defconfig
@@ -44,6 +44,7 @@ CONFIG_SPL_OF_CONTROL=y
CONFIG_OF_LIVE=y
CONFIG_OF_SPL_REMOVE_PROPS="interrupt-parent assigned-clocks
assigned-clock-rates assigned-clock-parents"
CONFIG_ENV_OVERWRITE=y
+CONFIG_ENV_IS_NOWHERE=y
This option is conflict with CONFIG_ENV_IS_IN_MMC, please check
again where should be this board get the env.
I created the defconfig with make savedefconfig, so if you're talking
about KConfig conflict, that is incorrect, there is no conflict.
Re: [PATCH 01/12] rockchip: puma-rk3399: fix boot_targets swap depending on U-Boot proper load medium
On 2022/7/23 00:06, Quentin Schulz wrote:
From: Quentin Schulz
distroboot should try first on the same MMC medium as the one the SPL
loaded U-Boot proper from. This was the case when the introducing commit
was merged because the default order was eMMC first and then SD card.
The check was therefore made only on whether we booted from SD card,
because otherwise the order was the expected one.
However, in commit b212ad24a604 ("rockchip: Fix MMC boot order"), the
order was swapped. Meaning our simple check is now useless.
Let's fix that by accounting for all scenarii: default boot_targets has
mmc0 first but booting from SD Card, mmc1 first but booting from eMMC.
Fixes: b212ad24a604 ("rockchip: Fix MMC boot order")
Cc: Quentin Schulz
Signed-off-by: Quentin Schulz
I will apply this first, but it will be better to use boot script, too
many logic to get the correct boot dev with this.
Reviewed-by: Kever Yang
Thanks,
- Kever
---
Depends on
https://lore.kernel.org/u-boot/20220715151552.953654-1-foss+ub...@0leil.net/
https://lore.kernel.org/u-boot/20220715151552.953654-2-foss+ub...@0leil.net/
.../puma_rk3399/puma-rk3399.c | 25 ++-
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
index deeba3084a..ce3436b770 100644
--- a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
+++ b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
@@ -77,18 +77,16 @@ static int setup_boottargets(void)
}
/*
-* Only run, if booting from mmc1 (i.e. /mmc@fe32) and
-* only consider cases where the default boot-order first
-* tries to boot from mmc0 (eMMC) and then from mmc1
-* (i.e. external SD).
-*
-* In other words: the SD card will be moved to earlier in the
-* order, if U-Boot was also loaded from the SD-card.
+* Make the default boot medium between SD Card and eMMC, the one that
+* was used to load U-Boot proper. If SPI-NOR flash was used, keep
+* original default order.
*/
- if (!strcmp(boot_device, "/mmc@fe32")) {
+ if (strcmp(boot_device, "/spi@ff1d/flash@0")) {
+ bool sd_booted = !strcmp(boot_device, "/mmc@fe32");
char *mmc0, *mmc1;
- debug("%s: booted from SD-Card\n", __func__);
+ debug("%s: booted from %s\n", __func__,
+ sd_booted ? "SD-Card" : "eMMC");
mmc0 = strstr(env, "mmc0");
mmc1 = strstr(env, "mmc1");
@@ -98,10 +96,13 @@ static int setup_boottargets(void)
}
/*
-* If mmc0 comes first in the boot order, we need to change
-* the strings to make mmc1 first.
+* If mmc0 comes first in the boot order and U-Boot proper was
+* loaded from mmc1, swap mmc0 and mmc1 in the list.
+* If mmc1 comes first in the boot order and U-Boot proper was
+* loaded from mmc0, swap mmc0 and mmc1 in the list.
*/
- if (mmc0 < mmc1) {
+ if ((mmc0 < mmc1 && sd_booted) ||
+ (mmc0 > mmc1 && !sd_booted)) {
mmc0[3] = '1';
mmc1[3] = '0';
debug("%s: set boot_targets to: %s\n", __func__, env);
Re: [PATCH] clk: rockchip: rk3399: Fix Unknown clock 77 on mmc@fe310000
On 2022/8/21 15:17, Michal Suchanek wrote:
Adding some debug prints I can see:
MMC: mmc@fe32: Got clock clock-controller@ff76 76
mmc@fe31: Got clock clock-controller@ff76 77
Unknown clock 77
rockchip_dwmmc_get_mmc_clk: err=-2
mmc@fe31: 3, mmc@fe32: 1, mmc@fe33: 0
According to kernel code the SDIO clock is identical to SDMMC clock
except for the con 16->15 change.
Add support for the clock to avoid the error.
Signed-off-by: Michal Suchanek
This does not affect any function in U-Boot because we do not use this
SDIO in U-Boot.
Reviewed-by: Kever Yang
Thanks,
- Kever
---
drivers/clk/rockchip/clk_rk3399.c | 66 ---
1 file changed, 43 insertions(+), 23 deletions(-)
diff --git a/drivers/clk/rockchip/clk_rk3399.c
b/drivers/clk/rockchip/clk_rk3399.c
index 7d31a9f22a..97bf1c6e15 100644
--- a/drivers/clk/rockchip/clk_rk3399.c
+++ b/drivers/clk/rockchip/clk_rk3399.c
@@ -728,6 +728,12 @@ static ulong rk3399_mmc_get_clk(struct rockchip_cru *cru,
uint clk_id)
u32 div, con;
switch (clk_id) {
+ case HCLK_SDIO:
+ case SCLK_SDIO:
+ con = readl(>clksel_con[15]);
+ /* dwmmc controller have internal div 2 */
+ div = 2;
+ break;
case HCLK_SDMMC:
case SCLK_SDMMC:
con = readl(>clksel_con[16]);
@@ -750,37 +756,46 @@ static ulong rk3399_mmc_get_clk(struct rockchip_cru *cru,
uint clk_id)
return DIV_TO_RATE(GPLL_HZ, div);
}
+static void rk3399_dwmmc_set_clk(struct rockchip_cru *cru,
+unsigned int con, ulong set_rate)
+{
+ /* Select clk_sdmmc source from GPLL by default */
+ /* mmc clock defaulg div 2 internal, provide double in cru */
+ int src_clk_div = DIV_ROUND_UP(GPLL_HZ / 2, set_rate);
+
+ if (src_clk_div > 128) {
+ /* use 24MHz source for 400KHz clock */
+ src_clk_div = DIV_ROUND_UP(OSC_HZ / 2, set_rate);
+ assert(src_clk_div - 1 < 128);
+ rk_clrsetreg(>clksel_con[con],
+CLK_EMMC_PLL_MASK | CLK_EMMC_DIV_CON_MASK,
+CLK_EMMC_PLL_SEL_24M << CLK_EMMC_PLL_SHIFT |
+(src_clk_div - 1) << CLK_EMMC_DIV_CON_SHIFT);
+ } else {
+ rk_clrsetreg(>clksel_con[con],
+CLK_EMMC_PLL_MASK | CLK_EMMC_DIV_CON_MASK,
+CLK_EMMC_PLL_SEL_GPLL << CLK_EMMC_PLL_SHIFT |
+(src_clk_div - 1) << CLK_EMMC_DIV_CON_SHIFT);
+ }
+}
+
static ulong rk3399_mmc_set_clk(struct rockchip_cru *cru,
ulong clk_id, ulong set_rate)
{
- int src_clk_div;
- int aclk_emmc = 198 * MHz;
-
switch (clk_id) {
+ case HCLK_SDIO:
+ case SCLK_SDIO:
+ rk3399_dwmmc_set_clk(cru, 15, set_rate);
+ break;
case HCLK_SDMMC:
case SCLK_SDMMC:
- /* Select clk_sdmmc source from GPLL by default */
- /* mmc clock defaulg div 2 internal, provide double in cru */
- src_clk_div = DIV_ROUND_UP(GPLL_HZ / 2, set_rate);
-
- if (src_clk_div > 128) {
- /* use 24MHz source for 400KHz clock */
- src_clk_div = DIV_ROUND_UP(OSC_HZ / 2, set_rate);
- assert(src_clk_div - 1 < 128);
- rk_clrsetreg(>clksel_con[16],
-CLK_EMMC_PLL_MASK | CLK_EMMC_DIV_CON_MASK,
-CLK_EMMC_PLL_SEL_24M << CLK_EMMC_PLL_SHIFT
|
-(src_clk_div - 1) <<
CLK_EMMC_DIV_CON_SHIFT);
- } else {
- rk_clrsetreg(>clksel_con[16],
-CLK_EMMC_PLL_MASK | CLK_EMMC_DIV_CON_MASK,
-CLK_EMMC_PLL_SEL_GPLL <<
CLK_EMMC_PLL_SHIFT |
-(src_clk_div - 1) <<
CLK_EMMC_DIV_CON_SHIFT);
- }
+ rk3399_dwmmc_set_clk(cru, 16, set_rate);
break;
- case SCLK_EMMC:
+ case SCLK_EMMC: {
+ int aclk_emmc = 198 * MHz;
/* Select aclk_emmc source from GPLL */
- src_clk_div = DIV_ROUND_UP(GPLL_HZ, aclk_emmc);
+ int src_clk_div = DIV_ROUND_UP(GPLL_HZ, aclk_emmc);
+
assert(src_clk_div - 1 < 32);
rk_clrsetreg(>clksel_con[21],
@@ -797,6 +812,7 @@ static ulong rk3399_mmc_set_clk(struct rockchip_cru *cru,
CLK_EMMC_PLL_SEL_GPLL << CLK_EMMC_PLL_SHIFT |
(src_clk_div - 1) << CLK_EMMC_DIV_CON_SHIFT);
break;
+ }
default:
return -EINVAL;
}
@@ -918,6 +934,8 @@ static ulong rk3399_clk_get_rate(struct clk *clk)
switch (clk->id) {
case 0
Re: [PATCH v2 09/11] arm: dts: rockchip: sync rk3066/rk3188 DT files from Linux
Hi Kever,
Despite you marked this serie as "Rejected" this patch contains a normal sync
from Linux and therefore can be applied independently.
Could you a have a look at it again?
Kind regards,
Johan Jonker
On 7/9/22 20:50, Johan Jonker wrote:
> Sync rk3066/rk3188 DT files from Linux.
> This is the state as of v5.18 in Linux +
> nfc node for MK808 rk3066a.
> CRU nodes now have a clock property.
> To prefend dtoc errors a fixed clock must also be
> included for tpl/spl in the rk3xxx-u-boot.dtsi file.
>
> Signed-off-by: Johan Jonker
> ---
> arch/arm/dts/rk3066a-mk808.dts| 18 ++
> arch/arm/dts/rk3066a.dtsi | 3 ++-
> arch/arm/dts/rk3188-radxarock.dts | 3 +--
> arch/arm/dts/rk3188.dtsi | 24 +++-
> arch/arm/dts/rk3xxx-u-boot.dtsi | 4
> 5 files changed, 40 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/dts/rk3066a-mk808.dts b/arch/arm/dts/rk3066a-mk808.dts
> index 667d57a4..cfa318a5 100644
> --- a/arch/arm/dts/rk3066a-mk808.dts
> +++ b/arch/arm/dts/rk3066a-mk808.dts
> @@ -160,6 +160,24 @@
> status = "okay";
> };
>
> + {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +
> + nand@0 {
> + reg = <0>;
> + label = "rk-nand";
> + nand-bus-width = <8>;
> + nand-ecc-mode = "hw";
> + nand-ecc-step-size = <1024>;
> + nand-ecc-strength = <40>;
> + nand-is-boot-medium;
> + rockchip,boot-blks = <8>;
> + rockchip,boot-ecc-strength = <24>;
> + };
> +};
> +
> {
> usb-host {
> host_drv: host-drv {
> diff --git a/arch/arm/dts/rk3066a.dtsi b/arch/arm/dts/rk3066a.dtsi
> index c25b9695..de9915d9 100644
> --- a/arch/arm/dts/rk3066a.dtsi
> +++ b/arch/arm/dts/rk3066a.dtsi
> @@ -202,8 +202,9 @@
> cru: clock-controller@2000 {
> compatible = "rockchip,rk3066a-cru";
> reg = <0x2000 0x1000>;
> + clocks = <>;
> + clock-names = "xin24m";
> rockchip,grf = <>;
> -
> #clock-cells = <1>;
> #reset-cells = <1>;
> assigned-clocks = < PLL_CPLL>, < PLL_GPLL>,
> diff --git a/arch/arm/dts/rk3188-radxarock.dts
> b/arch/arm/dts/rk3188-radxarock.dts
> index e7138a4a..a9ed3cd2 100644
> --- a/arch/arm/dts/rk3188-radxarock.dts
> +++ b/arch/arm/dts/rk3188-radxarock.dts
> @@ -6,7 +6,6 @@
> /dts-v1/;
> #include
> #include "rk3188.dtsi"
> -#include "rk3188-radxarock-u-boot.dtsi"
>
> / {
> model = "Radxa Rock";
> @@ -25,7 +24,7 @@
> compatible = "gpio-keys";
> autorepeat;
>
> - power {
> + key-power {
> gpios = < RK_PA4 GPIO_ACTIVE_LOW>;
> linux,code = ;
> label = "GPIO Key Power";
> diff --git a/arch/arm/dts/rk3188.dtsi b/arch/arm/dts/rk3188.dtsi
> index 9a80f83a..cdd4a0bd 100644
> --- a/arch/arm/dts/rk3188.dtsi
> +++ b/arch/arm/dts/rk3188.dtsi
> @@ -54,7 +54,7 @@
> };
> };
>
> - cpu0_opp_table: opp_table0 {
> + cpu0_opp_table: opp-table-0 {
> compatible = "operating-points-v2";
> opp-shared;
>
> @@ -195,8 +195,9 @@
> cru: clock-controller@2000 {
> compatible = "rockchip,rk3188-cru";
> reg = <0x2000 0x1000>;
> + clocks = <>;
> + clock-names = "xin24m";
> rockchip,grf = <>;
> -
> #clock-cells = <1>;
> #reset-cells = <1>;
> };
> @@ -223,7 +224,7 @@
> #size-cells = <1>;
> ranges;
>
> - gpio0: gpio0@2000a000 {
> + gpio0: gpio@2000a000 {
> compatible = "rockchip,rk3188-gpio-bank0";
> reg = <0x2000a000 0x100>;
> interrupts = ;
> @@ -236,7 +237,7 @@
> #interrupt-cells = <2>;
> };
>
> - gpio1: gpio1@2003c000 {
> + gpio1: gpio@2003c000 {
> compatible = "rockchip,gpio-bank";
> reg = <0x2003c000 0x100>;
> interrupts = ;
> @@ -249,7 +250,7 @@
> #interrupt-cells = <2>;
> };
>
> - gpio2: gpio2@2003e000 {
> + gpio2: gpio@2003e000 {
> compatible = "rockchip,gpio-bank";
> reg = <0x2003e000 0x100>;
> interrupts = ;
> @@ -262,7 +263,7 @@
> #interrupt-cells = <2>;
> };
>
> - gpio3: gpio3@2008 {
> + gpio3: gpio@2008 {
> compatible = "rockchip,gpio-bank";
> reg = <0x2008 0x100>;
> interrupts = ;
> @@ -275,15 +276,15 @@
> #interrupt-cells = <2>;
> };
>
Re: [PATCH v2] gpio: ftgpio010: Add support for Faraday Technology FTGPIO010
On Sunday 04 September 2022 13:22:00 Sergei Antonov wrote: > Add Faraday Technology's FTGPIO010 controller driver. > > Signed-off-by: Sergei Antonov > --- > v1 -> v2: > Replace setbits_le32() with a simpler function out_le32(). > Replace readl() with in_le32() to respect endianness. > > drivers/gpio/Kconfig | 6 +++ > drivers/gpio/Makefile| 1 + > drivers/gpio/ftgpio010.c | 100 +++ > 3 files changed, 107 insertions(+) > create mode 100644 drivers/gpio/ftgpio010.c Hello! I'm really not maintainer of ftgpio010.c driver, nor of gpio. So please do not send me emails about ftgpio010.c if you do not have really good reason. I'm getting tons of unrelated emails, so please do not spam me otherwise I would not be able to filter out those emails which are important and which I should review as maintainer.
[PATCH v2] gpio: ftgpio010: Add support for Faraday Technology FTGPIO010
Add Faraday Technology's FTGPIO010 controller driver.
Signed-off-by: Sergei Antonov
---
v1 -> v2:
Replace setbits_le32() with a simpler function out_le32().
Replace readl() with in_le32() to respect endianness.
drivers/gpio/Kconfig | 6 +++
drivers/gpio/Makefile| 1 +
drivers/gpio/ftgpio010.c | 100 +++
3 files changed, 107 insertions(+)
create mode 100644 drivers/gpio/ftgpio010.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index c949f9d2f7cc..2a60478b476a 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -605,4 +605,10 @@ config TURRIS_OMNIA_MCU
help
Support for GPIOs on MCU connected to Turris Omnia via i2c.
+config FTGPIO010
+ bool "Faraday Technology FTGPIO010 driver"
+ depends on DM_GPIO
+ help
+ Support for GPIOs on Faraday Technology's FTGPIO010 controller.
+
endif
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 9d718a554e59..eee7908871d8 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -75,3 +75,4 @@ obj-$(CONFIG_SL28CPLD_GPIO) += sl28cpld-gpio.o
obj-$(CONFIG_ZYNQMP_GPIO_MODEPIN) += zynqmp_gpio_modepin.o
obj-$(CONFIG_SLG7XL45106_I2C_GPO) += gpio_slg7xl45106.o
obj-$(CONFIG_$(SPL_TPL_)TURRIS_OMNIA_MCU) += turris_omnia_mcu.o
+obj-$(CONFIG_FTGPIO010)+= ftgpio010.o
diff --git a/drivers/gpio/ftgpio010.c b/drivers/gpio/ftgpio010.c
new file mode 100644
index ..fa6b180963d3
--- /dev/null
+++ b/drivers/gpio/ftgpio010.c
@@ -0,0 +1,100 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Faraday Technology's FTGPIO010 controller.
+ */
+
+#include
+#include
+#include
+#include
+
+struct ftgpio010_regs {
+ u32 out;
+ u32 in;
+ u32 direction;
+ u32 reserved;
+ u32 set;
+ u32 clear;
+};
+
+struct ftgpio010_plat {
+ struct ftgpio010_regs __iomem *regs;
+};
+
+static int ftgpio010_direction_input(struct udevice *dev, unsigned int pin)
+{
+ struct ftgpio010_plat *plat = dev_get_plat(dev);
+ struct ftgpio010_regs *const regs = plat->regs;
+
+ clrbits_le32(>direction, 1 << pin);
+ return 0;
+}
+
+static int ftgpio010_direction_output(struct udevice *dev, unsigned int pin,
+ int val)
+{
+ struct ftgpio010_plat *plat = dev_get_plat(dev);
+ struct ftgpio010_regs *const regs = plat->regs;
+
+ /* change the data first, then the direction. to avoid glitch */
+ out_le32(val ? >set : >clear, 1 << pin);
+ setbits_le32(>direction, 1 << pin);
+
+ return 0;
+}
+
+static int ftgpio010_get_value(struct udevice *dev, unsigned int pin)
+{
+ struct ftgpio010_plat *plat = dev_get_plat(dev);
+ struct ftgpio010_regs *const regs = plat->regs;
+
+ return in_le32(>in) >> pin & 1;
+}
+
+static int ftgpio010_set_value(struct udevice *dev, unsigned int pin, int val)
+{
+ struct ftgpio010_plat *plat = dev_get_plat(dev);
+ struct ftgpio010_regs *const regs = plat->regs;
+
+ out_le32(val ? >set : >clear, 1 << pin);
+ return 0;
+}
+
+static int ftgpio010_probe(struct udevice *dev)
+{
+ struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+
+ uc_priv->gpio_count = ofnode_read_u32_default(dev_ofnode(dev),
+ "nr-gpios", 32);
+ return 0;
+}
+
+static int ftgpio010_of_to_plat(struct udevice *dev)
+{
+ struct ftgpio010_plat *plat = dev_get_plat(dev);
+
+ plat->regs = dev_read_addr_ptr(dev);
+ return 0;
+}
+
+static const struct dm_gpio_ops ftgpio010_ops = {
+ .direction_input= ftgpio010_direction_input,
+ .direction_output = ftgpio010_direction_output,
+ .get_value = ftgpio010_get_value,
+ .set_value = ftgpio010_set_value,
+};
+
+static const struct udevice_id ftgpio010_ids[] = {
+ { .compatible = "faraday,ftgpio010" },
+ { }
+};
+
+U_BOOT_DRIVER(ftgpio010) = {
+ .name = "ftgpio010",
+ .id = UCLASS_GPIO,
+ .of_match = ftgpio010_ids,
+ .ops= _ops,
+ .of_to_plat = ftgpio010_of_to_plat,
+ .plat_auto = sizeof(struct ftgpio010_plat),
+ .probe = ftgpio010_probe,
+};
--
2.34.1
[PATCH v1] arm: dts: rockchip: move all rk3128 u-boot specific properties in separate dtsi files
Move all rk3128 u-boot specific properties in separate dtsi files.
Sort emmc node.
Signed-off-by: Johan Jonker
---
arch/arm/dts/rk3128-evb-u-boot.dtsi | 7 +++
arch/arm/dts/rk3128-evb.dts | 10 +-
arch/arm/dts/rk3128-u-boot.dtsi | 27 +++
arch/arm/dts/rk3128.dtsi| 11 ---
4 files changed, 39 insertions(+), 16 deletions(-)
create mode 100644 arch/arm/dts/rk3128-evb-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3128-u-boot.dtsi
diff --git a/arch/arm/dts/rk3128-evb-u-boot.dtsi
b/arch/arm/dts/rk3128-evb-u-boot.dtsi
new file mode 100644
index ..8b16bbe4
--- /dev/null
+++ b/arch/arm/dts/rk3128-evb-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include "rk3128-u-boot.dtsi"
+
+ {
+ u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/rk3128-evb.dts b/arch/arm/dts/rk3128-evb.dts
index a407ac2d..e7d8f7c9 100644
--- a/arch/arm/dts/rk3128-evb.dts
+++ b/arch/arm/dts/rk3128-evb.dts
@@ -37,6 +37,11 @@
};
};
+ {
+ fifo-mode;
+ status = "okay";
+};
+
{
status = "okay";
@@ -74,11 +79,6 @@
status = "okay";
};
- {
- fifo-mode;
- status = "okay";
-};
-
{
usb_otg {
otg_vbus_drv: host-vbus-drv {
diff --git a/arch/arm/dts/rk3128-u-boot.dtsi b/arch/arm/dts/rk3128-u-boot.dtsi
new file mode 100644
index ..dbb41fe1
--- /dev/null
+++ b/arch/arm/dts/rk3128-u-boot.dtsi
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include "rockchip-u-boot.dtsi"
+
+/ {
+ dmc: dmc@20004000 {
+ compatible = "rockchip,rk3128-dmc", "syscon";
+ reg = <0x0 0x20004000 0x0 0x1000>;
+ u-boot,dm-pre-reloc;
+ };
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ max-frequency = <15000>;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ max-frequency = <15000>;
+};
diff --git a/arch/arm/dts/rk3128.dtsi b/arch/arm/dts/rk3128.dtsi
index 62fd5343..589818da 100644
--- a/arch/arm/dts/rk3128.dtsi
+++ b/arch/arm/dts/rk3128.dtsi
@@ -237,14 +237,7 @@
clock-names = "clk_nandc", "g_clk_nandc", "hclk_nandc";
};
- dmc: dmc@20004000 {
- u-boot,dm-pre-reloc;
- compatible = "rockchip,rk3128-dmc", "syscon";
- reg = <0x0 0x20004000 0x0 0x1000>;
- };
-
cru: clock-controller@2000 {
- u-boot,dm-pre-reloc;
compatible = "rockchip,rk3128-cru";
reg = <0x2000 0x1000>;
rockchip,grf = <>;
@@ -440,7 +433,6 @@
sdmmc: dwmmc@10214000 {
compatible = "rockchip,rk312x-dw-mshc",
"rockchip,rk3288-dw-mshc";
reg = <0x10214000 0x4000>;
- max-frequency = <15000>;
interrupts = ;
clocks = < HCLK_SDMMC>, < SCLK_SDMMC>,
< SCLK_SDMMC_DRV>, < SCLK_SDMMC_SAMPLE>;
@@ -453,10 +445,8 @@
};
emmc: dwmmc@1021c000 {
- u-boot,dm-pre-reloc;
compatible = "rockchip,rk3128-dw-mshc",
"rockchip,rk3288-dw-mshc";
reg = <0x1021c000 0x4000>;
- max-frequency = <15000>;
interrupts = ;
clocks = < HCLK_EMMC>, < SCLK_EMMC>,
< SCLK_EMMC_DRV>, < SCLK_EMMC_SAMPLE>;
@@ -538,7 +528,6 @@
};
grf: syscon@20008000 {
- u-boot,dm-pre-reloc;
compatible = "rockchip,rk3128-grf", "syscon";
reg = <0x20008000 0x1000>;
};
--
2.20.1
Re: [PATCH v2 3/8] timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support
On Saturday 03 September 2022 19:36:03 Tony Dinh wrote: > Hi Pali, > > On Sat, Sep 3, 2022 at 6:08 PM Pali Rohár wrote: > > > > On Saturday 03 September 2022 17:38:01 Tony Dinh wrote: > > > Hi Pali, > > > > > > Is there a way to get the CPU frequency from the board upon start up? > > > > > > Thanks, > > > Tony > > > > Hello! Each SoC has either fixed CPU frequency or has some bits in SAR > > register which say on which frequency is CPU running. SAR bits are SoC > > specific and are documented either in Functional Specifications or in > > Hardware Specifications (both documents are available for free all > > 32-bit Marvell SoCs except 375 and 39x). > > Thanks for the recap. I do remember you posted a patch for that detection. > https://lists.denx.de/pipermail/u-boot/2022-August/492034.html > > Just want to make sure that the SAR register is the only way we can > detect it in u-boot. The Kirkwood 6192 SoC on this Pogo V4 board can > run at 200 Mhz and 800 Mhz with frequency scaling in Linux. > > Thanks, > Tony Well, All those SoCs have more clocks which are used for different peripherals. TCLK is something like base block and CPU is connected to different clock. Settings for it CPU clock is also in SAR register (different bits). And then there can be something like CPU scaling and cpufreq driver with configuration via different registers which can modify divisor of the main CPU clock. Which effectively can lower CPU speed. This cpufreq part is not implemented in U-Boot and IIRC CPU clock divisor should be at 1 = full CPU speed.
Re: [PATCH 0/9] Nokia RX-51: Small cleanups and UBI boot test case
On Saturday 03 September 2022 20:01:45 Tony Dinh wrote: > Hi Pali, > > On Sat, Sep 3, 2022 at 6:29 PM Pali Rohár wrote: > > > > Do various small fixup/cleanups and extend test script to boot kernel > > image from UBI volume. This test verifies that U-Boot UBI implementation > > is working and U-Boot can read volume with bootable kernel code > > correctly. And therefore CI prevents UBI breakage. > > > > Note that U-Boot UBIFS code on ARM is currently somehow broken and > > trying to mount UBIFS from UBI volume fails :-( I have already tried to > > debug this issue but I have no idea why it is failing. > > I've recently implemented UBI distro boot on a pair of Kirkwood boards > (Pogo V4 and NSA310s) successfully. I created the UBI partition and > formatted it in Debian 11.x, Linux kernel 5.19.x. I could let the > u-boot distro boot scan the UBI partition to find the boot script > boot.scr. And also mount it manually to look at the file system. Hello! I think you mean UBIFS on UBI, right? > An observation: I cannot mount OpenWrt rootfs in u-boot, since it is > an UBIFS volume overlay on squashfs. But creating my own UBIFS volume > allowed me to mount it in the u-boot command line. I think squashfs is > incomplete in u-boot, at the moment. UBIFS on squashfs? This looks strange. AFAIK UBIFS (also on linux) works only on UBI. I guess you could have squashfs on UBI, but on linux this requires mtdblock, hence it is squashfs on mtdblock on UBI. > Best, > Tony > > > > Function > > check_lpt_crc in unpack_ltab is failing. Volume is for sure correct and > > valid because Linux kernel can successfully mount it. And to make it > > more suspicious, U-Boot UBIFS is working fine on big endian powerpc > > platform. So UBIFS issue is probably endian or arch specific. > > (This is UBIFS related, not UBI related.) > > > > Pali Rohár (9): > > Nokia RX-51: Remove label copy_kernel_start from lowlevel_init.S > > Nokia RX-51: Do not clear unknown memory in lowlevel_init.S > > Nokia RX-51: Set default SYS_LOAD_ADDR to 0x80008000 > > Nokia RX-51: Change UBIFS volume size to 1870 LEBs in test script > > Nokia RX-51: Call bootm in test script only when image is valid > > Nokia RX-51: Fix documentation how to enable UBI support > > Nokia RX-51: Do not set useless ARCH= in test script > > Nokia RX-51: Add comment describing kernel image type into test script > > Nokia RX-51: Add booting from UBI into test script > > > > board/nokia/rx51/lowlevel_init.S | 7 +-- > > configs/nokia_rx51_defconfig | 2 +- > > doc/board/nokia/rx51.rst | 3 +- > > test/nokia_rx51_test.sh | 97 +--- > > 4 files changed, 82 insertions(+), 27 deletions(-) > > > > -- > > 2.20.1 > >
Re: [PATCH] scripts: config_whitelist: CONFIG_SYS_FLASH_AUTOPROTECT_LIST
On Sun, 4 Sept 2022 at 12:23, Sergei Antonov wrote:
>
> On Sat, 3 Sept 2022 at 19:16, Tom Rini wrote:
> >
> > On Sat, Sep 03, 2022 at 05:49:50PM +0300, Sergei Antonov wrote:
> > > On Sat, 3 Sept 2022 at 17:31, Tom Rini wrote:
> > > >
> > > > On Sat, Sep 03, 2022 at 05:30:30PM +0300, Sergei Antonov wrote:
> > > >
> > > > > CONFIG_SYS_FLASH_AUTOPROTECT_LIST is a feature of
> > > > > drivers/mtd/cfi_flash.c
> > > > > driver. It allows to specify a range of protected eraseblocks on
> > > > > flash memory.
> > > > >
> > > > > Fixes build error:
> > > > > Error: You must add new CONFIG options using Kconfig
> > > > > The following new ad-hoc CONFIG options were detected:
> > > > > CONFIG_SYS_FLASH_AUTOPROTECT_LIST
> > > > >
> > > > > Signed-off-by: Sergei Antonov
> > > > > ---
> > > > > scripts/config_whitelist.txt | 1 +
> > > > > 1 file changed, 1 insertion(+)
> > > >
> > > > Please move this to Kconfig so that it can be enabled, thanks.
> > >
> > > What type must it be in Kconfig? Note, it is an array initializer
> > > similar to CONFIG_SYS_BAUDRATE_TABLE.
> >
> > Ah, ugh. So, it's also currently unused code, what does it look like in
> > the platform you're making use of this on?
>
> In my _defconfig I use this line:
> CONFIG_SYS_FLASH_AUTOPROTECT_LIST="{{0x8000, 0x4}}"
> To protect the first 256 KB of flash memory.
Please, disregard the previous message. I was too hasty to reply.
I have include/configs/myplatform.h file which contains this line:
#define CONFIG_SYS_FLASH_AUTOPROTECT_LIST {{0x8000, 0x4}}
And I could not convert it to Kconfig string parameter.
Re: [PATCH] scripts: config_whitelist: CONFIG_SYS_FLASH_AUTOPROTECT_LIST
On Sat, 3 Sept 2022 at 19:16, Tom Rini wrote:
>
> On Sat, Sep 03, 2022 at 05:49:50PM +0300, Sergei Antonov wrote:
> > On Sat, 3 Sept 2022 at 17:31, Tom Rini wrote:
> > >
> > > On Sat, Sep 03, 2022 at 05:30:30PM +0300, Sergei Antonov wrote:
> > >
> > > > CONFIG_SYS_FLASH_AUTOPROTECT_LIST is a feature of
> > > > drivers/mtd/cfi_flash.c
> > > > driver. It allows to specify a range of protected eraseblocks on flash
> > > > memory.
> > > >
> > > > Fixes build error:
> > > > Error: You must add new CONFIG options using Kconfig
> > > > The following new ad-hoc CONFIG options were detected:
> > > > CONFIG_SYS_FLASH_AUTOPROTECT_LIST
> > > >
> > > > Signed-off-by: Sergei Antonov
> > > > ---
> > > > scripts/config_whitelist.txt | 1 +
> > > > 1 file changed, 1 insertion(+)
> > >
> > > Please move this to Kconfig so that it can be enabled, thanks.
> >
> > What type must it be in Kconfig? Note, it is an array initializer
> > similar to CONFIG_SYS_BAUDRATE_TABLE.
>
> Ah, ugh. So, it's also currently unused code, what does it look like in
> the platform you're making use of this on?
In my _defconfig I use this line:
CONFIG_SYS_FLASH_AUTOPROTECT_LIST="{{0x8000, 0x4}}"
To protect the first 256 KB of flash memory.
Re: [PATCH v15 10/10] test: unit test for eficonfig
On 9/2/22 16:23, Masahisa Kojima wrote:
Provide a unit test for the eficonfig command.
Signed-off-by: Masahisa Kojima
Acked-by: Ilias Apalodimas
---
No update since v15
Changes in v14:
- update to support media device enumeration in eficonfig startup
- move no block device test to the last test case
Changes in v12:
- update menu handling
Changes in v11:
- fix expected result when no BootOrder is defined
Newly added in v10
Your code does not pass the test, see
https://source.denx.de/u-boot/custodians/u-boot-efi/-/jobs/491449
test/py/tests/test_eficonfig/test_eficonfig.py:103: in test_efi_eficonfig
check_current_is_maintenance_menu()
test/py/tests/test_eficonfig/test_eficonfig.py:51: in
check_current_is_maintenance_menu
u_boot_console.p.expect([i])
test/py/u_boot_spawn.py:193: in expect
raise Timeout()
E u_boot_spawn.Timeout
Best regards
Heinrich
configs/sandbox_defconfig | 1 +
test/py/tests/test_eficonfig/conftest.py | 40 ++
.../py/tests/test_eficonfig/test_eficonfig.py | 350 ++
3 files changed, 391 insertions(+)
create mode 100644 test/py/tests/test_eficonfig/conftest.py
create mode 100644 test/py/tests/test_eficonfig/test_eficonfig.py
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index eba7bcbb48..48c60c606d 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -93,6 +93,7 @@ CONFIG_CMD_LINK_LOCAL=y
CONFIG_CMD_ETHSW=y
CONFIG_CMD_BMP=y
CONFIG_CMD_BOOTCOUNT=y
+CONFIG_CMD_EFICONFIG=y
CONFIG_CMD_EFIDEBUG=y
CONFIG_CMD_RTC=y
CONFIG_CMD_TIME=y
diff --git a/test/py/tests/test_eficonfig/conftest.py
b/test/py/tests/test_eficonfig/conftest.py
new file mode 100644
index 00..f289df0362
--- /dev/null
+++ b/test/py/tests/test_eficonfig/conftest.py
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+"""Fixture for UEFI eficonfig test
+"""
+
+import os
+import shutil
+from subprocess import check_call
+import pytest
+
+@pytest.fixture(scope='session')
+def efi_eficonfig_data(u_boot_config):
+"""Set up a file system to be used in UEFI "eficonfig" command
+ tests
+
+Args:
+u_boot_config -- U-boot configuration.
+
+Return:
+A path to disk image to be used for testing
+"""
+mnt_point = u_boot_config.persistent_data_dir + '/test_efi_eficonfig'
+image_path = u_boot_config.persistent_data_dir + '/efi_eficonfig.img'
+
+shutil.rmtree(mnt_point, ignore_errors=True)
+os.mkdir(mnt_point, mode = 0o755)
+
+with open(mnt_point + '/initrd-1.img', 'w', encoding = 'ascii') as file:
+file.write("initrd 1")
+
+with open(mnt_point + '/initrd-2.img', 'w', encoding = 'ascii') as file:
+file.write("initrd 2")
+
+shutil.copyfile(u_boot_config.build_dir + '/lib/efi_loader/initrddump.efi',
+mnt_point + '/initrddump.efi')
+
+check_call(f'virt-make-fs --partition=gpt --size=+1M --type=vfat
{mnt_point} {image_path}',
+ shell=True)
+
+return image_path
diff --git a/test/py/tests/test_eficonfig/test_eficonfig.py
b/test/py/tests/test_eficonfig/test_eficonfig.py
new file mode 100644
index 00..1c501deb1f
--- /dev/null
+++ b/test/py/tests/test_eficonfig/test_eficonfig.py
@@ -0,0 +1,350 @@
+# SPDX-License-Identifier: GPL-2.0+
+""" Unit test for UEFI menu-driven configuration
+"""
+
+import pytest
+import time
+
+@pytest.mark.boardspec('sandbox')
+@pytest.mark.buildconfigspec('cmd_eficonfig')
+@pytest.mark.buildconfigspec('cmd_bootefi_bootmgr')
+def test_efi_eficonfig(u_boot_console, efi_eficonfig_data):
+
+def send_user_input_and_wait(user_str, expect_str):
+time.sleep(0.1) # TODO: does not work correctly without sleep
+u_boot_console.run_command(cmd=user_str, wait_for_prompt=False,
+ wait_for_echo=True, send_nl=False)
+u_boot_console.run_command(cmd='\x0d', wait_for_prompt=False,
+ wait_for_echo=False, send_nl=False)
+if expect_str is not None:
+for i in expect_str:
+u_boot_console.p.expect([i])
+
+def press_up_down_enter_and_wait(up_count, down_count, enter, expect_str):
+# press UP key
+for i in range(up_count):
+u_boot_console.run_command(cmd='\x1b\x5b\x41',
wait_for_prompt=False,
+ wait_for_echo=False, send_nl=False)
+# press DOWN key
+for i in range(down_count):
+u_boot_console.run_command(cmd='\x1b\x5b\x42',
wait_for_prompt=False,
+ wait_for_echo=False, send_nl=False)
+# press ENTER if requested
+if enter:
+u_boot_console.run_command(cmd='\x0d', wait_for_prompt=False,
+ wait_for_echo=False, send_nl=False)
+# wait expected output
+if expect_str is not None:
+for i in expect_str:
+
Re: [PATCH v15 01/10] eficonfig: menu-driven addition of UEFI boot option
On 9/2/22 16:23, Masahisa Kojima wrote:
This commit add the "eficonfig" command.
The "eficonfig" command implements the menu-driven UEFI boot option
maintenance feature. This commit implements the addition of
new boot option. User can select the block device volume having
efi_simple_file_system_protocol and select the file corresponding
to the Boot variable. User can also enter the description and
optional_data of the BOOT variable in utf8.
This commit adds "include/efi_config.h", it contains the common
definition to be used from other menus such as UEFI Secure Boot
key management.
Signed-off-by: Masahisa Kojima
---
Changes in v15:
- moves the free(entry->data) outside the eficonfig_destroy() function and
entry->data is freed explicitly only when needed
- expose eficonfig_destroy() for succeeding secure boot key management patch
Changes in v14:
- fix the missing initialization
- add comment for key handling
No change in v13:
Changes in v12:
- add select/clear menu before displaying volume selectio
- move function declaration from efi_loader.h to efi_config.h
- remove unused declaration
- support the boot option does not have file path
- correctly handle if optional_data is empty
Changes in v11:
- refactor menu entry construction, directly use eficonfig_entry structure
- remove reading directory info to calculate the number of entry
- fix invalid efi_free_pool() in ill_file_info()
- use ANSI_CURSOR_POSITION and ANSI_CLEAR_LINE instead of printf("\n")
since current eficonfig implementation does not handle console size
correctly.
printf("\n") at the outside of console size breaks the console output.
Changes in v10:
- add initrd file selection
- do refactoring
- eficonfig_process_common() use list structure
- remove u'/' before copying file_path into current_path
- fix typos
- check snprintf error
Changes in v9:
- move "efi_guid_bootmenu_auto_generated definition" into efi_bootmgr.c
to address build error when CMD_EFICONFIG is disabled
- fix typos and comment
- remove file system information from error message
- remove unreachable code in eficonfig_choice_entry()
- single printf() call as much as possible
- call only getchar() in eficonfig_print_msg()
- filter out '.' entry from file selection
- update the efi_disk_get_device_name() implementation
- add function comment
Changes in v8:
- command name is change from "efimenu" to "eficonfig"
- function and struct prefixes is changed to "eficonfig"
- fix menu header string
Changes in v7:
- add "efimenu" command and uefi variable maintenance code
moved into cmd/efimenu.c
- create include/efimenu.h to define the common definition for
the other menu such as UEFI Secure Boot key management
- update boot option edit UI, user can select description, file,
and optional_data to edit in the same menu like following.
** Edit Boot Option **
Description: debian
File: virtio 0:1/EFI\debian\grubaa64.efi
Optional Data: test
Save
Quit
- remove exit parameter from efimenu_process_common()
- menu title type is changed from u16 to char
- efimenu_process_common() add menu title string
- reduce printf/puts function call for displaying the menu
- efi_console_get_u16_string() accept 0 length to allow
optional_data is empty
- efi_console_get_u16_string() the "size" parameter name is changes to "count"
- efimenu is now designed to maintain the UEFI variables, remove autoboot
related code
- remove one empty line before "Quit" entry
- efimenu_init() processes only the first time
Changes in v6:
- fix typos
- modify volume name to match U-Boot syntax
- compile in CONFIG_EFI_LOADER=n and CONFIG_CMD_BOOTEFI_BOOTMGR=n
- simplify u16_strncmp() usage
- support "a\b.efi" file path, use link list to handle filepath
- modify length check condition
- UEFI related menu items only appears with CONFIG_AUTOBOOT_MENU_SHOW=y
Changes in v5:
- remove forward declarations
- add const qualifier for menu items
- fix the possible unaligned access for directory info access
- split into three commit 1)add boot option 2) delete boot option 3)change boot
order
This commit is 1)add boot option.
- fix file name buffer allocation size, it should be EFI_BOOTMENU_FILE_PATH_MAX
* sizeof(u16)
- fix wrong size checking for file selection
Chanes in v4:
- UEFI boot option maintenance menu is integrated into bootmenu
- display the simplified volume name(e.g. usb0:1, nvme1:2) for the
volume selection
- instead of extending lib/efi_loader/efi_bootmgr.c, newly create
lib/efi_loader/efi_bootmenu_maintenance.c and implement boot
variable maintenance into it.
Changes in RFC v3:
not included in v3 series
Changes in RFC v2:
- enable utf8 user input for boot option name
- create lib/efi_loader/efi_console.c::efi_console_get_u16_string() for
utf8 user input handling
- use u16_strlcat instead of u16_strcat
- remove the EFI_CALLs, and newly create or expose the following
xxx_int() functions.
efi_locate_handle_buffer_int(),
Re: [PATCH v2 3/8] timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support
Am 2022-09-04 02:02, schrieb Tony Dinh: Hi Stefan, Sorry, that message was prematurely sent (fat finger). Please see the continuation below. On Sat, Sep 3, 2022 at 4:43 PM Tony Dinh wrote: Hi Stefan, On Sat, Sep 3, 2022 at 3:44 AM Stefan Roese wrote: > > Hi Tony, > > On 03.09.22 11:44, Tony Dinh wrote: > > Hi Stefan, > > > > On Thu, Sep 1, 2022 at 11:25 PM Stefan Roese wrote: > >> > >> Add timer_get_boot_us() to support boards, that have CONFIG_BOOTSTAGE > >> enabled, like pogo_v4. > >> > >> Signed-off-by: Stefan Roese > >> --- > >> v2: > >> - Change timer_get_boot_us() to use the timer_early functions > >> - Remove #if CONFIG_IS_ENABLED(BOOTSTAGE) > >> > >> Simon, I'm currently looking into this timer_get_boot_us() to using > >> timer_early_get_count() etc consolidation. > > > > Indeed, as you've mentioned above, I think timer_early_get_count() and > > timer_early_get_rate() do need to take into consideration what the > > input_clock_type is for Kirkwood boards with CONFIG_BOOTSTAGE such as > > the Pogo V4. > > > > I'm seeing on the Pogo V4 test, the timer command reports time about 6 > > times slower than it should. It does seem to jive with the fact that > > the Pogo V4 CONFIG_SYS_TCLK is 166Mhz, versus MVEBU 25MHz clock rate. > > Ah, I've missing updating the early functions to also differentiate > between fixed clocks and TCLK timer. > > Please give the attached patch a try - should be applied on top of this > latest patchset. That looks promising, but I think we are still missing something. After applying the attached patch, I ran the test again and it behaved the same way (clock rate 6 times slower). So I did another test. --- Test 1 Pogo_V4> timer start; sleep 60; timer get; sleep 30; timer get 60.000 90.000 So apparently the sleep cmd has reset the correct clock rate. --- Test 2 Pogo_V4> timer start; sleep 30; timer get; sleep 30; timer get 30.000 60.000 And then wait for 30 seconds, do another "timer get" (I expected to see about 90 to 95 seconds). Pogo_V4> timer get 66.237 I've did the same test and can confirm it. But I think that is a drawback from the timer command. With a 32bit timer and a TCLK of 166MHz (on my board), the timer will wrap around about every 26s. So if you don't do a get_timer() call for that whole period, the overflow won't be counted in timer_conv_64(). For the sleep command it works correctly, because it will poll get_timer() every 100us. In summary, you cannot expect a "timer get" on the console to work if you cannot make sure, the you call it at least every "2^32 / TCLK" seconds. -michael
[PATCH v1] arm: dts: rockchip: rk3128: bulk convert gpios to their constant counterparts
Bulk convert rk3128 DT gpios to their constant counterparts.
sed -i -f script.sed rk3128.dtsi
sed -i -f script.sed rk3128-evb.dts
/rockchip,pins *=/bcheck
b # to end of script
:append-next-line
N
:check
/^[^;]*$/bappend-next-line
s/
---
arch/arm/dts/rk3128-evb.dts | 4 +-
arch/arm/dts/rk3128.dtsi| 86 ++---
2 files changed, 45 insertions(+), 45 deletions(-)
diff --git a/arch/arm/dts/rk3128-evb.dts b/arch/arm/dts/rk3128-evb.dts
index 2fb2b0da..a407ac2d 100644
--- a/arch/arm/dts/rk3128-evb.dts
+++ b/arch/arm/dts/rk3128-evb.dts
@@ -82,13 +82,13 @@
{
usb_otg {
otg_vbus_drv: host-vbus-drv {
- rockchip,pins = <0 26 RK_FUNC_GPIO _pull_none>;
+ rockchip,pins = <0 RK_PD2 RK_FUNC_GPIO _pull_none>;
};
};
usb_host {
host_vbus_drv: host-vbus-drv {
- rockchip,pins = <2 23 RK_FUNC_GPIO _pull_none>;
+ rockchip,pins = <2 RK_PC7 RK_FUNC_GPIO _pull_none>;
};
};
};
diff --git a/arch/arm/dts/rk3128.dtsi b/arch/arm/dts/rk3128.dtsi
index 5d2499c1..62fd5343 100644
--- a/arch/arm/dts/rk3128.dtsi
+++ b/arch/arm/dts/rk3128.dtsi
@@ -618,85 +618,85 @@
*/
emmc_clk: emmc-clk {
- rockchip,pins = <2 7 RK_FUNC_2 _pull_none>;
+ rockchip,pins = <2 RK_PA7 2 _pull_none>;
};
emmc_cmd: emmc-cmd {
- rockchip,pins = <2 4 RK_FUNC_2 _pull_none>;
+ rockchip,pins = <2 RK_PA4 2 _pull_none>;
};
emmc_pwren: emmc-pwren {
- rockchip,pins = <2 5 RK_FUNC_2 _pull_none>;
+ rockchip,pins = <2 RK_PA5 2 _pull_none>;
};
emmc_bus8: emmc-bus8 {
- rockchip,pins = <1 24 RK_FUNC_2
_pull_none>,
- <1 25 RK_FUNC_2
_pull_none>,
- <1 26 RK_FUNC_2
_pull_none>,
- <1 27 RK_FUNC_2
_pull_none>,
- <1 28 RK_FUNC_2
_pull_none>,
- <1 29 RK_FUNC_2
_pull_none>,
- <1 30 RK_FUNC_2
_pull_none>,
- <1 31 RK_FUNC_2
_pull_none>;
+ rockchip,pins = <1 RK_PD0 2 _pull_none>,
+ <1 RK_PD1 2 _pull_none>,
+ <1 RK_PD2 2 _pull_none>,
+ <1 RK_PD3 2 _pull_none>,
+ <1 RK_PD4 2 _pull_none>,
+ <1 RK_PD5 2 _pull_none>,
+ <1 RK_PD6 2 _pull_none>,
+ <1 RK_PD7 2 _pull_none>;
};
};
nandc{
nandc_ale:nandc-ale {
- rockchip,pins = <0 18 RK_FUNC_1
_pull_none>;
+ rockchip,pins = <0 RK_PC2 1 _pull_none>;
};
nandc_cle:nandc-cle {
- rockchip,pins = <0 18 RK_FUNC_1
_pull_none>;
+ rockchip,pins = <0 RK_PC2 1 _pull_none>;
};
nandc_wrn:nandc-wrn {
- rockchip,pins = <0 18 RK_FUNC_1
_pull_none>;
+ rockchip,pins = <0 RK_PC2 1 _pull_none>;
};
nandc_rdn:nandc-rdn {
- rockchip,pins = <0 18 RK_FUNC_1
_pull_none>;
+ rockchip,pins = <0 RK_PC2 1 _pull_none>;
};
nandc_rdy:nandc-rdy {
- rockchip,pins = <0 18 RK_FUNC_1
_pull_none>;
+ rockchip,pins = <0 RK_PC2 1 _pull_none>;
};
nandc_cs0:nandc-cs0 {
- rockchip,pins = <0 18 RK_FUNC_1
_pull_none>;
+ rockchip,pins = <0 RK_PC2 1 _pull_none>;
};
nandc_data: nandc-data {
- rockchip,pins = <0 18 RK_FUNC_1
_pull_none>;
+ rockchip,pins = <0 RK_PC2 1 _pull_none>;
};
};
uart0 {
uart0_xfer:
Re: [PATCH v2 2/2] efi_selftest: unit test for EFI Conformance Profile Table
On 9/4/22 07:08, Ilias Apalodimas wrote:
Hi Heinrich,
[...]
+ */
+static int ecpt_find_guid(struct efi_conformance_profiles_table *ecpt,
+ const efi_guid_t *guid) {
+ int i;
+
+ for (i = 0; i < ecpt->number_of_profiles; ++i) {
+ if (!memcmp(>conformance_profiles[i], guid, 16))
+ return EFI_ST_SUCCESS;
Can't we use guidcmp here?
I would prefer to keep the unit tests independent of U-Boot's library
functions so that we can opt to compile them as freestanding UEFI
application.
Best regards
Heinrich
+ }
+ efi_st_error("GUID %pU not found\n", guid);
+ return EFI_ST_FAILURE;
+}
+
+/*
[...]
Thanks
/Ilias
[PATCH v2 1/1] cmd: fix tftpput command
From: Heinrich Schuchardt
Calling tftpput with less than 2 arguments must lead to a failure.
If tftpput is called with two arguments, these are the address and
the size of the file to be transferred.
Signed-off-by: Heinrich Schuchardt
---
v2:
carve out function parse_args()
---
cmd/net.c | 90 ---
1 file changed, 66 insertions(+), 24 deletions(-)
diff --git a/cmd/net.c b/cmd/net.c
index 3619c843d8..18627de16c 100644
--- a/cmd/net.c
+++ b/cmd/net.c
@@ -189,30 +189,49 @@ static void netboot_update_env(void)
#endif
}
-static int netboot_common(enum proto_t proto, struct cmd_tbl *cmdtp, int argc,
- char *const argv[])
+/**
+ * parse_addr_size() - parse address and size arguments for tftpput
+ *
+ * @argv: command line arguments
+ * Return: 0 on success
+ */
+static int parse_addr_size(char * const argv[])
{
- char *s;
- char *end;
- int rcode = 0;
- int size;
- ulong addr;
-
- net_boot_file_name_explicit = false;
+ if (strict_strtoul(argv[1], 16, _save_addr) < 0 ||
+ strict_strtoul(argv[2], 16, _save_size) < 0) {
+ printf("Invalid address/size\n");
+ return CMD_RET_USAGE;
+ }
+ return 0;
+}
- /* pre-set image_load_addr */
- s = env_get("loadaddr");
- if (s != NULL)
- image_load_addr = hextoul(s, NULL);
+/**
+ * parse_args() - parse command line arguments
+ *
+ * @proto: command prototype
+ * @argc: number of arguments
+ * @argv: command line arguments
+ * Return: 0 on success
+ */
+int parse_args(enum proto_t proto, int argc, char *const argv[])
+{
+ ulong addr;
+ char *end;
switch (argc) {
case 1:
+ if (CONFIG_IS_ENABLED(CMD_TFTPPUT) && proto == TFTPPUT)
+ return 1;
+
/* refresh bootfile name from env */
copy_filename(net_boot_file_name, env_get("bootfile"),
sizeof(net_boot_file_name));
break;
- case 2: /*
+ case 2:
+ if (CONFIG_IS_ENABLED(CMD_TFTPPUT) && proto == TFTPPUT)
+ return 1;
+ /*
* Only one arg - accept two forms:
* Just load address, or just boot file name. The latter
* form must be written in a format which can not be
@@ -232,29 +251,52 @@ static int netboot_common(enum proto_t proto, struct
cmd_tbl *cmdtp, int argc,
break;
case 3:
- image_load_addr = hextoul(argv[1], NULL);
- net_boot_file_name_explicit = true;
- copy_filename(net_boot_file_name, argv[2],
- sizeof(net_boot_file_name));
-
+ if (CONFIG_IS_ENABLED(CMD_TFTPPUT) && proto == TFTPPUT) {
+ if (parse_addr_size(argv))
+ return 1;
+ } else {
+ image_load_addr = hextoul(argv[1], NULL);
+ net_boot_file_name_explicit = true;
+ copy_filename(net_boot_file_name, argv[2],
+ sizeof(net_boot_file_name));
+ }
break;
#ifdef CONFIG_CMD_TFTPPUT
case 4:
- if (strict_strtoul(argv[1], 16, _save_addr) < 0 ||
- strict_strtoul(argv[2], 16, _save_size) < 0) {
- printf("Invalid address/size\n");
- return CMD_RET_USAGE;
- }
+ if (parse_addr_size(argv))
+ return 1;
net_boot_file_name_explicit = true;
copy_filename(net_boot_file_name, argv[3],
sizeof(net_boot_file_name));
break;
#endif
default:
+ return 1;
+ }
+ return 0;
+}
+
+static int netboot_common(enum proto_t proto, struct cmd_tbl *cmdtp, int argc,
+ char *const argv[])
+{
+ char *s;
+ int rcode = 0;
+ int size;
+
+ net_boot_file_name_explicit = false;
+ *net_boot_file_name = '\0';
+
+ /* pre-set image_load_addr */
+ s = env_get("loadaddr");
+ if (s != NULL)
+ image_load_addr = hextoul(s, NULL);
+
+ if (parse_args(proto, argc, argv)) {
bootstage_error(BOOTSTAGE_ID_NET_START);
return CMD_RET_USAGE;
}
+
bootstage_mark(BOOTSTAGE_ID_NET_START);
size = net_loop(proto);
--
2.37.2
[PATCH 1/1] cmd: correct short text for tftpboot
The command's name is a misnomer. The command loads a file but does not run (boot) it. Signed-off-by: Heinrich Schuchardt --- cmd/Kconfig | 2 +- cmd/net.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/cmd/Kconfig b/cmd/Kconfig index 8ea064b8d2..0e0be94f41 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -1719,7 +1719,7 @@ config CMD_TFTPBOOT bool "tftpboot" default y help - tftpboot - boot image via network using TFTP protocol + tftpboot - load file via network using TFTP protocol config CMD_TFTPPUT bool "tftp put" diff --git a/cmd/net.c b/cmd/net.c index 18627de16c..683d0966b0 100644 --- a/cmd/net.c +++ b/cmd/net.c @@ -46,7 +46,7 @@ int do_tftpb(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]) U_BOOT_CMD( tftpboot, 3, 1, do_tftpb, - "boot image via network using TFTP protocol", + "load file via network using TFTP protocol", "[loadAddress] [[hostIPaddr:]bootfilename]" ); #endif -- 2.37.2
Re: [PATCH v9 05/15] stm32mp1: dk2: Add image information for capsule updates
On Fri, Aug 26, 2022 at 03:27:06PM +0530, Sughosh Ganu wrote:
> Enabling capsule update functionality on the platform requires
> populating information on the images that are to be updated using the
> functionality. Do so for the DK2 board.
>
> Signed-off-by: Sughosh Ganu
> ---
> Changes since V8:
> * Use STM32MP_FIP_IMAGE_GUID for the FIP GUID value as suggested by
> Yann
>
> board/st/stm32mp1/stm32mp1.c | 23 +++
> include/configs/stm32mp15_common.h | 4
> 2 files changed, 27 insertions(+)
>
> diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
> index 9496890d16..bfec0a710d 100644
> --- a/board/st/stm32mp1/stm32mp1.c
> +++ b/board/st/stm32mp1/stm32mp1.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -87,6 +88,16 @@
> #define USB_START_LOW_THRESHOLD_UV 123
> #define USB_START_HIGH_THRESHOLD_UV 215
>
> +#if CONFIG_IS_ENABLED(EFI_HAVE_CAPSULE_SUPPORT)
> +struct efi_fw_image fw_images[1];
> +
> +struct efi_capsule_update_info update_info = {
> + .images = fw_images,
> +};
> +
> +u8 num_image_type_guids = ARRAY_SIZE(fw_images);
> +#endif /* EFI_HAVE_CAPSULE_SUPPORT */
> +
> int board_early_init_f(void)
> {
> /* nothing to do, only used in SPL */
> @@ -670,6 +681,18 @@ int board_init(void)
>
> setup_led(LEDST_ON);
>
> +#if CONFIG_IS_ENABLED(EFI_HAVE_CAPSULE_SUPPORT)
> + if (board_is_stm32mp15x_dk2()) {
> + efi_guid_t image_type_guid = STM32MP_FIP_IMAGE_GUID;
> + guidcpy(_images[0].image_type_id, _type_guid);
> + fw_images[0].fw_name = u"STM32MP-FIP";
> + /*
> + * For FWU multi bank update, the image
> + * index will be computed at runtime
> + */
> + fw_images[0].image_index = 0;
> + }
> +#endif
> return 0;
> }
>
> diff --git a/include/configs/stm32mp15_common.h
> b/include/configs/stm32mp15_common.h
> index c5412ffeb3..bb19dae945 100644
> --- a/include/configs/stm32mp15_common.h
> +++ b/include/configs/stm32mp15_common.h
> @@ -34,6 +34,10 @@
> #define CONFIG_SERVERIP 192.168.1.1
> #endif
>
> +#define STM32MP_FIP_IMAGE_GUID \
> + EFI_GUID(0x19d5df83, 0x11b0, 0x457b, 0xbe, 0x2c, \
> + 0x75, 0x59, 0xc1, 0x31, 0x42, 0xa5)
> +
>
> /*/
> #ifdef CONFIG_DISTRO_DEFAULTS
>
> /*/
> --
> 2.34.1
>
Reviewed-by: Ilias Apalodimas
Re: [PATCH v9 12/15] test: dm: Add test cases for FWU Metadata uclass
On Fri, Aug 26, 2022 at 03:27:13PM +0530, Sughosh Ganu wrote:
> Add test cases for accessing the FWU Metadata on the sandbox
> platform. The sandbox platform also uses the metadata access driver
> for GPT partitioned block devices.
>
> The FWU feature will be tested on the sandbox64 variant with a raw
> capsule. Remove the FIT capsule testing from sandbox64 defconfig --
> the FIT capsule test will be run on the sandbox_flattree variant.
>
> Signed-off-by: Sughosh Ganu
> Suggested-by: Heinrich Schuchardt
> ---
> Changes since V8: New patch
>
> arch/sandbox/Kconfig | 6 +
> arch/sandbox/dts/test.dts | 7 +-
> board/sandbox/sandbox.c | 10 ++
> configs/sandbox64_defconfig | 5 +-
> lib/fwu_updates/fwu.c | 6 +
> test/dm/Makefile | 1 +
> test/dm/fwu_mdata.c | 149 ++
> test/dm/fwu_mdata_disk_image.h| 112 +
> .../test_capsule_firmware_fit.py | 1 -
> .../test_capsule_firmware_signed_fit.py | 1 -
> tools/Makefile| 2 +-
> 11 files changed, 295 insertions(+), 5 deletions(-)
> create mode 100644 test/dm/fwu_mdata.c
> create mode 100644 test/dm/fwu_mdata_disk_image.h
>
> diff --git a/arch/sandbox/Kconfig b/arch/sandbox/Kconfig
> index 852a7c8bf2..40cdea7d46 100644
> --- a/arch/sandbox/Kconfig
> +++ b/arch/sandbox/Kconfig
> @@ -84,3 +84,9 @@ config SYS_FDT_LOAD_ADDR
> See `doc/arch/sandbox.rst` for more information.
>
> endmenu
> +
> +config FWU_NUM_BANKS
> + default 2
> +
> +config FWU_NUM_IMAGES_PER_BANK
> + default 2
> diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> index 2761588f0d..2cba13e98d 100644
> --- a/arch/sandbox/dts/test.dts
> +++ b/arch/sandbox/dts/test.dts
> @@ -948,7 +948,7 @@
> };
>
> /* This is used for the fastboot tests */
> - mmc0 {
> + mmc0: mmc0 {
> compatible = "sandbox,mmc";
> };
>
> @@ -1683,6 +1683,11 @@
> compatible = "sandbox,regmap_test";
> };
> };
> +
> + fwu-mdata {
> + compatible = "u-boot,fwu-mdata-gpt";
> + fwu-mdata-store = <>;
> + };
> };
>
> #include "sandbox_pmic.dtsi"
> diff --git a/board/sandbox/sandbox.c b/board/sandbox/sandbox.c
> index ca9a2ca5b1..76170f4cc8 100644
> --- a/board/sandbox/sandbox.c
> +++ b/board/sandbox/sandbox.c
> @@ -164,3 +164,13 @@ int init_addr_map(void)
>
> return 0;
> }
> +
> +#if defined(CONFIG_FWU_MULTI_BANK_UPDATE)
> +void fwu_plat_get_bootidx(void *boot_idx)
> +{
> + u32 *idx = boot_idx;
> +
> + /* Dummy value */
> + *idx = 0;
> +}
> +#endif
> diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
> index 290d1506c2..8d456e33d9 100644
> --- a/configs/sandbox64_defconfig
> +++ b/configs/sandbox64_defconfig
> @@ -242,9 +242,12 @@ CONFIG_LZ4=y
> CONFIG_ERRNO_STR=y
> CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
> CONFIG_EFI_CAPSULE_ON_DISK=y
> -CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
> +CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
> CONFIG_EFI_SECURE_BOOT=y
> CONFIG_TEST_FDTDEC=y
> CONFIG_UNIT_TEST=y
> CONFIG_UT_TIME=y
> CONFIG_UT_DM=y
> +CONFIG_FWU_MDATA=y
> +CONFIG_FWU_MDATA_GPT_BLK=y
> +CONFIG_FWU_MULTI_BANK_UPDATE=y
> diff --git a/lib/fwu_updates/fwu.c b/lib/fwu_updates/fwu.c
> index de2412785d..1fb6feabfd 100644
> --- a/lib/fwu_updates/fwu.c
> +++ b/lib/fwu_updates/fwu.c
> @@ -542,6 +542,12 @@ static int fwu_boottime_checks(void *ctx, struct event
> *event)
> struct udevice *dev;
> u32 boot_idx, active_idx;
>
> + /* Don't have boot time checks on sandbox */
> + if (IS_ENABLED(CONFIG_SANDBOX)) {
> + boottime_check = 1;
> + return 0;
> + }
> +
> ret = fwu_get_dev();
> if (ret)
> return ret;
> diff --git a/test/dm/Makefile b/test/dm/Makefile
> index 52fe178a82..61837703e8 100644
> --- a/test/dm/Makefile
> +++ b/test/dm/Makefile
> @@ -47,6 +47,7 @@ ifneq ($(CONFIG_EFI_PARTITION),)
> obj-$(CONFIG_FASTBOOT_FLASH_MMC) += fastboot.o
> endif
> obj-$(CONFIG_FIRMWARE) += firmware.o
> +obj-$(CONFIG_FWU_MDATA_GPT_BLK) += fwu_mdata.o
> obj-$(CONFIG_DM_HWSPINLOCK) += hwspinlock.o
> obj-$(CONFIG_DM_I2C) += i2c.o
> obj-$(CONFIG_SOUND) += i2s.o
> diff --git a/test/dm/fwu_mdata.c b/test/dm/fwu_mdata.c
> new file mode 100644
> index 00..8120af334e
> --- /dev/null
> +++ b/test/dm/fwu_mdata.c
> @@ -0,0 +1,149 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) 2022, Linaro Limited
> + * Copyright (c) 2022, Heinrich Schuchardt
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include "fwu_mdata_disk_image.h"
> +
> +/* Block size of compressed disk image */
> +#define
Re: [PATCH v9 01/15] dt/bindings: Add bindings for GPT based FWU Metadata storage device
On Fri, Aug 26, 2022 at 03:27:02PM +0530, Sughosh Ganu wrote:
> Add bindings needed for accessing the FWU metadata partitions. These
> include the compatible string which point to the access method and the
> actual device which stores the FWU metadata.
>
> The current patch adds basic bindings needed for accessing the
> metadata structure on GPT partitioned block devices.
>
> Signed-off-by: Sughosh Ganu
> Reviewed-by: Heinrich Schuchardt
> ---
> Changes since V8: None
>
> .../firmware/fwu-mdata-gpt.yaml | 32 +++
> 1 file changed, 32 insertions(+)
> create mode 100644 doc/device-tree-bindings/firmware/fwu-mdata-gpt.yaml
>
> diff --git a/doc/device-tree-bindings/firmware/fwu-mdata-gpt.yaml
> b/doc/device-tree-bindings/firmware/fwu-mdata-gpt.yaml
> new file mode 100644
> index 00..0735191ff1
> --- /dev/null
> +++ b/doc/device-tree-bindings/firmware/fwu-mdata-gpt.yaml
> @@ -0,0 +1,32 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/firmware/fwu-mdata-gpt.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: FWU metadata on device with GPT partitioned layout
> +
> +maintainers:
> + - Sughosh Ganu
> +
> +properties:
> + compatible:
> +items:
> + - const: u-boot,fwu-mdata-gpt
> +
> + fwu-mdata-store:
> +maxItems: 1
> +description: Phandle of the device which contains the FWU medatata
> partition.
> +
> +required:
> + - compatible
> + - fwu-mdata-store
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +fwu-mdata {
> +compatible = "u-boot,fwu-mdata-gpt";
> +fwu-mdata-store = <>;
> +};
> --
> 2.34.1
>
Reviewed-by: Ilias Apalodimas
