Re: [PATCH v4 2/2] efi_loader: Reset system after CapsuleUpdate on disk
Hi Simon,
BTW, I saw the below code in the sysreset-uclass.c. It seems if I pass
0 to argc, it seems to do SYSRESET_COLD, isn't it?
int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
{
enum sysreset_t reset_type = SYSRESET_COLD;
if (argc > 2)
return CMD_RET_USAGE;
if (argc == 2 && argv[1][0] == '-' && argv[1][1] == 'w') {
reset_type = SYSRESET_WARM;
}
printf("resetting ...\n");
mdelay(100);
sysreset_walk_halt(reset_type);
return 0;
}
2022年2月28日(月) 13:19 Masami Hiramatsu :
>
> Hi Simon,
>
> 2022年2月27日(日) 3:37 Simon Glass :
> >
> > Hi Masami,
> >
> > On Thu, 3 Feb 2022 at 02:23, Masami Hiramatsu
> > wrote:
> > >
> > > Add a cold reset soon after processing capsule update on disk.
> > > This is required in UEFI specification 2.9 Section 8.5.5
> > > "Delivery of Capsules via file on Mass Storage device" as;
> > >
> > > In all cases that a capsule is identified for processing the system is
> > > restarted after capsule processing is completed.
> > >
> > > This also reports the result of each capsule update so that the user can
> > > notice that the capsule update has been succeeded or not from console log.
> > >
> > > Signed-off-by: Masami Hiramatsu
> > > ---
> > > Changes in v4:
> > > - Do not use sysreset because that is a warm reset.
> >
> > I don't get that.
> >
> > You should use sysreset and the SYSRESET_COLD type.
>
> Thanks, yeah, I found that parameter.
> Let's fix that.
>
> Thank you,
>
> >
> > > - Fix patch description.
> > > ---
> > > lib/efi_loader/efi_capsule.c | 18 --
> > > 1 file changed, 16 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
> > > index 1ec7ea29ff..20d9490dbd 100644
> > > --- a/lib/efi_loader/efi_capsule.c
> > > +++ b/lib/efi_loader/efi_capsule.c
> > > @@ -14,6 +14,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -1120,8 +1121,11 @@ efi_status_t efi_launch_capsules(void)
> > > if (ret == EFI_SUCCESS) {
> > > ret = efi_capsule_update_firmware(capsule);
> > > if (ret != EFI_SUCCESS)
> > > - log_err("Applying capsule %ls failed\n",
> > > + log_err("Applying capsule %ls failed.\n",
> > > files[i]);
> > > + else
> > > + log_info("Applying capsule %ls
> > > succeeded.\n",
> > > +files[i]);
> > >
> > > /* create Capsule */
> > > set_capsule_result(index, capsule, ret);
> > > @@ -1142,6 +1146,16 @@ efi_status_t efi_launch_capsules(void)
> > > free(files[i]);
> > > free(files);
> > >
> > > - return ret;
> > > + /*
> > > +* UEFI spec requires to reset system after complete processing
> > > capsule
> > > +* update on the storage.
> > > +*/
> > > + log_info("Reboot after firmware update");
> > > + /* Cold reset is required for loading the new firmware. */
> > > + do_reset(NULL, 0, 0, NULL);
> >
> > No! This should use sysreset.
> >
> > > + hang();
> > > + /* not reach here */
> > > +
> > > + return 0;
> > > }
> > > #endif /* CONFIG_EFI_CAPSULE_ON_DISK */
> > >
> >
> > Regards,
> > Simon
>
>
>
> --
> Masami Hiramatsu
--
Masami Hiramatsu
Re: [PATCH v2] spi: Add spi_get_bus_and_cs() new use_dt param
Hi
Don't take care of this patch, a v3 will be send
Patrice
On 2/21/22 08:33, Patrice Chotard wrote:
> Add spi_get_bus_and_cs() new "use_dt" param which allows to
> select SPI speed and mode from DT or from default value passed
> in parameters.
>
> Introduce spi_flash_probe_bus_cs_default() which is identical
> to spi_flash_probe_bus_cs() except it calls spi_get_bus_and_cs()
> with use_dt param set to false.
>
> Since commit e2e95e5e2542 ("spi: Update speed/mode on change")
> when calling "sf probe" or "env save" on SPI flash,
> spi_set_speed_mode() is called twice.
>
> spi_get_bus_and_cs()
> |--> spi_claim_bus()
> | |--> spi_set_speed_mode(speed and mode from DT)
> ...
> |--> spi_set_speed_mode(default speed and mode value)
>
> The first spi_set_speed_mode() call is done with speed and mode
> values from DT, whereas the second call is done with speed
> and mode set to default value (speed is set to CONFIG_SF_DEFAULT_SPEED)
>
> This is an issue because SPI flash performance are impacted by
> using default speed which can be lower than the one defined in DT.
>
> One solution is to set CONFIG_SF_DEFAULT_SPEED to the speed defined
> in DT, but we loose flexibility offered by DT.
>
> Another issue can be encountered with 2 SPI flashes using 2 different
> speeds. In this specific case usage of CONFIG_SF_DEFAULT_SPEED is not
> flexible compared to get the 2 different speeds from DT.
>
> By adding new parameter "use_dt" to spi_get_bus_and_cs(), this allows
> to force usage of either speed and mode from DT (use_dt = true) or to
> use speed and mode parameter value.
>
> Signed-off-by: Patrice Chotard
> Cc: Marek Behun
> Cc: Jagan Teki
> Cc: Vignesh R
> Cc: Joe Hershberger
> Cc: Ramon Fried
> Cc: Lukasz Majewski
> Cc: Marek Vasut
> Cc: Wolfgang Denk
> Cc: Simon Glass
> Cc: Stefan Roese
> Cc: "Pali Rohár"
> Cc: Konstantin Porotchkin
> Cc: Igal Liberman
> Cc: Bin Meng
> Cc: Pratyush Yadav
> Cc: Sean Anderson
> Cc: Anji J
> Cc: Biwen Li
> Cc: Priyanka Jain
> Cc: Chaitanya Sakinam
>
> ---
>
> Changes in v2:
> - add spi_flash_probe_bus_cs_default() which calls spi_get_bus_and_cs()
> with "use_dt" param set to true, whereas spi_flash_probe_bus_cs() calls
> spi_get_bus_and_cs() with "use_dt" param set to true.
>
> board/CZ.NIC/turris_mox/turris_mox.c | 2 +-
> cmd/sf.c | 9 -
> cmd/spi.c| 2 +-
> drivers/mtd/spi/sf-uclass.c | 30 ++--
> drivers/spi/spi-uclass.c | 8
> drivers/usb/gadget/max3420_udc.c | 2 +-
> include/spi.h| 7 ---
> include/spi_flash.h | 4
> test/dm/spi.c| 15 +++---
> 9 files changed, 59 insertions(+), 20 deletions(-)
>
> diff --git a/board/CZ.NIC/turris_mox/turris_mox.c
> b/board/CZ.NIC/turris_mox/turris_mox.c
> index f0c5aa6a52..4b755e1420 100644
> --- a/board/CZ.NIC/turris_mox/turris_mox.c
> +++ b/board/CZ.NIC/turris_mox/turris_mox.c
> @@ -148,7 +148,7 @@ static int mox_do_spi(u8 *in, u8 *out, size_t size)
> struct udevice *dev;
> int ret;
>
> - ret = spi_get_bus_and_cs(0, 1, 100, SPI_CPHA | SPI_CPOL,
> + ret = spi_get_bus_and_cs(0, 1, 100, SPI_CPHA | SPI_CPOL, false,
>"spi_generic_drv", "moxtet@1", ,
>);
> if (ret)
> diff --git a/cmd/sf.c b/cmd/sf.c
> index 8bdebd9fd8..40b2cc3297 100644
> --- a/cmd/sf.c
> +++ b/cmd/sf.c
> @@ -91,6 +91,7 @@ static int do_spi_flash_probe(int argc, char *const argv[])
> unsigned int speed = CONFIG_SF_DEFAULT_SPEED;
> unsigned int mode = CONFIG_SF_DEFAULT_MODE;
> char *endp;
> + bool use_dt = true;
> #if CONFIG_IS_ENABLED(DM_SPI_FLASH)
> struct udevice *new, *bus_dev;
> int ret;
> @@ -117,11 +118,13 @@ static int do_spi_flash_probe(int argc, char *const
> argv[])
> speed = simple_strtoul(argv[2], , 0);
> if (*argv[2] == 0 || *endp != 0)
> return -1;
> + use_dt = false;
> }
> if (argc >= 4) {
> mode = hextoul(argv[3], );
> if (*argv[3] == 0 || *endp != 0)
> return -1;
> + use_dt = false;
> }
>
> #if CONFIG_IS_ENABLED(DM_SPI_FLASH)
> @@ -131,7 +134,11 @@ static int do_spi_flash_probe(int argc, char *const
> argv[])
> device_remove(new, DM_REMOVE_NORMAL);
> }
> flash = NULL;
> - ret = spi_flash_probe_bus_cs(bus, cs, speed, mode, );
> + if (use_dt)
> + ret = spi_flash_probe_bus_cs(bus, cs, speed, mode, );
> + else
> + ret = spi_flash_probe_bus_cs_default(bus, cs, speed, mode,
> );
> +
> if (ret) {
> printf("Failed to initialize SPI flash at %u:%u (error %d)\n",
> bus, cs, ret);
> diff --git a/cmd/spi.c
Re: [PATCH 2/2] Add SCSI scan for ENV in EXT4 or FAT
+ Simon, could you review this change? It would be nice to have this fix in upcoming U-Boot release. On Wednesday 09 February 2022 00:27:01 Rogier Stam wrote: > When having environment stored in EXT4 or FAT > and using an AHCI or SCSI device / partition > the scan would not be performed early enough > and hence the device would not be recognized. > This change adds the scan when the interface > is "scsi" in a similar way to mmc_initialize. > > Signed-off-by: Rogier Stam Reviewed-by: Pali Rohár > --- > env/ext4.c | 5 + > env/fat.c | 5 + > 2 files changed, 10 insertions(+) > > diff --git a/env/ext4.c b/env/ext4.c > index 9f65afb..47e05a4 100644 > --- a/env/ext4.c > +++ b/env/ext4.c > @@ -31,6 +31,7 @@ > #include > #include > #include > +#include > #include > > DECLARE_GLOBAL_DATA_PTR; > @@ -146,6 +147,10 @@ static int env_ext4_load(void) > if (!strcmp(ifname, "mmc")) > mmc_initialize(NULL); > #endif > +#if defined(CONFIG_AHCI) || defined(CONFIG_SCSI) > + if (!strcmp(ifname, "scsi")) > + scsi_scan(true); > +#endif > > part = blk_get_device_part_str(ifname, dev_and_part, > _desc, , 1); > diff --git a/env/fat.c b/env/fat.c > index fdccd6c..dbd6a13 100644 > --- a/env/fat.c > +++ b/env/fat.c > @@ -17,6 +17,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -122,6 +123,10 @@ static int env_fat_load(void) > if (!strcmp(CONFIG_ENV_FAT_INTERFACE, "mmc")) > mmc_initialize(NULL); > #endif > +#if defined(CONFIG_AHCI) || defined(CONFIG_SCSI) > + if (!strcmp(CONFIG_ENV_FAT_INTERFACE, "scsi")) > + scsi_scan(true); > +#endif > > part = blk_get_device_part_str(CONFIG_ENV_FAT_INTERFACE, > env_fat_device_and_part(), > -- > 2.7.4 >
Re: [PATCH 1/2] Fix Espressobin build for configs where ENV is not in SPI
+ Marek, Stefan
On Wednesday 09 February 2022 00:27:00 Rogier Stam wrote:
> When storing the UBoot Environment in for example EXT4,
> the U-Boot build is broken for several reasons:
> 1. armada-385-turris-omnia-u-boot.dtsi will not allow
>CONFIG_ENV_OFFSET and CONFIG_ENV_SIZE to be undefined
> 2. armada-37xx/board.c ft_board_setup function does not
>exist if CONFIG_ENV_IS_IN_SPI_FLASH is not defined
>
> This commit changes these files so that selecting a
> different location for the environment is possible.
>
> Signed-off-by: Rogier Stam
Reviewed-by: Pali Rohár
> ---
> arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi | 2 ++
> board/Marvell/mvebu_armada-37xx/board.c | 4 +++-
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi
> b/arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi
> index 3ff76c9..008787e 100644
> --- a/arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi
> +++ b/arch/arm/dts/armada-385-turris-omnia-u-boot.dtsi
> @@ -38,6 +38,7 @@
> };
> };
>
> +#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
> {
> u-boot,dm-pre-reloc;
>
> @@ -56,6 +57,7 @@
> };
> };
> };
> +#endif
>
> {
> u-boot,dm-pre-reloc;
> diff --git a/board/Marvell/mvebu_armada-37xx/board.c
> b/board/Marvell/mvebu_armada-37xx/board.c
> index d7b6eca..5bace0c 100644
> --- a/board/Marvell/mvebu_armada-37xx/board.c
> +++ b/board/Marvell/mvebu_armada-37xx/board.c
> @@ -328,9 +328,10 @@ int board_network_enable(struct mii_dev *bus)
> return 0;
> }
>
> -#if defined(CONFIG_OF_BOARD_SETUP) && defined(CONFIG_ENV_IS_IN_SPI_FLASH)
> +#ifdef CONFIG_OF_BOARD_SETUP
> int ft_board_setup(void *blob, struct bd_info *bd)
> {
> +#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
> int ret;
> int spi_off;
> int parts_off;
> @@ -424,6 +425,7 @@ int ft_board_setup(void *blob, struct bd_info *bd)
> return 0;
> }
>
> +#endif
> return 0;
> }
> #endif
> --
> 2.7.4
>
Re: [PATCH] gpio: slg7xl45106: Add support for slg7xl45106 i2c gpo expander
On 2/28/22 06:27, Heiko Schocher wrote: Hello Michal, On 23.02.22 16:21, Michal Simek wrote: From: T Karthik Reddy slg7xl45106 is i2c based 8-bit gpo expander, gpo pins are set and get by writing and reading corresponding gpo bit value into its data register. Signed-off-by: T Karthik Reddy Signed-off-by: Michal Simek --- MAINTAINERS | 1 + drivers/gpio/Kconfig| 8 +++ drivers/gpio/Makefile | 1 + drivers/gpio/gpio_slg7xl45106.c | 115 4 files changed, 125 insertions(+) create mode 100644 drivers/gpio/gpio_slg7xl45106.c Reviewed-by: Heiko Schocher Nitpick only, fix typo in subject s/gpo/gpio GPO is correct. This is output only device. There is no way to read anything back. Thanks, Michal
RE: [PATCH 1/5] armv8: include psci_update_dt() unconditionally
>-Original Message-
>From: U-Boot On Behalf Of Michael Walle
>Sent: Friday, November 26, 2021 10:04 PM
>To: u-boot@lists.denx.de
>Cc: Mingkai Hu ; Rajesh Bhagat
>; Michael Walle
>Subject: [PATCH 1/5] armv8: include psci_update_dt() unconditionally
>
>psci_update_dt() is also required if CONFIG_ARMV8_PSCI is set, that is, if
>u-boot
>is the PSCI provider.
>Guard the check which is intended to call into the PSCI implementation in the
>secure firmware, by the proper macro SEC_FIRMWARE_ARMV8_PSCI.
>
>Signed-off-by: Michael Walle
>---
> arch/arm/cpu/armv8/cpu-dt.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
>diff --git a/arch/arm/cpu/armv8/cpu-dt.c b/arch/arm/cpu/armv8/cpu-dt.c index
>61c38b17cb..1bf8fbaae3 100644
>--- a/arch/arm/cpu/armv8/cpu-dt.c
>+++ b/arch/arm/cpu/armv8/cpu-dt.c
>@@ -8,8 +8,8 @@
> #include
> #include
> #include
>+#include
>
>-#if CONFIG_IS_ENABLED(ARMV8_SEC_FIRMWARE_SUPPORT)
> int psci_update_dt(void *fdt)
> {
> /*
>@@ -18,8 +18,10 @@ int psci_update_dt(void *fdt)
>* number to support detecting PSCI dynamically and then switching
>* the SMP boot method between PSCI and spin-table.
>*/
>- if (sec_firmware_support_psci_version() == PSCI_INVALID_VER)
>+ if (CONFIG_IS_ENABLED(SEC_FIRMWARE_ARMV8_PSCI) &&
>+ sec_firmware_support_psci_version() == PSCI_INVALID_VER)
> return 0;
>+
> fdt_psci(fdt);
>
> #if defined(CONFIG_ARMV8_PSCI) && !defined(CONFIG_ARMV8_SECURE_BASE)
>@@ -30,4 +32,3 @@ int psci_update_dt(void *fdt)
>
> return 0;
> }
>-#endif
>--
>2.30.2
Kindly fix build for renesas platforms
2022-02-25T15:26:42.0514001Z Summary of current source for 17 boards (2
threads, 1 job per thread)
2022-02-25T15:26:42.0515545Zaarch64: w+ r8a77980_condor r8a77995_draak
r8a77970_eagle r8a77990_ebisu rcar3_salvator-x rcar3_ulcb + r8a779a0_falcon
2022-02-25T15:26:42.0516492Zarm: w+ alt blanche gose koelsch lager
porter silk stout
2022-02-25T15:26:42.0516894Z sh: w+ r2dplus
2022-02-25T15:26:42.0517553Z +srec_cat: warning: option
"-Little_Endian_CONSTant" is deprecated, please use
2022-02-25T15:26:42.0518178Z +"-CONSTant_Little_Endian" instead
2022-02-25T15:26:42.0518870Z +aarch64-linux-ld.bfd:
arch/arm/mach-rmobile/psci-r8a779a0.o: in function `psci_update_dt':
2022-02-25T15:26:42.0520304Z +arch/arm/mach-rmobile/psci-r8a779a0.c:49:
multiple definition of `psci_update_dt';
arch/arm/cpu/armv8/cpu-dt.o:arch/arm/cpu/armv8/cpu-dt.c:14: first defined here
2022-02-25T15:26:42.0521147Z +make[1]: *** [Makefile:1801: u-boot] Error 1
2022-02-25T15:26:42.0521728Z +make: *** [Makefile:177: sub-make] Error 2
Regards
Priyanka
Re: [PATCH] gpio: slg7xl45106: Add support for slg7xl45106 i2c gpo expander
Hello Michal, On 23.02.22 16:21, Michal Simek wrote: > From: T Karthik Reddy > > slg7xl45106 is i2c based 8-bit gpo expander, gpo pins are set and get by > writing and reading corresponding gpo bit value into its data register. > > Signed-off-by: T Karthik Reddy > Signed-off-by: Michal Simek > --- > > MAINTAINERS | 1 + > drivers/gpio/Kconfig| 8 +++ > drivers/gpio/Makefile | 1 + > drivers/gpio/gpio_slg7xl45106.c | 115 > 4 files changed, 125 insertions(+) > create mode 100644 drivers/gpio/gpio_slg7xl45106.c Reviewed-by: Heiko Schocher Nitpick only, fix typo in subject s/gpo/gpio bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
[PATCH v2 4/4] configs: am64x_evm_r5_defconfig: Add support for ESM
Enable ESM driver for AM64x R5 SPL/u-boot builds. Signed-off-by: Hari Nagalla --- configs/am64x_evm_r5_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/am64x_evm_r5_defconfig b/configs/am64x_evm_r5_defconfig index 61138dd1a9..e29e99c2d1 100644 --- a/configs/am64x_evm_r5_defconfig +++ b/configs/am64x_evm_r5_defconfig @@ -103,6 +103,7 @@ CONFIG_DM_I2C=y CONFIG_SYS_I2C_OMAP24XX=y CONFIG_DM_MAILBOX=y CONFIG_K3_SEC_PROXY=y +CONFIG_ESM_K3=y CONFIG_SPL_MISC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ADMA=y -- 2.17.1
[PATCH v2 2/4] arm: dts: k3-am64: Add support for ESM device nodes
Enable access to ESM0 configuration space and add Main ESM0 and MCU ESM
nodes to the AM64 device tree.
Signed-off-by: Hari Nagalla
---
arch/arm/dts/k3-am64.dtsi| 1 +
arch/arm/dts/k3-am642-r5-evm.dts | 19 +++
arch/arm/dts/k3-am642-r5-sk.dts | 19 +++
3 files changed, 39 insertions(+)
diff --git a/arch/arm/dts/k3-am64.dtsi b/arch/arm/dts/k3-am64.dtsi
index de6805b0c7..7aa94d5a6e 100644
--- a/arch/arm/dts/k3-am64.dtsi
+++ b/arch/arm/dts/k3-am64.dtsi
@@ -64,6 +64,7 @@
#address-cells = <2>;
#size-cells = <2>;
ranges = <0x00 0x000f4000 0x00 0x000f4000 0x00 0x02d0>, /*
PINCTRL */
+<0x00 0x0042 0x00 0x0042 0x00 0x1000>, /*
ESM0 */
<0x00 0x0060 0x00 0x0060 0x00 0x1100>, /*
GPIO */
<0x00 0x00a4 0x00 0x00a4 0x00 0x0800>, /*
Timesync router */
<0x00 0x0100 0x00 0x0100 0x00 0x02330400>, /*
First peripheral window */
diff --git a/arch/arm/dts/k3-am642-r5-evm.dts b/arch/arm/dts/k3-am642-r5-evm.dts
index cc48fd4cb6..3ea6471e94 100644
--- a/arch/arm/dts/k3-am642-r5-evm.dts
+++ b/arch/arm/dts/k3-am642-r5-evm.dts
@@ -82,6 +82,25 @@
};
};
+_main {
+ main_esm: esm@42 {
+ compatible = "ti,j721e-esm";
+ reg = <0x0 0x42 0x0 0x1000>;
+ ti,esm-pins = <160>, <161>;
+ u-boot,dm-spl;
+ };
+};
+
+_mcu {
+ u-boot,dm-spl;
+ mcu_esm: esm@410 {
+ compatible = "ti,j721e-esm";
+ reg = <0x0 0x410 0x0 0x1000>;
+ ti,esm-pins = <0>, <1>;
+ u-boot,dm-spl;
+ };
+};
+
_pmx0 {
u-boot,dm-spl;
main_uart0_pins_default: main-uart0-pins-default {
diff --git a/arch/arm/dts/k3-am642-r5-sk.dts b/arch/arm/dts/k3-am642-r5-sk.dts
index 7d1cb85615..1f96e3fcac 100644
--- a/arch/arm/dts/k3-am642-r5-sk.dts
+++ b/arch/arm/dts/k3-am642-r5-sk.dts
@@ -75,6 +75,25 @@
};
};
+_main {
+ main_esm: esm@42 {
+ compatible = "ti,j721e-esm";
+ reg = <0x0 0x42 0x0 0x1000>;
+ ti,esm-pins = <160>, <161>;
+ u-boot,dm-spl;
+ };
+};
+
+_mcu {
+ u-boot,dm-spl;
+ mcu_esm: esm@410 {
+ compatible = "ti,j721e-esm";
+ reg = <0x0 0x410 0x0 0x1000>;
+ ti,esm-pins = <0>, <1>;
+ u-boot,dm-spl;
+ };
+};
+
_pmx0 {
u-boot,dm-spl;
main_uart0_pins_default: main-uart0-pins-default {
--
2.17.1
[PATCH v2 3/4] arch: arm: mach-k3: am642_init: Probe ESM nodes
On AM64x devices, it is possible to route Main ESM0 error events to MCU
ESM. MCU ESM high error output can trigger the reset logic to reset the
device. So, for these devices we expect two ESM device nodes in the
device tree, one for Main ESM and the another MCU ESM in the device tree.
When these ESM device nodes are properly configired it is possible to
route the Main RTI0 WWDT output to the MCU ESM high ouput through Main
ESM and trigger a device reset when
CTRLMMR_MCU_RST_CTRL:MCU_ESM_ERROR_RESET_EN_Z is set to '0'.
On K3 AM64x devices, the R5 SPL u-boot handles the ESM device node
configurations.
Signed-off-by: Hari Nagalla
---
arch/arm/mach-k3/am642_init.c | 29 +
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-k3/am642_init.c b/arch/arm/mach-k3/am642_init.c
index 543dea02bc..f171c1e254 100644
--- a/arch/arm/mach-k3/am642_init.c
+++ b/arch/arm/mach-k3/am642_init.c
@@ -24,12 +24,22 @@
#include
#if defined(CONFIG_SPL_BUILD)
+#define MCU_CTRL_MMR0_BASE 0x0450
+#define CTRLMMR_MCU_RST_CTRL 0x04518170
static void ctrl_mmr_unlock(void)
{
/* Unlock all PADCFG_MMR1 module registers */
mmr_unlock(PADCFG_MMR1_BASE, 1);
+ /* Unlock all MCU_CTRL_MMR0 module registers */
+ mmr_unlock(MCU_CTRL_MMR0_BASE, 0);
+ mmr_unlock(MCU_CTRL_MMR0_BASE, 1);
+ mmr_unlock(MCU_CTRL_MMR0_BASE, 2);
+ mmr_unlock(MCU_CTRL_MMR0_BASE, 3);
+ mmr_unlock(MCU_CTRL_MMR0_BASE, 4);
+ mmr_unlock(MCU_CTRL_MMR0_BASE, 6);
+
/* Unlock all CTRL_MMR0 module registers */
mmr_unlock(CTRL_MMR0_BASE, 0);
mmr_unlock(CTRL_MMR0_BASE, 1);
@@ -37,9 +47,6 @@ static void ctrl_mmr_unlock(void)
mmr_unlock(CTRL_MMR0_BASE, 3);
mmr_unlock(CTRL_MMR0_BASE, 5);
mmr_unlock(CTRL_MMR0_BASE, 6);
-
- /* Unlock all MCU_PADCFG_MMR1 module registers */
- mmr_unlock(MCU_PADCFG_MMR1_BASE, 1);
}
/*
@@ -144,7 +151,7 @@ int fdtdec_board_setup(const void *fdt_blob)
void board_init_f(ulong dummy)
{
-#if defined(CONFIG_K3_LOAD_SYSFW) || defined(CONFIG_K3_AM64_DDRSS)
+#if defined(CONFIG_K3_LOAD_SYSFW) || defined(CONFIG_K3_AM64_DDRSS) ||
defined(CONFIG_ESM_K3)
struct udevice *dev;
int ret;
#endif
@@ -194,6 +201,20 @@ void board_init_f(ulong dummy)
/* Output System Firmware version info */
k3_sysfw_print_ver();
+#if defined(CONFIG_ESM_K3)
+ /* Probe/configure ESM0 */
+ ret = uclass_get_device_by_name(UCLASS_MISC, "esm@42", );
+ if (ret)
+ printf("esm main init failed: %d\n", ret);
+
+ /* Probe/configure MCUESM */
+ ret = uclass_get_device_by_name(UCLASS_MISC, "esm@410", );
+ if (ret)
+ printf("esm mcu init failed: %d\n", ret);
+
+ enable_mcu_esm_reset();
+#endif
+
#if defined(CONFIG_K3_AM64_DDRSS)
ret = uclass_get_device(UCLASS_RAM, 0, );
if (ret)
--
2.17.1
[PATCH v2 1/4] misc: k3_esm: Add functionality to set and route error events within K3SoC
Add functionality to enable, set priority to the input events and to
route to MCU ESM. On AM64x/AM62x devices, it is possible to route Main
ESM0 error events to MCU ESM. When these error events are routed to MCU
ESM high output, it can trigger the reset logic to reset the device,
when CTRLMMR_MCU_RST_CTRL:MCU_ESM_ERROR_RESET_EN_Z is set to '0'.
K3 based J7 devices (ex: J721e) also have ESM modules, and the changes
to the driver does not impact those devices.
Signed-off-by: Hari Nagalla
---
drivers/misc/k3_esm.c | 53 ---
1 file changed, 50 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/k3_esm.c b/drivers/misc/k3_esm.c
index cc2a23dd66..41faeb3d85 100644
--- a/drivers/misc/k3_esm.c
+++ b/drivers/misc/k3_esm.c
@@ -16,17 +16,57 @@
#define ESM_SFT_RST0x0c
#define ESM_SFT_RST_KEY0x0f
+#define ESM_EN 0x08
+#define ESM_EN_KEY 0x0f
#define ESM_STS(i) (0x404 + (i) / 32 * 0x20)
+#define ESM_STS_MASK(i)(1 << ((i) % 32))
#define ESM_PIN_EN_SET_OFFSET(i) (0x414 + (i) / 32 * 0x20)
-#define ESM_PIN_MASK(i)BIT((i) & 0x1f)
+#define ESM_PIN_MASK(i)(1 << ((i) % 32))
+#define ESM_INTR_EN_SET_OFFSET(i) (0x408 + (i) / 32 * 0x20)
+#define ESM_INTR_MASK(i) (1 << ((i) % 32))
+#define ESM_INTR_PRIO_SET_OFFSET(i)(0x410 + (i) / 32 * 0x20)
+#define ESM_INTR_PRIO_MASK(i) (1 << ((i) % 32))
static void esm_pin_enable(void __iomem *base, int pin)
{
+ u32 value;
+
+ value = readl(base + ESM_PIN_EN_SET_OFFSET(pin));
+ value |= ESM_PIN_MASK(pin);
/* Enable event */
- writel(ESM_PIN_MASK(pin), base + ESM_PIN_EN_SET_OFFSET(pin));
+ writel(value, base + ESM_PIN_EN_SET_OFFSET(pin));
+}
+
+static void esm_intr_enable(void __iomem *base, int pin)
+{
+ u32 value;
+
+ value = readl(base + ESM_INTR_EN_SET_OFFSET(pin));
+ value |= ESM_INTR_MASK(pin);
+ /* Enable Interrupt event */
+ writel(value, base + ESM_INTR_EN_SET_OFFSET(pin));
+}
+
+static void esm_intr_prio_set(void __iomem *base, int pin)
+{
+ u32 value;
+
+ value = readl(base + ESM_INTR_PRIO_SET_OFFSET(pin));
+ value |= ESM_INTR_PRIO_MASK(pin);
+ /* Set to priority */
+ writel(value, base + ESM_INTR_PRIO_SET_OFFSET(pin));
}
+static void esm_clear_raw_status(void __iomem *base, int pin)
+{
+ u32 value;
+
+ value = readl(base + ESM_STS(pin));
+ value |= ESM_STS_MASK(pin);
+ /* Clear Event status */
+ writel(value, base + ESM_STS(pin));
+}
/**
* k3_esm_probe: configures ESM based on DT data
*
@@ -67,8 +107,15 @@ static int k3_esm_probe(struct udevice *dev)
/* Clear any pending events */
writel(ESM_SFT_RST_KEY, base + ESM_SFT_RST);
- for (i = 0; i < num_pins; i++)
+ for (i = 0; i < num_pins; i++) {
+ esm_intr_prio_set(base, pins[i]);
+ esm_clear_raw_status(base, pins[i]);
esm_pin_enable(base, pins[i]);
+ esm_intr_enable(base, pins[i]);
+ }
+
+ /* Enable ESM */
+ writel(ESM_EN_KEY, base + ESM_EN);
free_pins:
kfree(pins);
--
2.17.1
[PATCH v2 0/4] Add ESM driver support for AM64x R5 SPL/U-boot
AM64x devices have a main ESM and a MCU ESM. The ESM driver enables routing of the error events from various sources to different processors or to reset hardware logic. Only the MCU ESM's high output can trigger reset logic. The main RTI0 WWDT output can be routed to the MCU highoutput to trigger reset through the main ESM. For this reset to occur CTRLMMR_MCU_RST_CTRL:MCU_ESM_ERROR_RESET_EN_Z is set to '0'. AM64x Technical Reference Manual - https://www.ti.com/lit/pdf/spruim2 Hari Nagalla (4): misc: k3_esm: Add functionality to set and route error events within K3SoC arm: dts: k3-am64: Add support for ESM device nodes arch: arm: mach-k3: am642_init: Probe ESM nodes configs: am64x_evm_r5_defconfig: Add support for ESM arch/arm/dts/k3-am64.dtsi| 1 + arch/arm/dts/k3-am642-r5-evm.dts | 19 arch/arm/dts/k3-am642-r5-sk.dts | 19 arch/arm/mach-k3/am642_init.c| 29 ++--- configs/am64x_evm_r5_defconfig | 1 + drivers/misc/k3_esm.c| 53 ++-- 6 files changed, 115 insertions(+), 7 deletions(-) -- 2.17.1
Re: [PATCH v4 2/2] efi_loader: Reset system after CapsuleUpdate on disk
Hi Simon,
2022年2月27日(日) 3:37 Simon Glass :
>
> Hi Masami,
>
> On Thu, 3 Feb 2022 at 02:23, Masami Hiramatsu
> wrote:
> >
> > Add a cold reset soon after processing capsule update on disk.
> > This is required in UEFI specification 2.9 Section 8.5.5
> > "Delivery of Capsules via file on Mass Storage device" as;
> >
> > In all cases that a capsule is identified for processing the system is
> > restarted after capsule processing is completed.
> >
> > This also reports the result of each capsule update so that the user can
> > notice that the capsule update has been succeeded or not from console log.
> >
> > Signed-off-by: Masami Hiramatsu
> > ---
> > Changes in v4:
> > - Do not use sysreset because that is a warm reset.
>
> I don't get that.
>
> You should use sysreset and the SYSRESET_COLD type.
Thanks, yeah, I found that parameter.
Let's fix that.
Thank you,
>
> > - Fix patch description.
> > ---
> > lib/efi_loader/efi_capsule.c | 18 --
> > 1 file changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
> > index 1ec7ea29ff..20d9490dbd 100644
> > --- a/lib/efi_loader/efi_capsule.c
> > +++ b/lib/efi_loader/efi_capsule.c
> > @@ -14,6 +14,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -1120,8 +1121,11 @@ efi_status_t efi_launch_capsules(void)
> > if (ret == EFI_SUCCESS) {
> > ret = efi_capsule_update_firmware(capsule);
> > if (ret != EFI_SUCCESS)
> > - log_err("Applying capsule %ls failed\n",
> > + log_err("Applying capsule %ls failed.\n",
> > files[i]);
> > + else
> > + log_info("Applying capsule %ls
> > succeeded.\n",
> > +files[i]);
> >
> > /* create Capsule */
> > set_capsule_result(index, capsule, ret);
> > @@ -1142,6 +1146,16 @@ efi_status_t efi_launch_capsules(void)
> > free(files[i]);
> > free(files);
> >
> > - return ret;
> > + /*
> > +* UEFI spec requires to reset system after complete processing
> > capsule
> > +* update on the storage.
> > +*/
> > + log_info("Reboot after firmware update");
> > + /* Cold reset is required for loading the new firmware. */
> > + do_reset(NULL, 0, 0, NULL);
>
> No! This should use sysreset.
>
> > + hang();
> > + /* not reach here */
> > +
> > + return 0;
> > }
> > #endif /* CONFIG_EFI_CAPSULE_ON_DISK */
> >
>
> Regards,
> Simon
--
Masami Hiramatsu
Re: [PATCH] image: Control FIT signature verification at runtime
On Tue, 15 Feb 2022, at 13:55, Andrew Jeffery wrote: > On Tue, 15 Feb 2022, at 13:42, Dhananjay Phadke wrote: >> On 2/14/2022 3:13 PM, Patrick Williams wrote: >>> On Mon, Feb 14, 2022 at 11:14:53AM -0800, Dhananjay Phadke wrote: There's a key-requirement policy already implemented [1]. [1] https://lore.kernel.org/u-boot/cover.1597643014.git.thir...@linux.microsoft.com/ Board code can patch "required-policy" = none at runtime based appropriate logic. >> >> [...] >> >>> >>> Isn't this jumper proposal just like the TCG Physical Presence requirements? >>> This is a software implementation and requires a particular hardware design >>> for >>> it to be done right, but it seems to be along the same lines. >> >> I'm supporting idea of having control on FIT verification, just pointed >> that it maybe done by board code by just patching U-Boot control FDT, >> either the "required-policy" property at /signature or "required" >> property in individual key nodes. > > This might separate the logic out in a way that's acceptable to Alex. > > Let me poke at it. I've thought about this some more and adding support for `required-mode = "none";` or similar seems like a massive footgun given that (as I understand it) the FIT image as a whole isn't verified. Only supporting "all" or "any" seems okay because some verification must succeed in the context of the keys available in the current stage. After some internal discussion this effort has been set aside so I'm not going to pursue it further for the moment. I don't think it's easy to proceed anyway without feedback from Alex. Andrew
Re: IMX8MM 4GiB boundary issue
On 2/26/22 14:30, Mark Kettenis wrote: Date: Fri, 25 Feb 2022 14:50:59 +0100 From: Marek Vasut On 2/25/22 12:37, Mark Kettenis wrote: From: Fabio Estevam Date: Fri, 25 Feb 2022 08:12:58 -0300 Hi Tim, On Thu, Feb 24, 2022 at 6:46 PM Tim Harvey wrote: Fabio, No, that commit is 'not' in v2021.07. Please test with master and you should see that go away. Yes, you are right. Regardless, Marek's suggestion is the right fix if you can manage that... we really don't want to limit 4GB boards to 3GB. I was hoping NXP would step up and address the peripheral drivers for this. Agreed, thanks! But isn't the problem here that (some of) the hardware peripherals simply can't address memory above the 4GB boundary? OS kernels can work around such limitations by using an IOMMU (if provided by the hardware) or by using bounce buffers (swiotlb in Linux speak). Right, see bounce_buffer in U-Boot. The traditional way to deal with this in u-boot is to make sure that u-boot only uses memory below the 4GB boundary by implementing board_get_usable_ram_top() and making sure that all the addresses in the u-boot environment are in "low" memory. The board_get_usable_ram_top() purpose was something else entirely at the beginning, it only started being misused to work around driver issues instead of fixing them later and that is utterly wrong. For EFI support there is the CONFIG_EFI_LOADER_BOUNCE_BUFFER option, which should be set to "y" in this case. There is generic bounce buffer for drivers, see common/bouncebuf.c . That implementation only seems to exist to handle misaligned buffers. As far as I can tell it doesn't make any attempt to make sure it allocates memory in a specific address range. Although I suppose that using memalign() means it allocates from the heap and boards have some control over where the heap lives. But doesn't that rely on board_get_usable_ram_top()? Possibly, I suspect someone will have to take a deeper look into this and maybe implement some better bounce buffer. I'm following this discussion since I'm trying to work out the best way to add PCIe support for the Apple M1 "boards". There the issue isn't so much that the hardware peripherals can't address memory above the 4GB boundary (there is no memory below the 4GB boundary!). But the IOMMU only has a 4GB iova window which means that I cannot have the IOMMU map all physical memory 1:1. So I either have to make sure that U-Boot (including the efi_loader subsystem) only uses memory in a particular 4GB range. Or I have to add an interface to have drivers explictly map memory through the IOMMU (and have them unmap when they're done). Such an interface would look somewhat similar to the bounce buffer interface. Maybe now is the right time to implement such interface ? Isn't that what linux uses swiotlb for ?
Re: [PATCH] include: configs: *imx8*: remove IMX_FEC_BASE
On Fri, 2022-02-18 at 21:48 +0100, Heiko Thiery wrote: > The IMX_FEC_BASE value is not used when CONFIG_DM_ETH is configured. So this > value can be removed. > > Signed-off-by: Heiko Thiery > --- > include/configs/imx8mm-cl-iot-gate.h | 2 -- > include/configs/imx8mm_beacon.h | 1 - > include/configs/imx8mm_evk.h | 2 -- > include/configs/imx8mm_venice.h | 1 - Looks good. However, Tim already did this for the venice [1] which is why it no longer applies cleanly. With that fixed. Tested-by: Marcel Ziswiler [1] https://patchwork.ozlabs.org/project/uboot/patch/20220211185206.9931-1-thar...@gateworks.com/ > include/configs/imx8mn_beacon.h | 1 - > include/configs/imx8mq_evk.h | 2 -- > include/configs/imx8mq_phanbell.h | 2 -- > include/configs/imx8ulp_evk.h | 2 -- > include/configs/kontron_pitx_imx8m.h | 1 - > include/configs/pico-imx8mq.h | 2 -- > include/configs/verdin-imx8mm.h | 1 - > 11 files changed, 17 deletions(-) > > diff --git a/include/configs/imx8mm-cl-iot-gate.h > b/include/configs/imx8mm-cl-iot-gate.h > index 7e6be6050c..4413bdcc58 100644 > --- a/include/configs/imx8mm-cl-iot-gate.h > +++ b/include/configs/imx8mm-cl-iot-gate.h > @@ -157,8 +157,6 @@ > #define CONFIG_FEC_MXC_PHYADDR 0 > #define FEC_QUIRK_ENET_MAC > > -#define IMX_FEC_BASE 0x30BE > - > /* USB Configs */ > #define CONFIG_EHCI_HCD_INIT_AFTER_RESET > #define CONFIG_MXC_USB_PORTSC (PORT_PTS_UTMI | PORT_PTS_PTW) > diff --git a/include/configs/imx8mm_beacon.h b/include/configs/imx8mm_beacon.h > index 77f062474d..029e8c4c7f 100644 > --- a/include/configs/imx8mm_beacon.h > +++ b/include/configs/imx8mm_beacon.h > @@ -109,6 +109,5 @@ > #define CONFIG_FEC_XCV_TYPE RGMII > #define CONFIG_FEC_MXC_PHYADDR 0 > #define FEC_QUIRK_ENET_MAC > -#define IMX_FEC_BASE 0x30BE > > #endif > diff --git a/include/configs/imx8mm_evk.h b/include/configs/imx8mm_evk.h > index c7022ef0f7..771eaf80d5 100644 > --- a/include/configs/imx8mm_evk.h > +++ b/include/configs/imx8mm_evk.h > @@ -89,6 +89,4 @@ > #define CONFIG_FEC_MXC_PHYADDR 0 > #define FEC_QUIRK_ENET_MAC > > -#define IMX_FEC_BASE 0x30BE > - > #endif > diff --git a/include/configs/imx8mm_venice.h b/include/configs/imx8mm_venice.h > index 7ab11cc8fb..a828f48d2e 100644 > --- a/include/configs/imx8mm_venice.h > +++ b/include/configs/imx8mm_venice.h > @@ -109,6 +109,5 @@ > #define CONFIG_FEC_XCV_TYPE RGMII > #define CONFIG_FEC_MXC_PHYADDR 0 > #define FEC_QUIRK_ENET_MAC > -#define IMX_FEC_BASE 0x30BE > > #endif > diff --git a/include/configs/imx8mn_beacon.h b/include/configs/imx8mn_beacon.h > index e2e322bb4d..e54b87c76a 100644 > --- a/include/configs/imx8mn_beacon.h > +++ b/include/configs/imx8mn_beacon.h > @@ -126,7 +126,6 @@ > #define CONFIG_FEC_XCV_TYPERGMII > #define CONFIG_FEC_MXC_PHYADDR 0 > #define FEC_QUIRK_ENET_MAC > -#define IMX_FEC_BASE 0x30BE > #endif /* CONFIG_FEC_MXC */ > > #endif > diff --git a/include/configs/imx8mq_evk.h b/include/configs/imx8mq_evk.h > index 4aaed3ae7d..1a472588ac 100644 > --- a/include/configs/imx8mq_evk.h > +++ b/include/configs/imx8mq_evk.h > @@ -43,8 +43,6 @@ > #define CONFIG_FEC_XCV_TYPE RGMII > #define CONFIG_FEC_MXC_PHYADDR 0 > #define FEC_QUIRK_ENET_MAC > - > -#define IMX_FEC_BASE 0x30BE > #endif > > #ifndef CONFIG_SPL_BUILD > diff --git a/include/configs/imx8mq_phanbell.h > b/include/configs/imx8mq_phanbell.h > index 16a2c2cf9d..1e1c186aed 100644 > --- a/include/configs/imx8mq_phanbell.h > +++ b/include/configs/imx8mq_phanbell.h > @@ -37,8 +37,6 @@ > #define CONFIG_FEC_XCV_TYPE RGMII > #define CONFIG_FEC_MXC_PHYADDR 0 > #define FEC_QUIRK_ENET_MAC > - > -#define IMX_FEC_BASE 0x30BE > #endif > > #define CONFIG_MFG_ENV_SETTINGS \ > diff --git a/include/configs/imx8ulp_evk.h b/include/configs/imx8ulp_evk.h > index 7da6802aa5..666306c028 100644 > --- a/include/configs/imx8ulp_evk.h > +++ b/include/configs/imx8ulp_evk.h > @@ -34,8 +34,6 @@ > > #define CONFIG_FEC_XCV_TYPERMII > #define CONFIG_FEC_MXC_PHYADDR 1 > - > -#define IMX_FEC_BASE 0x2995 > #endif > > #ifdef CONFIG_DISTRO_DEFAULTS > diff --git a/include/configs/kontron_pitx_imx8m.h > b/include/configs/kontron_pitx_imx8m.h > index 0f96b905ab..6f426cb08c 100644 > --- a/include/configs/kontron_pitx_imx8m.h > +++ b/include/configs/kontron_pitx_imx8m.h > @@ -43,7 +43,6 @@ > #define CONFIG_FEC_MXC_PHYADDR 0 > #define FEC_QUIRK_ENET_MAC > > -#define IMX_FEC_BASE 0x30BE > #define PHY_ANEG_TIMEOUT 2 > > #endif > diff --git a/include/configs/pico-imx8mq.h b/include/configs/pico-imx8mq.h > index 7bfa79059a..08204779d8 100644 > ---
Re: [PATCH] ARM: dts: net: dwc_eth_qos: Fix i.MX8MP compatible string
On Sat, 2022-02-26 at 04:36 +0100, Marek Vasut wrote:
> The correct compatible string for i.MX8MP variant of DWC EQoS MAC
> is "nxp,imx8mp-dwmac-eqos", use it. Drop the two current users of
> the current wrong compatible string to avoid breaking them.
Thanks, Marek, for fixing this.
> Signed-off-by: Marek Vasut
Tested-by: Marcel Ziswiler
> Cc: Fabio Estevam
> Cc: Marcel Ziswiler
> Cc: Peng Fan
> Cc: Stefano Babic
> ---
> arch/arm/dts/imx8mp-evk-u-boot.dtsi | 1 -
> arch/arm/dts/imx8mp-verdin-u-boot.dtsi | 1 -
> drivers/net/dwc_eth_qos.c | 2 +-
> 3 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> index ab849ebaaca..7c3789273da 100644
> --- a/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> @@ -112,7 +112,6 @@
> };
>
> {
> - compatible = "fsl,imx-eqos";
> /delete-property/ assigned-clocks;
> /delete-property/ assigned-clock-parents;
> /delete-property/ assigned-clock-rates;
> diff --git a/arch/arm/dts/imx8mp-verdin-u-boot.dtsi
> b/arch/arm/dts/imx8mp-verdin-u-boot.dtsi
> index a57ad45ed63..26140a79ebe 100644
> --- a/arch/arm/dts/imx8mp-verdin-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mp-verdin-u-boot.dtsi
> @@ -30,7 +30,6 @@
> };
>
> {
> - compatible = "fsl,imx-eqos";
> /delete-property/ assigned-clocks;
> /delete-property/ assigned-clock-parents;
> /delete-property/ assigned-clock-rates;
> diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
> index 22dad5b2030..ea0c2cfa5b2 100644
> --- a/drivers/net/dwc_eth_qos.c
> +++ b/drivers/net/dwc_eth_qos.c
> @@ -2032,7 +2032,7 @@ static const struct udevice_id eqos_ids[] = {
> #endif
> #if IS_ENABLED(CONFIG_DWC_ETH_QOS_IMX)
> {
> - .compatible = "fsl,imx-eqos",
> + .compatible = "nxp,imx8mp-dwmac-eqos",
> .data = (ulong)_imx_config
> },
> #endif
Re: [PATCH v5 3/4] test/py: Handle expected reboot while booting sandbox
Hi Tom, On Sun, 27 Feb 2022 at 13:58, Tom Rini wrote: > > On Sun, Feb 27, 2022 at 12:11:01PM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Sun, 27 Feb 2022 at 11:14, Tom Rini wrote: > > > > > > On Sun, Feb 27, 2022 at 08:39:30AM -0700, Simon Glass wrote: > > > > Hi Heinrich, > > > > > > > > On Sun, 27 Feb 2022 at 01:22, Heinrich Schuchardt > > > > wrote: > > > > > > > > > > On 2/26/22 19:37, Simon Glass wrote: > > > > > > Hi Masami, > > > > > > > > > > > > On Tue, 15 Feb 2022 at 23:16, Masami Hiramatsu > > > > > > wrote: > > > > > >> > > > > > >> Add expected_reset optional argument to > > > > > >> ConsoleBase::ensure_spawned(), > > > > > >> ConsoleBase::restart_uboot() and > > > > > >> ConsoleSandbox::restart_uboot_with_flags() > > > > > >> so that it can handle a reset while the 1st boot process after main > > > > > >> boot logo before prompt correctly. > > > > > >> > > > > > >> Signed-off-by: Masami Hiramatsu > > > > > >> --- > > > > > >> Changes in v5: > > > > > >>- Rename parameter to expect_reset and update the description > > > > > >> to clarify > > > > > >> the reset will happen between main boot and the command > > > > > >> prompt. > > > > > >> --- > > > > > >> test/py/u_boot_console_base.py| 48 > > > > > >> ++--- > > > > > >> test/py/u_boot_console_sandbox.py |7 - > > > > > >> 2 files changed, 33 insertions(+), 22 deletions(-) > > > > > >> > > > > > > > > > > > > Didn't I already comment on this patch? Why did it come back? > > > > > > > > > > Dear Simon, > > > > > > > > > > The discussion is in > > > > > https://patchwork.ozlabs.org/project/uboot/patch/164491595065.536855.9457820061065514578.stgit@localhost/ > > > > > > > > > > You suggested: "We have a means to avoid actually doing the reset, see > > > > > the reset driver." > > > > > > > > > > We need a real reset on the sandbox and no fake reset as already said > > > > > in > > > > > the referenced thread. > > > > > > > > Why? > > > > > > > > The fake reset is there for use by tests. We don't need this load of > > > > Python code at all for sandbox. We should worry about it later. > > > > > > Well, isn't this going to make the tests more sandbox-centric then, and > > > then need changes later to be able to test on real hardware? > > > > Yes, but it keeps the sandbox case simple. At present the sandbox > > tests can run within U-Boot (see the 'ut' command) and I very much > > want to keep it that way. That is, after all, why I wrote the reset > > driver. > > > > While tests on real hardware have value, I hope that all logic bugs > > are found on sandbox. > > Yes, it's important to test the code in sandbox before testing it on > hardware, to avoid "obvious" oops-it-broke changes, it's still very > important to be able to easily run this on real hardware. Ideally, I > hope to see updates to the pytest hook repository to flash the hardware > via capsule, as well as running a more formal pytest on hardware. To Can you be specific about what bugs you are trying to catch in that case? I am conscious of the nightmare that is Zephyr's thousands of QEMU-based tests that take 20 minutes to run in parallel on a 64-core machine, so I'd would like to make sure that real bugs are found in unit tests where possible. > that end, is it not most important to make sandbox look like a real > hardware platform, rather than adapt the test to know about special > sandbox things? Or am I missing something here and the test shouldn't The key thing is that sandbox runs essentially the same 'code under test' as the real board and that we can quickly verified (using the 'ut xxx' command) that it works. In this case, we want to run the EFI code under sandbox and make sure that it works. > need changes / special handling to support both sandbox and real > hardware, with what you're suggesting? The title of this patch refers to specific hacks in pytest to handle sandbox, doesn't it? So I think this is around the wrong way...that is in fact my objection. It simply should not be done that way, with special code in pytest, or whatever. It should be possible to run 'ut xxx' and have the test run from start to finish, without any outside influence. Sandbox has a sysreset driver, just like any other board. We can make it do whatever we want...see sandbox_sysreset_request(). We do use pytest to set things up beforehand, or to verify that things worked after the run, but we should not need it to even just run a unit test. In particular, it should not be necessary for sandbox to be restarted by an outside influence. Regards, Simon
Re: [PATCH v5 3/4] test/py: Handle expected reboot while booting sandbox
On Sun, Feb 27, 2022 at 12:11:01PM -0700, Simon Glass wrote: > Hi Tom, > > On Sun, 27 Feb 2022 at 11:14, Tom Rini wrote: > > > > On Sun, Feb 27, 2022 at 08:39:30AM -0700, Simon Glass wrote: > > > Hi Heinrich, > > > > > > On Sun, 27 Feb 2022 at 01:22, Heinrich Schuchardt > > > wrote: > > > > > > > > On 2/26/22 19:37, Simon Glass wrote: > > > > > Hi Masami, > > > > > > > > > > On Tue, 15 Feb 2022 at 23:16, Masami Hiramatsu > > > > > wrote: > > > > >> > > > > >> Add expected_reset optional argument to > > > > >> ConsoleBase::ensure_spawned(), > > > > >> ConsoleBase::restart_uboot() and > > > > >> ConsoleSandbox::restart_uboot_with_flags() > > > > >> so that it can handle a reset while the 1st boot process after main > > > > >> boot logo before prompt correctly. > > > > >> > > > > >> Signed-off-by: Masami Hiramatsu > > > > >> --- > > > > >> Changes in v5: > > > > >>- Rename parameter to expect_reset and update the description to > > > > >> clarify > > > > >> the reset will happen between main boot and the command prompt. > > > > >> --- > > > > >> test/py/u_boot_console_base.py| 48 > > > > >> ++--- > > > > >> test/py/u_boot_console_sandbox.py |7 - > > > > >> 2 files changed, 33 insertions(+), 22 deletions(-) > > > > >> > > > > > > > > > > Didn't I already comment on this patch? Why did it come back? > > > > > > > > Dear Simon, > > > > > > > > The discussion is in > > > > https://patchwork.ozlabs.org/project/uboot/patch/164491595065.536855.9457820061065514578.stgit@localhost/ > > > > > > > > You suggested: "We have a means to avoid actually doing the reset, see > > > > the reset driver." > > > > > > > > We need a real reset on the sandbox and no fake reset as already said in > > > > the referenced thread. > > > > > > Why? > > > > > > The fake reset is there for use by tests. We don't need this load of > > > Python code at all for sandbox. We should worry about it later. > > > > Well, isn't this going to make the tests more sandbox-centric then, and > > then need changes later to be able to test on real hardware? > > Yes, but it keeps the sandbox case simple. At present the sandbox > tests can run within U-Boot (see the 'ut' command) and I very much > want to keep it that way. That is, after all, why I wrote the reset > driver. > > While tests on real hardware have value, I hope that all logic bugs > are found on sandbox. Yes, it's important to test the code in sandbox before testing it on hardware, to avoid "obvious" oops-it-broke changes, it's still very important to be able to easily run this on real hardware. Ideally, I hope to see updates to the pytest hook repository to flash the hardware via capsule, as well as running a more formal pytest on hardware. To that end, is it not most important to make sandbox look like a real hardware platform, rather than adapt the test to know about special sandbox things? Or am I missing something here and the test shouldn't need changes / special handling to support both sandbox and real hardware, with what you're suggesting? -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 3/4] test/py: Handle expected reboot while booting sandbox
Hi Heinrich, On Sun, 27 Feb 2022 at 12:51, Simon Glass wrote: > > Hi Heinrich, > > On Sun, 27 Feb 2022 at 12:21, Heinrich Schuchardt wrote: > > > > > > > > Am 27. Februar 2022 20:11:01 MEZ schrieb Simon Glass : > > >Hi Tom, > > > > > >On Sun, 27 Feb 2022 at 11:14, Tom Rini wrote: > > >> > > >> On Sun, Feb 27, 2022 at 08:39:30AM -0700, Simon Glass wrote: > > >> > Hi Heinrich, > > >> > > > >> > On Sun, 27 Feb 2022 at 01:22, Heinrich Schuchardt > > >> > wrote: > > >> > > > > >> > > On 2/26/22 19:37, Simon Glass wrote: > > >> > > > Hi Masami, > > >> > > > > > >> > > > On Tue, 15 Feb 2022 at 23:16, Masami Hiramatsu > > >> > > > wrote: > > >> > > >> > > >> > > >> Add expected_reset optional argument to > > >> > > >> ConsoleBase::ensure_spawned(), > > >> > > >> ConsoleBase::restart_uboot() and > > >> > > >> ConsoleSandbox::restart_uboot_with_flags() > > >> > > >> so that it can handle a reset while the 1st boot process after > > >> > > >> main > > >> > > >> boot logo before prompt correctly. > > >> > > >> > > >> > > >> Signed-off-by: Masami Hiramatsu > > >> > > >> --- > > >> > > >> Changes in v5: > > >> > > >>- Rename parameter to expect_reset and update the description > > >> > > >> to clarify > > >> > > >> the reset will happen between main boot and the command > > >> > > >> prompt. > > >> > > >> --- > > >> > > >> test/py/u_boot_console_base.py| 48 > > >> > > >> ++--- > > >> > > >> test/py/u_boot_console_sandbox.py |7 - > > >> > > >> 2 files changed, 33 insertions(+), 22 deletions(-) > > >> > > >> > > >> > > > > > >> > > > Didn't I already comment on this patch? Why did it come back? > > >> > > > > >> > > Dear Simon, > > >> > > > > >> > > The discussion is in > > >> > > https://patchwork.ozlabs.org/project/uboot/patch/164491595065.536855.9457820061065514578.stgit@localhost/ > > >> > > > > >> > > You suggested: "We have a means to avoid actually doing the reset, > > >> > > see > > >> > > the reset driver." > > >> > > > > >> > > We need a real reset on the sandbox and no fake reset as already > > >> > > said in > > >> > > the referenced thread. > > >> > > > >> > Why? > > >> > > > >> > The fake reset is there for use by tests. We don't need this load of > > >> > Python code at all for sandbox. We should worry about it later. > > >> > > >> Well, isn't this going to make the tests more sandbox-centric then, and > > >> then need changes later to be able to test on real hardware? > > > > > >Yes, but it keeps the sandbox case simple. At present the sandbox > > >tests can run within U-Boot (see the 'ut' command) and I very much > > >want to keep it that way. That is, after all, why I wrote the reset > > >driver. > > > > > >While tests on real hardware have value, I hope that all logic bugs > > >are found on sandbox. > > > > How does this relate to your thoughts about this patch? > > > > The patch enables testing capsule updates including resets. This does not > > stop running the tests on the sandbox. > > > > Why do you suggest sandbox specific quirks in capsule updates? > > sandbox-specific but in any case I find the tone of that statement > offensive and misleading. I have asked you before to avoid this sort > of thing on the mailing list. Sandbox is what we use for unit tests. > > How is the test run at present on sandbox? My understanding is that > you want sandbox to rely on the pytest framework to work...do I have > that wrong? Also I'd really appreciate it if you could review Takahiro's series and help get it landed. It has been languishing for ages. Regards, Simon
Re: [PATCH v5 3/4] test/py: Handle expected reboot while booting sandbox
Hi Heinrich, On Sun, 27 Feb 2022 at 12:21, Heinrich Schuchardt wrote: > > > > Am 27. Februar 2022 20:11:01 MEZ schrieb Simon Glass : > >Hi Tom, > > > >On Sun, 27 Feb 2022 at 11:14, Tom Rini wrote: > >> > >> On Sun, Feb 27, 2022 at 08:39:30AM -0700, Simon Glass wrote: > >> > Hi Heinrich, > >> > > >> > On Sun, 27 Feb 2022 at 01:22, Heinrich Schuchardt > >> > wrote: > >> > > > >> > > On 2/26/22 19:37, Simon Glass wrote: > >> > > > Hi Masami, > >> > > > > >> > > > On Tue, 15 Feb 2022 at 23:16, Masami Hiramatsu > >> > > > wrote: > >> > > >> > >> > > >> Add expected_reset optional argument to > >> > > >> ConsoleBase::ensure_spawned(), > >> > > >> ConsoleBase::restart_uboot() and > >> > > >> ConsoleSandbox::restart_uboot_with_flags() > >> > > >> so that it can handle a reset while the 1st boot process after main > >> > > >> boot logo before prompt correctly. > >> > > >> > >> > > >> Signed-off-by: Masami Hiramatsu > >> > > >> --- > >> > > >> Changes in v5: > >> > > >>- Rename parameter to expect_reset and update the description to > >> > > >> clarify > >> > > >> the reset will happen between main boot and the command prompt. > >> > > >> --- > >> > > >> test/py/u_boot_console_base.py| 48 > >> > > >> ++--- > >> > > >> test/py/u_boot_console_sandbox.py |7 - > >> > > >> 2 files changed, 33 insertions(+), 22 deletions(-) > >> > > >> > >> > > > > >> > > > Didn't I already comment on this patch? Why did it come back? > >> > > > >> > > Dear Simon, > >> > > > >> > > The discussion is in > >> > > https://patchwork.ozlabs.org/project/uboot/patch/164491595065.536855.9457820061065514578.stgit@localhost/ > >> > > > >> > > You suggested: "We have a means to avoid actually doing the reset, see > >> > > the reset driver." > >> > > > >> > > We need a real reset on the sandbox and no fake reset as already said > >> > > in > >> > > the referenced thread. > >> > > >> > Why? > >> > > >> > The fake reset is there for use by tests. We don't need this load of > >> > Python code at all for sandbox. We should worry about it later. > >> > >> Well, isn't this going to make the tests more sandbox-centric then, and > >> then need changes later to be able to test on real hardware? > > > >Yes, but it keeps the sandbox case simple. At present the sandbox > >tests can run within U-Boot (see the 'ut' command) and I very much > >want to keep it that way. That is, after all, why I wrote the reset > >driver. > > > >While tests on real hardware have value, I hope that all logic bugs > >are found on sandbox. > > How does this relate to your thoughts about this patch? > > The patch enables testing capsule updates including resets. This does not > stop running the tests on the sandbox. > > Why do you suggest sandbox specific quirks in capsule updates? sandbox-specific but in any case I find the tone of that statement offensive and misleading. I have asked you before to avoid this sort of thing on the mailing list. Sandbox is what we use for unit tests. How is the test run at present on sandbox? My understanding is that you want sandbox to rely on the pytest framework to work...do I have that wrong? Regards, Simon
Re: [PATCH 1/7] clk: Make rfree return void
On 2/26/22 1:36 PM, Simon Glass wrote: Hi Sean, On Tue, 1 Feb 2022 at 21:24, Sean Anderson wrote: On 2/1/22 10:59 PM, Simon Glass wrote: Hi Sean, On Tue, 1 Feb 2022 at 07:49, Sean Anderson wrote: On 1/27/22 4:35 PM, Simon Glass wrote: Hi Sean, On Thu, 27 Jan 2022 at 08:43, Sean Anderson wrote: On 1/27/22 10:05 AM, Simon Glass wrote: Hi Sean, On Sat, 15 Jan 2022 at 15:25, Sean Anderson wrote: When freeing a clock there is not much we can do if there is an error, and most callers do not actually check the return value. Even e.g. checking to make sure that clk->id is valid should have been done in request() in the first place (unless someone is messing with the driver behind our back). Just return void and don't bother returning an error. Signed-off-by: Sean Anderson --- drivers/clk/clk-uclass.c | 7 +++ drivers/clk/clk_sandbox.c | 6 +++--- include/clk-uclass.h | 8 +++- 3 files changed, 9 insertions(+), 12 deletions(-) We have the same thing in other places too, but I am a little worried about removing error checking. We try to avoid checking arguments too much in U-Boot, due to code-size concerns, so I suppose I agree that an invalid clk should be caught by a debug assertion rather than a full check. But with driver model we have generally added an error return to every uclass method, for consistency and to permit returning error information if needed. Regards, Simon So there are a few reasons why I don't think a return value is useful here. To illustrate this, consider a typical user of the clock API: struct clk a, b; ret = clk_get_by_name(dev, "a", ); if (ret) return ret; ret = clk_get_by_name(dev, "b", ); if (ret) goto free_a; ret = clk_set_rate(, 500); if (ret) goto free_b; ret = clk_enable(); free_b: clk_free(); free_a: clk_free(); return ret; - Because a and b are "thick pointers" they do not need any cleanup to free their own resources. The only cleanup might be if the clock driver has allocated something in clk_request (more on this below) - By the time we call clk_free, the mutable portions of the function have already completed. In effect, the function has succeeded, regardless of whether clk_free fails. Additionally, we cannot take any action if it fails, since we still have to free both clocks. - clk_free occurs during the error path of the function. Even if it errored, we do not want to override the existing error from one of the functions doing "real" work. The last thing is that no clock driver actually does anything in rfree. The only driver with this function is the sandbox driver. I would like to remove the function altogether. As I understand it, the existing API is inspired by the reset drivers, so I would like to review its usage in the reset subsystem before removing it for the clock subsystem. I also want to make some changes to how rates and enables/disables are calculated which might provide a case for rfree. But once that is complete I think there will be no users still. What does this all look like in Linux? Their equivalent (clk_put) returns void, and generally so do most other cleanup functions, since .device_remove also returns void. We really cannot ignore errors from device_remove(). Once you are at device_remove, all the users are gone and it's up to the device to clean up after itself. And often there is nothing we can do once remove is called. As you yourself say in device_remove, /* We can't put the children back */ Well this assumes that device_remove() is actually removing the device, not just disabling DMA, etc. Really the only sensible thing is to print an error and continue booting if possible. And of course no clock drivers actually use this function anyway, nor do (all but 5) users check it. Anyway I think what you say about the 'thick pointer' makes sense. But my expectation was that removing a clock might turn off a clock above it in the tree, for example. No, this just frees resources (as is documented). If you want to turn off a clock, you have to call clk_disable. In fact, a very common use case is just like the example above, where the consmer frees the clock after enabling it. (This is also why clk->enable_count/rate are basically useless for anything other than CCF clocks) How about a clock provided by an audio codec on an I2C bus? Should clk_free() do anything in that case? I assume not. I think the compelling part of your argument is that it is a 'think pointer' and disable does nothing. So can you update clk_rfree() etc. to document what is allowed to be done in that function? The ideal case would be if you wanted to allocate some per-struct-clk data. Then, the correct place to free it would be rfree. But no one does this, and if
Re: [PATCH v5 3/4] test/py: Handle expected reboot while booting sandbox
Am 27. Februar 2022 20:11:01 MEZ schrieb Simon Glass : >Hi Tom, > >On Sun, 27 Feb 2022 at 11:14, Tom Rini wrote: >> >> On Sun, Feb 27, 2022 at 08:39:30AM -0700, Simon Glass wrote: >> > Hi Heinrich, >> > >> > On Sun, 27 Feb 2022 at 01:22, Heinrich Schuchardt >> > wrote: >> > > >> > > On 2/26/22 19:37, Simon Glass wrote: >> > > > Hi Masami, >> > > > >> > > > On Tue, 15 Feb 2022 at 23:16, Masami Hiramatsu >> > > > wrote: >> > > >> >> > > >> Add expected_reset optional argument to ConsoleBase::ensure_spawned(), >> > > >> ConsoleBase::restart_uboot() and >> > > >> ConsoleSandbox::restart_uboot_with_flags() >> > > >> so that it can handle a reset while the 1st boot process after main >> > > >> boot logo before prompt correctly. >> > > >> >> > > >> Signed-off-by: Masami Hiramatsu >> > > >> --- >> > > >> Changes in v5: >> > > >>- Rename parameter to expect_reset and update the description to >> > > >> clarify >> > > >> the reset will happen between main boot and the command prompt. >> > > >> --- >> > > >> test/py/u_boot_console_base.py| 48 >> > > >> ++--- >> > > >> test/py/u_boot_console_sandbox.py |7 - >> > > >> 2 files changed, 33 insertions(+), 22 deletions(-) >> > > >> >> > > > >> > > > Didn't I already comment on this patch? Why did it come back? >> > > >> > > Dear Simon, >> > > >> > > The discussion is in >> > > https://patchwork.ozlabs.org/project/uboot/patch/164491595065.536855.9457820061065514578.stgit@localhost/ >> > > >> > > You suggested: "We have a means to avoid actually doing the reset, see >> > > the reset driver." >> > > >> > > We need a real reset on the sandbox and no fake reset as already said in >> > > the referenced thread. >> > >> > Why? >> > >> > The fake reset is there for use by tests. We don't need this load of >> > Python code at all for sandbox. We should worry about it later. >> >> Well, isn't this going to make the tests more sandbox-centric then, and >> then need changes later to be able to test on real hardware? > >Yes, but it keeps the sandbox case simple. At present the sandbox >tests can run within U-Boot (see the 'ut' command) and I very much >want to keep it that way. That is, after all, why I wrote the reset >driver. > >While tests on real hardware have value, I hope that all logic bugs >are found on sandbox. How does this relate to your thoughts about this patch? The patch enables testing capsule updates including resets. This does not stop running the tests on the sandbox. Why do you suggest sandbox specific quirks in capsule updates? Best regards Heinrich > >Regards, >Simon
Re: [PATCH v5 3/4] test/py: Handle expected reboot while booting sandbox
Hi Tom, On Sun, 27 Feb 2022 at 11:14, Tom Rini wrote: > > On Sun, Feb 27, 2022 at 08:39:30AM -0700, Simon Glass wrote: > > Hi Heinrich, > > > > On Sun, 27 Feb 2022 at 01:22, Heinrich Schuchardt > > wrote: > > > > > > On 2/26/22 19:37, Simon Glass wrote: > > > > Hi Masami, > > > > > > > > On Tue, 15 Feb 2022 at 23:16, Masami Hiramatsu > > > > wrote: > > > >> > > > >> Add expected_reset optional argument to ConsoleBase::ensure_spawned(), > > > >> ConsoleBase::restart_uboot() and > > > >> ConsoleSandbox::restart_uboot_with_flags() > > > >> so that it can handle a reset while the 1st boot process after main > > > >> boot logo before prompt correctly. > > > >> > > > >> Signed-off-by: Masami Hiramatsu > > > >> --- > > > >> Changes in v5: > > > >>- Rename parameter to expect_reset and update the description to > > > >> clarify > > > >> the reset will happen between main boot and the command prompt. > > > >> --- > > > >> test/py/u_boot_console_base.py| 48 > > > >> ++--- > > > >> test/py/u_boot_console_sandbox.py |7 - > > > >> 2 files changed, 33 insertions(+), 22 deletions(-) > > > >> > > > > > > > > Didn't I already comment on this patch? Why did it come back? > > > > > > Dear Simon, > > > > > > The discussion is in > > > https://patchwork.ozlabs.org/project/uboot/patch/164491595065.536855.9457820061065514578.stgit@localhost/ > > > > > > You suggested: "We have a means to avoid actually doing the reset, see > > > the reset driver." > > > > > > We need a real reset on the sandbox and no fake reset as already said in > > > the referenced thread. > > > > Why? > > > > The fake reset is there for use by tests. We don't need this load of > > Python code at all for sandbox. We should worry about it later. > > Well, isn't this going to make the tests more sandbox-centric then, and > then need changes later to be able to test on real hardware? Yes, but it keeps the sandbox case simple. At present the sandbox tests can run within U-Boot (see the 'ut' command) and I very much want to keep it that way. That is, after all, why I wrote the reset driver. While tests on real hardware have value, I hope that all logic bugs are found on sandbox. Regards, Simon
[PATCH] clk: Consolidate some clock functions
These functions are exactly the same as their "nodev" varients, except they
accept a device and not an ofnode. Rewrite them to just call the other
function.
Signed-off-by: Sean Anderson
---
drivers/clk/clk-uclass.c | 22 ++
1 file changed, 2 insertions(+), 20 deletions(-)
diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index c20c928bf1..4ab876517a 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -138,14 +138,7 @@ static int clk_get_by_indexed_prop(struct udevice *dev,
const char *prop_name,
int clk_get_by_index(struct udevice *dev, int index, struct clk *clk)
{
- struct ofnode_phandle_args args;
- int ret;
-
- ret = dev_read_phandle_with_args(dev, "clocks", "#clock-cells", 0,
-index, );
-
- return clk_get_by_index_tail(ret, dev_ofnode(dev), , "clocks",
-index, clk);
+ return clk_get_by_index_nodev(dev_ofnode(dev), index, clk);
}
int clk_get_by_index_nodev(ofnode node, int index, struct clk *clk)
@@ -400,18 +393,7 @@ int clk_set_defaults(struct udevice *dev, enum
clk_defaults_stage stage)
int clk_get_by_name(struct udevice *dev, const char *name, struct clk *clk)
{
- int index;
-
- debug("%s(dev=%p, name=%s, clk=%p)\n", __func__, dev, name, clk);
- clk->dev = NULL;
-
- index = dev_read_stringlist_search(dev, "clock-names", name);
- if (index < 0) {
- debug("fdt_stringlist_search() failed: %d\n", index);
- return index;
- }
-
- return clk_get_by_index(dev, index, clk);
+ return clk_get_by_name_nodev(dev_ofnode(dev), name, clk);
}
#endif /* OF_REAL */
--
2.34.1
[PATCH] led: led_pwm: Add a driver for LEDs connected to PWM
From: Ivan Vozvakhov
Add a driver which allows to use of LEDs connected
to PWM (Linux compatible).
MAINTAINERS: add i.vozvakhov as a maintainer of leds-pwm
(required during new functionality adding).
Signed-off-by: Ivan Vozvakhov
Signed-off-by: Ivan Vozvakhov
---
MAINTAINERS| 6 +
doc/device-tree-bindings/leds/leds-pwm.txt | 47 +
drivers/led/Kconfig| 6 +
drivers/led/Makefile | 1 +
drivers/led/led_pwm.c | 189 +
5 files changed, 249 insertions(+)
create mode 100644 doc/device-tree-bindings/leds/leds-pwm.txt
create mode 100644 drivers/led/led_pwm.c
diff --git a/MAINTAINERS b/MAINTAINERS
index fb171e0c68..2e8f8cdada 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -869,6 +869,12 @@ F: doc/README.kwbimage
F: doc/kwboot.1
F: tools/kwb*
+LED
+M: Ivan Vozvakhov
+S: Supported
+F: doc/device-tree-bindings/leds/leds-pwm.txt
+F: drivers/led/led_pwm.c
+
LOGGING
M: Simon Glass
S: Maintained
diff --git a/doc/device-tree-bindings/leds/leds-pwm.txt
b/doc/device-tree-bindings/leds/leds-pwm.txt
new file mode 100644
index 00..186e8a848f
--- /dev/null
+++ b/doc/device-tree-bindings/leds/leds-pwm.txt
@@ -0,0 +1,47 @@
+LEDs connected to PWM (Linux compatible)
+
+Required properties:
+- compatible : should be "pwm-leds".
+
+Each LED is represented as a sub-node of the pwm-leds device. Each
+node's name represents the name of the corresponding LED.
+
+LED sub-node properties:
+- pwms : (required) LED pwm channel, see "pwms property" in
+ doc/device-tree-bindings/pwm/pwm.txt
+- label : (optional) LED label, see "label property" in
+ doc/device-tree-bindings/led/common.txt
+- max-brightness : (optional, unsigned, default 255) Maximum brightness
possible
+ for the LED
+- active-low : (optional, boolean, default false) For PWMs where the LED is
+ wired to supply rather than ground
+- u-boot,default-brightness : (optional, unsigned, default 0) Initial state
+ of pwm-leds
+
+Example:
+
+leds {
+compatible = "pwm-leds";
+status = "okay";
+
+blue {
+label = "led-blue";
+pwms = < 0 10 0>;
+max-brightness = <255>;
+u-boot,default-brightness = <127>;
+};
+
+green {
+label = "led-green";
+pwms = < 0 10 0>;
+max-brightness = <255>;
+u-boot,default-brightness = <127>;
+};
+
+red {
+label = "led-red";
+pwms = < 0 10 0>;
+max-brightness = <255>;
+u-boot,default-brightness = <127>;
+};
+}
diff --git a/drivers/led/Kconfig b/drivers/led/Kconfig
index cc87fbf395..48616e2f55 100644
--- a/drivers/led/Kconfig
+++ b/drivers/led/Kconfig
@@ -42,6 +42,12 @@ config LED_CORTINA
This option enables support for LEDs connected to the Cortina
Access CA SOCs.
+config LED_PWM
+ bool "LED PWM"
+ depends on LED && DM_PWM
+ help
+ Enable support for LEDs connected to PWM.
+ Linux compatible ofdata.
config LED_BLINK
bool "Support LED blinking"
diff --git a/drivers/led/Makefile b/drivers/led/Makefile
index 8e3ae7f146..c31a59e1aa 100644
--- a/drivers/led/Makefile
+++ b/drivers/led/Makefile
@@ -7,5 +7,6 @@ obj-y += led-uclass.o
obj-$(CONFIG_LED_BCM6328) += led_bcm6328.o
obj-$(CONFIG_LED_BCM6358) += led_bcm6358.o
obj-$(CONFIG_LED_BCM6858) += led_bcm6858.o
+obj-$(CONFIG_LED_PWM) += led_pwm.o
obj-$(CONFIG_$(SPL_)LED_GPIO) += led_gpio.o
obj-$(CONFIG_LED_CORTINA) += led_cortina.o
diff --git a/drivers/led/led_pwm.c b/drivers/led/led_pwm.c
new file mode 100644
index 00..d36ce4c0df
--- /dev/null
+++ b/drivers/led/led_pwm.c
@@ -0,0 +1,189 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2022 VK
+ * Author: Ivan Vozvakhov
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define LEDS_PWM_DRIVER_NAME "led_pwm"
+
+struct led_pwm_priv {
+ struct udevice *pwm;
+ uint active_low;/* polarity */
+ uint period;/* period_ns */
+ uint duty;
+ uint channel;
+ bool enabled;
+ bool polarity;
+};
+
+static int led_pwm_enable(struct udevice *dev)
+{
+ struct led_pwm_priv *priv = dev_get_priv(dev);
+ int ret;
+
+ ret = pwm_set_invert(priv->pwm, priv->channel, priv->polarity);
+ if (ret)
+ return ret;
+
+ ret = pwm_set_config(priv->pwm, priv->channel, priv->period,
priv->duty);
+ if (ret)
+ return ret;
+
+ ret = pwm_set_enable(priv->pwm, priv->channel, true);
+ if (ret)
+ return ret;
+
+ priv->enabled = true;
+
+ return 0;
+}
+
+static int led_pwm_disable(struct udevice *dev)
+{
+ struct led_pwm_priv *priv = dev_get_priv(dev);
+ int ret;
+
+ ret = pwm_set_config(priv->pwm, priv->channel, priv->period, 0);
+ if (ret)
+ return ret;
+
+
[PATCH] Add ethernet0 alias in Nanopi NEO's device tree
This is required to enable automatic MAC address generation.
Signed-off-by: Baltazár Radics
---
arch/arm/dts/sun8i-h3-nanopi-neo.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/sun8i-h3-nanopi-neo.dts
b/arch/arm/dts/sun8i-h3-nanopi-neo.dts
index 9f33f6fae..28cf6f8bd 100644
--- a/arch/arm/dts/sun8i-h3-nanopi-neo.dts
+++ b/arch/arm/dts/sun8i-h3-nanopi-neo.dts
@@ -45,6 +45,10 @@
/ {
model = "FriendlyARM NanoPi NEO";
compatible = "friendlyarm,nanopi-neo", "allwinner,sun8i-h3";
+
+ aliases {
+ ethernet0 =
+ }
};
{
--
2.35.1
Re: [PATCH v5 3/4] test/py: Handle expected reboot while booting sandbox
On Sun, Feb 27, 2022 at 08:39:30AM -0700, Simon Glass wrote: > Hi Heinrich, > > On Sun, 27 Feb 2022 at 01:22, Heinrich Schuchardt wrote: > > > > On 2/26/22 19:37, Simon Glass wrote: > > > Hi Masami, > > > > > > On Tue, 15 Feb 2022 at 23:16, Masami Hiramatsu > > > wrote: > > >> > > >> Add expected_reset optional argument to ConsoleBase::ensure_spawned(), > > >> ConsoleBase::restart_uboot() and > > >> ConsoleSandbox::restart_uboot_with_flags() > > >> so that it can handle a reset while the 1st boot process after main > > >> boot logo before prompt correctly. > > >> > > >> Signed-off-by: Masami Hiramatsu > > >> --- > > >> Changes in v5: > > >>- Rename parameter to expect_reset and update the description to > > >> clarify > > >> the reset will happen between main boot and the command prompt. > > >> --- > > >> test/py/u_boot_console_base.py| 48 > > >> ++--- > > >> test/py/u_boot_console_sandbox.py |7 - > > >> 2 files changed, 33 insertions(+), 22 deletions(-) > > >> > > > > > > Didn't I already comment on this patch? Why did it come back? > > > > Dear Simon, > > > > The discussion is in > > https://patchwork.ozlabs.org/project/uboot/patch/164491595065.536855.9457820061065514578.stgit@localhost/ > > > > You suggested: "We have a means to avoid actually doing the reset, see > > the reset driver." > > > > We need a real reset on the sandbox and no fake reset as already said in > > the referenced thread. > > Why? > > The fake reset is there for use by tests. We don't need this load of > Python code at all for sandbox. We should worry about it later. Well, isn't this going to make the tests more sandbox-centric then, and then need changes later to be able to test on real hardware? -- Tom signature.asc Description: PGP signature
Re: [PATCH 0/4] Add support for QEMU's ramfb display
On 27.02.22 16:35, Heinrich Schuchardt wrote: On 2/27/22 15:40, Alexander Graf wrote: QEMU implements multiple ways to expose graphics output to the virt machine, but most of them are incompatible with hardware virtualization. The one that does work reliably is ramfb. It's a very simple mechanism in which the guest reserves a memory region for the frame buffer and then notifies the host about its location and properties. The host then just displays the contents of the frame buffer on screen. This patch set adds support to drive the ramfb device in our QEMU arm targets. Theoretically, it should work as is with any of the other architectures as well though. With this driver, we have a very simple, KVM compatible way to expose GOP via UEFI to payloads and thus enable development and testing of graphical OS functionality with QEMU's -M virt. Alexander Graf (4): qfw: Add WRITE definition ramfb: Add driver for ramfb display qfw: Spawn ramfb device if its file is present qemu-arm*: Enable ramfb by default Please, enable the device on RISC-V too. Sure, I added a riscv enablement patch to the existing submission. It works like a charm :). Alex
[PATCH 5/5] qemu-riscv: Enable ramfb by default
Now that we have everything in place to support ramfb, let's wire it up
by default in the RISC-V QEMU targets. That way, you can easily use a
graphical console by just passing -device ramfb to the QEMU command line.
Signed-off-by: Alexander Graf
---
board/emulation/qemu-riscv/Kconfig | 6 ++
board/emulation/qemu-riscv/qemu-riscv.c | 15 +++
include/configs/qemu-riscv.h| 9 +
3 files changed, 30 insertions(+)
diff --git a/board/emulation/qemu-riscv/Kconfig
b/board/emulation/qemu-riscv/Kconfig
index 02bf84725b..1967fb3a63 100644
--- a/board/emulation/qemu-riscv/Kconfig
+++ b/board/emulation/qemu-riscv/Kconfig
@@ -67,5 +67,11 @@ config BOARD_SPECIFIC_OPTIONS # dummy
imply MTD_NOR_FLASH
imply CFI_FLASH
imply OF_HAS_PRIOR_STAGE
+ imply BOARD_EARLY_INIT_R
+ imply DM_VIDEO
+ imply VIDEO_RAMFB
+ imply SYS_CONSOLE_IS_IN_ENV
+ imply CMD_QFW
+ imply QFW_MMIO
endif
diff --git a/board/emulation/qemu-riscv/qemu-riscv.c
b/board/emulation/qemu-riscv/qemu-riscv.c
index ae3b7a3295..31799b8c3a 100644
--- a/board/emulation/qemu-riscv/qemu-riscv.c
+++ b/board/emulation/qemu-riscv/qemu-riscv.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -28,6 +29,20 @@ int is_flash_available(void)
}
#endif
+int board_early_init_r(void)
+{
+ struct udevice *qfw_dev;
+
+ /*
+* Make sure we enumerate the QEMU Firmware device to find ramfb
+* before console init starts.
+*/
+ if (IS_ENABLED(CONFIG_CMD_QFW))
+ qfw_get_dev(_dev);
+
+ return 0;
+}
+
int board_init(void)
{
/*
diff --git a/include/configs/qemu-riscv.h b/include/configs/qemu-riscv.h
index 618c3b63d4..663ba50688 100644
--- a/include/configs/qemu-riscv.h
+++ b/include/configs/qemu-riscv.h
@@ -39,6 +39,12 @@
func(SCSI, scsi, 0) \
func(DHCP, dhcp, na)
+#ifdef CONFIG_VIDEO_RAMFB
+# define QEMU_STDOUT "serial,vidconsole"
+#else
+# define QEMU_STDOUT "serial"
+#endif
+
#include
#define BOOTENV_DEV_QEMU(devtypeu, devtypel, instance) \
@@ -58,6 +64,9 @@
"scriptaddr=0x8810\0" \
"pxefile_addr_r=0x8820\0" \
"ramdisk_addr_r=0x8830\0" \
+ "stdin=serial\0" \
+ "stdout=" QEMU_STDOUT "\0" \
+ "stderr=" QEMU_STDOUT "\0" \
BOOTENV
#endif
--
2.32.0
Re: [PATCH] efi_loader: Ignore DT when ACPI is on
Hey Heinrich,
On 27.02.22 16:33, Heinrich Schuchardt wrote:
On 2/27/22 15:13, Alexander Graf wrote:
On 27.02.22 14:07, Mark Kettenis wrote:
From: Alexander Graf
Date: Sun, 27 Feb 2022 13:18:56 +0100
For targets that enable ACPI, we should not pass Device Trees into
the payload. However, our distro boot logic always passes the builtin
DT as an argument.
Hello Alex,
nice to see you back at U-Boot.
Thanks :)
If CONFIG_GENERATE_ACPI_TABLE=n, no ACPI table is generated. In this
case U-Boot may fall back to the built in devicetree.
If CONFIG_GENERATE_ACPI_TABLE=y, copy_fdt() does not exist and a
device-tree cannot be supplied to the EFI binary. If you still try
supply a device tree, the bootefi command writes an error an refuses to
boot.
This is the case I fell into (and that this patch touches), yes :).
With which defconfig does this lead to a boot failure?
This is with the qemu_arm64_defconfig and this on top:
echo -e
'CONFIG_ACPIGEN=y\nCONFIG_GENERATE_ACPI_TABLE=y\nCONFIG_CMD_ACPI=y' >>
.config
I haven't fully made up my mind whether this is something we'll want a
separate defconfig for eventually. I just wanted to play a bit with
loading Windows 10/11 via U-Boot :).
Which board supplies ${fdt_addr_r} and has CONFIG_GENERATE_ACPI_TABLE=y?
I don't see fdt_addr_r supplied at all in the QEMU env - there's only
$fdtcontroladdr which gets passed from QEMU. QEMU passes both to the
VM's firmware - DT via memory and location in register as well as ACPI
via fw_cfg.
I'm also not running the bootmgr code path. Since I have no env with
explicit boot entries, I run into the fallback case which always passes
a DT to the payload (line 147 in config_distro_bootcmd.h).
Alex
See include/config_distro_bootcmd.h line 127ff.
Best regards
Heinrich
To make it easy to use ACPI with distro boot, let's just ignore the DT
argument to bootefi when ACPI is enabled. That way, we can
successfully
distro boot payloads on ACPI enabled targets.
I've never understood why it is bad to provide both the DT and ACPI
tables. Several TianoCore EDK2 based firmwares do this or at least
give you the option to do this. And it works fine. If both are
provided, you just leave it up to the OS to decide what it wants to
use. Which makes me think the text was put there in the standard by
people with an agenda...
It's much more profane :). Upstream Linux went with "DT first, ACPI
last" while RHEL had a downstream patch that went "ACPI first, DT last".
And then people were confused why RHEL and upstream kernels had such
vastly different behavior on their systems.
Long story short, the best way to avoid this ambiguity is to only
provide one of the 2 to the OS. And that's what the BBRs dictate now.
They don't dictate what firmware does internally though, so we're free
to do whatever we like - and I think "if someone went through the effort
to enable ACPI on this system, they probably want to use it" is a fair
assumption with U-Boot. So we should prefer ACPI if available.
Alex
I think it would be good for U-Boot to give users a choice here, with
all possible combinations (only DT, only ACPI, both DT and ACPI). But
this is a step in the right direction.
Reviewed-by: Mark Kettenis
Signed-off-by: Alexander Graf
---
cmd/bootefi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 94d18ca73f..2c9bc0dcd2 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -265,8 +265,8 @@ efi_status_t efi_install_fdt(void *fdt)
*/
#if CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE)
if (fdt) {
- log_err("ERROR: can't have ACPI table and device tree.\n");
- return EFI_LOAD_ERROR;
+ log_warning("WARNING: Can't have ACPI table and device tree
- ignoring DT.\n");
+ return EFI_SUCCESS;
}
#else
bootm_headers_t img = { 0 };
--
2.32.0
Re: [PATCH v5 3/4] test/py: Handle expected reboot while booting sandbox
Hi Heinrich, On Sun, 27 Feb 2022 at 01:22, Heinrich Schuchardt wrote: > > On 2/26/22 19:37, Simon Glass wrote: > > Hi Masami, > > > > On Tue, 15 Feb 2022 at 23:16, Masami Hiramatsu > > wrote: > >> > >> Add expected_reset optional argument to ConsoleBase::ensure_spawned(), > >> ConsoleBase::restart_uboot() and ConsoleSandbox::restart_uboot_with_flags() > >> so that it can handle a reset while the 1st boot process after main > >> boot logo before prompt correctly. > >> > >> Signed-off-by: Masami Hiramatsu > >> --- > >> Changes in v5: > >>- Rename parameter to expect_reset and update the description to clarify > >> the reset will happen between main boot and the command prompt. > >> --- > >> test/py/u_boot_console_base.py| 48 > >> ++--- > >> test/py/u_boot_console_sandbox.py |7 - > >> 2 files changed, 33 insertions(+), 22 deletions(-) > >> > > > > Didn't I already comment on this patch? Why did it come back? > > Dear Simon, > > The discussion is in > https://patchwork.ozlabs.org/project/uboot/patch/164491595065.536855.9457820061065514578.stgit@localhost/ > > You suggested: "We have a means to avoid actually doing the reset, see > the reset driver." > > We need a real reset on the sandbox and no fake reset as already said in > the referenced thread. Why? The fake reset is there for use by tests. We don't need this load of Python code at all for sandbox. We should worry about it later. Regards, Simon
Re: [PATCH 0/4] Add support for QEMU's ramfb display
On 2/27/22 15:40, Alexander Graf wrote: QEMU implements multiple ways to expose graphics output to the virt machine, but most of them are incompatible with hardware virtualization. The one that does work reliably is ramfb. It's a very simple mechanism in which the guest reserves a memory region for the frame buffer and then notifies the host about its location and properties. The host then just displays the contents of the frame buffer on screen. This patch set adds support to drive the ramfb device in our QEMU arm targets. Theoretically, it should work as is with any of the other architectures as well though. With this driver, we have a very simple, KVM compatible way to expose GOP via UEFI to payloads and thus enable development and testing of graphical OS functionality with QEMU's -M virt. Alexander Graf (4): qfw: Add WRITE definition ramfb: Add driver for ramfb display qfw: Spawn ramfb device if its file is present qemu-arm*: Enable ramfb by default Please, enable the device on RISC-V too. Best regards Heinrich arch/arm/Kconfig| 4 ++ board/emulation/qemu-arm/qemu-arm.c | 14 drivers/misc/qfw.c | 23 ++ drivers/video/Kconfig | 8 +++ drivers/video/MAINTAINERS | 4 ++ drivers/video/Makefile | 1 + drivers/video/ramfb.c | 104 include/configs/qemu-arm.h | 9 +++ include/qfw.h | 1 + 9 files changed, 168 insertions(+) create mode 100644 drivers/video/MAINTAINERS create mode 100644 drivers/video/ramfb.c
Re: [PATCH] efi_loader: Ignore DT when ACPI is on
On 2/27/22 15:13, Alexander Graf wrote:
On 27.02.22 14:07, Mark Kettenis wrote:
From: Alexander Graf
Date: Sun, 27 Feb 2022 13:18:56 +0100
For targets that enable ACPI, we should not pass Device Trees into
the payload. However, our distro boot logic always passes the builtin
DT as an argument.
Hello Alex,
nice to see you back at U-Boot.
If CONFIG_GENERATE_ACPI_TABLE=n, no ACPI table is generated. In this
case U-Boot may fall back to the built in devicetree.
If CONFIG_GENERATE_ACPI_TABLE=y, copy_fdt() does not exist and a
device-tree cannot be supplied to the EFI binary. If you still try
supply a device tree, the bootefi command writes an error an refuses to
boot.
With which defconfig does this lead to a boot failure?
Which board supplies ${fdt_addr_r} and has CONFIG_GENERATE_ACPI_TABLE=y?
See include/config_distro_bootcmd.h line 127ff.
Best regards
Heinrich
To make it easy to use ACPI with distro boot, let's just ignore the DT
argument to bootefi when ACPI is enabled. That way, we can successfully
distro boot payloads on ACPI enabled targets.
I've never understood why it is bad to provide both the DT and ACPI
tables. Several TianoCore EDK2 based firmwares do this or at least
give you the option to do this. And it works fine. If both are
provided, you just leave it up to the OS to decide what it wants to
use. Which makes me think the text was put there in the standard by
people with an agenda...
It's much more profane :). Upstream Linux went with "DT first, ACPI
last" while RHEL had a downstream patch that went "ACPI first, DT last".
And then people were confused why RHEL and upstream kernels had such
vastly different behavior on their systems.
Long story short, the best way to avoid this ambiguity is to only
provide one of the 2 to the OS. And that's what the BBRs dictate now.
They don't dictate what firmware does internally though, so we're free
to do whatever we like - and I think "if someone went through the effort
to enable ACPI on this system, they probably want to use it" is a fair
assumption with U-Boot. So we should prefer ACPI if available.
Alex
I think it would be good for U-Boot to give users a choice here, with
all possible combinations (only DT, only ACPI, both DT and ACPI). But
this is a step in the right direction.
Reviewed-by: Mark Kettenis
Signed-off-by: Alexander Graf
---
cmd/bootefi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 94d18ca73f..2c9bc0dcd2 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -265,8 +265,8 @@ efi_status_t efi_install_fdt(void *fdt)
*/
#if CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE)
if (fdt) {
- log_err("ERROR: can't have ACPI table and device tree.\n");
- return EFI_LOAD_ERROR;
+ log_warning("WARNING: Can't have ACPI table and device tree
- ignoring DT.\n");
+ return EFI_SUCCESS;
}
#else
bootm_headers_t img = { 0 };
--
2.32.0
[PATCH 4/4] qemu-arm*: Enable ramfb by default
Now that we have everything in place to support ramfb, let's wire it up
by default in the ARM QEMU targets. That way, you can easily use a
graphical console by just passing -device ramfb to the QEMU command line.
Signed-off-by: Alexander Graf
---
arch/arm/Kconfig| 4
board/emulation/qemu-arm/qemu-arm.c | 14 ++
include/configs/qemu-arm.h | 9 +
3 files changed, 27 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 391a77c2b4..1f8b881c73 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -979,6 +979,10 @@ config ARCH_QEMU
imply DM_RTC
imply RTC_PL031
imply OF_HAS_PRIOR_STAGE
+ imply BOARD_EARLY_INIT_R
+ imply DM_VIDEO
+ imply VIDEO_RAMFB
+ imply SYS_CONSOLE_IS_IN_ENV
config ARCH_RMOBILE
bool "Renesas ARM SoCs"
diff --git a/board/emulation/qemu-arm/qemu-arm.c
b/board/emulation/qemu-arm/qemu-arm.c
index 16d5a97167..c898ea8a14 100644
--- a/board/emulation/qemu-arm/qemu-arm.c
+++ b/board/emulation/qemu-arm/qemu-arm.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
@@ -63,6 +64,19 @@ static struct mm_region qemu_arm64_mem_map[] = {
struct mm_region *mem_map = qemu_arm64_mem_map;
#endif
+int board_early_init_r(void)
+{
+ struct udevice *qfw_dev;
+
+ /*
+* Make sure we enumerate the QEMU Firmware device to find ramfb
+* before console init starts.
+*/
+ qfw_get_dev(_dev);
+
+ return 0;
+}
+
int board_init(void)
{
return 0;
diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
index 7ae71e0029..ac67e89a98 100644
--- a/include/configs/qemu-arm.h
+++ b/include/configs/qemu-arm.h
@@ -58,6 +58,12 @@
BOOT_TARGET_NVME(func) \
BOOT_TARGET_DHCP(func)
+#ifdef CONFIG_VIDEO_RAMFB
+# define QEMU_STDOUT "serial,vidconsole"
+#else
+# define QEMU_STDOUT "serial"
+#endif
+
#include
#define CONFIG_EXTRA_ENV_SETTINGS \
@@ -68,6 +74,9 @@
"pxefile_addr_r=0x4030\0" \
"kernel_addr_r=0x4040\0" \
"ramdisk_addr_r=0x4400\0" \
+ "stdin=serial\0" \
+ "stdout=" QEMU_STDOUT "\0" \
+ "stderr=" QEMU_STDOUT "\0" \
BOOTENV
#define CONFIG_SYS_CBSIZE 512
--
2.32.0
[PATCH 3/4] qfw: Spawn ramfb device if its file is present
Now that we have a ramfb device driver, let's add the necessary glueing
magic to also spawn it when we find its qfw file node.
Signed-off-by: Alexander Graf
---
drivers/misc/qfw.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/misc/qfw.c b/drivers/misc/qfw.c
index 7c6ed41f48..fefa0bce86 100644
--- a/drivers/misc/qfw.c
+++ b/drivers/misc/qfw.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#if defined(CONFIG_GENERATE_ACPI_TABLE) && !defined(CONFIG_ARM)
@@ -309,6 +310,26 @@ void qfw_read_entry(struct udevice *dev, u16 entry, u32
size, void *address)
qfw_read_entry_io(qdev, entry, size, address);
}
+static void qfw_bind_ramfb(struct udevice *dev)
+{
+#ifdef CONFIG_VIDEO_RAMFB
+ struct fw_file *file;
+ int ret;
+
+ ret = qfw_read_firmware_list(dev);
+ if (ret)
+ return;
+
+ file = qfw_find_file(dev, "etc/ramfb");
+ if (!file) {
+ /* No ramfb available. */
+ return;
+ }
+
+ device_bind_driver(dev, "ramfb", "qfw-ramfb", NULL);
+#endif
+}
+
int qfw_register(struct udevice *dev)
{
struct qfw_dev *qdev = dev_get_uclass_priv(dev);
@@ -325,6 +346,8 @@ int qfw_register(struct udevice *dev)
if (dma_enabled & FW_CFG_DMA_ENABLED)
qdev->dma_present = true;
+ qfw_bind_ramfb(dev);
+
return 0;
}
--
2.32.0
[PATCH 2/4] ramfb: Add driver for ramfb display
QEMU implements multiple ways to expose graphics output to the virt
machine, but most of them are incompatible with hardware virtualization.
The one that does work reliably is ramfb. It's a very simple mechanism
in which the guest reserves a memory region for the frame buffer and then
notifies the host about its location and properties. The host then just
displays the contents of the frame buffer on screen.
This patch implements a trivial version of a ramfb driver - hard coded
to a single resolution.
Signed-off-by: Alexander Graf
---
drivers/video/Kconfig | 8 +++
drivers/video/MAINTAINERS | 4 ++
drivers/video/Makefile| 1 +
drivers/video/ramfb.c | 104 ++
4 files changed, 117 insertions(+)
create mode 100644 drivers/video/MAINTAINERS
create mode 100644 drivers/video/ramfb.c
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index ff8e11f648..73a9e20534 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -871,6 +871,14 @@ config VIDEO_MCDE_SIMPLE
before u-boot starts, and u-boot will simply render to the pre-
allocated frame buffer surface.
+config VIDEO_RAMFB
+ bool "QEMU ramfb display driver for in-RAM display"
+ depends on EFI_LOADER && DM_VIDEO && QFW
+ help
+ Enables a RAM based simple frame buffer driver which uses qfw to
+ notify the hypervisor about the location of a Frame Buffer allocated
+ in guest RAM as well as its properties.
+
config OSD
bool "Enable OSD support"
depends on DM
diff --git a/drivers/video/MAINTAINERS b/drivers/video/MAINTAINERS
new file mode 100644
index 00..74c258a314
--- /dev/null
+++ b/drivers/video/MAINTAINERS
@@ -0,0 +1,4 @@
+QEMU RAMFB VIDEO DRIVER
+M: Alexander Graf
+S: Maintained
+F: drivers/video/ramfb.c
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 4038395b12..6cfec17072 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -74,6 +74,7 @@ obj-$(CONFIG_VIDEO_TEGRA20) += tegra.o
obj-$(CONFIG_VIDEO_VCXK) += bus_vcxk.o
obj-$(CONFIG_VIDEO_VESA) += vesa.o
obj-$(CONFIG_VIDEO_SEPS525) += seps525.o
+obj-$(CONFIG_VIDEO_RAMFB) += ramfb.o
obj-y += bridge/
obj-y += sunxi/
diff --git a/drivers/video/ramfb.c b/drivers/video/ramfb.c
new file mode 100644
index 00..c46bfa3baa
--- /dev/null
+++ b/drivers/video/ramfb.c
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2022 Alexander Graf
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define fourcc_code(a, b, c, d) ((u32)(a) | ((u32)(b) << 8) | \
+((u32)(c) << 16) | ((u32)(d) << 24))
+#define DRM_FORMAT_XRGB fourcc_code('X', 'R', '2', '4')
+
+#define DEFAULT_WIDTH 1280
+#define DEFAULT_HEIGHT 900
+#define DEFAULT_BPIX VIDEO_BPP32
+#define DEFAULT_FORMAT VIDEO_X8R8G8B8
+
+struct ramfb_cfg {
+ u64 addr;
+ u32 fourcc;
+ u32 flags;
+ u32 width;
+ u32 height;
+ u32 stride;
+} __packed;
+
+static int ramfb_probe(struct udevice *dev)
+{
+ struct video_uc_plat *plat = dev_get_uclass_plat(dev);
+ struct video_priv *uc_priv = dev_get_uclass_priv(dev);
+ u32 selector;
+ u64 base;
+ u64 size;
+ efi_status_t ret;
+ struct fw_file *file;
+ struct udevice *qfw;
+ struct dm_qfw_ops *ops;
+ struct qfw_dma dma = {};
+ struct ramfb_cfg cfg = {
+ .addr = 0,
+ .fourcc = cpu_to_be32(DRM_FORMAT_XRGB),
+ .flags = 0,
+ .width = cpu_to_be32(DEFAULT_WIDTH),
+ .height = cpu_to_be32(DEFAULT_HEIGHT),
+ .stride = 0,
+ };
+
+ ret = qfw_get_dev();
+ if (ret)
+ return -EPROBE_DEFER;
+
+ ops = dm_qfw_get_ops(qfw);
+ if (!ops)
+ return -EPROBE_DEFER;
+
+ file = qfw_find_file(qfw, "etc/ramfb");
+ if (!file) {
+ /* No ramfb available. At least we tried. */
+ return -ENOENT;
+ }
+
+ size = DEFAULT_WIDTH * DEFAULT_HEIGHT * VNBYTES(DEFAULT_BPIX);
+ ret = efi_allocate_pages(EFI_ALLOCATE_ANY_PAGES,
+EFI_RESERVED_MEMORY_TYPE,
+efi_size_in_pages(size), );
+ if (ret != EFI_SUCCESS)
+ return -ENOMEM;
+
+ debug("%s: base=%llx, size=%llu\n", __func__, base, size);
+
+ cfg.addr = cpu_to_be64(base);
+ plat->base = base;
+ plat->size = size;
+ uc_priv->xsize = DEFAULT_WIDTH;
+ uc_priv->ysize = DEFAULT_HEIGHT;
+ uc_priv->bpix = DEFAULT_BPIX;
+ uc_priv->format = DEFAULT_FORMAT;
+ uc_priv->fb = (void *)base;
+ uc_priv->fb_size = size;
+
+ selector = be16_to_cpu(file->cfg.select);
+ dma.length = cpu_to_be32(sizeof(cfg));
+ dma.address = cpu_to_be64((uintptr_t));
+ dma.control =
[PATCH 1/4] qfw: Add WRITE definition
The QEMU fw_cfg device supports writing entries as well. Add the constant
define for it so that we can leverage write functionality later.
Signed-off-by: Alexander Graf
---
include/qfw.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/qfw.h b/include/qfw.h
index 7ca132e66a..e42960cbb4 100644
--- a/include/qfw.h
+++ b/include/qfw.h
@@ -70,6 +70,7 @@ enum {
#define FW_CFG_DMA_READ(1 << 1)
#define FW_CFG_DMA_SKIP(1 << 2)
#define FW_CFG_DMA_SELECT (1 << 3)
+#define FW_CFG_DMA_WRITE (1 << 4)
/* Bit set in FW_CFG_ID response to indicate DMA interface availability. */
#define FW_CFG_DMA_ENABLED (1 << 1)
--
2.32.0
[PATCH 0/4] Add support for QEMU's ramfb display
QEMU implements multiple ways to expose graphics output to the virt machine, but most of them are incompatible with hardware virtualization. The one that does work reliably is ramfb. It's a very simple mechanism in which the guest reserves a memory region for the frame buffer and then notifies the host about its location and properties. The host then just displays the contents of the frame buffer on screen. This patch set adds support to drive the ramfb device in our QEMU arm targets. Theoretically, it should work as is with any of the other architectures as well though. With this driver, we have a very simple, KVM compatible way to expose GOP via UEFI to payloads and thus enable development and testing of graphical OS functionality with QEMU's -M virt. Alexander Graf (4): qfw: Add WRITE definition ramfb: Add driver for ramfb display qfw: Spawn ramfb device if its file is present qemu-arm*: Enable ramfb by default arch/arm/Kconfig| 4 ++ board/emulation/qemu-arm/qemu-arm.c | 14 drivers/misc/qfw.c | 23 ++ drivers/video/Kconfig | 8 +++ drivers/video/MAINTAINERS | 4 ++ drivers/video/Makefile | 1 + drivers/video/ramfb.c | 104 include/configs/qemu-arm.h | 9 +++ include/qfw.h | 1 + 9 files changed, 168 insertions(+) create mode 100644 drivers/video/MAINTAINERS create mode 100644 drivers/video/ramfb.c -- 2.32.0
[PATCH] qfw: Allocate ACPI memory using efi logic
When we allocate ACPI tables dynamically as part of the qfw ACPI loading
code and then later want to boot a UEFI target using them, we need to make
sure that the UEFI logic is aware that these memory regions are ACPI, so
that the loading kernel can mark them as reserved.
Since we'll never see alignment requirements more than a page, let's just
use efi_allocate_pages when we see high memory allocation requests in a
UEFI enabled environment. Even if we then boot using the native zImage
later, the memory allocation will still be valid.
Without this patch, Linux will refuse to consume the DSDT when passed from
qfw's ACPI framework. With this patch, it happily uses it.
Signed-off-by: Alexander Graf
---
drivers/misc/qfw.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/qfw.c b/drivers/misc/qfw.c
index 754bc6a603..7c6ed41f48 100644
--- a/drivers/misc/qfw.c
+++ b/drivers/misc/qfw.c
@@ -18,6 +18,9 @@
#if defined(CONFIG_GENERATE_ACPI_TABLE) && !defined(CONFIG_ARM)
#include
#endif
+#ifdef CONFIG_EFI_LOADER
+#include
+#endif
#if defined(CONFIG_GENERATE_ACPI_TABLE) && !defined(CONFIG_SANDBOX)
/*
@@ -35,7 +38,7 @@ static int bios_linker_allocate(struct udevice *dev,
{
uint32_t size, align;
struct fw_file *file;
- unsigned long aligned_addr;
+ unsigned long aligned_addr = 0;
align = le32_to_cpu(entry->alloc.align);
/* align must be power of 2 */
@@ -59,7 +62,19 @@ static int bios_linker_allocate(struct udevice *dev,
* in which is low memory
*/
if (entry->alloc.zone == BIOS_LINKER_LOADER_ALLOC_ZONE_HIGH) {
+#ifdef CONFIG_EFI_LOADER
+ efi_status_t ret;
+ u64 efi_addr = 1ULL << 32;
+
+ ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
+EFI_ACPI_RECLAIM_MEMORY,
+efi_size_in_pages(size),
+_addr);
+ if (ret == EFI_SUCCESS)
+ aligned_addr = efi_addr;
+#else
aligned_addr = (unsigned long)memalign(align, size);
+#endif
if (!aligned_addr) {
printf("error: allocating resource\n");
return -ENOMEM;
--
2.32.0
Re: [PATCH v5 3/4] test/py: Handle expected reboot while booting sandbox
On Sat, Feb 26, 2022 at 11:37:20AM -0700, Simon Glass wrote: > Hi Masami, > > On Tue, 15 Feb 2022 at 23:16, Masami Hiramatsu > wrote: > > > > Add expected_reset optional argument to ConsoleBase::ensure_spawned(), > > ConsoleBase::restart_uboot() and ConsoleSandbox::restart_uboot_with_flags() > > so that it can handle a reset while the 1st boot process after main > > boot logo before prompt correctly. > > > > Signed-off-by: Masami Hiramatsu > > --- > > Changes in v5: > > - Rename parameter to expect_reset and update the description to clarify > > the reset will happen between main boot and the command prompt. > > --- > > test/py/u_boot_console_base.py| 48 > > ++--- > > test/py/u_boot_console_sandbox.py |7 - > > 2 files changed, 33 insertions(+), 22 deletions(-) > > Didn't I already comment on this patch? Why did it come back? Maybe I'm confused. This is so that we can "cold" reset sandbox so it behaves more consistently to other platforms, yes? -- Tom signature.asc Description: PGP signature
Re: Pull request for efi-2022-04-rc3
On Sat, Feb 26, 2022 at 08:26:22AM +0100, Heinrich Schuchardt wrote: > Dear Tom, > > The following changes since commit c6ae38b38967a5c33d729c20e508a03ba3e0e3f6: > > Merge tag 'clk-2022.04-rc2' of > https://source.denx.de/u-boot/custodians/u-boot-clk (2022-02-25 11:21:32 > -0500) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-efi.git > tags/efi-2022-04-rc3 > > for you to fetch changes up to 3fa9ed9ae3b30dd6e7f5e887c76d183ad72a44a2: > > efi_loader: update the timing of enabling and disabling EFI watchdog > (2022-02-26 07:37:01 +0100) > > Gitlab CI showed no problems: > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/11093 > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-sh/master
On Sat, Feb 26, 2022 at 04:03:16AM +0100, Marek Vasut wrote: > The following changes since commit c6ae38b38967a5c33d729c20e508a03ba3e0e3f6: > > Merge tag 'clk-2022.04-rc2' of > https://source.denx.de/u-boot/custodians/u-boot-clk (2022-02-25 11:21:32 > -0500) > > are available in the Git repository at: > > git://source.denx.de/u-boot-sh.git master > > for you to fetch changes up to 4ce849f535ba185288c27e30091d71446e32a47a: > > arm: rmobile: rzg2_beacon: Enable proper Ethernet PHY (2022-02-25 21:42:07 > +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH] qfw: Do not include tables.h on arm
asm/tables.h does not exist on ARM and I did not need it to make the code compile successfully. Let's not include it there. Signed-off-by: Alexander Graf --- Maybe someone with more insight into the qfw code could tell me if we can remove the include altogether? :) --- drivers/misc/qfw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/misc/qfw.c b/drivers/misc/qfw.c index 677841aac5..754bc6a603 100644 --- a/drivers/misc/qfw.c +++ b/drivers/misc/qfw.c @@ -15,7 +15,7 @@ #include #include #include -#ifdef CONFIG_GENERATE_ACPI_TABLE +#if defined(CONFIG_GENERATE_ACPI_TABLE) && !defined(CONFIG_ARM) #include #endif -- 2.32.0
Re: [PATCH] efi_loader: Ignore DT when ACPI is on
On 27.02.22 14:07, Mark Kettenis wrote:
From: Alexander Graf
Date: Sun, 27 Feb 2022 13:18:56 +0100
For targets that enable ACPI, we should not pass Device Trees into
the payload. However, our distro boot logic always passes the builtin
DT as an argument.
To make it easy to use ACPI with distro boot, let's just ignore the DT
argument to bootefi when ACPI is enabled. That way, we can successfully
distro boot payloads on ACPI enabled targets.
I've never understood why it is bad to provide both the DT and ACPI
tables. Several TianoCore EDK2 based firmwares do this or at least
give you the option to do this. And it works fine. If both are
provided, you just leave it up to the OS to decide what it wants to
use. Which makes me think the text was put there in the standard by
people with an agenda...
It's much more profane :). Upstream Linux went with "DT first, ACPI
last" while RHEL had a downstream patch that went "ACPI first, DT last".
And then people were confused why RHEL and upstream kernels had such
vastly different behavior on their systems.
Long story short, the best way to avoid this ambiguity is to only
provide one of the 2 to the OS. And that's what the BBRs dictate now.
They don't dictate what firmware does internally though, so we're free
to do whatever we like - and I think "if someone went through the effort
to enable ACPI on this system, they probably want to use it" is a fair
assumption with U-Boot. So we should prefer ACPI if available.
Alex
I think it would be good for U-Boot to give users a choice here, with
all possible combinations (only DT, only ACPI, both DT and ACPI). But
this is a step in the right direction.
Reviewed-by: Mark Kettenis
Signed-off-by: Alexander Graf
---
cmd/bootefi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 94d18ca73f..2c9bc0dcd2 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -265,8 +265,8 @@ efi_status_t efi_install_fdt(void *fdt)
*/
#if CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE)
if (fdt) {
- log_err("ERROR: can't have ACPI table and device tree.\n");
- return EFI_LOAD_ERROR;
+ log_warning("WARNING: Can't have ACPI table and device tree -
ignoring DT.\n");
+ return EFI_SUCCESS;
}
#else
bootm_headers_t img = { 0 };
--
2.32.0
[PATCH] lib/acpi: Enable QEMU special cases for ARM
With QEMU, we receive ACPI tables from the hypervisor rather than build
them ourselves in U-Boot. That logic however hard codes the target to the
x86 QEMU target, leaving ARM out on the fun.
Let's add the ARM QEMU config as well to the ifdefs so that we can consume
QEMU provided firmware tables there as well.
Signed-off-by: Alexander Graf
---
lib/acpi/Makefile | 2 ++
lib/acpi/acpi_writer.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/acpi/Makefile b/lib/acpi/Makefile
index 956b5a0d72..66ba0e94ac 100644
--- a/lib/acpi/Makefile
+++ b/lib/acpi/Makefile
@@ -9,6 +9,7 @@ obj-y += acpi_writer.o
# With QEMU the ACPI tables come from there, not from U-Boot
ifndef CONFIG_QEMU
+ifndef CONFIG_ARCH_QEMU
obj-y += base.o
obj-y += csrt.o
obj-y += mcfg.o
@@ -21,3 +22,4 @@ endif
obj-y += facs.o
obj-y += ssdt.o
endif
+endif
diff --git a/lib/acpi/acpi_writer.c b/lib/acpi/acpi_writer.c
index 946f90e8e7..9c252aa58d 100644
--- a/lib/acpi/acpi_writer.c
+++ b/lib/acpi/acpi_writer.c
@@ -48,7 +48,7 @@ int acpi_write_one(struct acpi_ctx *ctx, const struct
acpi_writer *entry)
return 0;
}
-#ifndef CONFIG_QEMU
+#if !defined(CONFIG_QEMU) && !defined(CONFIG_ARCH_QEMU)
static int acpi_write_all(struct acpi_ctx *ctx)
{
const struct acpi_writer *writer =
--
2.32.0
Re: [PATCH] qemu-arm: Enable NVMe for distro boot
> From: Alexander Graf > Date: Sun, 27 Feb 2022 13:20:32 +0100 > > We already support the NVMe commands and PCIe backend in the QEMU target, > so let's make it easy for anyone to consume them and enable NVMe distro > boot along the way! > > With this patch, I can put an NVMe backed disk image into my QEMU VM and > have it automatically load a UEFI target blob. > > Signed-off-by: Alexander Graf > --- > include/configs/qemu-arm.h | 7 +++ > 1 file changed, 7 insertions(+) Reviewed-by: Mark Kettenis > diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h > index d45f606860..7ae71e0029 100644 > --- a/include/configs/qemu-arm.h > +++ b/include/configs/qemu-arm.h > @@ -39,6 +39,12 @@ > # define BOOT_TARGET_VIRTIO(func) > #endif > > +#if CONFIG_IS_ENABLED(CMD_NVME) > +# define BOOT_TARGET_NVME(func) func(NVME, nvme, 0) > +#else > +# define BOOT_TARGET_NVME(func) > +#endif > + > #if CONFIG_IS_ENABLED(CMD_DHCP) > # define BOOT_TARGET_DHCP(func) func(DHCP, dhcp, na) > #else > @@ -49,6 +55,7 @@ > BOOT_TARGET_USB(func) \ > BOOT_TARGET_SCSI(func) \ > BOOT_TARGET_VIRTIO(func) \ > + BOOT_TARGET_NVME(func) \ > BOOT_TARGET_DHCP(func) > > #include > -- > 2.32.0 > >
Re: [PATCH] efi_loader: Ignore DT when ACPI is on
> From: Alexander Graf
> Date: Sun, 27 Feb 2022 13:18:56 +0100
>
> For targets that enable ACPI, we should not pass Device Trees into
> the payload. However, our distro boot logic always passes the builtin
> DT as an argument.
>
> To make it easy to use ACPI with distro boot, let's just ignore the DT
> argument to bootefi when ACPI is enabled. That way, we can successfully
> distro boot payloads on ACPI enabled targets.
I've never understood why it is bad to provide both the DT and ACPI
tables. Several TianoCore EDK2 based firmwares do this or at least
give you the option to do this. And it works fine. If both are
provided, you just leave it up to the OS to decide what it wants to
use. Which makes me think the text was put there in the standard by
people with an agenda...
I think it would be good for U-Boot to give users a choice here, with
all possible combinations (only DT, only ACPI, both DT and ACPI). But
this is a step in the right direction.
Reviewed-by: Mark Kettenis
> Signed-off-by: Alexander Graf
> ---
> cmd/bootefi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 94d18ca73f..2c9bc0dcd2 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -265,8 +265,8 @@ efi_status_t efi_install_fdt(void *fdt)
>*/
> #if CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE)
> if (fdt) {
> - log_err("ERROR: can't have ACPI table and device tree.\n");
> - return EFI_LOAD_ERROR;
> + log_warning("WARNING: Can't have ACPI table and device tree -
> ignoring DT.\n");
> + return EFI_SUCCESS;
> }
> #else
> bootm_headers_t img = { 0 };
> --
> 2.32.0
>
>
Re: [PATCH 03/10] tpm: Fix the return type of tpm_startup
hello Heinrich,
On Fri, 25 Feb 2022 at 00:25, Heinrich Schuchardt wrote:
>
> On 2/24/22 19:05, Sughosh Ganu wrote:
> > The tpm_startup function returns negative values for error
> > conditions. Fix the return type of the function to a signed int
> > instead of a u32.
> >
> > Signed-off-by: Sughosh Ganu
> > ---
> > include/tpm_api.h | 2 +-
> > lib/tpm_api.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/tpm_api.h b/include/tpm_api.h
> > index b9e3e8b5e6..fb6ee14e23 100644
> > --- a/include/tpm_api.h
> > +++ b/include/tpm_api.h
> > @@ -18,7 +18,7 @@
> >* @param mode TPM startup mode
> >* Return: return code of the operation
>
> Should this become:
>
> Return: 0 for success, -ve in case of error ?
I think there are two types of return codes coming from tpm_startup.
One is the negative values which are primarily for handling error
conditions like invalid parameters, unsupported tpm chip version etc.
The other error codes are the response from the tpm chip for the
requested operation. These are non-negative values. For a successful
response though, both tpmv1 and tpmv2 response is a 0x0. Should this
be
Return: 0 for success, -EINVAL for invalid parameters, -ENOSYS for
unsupported TPM version, TPM error codes
>
> If we would stop at after this patch, TPM errors would be returned as
> -EPERM (= TPM_LIB_ERROR). So maybe this patch should be merged with a
> later patch.
Sorry, but I don't get this. The patch is changing the return type for
tpm_startup. I think this function is not returning TPM_LIB_ERROR --
that is returned by the RNG functions of the TPM device.
-sughosh
>
> Best regards
>
> Heinrich
>
> >*/
> > -u32 tpm_startup(struct udevice *dev, enum tpm_startup_type mode);
> > +int tpm_startup(struct udevice *dev, enum tpm_startup_type mode);
> >
> > /**
> >* Issue a TPM_SelfTestFull command.
> > diff --git a/lib/tpm_api.c b/lib/tpm_api.c
> > index 1bbe33a3fc..b762202866 100644
> > --- a/lib/tpm_api.c
> > +++ b/lib/tpm_api.c
> > @@ -21,7 +21,7 @@ static bool is_tpm2(struct udevice *dev)
> > return IS_ENABLED(CONFIG_TPM_V2) && tpm_get_version(dev) == TPM_V2;
> > }
> >
> > -u32 tpm_startup(struct udevice *dev, enum tpm_startup_type mode)
> > +int tpm_startup(struct udevice *dev, enum tpm_startup_type mode)
> > {
> > if (is_tpm1(dev)) {
> > return tpm1_startup(dev, mode);
>
N00b need help - U-Boot 2015.01-gfe79c6daed-dirty - How to detect CPU | how to backup firmware | how to boot custom-firmware
AXG:BL1:d1dbf2:a4926f;FEAT:F0DC31BC:2000;POC:F;EMMC:800;NAND:0;READ:0;0.0;0.0;CHK:0; sdio debug board detected TE: 140571 BL2 Built : 11:48:35, Mar 10 2020. axg gf91bf0a - jenkins@walle02-sh set vcck to 1050 mv set vddee to 950 mv Board ID = 3 CPU clk: 1200MHz DDR low power enabled DDR3 chl: Rank0 16bit @ 912MHz bist_test rank: 0 18 00 30 22 0a 3b 17 00 2f 24 0d 3c 00 00 00 00 00 00 00 00 00 00 00 00 772 - PASS Rank0: 512MB(auto)-2T-13 AddrBus test pass! NAND init Load FIP HDR from NAND, src: 0xc000, des: 0x0170, size: 0x4000, part: 0 Load BL3x from NAND, src: 0x0001, des: 0x01704000, size: 0x000afc00, part: 0 NOTICE: BL31: v1.3(release):d5a9e97 NOTICE: BL31: Built : 17:38:06, Mar 12 2020 NOTICE: BL31: AXG secure boot! NOTICE: BL31: BL33 decompress pass OPS=0x43 [Image: axg_v1.1.3489-8f09446 2020-03-12 13:58:51 jenkins@walle02-sh] 25 0c 43 00 ed b9 e3 7f 15 2a e1 53 b8 33 72 33 bl30:axg ver: 9 mode: 0 bl30:axg thermal0 [0.015888 Inits done] secure task start! high task start! low task start! ERROR: Error initializing runtime service opteed_fast U-Boot 2015.01-gfe79c6daed-dirty (Aug 27 2020 - 14:13:41) DRAM: 512 MiB Relocation Offset is: 1eec3000 mmu cfg end: 0x2000 mmu cfg end: 0x2000 register usb cfg[0][1] = 1ff74ad0 aml_i2c_init_port init regs for 0 NAND: get_sys_clk_rate_mtd() 292, clock setting 200! bus cycle0: 6,timing: 7 NAND device id: 98 da 90 15 76 16 NAND device: Manufacturer ID: 0x98, Chip ID: 0x98 (Toshiba A revision NAND 2Gib TC58NVG1S3HBAI4 ) get_sys_clk_rate_mtd() 292, clock setting 200! m3_nand_adjust_timing() sys_clk_rate 200, bus_c 6, bus_t 7 oob_fill_cnt =32 oob_size =64, bch_bytes =14 ecc mode:6 ecc_page_num=2 eep_need_oobsize=16 plane_num=1 writesize=0x800 ecc.size=0x200 bch_mode=1 oob avail size 6 Creating 1 MTD partitions on "A revision NAND 2Gib TC58NVG1S3HBAI4 ": 0x-0x0020 : "bootloader" A revision NAND 2Gib TC58NVG1S3HBAI4 initialized ok get_sys_clk_rate_mtd() 292, clock setting 200! bus cycle0: 6,timing: 7 NAND device id: 98 da 90 15 76 16 NAND device: Manufacturer ID: 0x98, Chip ID: 0x98 (Toshiba A revision NAND 2Gib TC58NVG1S3HBAI4 ) get_sys_clk_rate_mtd() 292, clock setting 200! m3_nand_adjust_timing() sys_clk_rate 200, bus_c 6, bus_t 7 oob_fill_cnt =32 oob_size =64, bch_bytes =14 ecc mode:6 ecc_page_num=2 eep_need_oobsize=16 PLANE change! plane_num=1 writesize=0x800 ecc.size=0x200 bch_mode=1 aml_nand_init :oobmul=1,oobfree.length=8,oob_size=64 oob avail size 8 nbbt=20 nenv=24 nkey=32 ndtb=40 nddr=44 bbt_start=20 env_start=24 key_start=32 dtb_start=40 ddr_start=44 nbbt: info size=0x800 max_scan_blk=24, start_blk=20 nbbt : phy_blk_addr=20, ec=0, phy_page_addr=0, timestamp=1 nbbt free list: blockN=21, ec=-1, dirty_flag=0 blockN=22, ec=-1, dirty_flag=0 blockN=23, ec=-1, dirty_flag=0 aml_nand_scan_rsv_info 1132: page_num=1 aml_nand_scan_rsv_info 1135 nbbt valid addr: 28 aml_nand_bbt_check 1256 bbt is valid, reading. aml_nand_read_rsv_info:444,read nbbt info to 28 nenv: info size=0x1 max_scan_blk=32, start_blk=24 nenv : phy_blk_addr=25, ec=3, phy_page_addr=0, timestamp=9 nenv free list: blockN=24, ec=3, dirty_flag=1 blockN=26, ec=0, dirty_flag=1 blockN=27, ec=-1, dirty_flag=0 blockN=28, ec=-1, dirty_flag=0 blockN=29, ec=-1, dirty_flag=0 blockN=30, ec=-1, dirty_flag=0 blockN=31, ec=-1, dirty_flag=0 aml_nand_scan_rsv_info 1132: page_num=32 aml_nand_scan_rsv_info 1135 nenv valid addr: 33 nkey: info size=0x8000 max_scan_blk=40, start_blk=32 nkey : phy_blk_addr=33, ec=0, phy_page_addr=0, timestamp=2 nkey free list: blockN=32, ec=0, dirty_flag=1 blockN=34, ec=-1, dirty_flag=0 blockN=35, ec=-1, dirty_flag=0 blockN=36, ec=-1, dirty_flag=0 blockN=37, ec=-1, dirty_flag=0 blockN=38, ec=-1, dirty_flag=0 blockN=39, ec=-1, dirty_flag=0 aml_nand_scan_rsv_info 1132: page_num=16 aml_nand_scan_rsv_info 1135 nkey valid addr: 42 ndtb: info size=0x2 max_scan_blk=44, start_blk=40 ndtb : phy_blk_addr=40, ec=0, phy_page_addr=0, timestamp=1 ndtb free list: blockN=41, ec=-1, dirty_flag=0 blockN=42, ec=-1, dirty_flag=0 blockN=43, ec=-1, dirty_flag=0 aml_nand_scan_rsv_info 1132: page_num=64 aml_nand_scan_rsv_info 1135 ndtb valid addr: 50 nddr: info size=0x800 max_scan_blk=46, start_blk=44 nddr : phy_blk_addr=-1, ec=0, phy_page_addr=0, timestamp=0 nddr free list: blockN=44, ec=-1, dirty_flag=0 blockN=45, ec=-1, dirty_flag=0 aml_nand_scan_rsv_info 1132: page_num=1 nddr valid addr: fffe aml_nand_rsv_info_check_except_bbt 1226 NO nddr exist tpl: off 8388608, size 8388608 NAND bbt detect factory Bad block at c00 NAND bbt detect factory Bad block at c02 Creating 7 MTD partitions on "A revision NAND 2Gib TC58NVG1S3HBAI4 ": 0x0080-0x0100 : "tpl" 0x0100-0x01a0 : "recovery" 0x01a0-0x0260 : "boot" 0x0260-0x0360 : "system" 0x0360-0x07a0 : "chrome" 0x07a0-0x07e0 : "factory"
Re: [PATCH] imx8m{m,n}_venice: update env memory layout
Hi Tim, [Adding Tom on Cc] On Sat, Feb 26, 2022 at 6:37 PM Tim Harvey wrote: > > On Sat, Feb 26, 2022 at 5:15 AM Fabio Estevam wrote: > > > > Hi Tim, > > > > On Fri, Feb 18, 2022 at 8:20 PM Tim Harvey wrote: > > > > > > Update distro config env memory layout: > > > - loadaddr=0x4820 allows for 130MB area for uncompressing (ie FIT > > >images, kernel_comp_addr_r) > > > - fdt_addr_r = loadaddr + 128MB - allows for 128MB kernel > > > - scriptaddr = fdt_addr_r + 512KB - allows for 512KB fdt > > > - ramdisk_addr_r = scriptaddr + 512KB - allows for 512KB script > > > > > > Signed-off-by: Tim Harvey > > > > What about following the suggestion from Heiko at: > > https://patchwork.ozlabs.org/project/uboot/patch/20220216122514.1659879-2-heiko.thi...@gmail.com/ > > Fabio, > > I don't understand why include/configs/ti_armv7_common.h is always > recommended when it comes to address maps. The comment there doesn't > read that well and there are several addresses that I believe are > outdated or uncommon (fdtaddr,rdaddr are outdated and it seems > loadaddr could be used for dtboaddr) > > In my opinion what is relevant when choosing an addressing scheme is > how much space you want to allow for kernel, fdt, scripts, ramdisk. > > ti_armv7_common.h allows for > kernel/loadaddr:96M (too small in my opinion on modern boards) > fdt:512M (makes sense) > script:32M (excessive, and I don't understand why this is below > loadaddr vs stacked on top of loadaddr like fdt) > ramdisk: depends on mem size as its the highest addr (makes sense) > > For my more modern boards with typically 1-4GiB of dram, I wanted to > allow for more than 96M for a kernel (kernel+ramdisk, fit image etc) > as I commonly exceed 96M when using a buildroot kernel+rootfs that has > something like gstreamer support for imx6/imx8 which is why I came up > with a different scheme which I document well in the commit log as > - loadaddr=0x4820 allows for 130MB area for uncompressing (ie FIT >images, kernel_comp_addr_r) > - fdt_addr_r = loadaddr + 128MB - allows for 128MB kernel > - scriptaddr = fdt_addr_r + 512KB - allows for 512KB fdt > - ramdisk_addr_r = scriptaddr + 512KB - allows for 512KB script You bring good points and maybe we could use include/configs/imx8mm_venice.h as a good standard to follow :-) Reviewed-by: Fabio Estevam
[PATCH] qemu-arm: Enable NVMe for distro boot
We already support the NVMe commands and PCIe backend in the QEMU target, so let's make it easy for anyone to consume them and enable NVMe distro boot along the way! With this patch, I can put an NVMe backed disk image into my QEMU VM and have it automatically load a UEFI target blob. Signed-off-by: Alexander Graf --- include/configs/qemu-arm.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h index d45f606860..7ae71e0029 100644 --- a/include/configs/qemu-arm.h +++ b/include/configs/qemu-arm.h @@ -39,6 +39,12 @@ # define BOOT_TARGET_VIRTIO(func) #endif +#if CONFIG_IS_ENABLED(CMD_NVME) +# define BOOT_TARGET_NVME(func) func(NVME, nvme, 0) +#else +# define BOOT_TARGET_NVME(func) +#endif + #if CONFIG_IS_ENABLED(CMD_DHCP) # define BOOT_TARGET_DHCP(func) func(DHCP, dhcp, na) #else @@ -49,6 +55,7 @@ BOOT_TARGET_USB(func) \ BOOT_TARGET_SCSI(func) \ BOOT_TARGET_VIRTIO(func) \ + BOOT_TARGET_NVME(func) \ BOOT_TARGET_DHCP(func) #include -- 2.32.0
[PATCH] efi_loader: Ignore DT when ACPI is on
For targets that enable ACPI, we should not pass Device Trees into
the payload. However, our distro boot logic always passes the builtin
DT as an argument.
To make it easy to use ACPI with distro boot, let's just ignore the DT
argument to bootefi when ACPI is enabled. That way, we can successfully
distro boot payloads on ACPI enabled targets.
Signed-off-by: Alexander Graf
---
cmd/bootefi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 94d18ca73f..2c9bc0dcd2 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -265,8 +265,8 @@ efi_status_t efi_install_fdt(void *fdt)
*/
#if CONFIG_IS_ENABLED(GENERATE_ACPI_TABLE)
if (fdt) {
- log_err("ERROR: can't have ACPI table and device tree.\n");
- return EFI_LOAD_ERROR;
+ log_warning("WARNING: Can't have ACPI table and device tree -
ignoring DT.\n");
+ return EFI_SUCCESS;
}
#else
bootm_headers_t img = { 0 };
--
2.32.0
Re: dm driver probe and dm question
On 2/26/22 20:11, Tim Harvey wrote:
On Fri, Feb 25, 2022 at 11:31 PM Heinrich Schuchardt wrote:
On 2/26/22 02:51, Tim Harvey wrote:
Greetings,
I've got an octeontx board which uses driver model
(CONFIG_DM/CONFIG_DM_I2C) but I find that the 'i2c_octeon' driver does
not probe automatically on boot until I do something like an 'i2c dev
0 && i2c probe'.
What would cause the i2c_octeon driver to not automatically probe?
It is the general design of U-Boot's driver model to use late probing.
This reduces the boot time.
Cf.
https://u-boot.readthedocs.io/en/latest/develop/driver-model/design.html#driver-lifecycle
Heinrich,
Thanks for the explanation. Is there any way to make a dm driver force
its probe in the case of being vital for board startup? How does this
work for UCLASS_PMIC devices that are vital to board operation?
Many board files call pmic_get() and pmic_probe() which triggers probing
the PMIC driver, e.g.
board/freescale/common/mc34vr500.c:
p = pmic_get("MC34VR500");
...
ret = pmic_probe(p);
Drivers may set
.flags = DM_FLAG_PRE_RELOC
In the device-tree you could use u-boot,dm-pre-reloc.
See
https://u-boot.readthedocs.io/en/latest/develop/driver-model/fdt-fixup.html?highlight=Pre-Relocation%20Support
Best regards
Heinrich
Re: [PATCH v5 3/4] test/py: Handle expected reboot while booting sandbox
On 2/26/22 19:37, Simon Glass wrote: Hi Masami, On Tue, 15 Feb 2022 at 23:16, Masami Hiramatsu wrote: Add expected_reset optional argument to ConsoleBase::ensure_spawned(), ConsoleBase::restart_uboot() and ConsoleSandbox::restart_uboot_with_flags() so that it can handle a reset while the 1st boot process after main boot logo before prompt correctly. Signed-off-by: Masami Hiramatsu --- Changes in v5: - Rename parameter to expect_reset and update the description to clarify the reset will happen between main boot and the command prompt. --- test/py/u_boot_console_base.py| 48 ++--- test/py/u_boot_console_sandbox.py |7 - 2 files changed, 33 insertions(+), 22 deletions(-) Didn't I already comment on this patch? Why did it come back? Dear Simon, The discussion is in https://patchwork.ozlabs.org/project/uboot/patch/164491595065.536855.9457820061065514578.stgit@localhost/ You suggested: "We have a means to avoid actually doing the reset, see the reset driver." We need a real reset on the sandbox and no fake reset as already said in the referenced thread. Best regards Heinrich Regards, Simon
