Re: [RFC PATCH 1/1] efi_loader: Enable RISCV_EFI_BOOT_PROTOCOL support
Am 26. Januar 2022 15:01:56 MEZ schrieb Jessica Clarke :
>On 26 Jan 2022, at 11:06, Sunil V L wrote:
>>
>> This adds support for new RISCV_EFI_BOOT_PROTOCOL to
>> communicate the boot hart ID to bootloader/kernel on RISC-V
>> UEFI platforms.
>>
>> Signed-off-by: Sunil V L
>> ---
>> include/efi_api.h | 4 +++
>> include/efi_loader.h | 2 ++
>> include/efi_riscv.h| 16 +
>> lib/efi_loader/Kconfig | 7
>> lib/efi_loader/Makefile| 1 +
>> lib/efi_loader/efi_riscv.c | 69 ++
>> lib/efi_loader/efi_setup.c | 6
>> 7 files changed, 105 insertions(+)
>> create mode 100644 include/efi_riscv.h
>> create mode 100644 lib/efi_loader/efi_riscv.c
>>
>> diff --git a/include/efi_api.h b/include/efi_api.h
>> index 8d5d835bd0..f123d0557c 100644
>> --- a/include/efi_api.h
>> +++ b/include/efi_api.h
>> @@ -438,6 +438,10 @@ struct efi_runtime_services {
>> EFI_GUID(0x607f766c, 0x7455, 0x42be, 0x93, \
>> 0x0b, 0xe4, 0xd7, 0x6d, 0xb2, 0x72, 0x0f)
>>
>> +#define RISCV_EFI_BOOT_PROTOCOL_GUID \
>> +EFI_GUID(0xccd15fec, 0x6f73, 0x4eec, 0x83, \
>> + 0x95, 0x3e, 0x69, 0xe4, 0xb9, 0x40, 0xbf)
>> +
>> /**
>> * struct efi_configuration_table - EFI Configuration Table
>> *
>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>> index 701efcd2b6..1fa75b40fe 100644
>> --- a/include/efi_loader.h
>> +++ b/include/efi_loader.h
>> @@ -527,6 +527,8 @@ efi_status_t efi_disk_register(void);
>> efi_status_t efi_rng_register(void);
>> /* Called by efi_init_obj_list() to install EFI_TCG2_PROTOCOL */
>> efi_status_t efi_tcg2_register(void);
>> +/* Called by efi_init_obj_list() to install RISCV_EFI_BOOT_PROTOCOL */
>> +efi_status_t efi_riscv_register(void);
>> /* Called by efi_init_obj_list() to do initial measurement */
>> efi_status_t efi_tcg2_do_initial_measurement(void);
>> /* measure the pe-coff image, extend PCR and add Event Log */
>> diff --git a/include/efi_riscv.h b/include/efi_riscv.h
>> new file mode 100644
>> index 00..6beb2637f6
>> --- /dev/null
>> +++ b/include/efi_riscv.h
>> @@ -0,0 +1,16 @@
>> +/* SPDX-License-Identifier: GPL-2.0+ */
>> +/*
>> + * RISCV_EFI_BOOT_PROTOCOL
>> + *
>> + * Copyright (c) 2022 Ventana Micro Systems Inc
>> + */
>> +
>> +#include
>> +
>> +#define RISCV_EFI_BOOT_PROTOCOL_REVISION 0x0001
>> +
>> +struct riscv_efi_boot_protocol {
>> +u64 revision;
>> +efi_status_t (EFIAPI *get_boot_hartid) (struct riscv_efi_boot_protocol
>> *this,
>> +efi_uintn_t *boot_hartid);
>> +};
>> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
>> index 24f9a2bb75..77ba6a7ea1 100644
>> --- a/lib/efi_loader/Kconfig
>> +++ b/lib/efi_loader/Kconfig
>> @@ -369,4 +369,11 @@ config EFI_ESRT
>> help
>>Enabling this option creates the ESRT UEFI system table.
>>
>> +config EFI_RISCV_BOOT_PROTOCOL
>> +bool "RISCV_EFI_BOOT_PROTOCOL support"
>> +default y
>
>Why would you ever turn it off for a RISC-V EFI system?
We don't need the protocol on ARM. So we want a configuration symbol for it.
The feature is experimental as there is no ratified specification requiring it.
So it is ok to be able to disable it. Anyway it defaults to yes on RISC-V.
We still put the boot-hartid into the device-tree as elder kernels need it and
future kernels may support this due to the legacy entry point. To minimize the
code size on constrained devices it may be necessary to disable the protocol.
>
>> +depends on RISCV
>> +help
>> + Provide a RISCV_EFI_BOOT_PROTOCOL implementation on RISC-V platform.
>> +
>> endif
>> diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
>> index fd344cea29..b2c664d108 100644
>> --- a/lib/efi_loader/Makefile
>> +++ b/lib/efi_loader/Makefile
>> @@ -62,6 +62,7 @@ obj-$(CONFIG_GENERATE_ACPI_TABLE) += efi_acpi.o
>> obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += efi_smbios.o
>> obj-$(CONFIG_EFI_RNG_PROTOCOL) += efi_rng.o
>> obj-$(CONFIG_EFI_TCG2_PROTOCOL) += efi_tcg2.o
>> +obj-$(CONFIG_EFI_RISCV_BOOT_PROTOCOL) += efi_riscv.o
>> obj-$(CONFIG_EFI_LOAD_FILE2_INITRD) += efi_load_initrd.o
>> obj-$(CONFIG_EFI_SIGNATURE_SUPPORT) += efi_signature.o
>>
>> diff --git a/lib/efi_loader/efi_riscv.c b/lib/efi_loader/efi_riscv.c
>> new file mode 100644
>> index 00..91b8d2b927
>> --- /dev/null
>> +++ b/lib/efi_loader/efi_riscv.c
>> @@ -0,0 +1,69 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Defines APIs that allow an OS to interact with UEFI firmware to query
>> + * information about the boot hart ID.
>> + *
>> + * Copyright (c) 2022, Ventana Micro Systems Inc
>> + */
>> +
>> +#define LOG_CATEGORY LOGC_EFI
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>> +static const efi_guid_t efi_guid_riscv_boot_protocol =
>> RISCV_EFI_BOOT_PROTOCOL_GUID;
>> +static efi_uintn_t hartid;
>> +
>> +/**
>> + * efi_riscv_get_boot_hartid()
[PATCH v2 4/4] doc: qemu-riscv: Update documentation for QEMU spike machine
We can now use same U-Boot images on both QEMU virt machine and QEMU spike machine so let's update the QEMU RISC-V documentation. Signed-off-by: Anup Patel --- doc/board/emulation/qemu-riscv.rst | 48 -- 1 file changed, 32 insertions(+), 16 deletions(-) diff --git a/doc/board/emulation/qemu-riscv.rst b/doc/board/emulation/qemu-riscv.rst index 4b8e104a21..0a4b121687 100644 --- a/doc/board/emulation/qemu-riscv.rst +++ b/doc/board/emulation/qemu-riscv.rst @@ -4,16 +4,21 @@ QEMU RISC-V === -QEMU for RISC-V supports a special 'virt' machine designed for emulation and -virtualization purposes. This document describes how to run U-Boot under it. -Both 32-bit and 64-bit targets are supported, running in either machine or -supervisor mode. +QEMU for RISC-V supports a special 'virt' machine and 'spike' machine designed +for emulation and virtualization purposes. This document describes how to run +U-Boot under it. Both 32-bit and 64-bit targets are supported, running in +either machine or supervisor mode. The QEMU virt machine models a generic RISC-V virtual machine with support for the VirtIO standard networking and block storage devices. It has CLINT, PLIC, 16550A UART devices in addition to VirtIO and it also uses device-tree to pass -configuration information to guest software. It implements RISC-V privileged -architecture spec v1.10. +configuration information to guest software. It implements the latest RISC-V +privileged architecture. + +The QEMU spike machine models a minimalistic RISC-V virtual machine with +only CLINT and HTIF devices. It also uses device-tree to pass configuration +information to guest software and implements the latest RISC-V privileged +architecture. Building U-Boot --- @@ -38,13 +43,17 @@ Running U-Boot -- The minimal QEMU command line to get U-Boot up and running is: -- For 32-bit RISC-V:: +- For 32-bit RISC-V virt machine:: -qemu-system-riscv32 -nographic -machine virt -bios u-boot +qemu-system-riscv32 -nographic -machine virt -bios u-boot.bin -- For 64-bit RISC-V:: +- For 64-bit RISC-V virt machine:: + +qemu-system-riscv64 -nographic -machine virt -bios u-boot.bin + +- For 64-bit RISC-V spike machine:: -qemu-system-riscv64 -nographic -machine virt -bios u-boot +qemu-system-riscv64 -nographic -machine spike -bios u-boot.bin The commands above create targets with 128MiB memory by default. A freely configurable amount of RAM can be created via the '-m' @@ -55,6 +64,7 @@ the new setting. For instructions on how to run U-Boot in supervisor mode on QEMU with OpenSBI, see the documentation available with OpenSBI: https://github.com/riscv/opensbi/blob/master/docs/platform/qemu_virt.md +https://github.com/riscv/opensbi/blob/master/docs/platform/spike.md These have been tested in QEMU 5.0.0. @@ -77,8 +87,9 @@ supported by U-Boot. Clone the OpenSBI repository and run the following command. See the OpenSBI documentation for full details: https://github.com/riscv/opensbi/blob/master/docs/platform/qemu_virt.md +https://github.com/riscv/opensbi/blob/master/docs/platform/spike.md -To make the FW_DYNAMIC binary (build/platform/qemu/virt/firmware/fw_dynamic.bin) +To make the FW_DYNAMIC binary (build/platform/generic/firmware/fw_dynamic.bin) available to U-Boot, either copy it into the U-Boot root directory or specify its location with the OPENSBI environment variable. Afterwards, compile U-Boot with the following commands. @@ -96,17 +107,22 @@ with the following commands. The minimal QEMU commands to run U-Boot SPL in both 32-bit and 64-bit configurations are: -- For 32-bit RISC-V:: +- For 32-bit RISC-V virt machine:: -qemu-system-riscv32 -nographic -machine virt -bios spl/u-boot-spl \ +qemu-system-riscv32 -nographic -machine virt -bios spl/u-boot-spl.bin \ -device loader,file=u-boot.itb,addr=0x8020 -- For 64-bit RISC-V:: +- For 64-bit RISC-V virt machine:: + +qemu-system-riscv64 -nographic -machine virt -bios spl/u-boot-spl.bin \ +-device loader,file=u-boot.itb,addr=0x8020 + +- For 64-bit RISC-V spike machine:: -qemu-system-riscv64 -nographic -machine virt -bios spl/u-boot-spl \ +qemu-system-riscv64 -nographic -machine spike -bios spl/u-boot-spl.bin \ -device loader,file=u-boot.itb,addr=0x8020 -An attached disk can be emulated by adding:: +An attached disk can be emulated in RISC-V virt machine by adding:: -device ich9-ahci,id=ahci \ -drive if=none,file=riscv64.img,format=raw,id=mydisk \ -- 2.25.1
[PATCH v2 3/4] riscv: qemu: Implement is_flash_available() for MTD NOR
Currently, if MTD NOR is enabled then U-Boot tries to issue flash
commands even when CFI flash DT node is not present. This causes
access fault on RISC-V emulators or ISS which do not emulate CFI
flash. To handle this issue, we implement is_flash_available() for
qemu-riscv board which will return 1 only if CFI flash DT node is
present.
Fixes: d248627f9d42 ("riscv: qemu: Enable MTD NOR flash support")
Signed-off-by: Anup Patel
Reviewed-by: Rick Chen
---
board/emulation/qemu-riscv/qemu-riscv.c | 12
1 file changed, 12 insertions(+)
diff --git a/board/emulation/qemu-riscv/qemu-riscv.c
b/board/emulation/qemu-riscv/qemu-riscv.c
index b0d9dd59b1..ae3b7a3295 100644
--- a/board/emulation/qemu-riscv/qemu-riscv.c
+++ b/board/emulation/qemu-riscv/qemu-riscv.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
#include
@@ -16,6 +17,17 @@
DECLARE_GLOBAL_DATA_PTR;
+#if IS_ENABLED(CONFIG_MTD_NOR_FLASH)
+int is_flash_available(void)
+{
+ if (!ofnode_equal(ofnode_by_compatible(ofnode_null(), "cfi-flash"),
+ ofnode_null()))
+ return 1;
+
+ return 0;
+}
+#endif
+
int board_init(void)
{
/*
--
2.25.1
[PATCH v2 2/4] riscv: qemu: Enable HTIF console support
Enable support for HTIF console so that we can use QEMU RISC-V U-Boot on RISC-V emulators and ISS having it. Signed-off-by: Anup Patel Reviewed-by: Philipp Tomsich Reviewed-by: Rick Chen --- board/emulation/qemu-riscv/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/board/emulation/qemu-riscv/Kconfig b/board/emulation/qemu-riscv/Kconfig index 1bbf1bc84a..f7538bc496 100644 --- a/board/emulation/qemu-riscv/Kconfig +++ b/board/emulation/qemu-riscv/Kconfig @@ -56,6 +56,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy imply DM_SCSI imply SYS_NS16550 imply SIFIVE_SERIAL + imply HTIF_CONSOLE if 64BIT imply SYSRESET imply SYSRESET_CMD_POWEROFF imply SYSRESET_SYSCON -- 2.25.1
[PATCH v2 1/4] serial: Add RISC-V HTIF console driver
Quite a few RISC-V emulators and ISS (including Spike) have host
transfer interface (HTIF) based console. This patch adds HTIF
based console driver for RISC-V platforms which depends totally
on DT node for HTIF register base address.
Signed-off-by: Anup Patel
Reviewed-by: Philipp Tomsich
Reviewed-by: Rick Chen
---
drivers/serial/Kconfig | 8 ++
drivers/serial/Makefile | 1 +
drivers/serial/serial_htif.c | 178 +++
3 files changed, 187 insertions(+)
create mode 100644 drivers/serial/serial_htif.c
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 6c8fdda9a0..345d1881f5 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -866,6 +866,14 @@ config PXA_SERIAL
If you have a machine based on a Marvell XScale PXA2xx CPU you
can enable its onboard serial ports by enabling this option.
+config HTIF_CONSOLE
+ bool "RISC-V HTIF console support"
+ depends on DM_SERIAL && 64BIT
+ help
+ Select this to enable host transfer interface (HTIF) based serial
+ console. The HTIF device is quite common in RISC-V emulators and
+ RISC-V ISS so this driver allows using U-Boot on such platforms.
+
config SIFIVE_SERIAL
bool "SiFive UART support"
depends on DM_SERIAL
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index 8168af640f..52e70aa191 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -73,6 +73,7 @@ obj-$(CONFIG_OWL_SERIAL) += serial_owl.o
obj-$(CONFIG_OMAP_SERIAL) += serial_omap.o
obj-$(CONFIG_MTK_SERIAL) += serial_mtk.o
obj-$(CONFIG_MT7620_SERIAL) += serial_mt7620.o
+obj-$(CONFIG_HTIF_CONSOLE) += serial_htif.o
obj-$(CONFIG_SIFIVE_SERIAL) += serial_sifive.o
obj-$(CONFIG_XEN_SERIAL) += serial_xen.o
diff --git a/drivers/serial/serial_htif.c b/drivers/serial/serial_htif.c
new file mode 100644
index 00..5d2bf0aaeb
--- /dev/null
+++ b/drivers/serial/serial_htif.c
@@ -0,0 +1,178 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2022 Ventana Micro Systems Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define HTIF_DATA_BITS 48
+#define HTIF_DATA_MASK ((1ULL << HTIF_DATA_BITS) - 1)
+#define HTIF_DATA_SHIFT0
+#define HTIF_CMD_BITS 8
+#define HTIF_CMD_MASK ((1ULL << HTIF_CMD_BITS) - 1)
+#define HTIF_CMD_SHIFT 48
+#define HTIF_DEV_BITS 8
+#define HTIF_DEV_MASK ((1ULL << HTIF_DEV_BITS) - 1)
+#define HTIF_DEV_SHIFT 56
+
+#define HTIF_DEV_SYSTEM0
+#define HTIF_DEV_CONSOLE 1
+
+#define HTIF_CONSOLE_CMD_GETC 0
+#define HTIF_CONSOLE_CMD_PUTC 1
+
+#if __riscv_xlen == 64
+# define TOHOST_CMD(dev, cmd, payload) \
+ (((u64)(dev) << HTIF_DEV_SHIFT) | \
+((u64)(cmd) << HTIF_CMD_SHIFT) | \
+(u64)(payload))
+#else
+# define TOHOST_CMD(dev, cmd, payload) ({ \
+ if ((dev) || (cmd)) \
+ __builtin_trap(); \
+ (payload); })
+#endif
+#define FROMHOST_DEV(fromhost_value) \
+ ((u64)((fromhost_value) >> HTIF_DEV_SHIFT) & HTIF_DEV_MASK)
+#define FROMHOST_CMD(fromhost_value) \
+ ((u64)((fromhost_value) >> HTIF_CMD_SHIFT) & HTIF_CMD_MASK)
+#define FROMHOST_DATA(fromhost_value) \
+ ((u64)((fromhost_value) >> HTIF_DATA_SHIFT) & HTIF_DATA_MASK)
+
+struct htif_plat {
+ void *fromhost;
+ void *tohost;
+ int console_char;
+};
+
+static void __check_fromhost(struct htif_plat *plat)
+{
+ u64 fh = readq(plat->fromhost);
+
+ if (!fh)
+ return;
+ writeq(0, plat->fromhost);
+
+ /* this should be from the console */
+ if (FROMHOST_DEV(fh) != HTIF_DEV_CONSOLE)
+ __builtin_trap();
+ switch (FROMHOST_CMD(fh)) {
+ case HTIF_CONSOLE_CMD_GETC:
+ plat->console_char = 1 + (u8)FROMHOST_DATA(fh);
+ break;
+ case HTIF_CONSOLE_CMD_PUTC:
+ break;
+ default:
+ __builtin_trap();
+ }
+}
+
+static void __set_tohost(struct htif_plat *plat,
+u64 dev, u64 cmd, u64 data)
+{
+ while (readq(plat->tohost))
+ __check_fromhost(plat);
+ writeq(TOHOST_CMD(dev, cmd, data), plat->tohost);
+}
+
+static int htif_serial_putc(struct udevice *dev, const char ch)
+{
+ struct htif_plat *plat = dev_get_plat(dev);
+
+ __set_tohost(plat, HTIF_DEV_CONSOLE, HTIF_CONSOLE_CMD_PUTC, ch);
+ return 0;
+}
+
+static int htif_serial_getc(struct udevice *dev)
+{
+ int ch;
+ struct htif_plat *plat = dev_get_plat(dev);
+
+ if (plat->console_char < 0)
+ __check_fromhost(plat);
+
+ if (plat->console_char >= 0) {
+ ch = plat->console_char;
+ plat->console_char = -1;
+ __set_tohost(plat, HTIF_DEV_CONSOLE, HTIF_CONSOL
[PATCH v2 0/4] QEMU spike machine support for U-Boot
We can use same U-Boot binary compiled using qemu-riscv64_smode_defconfig on QEMU virt machine and QEMU spike machine. To achieve this, we need HTIF console support for U-Boot QEMU RISC-V board hence this series. To test this series with latest OpenSBI, we can use the following command: qemu-system-riscv64 -M spike -m 256M -display none -serial stdio \ -bios opensbi/build/platform/generic/firmware/fw_jump.bin -kernel \ ./u-boot/u-boot.bin These patch can be found in qemu_riscv_htif_v2 branch at: https://github.com/avpatel/u-boot.git Changes since v1: - Use ofnode_by_compatible() in PATCH3 - Updated QEMU RISC-V documentation in PATCH4 Anup Patel (4): serial: Add RISC-V HTIF console driver riscv: qemu: Enable HTIF console support riscv: qemu: Implement is_flash_available() for MTD NOR doc: qemu-riscv: Update documentation for QEMU spike machine board/emulation/qemu-riscv/Kconfig | 1 + board/emulation/qemu-riscv/qemu-riscv.c | 12 ++ doc/board/emulation/qemu-riscv.rst | 48 --- drivers/serial/Kconfig | 8 ++ drivers/serial/Makefile | 1 + drivers/serial/serial_htif.c| 178 6 files changed, 232 insertions(+), 16 deletions(-) create mode 100644 drivers/serial/serial_htif.c -- 2.25.1
Re: [PATCH v2] power: zynqmp: Add power domain driver for ZynqMP
On 1/20/22 16:25, Michal Simek wrote:
> Driver should be enabled by CONFIG_POWER_DOMAIN=y and
> CONFIG_ZYNQMP_POWER_DOMAIN=y. Power domain driver doesn't have own DT node
> but it uses zynqmp firmware DT node that's why there is a need to bind
> driver when firmware node is found.
>
> Driver itself is simple. It is sending pmufw config object overlay for
> enabling access to device which is done in ...domain_request().
> In ...domain_on() capabilities are passed and node is requested.
> This should be bare minimum of required to get power domain driver working.
>
> Signed-off-by: Michal Simek
> ---
>
> Changes in v2:
> - s/binded/bound/ - Reported by gvb
>
> MAINTAINERS| 1 +
> drivers/firmware/firmware-zynqmp.c | 18 +
> drivers/power/domain/Kconfig | 9 +++
> drivers/power/domain/Makefile | 1 +
> drivers/power/domain/zynqmp-power-domain.c | 91 ++
> include/zynqmp_firmware.h | 31
> 6 files changed, 151 insertions(+)
> create mode 100644 drivers/power/domain/zynqmp-power-domain.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 64648c29219f..fca5227d0b93 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -628,6 +628,7 @@ F:drivers/mtd/nand/raw/zynq_nand.c
> F: drivers/net/phy/xilinx_phy.c
> F: drivers/net/zynq_gem.c
> F: drivers/phy/phy-zynqmp.c
> +F: drivers/power/domain/zynqmp-power-domain.c
> F: drivers/serial/serial_zynq.c
> F: drivers/reset/reset-zynqmp.c
> F: drivers/rtc/zynqmp_rtc.c
> diff --git a/drivers/firmware/firmware-zynqmp.c
> b/drivers/firmware/firmware-zynqmp.c
> index 839203ec82a1..5a618e490725 100644
> --- a/drivers/firmware/firmware-zynqmp.c
> +++ b/drivers/firmware/firmware-zynqmp.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -226,8 +227,25 @@ static const struct udevice_id zynqmp_firmware_ids[] = {
> { }
> };
>
> +static int zynqmp_firmware_bind(struct udevice *dev)
> +{
> + int ret;
> + struct udevice *child;
> +
> + if (IS_ENABLED(CONFIG_ZYNQMP_POWER_DOMAIN)) {
> + ret = device_bind_driver_to_node(dev, "zynqmp_power_domain",
> + "zynqmp_power_domain",
> + dev_ofnode(dev), &child);
> + if (ret)
> + printf("zynqmp power domain driver is not bound\n");
Doesn't need to handle error case? And how about displaying an error value(ret)?
> + }
> +
> + return dm_scan_fdt_dev(dev);
> +}
> +
> U_BOOT_DRIVER(zynqmp_firmware) = {
> .id = UCLASS_FIRMWARE,
> .name = "zynqmp_firmware",
> .of_match = zynqmp_firmware_ids,
> + .bind = zynqmp_firmware_bind,
> };
> diff --git a/drivers/power/domain/Kconfig b/drivers/power/domain/Kconfig
> index 9aea5fcdf082..93d2599d83c2 100644
> --- a/drivers/power/domain/Kconfig
> +++ b/drivers/power/domain/Kconfig
> @@ -88,4 +88,13 @@ config TI_POWER_DOMAIN
> help
> Generic power domain implementation for TI K3 devices.
>
> +config ZYNQMP_POWER_DOMAIN
> + bool "Enable the Xilinx ZynqMP Power domain driver"
> + depends on POWER_DOMAIN && ZYNQMP_FIRMWARE
> + help
> + Generic power domain implementation for Xilinx ZynqMP devices.
> + The driver should be enabled when system starts in very minimal
> + configuration and it is extended at run time. Then enabling
> + the driver will ensure that PMUFW enable access to requested IP.
> +
> endmenu
> diff --git a/drivers/power/domain/Makefile b/drivers/power/domain/Makefile
> index 530ae35671a2..7c8af67dbd64 100644
> --- a/drivers/power/domain/Makefile
> +++ b/drivers/power/domain/Makefile
> @@ -16,3 +16,4 @@ obj-$(CONFIG_SANDBOX_POWER_DOMAIN) +=
> sandbox-power-domain-test.o
> obj-$(CONFIG_TEGRA186_POWER_DOMAIN) += tegra186-power-domain.o
> obj-$(CONFIG_TI_SCI_POWER_DOMAIN) += ti-sci-power-domain.o
> obj-$(CONFIG_TI_POWER_DOMAIN) += ti-power-domain.o
> +obj-$(CONFIG_ZYNQMP_POWER_DOMAIN) += zynqmp-power-domain.o
> diff --git a/drivers/power/domain/zynqmp-power-domain.c
> b/drivers/power/domain/zynqmp-power-domain.c
> new file mode 100644
> index ..0a6cb67a8acc
> --- /dev/null
> +++ b/drivers/power/domain/zynqmp-power-domain.c
> @@ -0,0 +1,91 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2021, Xilinx. Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#define NODE_ID_LOCATION 5
> +
> +static unsigned int xpm_configobject[] = {
> + /**/
Remove "/******/". It doesn't need to add.
> + /* HEADER */
> + 2, /* Number of remaining words in the header */
> + 1, /* Number of sections included in config object */
> + PM_CONFIG_OBJECT_TYPE_OVERLAY, /*
Please pull u-boot-dm
Hi Tom, https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/10771 The following changes since commit 6146cd62aedc4849fec66f10ab0aa57f1dc64b8e: Merge branch '2022-01-24-assorted-updates' (2022-01-25 08:01:43 -0500) are available in the Git repository at: git://git.denx.de/u-boot-dm.git tags/dm-pull-26jan22 for you to fetch changes up to 2d2384bbaff0ab84c868b553c74048a5f6acc9e3: tools: mkimage: Show where signatures/keys are written (2022-01-26 08:50:44 -0700) acpi refactoring to allow non-x86 use binman support for bintools (binary tools) minor tools improvements in preparation for FDT signing various minor fixes and improvements Heiko Thiery (1): binman: doc: fix typo for u-boot-tpl Heinrich Schuchardt (2): sandbox: sandbox_serial_pending depends on DM_VIDEO sandbox: eth-raw: fix building with musl library Patrice Chotard (1): dm: Fix OF_BAD_ADDR definition Rasmus Villemoes (1): introduce CONFIG_DEVICE_TREE_INCLUDES Sean Anderson (1): usb: Use the first available device for ehci_gadget Simon Glass (83): x86: Allow any arch to generate ACPI tables x86: Move the acpi table to generic global_data arm: Allow supporting ACPI-table generation x86: Tidy up use of CONFIG_ACPIGEN sandbox: Allow building with GENERATE_ACPI_TABLE efi: Correct call to write_acpi_tables() efi: Correct address handling with ACPI tables acpi: Use finer-grained control of ACPI-table generation acpi: Allow include files within the board directory acpi: Move acpi_fill_header() to the generic header acpi: Add a table start acpi: Add a linker list for ACPI tables x86: acpi: Split out context creation from base tables x86: Use the ACPI table writer x86: Move base tables to a writer function x86: Move FACS table to a writer function x86: Move DSDT table to a writer function x86: Move GNVS table to a writer function x86: Move FADT table to a writer function x86: Move FACP table into separate functions x86: Move SSDT table to a writer function x86: Move TPM2 table to a writer function x86: Move MADT table to a writer function x86: Move TCPA table to a writer function x86: Move CSRT table to a writer function x86: acpi: Update acpi_fill_csrt() to use acpi_ctx x86: Move device-specific ACPI tables to a writer function x86: Move acpi_get_rsdp_addr() ACPI tables to the writer acpi: Collect tables in the acpi_item list acpi: Tidy up the item list acpi: Tidy up the table list doc: Add usage information for the acpi command acpi: Add some tables needed by ARM devices acpi: Add myself as maintainer Makefile: Fake external blobs by default with binman binman: Tweak elf tests for a toolchain change mkimage: Show the external-offset error binman: Expand the external FIT test a little patman: Allow running a tool and returning the full result buildman: Move the download function to tools patman: Tidy up the download function a little patman: Add a function to find a tool on the path binman: Drop the image name from the fake-blob message binman: Allow faked blobs in blob-ext-list binman: Correct path for fip_util binman: Add installation instructions binman: Add support for bintools binman: Plumb in support for bintools binman: Add tests for bintool binman: Add a bintool implementation for cbfstool binman: Add a bintool implementation for fiptool binman: Add a bintool implementation for futility binman: Add a bintool implementation for ifwitool binman: Add a bintool implementation for mkimage binman: Enable bintool tests including cmdline processing binman: Convert to using the CBFS bintool binman: Convert to using the FIP bintool binman: Convert to using the futility bintool binman: Convert to using the ifwitool bintool binman: Convert to using the mkimage bintool binman: Move compression into binman binman: Tidy up pylint warnings in comp_util binman: Add a bintool implementation for lz4 binman: Convert to using the lz4 bintool binman: Add a bintool implementation for lzma_alone binman: Convert to using the lzma_alone bintool binman: Plumb in support for missing bintools binman: Complete test coverage of comp_util binman: Add a command to generate bintool docs binman: Add documentation for bintools binman: Document the __bss_size symbol error rsa: Add debugging for failure cases fit_check_sign: Update help to mention the key is in a dtb tools: Move copyfile() into a common file tools: Avoid leaving extra data at the end o
[PATCH 1/1] doc: describe MSEL settings for booting from SD card
unmatched.rst describes booting from SD card or from SPI. But only for booting from SPI the boot selection settings are described. Add the missing information. Fix a typo 'uSD'. Signed-off-by: Heinrich Schuchardt --- doc/board/sifive/unmatched.rst | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/doc/board/sifive/unmatched.rst b/doc/board/sifive/unmatched.rst index b52a1f690c..24a889991c 100644 --- a/doc/board/sifive/unmatched.rst +++ b/doc/board/sifive/unmatched.rst @@ -20,8 +20,11 @@ The support for following drivers are already enabled: 4. SiFive SPI Driver. 5. MMC SPI Driver for MMC/SD support. -Booting from uSD using U-Boot SPL -- +Booting from micro SD card using U-Boot SPL +--- + +Booting from an SD card requires that the boot mode selection DIP switches +MSEL[3:0] are set to 1011. Building -- 2.33.1
Re: [RFC 1/2] drivers: mmc: write protect active boot area after mmc init.
Hi Paul
On 1/27/22 10:23, Paul Liu wrote:
> Hi Jaehoon,
>
> There are 2 boot partitions on eMMC. So the active one is write-protected.
> Users can write the new firmware to another boot partition (inactive) which
> is not write-protected.
> And then switch it on.
I know there are two boot partitions. Well, it seems that is for A/B switching
scheme, right?
>
> In U-boot, execute "mmc wp" write-protect all of the boot partitions.
> Maybe we can add an additional command that just write-protect only one
> boot partition.
>
> Yours,
> Paul
>
>
> On Thu, 27 Jan 2022 at 07:24, Jaehoon Chung wrote:
>
>> Hi,
>>
>> On 1/25/22 22:55, Ying-Chun Liu wrote:
>>> From: "Ying-Chun Liu (PaulLiu)"
>>>
>>> This commit implements write protection for active boot partition for
>>> eMMC. The active boot partition is write protected, and it is still
>>> able to write to the inactive boot partition.
>>
>> It seems that you want to enable Write-protect about boot partition
>> without additional command, right?
>> After initialized eMMC, how to update image into boot partition?
>>
>> Best Regards,
>> Jaehoon Chung
>>
>>>
>>> Signed-off-by: Ying-Chun Liu (PaulLiu)
>>> Cc: Peng Fan
>>> Cc: Jaehoon Chung
>>> ---
>>> drivers/mmc/Kconfig | 10
>>> drivers/mmc/mmc.c | 58 +
>>> 2 files changed, 68 insertions(+)
>>>
>>> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
>>> index e0927ce1c9..c4bae743e6 100644
>>> --- a/drivers/mmc/Kconfig
>>> +++ b/drivers/mmc/Kconfig
>>> @@ -100,6 +100,16 @@ config MMC_HW_PARTITIONING
>>> This adds a command and an API to do hardware partitioning on
>> eMMC
>>> devices.
>>>
>>> +config MMC_WRITE_PROTECT_ACTIVE_BOOT
>>> + bool "Write protection for active boot partition (eMMC)"
>>> + depends on MMC_HW_PARTITIONING
>>> + default n
>>> + help
>>> + Write protection for active boot partition when mmc initialized.
>>> + This option protects the active boot partition so that it cannot
>>> + be written. But it is still able to write to the inactive boot
>>> + partition.
>>> +
>>> config SUPPORT_EMMC_RPMB
>>> bool "Support eMMC replay protected memory block (RPMB)"
>>> imply CMD_MMC_RPMB
>>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>>> index 4d9871d69f..8620918749 100644
>>> --- a/drivers/mmc/mmc.c
>>> +++ b/drivers/mmc/mmc.c
>>> @@ -860,6 +860,60 @@ int mmc_boot_wp(struct mmc *mmc)
>>> return mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_BOOT_WP, 1);
>>> }
>>>
>>> +/**
>>> + * mmc_boot_wp_single_partition() - set write protection to a boot
>> partition.
>>> + *
>>> + * This function sets a single boot partition to protect and leave the
>>> + * other partition writable.
>>> + *
>>> + * @param mmc the mmc device.
>>> + * @param partition 0 - first boot partition, 1 - second boot partition.
>>> + */
>>> +int mmc_boot_wp_single_partition(struct mmc *mmc, int partition)
>>> +{
>>> + u8 value;
>>> + int ret;
>>> +
>>> + value = 1;
>>> +
>>> + if (partition == 0) {
>>> + value |= 0x80;
Use macro instead of 0x80.
>>> + ret = mmc_switch(mmc,
>>> + EXT_CSD_CMD_SET_NORMAL,
>>> + EXT_CSD_BOOT_WP,
>>> + value);
>>> + } else if (partition == 1) {
>>> + value |= 0x80;
>>> + value |= 0x02;
Ditto.
>>> + ret = mmc_switch(mmc,
>>> + EXT_CSD_CMD_SET_NORMAL,
>>> + EXT_CSD_BOOT_WP,
>>> + value);
>>> + } else {
>>> + ret = mmc_boot_wp(mmc);
>>> + }
how aboutusing switch statements?
switch (partition) {
case 0:
value |= 0x80;
case 1:
value |= 0x02;
mmc_switch();
break;
default:
mmc_boot_wp();
}
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +/**
>>> + * mmc_boot_wp_active_partition() - set write protection to active boot
>>> + * partition.
>>> + *
>>> + * @param mmc the mmc device.
>>> + */
>>> +static int mmc_boot_wp_active_partition(struct mmc *mmc)
>>> +{
>>> + u8 part;
>>> +
>>> + if (mmc->part_config == MMCPART_NOAVAILABLE)
>>> + return -EOPNOTSUPP;
>>> +
>>> + part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
>>> +
>>> + return mmc_boot_wp_single_partition(mmc, part - 1);
>>> +}
>>> +
>>> #if !CONFIG_IS_ENABLED(MMC_TINY)
>>> static int mmc_set_card_speed(struct mmc *mmc, enum bus_mode mode,
>>> bool hsdowngrade)
>>> @@ -2925,6 +2979,10 @@ static int mmc_complete_init(struct mmc *mmc)
>>> mmc->has_init = 0;
>>> else
>>> mmc->has_init = 1;
>>> +
>>> + if (!err && CONFIG_IS_ENABLED(MMC_WRITE_PROTECT_ACTIVE_BOOT))
I think that "if (CONFIG_IS_ENABLED(MMC_WRITE_PROTECT_ACTIVE_BOOT) && !err)" is
more better.
>>> + mmc_boot_wp_active_partition(m
Re: [RFC 1/2] drivers: mmc: write protect active boot area after mmc init.
Hi Jaehoon,
There are 2 boot partitions on eMMC. So the active one is write-protected.
Users can write the new firmware to another boot partition (inactive) which
is not write-protected.
And then switch it on.
In U-boot, execute "mmc wp" write-protect all of the boot partitions.
Maybe we can add an additional command that just write-protect only one
boot partition.
Yours,
Paul
On Thu, 27 Jan 2022 at 07:24, Jaehoon Chung wrote:
> Hi,
>
> On 1/25/22 22:55, Ying-Chun Liu wrote:
> > From: "Ying-Chun Liu (PaulLiu)"
> >
> > This commit implements write protection for active boot partition for
> > eMMC. The active boot partition is write protected, and it is still
> > able to write to the inactive boot partition.
>
> It seems that you want to enable Write-protect about boot partition
> without additional command, right?
> After initialized eMMC, how to update image into boot partition?
>
> Best Regards,
> Jaehoon Chung
>
> >
> > Signed-off-by: Ying-Chun Liu (PaulLiu)
> > Cc: Peng Fan
> > Cc: Jaehoon Chung
> > ---
> > drivers/mmc/Kconfig | 10
> > drivers/mmc/mmc.c | 58 +
> > 2 files changed, 68 insertions(+)
> >
> > diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> > index e0927ce1c9..c4bae743e6 100644
> > --- a/drivers/mmc/Kconfig
> > +++ b/drivers/mmc/Kconfig
> > @@ -100,6 +100,16 @@ config MMC_HW_PARTITIONING
> > This adds a command and an API to do hardware partitioning on
> eMMC
> > devices.
> >
> > +config MMC_WRITE_PROTECT_ACTIVE_BOOT
> > + bool "Write protection for active boot partition (eMMC)"
> > + depends on MMC_HW_PARTITIONING
> > + default n
> > + help
> > + Write protection for active boot partition when mmc initialized.
> > + This option protects the active boot partition so that it cannot
> > + be written. But it is still able to write to the inactive boot
> > + partition.
> > +
> > config SUPPORT_EMMC_RPMB
> > bool "Support eMMC replay protected memory block (RPMB)"
> > imply CMD_MMC_RPMB
> > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> > index 4d9871d69f..8620918749 100644
> > --- a/drivers/mmc/mmc.c
> > +++ b/drivers/mmc/mmc.c
> > @@ -860,6 +860,60 @@ int mmc_boot_wp(struct mmc *mmc)
> > return mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_BOOT_WP, 1);
> > }
> >
> > +/**
> > + * mmc_boot_wp_single_partition() - set write protection to a boot
> partition.
> > + *
> > + * This function sets a single boot partition to protect and leave the
> > + * other partition writable.
> > + *
> > + * @param mmc the mmc device.
> > + * @param partition 0 - first boot partition, 1 - second boot partition.
> > + */
> > +int mmc_boot_wp_single_partition(struct mmc *mmc, int partition)
> > +{
> > + u8 value;
> > + int ret;
> > +
> > + value = 1;
> > +
> > + if (partition == 0) {
> > + value |= 0x80;
> > + ret = mmc_switch(mmc,
> > + EXT_CSD_CMD_SET_NORMAL,
> > + EXT_CSD_BOOT_WP,
> > + value);
> > + } else if (partition == 1) {
> > + value |= 0x80;
> > + value |= 0x02;
> > + ret = mmc_switch(mmc,
> > + EXT_CSD_CMD_SET_NORMAL,
> > + EXT_CSD_BOOT_WP,
> > + value);
> > + } else {
> > + ret = mmc_boot_wp(mmc);
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +/**
> > + * mmc_boot_wp_active_partition() - set write protection to active boot
> > + * partition.
> > + *
> > + * @param mmc the mmc device.
> > + */
> > +static int mmc_boot_wp_active_partition(struct mmc *mmc)
> > +{
> > + u8 part;
> > +
> > + if (mmc->part_config == MMCPART_NOAVAILABLE)
> > + return -EOPNOTSUPP;
> > +
> > + part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
> > +
> > + return mmc_boot_wp_single_partition(mmc, part - 1);
> > +}
> > +
> > #if !CONFIG_IS_ENABLED(MMC_TINY)
> > static int mmc_set_card_speed(struct mmc *mmc, enum bus_mode mode,
> > bool hsdowngrade)
> > @@ -2925,6 +2979,10 @@ static int mmc_complete_init(struct mmc *mmc)
> > mmc->has_init = 0;
> > else
> > mmc->has_init = 1;
> > +
> > + if (!err && CONFIG_IS_ENABLED(MMC_WRITE_PROTECT_ACTIVE_BOOT))
> > + mmc_boot_wp_active_partition(mmc);
> > +
> > return err;
> > }
> >
>
>
[PULL] u-boot-usb/master
The following changes since commit 6146cd62aedc4849fec66f10ab0aa57f1dc64b8e:
Merge branch '2022-01-24-assorted-updates' (2022-01-25 08:01:43 -0500)
are available in the Git repository at:
git://source.denx.de/u-boot-usb.git master
for you to fetch changes up to fc2b399ac03b91339a1cb1bfd4d1a9ca87fe95c6:
usb: gadget: Add CDC ACM function (2022-01-26 23:23:17 +0100)
Loic Poulain (2):
lib/circbuf: Make circbuf selectable symbol
usb: gadget: Add CDC ACM function
Lukasz Majewski (4):
usb: Modify Kconfig of the USB_EHCI_MXS to use this driver with imx28
usb: ehci: Refactor the ehci_mxs_toggle_clock function to be
reused with DM
usb: ehci: Move common mxs code to separate functions
(ehci_hcd_{stop|start})
usb: ehci: dm: Convert i.MX28 ehci code to driver model
common/stdio.c | 3 +
drivers/usb/gadget/Kconfig | 9 ++
drivers/usb/gadget/Makefile | 1 +
drivers/usb/gadget/f_acm.c | 672
+
drivers/usb/host/Kconfig| 7 +-
drivers/usb/host/ehci-mxs.c | 328
---
include/stdio_dev.h | 1 +
lib/Kconfig | 3 +
lib/Makefile| 8 +-
9 files changed, 962 insertions(+), 70 deletions(-)
create mode 100644 drivers/usb/gadget/f_acm.c
Re: [PATCH 06/16] tools: Drop unused name in image-host
The name is created but never used. Drop it. Signed-off-by: Simon Glass --- tools/image-host.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH 01/16] rsa: Add debugging for failure cases
Add some more debugging to make it easier to see what is being tried and what fails. Fix a few comment styles while here. Signed-off-by: Simon Glass --- lib/rsa/rsa-verify.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH 03/16] tools: Move copyfile() into a common file
This function is useful in other places. Move it to a common file. Signed-off-by: Simon Glass --- tools/fit_common.c | 56 ++ tools/fit_common.h | 11 + tools/fit_image.c | 56 -- 3 files changed, 67 insertions(+), 56 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH 02/16] fit_check_sign: Update help to mention the key is in a dtb
The key is inside a dtb file, so tweak the help to make that clear. Signed-off-by: Simon Glass --- tools/fit_check_sign.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH 04/16] tools: Avoid leaving extra data at the end of copied files
The copyfile() implementation has strange behaviour if the destination file already exists. Update it to ensure that any existing data in the destination file is dropped. Signed-off-by: Simon Glass --- tools/fit_common.c | 2 +- tools/fit_common.h | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) Applied to u-boot-dm, thanks!
Re: [PATCH 05/16] tools: Improve comments in signing functions
Add some more comments to explain what is going on in the signing functions. Fix two repeated typos. Signed-off-by: Simon Glass --- include/image.h| 2 +- tools/fdt_host.h | 8 tools/image-host.c | 98 +++--- 3 files changed, 85 insertions(+), 23 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH 07/16] tools: Avoid confusion between keys and signatures
We should be consistent in using the term 'signature' to describe a value added to sign something and 'key' to describe the key that can be used to verify the signature. Tidy up the code to stick to this. Add some comments to fit_config_verify_key() and its callers while we are here. Signed-off-by: Simon Glass --- boot/image-fit-sig.c | 97 1 file changed, 72 insertions(+), 25 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH 11/16] tools: Pass public-key node through to caller
Update the two functions that call add_verify_data() so that the caller can see the node that was written to. Signed-off-by: Simon Glass --- tools/image-host.c | 28 +--- 1 file changed, 25 insertions(+), 3 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH 08/16] tools: Tidy up argument order in fit_config_check_sig()
Put the parent node first in the parameters as this is more natural. Also add a comment to explain what is going on. Signed-off-by: Simon Glass --- boot/image-fit-sig.c | 31 ++- 1 file changed, 22 insertions(+), 9 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH 12/16] tools: mkimage: Show where signatures/keys are written
At present mkimage displays the node information but it is not clear what signing action was taken. Add a message that shows it. For now it only supports showing a single signing action, since that is the common case. Sample: Signature written to 'sha1-basic/test.fit', node '/configurations/conf-1/signature' Public key written to 'sha1-basic/sandbox-u-boot.dtb', node '/signature/key-dev' Signed-off-by: Simon Glass --- include/image.h| 23 ++- tools/fit_common.c | 13 + tools/fit_common.h | 10 ++ tools/fit_image.c | 3 ++- tools/image-host.c | 23 ++- tools/imagetool.h | 3 +++ tools/mkimage.c| 4 7 files changed, 72 insertions(+), 7 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH 09/16] tools: Pass the key blob around
At present we rely on the key blob being in the global_data fdt_blob pointer. This is true in U-Boot but not with tools. For clarity, pass the parameter around. Signed-off-by: Simon Glass --- boot/image-fit-sig.c | 31 ++- boot/image-fit.c | 12 +++- common/spl/spl_fit.c | 3 ++- include/image.h | 23 ++- 4 files changed, 45 insertions(+), 24 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH v4 08/20] power: domain: ti: Add support for J721S2 SoC
On 1/26/22 00:26, Aswath Govindraju wrote:
> From: David Huang
>
> Add support for J721S2 SoC.
>
> Signed-off-by: David Huang
> Signed-off-by: Aswath Govindraju
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/power/domain/ti-power-domain.c | 5 +
> include/k3-dev.h | 1 +
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/power/domain/ti-power-domain.c
> b/drivers/power/domain/ti-power-domain.c
> index 4fe31686bd35..6af5dbb24191 100644
> --- a/drivers/power/domain/ti-power-domain.c
> +++ b/drivers/power/domain/ti-power-domain.c
> @@ -81,6 +81,11 @@ static const struct soc_attr ti_k3_soc_pd_data[] = {
> .family = "J7200",
> .data = &j7200_pd_platdata,
> },
> +#elif CONFIG_SOC_K3_J721S2
> + {
> + .family = "J721S2",
> + .data = &j721s2_pd_platdata,
> + },
> #endif
> { /* sentinel */ }
> };
> diff --git a/include/k3-dev.h b/include/k3-dev.h
> index 55c5057db35a..b46b8c3aabc7 100644
> --- a/include/k3-dev.h
> +++ b/include/k3-dev.h
> @@ -77,6 +77,7 @@ struct ti_k3_pd_platdata {
>
> extern const struct ti_k3_pd_platdata j721e_pd_platdata;
> extern const struct ti_k3_pd_platdata j7200_pd_platdata;
> +extern const struct ti_k3_pd_platdata j721s2_pd_platdata;
>
> u8 ti_pd_state(struct ti_pd *pd);
> u8 lpsc_get_state(struct ti_lpsc *lpsc);
Re: [PATCH v2 7/9] power: domain: apple: Add reset support
Hi,
On 1/23/22 04:38, Mark Kettenis wrote:
> The power management controller found on Apple SoCs als provides
> a way to reset all devices within a power domain. This is needed
> to cleanly shutdown the NVMe controller before we hand over
> control to the OS.
>
> Signed-off-by: Mark Kettenis
> Reviewed-by: Simon Glass
> Tested on: Macbook Air M1
> Tested-by: Simon Glass
Reviewed-by: Jaehoon Chung
Add minor comment.
> ---
> arch/arm/Kconfig | 1 +
> drivers/power/domain/apple-pmgr.c | 73 ++-
> 2 files changed, 73 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index ecacd6860b..14c83ea19e 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -935,6 +935,7 @@ config ARCH_APPLE
> select DM_GPIO
> select DM_KEYBOARD
> select DM_MAILBOX
> + select DM_RESET
> select DM_SERIAL
> select DM_USB
> select DM_VIDEO
> diff --git a/drivers/power/domain/apple-pmgr.c
> b/drivers/power/domain/apple-pmgr.c
> index d25f136b9d..4d06e76ff5 100644
> --- a/drivers/power/domain/apple-pmgr.c
> +++ b/drivers/power/domain/apple-pmgr.c
> @@ -6,14 +6,22 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> +#include
> #include
> #include
>
> -#define APPLE_PMGR_PS_TARGET GENMASK(3, 0)
> +#define APPLE_PMGR_RESET BIT(31)
> +#define APPLE_PMGR_DEV_DISABLE BIT(10)
> +#define APPLE_PMGR_WAS_CLKGATED BIT(9)
> +#define APPLE_PMGR_WAS_PWRGATED BIT(8)
Bit description is specified "WAS_CLKGATED"?
I think it can be removed "WAS". CLKGATED has already similar meaning.
Best Regards,
Jaehoon Chung
> #define APPLE_PMGR_PS_ACTUAL GENMASK(7, 4)
> +#define APPLE_PMGR_PS_TARGET GENMASK(3, 0)
> +
> +#define APPLE_PMGR_FLAGS (APPLE_PMGR_WAS_CLKGATED |
> APPLE_PMGR_WAS_PWRGATED)
>
> #define APPLE_PMGR_PS_ACTIVE 0xf
> #define APPLE_PMGR_PS_PWRGATE0x0
> @@ -25,6 +33,65 @@ struct apple_pmgr_priv {
> u32 offset; /* offset within regmap for this domain */
> };
>
> +static int apple_reset_of_xlate(struct reset_ctl *reset_ctl,
> + struct ofnode_phandle_args *args)
> +{
> + if (args->args_count != 0)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int apple_reset_request(struct reset_ctl *reset_ctl)
> +{
> + return 0;
> +}
> +
> +static int apple_reset_free(struct reset_ctl *reset_ctl)
> +{
> + return 0;
> +}
> +
> +static int apple_reset_assert(struct reset_ctl *reset_ctl)
> +{
> + struct apple_pmgr_priv *priv = dev_get_priv(reset_ctl->dev->parent);
> +
> + regmap_update_bits(priv->regmap, priv->offset,
> +APPLE_PMGR_FLAGS | APPLE_PMGR_DEV_DISABLE,
> +APPLE_PMGR_DEV_DISABLE);
> + regmap_update_bits(priv->regmap, priv->offset,
> +APPLE_PMGR_FLAGS | APPLE_PMGR_RESET,
> +APPLE_PMGR_RESET);
> +
> + return 0;
> +}
> +
> +static int apple_reset_deassert(struct reset_ctl *reset_ctl)
> +{
> + struct apple_pmgr_priv *priv = dev_get_priv(reset_ctl->dev->parent);
> +
> + regmap_update_bits(priv->regmap, priv->offset,
> +APPLE_PMGR_FLAGS | APPLE_PMGR_RESET, 0);
> + regmap_update_bits(priv->regmap, priv->offset,
> +APPLE_PMGR_FLAGS | APPLE_PMGR_DEV_DISABLE, 0);
> +
> + return 0;
> +}
> +
> +struct reset_ops apple_reset_ops = {
> + .of_xlate = apple_reset_of_xlate,
> + .request = apple_reset_request,
> + .rfree = apple_reset_free,
> + .rst_assert = apple_reset_assert,
> + .rst_deassert = apple_reset_deassert,
> +};
> +
> +static struct driver apple_reset_driver = {
> + .name = "apple_reset",
> + .id = UCLASS_RESET,
> + .ops = &apple_reset_ops,
> +};
> +
> static int apple_pmgr_request(struct power_domain *power_domain)
> {
> return 0;
> @@ -78,6 +145,7 @@ static const struct udevice_id apple_pmgr_ids[] = {
> static int apple_pmgr_probe(struct udevice *dev)
> {
> struct apple_pmgr_priv *priv = dev_get_priv(dev);
> + struct udevice *child;
> int ret;
>
> ret = dev_power_domain_on(dev);
> @@ -92,6 +160,9 @@ static int apple_pmgr_probe(struct udevice *dev)
> if (ret < 0)
> return ret;
>
> + device_bind(dev, &apple_reset_driver, "apple_reset", NULL,
> + dev_ofnode(dev), &child);
> +
> return 0;
> }
>
Re: [RFC 1/2] drivers: mmc: write protect active boot area after mmc init.
Hi,
On 1/25/22 22:55, Ying-Chun Liu wrote:
> From: "Ying-Chun Liu (PaulLiu)"
>
> This commit implements write protection for active boot partition for
> eMMC. The active boot partition is write protected, and it is still
> able to write to the inactive boot partition.
It seems that you want to enable Write-protect about boot partition without
additional command, right?
After initialized eMMC, how to update image into boot partition?
Best Regards,
Jaehoon Chung
>
> Signed-off-by: Ying-Chun Liu (PaulLiu)
> Cc: Peng Fan
> Cc: Jaehoon Chung
> ---
> drivers/mmc/Kconfig | 10
> drivers/mmc/mmc.c | 58 +
> 2 files changed, 68 insertions(+)
>
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index e0927ce1c9..c4bae743e6 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -100,6 +100,16 @@ config MMC_HW_PARTITIONING
> This adds a command and an API to do hardware partitioning on eMMC
> devices.
>
> +config MMC_WRITE_PROTECT_ACTIVE_BOOT
> + bool "Write protection for active boot partition (eMMC)"
> + depends on MMC_HW_PARTITIONING
> + default n
> + help
> + Write protection for active boot partition when mmc initialized.
> + This option protects the active boot partition so that it cannot
> + be written. But it is still able to write to the inactive boot
> + partition.
> +
> config SUPPORT_EMMC_RPMB
> bool "Support eMMC replay protected memory block (RPMB)"
> imply CMD_MMC_RPMB
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 4d9871d69f..8620918749 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -860,6 +860,60 @@ int mmc_boot_wp(struct mmc *mmc)
> return mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_BOOT_WP, 1);
> }
>
> +/**
> + * mmc_boot_wp_single_partition() - set write protection to a boot partition.
> + *
> + * This function sets a single boot partition to protect and leave the
> + * other partition writable.
> + *
> + * @param mmc the mmc device.
> + * @param partition 0 - first boot partition, 1 - second boot partition.
> + */
> +int mmc_boot_wp_single_partition(struct mmc *mmc, int partition)
> +{
> + u8 value;
> + int ret;
> +
> + value = 1;
> +
> + if (partition == 0) {
> + value |= 0x80;
> + ret = mmc_switch(mmc,
> + EXT_CSD_CMD_SET_NORMAL,
> + EXT_CSD_BOOT_WP,
> + value);
> + } else if (partition == 1) {
> + value |= 0x80;
> + value |= 0x02;
> + ret = mmc_switch(mmc,
> + EXT_CSD_CMD_SET_NORMAL,
> + EXT_CSD_BOOT_WP,
> + value);
> + } else {
> + ret = mmc_boot_wp(mmc);
> + }
> +
> + return ret;
> +}
> +
> +/**
> + * mmc_boot_wp_active_partition() - set write protection to active boot
> + * partition.
> + *
> + * @param mmc the mmc device.
> + */
> +static int mmc_boot_wp_active_partition(struct mmc *mmc)
> +{
> + u8 part;
> +
> + if (mmc->part_config == MMCPART_NOAVAILABLE)
> + return -EOPNOTSUPP;
> +
> + part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
> +
> + return mmc_boot_wp_single_partition(mmc, part - 1);
> +}
> +
> #if !CONFIG_IS_ENABLED(MMC_TINY)
> static int mmc_set_card_speed(struct mmc *mmc, enum bus_mode mode,
> bool hsdowngrade)
> @@ -2925,6 +2979,10 @@ static int mmc_complete_init(struct mmc *mmc)
> mmc->has_init = 0;
> else
> mmc->has_init = 1;
> +
> + if (!err && CONFIG_IS_ENABLED(MMC_WRITE_PROTECT_ACTIVE_BOOT))
> + mmc_boot_wp_active_partition(mmc);
> +
> return err;
> }
>
[PATCH] soc: soc_ti_k3: update j721e revision numbering
There is a 4 bit VARIANT number inside the JTAGID register that TI
increments any time a new variant for a chip is produced. Each
family of TI's SoCs uses a different versioning scheme based off
that VARIANT number.
CC: Dave Gerlach
Signed-off-by: Bryan Brattlof
---
drivers/soc/soc_ti_k3.c | 40 +++-
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/drivers/soc/soc_ti_k3.c b/drivers/soc/soc_ti_k3.c
index 9abed7d490a2c..7a126857cd709 100644
--- a/drivers/soc/soc_ti_k3.c
+++ b/drivers/soc/soc_ti_k3.c
@@ -15,9 +15,6 @@
#define J7200 0xbb6d
#define AM64X 0xbb38
-#define REV_SR1_0 0
-#define REV_SR2_0 1
-
#define JTAG_ID_VARIANT_SHIFT 28
#define JTAG_ID_VARIANT_MASK (0xf << 28)
#define JTAG_ID_PARTNO_SHIFT 12
@@ -55,25 +52,42 @@ static const char *get_family_string(u32 idreg)
return family;
}
+static char *j721e_rev_string_map[] = {
+ "1.0", "1.1",
+};
+
+static char *am65x_rev_string_map[] = {
+ "1.0", "2.0",
+};
+
static const char *get_rev_string(u32 idreg)
{
- const char *revision;
u32 rev;
+ u32 soc;
rev = (idreg & JTAG_ID_VARIANT_MASK) >> JTAG_ID_VARIANT_SHIFT;
+ soc = (idreg & JTAG_ID_PARTNO_MASK) >> JTAG_ID_PARTNO_SHIFT;
- switch (rev) {
- case REV_SR1_0:
- revision = "1.0";
- break;
- case REV_SR2_0:
- revision = "2.0";
- break;
+ switch (soc) {
+ case J721E:
+ if (rev > ARRAY_SIZE(j721e_rev_string_map))
+ goto bail;
+ return j721e_rev_string_map[rev];
+
+ case AM65X:
+ if (rev > ARRAY_SIZE(am65x_rev_string_map))
+ goto bail;
+ return am65x_rev_string_map[rev];
+
+ case AM64X:
+ case J7200:
default:
- revision = "Unknown Revision";
+ if (!rev)
+ return "1.0";
};
- return revision;
+bail:
+ return "Unknown Revision";
}
static int soc_ti_k3_get_family(struct udevice *dev, char *buf, int size)
--
2.17.1
U boot for Roach2
Good afternoon I want to use an image (linux system embedded) to boot from an SD card on the Roach2 board Please, could you give any suggestions on how to do it? I have the file download from ftp://ftp.denx.de/pub/u_boot/imagesthe version u-boot-2022.01. Many thanks Kind regards -- Jael Rojas Miguel
Re: Compile only changed files when doing 'make'?
On 2022-01-25, Grant Edwards wrote: > I'm working on a Renesas supplied port of U-Boot, and it seems that > 'make' always compiles every single (configured) source file instead > compiling only the source files that have been changed since the > previous 'make'. This problem appears to be caused by an incompatibility between the Kbuild infrastructure2 and GNU make-4.3. Switching to make-4.2.1 solved the problem. The U-Boot source tree we're using is the v2017.01 branch. It's the latest supported by the Renesas board support files. I'm not very happy they haven't contributed the supported upstream to make it easier to support newer versions. I've asked Renesas about this, and they have no plans to either support a newer version of U-Boot or contribute their support files. :/ I assume that this Kbuild incompatibility with make-4.3 has been fixed in newer versions of U-Boot. If this Kbuild problem is familiar to anybody, and you know where the fix was made, I'd appreciate a pointer so that I can back-port that fix to my v2017.01 sources. Thanks... -- Grant
[PATCH v7 2/2] arm: imx8m: add support for Advantech RSB-3720
From: "Ying-Chun Liu (PaulLiu)" Add initial support for Advantech RSB-3720 board. The initial support includes: - MMC - eMMC - I2C - FEC - Serial console Signed-off-by: Darren Huang Signed-off-by: Kevin12.Chen Signed-off-by: Phill.Liu Signed-off-by: Tim Liang Signed-off-by: wei.zeng Signed-off-by: Ying-Chun Liu (PaulLiu) Cc: uboot-imx Cc: Peng Fan (OSS) --- v3: remove unnecessary code. move board code to board/advantech v4: rebase to latest master branch v7: remove redefined configs for latest master branch. --- arch/arm/dts/Makefile |3 + arch/arm/mach-imx/imx8m/Kconfig | 15 + board/advantech/imx8mp_rsb3720a1/Kconfig | 14 + board/advantech/imx8mp_rsb3720a1/MAINTAINERS |7 + board/advantech/imx8mp_rsb3720a1/Makefile | 24 + .../imx8mp_rsb3720a1/imx8mp_rsb3720a1.c | 213 ++ .../imx8mp_rsb3720a1/imximage-8mp-lpddr4.cfg | 11 + .../lpddr4_timing_rsb3720a1_4G.c | 1848 .../lpddr4_timing_rsb3720a1_6G.c | 1875 + board/advantech/imx8mp_rsb3720a1/spl.c| 260 +++ configs/imx8mp_rsb3720a1_4G_defconfig | 167 ++ configs/imx8mp_rsb3720a1_6G_defconfig | 168 ++ include/configs/imx8mp_rsb3720.h | 223 ++ 13 files changed, 4828 insertions(+) create mode 100644 board/advantech/imx8mp_rsb3720a1/Kconfig create mode 100644 board/advantech/imx8mp_rsb3720a1/MAINTAINERS create mode 100644 board/advantech/imx8mp_rsb3720a1/Makefile create mode 100644 board/advantech/imx8mp_rsb3720a1/imx8mp_rsb3720a1.c create mode 100644 board/advantech/imx8mp_rsb3720a1/imximage-8mp-lpddr4.cfg create mode 100644 board/advantech/imx8mp_rsb3720a1/lpddr4_timing_rsb3720a1_4G.c create mode 100644 board/advantech/imx8mp_rsb3720a1/lpddr4_timing_rsb3720a1_6G.c create mode 100644 board/advantech/imx8mp_rsb3720a1/spl.c create mode 100644 configs/imx8mp_rsb3720a1_4G_defconfig create mode 100644 configs/imx8mp_rsb3720a1_6G_defconfig create mode 100644 include/configs/imx8mp_rsb3720.h diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index ce332021d8..d572404003 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -1174,6 +1174,9 @@ dtb-$(CONFIG_TARGET_DURIAN) += phytium-durian.dtb dtb-$(CONFIG_TARGET_PRESIDIO_ASIC) += ca-presidio-engboard.dtb dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE) += imx8mm-cl-iot-gate.dtb +ifneq ($(CONFIG_TARGET_IMX8MP_RSB3720A1_4G)$(CONFIG_TARGET_IMX8MP_RSB3720A1_6G),) +dtb-y += imx8mp-rsb3720-a1.dtb +endif dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE_OPTEE) += imx8mm-cl-iot-gate-optee.dtb diff --git a/arch/arm/mach-imx/imx8m/Kconfig b/arch/arm/mach-imx/imx8m/Kconfig index d6a869068a..f0d3eefa02 100644 --- a/arch/arm/mach-imx/imx8m/Kconfig +++ b/arch/arm/mach-imx/imx8m/Kconfig @@ -160,8 +160,23 @@ config TARGET_IMX8MM_CL_IOT_GATE_OPTEE select IMX8MM select SUPPORT_SPL select IMX8M_LPDDR4 + +config TARGET_IMX8MP_RSB3720A1_4G + bool "Support i.MX8MP RSB3720A1 4G" + select BINMAN + select IMX8MP + select SUPPORT_SPL + select IMX8M_LPDDR4 + +config TARGET_IMX8MP_RSB3720A1_6G + bool "Support i.MX8MP RSB3720A1 6G" + select BINMAN + select IMX8MP + select SUPPORT_SPL + select IMX8M_LPDDR4 endchoice +source "board/advantech/imx8mp_rsb3720a1/Kconfig" source "board/beacon/imx8mm/Kconfig" source "board/beacon/imx8mn/Kconfig" source "board/compulab/imx8mm-cl-iot-gate/Kconfig" diff --git a/board/advantech/imx8mp_rsb3720a1/Kconfig b/board/advantech/imx8mp_rsb3720a1/Kconfig new file mode 100644 index 00..4486ed6d33 --- /dev/null +++ b/board/advantech/imx8mp_rsb3720a1/Kconfig @@ -0,0 +1,14 @@ +if TARGET_IMX8MP_RSB3720A1_4G || TARGET_IMX8MP_RSB3720A1_6G + +config SYS_BOARD + default "imx8mp_rsb3720a1" + +config SYS_VENDOR + default "advantech" + +config SYS_CONFIG_NAME + default "imx8mp_rsb3720" + +source "board/freescale/common/Kconfig" + +endif diff --git a/board/advantech/imx8mp_rsb3720a1/MAINTAINERS b/board/advantech/imx8mp_rsb3720a1/MAINTAINERS new file mode 100644 index 00..bc967af4f5 --- /dev/null +++ b/board/advantech/imx8mp_rsb3720a1/MAINTAINERS @@ -0,0 +1,7 @@ +i.MX8MP RSB3720 BOARD +M: Ying-Chun Liu (PaulLiu) +S: Maintained +F: board/advantech/imx8mp_rsb3720a1/ +F: include/configs/imx8mp_rsb3720a1.h +F: configs/imx8mp_rsb3720a1_4G_defconfig +F: configs/imx8mp_rsb3720a1_6G_defconfig diff --git a/board/advantech/imx8mp_rsb3720a1/Makefile b/board/advantech/imx8mp_rsb3720a1/Makefile new file mode 100644 index 00..eb6b18b04a --- /dev/null +++ b/board/advantech/imx8mp_rsb3720a1/Makefile @@ -0,0 +1,24 @@ +# +# Copyright 2019 NXP +# Copyright 2022 Linaro +# +# SPDX-License-Identifier: GPL-2.0+ +# + +ifdef CONFIG_TARGET_IMX8MP_RSB3720A1_6G +obj-y += imx8mp_rsb3720a1.o + +ifdef CONFIG_SPL_BUILD +obj-y += spl.o +obj-$(CONFIG_IMX8M_LPDDR4) += lpddr4_timing_rsb3720a1_6
[RFC PATCH 1/1] efi_loader: Enable RISCV_EFI_BOOT_PROTOCOL support
This adds support for new RISCV_EFI_BOOT_PROTOCOL to
communicate the boot hart ID to bootloader/kernel on RISC-V
UEFI platforms.
Signed-off-by: Sunil V L
---
include/efi_api.h | 4 +++
include/efi_loader.h | 2 ++
include/efi_riscv.h| 16 +
lib/efi_loader/Kconfig | 7
lib/efi_loader/Makefile| 1 +
lib/efi_loader/efi_riscv.c | 69 ++
lib/efi_loader/efi_setup.c | 6
7 files changed, 105 insertions(+)
create mode 100644 include/efi_riscv.h
create mode 100644 lib/efi_loader/efi_riscv.c
diff --git a/include/efi_api.h b/include/efi_api.h
index 8d5d835bd0..f123d0557c 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -438,6 +438,10 @@ struct efi_runtime_services {
EFI_GUID(0x607f766c, 0x7455, 0x42be, 0x93, \
0x0b, 0xe4, 0xd7, 0x6d, 0xb2, 0x72, 0x0f)
+#define RISCV_EFI_BOOT_PROTOCOL_GUID \
+ EFI_GUID(0xccd15fec, 0x6f73, 0x4eec, 0x83, \
+0x95, 0x3e, 0x69, 0xe4, 0xb9, 0x40, 0xbf)
+
/**
* struct efi_configuration_table - EFI Configuration Table
*
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 701efcd2b6..1fa75b40fe 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -527,6 +527,8 @@ efi_status_t efi_disk_register(void);
efi_status_t efi_rng_register(void);
/* Called by efi_init_obj_list() to install EFI_TCG2_PROTOCOL */
efi_status_t efi_tcg2_register(void);
+/* Called by efi_init_obj_list() to install RISCV_EFI_BOOT_PROTOCOL */
+efi_status_t efi_riscv_register(void);
/* Called by efi_init_obj_list() to do initial measurement */
efi_status_t efi_tcg2_do_initial_measurement(void);
/* measure the pe-coff image, extend PCR and add Event Log */
diff --git a/include/efi_riscv.h b/include/efi_riscv.h
new file mode 100644
index 00..6beb2637f6
--- /dev/null
+++ b/include/efi_riscv.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * RISCV_EFI_BOOT_PROTOCOL
+ *
+ * Copyright (c) 2022 Ventana Micro Systems Inc
+ */
+
+#include
+
+#define RISCV_EFI_BOOT_PROTOCOL_REVISION 0x0001
+
+struct riscv_efi_boot_protocol {
+ u64 revision;
+ efi_status_t (EFIAPI *get_boot_hartid) (struct riscv_efi_boot_protocol
*this,
+ efi_uintn_t *boot_hartid);
+};
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 24f9a2bb75..77ba6a7ea1 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -369,4 +369,11 @@ config EFI_ESRT
help
Enabling this option creates the ESRT UEFI system table.
+config EFI_RISCV_BOOT_PROTOCOL
+ bool "RISCV_EFI_BOOT_PROTOCOL support"
+ default y
+ depends on RISCV
+ help
+ Provide a RISCV_EFI_BOOT_PROTOCOL implementation on RISC-V platform.
+
endif
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index fd344cea29..b2c664d108 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_GENERATE_ACPI_TABLE) += efi_acpi.o
obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += efi_smbios.o
obj-$(CONFIG_EFI_RNG_PROTOCOL) += efi_rng.o
obj-$(CONFIG_EFI_TCG2_PROTOCOL) += efi_tcg2.o
+obj-$(CONFIG_EFI_RISCV_BOOT_PROTOCOL) += efi_riscv.o
obj-$(CONFIG_EFI_LOAD_FILE2_INITRD) += efi_load_initrd.o
obj-$(CONFIG_EFI_SIGNATURE_SUPPORT) += efi_signature.o
diff --git a/lib/efi_loader/efi_riscv.c b/lib/efi_loader/efi_riscv.c
new file mode 100644
index 00..91b8d2b927
--- /dev/null
+++ b/lib/efi_loader/efi_riscv.c
@@ -0,0 +1,69 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Defines APIs that allow an OS to interact with UEFI firmware to query
+ * information about the boot hart ID.
+ *
+ * Copyright (c) 2022, Ventana Micro Systems Inc
+ */
+
+#define LOG_CATEGORY LOGC_EFI
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static const efi_guid_t efi_guid_riscv_boot_protocol =
RISCV_EFI_BOOT_PROTOCOL_GUID;
+static efi_uintn_t hartid;
+
+/**
+ * efi_riscv_get_boot_hartid() - return boot hart ID
+ *
+ * @this: RISCV_EFI_BOOT_PROTOCOL instance
+ * @boot_hartidcaller allocated memory to return boot hart id
+
+ * Return: status code
+ */
+static efi_status_t EFIAPI
+efi_riscv_get_boot_hartid(struct riscv_efi_boot_protocol *this,
+ efi_uintn_t *boot_hartid)
+{
+ log_err(" efi_riscv_get_boot_hartid ENTER\n");
+ if ((this == NULL) || (boot_hartid == NULL))
+ return EFI_INVALID_PARAMETER;
+
+ *boot_hartid = hartid;
+
+ return EFI_SUCCESS;
+}
+
+static const struct riscv_efi_boot_protocol riscv_efi_boot_prot = {
+ .revision = RISCV_EFI_BOOT_PROTOCOL_REVISION,
+ .get_boot_hartid = efi_riscv_get_boot_hartid
+};
+
+/**
+ * efi_riscv_register() - register RISCV_EFI_BOOT_PROTOCOL
+ *
+ *
+ * Return: status code
+ */
+efi_status_t efi_riscv_register(void)
+{
+ efi_status_t ret = EFI_SUCCESS;
[RFC PATCH 0/1] RISCV_EFI_BOOT_PROTOCOL support in U-boot
This patch adds the support in u-boot for new RISCV_EFI_BOOT_PROTOCOL for RISC-V UEFI platforms. This protocol is required to communicate the boot hart ID to the bootloader/kernel which need to follow the EFI calling conventions. The latest draft spec of this new protocol is available at https://github.com/riscv-non-isa/riscv-uefi/releases/download/1.0-rc2/RISCV_UEFI_PROTOCOL-spec.pdf This u-boot patch can be found in: riscv_boot_protocol_rfc_v1 branch at https://github.com/vlsunil/u-boot.git This patch is tested in qemu. To fully test the feature, we need Linux changes which consume this protocol. The linux patch can be found in: riscv_boot_protocol_rfc_v1 branch at https://github.com/vlsunil/linux.git Sunil V L (1): efi_loader: Enable RISCV_EFI_BOOT_PROTOCOL support include/efi_api.h | 4 +++ include/efi_loader.h | 2 ++ include/efi_riscv.h| 16 + lib/efi_loader/Kconfig | 7 lib/efi_loader/Makefile| 1 + lib/efi_loader/efi_riscv.c | 69 ++ lib/efi_loader/efi_setup.c | 6 7 files changed, 105 insertions(+) create mode 100644 include/efi_riscv.h create mode 100644 lib/efi_loader/efi_riscv.c -- 2.25.1
Re: Bug#1003490: u-boot: FTBFS on arch:all with qemu-ppce500 target
On 2022-01-25 19:04, Vagrant Cascadian wrote:
> On 2022-01-25, Vagrant Cascadian wrote:
> > On 2022-01-15, Aurelien Jarno wrote:
> >> On 2022-01-11 16:40, Vagrant Cascadian wrote:
> >>> On 2022-01-11, Lennart Sorensen wrote:
> >>> > On Mon, Jan 10, 2022 at 05:10:04PM -0800, Vagrant Cascadian wrote:
> >>> >> Something in the toolchain recently changed which causes u-boot
> >>> >> arch:all
> >>> >> build to FTBFS... I suspect binutils, as building in "bookworm" still
> >>> >> works fine where binutils hasn't yet migrated.
> >>> >>
> >>> >> On arch:all builds the qemu-ppce500 target is cross-compiled.
> >>> >>
> >>> >> Full log:
> >>> >>
> >>> >>
> >>> >> https://buildd.debian.org/status/fetch.php?pkg=u-boot&arch=all&ver=2022.01%2Bdfsg-1&stamp=1641860624&raw=0
> >>> >>
> >>> >> The hopefully relevent lines from the build log:
> ...
> >>> >> {standard input}: Assembler messages:
> >>> >> {standard input}:127: Error: unrecognized opcode: `tlbre'
> >>> >> {standard input}:418: Error: unrecognized opcode: `tlbre'
> >>> >> {standard input}:821: Error: unrecognized opcode: `msync'
> >>> >> {standard input}:821: Error: unrecognized opcode: `tlbwe'
> >>> >> {standard input}:884: Error: unrecognized opcode: `tlbsx'
> >>> >> make[4]: *** [/<>/scripts/Makefile.build:253:
> >>> >> arch/powerpc/cpu/mpc85xx/tlb.o] Error 1
> >>> >> make[3]: *** [/<>/Makefile:1810:
> >>> >> arch/powerpc/cpu/mpc85xx] Error 2
> >>> >> make[3]: *** Waiting for unfinished jobs
> >>> >> powerpc-linux-gnu-gcc -Wp,-MD,arch/powerpc/lib/.traps.o.d -nost
> > ...
> >>> The binutils versions appear to be:
> >>>
> >>> succeeding, bookworm 2.37-10.1
> >>> failing, sid 2.37.50.20220106-2
> >>>
> >>
> >> Yep, this is due to commit b25f942e18d6ecd7ec3e2d2e9930eb4f996c258a on
> >> the binutils side [1], which changes the behavior of `.machine`
> >> directives to override, rather than augment, the base CPU. GCC is called
> >> with -Wa,-me500 to enable PowerPC e500 instructions on the assembler
> >> side, but as the default GCC machine is ppc, a `.set machine ppc` is
> >> emitted at the beginning of the assembly code.
> >>
> >> One option would be to force the CPU to e500 on the GCC side, however
> >> support for it has been removed. The options is therefore to force the
> >> machine in the assembly code. This is what the attached patch does.
> >
> > Somehow I missed that you had attached a patch! I will try to get this
> > tested and uploaded to Debian soon...
>
> Your patch fixed building qemu-ppce500, but now I think we have a
> potentially similar problem with qemu-riscv64 and qemu-riscv64_smode:
>
> /<>/arch/riscv/cpu/cpu.c: Assembler messages:
> /<>/arch/riscv/cpu/cpu.c:94: Error: unrecognized opcode
> `csrs sstatus,a5'
> /<>/arch/riscv/cpu/cpu.c:95: Error: unrecognized opcode
> `csrw 0x003,0'
> make[4]: *** [/<>/scripts/Makefile.build:254:
> arch/riscv/cpu/cpu.o] Error 1
> make[3]: *** [/<>/Makefile:1810: arch/riscv/cpu] Error 2
> make[3]: Leaving directory
> '/<>/debian/build/qemu-riscv64_smode'
I guess this is due to:
http://lists.infradead.org/pipermail/linux-riscv/2022-January/011728.html
Unfortunately as the change has been done in a not yet released binutils
version, there is no way for the fix to have been done upstream yet.
Note that this also breaks at least linux and opensbi.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
signature.asc
Description: PGP signature
RE: [PATCH 07/14] video: Drop references to CONFIG_VIDEO et al
> -Original Message-
> From: Simon Glass
> Sent: 2022年1月23日 22:04
> To: U-Boot Mailing List
> Cc: Anatolij Gustschin ; Jagan Teki
> ; Andre Przywara ;
> Simon Glass ; Andy Shevchenko
> ; Aswath Govindraju
> ; Aymen Sghaier ; Bin Meng
> ; Dario Binacchi ; Fabio Estevam
> ; Heiko Schocher ; Heinrich Schuchardt
> ; Jaehoon Chung ; Jason
> Liu ; Joel Peshkin ;
> Kory Maincent ; Marek Vasut
> ; Michal Simek ; dl-uboot-imx
> ; Ovidiu Panait ; Peng
> Fan ; Rasmus Villemoes ;
> samuel.e...@siemens.com; Stefan Bosch ; Stefan
> Roese ; Stefano Babic
> Subject: [PATCH 07/14] video: Drop references to CONFIG_VIDEO et al
>
> Drop the Kconfigs which are not used and all references to them. In
particular,
> this drops CONFIG_VIDEO to avoid confusion and allow us to eventually
> rename CONFIG_DM_VIDEO to CONFIG_VIDEO.
>
> Also drop the prototype for video_get_info_str() which is no-longer used.
>
> Signed-off-by: Simon Glass
> ---
>
> README| 3 -
> arch/arm/include/asm/mach-imx/mx5_video.h | 5 --
> .../mach-nexell/include/mach/display_dev.h| 2 +-
> board/freescale/mx51evk/Makefile | 1 -
> board/freescale/mx53loco/Makefile | 1 -
> board/kosagi/novena/novena_spl.c | 23
> cmd/Kconfig | 2 +-
> cmd/bdinfo.c | 2 +-
> cmd/bmp.c | 4 +-
> common/fdt_support.c | 2 +-
> common/stdio.c| 3 +-
> drivers/video/Kconfig | 56 +--
> drivers/video/nexell_display.c| 3 +-
> include/asm-generic/global_data.h | 2 +-
> include/configs/pxm2.h| 7 ---
> include/configs/rut.h | 9 ---
> lib/efi_loader/Kconfig| 1 -
> 17 files changed, 10 insertions(+), 116 deletions(-)
For the imx51/53 board.
Acked-by: Jason Liu
>
> diff --git a/README b/README
> index 816d9c4dfb2..40ef21df3b5 100644
> --- a/README
> +++ b/README
> @@ -1013,9 +1013,6 @@ The following options need to be configured:
> support, and should also define these other macros:
>
> CONFIG_SYS_DIU_ADDR
> - CONFIG_VIDEO
> - CONFIG_VIDEO_SW_CURSOR
> - CONFIG_VGA_AS_SINGLE_DEVICE
>
> The DIU driver will look for the 'video-mode' environment
> variable, and if defined, enable the DIU as a console during
diff --git
> a/arch/arm/include/asm/mach-imx/mx5_video.h
> b/arch/arm/include/asm/mach-imx/mx5_video.h
> index dc6aa00c894..b55c0fe8971 100644
> --- a/arch/arm/include/asm/mach-imx/mx5_video.h
> +++ b/arch/arm/include/asm/mach-imx/mx5_video.h
> @@ -6,12 +6,7 @@
> #ifndef __MX5_VIDEO_H
> #define __MX5_VIDEO_H
>
> -#ifdef CONFIG_VIDEO
> -void lcd_enable(void);
> -void setup_iomux_lcd(void);
> -#else
> static inline void lcd_enable(void) { } static inline void
setup_iomux_lcd(void)
> { } -#endif
>
> #endif
> diff --git a/arch/arm/mach-nexell/include/mach/display_dev.h
> b/arch/arm/mach-nexell/include/mach/display_dev.h
> index ffa45518d99..39b28ca1299 100644
> --- a/arch/arm/mach-nexell/include/mach/display_dev.h
> +++ b/arch/arm/mach-nexell/include/mach/display_dev.h
> @@ -8,7 +8,7 @@
> #ifndef _NX__DISPLAY_DEV_H_
> #define _NX__DISPLAY_DEV_H_
>
> -#if defined CONFIG_VIDEO || defined CONFIG_DM_VIDEO
> +#if defined CONFIG_DM_VIDEO
> #elif defined CONFIG_LCD
> #include
> #endif
> diff --git a/board/freescale/mx51evk/Makefile
> b/board/freescale/mx51evk/Makefile
> index 1a9581cabf9..808e35015e8 100644
> --- a/board/freescale/mx51evk/Makefile
> +++ b/board/freescale/mx51evk/Makefile
> @@ -5,4 +5,3 @@
> # (C) Copyright 2009 Freescale Semiconductor, Inc.
>
> obj-y+= mx51evk.o
> -obj-$(CONFIG_VIDEO) += mx51evk_video.o
> diff --git a/board/freescale/mx53loco/Makefile
> b/board/freescale/mx53loco/Makefile
> index d2ebd94dca1..9befe426957 100644
> --- a/board/freescale/mx53loco/Makefile
> +++ b/board/freescale/mx53loco/Makefile
> @@ -4,4 +4,3 @@
> # Jason Liu
>
> obj-y+= mx53loco.o
> -obj-$(CONFIG_VIDEO) += mx53loco_video.o
> diff --git a/board/kosagi/novena/novena_spl.c
> b/board/kosagi/novena/novena_spl.c
> index 3d22f2019e9..24c0fb22268 100644
> --- a/board/kosagi/novena/novena_spl.c
> +++ b/board/kosagi/novena/novena_spl.c
> @@ -379,30 +379,7 @@ static void novena_spl_setup_iomux_uart(void)
> imx_iomux_v3_setup_multiple_pads(uart4_pads,
> ARRAY_SIZE(uart4_pads)); }
>
> -/*
> - * Video
> - */
> -#ifdef CONFIG_VIDEO
> -static iomux_v3_cfg_t hdmi_pads[] = {
> - /* "Ghost HPD" pin */
> - MX6_PAD_EIM_A24__GPIO5_IO04 | MUX_PAD_CTRL(NO_PAD_CTRL),
> -
> - /* LCD_PWR_CTL */
> - MX6_PAD_CSI0_DAT10__GPIO5_IO28 | MUX_PAD_CTRL(NO_PAD_CTRL),
> - /* LCD_BL_ON */
do you have plan to add kaslrseed support to extlinux.conf
Hi, Chris Morgan thank you to add kaslrseed to U-boot, do you have plan to add it to extlinux.conf? BR. Ning
Re: [PATCH v5 03/13] mmc: fsl: Use brackets around if()
On 1/22/22 21:07, Simon Glass wrote:
> At present the IS_ENABLED() macro has extra brackets, making it possible
> to write:
>
>if IS_ENABLED(CONFIG_XXX)
>
> but it is a bit confusing. Add the missing brackets.
>
> Signed-off-by: Simon Glass
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
>
> (no changes since v1)
>
> drivers/mmc/fsl_esdhc_imx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
> index 9299635f509..08ea98fe81a 100644
> --- a/drivers/mmc/fsl_esdhc_imx.c
> +++ b/drivers/mmc/fsl_esdhc_imx.c
> @@ -453,7 +453,7 @@ static int esdhc_send_cmd_common(struct fsl_esdhc_priv
> *priv, struct mmc *mmc,
>
> /* Send the command */
> esdhc_write32(®s->cmdarg, cmd->cmdarg);
> - if IS_ENABLED(CONFIG_FSL_USDHC) {
> + if (IS_ENABLED(CONFIG_FSL_USDHC)) {
> u32 mixctrl = esdhc_read32(®s->mixctrl);
>
> esdhc_write32(®s->mixctrl,
Re: [PATCH] cmd: mmc: Consider GP partitions in mmc hwpartition user enh start -
On 1/18/22 06:54, Marek Vasut wrote:
> In case the eMMC contains any GP partitions or user sets up new GP
> partitions, the size of these GP partitions reduce the size of the
> USER partition. Subtract the size of those GP partitions from the
> calculated size of USER partition when using `user enh start -`.
>
> The following test used to fail before:
> ```
> u-boot=> mmc hwpartition gp1 524288 enh user enh 0 - wrrel on check
> Partition configuration:
> User Enhanced Start: 0 Bytes
> User Enhanced Size: 1.8 GiB
> User partition write reliability: on
> GP1 Capacity: 256 MiB ENH
> No GP2 partition
> No GP3 partition
> No GP4 partition
> Total enhanced size exceeds maximum (261 > 229)
> Failed!
> ```
> The test now passes:
> ```
> u-boot=> mmc hwpartition gp1 524288 enh user enh 0 - wrrel on check
> Partition configuration:
> User Enhanced Start: 0 Bytes
> User Enhanced Size: 1.5 GiB
> User partition write reliability: on
> GP1 Capacity: 256 MiB ENH
> No GP2 partition
> No GP3 partition
> No GP4 partition
> ```
>
> Signed-off-by: Marek Vasut
> Cc: Fabio Estevam
> Cc: Jaehoon Chung
> Cc: Peng Fan
> Cc: Stefano Babic
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> cmd/mmc.c | 22 --
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/cmd/mmc.c b/cmd/mmc.c
> index 96d81ffdf36..503dbb6199c 100644
> --- a/cmd/mmc.c
> +++ b/cmd/mmc.c
> @@ -597,7 +597,7 @@ static void parse_hwpart_user_enh_size(struct mmc *mmc,
> struct mmc_hwpart_conf *pconf,
> char *argv)
> {
> - int ret;
> + int i, ret;
>
> pconf->user.enh_size = 0;
>
> @@ -606,7 +606,7 @@ static void parse_hwpart_user_enh_size(struct mmc *mmc,
> ret = mmc_send_ext_csd(mmc, ext_csd);
> if (ret)
> return;
> - /* This value is in 512B block units */
> + /* The enh_size value is in 512B block units */
> pconf->user.enh_size =
> ((ext_csd[EXT_CSD_MAX_ENH_SIZE_MULT + 2] << 16) +
> (ext_csd[EXT_CSD_MAX_ENH_SIZE_MULT + 1] << 8) +
> @@ -614,6 +614,24 @@ static void parse_hwpart_user_enh_size(struct mmc *mmc,
> ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] *
> ext_csd[EXT_CSD_HC_WP_GRP_SIZE];
> pconf->user.enh_size -= pconf->user.enh_start;
> + for (i = 0; i < ARRAY_SIZE(mmc->capacity_gp); i++) {
> + /*
> + * If the eMMC already has GP partitions set,
> + * subtract their size from the maximum USER
> + * partition size.
> + *
> + * Else, if the command was used to configure new
> + * GP partitions, subtract their size from maximum
> + * USER partition size.
> + */
> + if (mmc->capacity_gp[i]) {
> + /* The capacity_gp is in 1B units */
> + pconf->user.enh_size -= mmc->capacity_gp[i] >>
> 9;
> + } else if (pconf->gp_part[i].size) {
> + /* The gp_part[].size is in 512B units */
> + pconf->user.enh_size -= pconf->gp_part[i].size;
> + }
> + }
> } else {
> pconf->user.enh_size = dectoul(argv, NULL);
> }
[PATCH v1 2/2] imx: imx8qm_rm7720: adjust fdt_addr
The Linux Kernel Image size for arm64 is still growing. A Kernel with 54 MB at load address 0x8028 overlaps with fdt_addr at 0x8300. So let's increase it to 0x8400 Signed-off-by: Oliver Graute --- include/configs/imx8qm_rom7720.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/imx8qm_rom7720.h b/include/configs/imx8qm_rom7720.h index 31d861481f..3c905b1446 100644 --- a/include/configs/imx8qm_rom7720.h +++ b/include/configs/imx8qm_rom7720.h @@ -61,7 +61,7 @@ "image=Image\0" \ "panel=NULL\0" \ "console=ttyLP0\0" \ - "fdt_addr=0x8300\0" \ + "fdt_addr=0x8400\0" \ "boot_fdt=try\0" \ "fdt_file=imx8qm-rom7720-a1.dtb\0" \ "initrd_addr=0x8380\0" \ -- 2.17.1
[PATCH v1 1/2] imx: imx8qm_rom7720: Increase CONFIG_SYS_BOOTM_LEN to 64MB
Increase CONFIG_SYS_BOOTM_LEN to 64MB Signed-off-by: Oliver Graute --- include/configs/imx8qm_rom7720.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/imx8qm_rom7720.h b/include/configs/imx8qm_rom7720.h index 666e497b0b..31d861481f 100644 --- a/include/configs/imx8qm_rom7720.h +++ b/include/configs/imx8qm_rom7720.h @@ -21,6 +21,8 @@ #define USDHC2_BASE_ADDR 0x5B02 #define USDHC3_BASE_ADDR 0x5B03 +#define CONFIG_SYS_BOOTM_LEN SZ_64M + /* FUSE command */ /* Boot M4 */ -- 2.17.1
Re: [RFC PATCH v3 4/5] beacon: imx8mn: override env_get_location in imx8mn_beacon.c
On Wed, Jan 26, 2022 at 12:05:22PM -0600, Adam Ford wrote:
> On Sat, Dec 25, 2021 at 2:26 PM Tommaso Merciai
> wrote:
> >
> > Override env_get_location function at board level, previously dropped
> > down from arch/arm/mach-imx/imx8m/soc.c
> >
> > References:
> > - commit 37d3e3bb95d7532e2503f115dd6c6762fd3b0262
> >
> > Signed-off-by: Tommaso Merciai
>
Hi Adam,
> I am going to re-do the patch for the beacon board, because I talked
> it over with my colleagues, and we'd like to force the environment to
> one location or another and not base it on whether or not it was the
> boot device.
>
> I guess my questions is what's the status of the remaining patch
> series, and how do I integrate my desired changes into it? I can send
> you what I want for my board if you're going to resubmit the series.
It's ok for me. Send me your changes.
Thanks.
> I wonder if a sub-function could be called where the existing
> env_get_location() is renamed to something else, but declared as weak
> can called from env_get_location. Anyone who wants a their own
> function can write their own so we don't have two functions with the
> same name declared as weak.
>
> What are your thoughts on that?
Right. In this way every boards that use imx8mp/imx8mn can override this
function according to their own needs.
Tommaso
>
> adam
> > ---
> > board/beacon/imx8mn/imx8mn_beacon.c | 35 -
> > 1 file changed, 34 insertions(+), 1 deletion(-)
> >
> > diff --git a/board/beacon/imx8mn/imx8mn_beacon.c
> > b/board/beacon/imx8mn/imx8mn_beacon.c
> > index 7fe252b262..05ab5613ee 100644
> > --- a/board/beacon/imx8mn/imx8mn_beacon.c
> > +++ b/board/beacon/imx8mn/imx8mn_beacon.c
> > @@ -6,14 +6,47 @@
> > #include
> > #include
> > #include
> > -
> > +#include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > DECLARE_GLOBAL_DATA_PTR;
> >
> > +enum env_location env_get_location(enum env_operation op, int prio)
> > +{
> > + enum boot_device dev = get_boot_device();
> > + enum env_location env_loc = ENVL_UNKNOWN;
> > +
> > + if (prio)
> > + return env_loc;
> > +
> > + if (IS_ENABLED(CONFIG_ENV_IS_IN_SPI_FLASH) && dev == QSPI_BOOT) {
> > + env_loc = ENVL_SPI_FLASH;
> > + } else if (IS_ENABLED(CONFIG_ENV_IS_IN_NAND) && dev == NAND_BOOT) {
> > + env_loc = ENVL_NAND;
> > + } else if (IS_ENABLED(CONFIG_ENV_IS_IN_MMC)) {
> > + switch (dev) {
> > + case SD1_BOOT:
> > + case SD2_BOOT:
> > + case SD3_BOOT:
> > + case MMC1_BOOT:
> > + case MMC2_BOOT:
> > + case MMC3_BOOT:
> > + env_loc = ENVL_MMC;
> > + break;
> > + default:
> > + break;
> > + }
> > + } else if (IS_ENABLED(CONFIG_ENV_IS_NOWHERE)) {
> > + env_loc = ENVL_MMC;
> > + }
> > +
> > + return env_loc;
> > +}
> > +
> > #if IS_ENABLED(CONFIG_FEC_MXC)
> > static int setup_fec(void)
> > {
> > --
> > 2.25.1
> >
tools: imximage: i.MXRT flash config table (questions)
Hi friends!! I'm sorry if this isn't the right way of asking a question. For booting the imxrt10xx from SPI flash it needs a flash config block starting with "ascii "FCFB" Big Endian" from address 0 - 0x1000 of the flash documented on page 217 of the imxrt1050RM. The problem I see is that we cant put a binary blob into U-Boot, and I don't see a way to do this in the IMX docs folder(maybe I'm blind). So I want to ask if there is a way to do it already and if not should i make another program for /tools or add it to imximage. I have already made something simple here: https://github.com/Mr-Bossman/imx_flashconf https://repo.jachan.dev/?p=imx_flashconf.git;a=tree Please ignore the formatting inconsistencies. Also on a side note is there a way for U-Boot to run in XIP mode it seems like there is but I cant figure it out. And would there be willingness to add drivers for psram? Sorry about the spam... Thank you, Jesse Taube
drivers: mtd: spi: Use correct 4 byte mode enablement for ISSI SPI flash devices alongside spi-nor-tiny.c subsystem
Hi All, I noticed this was missing from the spi-nor-tiny.c subsystem while trying to use an ISSI SPI flash device with the U-Boot SPL. This patch will allow 4 byte addressing mode to be enabled with ISSI flash devices while inside the U-Boot SPL / using spi-nor-tiny.c. Sincerely, Nathan From 218e00fcaea8c5795e792af09f5d21fc19e3d831 Mon Sep 17 00:00:00 2001 From: Nathan Barrett-Morrison Date: Wed, 26 Jan 2022 13:43:53 -0500 Subject: [PATCH] drivers: mtd: spi: Use correct 4 byte mode enablement for ISSI SPI flash devices alongside spi-nor-tiny.c subsystem Signed-off-by: Nathan Barrett-Morrison Cc: Jagan Teki Cc: Vignesh R CC: Tom Rini --- drivers/mtd/spi/spi-nor-tiny.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mtd/spi/spi-nor-tiny.c b/drivers/mtd/spi/spi-nor-tiny.c index 68152ce3b4..130917aaa8 100644 --- a/drivers/mtd/spi/spi-nor-tiny.c +++ b/drivers/mtd/spi/spi-nor-tiny.c @@ -219,6 +219,7 @@ static inline int set_4byte(struct spi_nor *nor, const struct flash_info *info, case SNOR_MFR_MICRON: /* Some Micron need WREN command; all will accept it */ need_wren = true; + case SNOR_MFR_ISSI: case SNOR_MFR_MACRONIX: case SNOR_MFR_WINBOND: if (need_wren) -- 2.34.1
[PATCH] drivers: mtd: spi: Use correct 4 byte mode enablement for ISSI SPI flash devices alongside spi-nor-tiny.c subsystem
Hi All, I noticed this was missing from the spi-nor-tiny.c subsystem while trying to use an ISSI SPI flash device with the U-Boot SPL. This patch will allow 4 byte addressing mode to be enabled with ISSI flash devices while inside the U-Boot SPL / using spi-nor-tiny.c. Sincerely, Nathan
drivers: mtd: spi: Allow Quad I/O enablement for ISSI SPI flash devices alongside spi-nor-tiny.c subsystem
Hi All,
I noticed this was missing from the spi-nor-tiny.c subsystem while trying
to use an ISSI SPI flash device with the U-Boot SPL.
This patch will allow Quad (4x) I/O mode to be enabled with ISSI flash
devices while inside the U-Boot SPL / using spi-nor-tiny.c.
Sincerely,
Nathan
From 1a7fd52f21d3d3ad4b2ff736a9ea3c1affb9c007 Mon Sep 17 00:00:00 2001
From: Nathan Barrett-Morrison
Date: Wed, 26 Jan 2022 13:44:39 -0500
Subject: [PATCH] drivers: mtd: spi: Allow Quad I/O enablement for ISSI SPI
flash devices alongside spi-nor-tiny.c subsystem
Signed-off-by: Nathan Barrett-Morrison
Cc: Jagan Teki
Cc: Vignesh R
CC: Tom Rini
---
drivers/mtd/spi/spi-nor-tiny.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi/spi-nor-tiny.c b/drivers/mtd/spi/spi-nor-tiny.c
index 130917aaa8..4957448d11 100644
--- a/drivers/mtd/spi/spi-nor-tiny.c
+++ b/drivers/mtd/spi/spi-nor-tiny.c
@@ -664,6 +664,7 @@ static int spi_nor_setup(struct spi_nor *nor, const struct flash_info *info,
switch (JEDEC_MFR(info)) {
#ifdef CONFIG_SPI_FLASH_MACRONIX
case SNOR_MFR_MACRONIX:
+ case SNOR_MFR_ISSI:
err = macronix_quad_enable(nor);
break;
#endif
--
2.34.1
Re: i.MX8MN (ROMv2) fails to boot over USB
On Wed, Jan 26, 2022 at 12:31 PM Michael Nazzareno Trimarchi wrote: > > HI Adam > > On Wed, Jan 26, 2022 at 7:01 PM Adam Ford wrote: > > > > On Wed, Jan 26, 2022 at 11:24 AM Michael Nazzareno Trimarchi > > wrote: > > > > > > Hi Adam > > > > > > On Wed, Jan 26, 2022 at 2:26 AM Tim Harvey wrote: > > > > > > > > On Tue, Jan 25, 2022 at 3:49 PM Adam Ford wrote: > > > > > > > > > > I have a flash.bin file that boots over MMC just fine, but when I use > > > > > that same flash.bin file, it appears to hang after running ATF. I > > > > > dumped some debug info for printing the handling of the FIT file, and > > > > > I noticed the fit read sizes are also not consistent between MMC and > > > > > USB loads with the identical flash.bin. > > > > > > > > > > MMC booting is calling spl_romapi_raw_seekable_read, but the USB > > > > > booting is not. Maybe this is normal. > > > > > > > > > > I was hoping someone might have some pointers on how I can > > > > > troubleshoot this. It's also weird to me that the various nodes are > > > > > listed twice in the USB boot, but not the MMC boot. > > > > > > > > > > I have poked around in the spl_imx_romapi.c file, but I am not seeing > > > > > anything obvious. > > > > > > > > > > SPL and ATF are executing, so it's partially decoding the FIT file and > > > > > executing those two pieces correctly from what I can see. > > > > > > > > > > USB log (no FDT) > > > > > U-Boot SPL 2022.01-00753-g7f7f25ecb8-dirty (Jan 25 2022 - 15:54:57 > > > > > -0600) > > > > > WDT: Started watchdog@3028 with servicing (60s timeout) > > > > > Trying to boot from BOOTROM > > > > > Find img info 0x&48027600, size 872 > > > > > Need continue download 1024 > > > > > fit read sector 48027600, sectors=872, dst=42206c40, count=872, > > > > > size=0x368 > > > > > firmware: 'uboot' > > > > > External data: dst=4020, offset=3000, size=a4d98 > > > > > fdt: 'fdt' > > > > > External data: dst=402a4dc0, offset=b1e60, size=af68 > > > > > loadables: 'atf' > > > > > External data: dst=96, offset=a7d98, size=a0c6 > > > > > no string for index 1 > > > > > Download 772040, Total size 773576 > > > > > fit read sector 48027600, sectors=872, dst=42206fb0, count=872, > > > > > size=0x368 > > > > > firmware: 'uboot' > > > > > External data: dst=4020, offset=3000, size=a4d98 > > > > > fdt: 'fdt' > > > > > External data: dst=402a4dc0, offset=b1e60, size=af68 > > > > > loadables: 'atf' > > > > > External data: dst=96, offset=a7d98, size=a0c6 > > > > > no string for index 1 > > > > > NOTICE: BL31: v2.4(release):lf-5.10.72-2.2.0-0-g5782363f9 > > > > > NOTICE: BL31: Built : 14:45:34, Jan 25 2022 > > > > > > > > > > > > > > > > > > > > MMC Booting Log (with DTB): > > > > > > > > > > U-Boot SPL 2022.01-00753-g7f7f25ecb8-dirty (Jan 25 2022 - 15:54:57 > > > > > -0600) > > > > > WDT: Started watchdog@3028 with servicing (60s timeout) > > > > > Trying to boot from BOOTROM > > > > > image offset 0x8000, pagesize 0x200, ivt offset 0x0 > > > > > ROM API load from 0x6, size 0x400 > > > > > spl_romapi_raw_seekable_read 0x6, size 0x400 > > > > > fit read sector 300, sectors=2, dst=42206c40, count=2, size=0x368 > > > > > firmware: 'uboot' > > > > > ROM API load from 0x63000, size 0xa4e00 > > > > > spl_romapi_raw_seekable_read 0x63000, size 0xa4e00 > > > > > External data: dst=4020, offset=3000, size=a4d98 > > > > > fdt: 'fdt' > > > > > ROM API load from 0x111e00, size 0xb000 > > > > > spl_romapi_raw_seekable_read 0x111e00, size 0xb000 > > > > > External data: dst=402a4dc0, offset=b1e60, size=af68 > > > > > loadables: 'atf' > > > > > ROM API load from 0x107c00, size 0xa400 > > > > > spl_romapi_raw_seekable_read 0x107c00, size 0xa400 > > > > > External data: dst=96, offset=a7d98, size=a0c6 > > > > > no string for index 1 > > > > > NOTICE: BL31: v2.4(release):lf-5.10.72-2.2.0-0-g5782363f9 > > > > > NOTICE: BL31: Built : 14:45:34, Jan 25 2022 > > > > > > > > > > > > > > > > > > Adam, > > > > > > > > I've previously run into this as well and unfortunately have no > > > > solution. Note that I had to hack in some support to the SPL for USB > > > > which I assume you've done as well. If I recall trying to enable > > > > DM_USB for the SPL took too much space so that hacks I had revolved > > > > around getting it to work in the non-DM fashion. > > > > > > I was having the same problem and I found that was related to > > > diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c > > > index 863508776d..9d6dab08e6 100644 > > > --- a/arch/arm/mach-imx/imx8m/soc.c > > > +++ b/arch/arm/mach-imx/imx8m/soc.c > > > @@ -1333,6 +1333,7 @@ enum env_location env_get_location(enum > > > env_operation op, int prio) > > > > > > You should support USB_BOOT in switch case or change your defconfig > > > and add CONFIG_ENV_IS_NOWHERE=y > > > > Thanks for the tip. it strikes me as odd that the system would hang > > if we don't know what to do with the environment. I would expect it > > to just
Re: i.MX8MN (ROMv2) fails to boot over USB
HI Adam On Wed, Jan 26, 2022 at 7:01 PM Adam Ford wrote: > > On Wed, Jan 26, 2022 at 11:24 AM Michael Nazzareno Trimarchi > wrote: > > > > Hi Adam > > > > On Wed, Jan 26, 2022 at 2:26 AM Tim Harvey wrote: > > > > > > On Tue, Jan 25, 2022 at 3:49 PM Adam Ford wrote: > > > > > > > > I have a flash.bin file that boots over MMC just fine, but when I use > > > > that same flash.bin file, it appears to hang after running ATF. I > > > > dumped some debug info for printing the handling of the FIT file, and > > > > I noticed the fit read sizes are also not consistent between MMC and > > > > USB loads with the identical flash.bin. > > > > > > > > MMC booting is calling spl_romapi_raw_seekable_read, but the USB > > > > booting is not. Maybe this is normal. > > > > > > > > I was hoping someone might have some pointers on how I can > > > > troubleshoot this. It's also weird to me that the various nodes are > > > > listed twice in the USB boot, but not the MMC boot. > > > > > > > > I have poked around in the spl_imx_romapi.c file, but I am not seeing > > > > anything obvious. > > > > > > > > SPL and ATF are executing, so it's partially decoding the FIT file and > > > > executing those two pieces correctly from what I can see. > > > > > > > > USB log (no FDT) > > > > U-Boot SPL 2022.01-00753-g7f7f25ecb8-dirty (Jan 25 2022 - 15:54:57 > > > > -0600) > > > > WDT: Started watchdog@3028 with servicing (60s timeout) > > > > Trying to boot from BOOTROM > > > > Find img info 0x&48027600, size 872 > > > > Need continue download 1024 > > > > fit read sector 48027600, sectors=872, dst=42206c40, count=872, > > > > size=0x368 > > > > firmware: 'uboot' > > > > External data: dst=4020, offset=3000, size=a4d98 > > > > fdt: 'fdt' > > > > External data: dst=402a4dc0, offset=b1e60, size=af68 > > > > loadables: 'atf' > > > > External data: dst=96, offset=a7d98, size=a0c6 > > > > no string for index 1 > > > > Download 772040, Total size 773576 > > > > fit read sector 48027600, sectors=872, dst=42206fb0, count=872, > > > > size=0x368 > > > > firmware: 'uboot' > > > > External data: dst=4020, offset=3000, size=a4d98 > > > > fdt: 'fdt' > > > > External data: dst=402a4dc0, offset=b1e60, size=af68 > > > > loadables: 'atf' > > > > External data: dst=96, offset=a7d98, size=a0c6 > > > > no string for index 1 > > > > NOTICE: BL31: v2.4(release):lf-5.10.72-2.2.0-0-g5782363f9 > > > > NOTICE: BL31: Built : 14:45:34, Jan 25 2022 > > > > > > > > > > > > > > > > MMC Booting Log (with DTB): > > > > > > > > U-Boot SPL 2022.01-00753-g7f7f25ecb8-dirty (Jan 25 2022 - 15:54:57 > > > > -0600) > > > > WDT: Started watchdog@3028 with servicing (60s timeout) > > > > Trying to boot from BOOTROM > > > > image offset 0x8000, pagesize 0x200, ivt offset 0x0 > > > > ROM API load from 0x6, size 0x400 > > > > spl_romapi_raw_seekable_read 0x6, size 0x400 > > > > fit read sector 300, sectors=2, dst=42206c40, count=2, size=0x368 > > > > firmware: 'uboot' > > > > ROM API load from 0x63000, size 0xa4e00 > > > > spl_romapi_raw_seekable_read 0x63000, size 0xa4e00 > > > > External data: dst=4020, offset=3000, size=a4d98 > > > > fdt: 'fdt' > > > > ROM API load from 0x111e00, size 0xb000 > > > > spl_romapi_raw_seekable_read 0x111e00, size 0xb000 > > > > External data: dst=402a4dc0, offset=b1e60, size=af68 > > > > loadables: 'atf' > > > > ROM API load from 0x107c00, size 0xa400 > > > > spl_romapi_raw_seekable_read 0x107c00, size 0xa400 > > > > External data: dst=96, offset=a7d98, size=a0c6 > > > > no string for index 1 > > > > NOTICE: BL31: v2.4(release):lf-5.10.72-2.2.0-0-g5782363f9 > > > > NOTICE: BL31: Built : 14:45:34, Jan 25 2022 > > > > > > > > > > > > > > Adam, > > > > > > I've previously run into this as well and unfortunately have no > > > solution. Note that I had to hack in some support to the SPL for USB > > > which I assume you've done as well. If I recall trying to enable > > > DM_USB for the SPL took too much space so that hacks I had revolved > > > around getting it to work in the non-DM fashion. > > > > I was having the same problem and I found that was related to > > diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c > > index 863508776d..9d6dab08e6 100644 > > --- a/arch/arm/mach-imx/imx8m/soc.c > > +++ b/arch/arm/mach-imx/imx8m/soc.c > > @@ -1333,6 +1333,7 @@ enum env_location env_get_location(enum > > env_operation op, int prio) > > > > You should support USB_BOOT in switch case or change your defconfig > > and add CONFIG_ENV_IS_NOWHERE=y > > Thanks for the tip. it strikes me as odd that the system would hang > if we don't know what to do with the environment. I would expect it > to just load the default and move on. > > I'll work on a defconfig fix. > Those nxp function should be dropped or fixed anyway Michael > adam > > > > Michael > > > > > > > > > > Best regards, > > > > > > Tim -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 m
[PATCH] imx: imx8mn_beacon: Fix USB booting
The i.MX8M Nano can boot over USB using the boot ROM instead of adding extra code to SPL to support USB drivers, etc. However, when booting from USB, the environment doesnt' know where to load and causes a hang. Fix this hang by supporting CONFIG_ENV_IS_NOWHERE=y. It only falls back to this condition when booting from USB, so it does not impact MMC booting. Suggested-by: Michael Nazzareno Trimarchi Signed-off-by: Adam Ford diff --git a/configs/imx8mn_beacon_2g_defconfig b/configs/imx8mn_beacon_2g_defconfig index 8b98d687ec..1766a43cce 100644 --- a/configs/imx8mn_beacon_2g_defconfig +++ b/configs/imx8mn_beacon_2g_defconfig @@ -66,6 +66,7 @@ CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y CONFIG_OF_SPL_REMOVE_PROPS="interrupt-parent interrupts" CONFIG_ENV_OVERWRITE=y +CONFIG_ENV_IS_NOWHERE=y CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_SYS_MMC_ENV_DEV=2 diff --git a/configs/imx8mn_beacon_defconfig b/configs/imx8mn_beacon_defconfig index a707ee664e..8ac36121aa 100644 --- a/configs/imx8mn_beacon_defconfig +++ b/configs/imx8mn_beacon_defconfig @@ -66,6 +66,7 @@ CONFIG_CMD_FAT=y CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y CONFIG_ENV_OVERWRITE=y +CONFIG_ENV_IS_NOWHERE=y CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_SYS_MMC_ENV_DEV=2 -- 2.32.0
Re: [RFC PATCH v3 4/5] beacon: imx8mn: override env_get_location in imx8mn_beacon.c
On Sat, Dec 25, 2021 at 2:26 PM Tommaso Merciai wrote:
>
> Override env_get_location function at board level, previously dropped
> down from arch/arm/mach-imx/imx8m/soc.c
>
> References:
> - commit 37d3e3bb95d7532e2503f115dd6c6762fd3b0262
>
> Signed-off-by: Tommaso Merciai
I am going to re-do the patch for the beacon board, because I talked
it over with my colleagues, and we'd like to force the environment to
one location or another and not base it on whether or not it was the
boot device.
I guess my questions is what's the status of the remaining patch
series, and how do I integrate my desired changes into it? I can send
you what I want for my board if you're going to resubmit the series.
I wonder if a sub-function could be called where the existing
env_get_location() is renamed to something else, but declared as weak
can called from env_get_location. Anyone who wants a their own
function can write their own so we don't have two functions with the
same name declared as weak.
What are your thoughts on that?
adam
> ---
> board/beacon/imx8mn/imx8mn_beacon.c | 35 -
> 1 file changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/board/beacon/imx8mn/imx8mn_beacon.c
> b/board/beacon/imx8mn/imx8mn_beacon.c
> index 7fe252b262..05ab5613ee 100644
> --- a/board/beacon/imx8mn/imx8mn_beacon.c
> +++ b/board/beacon/imx8mn/imx8mn_beacon.c
> @@ -6,14 +6,47 @@
> #include
> #include
> #include
> -
> +#include
> #include
> #include
> +#include
> #include
> #include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +enum env_location env_get_location(enum env_operation op, int prio)
> +{
> + enum boot_device dev = get_boot_device();
> + enum env_location env_loc = ENVL_UNKNOWN;
> +
> + if (prio)
> + return env_loc;
> +
> + if (IS_ENABLED(CONFIG_ENV_IS_IN_SPI_FLASH) && dev == QSPI_BOOT) {
> + env_loc = ENVL_SPI_FLASH;
> + } else if (IS_ENABLED(CONFIG_ENV_IS_IN_NAND) && dev == NAND_BOOT) {
> + env_loc = ENVL_NAND;
> + } else if (IS_ENABLED(CONFIG_ENV_IS_IN_MMC)) {
> + switch (dev) {
> + case SD1_BOOT:
> + case SD2_BOOT:
> + case SD3_BOOT:
> + case MMC1_BOOT:
> + case MMC2_BOOT:
> + case MMC3_BOOT:
> + env_loc = ENVL_MMC;
> + break;
> + default:
> + break;
> + }
> + } else if (IS_ENABLED(CONFIG_ENV_IS_NOWHERE)) {
> + env_loc = ENVL_MMC;
> + }
> +
> + return env_loc;
> +}
> +
> #if IS_ENABLED(CONFIG_FEC_MXC)
> static int setup_fec(void)
> {
> --
> 2.25.1
>
Re: i.MX8MN (ROMv2) fails to boot over USB
On Wed, Jan 26, 2022 at 11:24 AM Michael Nazzareno Trimarchi wrote: > > Hi Adam > > On Wed, Jan 26, 2022 at 2:26 AM Tim Harvey wrote: > > > > On Tue, Jan 25, 2022 at 3:49 PM Adam Ford wrote: > > > > > > I have a flash.bin file that boots over MMC just fine, but when I use > > > that same flash.bin file, it appears to hang after running ATF. I > > > dumped some debug info for printing the handling of the FIT file, and > > > I noticed the fit read sizes are also not consistent between MMC and > > > USB loads with the identical flash.bin. > > > > > > MMC booting is calling spl_romapi_raw_seekable_read, but the USB > > > booting is not. Maybe this is normal. > > > > > > I was hoping someone might have some pointers on how I can > > > troubleshoot this. It's also weird to me that the various nodes are > > > listed twice in the USB boot, but not the MMC boot. > > > > > > I have poked around in the spl_imx_romapi.c file, but I am not seeing > > > anything obvious. > > > > > > SPL and ATF are executing, so it's partially decoding the FIT file and > > > executing those two pieces correctly from what I can see. > > > > > > USB log (no FDT) > > > U-Boot SPL 2022.01-00753-g7f7f25ecb8-dirty (Jan 25 2022 - 15:54:57 -0600) > > > WDT: Started watchdog@3028 with servicing (60s timeout) > > > Trying to boot from BOOTROM > > > Find img info 0x&48027600, size 872 > > > Need continue download 1024 > > > fit read sector 48027600, sectors=872, dst=42206c40, count=872, size=0x368 > > > firmware: 'uboot' > > > External data: dst=4020, offset=3000, size=a4d98 > > > fdt: 'fdt' > > > External data: dst=402a4dc0, offset=b1e60, size=af68 > > > loadables: 'atf' > > > External data: dst=96, offset=a7d98, size=a0c6 > > > no string for index 1 > > > Download 772040, Total size 773576 > > > fit read sector 48027600, sectors=872, dst=42206fb0, count=872, size=0x368 > > > firmware: 'uboot' > > > External data: dst=4020, offset=3000, size=a4d98 > > > fdt: 'fdt' > > > External data: dst=402a4dc0, offset=b1e60, size=af68 > > > loadables: 'atf' > > > External data: dst=96, offset=a7d98, size=a0c6 > > > no string for index 1 > > > NOTICE: BL31: v2.4(release):lf-5.10.72-2.2.0-0-g5782363f9 > > > NOTICE: BL31: Built : 14:45:34, Jan 25 2022 > > > > > > > > > > > > MMC Booting Log (with DTB): > > > > > > U-Boot SPL 2022.01-00753-g7f7f25ecb8-dirty (Jan 25 2022 - 15:54:57 -0600) > > > WDT: Started watchdog@3028 with servicing (60s timeout) > > > Trying to boot from BOOTROM > > > image offset 0x8000, pagesize 0x200, ivt offset 0x0 > > > ROM API load from 0x6, size 0x400 > > > spl_romapi_raw_seekable_read 0x6, size 0x400 > > > fit read sector 300, sectors=2, dst=42206c40, count=2, size=0x368 > > > firmware: 'uboot' > > > ROM API load from 0x63000, size 0xa4e00 > > > spl_romapi_raw_seekable_read 0x63000, size 0xa4e00 > > > External data: dst=4020, offset=3000, size=a4d98 > > > fdt: 'fdt' > > > ROM API load from 0x111e00, size 0xb000 > > > spl_romapi_raw_seekable_read 0x111e00, size 0xb000 > > > External data: dst=402a4dc0, offset=b1e60, size=af68 > > > loadables: 'atf' > > > ROM API load from 0x107c00, size 0xa400 > > > spl_romapi_raw_seekable_read 0x107c00, size 0xa400 > > > External data: dst=96, offset=a7d98, size=a0c6 > > > no string for index 1 > > > NOTICE: BL31: v2.4(release):lf-5.10.72-2.2.0-0-g5782363f9 > > > NOTICE: BL31: Built : 14:45:34, Jan 25 2022 > > > > > > > > > > Adam, > > > > I've previously run into this as well and unfortunately have no > > solution. Note that I had to hack in some support to the SPL for USB > > which I assume you've done as well. If I recall trying to enable > > DM_USB for the SPL took too much space so that hacks I had revolved > > around getting it to work in the non-DM fashion. > > I was having the same problem and I found that was related to > diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c > index 863508776d..9d6dab08e6 100644 > --- a/arch/arm/mach-imx/imx8m/soc.c > +++ b/arch/arm/mach-imx/imx8m/soc.c > @@ -1333,6 +1333,7 @@ enum env_location env_get_location(enum > env_operation op, int prio) > > You should support USB_BOOT in switch case or change your defconfig > and add CONFIG_ENV_IS_NOWHERE=y Thanks for the tip. it strikes me as odd that the system would hang if we don't know what to do with the environment. I would expect it to just load the default and move on. I'll work on a defconfig fix. adam > > Michael > > > > > > Best regards, > > > > Tim
Re: [PATCH v2 09/12] configs: sunxi: Add common SUNIV header
On 1/26/22 08:53, Jesse Taube wrote: From: Icenowy Zheng Adds support for SUNIV and the F1C100s. Signed-off-by: Icenowy Zheng Signed-off-by: Jesse Taube --- V1->V2: * Combine ifdefs * Fix indentation * Fix negative logic * Fix rebase artifacts * Remove CONFIG_SYS_LOAD_ADDR * Remove CONFIG_ENV_SECT_SIZE --- include/configs/suniv.h| 14 include/configs/sunxi-common.h | 59 +- 2 files changed, 57 insertions(+), 16 deletions(-) create mode 100644 include/configs/suniv.h diff --git a/include/configs/suniv.h b/include/configs/suniv.h new file mode 100644 index 00..6118cd5e1a --- /dev/null +++ b/include/configs/suniv.h @@ -0,0 +1,14 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Configuration settings for new Allwinner F-series (suniv) CPU + */ + +#ifndef __CONFIG_H +#define __CONFIG_H + +/* + * Include common sunxi configuration where most the settings are + */ +#include + +#endif /* __CONFIG_H */ diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 7260eb72a4..38c3321c4f 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -22,7 +22,12 @@ /* Serial & console */ #define CONFIG_SYS_NS16550_SERIAL /* ns16550 reg in the low bits of cpu reg */ +#ifdef CONFIG_MACH_SUNIV +/* suniv doesn't have apb2 and uart is connected to apb1 */ +#define CONFIG_SYS_NS16550_CLK 1 +#else #define CONFIG_SYS_NS16550_CLK2400 +#endif #ifndef CONFIG_DM_SERIAL # define CONFIG_SYS_NS16550_REG_SIZE -4 # define CONFIG_SYS_NS16550_COM1 SUNXI_UART0_BASE @@ -49,6 +54,15 @@ * since it needs to fit in with the other values. By also #defining it * we get warnings if the Kconfig value mismatches. */ #define CONFIG_SPL_BSS_START_ADDR 0x2ff8 +#elif defined(CONFIG_MACH_SUNIV) +#define SDRAM_OFFSET(x) 0x8##x +#define CONFIG_SYS_SDRAM_BASE 0x8000 +/* Note SPL_STACK_R_ADDR is set through Kconfig, we include it here + * since it needs to fit in with the other values. By also #defining it + * we get warnings if the Kconfig value mismatches. + */ +#define CONFIG_SPL_STACK_R_ADDR0x81e0 +#define CONFIG_SPL_BSS_START_ADDR 0x81f8 #else #define SDRAM_OFFSET(x) 0x4##x #define CONFIG_SYS_SDRAM_BASE 0x4000 @@ -186,21 +200,7 @@ #define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(FE0)) #define RAMDISK_ADDR_R__stringify(SDRAM_OFFSET(FF0)) -#else -/* - * 160M RAM (256M minimum minus 64MB heap + 32MB for u-boot, stack, fb, etc. - * 32M uncompressed kernel, 16M compressed kernel, 1M fdt, - * 1M script, 1M pxe, 1M dt overlay and the ramdisk at the end. - */ -#ifndef CONFIG_MACH_SUN8I_V3S -#define BOOTM_SIZE__stringify(0xa00) -#define KERNEL_ADDR_R __stringify(SDRAM_OFFSET(200)) -#define FDT_ADDR_R__stringify(SDRAM_OFFSET(300)) -#define SCRIPT_ADDR_R __stringify(SDRAM_OFFSET(310)) -#define PXEFILE_ADDR_R__stringify(SDRAM_OFFSET(320)) -#define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(330)) -#define RAMDISK_ADDR_R__stringify(SDRAM_OFFSET(340)) -#else +#elif defined(CONFIG_MACH_SUN8I_V3S) /* * 64M RAM minus 2MB heap + 16MB for u-boot, stack, fb, etc. * 16M uncompressed kernel, 8M compressed kernel, 1M fdt, @@ -213,7 +213,34 @@ #define PXEFILE_ADDR_R__stringify(SDRAM_OFFSET(1A0)) #define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(1B0)) #define RAMDISK_ADDR_R__stringify(SDRAM_OFFSET(1C0)) -#endif + +#elif defined(CONFIG_MACH_SUNIV) +/* + * 32M RAM minus 1MB heap + 8MB for u-boot, stack, fb, etc. + * 8M uncompressed kernel, 4M compressed kernel, 512K fdt, + * 512K script, 512K pxe and the ramdisk at the end. + */ +#define BOOTM_SIZE__stringify(0x170) +#define KERNEL_ADDR_R __stringify(SDRAM_OFFSET(050)) +#define FDT_ADDR_R__stringify(SDRAM_OFFSET(0C0)) +#define SCRIPT_ADDR_R __stringify(SDRAM_OFFSET(0C5)) +#define PXEFILE_ADDR_R__stringify(SDRAM_OFFSET(0D0)) +#define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(0D5)) +#define RAMDISK_ADDR_R__stringify(SDRAM_OFFSET(0D6)) + +#else +/* + * 160M RAM (256M minimum minus 64MB heap + 32MB for u-boot, stack, fb, etc. + * 32M uncompressed kernel, 16M compressed kernel, 1M fdt, + * 1M script, 1M pxe and the ramdisk at the end. + */ ^^ I copied wrong comment I'll fix this in V3... +#define BOOTM_SIZE__stringify(0xa00) +#define KERNEL_ADDR_R __stringify(SDRAM_OFFSET(200)) +#define FDT_ADDR_R__stringify(SDRAM_OFFSET(300)) +#define SCRIPT_ADDR_R __stringify(SDRAM_OFFSET(310)) +#define PXEFILE_ADDR_R__stringify(SDRAM_OFFSET(320)) +#define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(330)) +#define RAMDISK_ADDR_R__stringify(SDRAM_OFFSET(340)) #endif #define MEM_LAYOUT_ENV_SETTINGS \
Re: i.MX8MN (ROMv2) fails to boot over USB
Hi Adam On Wed, Jan 26, 2022 at 2:26 AM Tim Harvey wrote: > > On Tue, Jan 25, 2022 at 3:49 PM Adam Ford wrote: > > > > I have a flash.bin file that boots over MMC just fine, but when I use > > that same flash.bin file, it appears to hang after running ATF. I > > dumped some debug info for printing the handling of the FIT file, and > > I noticed the fit read sizes are also not consistent between MMC and > > USB loads with the identical flash.bin. > > > > MMC booting is calling spl_romapi_raw_seekable_read, but the USB > > booting is not. Maybe this is normal. > > > > I was hoping someone might have some pointers on how I can > > troubleshoot this. It's also weird to me that the various nodes are > > listed twice in the USB boot, but not the MMC boot. > > > > I have poked around in the spl_imx_romapi.c file, but I am not seeing > > anything obvious. > > > > SPL and ATF are executing, so it's partially decoding the FIT file and > > executing those two pieces correctly from what I can see. > > > > USB log (no FDT) > > U-Boot SPL 2022.01-00753-g7f7f25ecb8-dirty (Jan 25 2022 - 15:54:57 -0600) > > WDT: Started watchdog@3028 with servicing (60s timeout) > > Trying to boot from BOOTROM > > Find img info 0x&48027600, size 872 > > Need continue download 1024 > > fit read sector 48027600, sectors=872, dst=42206c40, count=872, size=0x368 > > firmware: 'uboot' > > External data: dst=4020, offset=3000, size=a4d98 > > fdt: 'fdt' > > External data: dst=402a4dc0, offset=b1e60, size=af68 > > loadables: 'atf' > > External data: dst=96, offset=a7d98, size=a0c6 > > no string for index 1 > > Download 772040, Total size 773576 > > fit read sector 48027600, sectors=872, dst=42206fb0, count=872, size=0x368 > > firmware: 'uboot' > > External data: dst=4020, offset=3000, size=a4d98 > > fdt: 'fdt' > > External data: dst=402a4dc0, offset=b1e60, size=af68 > > loadables: 'atf' > > External data: dst=96, offset=a7d98, size=a0c6 > > no string for index 1 > > NOTICE: BL31: v2.4(release):lf-5.10.72-2.2.0-0-g5782363f9 > > NOTICE: BL31: Built : 14:45:34, Jan 25 2022 > > > > > > > > MMC Booting Log (with DTB): > > > > U-Boot SPL 2022.01-00753-g7f7f25ecb8-dirty (Jan 25 2022 - 15:54:57 -0600) > > WDT: Started watchdog@3028 with servicing (60s timeout) > > Trying to boot from BOOTROM > > image offset 0x8000, pagesize 0x200, ivt offset 0x0 > > ROM API load from 0x6, size 0x400 > > spl_romapi_raw_seekable_read 0x6, size 0x400 > > fit read sector 300, sectors=2, dst=42206c40, count=2, size=0x368 > > firmware: 'uboot' > > ROM API load from 0x63000, size 0xa4e00 > > spl_romapi_raw_seekable_read 0x63000, size 0xa4e00 > > External data: dst=4020, offset=3000, size=a4d98 > > fdt: 'fdt' > > ROM API load from 0x111e00, size 0xb000 > > spl_romapi_raw_seekable_read 0x111e00, size 0xb000 > > External data: dst=402a4dc0, offset=b1e60, size=af68 > > loadables: 'atf' > > ROM API load from 0x107c00, size 0xa400 > > spl_romapi_raw_seekable_read 0x107c00, size 0xa400 > > External data: dst=96, offset=a7d98, size=a0c6 > > no string for index 1 > > NOTICE: BL31: v2.4(release):lf-5.10.72-2.2.0-0-g5782363f9 > > NOTICE: BL31: Built : 14:45:34, Jan 25 2022 > > > > > > Adam, > > I've previously run into this as well and unfortunately have no > solution. Note that I had to hack in some support to the SPL for USB > which I assume you've done as well. If I recall trying to enable > DM_USB for the SPL took too much space so that hacks I had revolved > around getting it to work in the non-DM fashion. I was having the same problem and I found that was related to diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c index 863508776d..9d6dab08e6 100644 --- a/arch/arm/mach-imx/imx8m/soc.c +++ b/arch/arm/mach-imx/imx8m/soc.c @@ -1333,6 +1333,7 @@ enum env_location env_get_location(enum env_operation op, int prio) You should support USB_BOOT in switch case or change your defconfig and add CONFIG_ENV_IS_NOWHERE=y Michael > > Best regards, > > Tim
Re: [PATCH v2] binman: Skip node generation for images read from files
On 26.01.22 16:57, Simon Glass wrote:
Hi Jan,
On Mon, 17 Jan 2022 at 00:28, Jan Kiszka wrote:
From: Jan Kiszka
We can and should run the node generator only when creating a new image.
When we read it back, there is no need to generate nodes - they already
exits, and binman does not dive that deep into the image - and there is
no way to provide the required fdt-list. So forward the mode from the
image to every Entry object it contains so that Entry_fit can simply
skip generator nodes when reading them from an fdtmap.
This unbreaks all read-backs of images that contain generator nodes in
their fdtmap.
Signed-off-by: Jan Kiszka
---
Changes in v2:
- more verbose commit log
tools/binman/entry.py | 5 -
tools/binman/etype/fit.py | 2 +-
tools/binman/etype/section.py | 4 ++--
tools/binman/image.py | 7 ---
4 files changed, 11 insertions(+), 7 deletions(-)
Did you miss my other comments and a test?
Sorry, I indeed the other comments on the code - after ignoring the one
about a test case. ENOTIME.
Jan
diff --git a/tools/binman/entry.py b/tools/binman/entry.py
index bac90bbbcd..fdb9746fda 100644
--- a/tools/binman/entry.py
+++ b/tools/binman/entry.py
@@ -75,7 +75,7 @@ class Entry(object):
available. This is mainly used for testing.
external: True if this entry contains an external binary blob
"""
-def __init__(self, section, etype, node, name_prefix=''):
+def __init__(self, section, etype, node, name_prefix='', generate=None):
# Put this here to allow entry-docs and help to work without libfdt
global state
from binman import state
@@ -105,6 +105,9 @@ class Entry(object):
self.external = False
self.allow_missing = False
self.allow_fake = False
+if generate == None:
+generate = section.generate if section else True
+self.generate = generate
@staticmethod
def FindEntryClass(etype, expanded):
diff --git a/tools/binman/etype/fit.py b/tools/binman/etype/fit.py
index b41187df80..4e4d2f9c22 100644
--- a/tools/binman/etype/fit.py
+++ b/tools/binman/etype/fit.py
@@ -193,7 +193,7 @@ class Entry_fit(Entry):
# the FIT (e.g. "/images/kernel/u-boot"), so don't call
# fsw.add_node() or _AddNode() for it.
pass
-elif subnode.name.startswith('@'):
+elif self.generate and subnode.name.startswith('@'):
if self._fdts:
# Generate notes for each FDT
for seq, fdt_fname in enumerate(self._fdts):
diff --git a/tools/binman/etype/section.py b/tools/binman/etype/section.py
index 7a55d03231..319156a09a 100644
--- a/tools/binman/etype/section.py
+++ b/tools/binman/etype/section.py
@@ -154,9 +154,9 @@ class Entry_section(Entry):
available. This is set by the `SetAllowMissing()` method, if
`--allow-missing` is passed to binman.
"""
-def __init__(self, section, etype, node, test=False):
+def __init__(self, section, etype, node, test=False, generate=None):
if not test:
-super().__init__(section, etype, node)
+super().__init__(section, etype, node, generate=generate)
self._entries = OrderedDict()
self._pad_byte = 0
self._sort = False
diff --git a/tools/binman/image.py b/tools/binman/image.py
index f0a7d65299..1ff97e687c 100644
--- a/tools/binman/image.py
+++ b/tools/binman/image.py
@@ -69,8 +69,9 @@ class Image(section.Entry_section):
version which does not support all the entry types.
"""
def __init__(self, name, node, copy_to_orig=True, test=False,
- ignore_missing=False, use_expanded=False,
missing_etype=False):
-super().__init__(None, 'section', node, test=test)
+ ignore_missing=False, use_expanded=False, missing_etype=False,
+ generate=True):
+super().__init__(None, 'section', node, test=test, generate=generate)
self.copy_to_orig = copy_to_orig
self.name = 'main-section'
self.image_name = name
@@ -130,7 +131,7 @@ class Image(section.Entry_section):
# Return an Image with the associated nodes
root = dtb.GetRoot()
image = Image('image', root, copy_to_orig=False, ignore_missing=True,
- missing_etype=True)
+ missing_etype=True, generate=False)
image.image_node = fdt_util.GetString(root, 'image-node', 'image')
image.fdtmap_dtb = dtb
--
2.31.1
Regards,
Simon
--
Siemens AG, Technology
Competence Center Embedded Linux
Re: [PATCH] doc: replace @return by Return:
Hi, I'm ambivalent about this patch. Pro: - we can make everything use the correct @return in one go - we have a lot of other churn so this is no different Con: it changes things that may not appear in the docs for a long time, if ever. It is less effective without a checkpatch rule The ordering of text within the comment is still not right in many cases Sphinx is very simplistic and it would be nice to make it smarter So I'd say if this can come with a checkpatch rule then I'm for it. Otherwise we might be better off to fix files manually (@return and ordering) as we add them to the docs. Regards, Simon
[PATCH v1] imx: imx8qm-rom7720: switch to binman
Switch to use binman to pack images
Signed-off-by: Oliver Graute
---
arch/arm/dts/imx8qm-rom7720-a1.dts| 1 +
arch/arm/dts/imx8qm-u-boot.dtsi | 133 ++
arch/arm/mach-imx/imx8/Kconfig| 1 +
.../advantech/imx8qm_rom7720_a1/imximage.cfg | 4 +-
configs/imx8qm_rom7720_a1_4G_defconfig| 2 +-
doc/board/advantech/imx8qm-rom7720-a1.rst | 3 +-
6 files changed, 139 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/dts/imx8qm-u-boot.dtsi
diff --git a/arch/arm/dts/imx8qm-rom7720-a1.dts
b/arch/arm/dts/imx8qm-rom7720-a1.dts
index d1f2fff869..332d441c6d 100644
--- a/arch/arm/dts/imx8qm-rom7720-a1.dts
+++ b/arch/arm/dts/imx8qm-rom7720-a1.dts
@@ -10,6 +10,7 @@
/memreserve/ 0x8000 0x0002;
#include "fsl-imx8qm.dtsi"
+#include "imx8qm-u-boot.dtsi"
/ {
model = "Advantech iMX8QM Qseven series";
diff --git a/arch/arm/dts/imx8qm-u-boot.dtsi b/arch/arm/dts/imx8qm-u-boot.dtsi
new file mode 100644
index 00..5da420ece6
--- /dev/null
+++ b/arch/arm/dts/imx8qm-u-boot.dtsi
@@ -0,0 +1,133 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 NXP
+ */
+
+/ {
+ binman: binman {
+ multiple-images;
+ };
+};
+
+&binman {
+ u-boot-spl-ddr {
+ align = <4>;
+ align-size = <4>;
+ filename = "u-boot-spl-ddr.bin";
+ pad-byte = <0xff>;
+
+ u-boot-spl {
+ align-end = <4>;
+ filename = "u-boot-spl.bin";
+ };
+ };
+
+ spl {
+ filename = "spl.bin";
+
+ mkimage {
+ args = "-n spl/u-boot-spl.cfgout -T imx8image -e
0x10";
+
+ blob {
+ filename = "u-boot-spl-ddr.bin";
+ };
+ };
+ };
+
+ itb {
+ filename = "u-boot.itb";
+
+ fit {
+ description = "Configuration to load ATF before U-Boot";
+ fit,external-offset = ;
+ fit,fdt-list = "of-list";
+ #address-cells = <1>;
+
+ images {
+ uboot {
+ arch = "arm64";
+ compression = "none";
+ description = "U-Boot (64-bit)";
+ load = ;
+ type = "standalone";
+
+ uboot_blob {
+ filename = "u-boot-nodtb.bin";
+ type = "blob-ext";
+ };
+ };
+
+ atf {
+ arch = "arm64";
+ compression = "none";
+ description = "ARM Trusted Firmware";
+ entry = <0x0091>;
+ load = <0x00091000>;
+ type = "firmware";
+
+ atf_blob {
+ filename = "bl31.bin";
+ type = "blob-ext";
+ };
+ };
+
+ scfw {
+ arch = "arm64";
+ compression = "none";
+ description = "System Controler
Firmware";
+ type = "firmware";
+
+ scfw_blob {
+ filename =
"mx8qm-val-scfw-tcm.bin";
+ type = "blob-ext";
+ };
+ };
+
+ seco {
+ arch = "arm64";
+ compression = "none";
+ description = "Seco Firmware";
+ type = "firmware";
+
+ seco_blob {
+ filename =
"mx8qm-ahab-container.img";
+ type = "blob-ext";
+ };
+ };
+
+ fdt {
+ filename = "imx8qm-rom7720-a1";
+ type = "flat_dt";
+ compression = "none";
+
+
Re: [PATCH v2] binman: Skip node generation for images read from files
Hi Jan,
On Mon, 17 Jan 2022 at 00:28, Jan Kiszka wrote:
>
> From: Jan Kiszka
>
> We can and should run the node generator only when creating a new image.
> When we read it back, there is no need to generate nodes - they already
> exits, and binman does not dive that deep into the image - and there is
> no way to provide the required fdt-list. So forward the mode from the
> image to every Entry object it contains so that Entry_fit can simply
> skip generator nodes when reading them from an fdtmap.
>
> This unbreaks all read-backs of images that contain generator nodes in
> their fdtmap.
>
> Signed-off-by: Jan Kiszka
> ---
>
> Changes in v2:
> - more verbose commit log
>
> tools/binman/entry.py | 5 -
> tools/binman/etype/fit.py | 2 +-
> tools/binman/etype/section.py | 4 ++--
> tools/binman/image.py | 7 ---
> 4 files changed, 11 insertions(+), 7 deletions(-)
Did you miss my other comments and a test?
>
> diff --git a/tools/binman/entry.py b/tools/binman/entry.py
> index bac90bbbcd..fdb9746fda 100644
> --- a/tools/binman/entry.py
> +++ b/tools/binman/entry.py
> @@ -75,7 +75,7 @@ class Entry(object):
> available. This is mainly used for testing.
> external: True if this entry contains an external binary blob
> """
> -def __init__(self, section, etype, node, name_prefix=''):
> +def __init__(self, section, etype, node, name_prefix='', generate=None):
> # Put this here to allow entry-docs and help to work without libfdt
> global state
> from binman import state
> @@ -105,6 +105,9 @@ class Entry(object):
> self.external = False
> self.allow_missing = False
> self.allow_fake = False
> +if generate == None:
> +generate = section.generate if section else True
> +self.generate = generate
>
> @staticmethod
> def FindEntryClass(etype, expanded):
> diff --git a/tools/binman/etype/fit.py b/tools/binman/etype/fit.py
> index b41187df80..4e4d2f9c22 100644
> --- a/tools/binman/etype/fit.py
> +++ b/tools/binman/etype/fit.py
> @@ -193,7 +193,7 @@ class Entry_fit(Entry):
> # the FIT (e.g. "/images/kernel/u-boot"), so don't call
> # fsw.add_node() or _AddNode() for it.
> pass
> -elif subnode.name.startswith('@'):
> +elif self.generate and subnode.name.startswith('@'):
> if self._fdts:
> # Generate notes for each FDT
> for seq, fdt_fname in enumerate(self._fdts):
> diff --git a/tools/binman/etype/section.py b/tools/binman/etype/section.py
> index 7a55d03231..319156a09a 100644
> --- a/tools/binman/etype/section.py
> +++ b/tools/binman/etype/section.py
> @@ -154,9 +154,9 @@ class Entry_section(Entry):
> available. This is set by the `SetAllowMissing()` method, if
> `--allow-missing` is passed to binman.
> """
> -def __init__(self, section, etype, node, test=False):
> +def __init__(self, section, etype, node, test=False, generate=None):
> if not test:
> -super().__init__(section, etype, node)
> +super().__init__(section, etype, node, generate=generate)
> self._entries = OrderedDict()
> self._pad_byte = 0
> self._sort = False
> diff --git a/tools/binman/image.py b/tools/binman/image.py
> index f0a7d65299..1ff97e687c 100644
> --- a/tools/binman/image.py
> +++ b/tools/binman/image.py
> @@ -69,8 +69,9 @@ class Image(section.Entry_section):
> version which does not support all the entry types.
> """
> def __init__(self, name, node, copy_to_orig=True, test=False,
> - ignore_missing=False, use_expanded=False,
> missing_etype=False):
> -super().__init__(None, 'section', node, test=test)
> + ignore_missing=False, use_expanded=False,
> missing_etype=False,
> + generate=True):
> +super().__init__(None, 'section', node, test=test, generate=generate)
> self.copy_to_orig = copy_to_orig
> self.name = 'main-section'
> self.image_name = name
> @@ -130,7 +131,7 @@ class Image(section.Entry_section):
> # Return an Image with the associated nodes
> root = dtb.GetRoot()
> image = Image('image', root, copy_to_orig=False,
> ignore_missing=True,
> - missing_etype=True)
> + missing_etype=True, generate=False)
>
> image.image_node = fdt_util.GetString(root, 'image-node', 'image')
> image.fdtmap_dtb = dtb
> --
> 2.31.1
Regards,
Simon
Re: [PATCH 2/4] pci: Extend 'pci regions' command with bus number
On 1/25/22 17:50, Pali Rohár wrote:
On Tuesday 25 January 2022 16:53:05 Stefan Roese wrote:
On 1/17/22 16:38, Pali Rohár wrote:
'pci regions' currently prints only region information from bus 0 which
belongs to controller 0. Parser for 'pci regions' cmdline currently ignores
any additional arguments and so U-Boot always uses bus 0.
Regions are stored in controller (not on the bus) and therefore to retrieve
controller from the bus, it is needed to call pci_get_controller() which
returns root bus. Because bus 0 is root bus, current code worked fine for
controller 0.
Extend cmdline parser for 'pci regions' to allows specifying bus number,
extend pci_show_regions() code to accept also non-zero bus number and
print bus ranges for which is regions configuration assigned.
Signed-off-by: Pali Rohár
Nitpicking comment below. But still:
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
cmd/pci.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/cmd/pci.c b/cmd/pci.c
index 3b1863f139c9..53edf0d90010 100644
--- a/cmd/pci.c
+++ b/cmd/pci.c
@@ -443,7 +443,7 @@ static const struct pci_flag_info {
static void pci_show_regions(struct udevice *bus)
{
- struct pci_controller *hose = dev_get_uclass_priv(bus);
+ struct pci_controller *hose =
dev_get_uclass_priv(pci_get_controller(bus));
const struct pci_region *reg;
int i, j;
@@ -452,6 +452,7 @@ static void pci_show_regions(struct udevice *bus)
return;
}
+ printf("Buses %02x-%02x\n", hose->first_busno, hose->last_busno);
printf("# %-18s %-18s %-18s %s\n", "Bus start", "Phys start", "Size",
"Flags");
for (i = 0, reg = hose->regions; i < hose->region_count; i++, reg++) {
@@ -520,8 +521,9 @@ static int do_pci(struct cmd_tbl *cmdtp, int flag, int
argc, char *const argv[])
value = 0;
argc--;
}
- if (argc > 1)
- busnum = hextoul(argv[1], NULL);
+ if (argc > 2 || (argc > 1 && cmd != 'r' && argv[1][0]
!= 's')) {
+ busnum = hextoul(argv[argc - 1], NULL);
+ }
Nitpicking:
Single line statements without parentheses is preferred.
In next patches I'm adding more statements into this branch and I did
not wanted to make next patches too noisy.
Thanks for the explanation. Fine with me. RB tag is already sent.
Thanks,
Stefan
Re: [PATCH u-boot-marvell 14/14] tools: kwboot: Set debug flag to 1
On 1/25/22 18:13, Marek Behún wrote: From: Pali Rohár This should enable BootROM output on UART. (At least on A385 BootROM this is broken, BootROM ignores this debug flag and does not enable its output on UART if some valid image is available in SPI-NOR.) Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Reviewed-by: Stefan Roese Thanks, Stefan --- tools/kwboot.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/kwboot.c b/tools/kwboot.c index 859559fb72..2684f0e75a 100644 --- a/tools/kwboot.c +++ b/tools/kwboot.c @@ -1631,6 +1631,7 @@ kwboot_img_patch(void *img, size_t *size, int baudrate) * baudrate (which should be 115200) and do not touch * UART MPP configuration. */ + hdr->flags |= 0x1; hdr->options &= ~0x1F; hdr->options |= MAIN_HDR_V1_OPT_BAUD_DEFAULT; hdr->options |= 0 << 3; Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH u-boot-marvell 11/14] tools: kwboot: Handle EINTR in kwboot_write()
On 1/25/22 18:13, Marek Behún wrote:
From: Pali Rohár
The write() syscall may be interrupted. Handle EINTR and retry it.
Signed-off-by: Pali Rohár
Signed-off-by: Marek Behún
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
tools/kwboot.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index de433c1b04..8b748f0fdd 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -292,13 +292,15 @@ static int blk_rsp_timeo = KWBOOT_BLK_RSP_TIMEO;
static ssize_t
kwboot_write(int fd, const char *buf, size_t len)
{
- size_t tot = 0;
+ ssize_t tot = 0;
while (tot < len) {
ssize_t wr = write(fd, buf + tot, len - tot);
- if (wr < 0)
- return -1;
+ if (wr < 0 && errno == EINTR)
+ continue;
+ else if (wr < 0)
+ return wr;
tot += wr;
}
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH u-boot-marvell 10/14] tools: kwboot: Remove 2s delay before sending first xmodem packet
On 1/25/22 18:13, Marek Behún wrote:
From: Pali Rohár
This delay is not needed anymore since kwboot already handles retrying
logic for incomplete xmodem packets and also forces BootROM to flush its
input queue. Removing it decreases total transfer time.
Signed-off-by: Pali Rohár
Signed-off-by: Marek Behún
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
tools/kwboot.c | 4
1 file changed, 4 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 824ae005b2..de433c1b04 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1142,10 +1142,6 @@ kwboot_xmodem(int tty, const void *_img, size_t size,
int baudrate)
*/
hdrsz += (KWBOOT_XM_BLKSZ - hdrsz % KWBOOT_XM_BLKSZ) % KWBOOT_XM_BLKSZ;
- kwboot_printv("Waiting %d ms and flushing tty\n", blk_rsp_timeo);
- usleep(blk_rsp_timeo * 1000);
- tcflush(tty, TCIOFLUSH);
-
pnum = 1;
rc = kwboot_xmodem_one(tty, &pnum, 1, img, hdrsz, baudrate);
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH u-boot-marvell 13/14] tools: kwboot: Fix usage of -D without -t
On 1/25/22 18:13, Marek Behún wrote: From: Pali Rohár When -D is specified then both bootmsg and debugmsg are not set, but imgpath is set. Fix this check for valid and required parameters. Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Reviewed-by: Stefan Roese Thanks, Stefan --- tools/kwboot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/kwboot.c b/tools/kwboot.c index fca1c73c55..859559fb72 100644 --- a/tools/kwboot.c +++ b/tools/kwboot.c @@ -1819,7 +1819,7 @@ main(int argc, char **argv) } } while (1); - if (!bootmsg && !term && !debugmsg) + if (!bootmsg && !term && !debugmsg && !imgpath) goto usage; ttypath = argv[optind++]; Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2 07/38] patman: Tidy up the download function a little
Reverse the order of the return tuple, so that the filename is first. This seems more obvious than putting the temporary directory first. Correct a bug that leaves a space on the final line. Allow the caller to control the name of the temporary directory. Signed-off-by: Simon Glass --- (no changes since v1) tools/buildman/toolchain.py | 2 +- tools/patman/tools.py | 16 ++-- 2 files changed, 11 insertions(+), 7 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH u-boot-marvell 12/14] tools: kwboot: Handle EINTR in kwboot_tty_recv()
On 1/25/22 18:13, Marek Behún wrote:
From: Pali Rohár
The select() and read() syscalls may be interrupted. Handle EINTR and
retry them.
Signed-off-by: Pali Rohár
Signed-off-by: Marek Behún
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
tools/kwboot.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 8b748f0fdd..fca1c73c55 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -409,15 +409,19 @@ kwboot_tty_recv(int fd, void *buf, size_t len, int timeo)
do {
nfds = select(fd + 1, &rfds, NULL, NULL, &tv);
- if (nfds < 0)
+ if (nfds < 0 && errno == EINTR)
+ continue;
+ else if (nfds < 0)
goto out;
- if (!nfds) {
+ else if (!nfds) {
errno = ETIMEDOUT;
goto out;
}
n = read(fd, buf, len);
- if (n <= 0)
+ if (n < 0 && errno == EINTR)
+ continue;
+ else if (n <= 0)
goto out;
buf = (char *)buf + n;
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH u-boot-marvell 09/14] tools: kwboot: Force BootROM to flush input queue after boot pattern
On 1/25/22 18:13, Marek Behún wrote:
From: Pali Rohár
Force the BootROM to flush its input queue after sending boot pattern.
This ensures that after function kwboot_bootmsg() finishes, BootROM is
able to start receiving xmodem packets without any specific delay or
setup.
Signed-off-by: Pali Rohár
Signed-off-by: Marek Behún
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
tools/kwboot.c | 36 +++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index c413a8bf51..824ae005b2 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -717,6 +717,7 @@ out:
static int
kwboot_bootmsg(int tty, void *msg)
{
+ struct kwboot_block block;
int rc;
char c;
int count;
@@ -747,7 +748,40 @@ kwboot_bootmsg(int tty, void *msg)
kwboot_printv("\n");
- return rc;
+ if (rc)
+ return rc;
+
+ /*
+* At this stage we have sent more boot message patterns and BootROM
+* (at least on Armada XP and 385) started interpreting sent bytes as
+* part of xmodem packets. If BootROM is expecting SOH byte as start of
+* a xmodem packet and it receives byte 0xff, then it throws it away and
+* sends a NAK reply to host. If BootROM does not receive any byte for
+* 2s when expecting some continuation of the xmodem packet, it throws
+* away the partially received xmodem data and sends NAK reply to host.
+*
+* Therefore for starting xmodem transfer we have two options: Either
+* wait 2s or send 132 0xff bytes (which is the size of xmodem packet)
+* to ensure that BootROM throws away any partially received data.
+*/
+
+ /* flush output queue with remaining boot message patterns */
+ tcflush(tty, TCOFLUSH);
+
+ /* send one xmodem packet with 0xff bytes to force BootROM to re-sync */
+ memset(&block, 0xff, sizeof(block));
+ kwboot_tty_send(tty, &block, sizeof(block), 0);
+
+ /*
+* Sending 132 bytes via 115200B/8-N-1 takes 11.45 ms, reading 132 bytes
+* takes 11.45 ms, so waiting for 30 ms should be enough.
+*/
+ usleep(30 * 1000);
+
+ /* flush remaining NAK replies from input queue */
+ tcflush(tty, TCIFLUSH);
+
+ return 0;
}
static int
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH u-boot-marvell 08/14] tools: kwboot: Allow to use option -b without image path
On 1/25/22 18:13, Marek Behún wrote:
From: Pali Rohár
Allow option -b without image path parameter, to send boot pattern and
wait for response but not send any image. This allows to use kwboot just
for processing boot pattern and user can use any other xmodem tool for
transferring the image itself (e.g. sx). Useful for debugging purposes.
Signed-off-by: Pali Rohár
Signed-off-by: Marek Behún
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
tools/kwboot.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 1dcec1969a..c413a8bf51 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1699,6 +1699,8 @@ main(int argc, char **argv)
size_t size;
size_t after_img_rsv;
int baudrate;
+ int prev_optind;
+ int c;
rv = 1;
tty = -1;
@@ -1716,22 +1718,32 @@ main(int argc, char **argv)
kwboot_verbose = isatty(STDOUT_FILENO);
do {
- int c = getopt(argc, argv, "hb:ptaB:dD:q:s:o:");
+ prev_optind = optind;
+ c = getopt(argc, argv, "hbptaB:dD:q:s:o:");
if (c < 0)
break;
switch (c) {
case 'b':
+ if (imgpath || bootmsg || debugmsg)
+ goto usage;
bootmsg = kwboot_msg_boot;
- imgpath = optarg;
+ if (prev_optind == optind)
+ goto usage;
+ if (argv[optind] && argv[optind][0] != '-')
+ imgpath = argv[optind++];
break;
case 'D':
+ if (imgpath || bootmsg || debugmsg)
+ goto usage;
bootmsg = NULL;
imgpath = optarg;
break;
case 'd':
+ if (imgpath || bootmsg || debugmsg)
+ goto usage;
debugmsg = kwboot_msg_debug;
break;
@@ -1774,11 +1786,11 @@ main(int argc, char **argv)
if (!bootmsg && !term && !debugmsg)
goto usage;
- if (argc - optind < 1)
- goto usage;
-
ttypath = argv[optind++];
+ if (optind != argc)
+ goto usage;
+
tty = kwboot_open_tty(ttypath, imgpath ? 115200 : baudrate);
if (tty < 0) {
perror(ttypath);
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH u-boot-marvell 07/14] tools: kwboot: Show 'E' in progress output when error occurs
On 1/25/22 18:13, Marek Behún wrote:
From: Pali Rohár
When kwboot is unable to resend current xmodem packet, show an 'E' in the
progress output instead of a '+'. This allows to distinguish between the
state when kwboot is retrying sending the packet and when retry is not
possible.
Signed-off-by: Pali Rohár
Signed-off-by: Marek Behún
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
tools/kwboot.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index dfac8aed7b..1dcec1969a 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -975,8 +975,12 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block,
int allow_non_xm,
if (rc)
goto err;
- if (!allow_non_xm && c != ACK)
- kwboot_progress(-1, '+');
+ if (!allow_non_xm && c != ACK) {
+ if (c == NAK && allow_retries && retries + 1 < 16)
+ kwboot_progress(-1, '+');
+ else
+ kwboot_progress(-1, 'E');
+ }
} while (c == NAK && allow_retries && retries++ < 16);
if (non_xm_print)
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH u-boot-marvell 06/14] tools: kwboot: Fix handling of repeated xmodem packets
On 1/25/22 18:13, Marek Behún wrote:
From: Pali Rohár
Unfortunately during some stages of xmodem transfer, A385 BootROM is not
able to handle repeated xmodem packets. So if an error occurs during that
stage, stop the transfer and return failure.
Signed-off-by: Pali Rohár
Signed-off-by: Marek Behún
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
tools/kwboot.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index a619a6c3c1..dfac8aed7b 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -946,7 +946,7 @@ kwboot_xm_recv_reply(int fd, char *c, int stop_on_non_xm,
static int
kwboot_xm_sendblock(int fd, struct kwboot_block *block, int allow_non_xm,
- int *done_print, int baudrate)
+ int *done_print, int baudrate, int allow_retries)
{
int non_xm_print, baud_changed;
int rc, err, retries;
@@ -977,7 +977,7 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block, int
allow_non_xm,
if (!allow_non_xm && c != ACK)
kwboot_progress(-1, '+');
- } while (c == NAK && retries++ < 16);
+ } while (c == NAK && allow_retries && retries++ < 16);
if (non_xm_print)
kwboot_printv("\n");
@@ -1044,8 +1044,30 @@ kwboot_xmodem_one(int tty, int *pnum, int header, const
uint8_t *data,
last_block = (left <= blksz);
+ /*
+* Handling of repeated xmodem packets is completely broken in
+* Armada 385 BootROM - it completely ignores xmodem packet
+* numbers, they are only used for checksum verification.
+* BootROM can handle a retry of the xmodem packet only during
+* the transmission of kwbimage header and only if BootROM
+* itself sent NAK response to previous attempt (it does it on
+* checksum failure). During the transmission of kwbimage data
+* part, BootROM always expects next xmodem packet, even if it
+* sent NAK to previous attempt - there is absolutely no way to
+* repair incorrectly transmitted xmodem packet during kwbimage
+* data part upload. Also, if kwboot receives non-ACK/NAK
+* response (meaning that original BootROM response was damaged
+* on UART) there is no way to detect if BootROM accepted xmodem
+* packet or not and no way to check if kwboot could repeat the
+* packet or not.
+*
+* Stop transfer and return failure if kwboot receives unknown
+* reply if non-xmodem reply is not allowed (for all xmodem
+* packets except the last header packet) or when non-ACK reply
+* is received during data part transfer.
+*/
rc = kwboot_xm_sendblock(tty, &block, header && last_block,
-&done_print, baudrate);
+&done_print, baudrate, header);
if (rc)
goto out;
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH u-boot-marvell 05/14] tools: kwboot: Do not change received character in kwboot_xm_recv_reply()
On 1/25/22 18:13, Marek Behún wrote:
From: Pali Rohár
Marvell BootROM expects retransmission of previous xmodem packet only in
the case when it sends NAK response to the host.
Do not change non-xmodem response (possibly UART transfer error) to NAK
in kwboot_xm_recv_reply() function. Allow caller to receive original
response from device.
Change argument 'nak_on_non_xm' to 'stop_on_non_xm'. Instead of changing
non-xmodem character to NAK, stop processing on invalid character and
return it.
Signed-off-by: Pali Rohár
Signed-off-by: Marek Behún
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
tools/kwboot.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 0b97990d09..a619a6c3c1 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -875,7 +875,7 @@ kwboot_baud_magic_handle(int fd, char c, int baudrate)
}
static int
-kwboot_xm_recv_reply(int fd, char *c, int nak_on_non_xm,
+kwboot_xm_recv_reply(int fd, char *c, int stop_on_non_xm,
int ignore_nak_reply,
int allow_non_xm, int *non_xm_print,
int baudrate, int *baud_changed)
@@ -931,10 +931,8 @@ kwboot_xm_recv_reply(int fd, char *c, int nak_on_non_xm,
*non_xm_print = 1;
}
} else {
- if (nak_on_non_xm) {
- *c = NAK;
+ if (stop_on_non_xm)
break;
- }
timeout = recv_until - _now();
if (timeout < 0) {
errno = ETIMEDOUT;
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2 17/38] binman: Add a bintool implementation for cbfstool
Add a Bintool for this, which is used to run CBFS tests. It supports the features needed by the tests as well as fetching a binary from Google Drive. Building it from source is very slow since it is not separately supported by the coreboot build system and it builds an entire gcc toolchain before starting. Signed-off-by: Simon Glass --- (no changes since v1) tools/binman/btool/cbfstool.py | 219 + 1 file changed, 219 insertions(+) create mode 100644 tools/binman/btool/cbfstool.py Applied to u-boot-dm, thanks!
Re: [PATCH v2 29/38] binman: Tidy up pylint warnings in comp_util
Tweak some naming and comments to resolve these. Use WriteFile() to write the file. Signed-off-by: Simon Glass --- (no changes since v1) tools/binman/cbfs_util.py | 8 tools/binman/comp_util.py | 19 +-- tools/binman/entry.py | 2 +- tools/binman/etype/section.py | 2 +- tools/binman/ftest.py | 8 5 files changed, 19 insertions(+), 20 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH] introduce CONFIG_DEVICE_TREE_INCLUDES
On 25/01/2022 00.50, Simon Glass wrote: > Hi Rasmus, > > On Mon, 24 Jan 2022 at 15:15, Rasmus Villemoes > wrote: >> >> On 24/01/2022 18.57, Simon Glass wrote: >> And the thing about "adding the signature" - yes, indeed, _signing_ can and should be done after building. But that is not at all what this started with, this is about embedding the metadata that U-Boot (or SPL) will need for _verifying_ during the build itself - when the private key may not even be available. Again, I think that it's a fundamental design bug that generating and adding that metadata in the form needed by U-Boot can only be done as a side effect of signing some unrelated image. >>> >>> It is a side effect of signing *the same* image, i.e. the image that >>> holds the signature and the public key. There is only one image, the >>> firmware image produced by binman. >> >> Huh? Are we talking about the same thing? What you write makes no sense >> at all. > > Perhaps it is a terminology thing. For me: > > image: the final firmware image with everything in it > binary: a component of the image > > So there is only one image. It still makes no sense. I'm talking about the -K option to mkimage, which modifies the .dtb-which-is-to-be-used-by-U-Boot while building a FIT image containing kernel, initramfs and whatnot. That's certainly two very different images (or, in your terminology, one image and an entirely distinct binary destined to be included in another image). Or for that matter, if one wants to do the same dance during SPL -> U-Boot, this could be the FIT image containing U-Boot proper and its control dtb (which must, of course, already have had the public-key-for-verifying-the-kernel embedded) vs the SPL's control .dtb, again two entirely different beasts. The point is, I should not _need_ to sign anything in order to get the public key info into the control .dtbs. That's why I call it a design bug. I have explained all of this several times, including in the commit message. And the more you push for everyone to be using binman to generate the final images, the more important it is that the U-Boot .dtb contains the public-key-info before it gets used to build the final U-Boot image (whether that's itself a FIT or just a concatenation of u-boot.bin and u-boot.dtb). If I was assembling the final U-Boot image myself, I would just need the u-boot recipe to produce u-boot.bin and u-boot.dtb, and then I could have a separate step that updated u-boot.dtb. But when binman is in charge of doing that assembly, there's no such place to hook in, so I just want a way to ensure that the u-boot.dtb that gets generated is already the final one - which is what this patch is supposed to help with. Rasmus Applied to u-boot-dm, thanks!
Re: [PATCH] usb: Use the first available device for ehci_gadget
On Fri, 5 Nov 2021 at 10:53, Sean Anderson wrote: > > For whatever reason, usb_setup_ehci_gadget removes and probes USB device > 0. However, not all systems have a device 0. Use the first device > instead. > > The device probed should probably have something to do with the > controller (as specified by e.g. ums or fastboot > ). In fact, I find it odd that we probe the USB device in > the first place, because this is just to set up the gadget itself. > Presumably, the controller should be probed by usb_gadget_initialize > somehow. > > Signed-off-by: Sean Anderson > --- > > drivers/usb/host/usb-uclass.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass Applied to u-boot-dm, thanks!
Re: [PATCH v2] dm: Fix OF_BAD_ADDR definition
On Tue, 4 Jan 2022 at 00:42, Patrice Chotard wrote: > > When OF_LIVE flag is enabled on a 64 bits platform, there is an > issue when dev_read_addr() is called and need to perform an address > translation using __of_translate_address(). > > In case of error, __of_translate_address() return's value is OF_BAD_ADDR > (wich is defined in include/dm/of.h to ((u64)-1) = 0x). > The return value of dev_read_addr() is often compared to FDT_ADDR_T_NONE > which is defined as (-1U) = 0x. > In this case the comparison is always false. > > To fix this issue, define FDT_ADDR_T_NONE to (ulong)(-1) in case of > AARCH64. Update accordingly related tests. > > Signed-off-by: Patrice Chotard > > --- > > Changes in v2: > - define FDT_ADDR_T_NONE as ((ulong)(-1)) and keep OF_BAD_ADDR unchanged > > include/fdtdec.h | 5 - > test/dm/ofnode.c | 2 +- > test/dm/pci.c | 4 ++-- > test/dm/test-fdt.c | 2 +- > 4 files changed, 8 insertions(+), 5 deletions(-) Reviewed-by: Simon Glass Applied to u-boot-dm, thanks!
Re: [PATCH v2 02/38] binman: Tweak elf tests for a toolchain change
Some newer toolchains do not create a symbol for the .ucode section that this test relies on. Update the test to use the symbol that is explicitly created, instead. Signed-off-by: Simon Glass --- (no changes since v1) tools/binman/elf_test.py | 8 1 file changed, 4 insertions(+), 4 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH] binman: Document the __bss_size symbol error
Add a note about the message so it is clear why it occurs. Signed-off-by: Simon Glass --- tools/binman/binman.rst | 29 + 1 file changed, 29 insertions(+) Applied to u-boot-dm, thanks!
Re: [PATCH v2 01/38] Makefile: Fake external blobs by default with binman
This behaviour is necessary with boards where the binman description requires processing external blobs, since these may be missing. Enable it by default, so that CI is happy. Warnings indicate that a valid image is not produced, as with the --allow-missing option. Signed-off-by: Simon Glass --- (no changes since v1) Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Applied to u-boot-dm, thanks!
Re: [PATCH v2 03/38] mkimage: Show the external-offset error
This is a debug message at present, which is not very helpful. Print out the error so that action can be taken. Signed-off-by: Simon Glass --- (no changes since v1) tools/fit_image.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH v2 04/38] binman: Expand the external FIT test a little
At present this does not check that the external data is in the expected place. Use a non-zero offset for the external data and check it. Signed-off-by: Simon Glass --- (no changes since v1) tools/binman/ftest.py | 17 + tools/binman/test/162_fit_external.dts | 2 +- 2 files changed, 18 insertions(+), 1 deletion(-) Applied to u-boot-dm, thanks!
Re: [PATCH v2 05/38] patman: Allow running a tool and returning the full result
Add a new function which returns the entire result from running a tool, not just stdout. Update Run() to use this and to return stdout on error, if stderr is empty, since some unfortunate tools write their error output to stdout rather than stderr. Move building of the PATH to a separate function. Make the exception catching more specific, to catch just ValueError, since broad exceptions are a pain to debug. Signed-off-by: Simon Glass --- (no changes since v1) tools/patman/tools.py | 56 +++ 1 file changed, 46 insertions(+), 10 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH v2 06/38] buildman: Move the download function to tools
This function is handy for binman as well. Move it into the shared 'tools' module. Signed-off-by: Simon Glass --- (no changes since v1) tools/buildman/toolchain.py | 46 + tools/patman/tools.py | 45 2 files changed, 46 insertions(+), 45 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH v2 08/38] patman: Add a function to find a tool on the path
The Run() function automatically uses the PATH variable to locate a tool when running it. Add a function that does this manually, so we don't have to run a tool to find out if it is present. This is needed by the new Bintool class, which wants to check which tools are present. Signed-off-by: Simon Glass --- (no changes since v1) tools/patman/tools.py | 23 +++ 1 file changed, 23 insertions(+) Applied to u-boot-dm, thanks!
Re: [PATCH v2 10/38] binman: Drop the image name from the fake-blob message
This is not really needed and it makes the message different from the missing-blob message. Update it. Signed-off-by: Simon Glass --- (no changes since v1) tools/binman/control.py | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH v2 11/38] binman: Allow faked blobs in blob-ext-list
Since this is a list of blobs, each blob should have the ability to be faked, as with blob-ext. Update the Entry base class to set allow_fake and use the base class in the section code also, so that this propagagtes to blob-ext-list, which is not a section. Signed-off-by: Simon Glass --- (no changes since v1) tools/binman/entry.py| 2 +- tools/binman/etype/blob_ext_list.py | 1 + tools/binman/etype/section.py| 1 + tools/binman/ftest.py| 8 tools/binman/test/218_blob_ext_list_fake.dts | 14 ++ 5 files changed, 25 insertions(+), 1 deletion(-) create mode 100644 tools/binman/test/218_blob_ext_list_fake.dts Applied to u-boot-dm, thanks!
Re: [PATCH v2 12/38] binman: Correct path for fip_util
This should be imported from the binman module. Fix it. Signed-off-by: Simon Glass --- (no changes since v1) tools/binman/fip_util_test.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Applied to u-boot-dm, thanks!
Re: [PATCH v2 13/38] binman: Add installation instructions
Explain how to install binman, since it is not obvious. Signed-off-by: Simon Glass --- (no changes since v1) tools/binman/binman.rst | 27 +-- 1 file changed, 25 insertions(+), 2 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH v2 14/38] binman: Add support for bintools
Binman requires various tools to actually work, such as 'lz4' to compress data and 'futility' to sign Chrome OS firmware. At present these are handled in an ad-hoc manner and there is no easy way to find out what tools are needd to build an image, nor where to obtain them. Add an implementation of 'bintool', a base class which implements this functionality. When a bintool is required, it can be requested from this module, then executed. When the tool is missing, it can provide a way to obtain it. Note that this uses Command directly, not the tools.Run() function. This allows proper handling of missing tools and avoids needing to catch and re-raise exceptions. Signed-off-by: Simon Glass --- (no changes since v1) tools/binman/bintool.py | 421 1 file changed, 421 insertions(+) create mode 100644 tools/binman/bintool.py Applied to u-boot-dm, thanks!
Re: [PATCH v2 15/38] binman: Plumb in support for bintools
Support collecting the available bintools needed by an image, by scanning the entries in the image. Also add a command-line interface to access the basic bintool features, such as listing the bintools and fetching them if needed. Signed-off-by: Simon Glass --- (no changes since v1) tools/binman/cmdline.py | 7 +++ tools/binman/control.py | 17 - tools/binman/entry.py | 22 ++ tools/binman/etype/section.py | 4 tools/binman/ftest.py | 1 + tools/binman/image.py | 14 ++ 6 files changed, 64 insertions(+), 1 deletion(-) Applied to u-boot-dm, thanks!
Re: [PATCH v2 16/38] binman: Add tests for bintool
Add tests to cover the bintool functionality. Signed-off-by: Simon Glass --- (no changes since v1) tools/binman/bintool_test.py | 353 + tools/binman/btool/_testing.py | 36 2 files changed, 389 insertions(+) create mode 100644 tools/binman/bintool_test.py create mode 100644 tools/binman/btool/_testing.py Applied to u-boot-dm, thanks!
Re: [PATCH v2 18/38] binman: Add a bintool implementation for fiptool
Add a Bintool for this, which is used to run FIP tests. It supports the features needed by the tests as well as building a binary from the git tree. Signed-off-by: Simon Glass --- (no changes since v1) tools/binman/btool/fiptool.py | 123 ++ 1 file changed, 123 insertions(+) create mode 100644 tools/binman/btool/fiptool.py Applied to u-boot-dm, thanks!
Re: [PATCH v2 19/38] binman: Add a bintool implementation for futility
Add a Bintool for this, which is used to sign Chrome OS images and build the Google Binary Block (GBB). It supports the features needed by binman as well as fetching a binary from Google Drive. Building it from source is possible but is left for another time, as it requires at least one other library. Signed-off-by: Simon Glass --- (no changes since v1) tools/binman/btool/futility.py | 178 + 1 file changed, 178 insertions(+) create mode 100644 tools/binman/btool/futility.py Applied to u-boot-dm, thanks!
Re: [PATCH v2 20/38] binman: Add a bintool implementation for ifwitool
Add a Bintool for this, which is used to build Intel IFWI images. It supports the features needed by the tests as well as downloading a binary from Google Drive. Although this is built in the U-Boot tree, it is not currently included with u-boot-tools, so it may be useful to install a binary on the system. Signed-off-by: Simon Glass --- (no changes since v1) tools/binman/btool/ifwitool.py | 166 + 1 file changed, 166 insertions(+) create mode 100644 tools/binman/btool/ifwitool.py Applied to u-boot-dm, thanks!
Re: [PATCH v2 21/38] binman: Add a bintool implementation for mkimage
Add a Bintool for this, which is used to build images for use by U-Boot. It supports the features needed by binman as well as installing via the u-boot-tools packages. Although this is built in the U-Boot tree, it is still useful to install a binary on the system. Signed-off-by: Simon Glass --- (no changes since v1) tools/binman/btool/mkimage.py | 80 +++ 1 file changed, 80 insertions(+) create mode 100644 tools/binman/btool/mkimage.py Applied to u-boot-dm, thanks!
Re: [PATCH v2 22/38] binman: Enable bintool tests including cmdline processing
The tests rely on having at least 5 bintool implementions. Now that we have this, enable them. Add tests for the binman 'tool' subcommand. Signed-off-by: Simon Glass --- (no changes since v1) tools/binman/ftest.py | 32 tools/binman/main.py | 7 --- 2 files changed, 36 insertions(+), 3 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH v2 24/38] binman: Convert to using the FIP bintool
Update the FIP tests to use this bintool, instead of running fiptool directly. This simplifies the code and provides more consistency as well as supporting missing bintools. Signed-off-by: Simon Glass --- (no changes since v1) tools/binman/fip_util.py | 26 -- tools/binman/fip_util_test.py | 23 --- 2 files changed, 8 insertions(+), 41 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH v2 23/38] binman: Convert to using the CBFS bintool
Update the CBFS tests to use this bintool, instead of running cbfstool directly. This simplifies the overall code and provides more consistency, as well as supporting missing bintools. Signed-off-by: Simon Glass --- (no changes since v1) tools/binman/cbfs_util.py | 24 tools/binman/cbfs_util_test.py | 51 +- 2 files changed, 19 insertions(+), 56 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH v2 25/38] binman: Convert to using the futility bintool
Update the GBB and vblock entry types to use this bintool, instead of running futility directly. This simplifies the code and provides more consistency as well as supporting missing bintools. Signed-off-by: Simon Glass --- (no changes since v1) tools/binman/etype/gbb.py| 37 +--- tools/binman/etype/vblock.py | 32 ++- 2 files changed, 41 insertions(+), 28 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH v2 33/38] binman: Convert to using the lzma_alone bintool
Update the code to use this bintool, instead of running lzma_alone directly. This simplifies the code and provides more consistency. Signed-off-by: Simon Glass --- (no changes since v1) tools/binman/comp_util.py | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH v2 34/38] binman: Plumb in support for missing bintools
Bintools can be missing, in which case binman continues operation but reports an invalid image. Plumb in support for this and add tests for entry types which use bintools. Signed-off-by: Simon Glass --- (no changes since v1) tools/binman/cmdline.py | 2 ++ tools/binman/control.py | 12 ++- tools/binman/entry.py | 20 tools/binman/etype/section.py | 11 +++ tools/binman/ftest.py | 60 ++- 5 files changed, 103 insertions(+), 2 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH v2 26/38] binman: Convert to using the ifwitool bintool
Update the ifwi entry type to use this bintool, instead of running ifwitool directly. This simplifies the code and provides more consistency as well as supporting missing bintools. Signed-off-by: Simon Glass --- (no changes since v1) tools/binman/etype/intel_ifwi.py | 25 +++-- tools/binman/ftest.py| 4 ++-- tools/patman/tools.py| 31 --- 3 files changed, 21 insertions(+), 39 deletions(-) Applied to u-boot-dm, thanks!
Re: [PATCH v2 28/38] binman: Move compression into binman
The compression functions are not actually used by patman, so we don't need then in the tools module. Also we want to change them to use bintools, which patman will not support. Move these into a new comp_util module, within binman. Signed-off-by: Simon Glass --- (no changes since v1) tools/binman/cbfs_util.py | 9 ++-- tools/binman/comp_util.py | 88 +++ tools/binman/entry.py | 3 +- tools/binman/etype/section.py | 3 +- tools/binman/ftest.py | 9 ++-- tools/patman/tools.py | 79 --- 6 files changed, 102 insertions(+), 89 deletions(-) create mode 100644 tools/binman/comp_util.py Applied to u-boot-dm, thanks!
Re: [PATCH v2 27/38] binman: Convert to using the mkimage bintool
Update the fit and mkimage entry types to use this bintool, instead of running mkimage directly. This simplifies the code and provides more consistency as well as supporting missing bintools. Signed-off-by: Simon Glass --- (no changes since v1) tools/binman/etype/fit.py | 20 tools/binman/etype/mkimage.py | 13 +++-- 2 files changed, 27 insertions(+), 6 deletions(-) Applied to u-boot-dm, thanks!
