Re: [PATCH 0/4] introduce EFI_RAM_DISK_PROTOCOL
On Fri, Jul 07, 2023 at 01:00:40PM +0900, Masahisa Kojima wrote: > This series introduces the EFI_RAM_DISK_PROTOCOL implementation. > The major purpose of this series is a preparation for EFI HTTP(S) boot. > > Now U-Boot can download the distro installer ISO image > via wget or tftpboot commands, but U-Boot can not mount > the downloaded ISO image. > By calling EFI_RAM_DISK_PROTOCOL->register API, user can > mount the ISO image and boot the distro installer. > > Note that the installation process may not proceed > after the distro installer calls ExitBootServices() > since there is no hand-off process for the block device of > memory mapped ISO image. > > The EFI_RAM_DISK_PROTOCOL was tested with the > debian network installer[1] on qemu_arm64 platform. > The example procedure is as follows. > => tftpboot 4100 mini.iso > => efidebug disk load 4100 $filesize Can a disk created here be used natively on U-Boot with commands like (fs)ls or (fs)load? If so, it would be nice to mention the fact. -Takahiro Akashi > After these commands, ISO image is mounted like: > > => efidebug dh > > 7eec5910 (efiblk#0) > /RamDisk(0x4100,4974afff,3d5abd30-4175-87ce-6d64-d2ade523c4bb,0x0) > Block IO > > 7eec6140 (efiblk#0:1) > > /RamDisk(0x4100,4974afff,3d5abd30-4175-87ce-6d64-d2ade523c4bb,0x0)/HD(1,0x01,0,0x0,0x33800) > Block IO > > 7eec62b0 (efiblk#0:2) > > /RamDisk(0x4100,4974afff,3d5abd30-4175-87ce-6d64-d2ade523c4bb,0x0)/HD(2,0x01,0,0x33800,0x1) > Block IO > System Partition > Simple File System > > => dm tree > > blk 0 [ + ] efi_blk `-- efiblk#0 > partition 0 [ + ] blk_partition |-- efiblk#0:1 > partition 1 [ + ] blk_partition `-- efiblk#0:2 > > Debian can be successfully installed with this RAM disk on QEMU. > > [TODO] > - udevices created in ./lib/efi_driver/efi_block_device.c::efi_bl_bind() > are not removed when the efi_handle is removed. > So after unload the RAM disk, udevices still exist. > I plan to add a udevice removal process in > ./lib/efi_driver/efi_uclass.c::efi_uc_stop(). > In addition, I also plan to add unbind() callback in struct efi_driver_ops. > > > [1] > https://deb.debian.org/debian/dists/bookworm/main/installer-arm64/current/images/netboot/mini.iso > > Masahisa Kojima (4): > efi_loader: add RAM disk device path > efi_loader: add EFI_RAM_DISK_PROTOCOL implementation > cmd: efidebug: add RAM disk mount command > efi_selftest: add EFI_RAM_DISK_PROTOCOL selftest > > cmd/efidebug.c | 117 ++ > include/efi_api.h| 32 ++ > include/efi_loader.h | 4 + > lib/efi_driver/efi_uclass.c | 7 +- > lib/efi_loader/Kconfig | 6 + > lib/efi_loader/Makefile | 1 + > lib/efi_loader/efi_device_path_to_text.c | 14 + > lib/efi_loader/efi_ram_disk.c| 334 +++ > lib/efi_loader/efi_setup.c | 6 + > lib/efi_selftest/Makefile| 1 + > lib/efi_selftest/efi_selftest_ram_disk.c | 511 +++ > lib/uuid.c | 4 + > 12 files changed, 1035 insertions(+), 2 deletions(-) > create mode 100644 lib/efi_loader/efi_ram_disk.c > create mode 100644 lib/efi_selftest/efi_selftest_ram_disk.c > > > base-commit: e2e2aea5733f0d23cd9593bbefe5c803c552dcb9 > -- > 2.34.1 >
[PATCH 4/4] efi_selftest: add EFI_RAM_DISK_PROTOCOL selftest
This adds the selftest for the EFI_RAM_DISK_PROTOCOL.
Signed-off-by: Masahisa Kojima
---
lib/efi_selftest/Makefile| 1 +
lib/efi_selftest/efi_selftest_ram_disk.c | 511 +++
2 files changed, 512 insertions(+)
create mode 100644 lib/efi_selftest/efi_selftest_ram_disk.c
diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile
index e4d75420bf..899f2278d5 100644
--- a/lib/efi_selftest/Makefile
+++ b/lib/efi_selftest/Makefile
@@ -70,6 +70,7 @@ endif
ifeq ($(CONFIG_BLK)$(CONFIG_DOS_PARTITION),yy)
obj-y += efi_selftest_block_device.o
+obj-$(CONFIG_EFI_RAM_DISK_PROTOCOL) += efi_selftest_ram_disk.o
endif
obj-$(CONFIG_EFI_ESRT) += efi_selftest_esrt.o
diff --git a/lib/efi_selftest/efi_selftest_ram_disk.c
b/lib/efi_selftest/efi_selftest_ram_disk.c
new file mode 100644
index 00..5d6ae1f44f
--- /dev/null
+++ b/lib/efi_selftest/efi_selftest_ram_disk.c
@@ -0,0 +1,511 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * efi_selftest_ram_disk
+ * The disk image defined in efi_selftest_disk_image.h is
+ * used in this test.
+ * Most source code originates from efi_selftest_block_device.c.
+ *
+ * Copyright (c) 2023, Linaro Limited
+ */
+
+#include
+#include "efi_selftest_disk_image.h"
+#include
+
+/* Block size of compressed disk image */
+#define COMPRESSED_DISK_IMAGE_BLOCK_SIZE 8
+
+/* Binary logarithm of the block size */
+#define LB_BLOCK_SIZE 9
+
+static struct efi_boot_services *boottime;
+
+static const efi_guid_t block_io_protocol_guid = EFI_BLOCK_IO_PROTOCOL_GUID;
+static const efi_guid_t guid_device_path = EFI_DEVICE_PATH_PROTOCOL_GUID;
+static const efi_guid_t guid_simple_file_system_protocol =
+ EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID;
+static const efi_guid_t guid_file_system_info = EFI_FILE_SYSTEM_INFO_GUID;
+static const efi_guid_t guid_ram_disk_protocol = EFI_RAM_DISK_PROTOCOL_GUID;
+static efi_guid_t guid_virtual_disk = EFI_VIRTUAL_DISK_GUID;
+
+/* One 8 byte block of the compressed disk image */
+struct line {
+ size_t addr;
+ char *line;
+};
+
+/* Compressed disk image */
+struct compressed_disk_image {
+ size_t length;
+ struct line lines[];
+};
+
+static const struct compressed_disk_image img = EFI_ST_DISK_IMG;
+
+/* Decompressed disk image */
+static u8 *image;
+static u8 *image2;
+
+/*
+ * Decompress the disk image.
+ *
+ * @image decompressed disk image
+ * Return: status code
+ */
+static efi_status_t decompress(u8 **image)
+{
+ u8 *buf;
+ size_t i;
+ size_t addr;
+ size_t len;
+ efi_status_t ret;
+
+ ret = boottime->allocate_pool(EFI_LOADER_DATA, img.length,
+ (void **));
+ if (ret != EFI_SUCCESS) {
+ efi_st_error("Out of memory\n");
+ return ret;
+ }
+ boottime->set_mem(buf, img.length, 0);
+
+ for (i = 0; ; ++i) {
+ if (!img.lines[i].line)
+ break;
+ addr = img.lines[i].addr;
+ len = COMPRESSED_DISK_IMAGE_BLOCK_SIZE;
+ if (addr + len > img.length)
+ len = img.length - addr;
+ boottime->copy_mem(buf + addr, img.lines[i].line, len);
+ }
+ *image = buf;
+ return ret;
+}
+
+/*
+ * Setup unit test.
+ *
+ * @handle:handle of the loaded image
+ * @systable: system table
+ * Return: EFI_ST_SUCCESS for success
+ */
+static int setup(const efi_handle_t handle,
+const struct efi_system_table *systable)
+{
+ boottime = systable->boottime;
+
+ decompress();
+ decompress();
+
+ return EFI_ST_SUCCESS;
+}
+
+/*
+ * Tear down unit test.
+ *
+ * Return: EFI_ST_SUCCESS for success
+ */
+static int teardown(void)
+{
+ efi_status_t r;
+
+ if (image) {
+ r = boottime->free_pool(image);
+ if (r != EFI_SUCCESS) {
+ efi_st_error("Failed to free image\n");
+ return EFI_ST_FAILURE;
+ }
+ }
+ if (image2) {
+ r = boottime->free_pool(image2);
+ if (r != EFI_SUCCESS) {
+ efi_st_error("Failed to free image\n");
+ return EFI_ST_FAILURE;
+ }
+ }
+ return EFI_ST_SUCCESS;
+}
+
+/*
+ * Get length of device path without end tag.
+ *
+ * @dp device path
+ * Return: length of device path in bytes
+ */
+static efi_uintn_t dp_size(struct efi_device_path *dp)
+{
+ struct efi_device_path *pos = dp;
+
+ while (pos->type != DEVICE_PATH_TYPE_END)
+ pos = (struct efi_device_path *)((char *)pos + pos->length);
+ return (char *)pos - (char *)dp;
+}
+
+/*
+ * Execute unit test.
+ *
+ * Return: EFI_ST_SUCCESS for success
+ */
+static int execute(void)
+{
+ efi_status_t ret;
+ struct efi_device_path *ram_disk_dp, *ram_disk_dp2;
+ struct
[PATCH 3/4] cmd: efidebug: add RAM disk mount command
This commit implements the test commands for EFI_RAM_DISK_PROTOCOL.
With the disk load/unload commands, user can mount the
ISO image in the volatile memory through EFI_RAM_DISK_PROTOCOL.
Currently the load command can load only one image at a time
even if UEFI specification does not limit the number of images.
Anyway one image is enough for testing.
Signed-off-by: Masahisa Kojima
---
cmd/efidebug.c | 117 +
1 file changed, 117 insertions(+)
diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index 9622430c47..3466ae7e32 100644
--- a/cmd/efidebug.c
+++ b/cmd/efidebug.c
@@ -1421,6 +1421,113 @@ static int do_efi_query_info(struct cmd_tbl *cmdtp, int
flag,
return CMD_RET_SUCCESS;
}
+#ifdef CONFIG_EFI_RAM_DISK_PROTOCOL
+static struct efi_device_path *ram_disk_dp;
+static efi_guid_t virtual_cd_guid = EFI_VIRTUAL_CD_GUID;
+
+static int do_efi_disk_load(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ u64 addr, size;
+ efi_status_t ret;
+ struct efi_ram_disk_protocol *ram_disk = NULL;
+
+ if (ram_disk_dp) {
+ printf("Only one image can be loaded\n");
+ return CMD_RET_FAILURE;
+ }
+
+ argc--;
+ argv++;
+
+ if (argc != 2)
+ return CMD_RET_USAGE;
+
+ addr = hextoul(argv[0], NULL);
+ size = hextoul(argv[1], NULL);
+
+ ret = EFI_CALL(BS->locate_protocol(_guid_ram_disk_protocol, NULL,
+ (void **)_disk));
+ if (ret != EFI_SUCCESS || !ram_disk) {
+ printf("No EFI_RAM_DISK_PROTOCOL found(ret = %lu)\n",
+ ret & ~EFI_ERROR_MASK);
+ return CMD_RET_FAILURE;
+ }
+
+ ret = EFI_CALL(ram_disk->disk_register(addr, size, _cd_guid,
NULL,
+ _disk_dp));
+ if (ret != EFI_SUCCESS || !ram_disk_dp) {
+ printf("RAM DISK register failed(ret = %lu)\n",
+ ret & ~EFI_ERROR_MASK);
+ return CMD_RET_FAILURE;
+ }
+
+ return CMD_RET_SUCCESS;
+}
+
+static int do_efi_disk_unload(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ efi_status_t ret;
+ struct efi_ram_disk_protocol *ram_disk = NULL;
+
+ ret = EFI_CALL(BS->locate_protocol(_guid_ram_disk_protocol, NULL,
+ (void **)_disk));
+ if (ret != EFI_SUCCESS || !ram_disk) {
+ printf("No EFI_RAM_DISK_PROTOCOL found(ret = %lu)\n",
+ ret & ~EFI_ERROR_MASK);
+ return CMD_RET_FAILURE;
+ }
+
+ ret = EFI_CALL(ram_disk->unregister(ram_disk_dp));
+ if (ret != EFI_SUCCESS) {
+ printf("RAM DISK unregister failed(ret = %lu)\n",
+ ret & ~EFI_ERROR_MASK);
+ return CMD_RET_FAILURE;
+ }
+
+ ram_disk_dp = NULL;
+
+ return CMD_RET_SUCCESS;
+}
+
+static struct cmd_tbl cmd_efidebug_disk_sub[] = {
+ U_BOOT_CMD_MKENT(load, CONFIG_SYS_MAXARGS, 1, do_efi_disk_load, "", ""),
+ U_BOOT_CMD_MKENT(unload, CONFIG_SYS_MAXARGS, 1, do_efi_disk_unload, "",
""),
+};
+
+/**
+ * do_efi_disk() - manage UEFI ram disk device
+ *
+ * @cmdtp: Command table
+ * @flag: Command flag
+ * @argc: Number of arguments
+ * @argv: Argument array
+ * Return: CMD_RET_SUCCESS on success,
+ * CMD_RET_USAGE or CMD_RET_RET_FAILURE on failure
+ *
+ * Implement efidebug "disk" sub-command.
+ */
+static int do_efi_disk(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ struct cmd_tbl *cp;
+
+ if (argc < 2)
+ return CMD_RET_USAGE;
+
+ argc--;
+ argv++;
+
+ cp = find_cmd_tbl(argv[0], cmd_efidebug_disk_sub,
+ ARRAY_SIZE(cmd_efidebug_disk_sub));
+ if (!cp)
+ return CMD_RET_USAGE;
+
+ return cp->cmd(cmdtp, flag, argc, argv);
+}
+#endif
+
static struct cmd_tbl cmd_efidebug_sub[] = {
U_BOOT_CMD_MKENT(boot, CONFIG_SYS_MAXARGS, 1, do_efi_boot_opt, "", ""),
#ifdef CONFIG_EFI_HAVE_CAPSULE_SUPPORT
@@ -1441,6 +1548,10 @@ static struct cmd_tbl cmd_efidebug_sub[] = {
"", ""),
U_BOOT_CMD_MKENT(query, CONFIG_SYS_MAXARGS, 1, do_efi_query_info,
"", ""),
+#ifdef CONFIG_EFI_RAM_DISK_PROTOCOL
+ U_BOOT_CMD_MKENT(disk, CONFIG_SYS_MAXARGS, 1, do_efi_disk,
+"", ""),
+#endif
};
/**
@@ -1526,6 +1637,12 @@ static char efidebug_help_text[] =
" - show UEFI memory map\n"
"efidebug tables\n"
" - show UEFI configuration tables\n"
+#ifdef CONFIG_EFI_RAM_DISK_PROTOCOL
+ "efidebug disk load \n"
+ " - load ISO image\n"
+ "efidebug disk unload\n"
+ " - unload ISO image\n"
+#endif
#ifdef
[PATCH 2/4] efi_loader: add EFI_RAM_DISK_PROTOCOL implementation
This commit adds the EFI_RAM_DISK_PROTOCOL implementation.
User can mount the distro installer by registering the
memory mapped ISO image through EFI_RAM_DISK_PROTOCOL.
Note that the installation process may not proceed
after the distro installer calls ExitBootServices()
since there is no hand-off process for the block device of
memory mapped ISO image.
Signed-off-by: Masahisa Kojima
---
include/efi_api.h | 13 ++
include/efi_loader.h | 4 +
lib/efi_driver/efi_uclass.c | 7 +-
lib/efi_loader/Kconfig| 6 +
lib/efi_loader/Makefile | 1 +
lib/efi_loader/efi_ram_disk.c | 334 ++
lib/efi_loader/efi_setup.c| 6 +
lib/uuid.c| 4 +
8 files changed, 373 insertions(+), 2 deletions(-)
create mode 100644 lib/efi_loader/efi_ram_disk.c
diff --git a/include/efi_api.h b/include/efi_api.h
index 4ee4a1b5e9..3982ab89bc 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -764,6 +764,19 @@ struct efi_block_io {
efi_status_t (EFIAPI *flush_blocks)(struct efi_block_io *this);
};
+#define EFI_RAM_DISK_PROTOCOL_GUID \
+ EFI_GUID(0xab38a0df, 0x6873, 0x44a9, \
+ 0x87, 0xe6, 0xd4, 0xeb, 0x56, 0x14, 0x84, 0x49)
+
+struct efi_ram_disk_protocol {
+ /* "register" is a reserved keyword in C, use "disk_register" instead */
+ efi_status_t(EFIAPI *disk_register)(
+ u64 ram_disk_base, u64 ram_disk_size, efi_guid_t *ram_disk_type,
+ struct efi_device_path *parent_device_path,
+ struct efi_device_path **device_path);
+ efi_status_t (EFIAPI *unregister)(struct efi_device_path *device_path);
+};
+
struct simple_text_output_mode {
s32 max_mode;
s32 mode;
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 604fd765f7..70c8c83099 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -333,6 +333,8 @@ extern const efi_guid_t smbios_guid;
/*GUID of console */
extern const efi_guid_t efi_guid_text_input_protocol;
extern const efi_guid_t efi_guid_text_output_protocol;
+/* GUID of Ram Disk protocol */
+extern const efi_guid_t efi_guid_ram_disk_protocol;
extern char __efi_runtime_start[], __efi_runtime_stop[];
extern char __efi_runtime_rel_start[], __efi_runtime_rel_stop[];
@@ -1159,4 +1161,6 @@ efi_status_t efi_disk_get_device_name(const efi_handle_t
handle, char *buf, int
*/
void efi_add_known_memory(void);
+efi_status_t efi_ram_disk_register(void);
+
#endif /* _EFI_LOADER_H */
diff --git a/lib/efi_driver/efi_uclass.c b/lib/efi_driver/efi_uclass.c
index 45f9351988..f7597811b7 100644
--- a/lib/efi_driver/efi_uclass.c
+++ b/lib/efi_driver/efi_uclass.c
@@ -44,8 +44,11 @@ static efi_status_t check_node_type(efi_handle_t handle)
/* Get the last node */
const struct efi_device_path *node = efi_dp_last_node(dp);
/* We do not support partitions as controller */
- if (!node || node->type == DEVICE_PATH_TYPE_MEDIA_DEVICE)
- ret = EFI_UNSUPPORTED;
+ if (!node || node->type == DEVICE_PATH_TYPE_MEDIA_DEVICE) {
+ /* We support RAM disk as controller */
+ if (node->sub_type !=
DEVICE_PATH_SUB_TYPE_RAM_DISK_PATH)
+ ret = EFI_UNSUPPORTED;
+ }
}
return ret;
}
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index c5835e6ef6..1a81b65688 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -433,4 +433,10 @@ config EFI_RISCV_BOOT_PROTOCOL
replace the transfer via the device-tree. The latter is not
possible on systems using ACPI.
+config EFI_RAM_DISK_PROTOCOL
+ bool "EFI_RAM_DISK_PROTOCOL support"
+ depends on PARTITIONS
+ help
+ Provide a EFI_RAM_DISK_PROTOCOL implementation to register the
+ RAM disk and create the block device.
endif
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 1a8c8d7cab..4197f594a2 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -86,6 +86,7 @@ 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
obj-$(CONFIG_EFI_ECPT) += efi_conformance.o
+obj-$(CONFIG_EFI_RAM_DISK_PROTOCOL) += efi_ram_disk.o
EFI_VAR_SEED_FILE := $(subst $\",,$(CONFIG_EFI_VAR_SEED_FILE))
$(obj)/efi_var_seed.o: $(srctree)/$(EFI_VAR_SEED_FILE)
diff --git a/lib/efi_loader/efi_ram_disk.c b/lib/efi_loader/efi_ram_disk.c
new file mode 100644
index 00..10a6944aea
--- /dev/null
+++ b/lib/efi_loader/efi_ram_disk.c
@@ -0,0 +1,334 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * RAM Disk Protocol
+ *
+ * Copyright (c) 2023, Linaro Limited
+ */
+
+#include
+#include
+#include
+#include
+
+#define MEM_BLOCK_SIZE_SHIFT 9 /* 512 bytes */
+
+const efi_guid_t efi_guid_ram_disk_protocol =
[PATCH 1/4] efi_loader: add RAM disk device path
This is a preparation to add the EFI_RAM_DISK_PROTOCOL.
This commit adds the RAM disk device path structure
and text conversion to Device Path to Text Protocol.
Signed-off-by: Masahisa Kojima
---
include/efi_api.h| 19 +++
lib/efi_loader/efi_device_path_to_text.c | 14 ++
2 files changed, 33 insertions(+)
diff --git a/include/efi_api.h b/include/efi_api.h
index 55a4c989fc..4ee4a1b5e9 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -682,6 +682,7 @@ struct efi_device_path_uri {
# define DEVICE_PATH_SUB_TYPE_CDROM_PATH 0x02
# define DEVICE_PATH_SUB_TYPE_VENDOR_PATH 0x03
# define DEVICE_PATH_SUB_TYPE_FILE_PATH 0x04
+# define DEVICE_PATH_SUB_TYPE_RAM_DISK_PATH 0x09
struct efi_device_path_hard_drive_path {
struct efi_device_path dp;
@@ -705,6 +706,24 @@ struct efi_device_path_file_path {
u16 str[];
} __packed;
+/* This GUID defines a RAM Disk supporting a raw disk format in volatile
memory */
+#define EFI_VIRTUAL_DISK_GUID \
+ EFI_GUID(0x77ab535a, 0x45fc, 0x624b, \
+ 0x55, 0x60, 0xf7, 0xb2, 0x81, 0xd1, 0xf9, 0x6e)
+
+/* This GUID defines a RAM Disk supporting an ISO image in volatile memory */
+#define EFI_VIRTUAL_CD_GUID \
+ EFI_GUID(0x3d5abd30, 0x4175, 0x87ce, \
+0x6d, 0x64, 0xd2, 0xad, 0xe5, 0x23, 0xc4, 0xbb)
+
+struct efi_device_path_ram_disk_path {
+ struct efi_device_path dp;
+ u64 starting_address;
+ u64 ending_address;
+ efi_guid_t disk_type_guid;
+ u16 disk_instance;
+} __packed;
+
#define EFI_BLOCK_IO_PROTOCOL_GUID \
EFI_GUID(0x964e5b21, 0x6459, 0x11d2, \
0x8e, 0x39, 0x00, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
diff --git a/lib/efi_loader/efi_device_path_to_text.c
b/lib/efi_loader/efi_device_path_to_text.c
index 8c76d8be60..4395e79f33 100644
--- a/lib/efi_loader/efi_device_path_to_text.c
+++ b/lib/efi_loader/efi_device_path_to_text.c
@@ -324,6 +324,20 @@ static char *dp_media(char *s, struct efi_device_path *dp)
free(buffer);
break;
}
+ case DEVICE_PATH_SUB_TYPE_RAM_DISK_PATH: {
+ struct efi_device_path_ram_disk_path *rddp =
+ (struct efi_device_path_ram_disk_path *)dp;
+ u64 start;
+ u64 end;
+
+ /* Copy from packed structure to aligned memory */
+ memcpy(, >starting_address, sizeof(start));
+ memcpy(, >ending_address, sizeof(end));
+
+ s += sprintf(s, "RamDisk(0x%llx,%llx,%pUl,0x%x)", start, end,
+>disk_type_guid, rddp->disk_instance);
+ break;
+ }
default:
s = dp_unknown(s, dp);
break;
--
2.34.1
[PATCH 0/4] introduce EFI_RAM_DISK_PROTOCOL
This series introduces the EFI_RAM_DISK_PROTOCOL implementation. The major purpose of this series is a preparation for EFI HTTP(S) boot. Now U-Boot can download the distro installer ISO image via wget or tftpboot commands, but U-Boot can not mount the downloaded ISO image. By calling EFI_RAM_DISK_PROTOCOL->register API, user can mount the ISO image and boot the distro installer. Note that the installation process may not proceed after the distro installer calls ExitBootServices() since there is no hand-off process for the block device of memory mapped ISO image. The EFI_RAM_DISK_PROTOCOL was tested with the debian network installer[1] on qemu_arm64 platform. The example procedure is as follows. => tftpboot 4100 mini.iso => efidebug disk load 4100 $filesize After these commands, ISO image is mounted like: => efidebug dh 7eec5910 (efiblk#0) /RamDisk(0x4100,4974afff,3d5abd30-4175-87ce-6d64-d2ade523c4bb,0x0) Block IO 7eec6140 (efiblk#0:1) /RamDisk(0x4100,4974afff,3d5abd30-4175-87ce-6d64-d2ade523c4bb,0x0)/HD(1,0x01,0,0x0,0x33800) Block IO 7eec62b0 (efiblk#0:2) /RamDisk(0x4100,4974afff,3d5abd30-4175-87ce-6d64-d2ade523c4bb,0x0)/HD(2,0x01,0,0x33800,0x1) Block IO System Partition Simple File System => dm tree blk 0 [ + ] efi_blk `-- efiblk#0 partition 0 [ + ] blk_partition |-- efiblk#0:1 partition 1 [ + ] blk_partition `-- efiblk#0:2 Debian can be successfully installed with this RAM disk on QEMU. [TODO] - udevices created in ./lib/efi_driver/efi_block_device.c::efi_bl_bind() are not removed when the efi_handle is removed. So after unload the RAM disk, udevices still exist. I plan to add a udevice removal process in ./lib/efi_driver/efi_uclass.c::efi_uc_stop(). In addition, I also plan to add unbind() callback in struct efi_driver_ops. [1] https://deb.debian.org/debian/dists/bookworm/main/installer-arm64/current/images/netboot/mini.iso Masahisa Kojima (4): efi_loader: add RAM disk device path efi_loader: add EFI_RAM_DISK_PROTOCOL implementation cmd: efidebug: add RAM disk mount command efi_selftest: add EFI_RAM_DISK_PROTOCOL selftest cmd/efidebug.c | 117 ++ include/efi_api.h| 32 ++ include/efi_loader.h | 4 + lib/efi_driver/efi_uclass.c | 7 +- lib/efi_loader/Kconfig | 6 + lib/efi_loader/Makefile | 1 + lib/efi_loader/efi_device_path_to_text.c | 14 + lib/efi_loader/efi_ram_disk.c| 334 +++ lib/efi_loader/efi_setup.c | 6 + lib/efi_selftest/Makefile| 1 + lib/efi_selftest/efi_selftest_ram_disk.c | 511 +++ lib/uuid.c | 4 + 12 files changed, 1035 insertions(+), 2 deletions(-) create mode 100644 lib/efi_loader/efi_ram_disk.c create mode 100644 lib/efi_selftest/efi_selftest_ram_disk.c base-commit: e2e2aea5733f0d23cd9593bbefe5c803c552dcb9 -- 2.34.1
Re: [bug report] sunxi: H6: no ethernet on Orange Pi One Plus
On Wed, Jul 05, 2023 at 02:15:43PM -0300, Fabio Estevam wrote: > On Wed, Jul 5, 2023 at 1:31 PM Anne Macedo wrote: > > > I think I'm on the right path :) > > > > 1. Included SUNXI_SETUP_REGULATORS=0 to the bl31 make > > 2. Changed the phy mode on arch/arm/dts/sun50i-h6-orangepi-one-plus.dts > >From rgmii-id to rgmii > > This does not look like the correct fix. Please see this commit from Linux: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.4.1=544cc3f8573bf9a82e8f348741f2f68d2a8376fb > > >More info on [1][2][3] > > 3. Added this configs to configs/orangepi_one_plus_defconfig: > >CONFIG_SPL_SPI_SUNXI=y > >CONFIG_SUNXI_NO_PMIC=y >e>CONFIG_SUN8I_EMAC=y > > > > Result: > > > > U-Boot 2023.04-gfd4ed6b (Apr 03 2023 - 20:38:50 +) Allwinner > > Technology > > > > CPU: Allwinner H6 (SUN50I) > > Model: OrangePi One Plus > > DRAM: 1 GiB > > Core: 55 devices, 17 uclasses, devicetree: separate > > WDT: Not starting watchdog@7020400 > > MMC: mmc@402: 0 > > Loading Environment from FAT... Unable to read "uboot.env" from > > mmc0:1... > > In:serial@500 > > Out: serial@500 > > Err: serial@500 > > Net: eth0: ethernet@502 > > > > => dhcp > > sun8i_emac_eth_start: Timeout > > => mdio list > > ethernet@502: > > 1 - Generic PHY <--> ethernet@502 > > What about using the Realtek PHY driver instead of the Generic one? > > --- a/configs/orangepi_one_plus_defconfig > +++ b/configs/orangepi_one_plus_defconfig > @@ -8,3 +8,6 @@ CONFIG_SUNXI_DRAM_H6_LPDDR3=y > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_OHCI_HCD=y > +CONFIG_PHY_REALTEK=y > +CONFIG_RGMII=y > +CONFIG_MII=y > > Does this help? Sorry for the delay, life came in the way. u-boot config: CONFIG_PHY_REALTEK=y CONFIG_RGMII=y CONFIG_MII=y tfa config: SUNXI_SETUP_REGULATORS=0 result: => dhcp No ethernet found. u-boot config: CONFIG_SPL_SPI_SUNXI=y CONFIG_SUNXI_NO_PMIC=y CONFIG_SUN8I_EMAC=y CONFIG_PHY_REALTEK=y CONFIG_RGMII=y CONFIG_MII=y tfa config: SUNXI_SETUP_REGULATORS=0 result: Net: PHY reset timed out eth0: ethernet@502 => dhcp sun8i_emac_eth_start: Timeout => mdio list ethernet@502: 1 - Generic PHY <--> ethernet@502 It's interesting that it keeps using Generic PHY. Regards, Anne
RE: [PATCH u-boot 0/4] mmc: Explain and cleanup partition selection
> -Original Message- > From: Pali Rohár > Sent: Thursday, July 6, 2023 7:51 PM > To: Jaehoon Chung ; Tom Rini > Cc: Peng Fan ; Stefan Roese ; > u-boot@lists.denx.de > Subject: Re: [PATCH u-boot 0/4] mmc: Explain and cleanup partition selection > > On Monday 03 July 2023 21:16:37 Jaehoon Chung wrote: > > Hi, > > > > On 4/14/23 06:10, Pali Rohár wrote: > > > Some people do not want to read review comments in emails. So put > > > comments and explanation into the source code itself; make emmc > > > partition selection code more explicit and validate configuration in > > > bubt command. > > > > Sorry for too late. > > After applied this patch-set, some board are failed with spl's size > > overflowed > > > > The below is one of failed log. > > > > +arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 352 bytes > > +make[2]: *** [scripts/Makefile.spl:527: spl/u-boot-spl] Error 1 > > +make[1]: *** [Makefile:2049: spl/u-boot-spl] Error 2 > > Crap, and again we have there same issue. Patch after months does not > apply anymore. And resending the patch would again result in the same > problem that it would not apply anymore after half of the year... > > > Anyway, only first patch is SPL specific, other should apply without any > problem. Except spl specific patch, I will check again about your other patches. Thanks! Best Regards, Jaehoon Chung > > > > > Best Regards, > > Jaehoon Chung > > > > > > > > Pali Rohár (4): > > > mmc: spl: Make partition choice in > > > default_spl_mmc_emmc_boot_partition() more explicit > > > cmd: mvebu/bubt: Validate EXT_CSD[179] eMMC register in > > > mmc_burn_image() > > > sunxi: eMMC: Add comments explaining mapping between bootpart and > > > mmc_switch_part() > > > board: purism: Use U-Boot mmc function for converting boot part to > > > part access > > > > > > arch/arm/mach-sunxi/board.c| 12 ++- > > > board/purism/librem5/librem5.c | 6 +- > > > cmd/mvebu/bubt.c | 24 +++-- > > > common/spl/spl_mmc.c | 38 +++--- > > > 4 files changed, 64 insertions(+), 16 deletions(-) > >
RE: [PATCH] ARM: dts: imx: Fix eMMC boot on Data Modul i.MX8M Plus eDM SBC
> -Original Message-
> From: U-Boot On Behalf Of Peng Fan
> Sent: Thursday, July 6, 2023 5:01 PM
> To: Marek Vasut ; u-boot@lists.denx.de
> Cc: tr...@konsulko.com; Fabio Estevam ; Peng Fan
> ; Stefano Babic
>
> Subject: Re: [PATCH] ARM: dts: imx: Fix eMMC boot on Data Modul i.MX8M Plus
> eDM SBC
>
>
>
> On 7/6/2023 7:26 AM, Marek Vasut wrote:
> > In case the i.MX8M Plus starts from eMMC BOOT1/BOOT2 HW partitions, the
> > flash.bin container is stored at offset 0 from the start, that means the
> > fitImage itb is at offset 0x2c0 instead of 0x300 sectors from the start.
> > Handle this difference in custom spl_mmc_get_uboot_raw_sector() .
> >
> > Signed-off-by: Marek Vasut
>
> Reviewed-by: Peng Fan
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
>
> > ---
> > Cc: Fabio Estevam
> > Cc: Peng Fan
> > Cc: Stefano Babic
> > ---
> > board/data_modul/imx8mp_edm_sbc/spl.c | 14 ++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/board/data_modul/imx8mp_edm_sbc/spl.c
> > b/board/data_modul/imx8mp_edm_sbc/spl.c
> > index c30185e48d4..2fdd95a730c 100644
> > --- a/board/data_modul/imx8mp_edm_sbc/spl.c
> > +++ b/board/data_modul/imx8mp_edm_sbc/spl.c
> > @@ -107,6 +107,20 @@ void board_boot_order(u32 *spl_boot_list)
> > spl_boot_list[4] = BOOT_DEVICE_NONE;
> > }
> >
> > +unsigned long spl_mmc_get_uboot_raw_sector(struct mmc *mmc, unsigned long
> > sect)
> > +{
> > + const u32 boot_dev = spl_boot_device();
> > + int part;
> > +
> > + if (boot_dev == BOOT_DEVICE_MMC2) { /* eMMC */
> > + part = spl_mmc_emmc_boot_partition(mmc);
> > + if (part == 1 || part == 2) /* eMMC BOOT1/BOOT2 HW
> > partitions */
> > + return sect - 0x40;
> > + }
> > +
> > + return sect;
> > +}
> > +
> > static struct dram_timing_info *dram_timing_info[8] = {
> > _imx8mp_sbc_dram_timing_32_32, /* 32 Gbit x32 */
> > NULL, /* 32 Gbit x16 */
RE: [PATCH u-boot 0/4] mmc: Explain and cleanup partition selection
Hi > -Original Message- > From: Pali Rohár > Sent: Friday, July 7, 2023 2:39 AM > To: Jaehoon Chung ; Tom Rini > Cc: Peng Fan ; Stefan Roese ; > u-boot@lists.denx.de > Subject: Re: [PATCH u-boot 0/4] mmc: Explain and cleanup partition selection > > On Thursday 06 July 2023 12:50:34 Pali Rohár wrote: > > On Monday 03 July 2023 21:16:37 Jaehoon Chung wrote: > > > Hi, > > > > > > On 4/14/23 06:10, Pali Rohár wrote: > > > > Some people do not want to read review comments in emails. So put > > > > comments and explanation into the source code itself; make emmc > > > > partition selection code more explicit and validate configuration in > > > > bubt command. > > > > > > Sorry for too late. > > > After applied this patch-set, some board are failed with spl's size > > > overflowed > > > > > > The below is one of failed log. > > > > > > +arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 352 bytes > > > +make[2]: *** [scripts/Makefile.spl:527: spl/u-boot-spl] Error 1 > > > +make[1]: *** [Makefile:2049: spl/u-boot-spl] Error 2 > > > > Crap, and again we have there same issue. Patch after months does not > > apply anymore. And resending the patch would again result in the same > > problem that it would not apply anymore after half of the year... > > Here is v2 patch with simple fix for that platform: > https://protect2.fireeye.com/v1/url?k=bec9bc29-df42a906-bec83766-74fe485cbfe7- > 2e40f47b53afb09d=1=e8f6a6f2-8f6f-4bf1-9b91- > 3f71d3577fc7=https%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Fuboot%2Fpatch%2F20230706173502.2796-1- > pali%40kernel.org%2F > > And it passed _now_ CI pipeline: > https://protect2.fireeye.com/v1/url?k=543f3751-35b4227e-543ebc1e-74fe485cbfe7- > ff5f636a3c274f12=1=e8f6a6f2-8f6f-4bf1-9b91-3f71d3577fc7=https%3A%2F%2Fgithub.com%2Fu-boot%2Fu- > boot%2Fpull%2F340 > Thanks for sharing it. Best Regards, Jaehoon Chung > > > > Anyway, only first patch is SPL specific, other should apply without any > > problem. > > > > > > > > Best Regards, > > > Jaehoon Chung > > > > > > > > > > > Pali Rohár (4): > > > > mmc: spl: Make partition choice in > > > > default_spl_mmc_emmc_boot_partition() more explicit > > > > cmd: mvebu/bubt: Validate EXT_CSD[179] eMMC register in > > > > mmc_burn_image() > > > > sunxi: eMMC: Add comments explaining mapping between bootpart and > > > > mmc_switch_part() > > > > board: purism: Use U-Boot mmc function for converting boot part to > > > > part access > > > > > > > > arch/arm/mach-sunxi/board.c| 12 ++- > > > > board/purism/librem5/librem5.c | 6 +- > > > > cmd/mvebu/bubt.c | 24 +++-- > > > > common/spl/spl_mmc.c | 38 +++--- > > > > 4 files changed, 64 insertions(+), 16 deletions(-) > > >
Re: [PATCH v1] HSD #18028953892: usb: xhci-dwc3: Fix USB3.1 controller register access in reset state
On 6/22/23 16:08, Lim, Jit Loon wrote: -Original Message- From: Marek Vasut Sent: Thursday, 22 June, 2023 5:35 PM To: Lim, Jit Loon ; u-boot@lists.denx.de Cc: Jagan Teki ; Simon ; Chee, Tien Fong ; Hea, Kok Kiang ; Lokanathan, Raaj ; Maniyam, Dinesh ; Ng, Boon Khai ; Yuslaimi, Alif Zakuan ; Chong, Teik Heng ; Zamri, Muhammad Hazim Izzat ; Tang, Sieu Mun ; Bin Meng ; Michal Simek ; Tom Rini ; Eugen Hristev Subject: Re: [PATCH v1] HSD #18028953892: usb: xhci-dwc3: Fix USB3.1 controller register access in reset state On 6/22/23 04:48, Lim, Jit Loon wrote: -Original Message- From: Marek Vasut Sent: Wednesday, 21 June, 2023 10:19 PM To: Lim, Jit Loon ; u-boot@lists.denx.de Cc: Jagan Teki ; Simon ; Chee, Tien Fong ; Hea, Kok Kiang ; Lokanathan, Raaj ; Maniyam, Dinesh ; Ng, Boon Khai ; Yuslaimi, Alif Zakuan ; Chong, Teik Heng ; Zamri, Muhammad Hazim Izzat ; Tang, Sieu Mun ; Bin Meng Subject: Re: [PATCH v1] HSD #18028953892: usb: xhci-dwc3: Fix USB3.1 controller register access in reset state On 6/21/23 16:11, Jit Loon Lim wrote: From: Teik Heng Chong The controller registers should not be accessed while the controller's vcc_reset_n is asserted. Signed-off-by: Teik Heng Chong Is this patch ported from Linux or is this custom development ? Is there a matching patch/fix in Linux already ? In xhci_dwc3_probe(), the program sequence is vcc reset -> clk init -> phy setup -> xhci_register therefore, when xhci_dwc3_remove is called, the proper usb stop sequence should be xhci_register _> phy setup -> clk init -> vcc reset if we look at linux driver https://elixir.bootlin.com/linux/latest/source/drivers/usb/dwc3/dwc3-o f-simple.c#L33 dwc3_of_simple_probe: The sequence is reset -> clock __dwc3_of_simple_teardown: Then, clock -> reset So based on the above, we have made changes and the uboot fix is now aligned with linux driver. Instead of adding random patches to the U-Boot dwc3 driver, please just synchronize the driver with Linux. You should be able to add the missing patches to the DWC3 driver from Linux since the last synchronization point, the process should be largely mechanical. Make sure to include commit ID of each Linux commit in the new matching U-Boot patch. It shouldn't be difficult, one approach I can think of is roughly this: - figure out the original merge base from which the DWC3 driver was imported to U-Boot - in U-Boot, revert all dwc3 patches on top of that import patch - pick all Linux kernel dwc3 patches from that merge base and apply on top of this U-Boot with reverts - Run rebase and drop the reverts, let git drop duplicate patches We believed the previous reply from us is a bit confusing. There is no exact same function/file for U-Boot to use in Linux. What we are doing is, we are referring to Linux sequence. Linux: (dwc3_of_simple_probe) https://elixir.bootlin.com/linux/latest/source/drivers/usb/dwc3/dwc3-of-simple.c#L33 U-Boot: (xhci_dwc3_probe) https://elixir.bootlin.com/u-boot/latest/source/drivers/usb/host/xhci-dwc3.c#L159 Linux: (__dwc3_of_simple_teardown) https://elixir.bootlin.com/linux/latest/source/drivers/usb/dwc3/dwc3-of-simple.c#L98 U-Boot: (xhci_dwc3_remove) https://elixir.bootlin.com/u-boot/latest/source/drivers/usb/host/xhci-dwc3.c#L227 So we believed that we can't directly pickup all Linux kernel dwc3 patches and merge to U-Boot. If you were to sync the driver from Linux to U-Boot, then the same sequence as Linux uses would be automatically used too, right ? Sorry for the abysmal delay in my reply.
[PATCH] ARM: stm32: Inhibit PDDS because CSTBYDIS is set
The PWR_MPUCR CSTBYDIS bit is set, therefore the CA cores can never enter CStandby state and would always end up in CStop state. Clear the PDDS bit, which indicates the CA cores can enter CStandby state as it makes little sense to keep it set with CSTBYDIS also set. This does however fix a problem too. When both PWR_MPUCR and PWR_MCUCR PDDS bits are set, then the chip enters CStandby state even though the PWR_MCUCR CSTBYDIS is set. Clearing the PWR_MPUCR PDDS prevents that from happening. Signed-off-by: Marek Vasut --- Cc: Patrice Chotard Cc: Patrick Delaunay Cc: uboot-st...@st-md-mailman.stormreply.com --- arch/arm/mach-stm32mp/psci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-stm32mp/psci.c b/arch/arm/mach-stm32mp/psci.c index 50e3fc4ae45..79734b5289b 100644 --- a/arch/arm/mach-stm32mp/psci.c +++ b/arch/arm/mach-stm32mp/psci.c @@ -754,7 +754,7 @@ void __secure psci_system_suspend(u32 __always_unused function_id, setbits_le32(STM32_RCC_BASE + RCC_MP_CIER, RCC_MP_CIFR_WKUPF); setbits_le32(STM32_PWR_BASE + PWR_MPUCR, -PWR_MPUCR_CSSF | PWR_MPUCR_CSTDBYDIS | PWR_MPUCR_PDDS); +PWR_MPUCR_CSSF | PWR_MPUCR_CSTDBYDIS); saved_mcudivr = readl(STM32_RCC_BASE + RCC_MCUDIVR); saved_pll3cr = readl(STM32_RCC_BASE + RCC_PLL3CR); -- 2.40.1
Re: v2023.07-rc5 regression: Image overlaps SPL
Hi, On Wed, 5 Jul 2023 at 09:35, Tom Rini wrote: > > On Tue, Jul 04, 2023 at 02:13:01PM -0300, Fabio Estevam wrote: > > On 04/07/2023 14:04, Francesco Dolcini wrote: > > > > > The boards that do not check the return value might start to behave > > > wrongly without an obvious error to help the debugging. > > > > Yes, the current implementation of fdt_status_disabled() is fragile, but > > there's not so much we can do for the upcoming 2023.07. > > > > I can try to prepare a patch to improve it after 2023.07 is out next week. > > It's also been fragile-as-designed since inception. The trigger here was > that renaming a ton of properties _reduced_ the overall dtb size itself > and so some edge cases got pushed over the edge. I'm honestly not sure > if it's better to: > - Give everyone a small padding by default > - Make the platforms which may call one of these functions a small > padding by default One of the above seems good to me. Perhaps we could add a default padding, with the ability to reduce it to 0, or increase it. I suspect that not many boards update the FDT in SPL. > - Audit the callers and make them handle -FDT_ERR_NOSPACE like the other > cases where we grow the dtb size do. Even if yes, many of those other > cases are for non-trivial growth rather than just adding 4 more > letters. > - Make fdt_set_node_status() handle the disabled case when out of space > and grow/retry. I don't like that since: - it adds to complexity in that a 'leaf' function is messing with stuff it shouldn't - In generate we don't know if there is space to increase the FDT size - It likely increase code size for a case that cannot happen if people have tested it properly - It affects all boards If boards are ignoring errors, that is up to the boards. We do encourage people (in core review) to check all errors. This is an example of why. Regards, Simon
Re: [PULL] u-boot-usb/master
On Mon, Jul 03, 2023 at 01:22:21PM +0200, Marek Vasut wrote: > The following changes since commit ac29400f1f4ae5df2542bacfe4c142db7824bd6c: > > Merge tag 'efi-2023-07-rc6' of > https://source.denx.de/u-boot/custodians/u-boot-efi (2023-07-01 16:11:51 > -0400) > > are available in the Git repository at: > > git://source.denx.de/u-boot-usb.git master > > for you to fetch changes up to d266d4b63873c2176677a79d48faeb9db7d4acdd: > > usb: dwc3-generic: Ensure reset GPIO is configured as an output (2023-07-03 > 10:46:34 +0200) > Since we talked a little about this on IRC, applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-riscv/riscv-for-next
On Thu, Jul 06, 2023 at 10:45:51AM +, Leo Liang wrote: > Hi Tom, > > The following changes since commit e80f4079b3a3db0961b73fa7a96e6c90242d8d25: > > Merge tag 'v2023.07-rc6' into next (2023-07-05 11:28:55 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-riscv.git riscv-for-next > > for you to fetch changes up to 12f66e2197c59e500d1e2ee359bb2ce22d748290: > > board: ae350: Add missing env variables for booti (2023-07-06 17:28:08 > +0800) > > CI result shows no issue: > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/16799 > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: EFI Secure boot default keys
On Wed, Jun 28, 2023 at 04:26:58PM +, Neil Jones wrote: Please can someone describe the format of the file needed for the default / built-in EFI secure boot keys (ubootefi.var) The only docs I have found suggest its best to enroll the keys from within u-boot onto some removable media, then copy this off and use this as the default, this is not very helpful and doesn't work for me: The file format is described in https://github.com/ARM-software/ebbr/blob/main/source/chapter5-variable-storage.rst U-Boot comes with tools/efivar.py to edit ubootefi.var. Best regards Heinrich
Re: [PATCH v2 u-boot] mmc: spl: Make partition choice in default_spl_mmc_emmc_boot_partition() more explicit
On Thu, Jul 06, 2023 at 07:49:18PM +0200, Pali Rohár wrote:
> On Thursday 06 July 2023 13:42:18 Tom Rini wrote:
> > On Thu, Jul 06, 2023 at 07:35:02PM +0200, Pali Rohár wrote:
> > > To make eMMC partition choosing in default_spl_mmc_emmc_boot_partition()
> > > function better understandable, rewrite it via explicit switch-case code
> > > pattern.
> > >
> > > Also add a warning when eMMC EXT_CSD[179] register is configured by user
> > > to
> > > value which is not suitable for eMMC booting and SPL do not know how to
> > > interpret it.
> > >
> > > Note that when booting from eMMC device via EXT_CSD[179] register is
> > > explicitly disabled then SPL still loads and boots from this eMMC device
> > > from User Area partition. This behavior was not changed in this commit and
> > > should be revisited in the future.
> > >
> > > Signed-off-by: Pali Rohár
> > > ---
> > > Changes in v2:
> > > * Disable showing warning on sama5d2_xplained due to size restrictions
> > > ---
> > > This patch depends on another patch:
> > > mmc: spl: Add comments for default_spl_mmc_emmc_boot_partition()
> > > https://patchwork.ozlabs.org/project/uboot/patch/20230404202805.8523-1-p...@kernel.org/
> > > ---
> > > common/spl/Kconfig | 7 +++
> > > common/spl/spl_mmc.c | 46
> > > 2 files changed, 45 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > > index 865571d4579c..0574d22b3b25 100644
> > > --- a/common/spl/Kconfig
> > > +++ b/common/spl/Kconfig
> > > @@ -855,6 +855,13 @@ config SPL_MMC_WRITE
> > > help
> > > Enable write access to MMC and SD Cards in SPL
> > >
> > > +config SPL_MMC_WARNINGS
> > > + bool "Print MMC warnings"
> > > + depends on SPL_MMC
> > > + default y if !TARGET_SAMA5D2_XPLAINED
> > > + help
> > > + Print SPL MMC warnings. You can disable this option to reduce SPL
> > > size.
> > > +
> > >
> > > config SPL_MPC8XXX_INIT_DDR
> > > bool "Support MPC8XXX DDR init"
> > > diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> > > index f7a42a11477d..ec424ceded0e 100644
> > > --- a/common/spl/spl_mmc.c
> > > +++ b/common/spl/spl_mmc.c
> > > @@ -408,15 +408,45 @@ int default_spl_mmc_emmc_boot_partition(struct mmc
> > > *mmc)
> > >*
> > >* Note: See difference between EXT_CSD_EXTRACT_PARTITION_ACCESS
> > >* and EXT_CSD_EXTRACT_BOOT_PART, specially about User area value.
> > > - *
> > > - * FIXME: When booting from this eMMC device is explicitly
> > > - * disabled then we use User area for booting. This is incorrect.
> > > - * Probably we should skip this eMMC device and select the next
> > > - * one for booting. Or at least throw warning about this fallback.
> > >*/
> > > - part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
> > > - if (part == 7)
> > > - part = 0;
> > > + if (mmc->part_config == MMCPART_NOAVAILABLE)
> > > + part = 0; /* If partitions are not supported then we have only
> > > User Area partition */
> > > + else {
> > > + switch(EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config)) {
> > > + case 0: /* Booting from this eMMC device is disabled */
> > > +#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> > > +#ifdef CONFIG_SPL_MMC_WARNINGS
> > > + puts("spl: WARNING: Booting from this eMMC device is
> > > disabled in EXT_CSD[179] register\n");
> > > + puts("spl: WARNING: Continuing anyway and selecting
> > > User Area partition for booting\n");
> > > +#else
> > > + puts("spl: mmc: fallback to user area\n");
> > > +#endif
> > > +#endif
> > > + /* FIXME: This is incorrect and probably we should
> > > select next eMMC device for booting */
> > > + part = 0;
> > > + break;
> > > + case 1: /* Boot partition 1 is used for booting */
> > > + part = 1;
> > > + break;
> > > + case 2: /* Boot partition 2 is used for booting */
> > > + part = 2;
> > > + break;
> > > + case 7: /* User area is used for booting */
> > > + part = 0;
> > > + break;
> > > + default: /* Other values are reserved */
> > > +#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> > > +#ifdef CONFIG_SPL_MMC_WARNINGS
> > > + puts("spl: WARNING: EXT_CSD[179] register is configured
> > > to boot from Reserved value\n");
> > > + puts("spl: WARNING: Selecting User Area partition for
> > > booting\n");
> > > +#else
> > > + puts("spl: mmc: fallback to user area\n");
> > > +#endif
> > > +#endif
> > > + part = 0;
> > > + break;
> > > + }
> > > + }
> > > #endif
> >
> > Please just use debug() for these messages.
>
> All other error/warning messages in this file are printed via puts().
> So I'm just following the current style (and I'm really not going to
> change all occurrences in this patch).
Re: [PATCH v2 u-boot] mmc: spl: Make partition choice in default_spl_mmc_emmc_boot_partition() more explicit
On Thursday 06 July 2023 13:42:18 Tom Rini wrote:
> On Thu, Jul 06, 2023 at 07:35:02PM +0200, Pali Rohár wrote:
> > To make eMMC partition choosing in default_spl_mmc_emmc_boot_partition()
> > function better understandable, rewrite it via explicit switch-case code
> > pattern.
> >
> > Also add a warning when eMMC EXT_CSD[179] register is configured by user to
> > value which is not suitable for eMMC booting and SPL do not know how to
> > interpret it.
> >
> > Note that when booting from eMMC device via EXT_CSD[179] register is
> > explicitly disabled then SPL still loads and boots from this eMMC device
> > from User Area partition. This behavior was not changed in this commit and
> > should be revisited in the future.
> >
> > Signed-off-by: Pali Rohár
> > ---
> > Changes in v2:
> > * Disable showing warning on sama5d2_xplained due to size restrictions
> > ---
> > This patch depends on another patch:
> > mmc: spl: Add comments for default_spl_mmc_emmc_boot_partition()
> > https://patchwork.ozlabs.org/project/uboot/patch/20230404202805.8523-1-p...@kernel.org/
> > ---
> > common/spl/Kconfig | 7 +++
> > common/spl/spl_mmc.c | 46
> > 2 files changed, 45 insertions(+), 8 deletions(-)
> >
> > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > index 865571d4579c..0574d22b3b25 100644
> > --- a/common/spl/Kconfig
> > +++ b/common/spl/Kconfig
> > @@ -855,6 +855,13 @@ config SPL_MMC_WRITE
> > help
> > Enable write access to MMC and SD Cards in SPL
> >
> > +config SPL_MMC_WARNINGS
> > + bool "Print MMC warnings"
> > + depends on SPL_MMC
> > + default y if !TARGET_SAMA5D2_XPLAINED
> > + help
> > + Print SPL MMC warnings. You can disable this option to reduce SPL
> > size.
> > +
> >
> > config SPL_MPC8XXX_INIT_DDR
> > bool "Support MPC8XXX DDR init"
> > diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> > index f7a42a11477d..ec424ceded0e 100644
> > --- a/common/spl/spl_mmc.c
> > +++ b/common/spl/spl_mmc.c
> > @@ -408,15 +408,45 @@ int default_spl_mmc_emmc_boot_partition(struct mmc
> > *mmc)
> > *
> > * Note: See difference between EXT_CSD_EXTRACT_PARTITION_ACCESS
> > * and EXT_CSD_EXTRACT_BOOT_PART, specially about User area value.
> > -*
> > -* FIXME: When booting from this eMMC device is explicitly
> > -* disabled then we use User area for booting. This is incorrect.
> > -* Probably we should skip this eMMC device and select the next
> > -* one for booting. Or at least throw warning about this fallback.
> > */
> > - part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
> > - if (part == 7)
> > - part = 0;
> > + if (mmc->part_config == MMCPART_NOAVAILABLE)
> > + part = 0; /* If partitions are not supported then we have only
> > User Area partition */
> > + else {
> > + switch(EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config)) {
> > + case 0: /* Booting from this eMMC device is disabled */
> > +#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> > +#ifdef CONFIG_SPL_MMC_WARNINGS
> > + puts("spl: WARNING: Booting from this eMMC device is
> > disabled in EXT_CSD[179] register\n");
> > + puts("spl: WARNING: Continuing anyway and selecting
> > User Area partition for booting\n");
> > +#else
> > + puts("spl: mmc: fallback to user area\n");
> > +#endif
> > +#endif
> > + /* FIXME: This is incorrect and probably we should
> > select next eMMC device for booting */
> > + part = 0;
> > + break;
> > + case 1: /* Boot partition 1 is used for booting */
> > + part = 1;
> > + break;
> > + case 2: /* Boot partition 2 is used for booting */
> > + part = 2;
> > + break;
> > + case 7: /* User area is used for booting */
> > + part = 0;
> > + break;
> > + default: /* Other values are reserved */
> > +#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> > +#ifdef CONFIG_SPL_MMC_WARNINGS
> > + puts("spl: WARNING: EXT_CSD[179] register is configured
> > to boot from Reserved value\n");
> > + puts("spl: WARNING: Selecting User Area partition for
> > booting\n");
> > +#else
> > + puts("spl: mmc: fallback to user area\n");
> > +#endif
> > +#endif
> > + part = 0;
> > + break;
> > + }
> > + }
> > #endif
>
> Please just use debug() for these messages.
>
> --
> Tom
All other error/warning messages in this file are printed via puts().
So I'm just following the current style (and I'm really not going to
change all occurrences in this patch).
Re: [PATCH v2 u-boot] mmc: spl: Make partition choice in default_spl_mmc_emmc_boot_partition() more explicit
On Thu, Jul 06, 2023 at 07:35:02PM +0200, Pali Rohár wrote:
> To make eMMC partition choosing in default_spl_mmc_emmc_boot_partition()
> function better understandable, rewrite it via explicit switch-case code
> pattern.
>
> Also add a warning when eMMC EXT_CSD[179] register is configured by user to
> value which is not suitable for eMMC booting and SPL do not know how to
> interpret it.
>
> Note that when booting from eMMC device via EXT_CSD[179] register is
> explicitly disabled then SPL still loads and boots from this eMMC device
> from User Area partition. This behavior was not changed in this commit and
> should be revisited in the future.
>
> Signed-off-by: Pali Rohár
> ---
> Changes in v2:
> * Disable showing warning on sama5d2_xplained due to size restrictions
> ---
> This patch depends on another patch:
> mmc: spl: Add comments for default_spl_mmc_emmc_boot_partition()
> https://patchwork.ozlabs.org/project/uboot/patch/20230404202805.8523-1-p...@kernel.org/
> ---
> common/spl/Kconfig | 7 +++
> common/spl/spl_mmc.c | 46
> 2 files changed, 45 insertions(+), 8 deletions(-)
>
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> index 865571d4579c..0574d22b3b25 100644
> --- a/common/spl/Kconfig
> +++ b/common/spl/Kconfig
> @@ -855,6 +855,13 @@ config SPL_MMC_WRITE
> help
> Enable write access to MMC and SD Cards in SPL
>
> +config SPL_MMC_WARNINGS
> + bool "Print MMC warnings"
> + depends on SPL_MMC
> + default y if !TARGET_SAMA5D2_XPLAINED
> + help
> + Print SPL MMC warnings. You can disable this option to reduce SPL
> size.
> +
>
> config SPL_MPC8XXX_INIT_DDR
> bool "Support MPC8XXX DDR init"
> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> index f7a42a11477d..ec424ceded0e 100644
> --- a/common/spl/spl_mmc.c
> +++ b/common/spl/spl_mmc.c
> @@ -408,15 +408,45 @@ int default_spl_mmc_emmc_boot_partition(struct mmc *mmc)
>*
>* Note: See difference between EXT_CSD_EXTRACT_PARTITION_ACCESS
>* and EXT_CSD_EXTRACT_BOOT_PART, specially about User area value.
> - *
> - * FIXME: When booting from this eMMC device is explicitly
> - * disabled then we use User area for booting. This is incorrect.
> - * Probably we should skip this eMMC device and select the next
> - * one for booting. Or at least throw warning about this fallback.
>*/
> - part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
> - if (part == 7)
> - part = 0;
> + if (mmc->part_config == MMCPART_NOAVAILABLE)
> + part = 0; /* If partitions are not supported then we have only
> User Area partition */
> + else {
> + switch(EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config)) {
> + case 0: /* Booting from this eMMC device is disabled */
> +#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> +#ifdef CONFIG_SPL_MMC_WARNINGS
> + puts("spl: WARNING: Booting from this eMMC device is
> disabled in EXT_CSD[179] register\n");
> + puts("spl: WARNING: Continuing anyway and selecting
> User Area partition for booting\n");
> +#else
> + puts("spl: mmc: fallback to user area\n");
> +#endif
> +#endif
> + /* FIXME: This is incorrect and probably we should
> select next eMMC device for booting */
> + part = 0;
> + break;
> + case 1: /* Boot partition 1 is used for booting */
> + part = 1;
> + break;
> + case 2: /* Boot partition 2 is used for booting */
> + part = 2;
> + break;
> + case 7: /* User area is used for booting */
> + part = 0;
> + break;
> + default: /* Other values are reserved */
> +#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> +#ifdef CONFIG_SPL_MMC_WARNINGS
> + puts("spl: WARNING: EXT_CSD[179] register is configured
> to boot from Reserved value\n");
> + puts("spl: WARNING: Selecting User Area partition for
> booting\n");
> +#else
> + puts("spl: mmc: fallback to user area\n");
> +#endif
> +#endif
> + part = 0;
> + break;
> + }
> + }
> #endif
Please just use debug() for these messages.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH u-boot 0/4] mmc: Explain and cleanup partition selection
On Thursday 06 July 2023 12:50:34 Pali Rohár wrote: > On Monday 03 July 2023 21:16:37 Jaehoon Chung wrote: > > Hi, > > > > On 4/14/23 06:10, Pali Rohár wrote: > > > Some people do not want to read review comments in emails. So put > > > comments and explanation into the source code itself; make emmc > > > partition selection code more explicit and validate configuration in > > > bubt command. > > > > Sorry for too late. > > After applied this patch-set, some board are failed with spl's size > > overflowed > > > > The below is one of failed log. > > > > +arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 352 bytes > > +make[2]: *** [scripts/Makefile.spl:527: spl/u-boot-spl] Error 1 > > +make[1]: *** [Makefile:2049: spl/u-boot-spl] Error 2 > > Crap, and again we have there same issue. Patch after months does not > apply anymore. And resending the patch would again result in the same > problem that it would not apply anymore after half of the year... Here is v2 patch with simple fix for that platform: https://patchwork.ozlabs.org/project/uboot/patch/20230706173502.2796-1-p...@kernel.org/ And it passed _now_ CI pipeline: https://github.com/u-boot/u-boot/pull/340 > > Anyway, only first patch is SPL specific, other should apply without any > problem. > > > > > Best Regards, > > Jaehoon Chung > > > > > > > > Pali Rohár (4): > > > mmc: spl: Make partition choice in > > > default_spl_mmc_emmc_boot_partition() more explicit > > > cmd: mvebu/bubt: Validate EXT_CSD[179] eMMC register in > > > mmc_burn_image() > > > sunxi: eMMC: Add comments explaining mapping between bootpart and > > > mmc_switch_part() > > > board: purism: Use U-Boot mmc function for converting boot part to > > > part access > > > > > > arch/arm/mach-sunxi/board.c| 12 ++- > > > board/purism/librem5/librem5.c | 6 +- > > > cmd/mvebu/bubt.c | 24 +++-- > > > common/spl/spl_mmc.c | 38 +++--- > > > 4 files changed, 64 insertions(+), 16 deletions(-) > >
[PATCH v2 u-boot] mmc: spl: Make partition choice in default_spl_mmc_emmc_boot_partition() more explicit
To make eMMC partition choosing in default_spl_mmc_emmc_boot_partition()
function better understandable, rewrite it via explicit switch-case code
pattern.
Also add a warning when eMMC EXT_CSD[179] register is configured by user to
value which is not suitable for eMMC booting and SPL do not know how to
interpret it.
Note that when booting from eMMC device via EXT_CSD[179] register is
explicitly disabled then SPL still loads and boots from this eMMC device
from User Area partition. This behavior was not changed in this commit and
should be revisited in the future.
Signed-off-by: Pali Rohár
---
Changes in v2:
* Disable showing warning on sama5d2_xplained due to size restrictions
---
This patch depends on another patch:
mmc: spl: Add comments for default_spl_mmc_emmc_boot_partition()
https://patchwork.ozlabs.org/project/uboot/patch/20230404202805.8523-1-p...@kernel.org/
---
common/spl/Kconfig | 7 +++
common/spl/spl_mmc.c | 46
2 files changed, 45 insertions(+), 8 deletions(-)
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 865571d4579c..0574d22b3b25 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -855,6 +855,13 @@ config SPL_MMC_WRITE
help
Enable write access to MMC and SD Cards in SPL
+config SPL_MMC_WARNINGS
+ bool "Print MMC warnings"
+ depends on SPL_MMC
+ default y if !TARGET_SAMA5D2_XPLAINED
+ help
+ Print SPL MMC warnings. You can disable this option to reduce SPL
size.
+
config SPL_MPC8XXX_INIT_DDR
bool "Support MPC8XXX DDR init"
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index f7a42a11477d..ec424ceded0e 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -408,15 +408,45 @@ int default_spl_mmc_emmc_boot_partition(struct mmc *mmc)
*
* Note: See difference between EXT_CSD_EXTRACT_PARTITION_ACCESS
* and EXT_CSD_EXTRACT_BOOT_PART, specially about User area value.
-*
-* FIXME: When booting from this eMMC device is explicitly
-* disabled then we use User area for booting. This is incorrect.
-* Probably we should skip this eMMC device and select the next
-* one for booting. Or at least throw warning about this fallback.
*/
- part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
- if (part == 7)
- part = 0;
+ if (mmc->part_config == MMCPART_NOAVAILABLE)
+ part = 0; /* If partitions are not supported then we have only
User Area partition */
+ else {
+ switch(EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config)) {
+ case 0: /* Booting from this eMMC device is disabled */
+#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
+#ifdef CONFIG_SPL_MMC_WARNINGS
+ puts("spl: WARNING: Booting from this eMMC device is
disabled in EXT_CSD[179] register\n");
+ puts("spl: WARNING: Continuing anyway and selecting
User Area partition for booting\n");
+#else
+ puts("spl: mmc: fallback to user area\n");
+#endif
+#endif
+ /* FIXME: This is incorrect and probably we should
select next eMMC device for booting */
+ part = 0;
+ break;
+ case 1: /* Boot partition 1 is used for booting */
+ part = 1;
+ break;
+ case 2: /* Boot partition 2 is used for booting */
+ part = 2;
+ break;
+ case 7: /* User area is used for booting */
+ part = 0;
+ break;
+ default: /* Other values are reserved */
+#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
+#ifdef CONFIG_SPL_MMC_WARNINGS
+ puts("spl: WARNING: EXT_CSD[179] register is configured
to boot from Reserved value\n");
+ puts("spl: WARNING: Selecting User Area partition for
booting\n");
+#else
+ puts("spl: mmc: fallback to user area\n");
+#endif
+#endif
+ part = 0;
+ break;
+ }
+ }
#endif
return part;
}
--
2.20.1
Re: [PATCH] lib: sparse: allocate blkcnt instead of arbitrary small number
On Thu, Jul 06, 2023 at 11:43:13AM +0200, Mattijs Korpershoek wrote:
> On lun., juin 19, 2023 at 10:21, Mattijs Korpershoek
> wrote:
>
> > Hi Qianfan,
> >
> > Thank you for your review.
> >
> > On lun., juin 19, 2023 at 14:19, qianfan wrote:
> >
> >> 在 2023/6/16 21:26, Mattijs Korpershoek 写道:
> >>> Commit 62649165cb02 ("lib: sparse: Make CHUNK_TYPE_RAW buffer aligned")
> >>> fixed cache alignment for systems with a D-CACHE.
> >>>
> >>> However it introduced some performance regressions [1] on system
> >>> flashing huge images, such as Android.
> >>>
> >>> On AM62x SK EVM, we also observe such performance penalty:
> >>> Sending sparse 'super' 1/2 (768793 KB) OKAY [ 23.954s]
> >>> Writing 'super'OKAY [ 75.926s]
> >>> Sending sparse 'super' 2/2 (629819 KB) OKAY [ 19.641s]
> >>> Writing 'super'OKAY [ 62.849s]
> >>> Finished. Total time: 182.474s
> >>>
> >>> The reason for this is that we use an arbitrary small buffer
> >>> (info->blksz * 100) for transferring.
> >>>
> >>> Fix it by using a bigger buffer (info->blksz * blkcnt) as suggested in
> >>> the original's patch review [2].
> >>>
> >>> With this patch, performance impact is mitigated:
> >>> Sending sparse 'super' 1/2 (768793 KB) OKAY [ 24.006s]
> >>> Writing 'super'OKAY [ 15.920s]
> >>> Sending sparse 'super' 2/2 (629819 KB) OKAY [ 19.651s]
> >>> Writing 'super'OKAY [ 14.665s]
> >>> Finished. Total time: 74.346s
> >>>
> >>> [1]
> >>> https://lore.kernel.org/r/20221118121323.4009193-1-gary.bis...@boundarydevices.com
> >>> [2]
> >>> https://lore.kernel.org/r/all/43e4c17c-4483-ec8e-f843-9b4c5569b...@seco.com/
> >>>
> >>> Fixes: 62649165cb02 ("lib: sparse: Make CHUNK_TYPE_RAW buffer aligned")
> >>> Signed-off-by: Mattijs Korpershoek
> >>> ---
> >>> lib/image-sparse.c | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/lib/image-sparse.c b/lib/image-sparse.c
> >>> index 5ec0f94ab3eb..25aed0604192 100644
> >>> --- a/lib/image-sparse.c
> >>> +++ b/lib/image-sparse.c
> >>> @@ -55,7 +55,7 @@ static lbaint_t write_sparse_chunk_raw(struct
> >>> sparse_storage *info,
> >>>void *data,
> >>>char *response)
> >>> {
> >>> - lbaint_t n = blkcnt, write_blks, blks = 0, aligned_buf_blks = 100;
> >>> + lbaint_t n = blkcnt, write_blks, blks = 0, aligned_buf_blks = blkcnt;
> >> Hi:
> >>
> >> It's a good point that this code report the performance was affected by
> >> write large small
> >> mmc blks, not memory copy.
> >
> > I believe memory copy also affects performance, but in my case,
> > it has less impact than small mmc blks.
> >
> > With 62649165cb02 reverted:
> > Sending sparse 'super' 1/2 (768793 KB) OKAY [ 23.947s]
> > Writing 'super'OKAY [ 12.983s]
> > Sending sparse 'super' 2/2 (629819 KB) OKAY [ 19.600s]
> > Writing 'super'OKAY [ 12.796s]
> > Finished. Total time: 69.430s
> >
> > With aligned_buf_blks = blkcnt:
> > Sending sparse 'super' 1/2 (768793 KB) OKAY [ 24.072s]
> > Writing 'super'OKAY [ 16.177s]
> > Sending sparse 'super' 2/2 (629819 KB) OKAY [ 19.681s]
> > Writing 'super'OKAY [ 14.845s]
> > Finished. Total time: 74.919s
> >
> >>
> >> And I can not make sure whether memalign can always alloc such huge
> >> memory when we change the
> >> aligned_buf_blks to blkcnt.
> >
> > Could you clarify the concern here? I've dumped blkcnt for my board
> > (AM62x SK EVK) and the biggest blkcnt I found was: 131072
> >
> > With info->blksz = 512, this gives me: 512 * 131072 = 67108864
> >
> > Which is a memalign (memory alloc) of 64MB. Is 64MB really that big? (I
> > don't realize it's that much)
> >
> >>
> >> Could you please set aligned_buf_blks to FASTBOOT_MAX_BLK_WRITE(16384)
> >> and test again?
> >
> > With aligned_buf_blks = FASTBOOT_MAX_BLK_WRITE(16384):
> > Sending sparse 'super' 1/2 (768793 KB) OKAY [ 23.912s]
> > Writing 'super'OKAY [ 15.780s]
> > Sending sparse 'super' 2/2 (629819 KB) OKAY [ 19.581s]
> > Writing 'super'OKAY [ 17.192s]
> > Finished. Total time: 76.569s
> >
> > So using FASTBOOT_MAX_BLK_WRITE is slightly worse than using blkcnt.
> > But allocations (for blksz = 512) are smaller: 8MB instead of 64MB in my
> > example.
> >
> > I can spin up a v2 with FASTBOOT_MAX_BLK_WRITE but i'm waiting a little
> > more feedback before doing so.
>
> Hi Marek, Tom,
>
> What's your take on this ? Can we keep blkcnt or should I respin using
> FASTBOOT_MAX_BLK_WRITE ?
>
> I have also tested this on VIM3, on
> U-Boot 2023.07-rc6-3-g923de765ee1a:
>
> Sending sparse 'super'
[PATCH 10/10] arm: dts: keystone-k2e-evm-u-boot: Remove usb1 mode configuration
USB1 dual-role feature is already handled as peripheral only
in dwc3-generic driver.
Signed-off-by: Julien Panis
---
arch/arm/dts/keystone-k2e-evm-u-boot.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/keystone-k2e-evm-u-boot.dtsi
b/arch/arm/dts/keystone-k2e-evm-u-boot.dtsi
index 970d452f0804..a75f78377c28 100644
--- a/arch/arm/dts/keystone-k2e-evm-u-boot.dtsi
+++ b/arch/arm/dts/keystone-k2e-evm-u-boot.dtsi
@@ -39,7 +39,6 @@
{
dwc3@2501 {
phys = <_phy>;
- dr_mode = "peripheral";
snps,u2ss_inp3_quirk;
status = "okay";
};
--
2.37.3
[PATCH 09/10] arm: dts: k3-j721e-common-proc-board-u-boot: Remove usb0 mode configuration
USB0 dual-role feature is already handled as peripheral only
in dwc3-generic driver.
Signed-off-by: Julien Panis
---
arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
index 867ec2bb1aff..d14f3346caf7 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
@@ -143,7 +143,6 @@
};
{
- dr_mode = "peripheral";
bootph-pre-ram;
};
--
2.37.3
[PATCH 08/10] arm: dts: k3-j7200-common-proc-board-u-boot: Remove usb0 mode configuration
USB0 dual-role feature is already handled as peripheral only
in dwc3-generic driver.
Signed-off-by: Julien Panis
---
arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
index f57c2306ba1a..dbe22fc3a459 100644
--- a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
@@ -157,7 +157,6 @@
};
{
- dr_mode = "peripheral";
bootph-pre-ram;
};
--
2.37.3
[PATCH 07/10] arm: dts: k3-am654-r5-base-board-u-boot: Remove usb mode configuration
USB0 and USB1 dual-role feature is already handled
as peripheral only in dwc3-generic driver.
Signed-off-by: Julien Panis
---
arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi
b/arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi
index 4516ab1437e7..3ccd42985fd8 100644
--- a/arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi
@@ -169,10 +169,6 @@
bootph-pre-ram;
};
- {
- dr_mode = "peripheral";
-};
-
{
bootph-pre-ram;
};
@@ -198,7 +194,6 @@
{
pinctrl-names = "default";
pinctrl-0 = <_pins_default>;
- dr_mode = "peripheral";
bootph-pre-ram;
};
--
2.37.3
[PATCH 06/10] arm: dts: k3-am642-evm-u-boot: Remove usb0 mode configuration
USB0 dual-role feature is already handled as peripheral only
in dwc3-generic driver.
Signed-off-by: Julien Panis
---
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
index 64857b09099d..f3f0d07df49f 100644
--- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
@@ -56,7 +56,6 @@
};
{
- dr_mode="peripheral";
bootph-pre-ram;
};
--
2.37.3
[PATCH 05/10] arm: dts: dra76-evm-u-boot: Remove usb1 mode configuration
USB1 dual-role feature is already handled as peripheral only
in dwc3-generic driver.
Signed-off-by: Julien Panis
---
arch/arm/dts/dra76-evm-u-boot.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/dra76-evm-u-boot.dtsi
b/arch/arm/dts/dra76-evm-u-boot.dtsi
index 1216d93bdcd6..47a92e214d27 100644
--- a/arch/arm/dts/dra76-evm-u-boot.dtsi
+++ b/arch/arm/dts/dra76-evm-u-boot.dtsi
@@ -31,7 +31,6 @@
{
bootph-pre-ram;
- dr_mode = "peripheral";
};
_phy1 {
--
2.37.3
[PATCH 04/10] arm: dts: dra72-evm-u-boot: Remove usb1 mode configuration
USB1 dual-role feature is already handled as peripheral only
in dwc3-generic driver.
Signed-off-by: Julien Panis
---
arch/arm/dts/dra72-evm-u-boot.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/dra72-evm-u-boot.dtsi
b/arch/arm/dts/dra72-evm-u-boot.dtsi
index 91a3b6b742a0..18350ed08909 100644
--- a/arch/arm/dts/dra72-evm-u-boot.dtsi
+++ b/arch/arm/dts/dra72-evm-u-boot.dtsi
@@ -11,7 +11,6 @@
{
bootph-pre-ram;
- dr_mode = "peripheral";
};
_phy1 {
--
2.37.3
[PATCH 03/10] arm: dts: dra72-evm-revc-u-boot: Remove usb1 mode configuration
USB1 dual-role feature is already handled as peripheral only
in dwc3-generic driver.
Signed-off-by: Julien Panis
---
arch/arm/dts/dra72-evm-revc-u-boot.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/dra72-evm-revc-u-boot.dtsi
b/arch/arm/dts/dra72-evm-revc-u-boot.dtsi
index 8e7dc719bf85..48a194c941d7 100644
--- a/arch/arm/dts/dra72-evm-revc-u-boot.dtsi
+++ b/arch/arm/dts/dra72-evm-revc-u-boot.dtsi
@@ -51,7 +51,6 @@
{
bootph-pre-ram;
- dr_mode = "peripheral";
};
_phy1 {
--
2.37.3
[PATCH 02/10] arm: dts: dra71-evm-u-boot: Remove usb1 mode configuration
USB1 dual-role feature is already handled as peripheral only
in dwc3-generic driver.
Signed-off-by: Julien Panis
---
arch/arm/dts/dra71-evm-u-boot.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/dra71-evm-u-boot.dtsi
b/arch/arm/dts/dra71-evm-u-boot.dtsi
index 8e7dc719bf85..48a194c941d7 100644
--- a/arch/arm/dts/dra71-evm-u-boot.dtsi
+++ b/arch/arm/dts/dra71-evm-u-boot.dtsi
@@ -51,7 +51,6 @@
{
bootph-pre-ram;
- dr_mode = "peripheral";
};
_phy1 {
--
2.37.3
[PATCH 01/10] arm: dts: dra7-evm-u-boot: Remove usb1 mode configuration
USB1 dual-role feature is already handled as peripheral only
in dwc3-generic driver.
Signed-off-by: Julien Panis
---
arch/arm/dts/dra7-evm-u-boot.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/dra7-evm-u-boot.dtsi
b/arch/arm/dts/dra7-evm-u-boot.dtsi
index 87b2451a8e8b..f6fd21f2c660 100644
--- a/arch/arm/dts/dra7-evm-u-boot.dtsi
+++ b/arch/arm/dts/dra7-evm-u-boot.dtsi
@@ -39,7 +39,6 @@
{
bootph-pre-ram;
- dr_mode = "peripheral";
};
_phy1 {
--
2.37.3
[PATCH 00/10] Remove unnecessary USBx dr_mode configuration.
For all TI platforms handled in this series, USBx dr_mode
was configured as peripheral in '-u-boot.dtsi'.
This series removes these fragments, since USBx dual-role
feature is already handled as peripheral only in
'dwc3_glue_bind_common()' function of 'dwc3-generic.c' driver:
static int dwc3_glue_bind_common(struct udevice *parent, ofnode node)
{
[...]
switch (dr_mode) {
case USB_DR_MODE_PERIPHERAL:
case USB_DR_MODE_OTG:
debug("%s: dr_mode: OTG or Peripheral\n", __func__);
driver = "dwc3-generic-peripheral";
break;
[...]
}
This follows a discussion about a similar topic for am3 boards:
https://lore.kernel.org/u-boot/20230621-fix_usb_ether_init-v4-0-5f4977bb7...@baylibre.com/
Signed-off-by: Julien Panis
---
Julien Panis (10):
arm: dts: dra7-evm-u-boot: Remove usb1 mode configuration
arm: dts: dra71-evm-u-boot: Remove usb1 mode configuration
arm: dts: dra72-evm-revc-u-boot: Remove usb1 mode configuration
arm: dts: dra72-evm-u-boot: Remove usb1 mode configuration
arm: dts: dra76-evm-u-boot: Remove usb1 mode configuration
arm: dts: k3-am642-evm-u-boot: Remove usb0 mode configuration
arm: dts: k3-am654-r5-base-board-u-boot: Remove usb mode configuration
arm: dts: k3-j7200-common-proc-board-u-boot: Remove usb0 mode
configuration
arm: dts: k3-j721e-common-proc-board-u-boot: Remove usb0 mode
configuration
arm: dts: keystone-k2e-evm-u-boot: Remove usb1 mode configuration
arch/arm/dts/dra7-evm-u-boot.dtsi | 1 -
arch/arm/dts/dra71-evm-u-boot.dtsi | 1 -
arch/arm/dts/dra72-evm-revc-u-boot.dtsi | 1 -
arch/arm/dts/dra72-evm-u-boot.dtsi | 1 -
arch/arm/dts/dra76-evm-u-boot.dtsi | 1 -
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 1 -
arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi | 5 -
arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi | 1 -
arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi | 1 -
arch/arm/dts/keystone-k2e-evm-u-boot.dtsi | 1 -
10 files changed, 14 deletions(-)
---
base-commit: 19b77d3d23966a0d6dbb3c86187765f11100fb6f
change-id: 20230706-handle-otg-as-periph-4546e874cd15
Best regards,
--
Julien Panis
Re: [PATCH v1 1/2] drivers: firmware: introduce Meson Secure Monitor driver
Hi Alexey, On Thu, 6 Jul 2023 at 14:16, Alexey Romanov wrote: > > At the moment, only smc API is a set of functions in > arch/arm/mach-meson/sm.c. This approach is hard to configure > and also doesn't contain any generic API for calling smc. > > This patch add Meson SM driver with generic API (struct meson_sm_ops): > > - sm_call() > - sm_call_write() > - sm_call_read() > > A typical driver usage example is shown here: > > 1. uclass_get_device_by_driver(UCLASS_FIRMWARE, "secure-monitor", ); > 2. handle = meson_sm_get_handle(dev); > 3. handle->ops.sm_call(dev, cmd, ...); > > Signed-off-by: Alexey Romanov > --- > arch/arm/mach-meson/Kconfig | 1 + > drivers/firmware/Kconfig | 10 ++ > drivers/firmware/Makefile | 1 + > drivers/firmware/meson/Kconfig| 6 + > drivers/firmware/meson/Makefile | 3 + > drivers/firmware/meson/meson_sm.c | 217 ++ > include/meson/sm_handle.h | 38 ++ > 7 files changed, 276 insertions(+) > create mode 100644 drivers/firmware/meson/Kconfig > create mode 100644 drivers/firmware/meson/Makefile > create mode 100644 drivers/firmware/meson/meson_sm.c > create mode 100644 include/meson/sm_handle.h Please can you use the remoteproc uclass for this and add a proper driver? Regards, SImon
Re: [PATCH] tpm: Add TPM2_GetTestResult command support
Hi Julia,
On Wed, 5 Jul 2023 at 00:55, Julia Daxenberger
wrote:
>
> Hi Simon,
>
> On Mon, 3 Jul 2023 at 15:31, Simon Glass wrote:
> >
> > Hi Julia,
> >
> > On Mon, 3 Jul 2023 at 14:03, Julia Daxenberger
> > wrote:
> > >
> > > Add TPM2_GetTestResult command support and change the command file and the
> > > help accordingly. Add Python tests and sandbox driver functionality.
> > >
> > > The TPM2_GetTestResult command is performed after the TPM2_SelfTest
> > > command
> > > and returns manufacturer-specific information regarding the results of the
> > > self-test and an indication of the test status.
> > >
> > > Signed-off-by: Julia Daxenberger
> > > ---
> > > cmd/tpm-v2.c | 60 +
> > > drivers/tpm/tpm2_tis_sandbox.c | 47 ++-
> > > include/tpm-v2.h | 23 ++
> > > lib/tpm-v2.c | 82 ++
> > > test/py/tests/test_tpm2.py | 50 +
> > > 5 files changed, 261 insertions(+), 1 deletion(-)
> > >
> >
> > Reviewed-by: Simon Glass
> >
> >
> > See below
> >
> > [..]
> >
> > > diff --git a/test/py/tests/test_tpm2.py b/test/py/tests/test_tpm2.py
> > > index d2ad6f9e73..aad1d7a55b 100644
> > > --- a/test/py/tests/test_tpm2.py
> > > +++ b/test/py/tests/test_tpm2.py
> > > @@ -1,6 +1,7 @@
> > > # SPDX-License-Identifier: GPL-2.0+
> > > # Copyright (c) 2018, Bootlin
> > > # Author: Miquel Raynal
> > > +# Copyright (C) 2023 Infineon Technologies AG
> > >
> > > import os.path
> > > import pytest
> > > @@ -316,3 +317,52 @@ def test_tpm2_cleanup(u_boot_console):
> > > """Ensure the TPM is cleared from password or test related
> > > configuration."""
> > >
> > > force_init(u_boot_console, True)
> > > +
> > > +@pytest.mark.buildconfigspec('cmd_tpm_v2')
> > > +def test_tpm2_get_test_result(u_boot_console):
> > > +"""Execute a TPM_GetTestResult command.
> > > +
> > > +Ask the TPM to get the test result of the self test.
> > > +Display the Test Result and Test Result Data.
> > > +
> > > +Expected default return value of tpm2_get_test_result, if the TPM
> > > has not been initialized:
> > > +- TPM2_RC_INITIALIZE = TPM2_RC_VER1 + 0x = 0x0100.
> > > +
> > > +Expected default value for test_result:
> > > +- TPM_RC_NEEDS_TEST = 0x0153, if tpm2 self_test has not been
> > > executed.
> > > +- TPM_RC_SUCCESS = 0x, if testing is complete without
> > > functional failures.
> > > +
> > > +There is no expected default value for the test result data because
> > > it would depend on the chip
> > > +used. The test result data is therefore not tested.
> > > +"""
> > > +if is_sandbox(u_boot_console):
> > > +u_boot_console.restart_uboot()
> >
> > We should get rid of this somehow. We don't want sandbox rebooting
> > inthe middle of a test. It makes debugging painful, apart from
> > anything else. What TPM state needs to be reset?
> >
> > Looking at tpm2_tis_sandbox.c it is probably the s_state variable. The
> > TPM state can be preserved across runs and is stored in the state
> > file.
> >
> > But if the state file is not being used (no -s argument) then the TPM
> > should be reset each time DM is brought back up, i.e. between every
> > test.
> >
> > So, do we even need this reset?
> >
> > Regards,
> > Simon
>
> In my understanding, shutting down and restarting U-Boot with
> restart_uboot() at the beginning of a test is beneficial, as it puts
> sandbox back into a known state for the test. This allows all tests to
> run in parallel, since no test depends on another.
Actually with sandbox, we just restart the driver model each time. You
can see this logic in test-main.c
>
> In the test_tpm2_get_test_result test specifically, the reset is needed
> to test the behaviour of the do_tpm2_get_test_result() function, when
> the tpm has not already been initialized and the TPM self_test has not
> been executed. Performing restart_uboot() is essential to test for error
> code output, as sandbox always returns "TPM2_RC_SUCCESS" when the
> restart is not performed, making the test fail.
>
> restart_uboot() is performed at the beginning of all tests in
> test_tpm2.py, either on its own, or as part of the tpm2_sandbox_init()
> command.
Yes, we should fix this. No other subsystem has this problem. I am
wondering what is actually going on? The tpm must be keeping state
outside of driver model. Perhaps we just need to call a TPM function
to clear that state, in state_reset_for_test().
Regards,
Simon
Re: [PATCHv3 3/3] net/lwip: add doc/develop/net_lwip.rst
Hi Maxim, On Wed, 5 Jul 2023 at 09:17, Maxim Uvarov wrote: > > Just add inital doc. > > Signed-off-by: Maxim Uvarov > --- > doc/develop/index.rst| 1 + > doc/develop/net_lwip.rst | 59 > 2 files changed, 60 insertions(+) > create mode 100644 doc/develop/net_lwip.rst > > diff --git a/doc/develop/index.rst b/doc/develop/index.rst > index 97c526e997..a092c33df0 100644 > --- a/doc/develop/index.rst > +++ b/doc/develop/index.rst > @@ -43,6 +43,7 @@ Implementation > smbios > spl > uefi/index > + net_lwip > vbe > version > > diff --git a/doc/develop/net_lwip.rst b/doc/develop/net_lwip.rst > new file mode 100644 > index 00..2520fe11b1 > --- /dev/null > +++ b/doc/develop/net_lwip.rst > @@ -0,0 +1,59 @@ > +.. SPDX-License-Identifier: GPL-2.0+ > + > +LWIP IP stack intergation for U-boot U-Boot > + > + > +Intro > +- > + > +LWIP is a library for implementation network protocols, which is commonly > used > +on embedded devices. > + > +https://savannah.nongnu.org/projects/lwip/ > + > +LwIP license: > +LwIP is licensed under a BSD-style license: > http://lwip.wikia.com/wiki/License. > + > +Main features include: > + > +* Protocols: IP, IPv6, ICMP, ND, MLD, UDP, TCP, IGMP, ARP, PPPoS, PPPoE > + > +* DHCP client, DNS client (incl. mDNS hostname resolver), AutoIP/APIPA > (Zeroconf), SNMP agent (v1, v2c, v3, private MIB support & MIB compiler) > + > +* APIs: specialized APIs for enhanced performance, optional Berkeley-alike > socket API > + > +* Extended features: IP forwarding over multiple network interfaces, TCP > congestion control, RTT estimation and fast recovery/fast retransmit > + > +* Addon applications: HTTP(S) server, SNTP client, SMTP(S) client, ping, > NetBIOS nameserver, mDNS responder, MQTT client, TFTP server > + > +U-boot implementation details > +- > + > +1. In general we can build lwIP as .a library and link it against u-boot or > compile it in > +the U-boot tree in the same way as other U-boot files. There are few reasons > why I selected > +the second variant: LwIP is very customizable with defines for features, > memory size, types of > +allocation, some internal types and platform specific code. And it was more > easy to enable/disable > +debug which is also done with defines, and is needed periodically. > + > +2. lwIP has 2 APIs - raw mode and sequential (as lwIP names it, or socket > API as we name it in Linux). > +For now only raw API is supported. > + > +Raw IP means that the call back function for RX path is registered and will > be called when packet > +data passes the IP stack and is ready for the application. > + > +Example is unmodified working ping example from lwip sources which > registeres the callback: > + > +.. code-block:: c > + > +ping_pcb = raw_new(IP_PROTO_ICMP); > +raw_recv(ping_pcb, ping_recv, NULL); <- ping_recv is app callback. > +raw_bind(ping_pcb, IP_ADDR_ANY) > + > +Socket API also gives nice advantages due it will be easy to port linux > socket applications to u-boot. > +I.e. LwIP sockets compatible with the linux ones. But that will require RX > thread running in the background. > +So that means we need some kind of scheduler, locking and threading support > or find some other solution. > + > +3. Input and output > + > +RX packet path is injected to U-boot eth_rx() polling loop and TX patch is > in eth_send() accordingly. > +So we do not touch any drivers code and just eat packets when they are ready. > -- > 2.30.2 > Regards, SImon
Re: [PATCH v2] fpga: add inline stub for fpga_load
Hi Eugen,
On Wed, 5 Jul 2023 at 07:05, Eugen Hristev wrote:
>
> In case CC_OPTIMIZE_FOR_DEBUG is set, unused code will not be optimized out,
> hence the reference to fpga_load will be compiled.
> if DM_FPGA and SPL_FPGA are not set, the build will fail with :
>
> aarch64-none-linux-gnu-ld.bfd: common/spl/spl_fit.o: in function
> `spl_fit_upload_fpga':
> u-boot/common/spl/spl_fit.c:595: undefined reference to `fpga_load'
>
> To solve this, added an inline empty stub in the header if
> CC_OPTIMIZE_FOR_DEBUG is set such that the build will succeed.
>
> Signed-off-by: Eugen Hristev
> ---
> Changes in v2:
> - this is a rework as suggested by Simon of this previous patch :
> https://patchwork.ozlabs.org/project/uboot/patch/20230619102839.277902-1-eugen.hris...@collabora.com/
>
> include/fpga.h | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/include/fpga.h b/include/fpga.h
> index ed688cc0fa3b..50ab03af06bb 100644
> --- a/include/fpga.h
> +++ b/include/fpga.h
> @@ -60,8 +60,17 @@ int fpga_add(fpga_type devtype, void *desc);
> int fpga_count(void);
> const fpga_desc *const fpga_get_desc(int devnum);
> int fpga_is_partial_data(int devnum, size_t img_len);
> +#if defined(CONFIG_CC_OPTIMIZE_FOR_DEBUG)
> +static inline int fpga_load(int devnum, const void *buf, size_t bsize,
> + bitstream_type bstype, int flags)
> +{
> + return 0;
It should return -ENOSYS, right?
> +}
> +#else
> int fpga_load(int devnum, const void *buf, size_t bsize,
> bitstream_type bstype, int flags);
> +#endif
> +
> int fpga_fsload(int devnum, const void *buf, size_t size,
> fpga_fs_info *fpga_fsinfo);
> int fpga_loads(int devnum, const void *buf, size_t size,
> --
> 2.34.1
>
Regards,
SImon
Re: [PATCHv3 1/3] net/lwip: add lwip-external submodule
Hi Maxim, On Wed, 5 Jul 2023 at 09:16, Maxim Uvarov wrote: > > This commit adds the lwip library as a git submodule. I think > there has to be advantages to compile lwip inside U-boot, > i.e. use the same compiler and flags as the main code. > One of them is LTO and the other is to enable additional debug > options for network protocol during development. Also we can > copy lwip library code inside U-boot, but for now I don't want > to send all lwip code to the mailing list. So it's git submodule. That's fine for now, but at some point, we should apply it as patches if we are moving to lwip. Regards, Simon
Re: [PATCH] lzma: Fix decompression speed regression
On Wed, 5 Jul 2023 at 09:54, Christophe Leroy
wrote:
>
> Uncompressing a 1.7Mbytes FIT image on U-boot 2023.04 takes
> approx 7s on a powerpc 8xx.
> The same on U-boot 2023.07-rc6 takes approx 28s unless watchdog
> is disabled.
>
> During that decompression, LzmaDec_DecodeReal() calls schedule
> 1.6 million times, that is every 4µs in average.
>
> In the past it used to be a call to WATCHDOG_RESET() which was
> just calling hw_watchdog_reset().
>
> But the combination of commit 29caf9305b6 ("cyclic: Use schedule()
> instead of WATCHDOG_RESET()") and commit 26e8ebcd7cb ("watchdog:
> mpc8xxx: Make it generic") results in an heavier processing.
>
> However, there is absolutely no point in calling schedule() that
> often.
>
> By moving and keeping only one call to schedule() in the main
> loop the number of calls is reduced to 1.2 million which is still
> too much. So add logic to only call schedule every 1024 times.
> That leads to a call to schedule approx every 6ms which is still
> far enough to entertain the watchdog which has a 1s timeout on
> powerpc 8xx.
>
> powerpc 8xx being one of the slowest targets we have today in
> U-boot, and most other watchdogs having a timeout of one minutes
> instead of one second like the 8xx, this fix should not have
> negative impact on other targets.
>
> Fixes: 29caf9305b6 ("cyclic: Use schedule() instead of WATCHDOG_RESET()")
> Signed-off-by: Christophe Leroy
> ---
> lib/lzma/LzmaDec.c | 18 --
> 1 file changed, 4 insertions(+), 14 deletions(-)
Reviewed-by: Simon Glass
+Stefan Roese I wonder if we need a more general fix?
Re: EFI Secure boot default keys
On 06.07.23 11:25, AKASHI Takahiro wrote:
On Thu, Jul 06, 2023 at 08:23:06AM +, Neil Jones wrote:
Please can someone describe the format of the file needed for the default /
built-in EFI secure boot keys (ubootefi.var)
The only docs I have found suggest its best to enroll the keys from within
u-boot onto some removable media, then copy this off and use this as the
default, this is not very helpful and doesn't work for me:
=> fatload mmc 0:1 ${loadaddr} PK.aut
2053 bytes read in 18 ms (111.3 KiB/s)
=> setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize PK
setenv - set environment variables
Usage:
setenv setenv [-f] name value ...
- [forcibly] set environment variable 'name' to 'value ...'
setenv [-f] name
- [forcibly] delete environment variable 'name'
my setenv doesn't support all the extra switches ? This is with 2022.04, all
other EFI options seem to be in this release and I can boot unsigned EFI images
ok.
Please turn on CONFIG_CMD_NVEDIT_EFI when building your U-Boot.
This option was disabled by the commit:
commit 3b728f8728fa (tag: efi-2020-01-rc1)
Author: Heinrich Schuchardt
Date: Sun Oct 6 15:44:22 2019 +0200
cmd: disable CMD_NVEDIT_EFI by default
The binary size of efi has grown much since in the past, though.
-Takahiro Akashi
Thanks, I have secure boot working now. A tool to generate the ubootefi.var
offline or even just a description of the file format would be very useful.
Thank you for the suggestion. While I'd like to defer to Heinrich,
the C definition of the file format can be found as struct efi_var_file
in include/efi_variable.h
Thanks!
I have noticed one issue when using ubootefi.var on mmc, when I switch boot
order it wipes out the keys and I have to re-enrol them:
=> fatls mmc 0:1
3040 ubootefi.var
1 file(s), 0 dir(s)
I'm not sure that secure boot related variables have been loaded
at this point.
This is during initial generation / enrollment of the variables
Hello Neil,
If you want to use secure boot, please either use
CONFIG_EFI_VARIABLES_PRESEED or CONFIG_EFI_MM_COMM_TEE.
U-Boot will never load the security database from file.
Without CONFIG_EFI_MM_COMM_TEE=y setting up the security database via
setenv -e is only usable for one time testing. After reboot the security
database will be gone (or fallback to the preseed for
CONFIG_EFI_VARIABLES_PRESEED=y).
Best regards
Heinrich
Anyhow, please try to enable CONFIG_EFI_VARIABLES_PRESEED with
EFI_VAR_FILE_NAME set. Otherwise, those variables will never be
restored.
(This is another topic that are not described in doc/develop/uefi.)
I have CONFIG_EFI_VARIABLES_PRESEED working, but while generating the file
ubootefi.var for the first time (without CONFIG_EFI_VARIABLES_PRESEED set) you
have to follow a specific order, or the file gets overwritten eg:
Working:
efidebug boot order 1 2
efidebug boot add -b 1 Signed mmc 0:1 /ImageSig.efi
efidebug boot add -b 2 UnSigned mmc 0:1 /Image
fatload mmc 0:1 ${loadaddr} PK.aut
setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize PK
fatload mmc 0:1 ${loadaddr} KEK.aut
setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize KEK
fatload mmc 0:1 ${loadaddr} DB.aut
setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize db
Failing:
setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize PK
fatload mmc 0:1 ${loadaddr} KEK.aut
setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize KEK
fatload mmc 0:1 ${loadaddr} DB.aut
setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize db
efidebug boot order 1 2 ### This command overwrites the keys just loaded
Are you sure that "env print -e" shows all the variables including
PK, KEK and db at this point?
Since I don't have enough time to examine this issue, can you please
try to trace efi_var_collect() in efi_var_file.c which is responsible
for enumerating all the non-volatile variables to be saved at each
SET_VARIABLE api call?
-Takahiro Akashi
Cheers,
Neil
Thanks,
-Takahiro Akashi
=> efidebug boot order 2 1
=> fatls mmc 0:1
440 ubootefi.var
(Size drops from 3040 to 440 bytes and keys have gone)
From: AKASHI Takahiro
Sent: 29 June 2023 02:01
To: Neil Jones
Cc: u-boot@lists.denx.de
Subject: Re: EFI Secure boot default keys
On Wed, Jun 28, 2023 at 04:26:58PM +, Neil Jones wrote:
Please can someone describe the format of the file needed for the default /
built-in EFI secure boot keys (ubootefi.var)
The only docs I have found suggest its best to enroll the keys from within
u-boot onto some removable media, then copy this off and use this as the
default, this is not very helpful and doesn't work for me:
=> fatload mmc 0:1 ${loadaddr} PK.aut
2053 bytes read in 18 ms (111.3 KiB/s)
=> setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize PK
setenv - set environment variables
Usage:
setenv setenv [-f] name value ...
- [forcibly] set environment variable 'name' to 'value ...'
setenv [-f] name
-
Re: [PATCH 3/6] arm: dts: k3-am642: Sync main_i2c0 with kernel
On 17:13-20230706, Roger Quadros wrote:
> Hi Nishanth,
>
> On 06/07/2023 15:38, Nishanth Menon wrote:
> > On 21:10-20230704, Roger Quadros wrote:
> >> main_i2c0 and pinmux should be in k3-am642-evm.dts.
> >> Also add the I2C EEPROM.
> >>
> >> Signed-off-by: Roger Quadros
> >> ---
> >> arch/arm/dts/k3-am642-evm-u-boot.dtsi | 11 ---
> >> arch/arm/dts/k3-am642-evm.dts | 20
> >> 2 files changed, 20 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
> >> b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
> >> index 64857b0909..80c04d0117 100644
> >> --- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
> >> +++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
> >> @@ -34,21 +34,10 @@
> >>
> >> _pmx0 {
> >>bootph-pre-ram;
> >> - main_i2c0_pins_default: main-i2c0-pins-default {
> >> - bootph-pre-ram;
> >> - pinctrl-single,pins = <
> >> - AM64X_IOPAD(0x0260, PIN_INPUT_PULLUP, 0) /* (A18)
> >> I2C0_SCL */
> >> - AM64X_IOPAD(0x0264, PIN_INPUT_PULLUP, 0) /* (B18)
> >> I2C0_SDA */
> >> - >;
> >> - };
> >> };
> >>
> >> _i2c0 {
> >> - status = "okay";
> >>bootph-pre-ram;
> >> - pinctrl-names = "default";
> >> - pinctrl-0 = <_i2c0_pins_default>;
> >> - clock-frequency = <40>;
> >> };
> >>
> >> _uart0 {
> >> diff --git a/arch/arm/dts/k3-am642-evm.dts b/arch/arm/dts/k3-am642-evm.dts
> >> index 39feea78a0..529eb81538 100644
> >> --- a/arch/arm/dts/k3-am642-evm.dts
> >> +++ b/arch/arm/dts/k3-am642-evm.dts
> >> @@ -233,6 +233,13 @@
> >>>;
> >>};
> >>
> >> + main_i2c0_pins_default: main-i2c0-default-pins {
> >> + pinctrl-single,pins = <
> >> + AM64X_IOPAD(0x0260, PIN_INPUT_PULLUP, 0) /* (A18)
> >> I2C0_SCL */
> >> + AM64X_IOPAD(0x0264, PIN_INPUT_PULLUP, 0) /* (B18)
> >> I2C0_SDA */
> >> + >;
> >> + };
> >> +
> >>main_i2c1_pins_default: main-i2c1-pins-default {
> >>pinctrl-single,pins = <
> >>AM64X_IOPAD(0x0268, PIN_INPUT_PULLUP, 0) /* (C18)
> >> I2C1_SCL */
> >> @@ -335,6 +342,19 @@
> >>status = "reserved";
> >> };
> >>
> >> +_i2c0 {
> >> + status = "okay";
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <_i2c0_pins_default>;
> >> + clock-frequency = <40>;
> >> +
> >> + eeprom@50 {
> >> + /* AT24CM01 */
> >> + compatible = "atmel,24c1024";
> >> + reg = <0x50>;
> >> + };
> >> +};
> >> +
> >> _i2c1 {
> >>status = "okay";
> >>pinctrl-names = "default";
> >> --
> >> 2.34.1
> >>
> >
> > We should be getting this change again as part of sync back from kernel.
> >
> >
> Got it.
>
> Adding the EEPROM node causes I2C timeout error prints like below.
> Any clue why that would be the case?
>
> Timed out in wait_for_event: status=
> Check if pads/pull-ups of bus are properly configured
> EEPROM not available at 0x50, trying to read at 0x51
> Timed out in wait_for_event: status=
> Check if pads/pull-ups of bus are properly configured
> Reading on-board EEPROM at 0x51 failed -121
https://lore.kernel.org/all/20230414073328.381336-7...@ti.com/
https://gist.github.com/nmenon/6b09f55251225d3f3cce076c32a33bba#file-am64-evm-L658
Seems to work for me in kernel - u-boot we will need to debug a bit. it
has been a massive pain in the backend to deal with the mix of
mis-behaving eeproms so far (whack-a-mole).. :(
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH 3/6] arm: dts: k3-am642: Sync main_i2c0 with kernel
Hi Nishanth,
On 06/07/2023 15:38, Nishanth Menon wrote:
> On 21:10-20230704, Roger Quadros wrote:
>> main_i2c0 and pinmux should be in k3-am642-evm.dts.
>> Also add the I2C EEPROM.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> arch/arm/dts/k3-am642-evm-u-boot.dtsi | 11 ---
>> arch/arm/dts/k3-am642-evm.dts | 20
>> 2 files changed, 20 insertions(+), 11 deletions(-)
>>
>> diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
>> b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
>> index 64857b0909..80c04d0117 100644
>> --- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
>> +++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
>> @@ -34,21 +34,10 @@
>>
>> _pmx0 {
>> bootph-pre-ram;
>> -main_i2c0_pins_default: main-i2c0-pins-default {
>> -bootph-pre-ram;
>> -pinctrl-single,pins = <
>> -AM64X_IOPAD(0x0260, PIN_INPUT_PULLUP, 0) /* (A18)
>> I2C0_SCL */
>> -AM64X_IOPAD(0x0264, PIN_INPUT_PULLUP, 0) /* (B18)
>> I2C0_SDA */
>> ->;
>> -};
>> };
>>
>> _i2c0 {
>> -status = "okay";
>> bootph-pre-ram;
>> -pinctrl-names = "default";
>> -pinctrl-0 = <_i2c0_pins_default>;
>> -clock-frequency = <40>;
>> };
>>
>> _uart0 {
>> diff --git a/arch/arm/dts/k3-am642-evm.dts b/arch/arm/dts/k3-am642-evm.dts
>> index 39feea78a0..529eb81538 100644
>> --- a/arch/arm/dts/k3-am642-evm.dts
>> +++ b/arch/arm/dts/k3-am642-evm.dts
>> @@ -233,6 +233,13 @@
>> >;
>> };
>>
>> +main_i2c0_pins_default: main-i2c0-default-pins {
>> +pinctrl-single,pins = <
>> +AM64X_IOPAD(0x0260, PIN_INPUT_PULLUP, 0) /* (A18)
>> I2C0_SCL */
>> +AM64X_IOPAD(0x0264, PIN_INPUT_PULLUP, 0) /* (B18)
>> I2C0_SDA */
>> +>;
>> +};
>> +
>> main_i2c1_pins_default: main-i2c1-pins-default {
>> pinctrl-single,pins = <
>> AM64X_IOPAD(0x0268, PIN_INPUT_PULLUP, 0) /* (C18)
>> I2C1_SCL */
>> @@ -335,6 +342,19 @@
>> status = "reserved";
>> };
>>
>> +_i2c0 {
>> +status = "okay";
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_i2c0_pins_default>;
>> +clock-frequency = <40>;
>> +
>> +eeprom@50 {
>> +/* AT24CM01 */
>> +compatible = "atmel,24c1024";
>> +reg = <0x50>;
>> +};
>> +};
>> +
>> _i2c1 {
>> status = "okay";
>> pinctrl-names = "default";
>> --
>> 2.34.1
>>
>
> We should be getting this change again as part of sync back from kernel.
>
>
Got it.
Adding the EEPROM node causes I2C timeout error prints like below.
Any clue why that would be the case?
Timed out in wait_for_event: status=
Check if pads/pull-ups of bus are properly configured
EEPROM not available at 0x50, trying to read at 0x51
Timed out in wait_for_event: status=
Check if pads/pull-ups of bus are properly configured
Reading on-board EEPROM at 0x51 failed -121
--
cheers,
-roger
Re: [PATCH v4 0/2] Fix 'no USB device found' error.
Hi Julien, On 06/07/2023 13:40, Julien Panis wrote: > This series fixes the "No USB device found" error > for am335x-icev2 and am335x-evmsk. USB0 dual-role > feature is now handled as peripheral only in the > driver. > > The error was not produced for am335x-evm because > usb0 dr_mode was configured as peripheral in > 'am335x-evm-u-boot.dtsi'. This fragment is no > longer needed. > > Signed-off-by: Julien Panis > --- > Changes in v4: > - Handle usb dual-role feature as peripheral in ti-musb driver. > - Link to v3: > https://lore.kernel.org/r/20230621-fix_usb_ether_init-v3-1-40493e1d7...@baylibre.com > > Changes in v3: > - Remove usb0 dr_mode configuration from 'am335x-evm-u-boot.dtsi'. > - Link to v2: > https://lore.kernel.org/r/20230621-fix_usb_ether_init-v2-0-ff121f0e8...@baylibre.com > > Changes in v2: > - Drop the modification made in arch/arm/mach-omap2/am33xx/board.c > - Configure usb0 dr_mode as peripheral in 'am335x-icev2-u-boot.dtsi' > and 'am335x-evmsk-u-boot.dtsi' device trees. > - Link to v1: > https://lore.kernel.org/r/20230621-fix_usb_ether_init-v1-1-215692399...@baylibre.com > > --- > Julien Panis (2): > musb-new: ti-musb: Handle usb dual-role feature as peripheral > arm: dts: am335x-evm-u-boot: Remove usb0 mode configuration for this series: Reviewed-by: Roger Quadros I also see other boards doing the wrong thing. i.e. replacing 'otg' with 'peripheral'. dra71-evm-u-boot.dtsi: dr_mode = "peripheral"; dra72-evm-revc-u-boot.dtsi: dr_mode = "peripheral"; dra72-evm-u-boot.dtsi: dr_mode = "peripheral"; dra76-evm-u-boot.dtsi: dr_mode = "peripheral"; dra7-evm-u-boot.dtsi: dr_mode = "peripheral"; k3-am642-evm-u-boot.dtsi: dr_mode="peripheral"; k3-am654-r5-base-board-u-boot.dtsi: dr_mode = "peripheral"; k3-am654-r5-base-board-u-boot.dtsi: dr_mode = "peripheral"; k3-j7200-common-proc-board-u-boot.dtsi: dr_mode = "peripheral"; k3-j721e-common-proc-board-u-boot.dtsi: dr_mode = "peripheral"; keystone-k2e-evm-u-boot.dtsi: dr_mode = "peripheral"; Is this something you can fix (in dwc3 driver) as it is on similar lines ;). Thanks! -- cheers, -roger
[PATCH v1 2/2] asm/arch: mach-meson: use secure monitor driver
Now we have to use UCLASS_FIRMWARE meson secure monitor driver
instead of raw smc_call() function call.
Signed-off-by: Alexey Romanov
---
arch/arm/mach-meson/sm.c | 161 +++
1 file changed, 97 insertions(+), 64 deletions(-)
diff --git a/arch/arm/mach-meson/sm.c b/arch/arm/mach-meson/sm.c
index d600c64d0be..347ff448f79 100644
--- a/arch/arm/mach-meson/sm.c
+++ b/arch/arm/mach-meson/sm.c
@@ -16,72 +16,74 @@
#include
#include
#include
+#include
#include
#include
-#define FN_GET_SHARE_MEM_INPUT_BASE0x8220
-#define FN_GET_SHARE_MEM_OUTPUT_BASE 0x8221
-#define FN_EFUSE_READ 0x8230
-#define FN_EFUSE_WRITE 0x8231
-#define FN_CHIP_ID 0x8244
-#define FN_PWRDM_SET 0x8293
-
-static void *shmem_input;
-static void *shmem_output;
-
-static void meson_init_shmem(void)
+static inline struct udevice *meson_get_sm_device(void)
{
- struct pt_regs regs;
-
- if (shmem_input && shmem_output)
- return;
+ struct udevice *dev;
+ int err;
- regs.regs[0] = FN_GET_SHARE_MEM_INPUT_BASE;
- smc_call();
- shmem_input = (void *)regs.regs[0];
-
- regs.regs[0] = FN_GET_SHARE_MEM_OUTPUT_BASE;
- smc_call();
- shmem_output = (void *)regs.regs[0];
+ err = uclass_get_device_by_name(UCLASS_FIRMWARE, "secure-monitor",
);
+ if (err) {
+ pr_err("Mesom SM device not found\n");
+ return ERR_PTR(err);
+ }
- debug("Secure Monitor shmem: 0x%p 0x%p\n", shmem_input, shmem_output);
+ return dev;
}
ssize_t meson_sm_read_efuse(uintptr_t offset, void *buffer, size_t size)
{
- struct pt_regs regs;
-
- meson_init_shmem();
-
- regs.regs[0] = FN_EFUSE_READ;
- regs.regs[1] = offset;
- regs.regs[2] = size;
-
- smc_call();
-
- if (regs.regs[0] == 0)
- return -1;
+ struct meson_sm_handle *handle;
+ struct udevice *dev;
+ int err;
+
+ dev = meson_get_sm_device();
+ if (IS_ERR(dev))
+ return PTR_ERR(dev);
+
+ handle = meson_sm_get_handle(dev);
+ if (IS_ERR(handle)) {
+ pr_err("Failed to get Meson SM handle\n");
+ return PTR_ERR(handle);
+ }
- memcpy(buffer, shmem_output, min(size, regs.regs[0]));
+ err = handle->ops.sm_call_read(dev, buffer, size,
+ MESON_SMC_CMD_EFUSE_READ, offset, size);
+ if (err < 0) {
+ pr_err("Failed to read efuse memory (%d)\n", err);
+ return err;
+ }
- return regs.regs[0];
+ return err;
}
ssize_t meson_sm_write_efuse(uintptr_t offset, void *buffer, size_t size)
{
- struct pt_regs regs;
-
- meson_init_shmem();
-
-memcpy(shmem_input, buffer, size);
-
- regs.regs[0] = FN_EFUSE_WRITE;
- regs.regs[1] = offset;
- regs.regs[2] = size;
+ struct meson_sm_handle *handle;
+ struct udevice *dev;
+ int err;
+
+ dev = meson_get_sm_device();
+ if (IS_ERR(dev))
+ return PTR_ERR(dev);
+
+ handle = meson_sm_get_handle(dev);
+ if (IS_ERR(handle)) {
+ pr_err("Failed to get Meson SM handle\n");
+ return PTR_ERR(handle);
+ }
- smc_call();
+ err = handle->ops.sm_call_write(dev, buffer, size,
+ MESON_SMC_CMD_EFUSE_WRITE, offset, size);
+ if (err < 0) {
+ pr_err("Failed to write efuse memory (%d)\n", err);
+ return err;
+ }
- return regs.regs[0];
+ return err;
}
#define SM_CHIP_ID_LENGTH 119
@@ -90,18 +92,35 @@ ssize_t meson_sm_write_efuse(uintptr_t offset, void
*buffer, size_t size)
int meson_sm_get_serial(void *buffer, size_t size)
{
- struct pt_regs regs;
-
- meson_init_shmem();
+ struct meson_sm_handle *handle;
+ struct udevice *dev;
+ u8 *id_buffer;
+ int err;
+
+ dev = meson_get_sm_device();
+ if (IS_ERR(dev))
+ return PTR_ERR(dev);
+
+ handle = meson_sm_get_handle(dev);
+ if (IS_ERR(handle)) {
+ pr_err("Failed to get Meson SM handle\n");
+ return PTR_ERR(handle);
+ }
- regs.regs[0] = FN_CHIP_ID;
- regs.regs[1] = 0;
- regs.regs[2] = 0;
+ id_buffer = malloc(sizeof(u8) * SM_CHIP_ID_LENGTH);
+ if (!id_buffer)
+ return -ENOMEM;
- smc_call();
+ err = handle->ops.sm_call_read(dev, id_buffer, SM_CHIP_ID_LENGTH,
+ MESON_SMC_CMD_CHIP_ID_GET, 0, 0);
+ if (err < 0) {
+ pr_err("Failed to read serial number (%d)\n", err);
+ free(id_buffer);
+ return err;
+ }
- memcpy(buffer, shmem_output + SM_CHIP_ID_OFFSET,
- min_t(size_t, size, SM_CHIP_ID_SIZE));
+
[PATCH v1 1/2] drivers: firmware: introduce Meson Secure Monitor driver
At the moment, only smc API is a set of functions in
arch/arm/mach-meson/sm.c. This approach is hard to configure
and also doesn't contain any generic API for calling smc.
This patch add Meson SM driver with generic API (struct meson_sm_ops):
- sm_call()
- sm_call_write()
- sm_call_read()
A typical driver usage example is shown here:
1. uclass_get_device_by_driver(UCLASS_FIRMWARE, "secure-monitor", );
2. handle = meson_sm_get_handle(dev);
3. handle->ops.sm_call(dev, cmd, ...);
Signed-off-by: Alexey Romanov
---
arch/arm/mach-meson/Kconfig | 1 +
drivers/firmware/Kconfig | 10 ++
drivers/firmware/Makefile | 1 +
drivers/firmware/meson/Kconfig| 6 +
drivers/firmware/meson/Makefile | 3 +
drivers/firmware/meson/meson_sm.c | 217 ++
include/meson/sm_handle.h | 38 ++
7 files changed, 276 insertions(+)
create mode 100644 drivers/firmware/meson/Kconfig
create mode 100644 drivers/firmware/meson/Makefile
create mode 100644 drivers/firmware/meson/meson_sm.c
create mode 100644 include/meson/sm_handle.h
diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig
index 669ca09a00a..b8746d27f63 100644
--- a/arch/arm/mach-meson/Kconfig
+++ b/arch/arm/mach-meson/Kconfig
@@ -11,6 +11,7 @@ config MESON64_COMMON
select PWRSEQ
select MMC_PWRSEQ
select BOARD_LATE_INIT
+ select MESON_FIRMWARE
imply CMD_DM
config MESON_GX
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index eae1c8ddc9f..17b70fdea6d 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -37,6 +37,15 @@ config ZYNQMP_FIRMWARE
Say yes to enable ZynqMP firmware interface driver.
If in doubt, say N.
+config MESON_FIRMWARE
+ bool "Meson Firmware interface"
+ select FIRMWARE
+ help
+ This option enables Meson firmware interface,
+ which is used by different drivers to communicate
+ with the firmware for various platform management
+ services.
+
config ARM_SMCCC_FEATURES
bool "Arm SMCCC features discovery"
depends on ARM_PSCI_FW
@@ -45,4 +54,5 @@ config ARM_SMCCC_FEATURES
the PSCI driver is always probed and binds dirvers registered to the
Arm SMCCC
services if any and reported as supported by the SMCCC firmware.
+source "drivers/firmware/meson/Kconfig"
source "drivers/firmware/scmi/Kconfig"
diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index 7ce83d72bd3..a6300be27ad 100644
--- a/drivers/firmware/Makefile
+++ b/drivers/firmware/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_TI_SCI_PROTOCOL) += ti_sci.o
obj-$(CONFIG_SANDBOX) += firmware-sandbox.o
obj-$(CONFIG_ZYNQMP_FIRMWARE) += firmware-zynqmp.o
obj-$(CONFIG_SCMI_FIRMWARE)+= scmi/
+obj-$(CONFIG_MESON_FIRMWARE) += meson/
diff --git a/drivers/firmware/meson/Kconfig b/drivers/firmware/meson/Kconfig
new file mode 100644
index 000..0fd4f3251e1
--- /dev/null
+++ b/drivers/firmware/meson/Kconfig
@@ -0,0 +1,6 @@
+config MESON_SM
+ bool "Amlogic Secure Monitor driver"
+ depends on ARCH_MESON
+ default y
+ help
+ Say y here to enable the Amlogic secure monitor driver.
diff --git a/drivers/firmware/meson/Makefile b/drivers/firmware/meson/Makefile
new file mode 100644
index 000..b5d26f150b0
--- /dev/null
+++ b/drivers/firmware/meson/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+obj-$(CONFIG_MESON_SM) += meson_sm.o
diff --git a/drivers/firmware/meson/meson_sm.c
b/drivers/firmware/meson/meson_sm.c
new file mode 100644
index 000..28eacb89810
--- /dev/null
+++ b/drivers/firmware/meson/meson_sm.c
@@ -0,0 +1,217 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2023 SberDevices, Inc.
+ *
+ * Author: Alexey Romanov
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct meson_sm_cmd {
+ u32 smc_id;
+};
+
+#define SET_CMD(index, id) \
+ [index] = { \
+ .smc_id = id, \
+ }
+
+struct meson_sm_data {
+ u32 cmd_get_shmem_in;
+ u32 cmd_get_shmem_out;
+ unsigned int shmem_size;
+ struct meson_sm_cmd cmd[];
+};
+
+struct meson_sm_priv {
+ void *sm_shmem_in;
+ void *sm_shmem_out;
+ struct meson_sm_handle handle;
+ const struct meson_sm_data *data;
+};
+
+static unsigned long __meson_sm_call(u32 cmd, u32 arg0, u32 arg1, u32 arg2,
+ u32 arg3, u32 arg4)
+{
+ struct pt_regs r;
+
+ r.regs[0] = cmd;
+ r.regs[1] = arg0;
+ r.regs[2] = arg1;
+ r.regs[3] = arg2;
+ r.regs[4] = arg3;
+ r.regs[5] = arg4;
+
+ smc_call();
+
+ return r.regs[0];
+};
+
+static u32 meson_sm_get_cmd(const struct meson_sm_data *data,
+ u32 cmd_index)
+{
+ struct meson_sm_cmd cmd;
+
+ if
[PATCH v1 0/2] Introduce Meson SM driver
Hello! This patchset adds Meson Secure Monitor driver, which export following generic API: - sm_call_read() - sm_call_write() - sm_call() Also, now use this new API in arch/arm/mach-meson/sm.c helper functions. Alexey Romanov (2): drivers: firmware: introduce Meson Secure Monitor driver asm/arch: mach-meson: use secure monitor driver arch/arm/mach-meson/Kconfig | 1 + arch/arm/mach-meson/sm.c | 161 +- drivers/firmware/Kconfig | 10 ++ drivers/firmware/Makefile | 1 + drivers/firmware/meson/Kconfig| 6 + drivers/firmware/meson/Makefile | 3 + drivers/firmware/meson/meson_sm.c | 217 ++ include/meson/sm_handle.h | 38 ++ 8 files changed, 373 insertions(+), 64 deletions(-) create mode 100644 drivers/firmware/meson/Kconfig create mode 100644 drivers/firmware/meson/Makefile create mode 100644 drivers/firmware/meson/meson_sm.c create mode 100644 include/meson/sm_handle.h -- 2.38.1
Re: [PATCH 3/5] ARM: dts: at91: sam9x60: Change i2c compatible
Sorry! misunderstood as kernel. Ignore this comment.
On 06/07/23 14:02, Durai Manickam KR wrote:
> Hi Alexander,
>
> sam9x60_curiosity and sam9x60ek belongs to same SOC family. So the
> compatible string is updated as "microchip,sam9x60-i2c" in the
> sam9x60.dtsi file. These changes are available in linux-6.4.y branch.
>
> On 06/07/23 01:46, Alexander Dahl wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you
>> know the content is safe
>>
>> From: Alexander Dahl
>>
>> There's a more specific compatible string for the i2c interface, use it.
>>
>> Signed-off-by: Alexander Dahl
>> ---
>>
>> Notes:
>> I²C access to the eeprom did not work though, neither before nor
>> after
>> this change.
>>
>> arch/arm/dts/at91-sam9x60_curiosity.dts | 2 +-
>> arch/arm/dts/sam9x60ek.dts | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/dts/at91-sam9x60_curiosity.dts
>> b/arch/arm/dts/at91-sam9x60_curiosity.dts
>> index da5e19b66b..ae707dd64b 100644
>> --- a/arch/arm/dts/at91-sam9x60_curiosity.dts
>> +++ b/arch/arm/dts/at91-sam9x60_curiosity.dts
>> @@ -21,7 +21,7 @@
>> status = "okay";
>>
>> i2c@600 {
>> - compatible =
>> "atmel,sama5d2-i2c";
>> + compatible =
>> "microchip,sam9x60-i2c";
>> reg = <0x600 0x200>;
>> pinctrl-names = "default";
>> pinctrl-0 = <_flx0>;
>> diff --git a/arch/arm/dts/sam9x60ek.dts b/arch/arm/dts/sam9x60ek.dts
>> index 45e2f4cc40..74016f5e28 100644
>> --- a/arch/arm/dts/sam9x60ek.dts
>> +++ b/arch/arm/dts/sam9x60ek.dts
>> @@ -62,7 +62,7 @@
>> status = "okay";
>>
>> i2c@600 {
>> - compatible =
>> "atmel,sama5d2-i2c";
>> + compatible =
>> "microchip,sam9x60-i2c";
>> reg = <0x600 0x200>;
>> pinctrl-names = "default";
>> pinctrl-0 = <_flx0>;
>> --
>> 2.30.2
>>
Re: [PATCH 2/5] ARM: dts: at91: sam9x60-curiosity: Fix EEPROM type
Sorry! misunderstood as kernel. Ignore this comment.
On 06/07/23 14:00, Durai Manickam KR wrote:
> Hi Alexander,
>
> I hope these changes are already present in upstream branch linux-6.4.y
>
> On 06/07/23 01:46, Alexander Dahl wrote:
>> [Some people who received this message don't often get email from
>> p...@lespocky.de. Learn why this is important at
>> https://aka.ms/LearnAboutSenderIdentification ]
>>
>> EXTERNAL EMAIL: Do not click links or open attachments unless you
>> know the content is safe
>>
>> From: Alexander Dahl
>>
>> The user guide says it's a Microchip 24AA025E48 serial EEPROM, which is
>> a 2-Kbit I2C Serial EEPROM with EUI-48™ Identity. This is the chip
>> actually populated on board EV40E67A rev 4.
>>
>> Signed-off-by: Alexander Dahl
>> ---
>>
>> Notes:
>> Sadly this did not fix the problem, that I could not access that
>> eeprom through I²C.
>>
>> arch/arm/dts/at91-sam9x60_curiosity.dts | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/dts/at91-sam9x60_curiosity.dts
>> b/arch/arm/dts/at91-sam9x60_curiosity.dts
>> index d6ae3d648d..da5e19b66b 100644
>> --- a/arch/arm/dts/at91-sam9x60_curiosity.dts
>> +++ b/arch/arm/dts/at91-sam9x60_curiosity.dts
>> @@ -31,7 +31,7 @@
>> status = "okay";
>>
>> eeprom@53 {
>> - compatible =
>> "atmel,24c32";
>> + compatible =
>> "atmel,24c02";
>> reg = <0x53>;
>> pagesize = <16>;
>> };
>> --
>> 2.30.2
>>
Re: [PATCH 3/5] ARM: dts: at91: sam9x60: Change i2c compatible
Hi Alexander,
sam9x60_curiosity and sam9x60ek belongs to same SOC family. So the
compatible string is updated as "microchip,sam9x60-i2c" in the
sam9x60.dtsi file. These changes are available in linux-6.4.y branch.
On 06/07/23 01:46, Alexander Dahl wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> From: Alexander Dahl
>
> There's a more specific compatible string for the i2c interface, use it.
>
> Signed-off-by: Alexander Dahl
> ---
>
> Notes:
> I²C access to the eeprom did not work though, neither before nor after
> this change.
>
> arch/arm/dts/at91-sam9x60_curiosity.dts | 2 +-
> arch/arm/dts/sam9x60ek.dts | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/dts/at91-sam9x60_curiosity.dts
> b/arch/arm/dts/at91-sam9x60_curiosity.dts
> index da5e19b66b..ae707dd64b 100644
> --- a/arch/arm/dts/at91-sam9x60_curiosity.dts
> +++ b/arch/arm/dts/at91-sam9x60_curiosity.dts
> @@ -21,7 +21,7 @@
> status = "okay";
>
> i2c@600 {
> - compatible = "atmel,sama5d2-i2c";
> + compatible = "microchip,sam9x60-i2c";
> reg = <0x600 0x200>;
> pinctrl-names = "default";
> pinctrl-0 = <_flx0>;
> diff --git a/arch/arm/dts/sam9x60ek.dts b/arch/arm/dts/sam9x60ek.dts
> index 45e2f4cc40..74016f5e28 100644
> --- a/arch/arm/dts/sam9x60ek.dts
> +++ b/arch/arm/dts/sam9x60ek.dts
> @@ -62,7 +62,7 @@
> status = "okay";
>
> i2c@600 {
> - compatible = "atmel,sama5d2-i2c";
> + compatible = "microchip,sam9x60-i2c";
> reg = <0x600 0x200>;
> pinctrl-names = "default";
> pinctrl-0 = <_flx0>;
> --
> 2.30.2
>
Re: [PATCH 2/5] ARM: dts: at91: sam9x60-curiosity: Fix EEPROM type
Hi Alexander,
I hope these changes are already present in upstream branch linux-6.4.y
On 06/07/23 01:46, Alexander Dahl wrote:
> [Some people who received this message don't often get email from
> p...@lespocky.de. Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> From: Alexander Dahl
>
> The user guide says it's a Microchip 24AA025E48 serial EEPROM, which is
> a 2-Kbit I2C Serial EEPROM with EUI-48™ Identity. This is the chip
> actually populated on board EV40E67A rev 4.
>
> Signed-off-by: Alexander Dahl
> ---
>
> Notes:
> Sadly this did not fix the problem, that I could not access that
> eeprom through I²C.
>
> arch/arm/dts/at91-sam9x60_curiosity.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/dts/at91-sam9x60_curiosity.dts
> b/arch/arm/dts/at91-sam9x60_curiosity.dts
> index d6ae3d648d..da5e19b66b 100644
> --- a/arch/arm/dts/at91-sam9x60_curiosity.dts
> +++ b/arch/arm/dts/at91-sam9x60_curiosity.dts
> @@ -31,7 +31,7 @@
> status = "okay";
>
> eeprom@53 {
> - compatible = "atmel,24c32";
> + compatible = "atmel,24c02";
> reg = <0x53>;
> pagesize = <16>;
> };
> --
> 2.30.2
>
Re: EFI Secure boot default keys
>> >> Please can someone describe the format of the file needed for the default
>> >> / built-in EFI secure boot keys (ubootefi.var)
>> >>
>> >> The only docs I have found suggest its best to enroll the keys from
>> >> within u-boot onto some removable media, then copy this off and use this
>> >> as the default, this is not very helpful and doesn't work for me:
>> >>
>> >> => fatload mmc 0:1 ${loadaddr} PK.aut
>> >> 2053 bytes read in 18 ms (111.3 KiB/s)
>> >> => setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize PK
>> >> setenv - set environment variables
>> >>
>> >> Usage:
>> >> setenv setenv [-f] name value ...
>> >> - [forcibly] set environment variable 'name' to 'value ...'
>> >> setenv [-f] name
>> >> - [forcibly] delete environment variable 'name'
>> >>
>> >> my setenv doesn't support all the extra switches ? This is with 2022.04,
>> >> all other EFI options seem to be in this release and I can boot unsigned
>> >> EFI images ok.
>> >
>> >Please turn on CONFIG_CMD_NVEDIT_EFI when building your U-Boot.
>> >
>> >This option was disabled by the commit:
>> > commit 3b728f8728fa (tag: efi-2020-01-rc1)
>> > Author: Heinrich Schuchardt
>> > Date: Sun Oct 6 15:44:22 2019 +0200
>> >
>> > cmd: disable CMD_NVEDIT_EFI by default
>> >
>> >The binary size of efi has grown much since in the past, though.
>> >
>> >-Takahiro Akashi
>>
>> Thanks, I have secure boot working now. A tool to generate the ubootefi.var
>> offline or even just a description of the file format would be very useful.
>
>Thank you for the suggestion. While I'd like to defer to Heinrich,
>the C definition of the file format can be found as struct efi_var_file
>in include/efi_variable.h
>
Thanks!
>> I have noticed one issue when using ubootefi.var on mmc, when I switch boot
>> order it wipes out the keys and I have to re-enrol them:
>>
>> => fatls mmc 0:1
>> 3040 ubootefi.var
>>
>> 1 file(s), 0 dir(s)
>
>I'm not sure that secure boot related variables have been loaded
>at this point.
This is during initial generation / enrollment of the variables
>Anyhow, please try to enable CONFIG_EFI_VARIABLES_PRESEED with
>EFI_VAR_FILE_NAME set. Otherwise, those variables will never be
>restored.
>(This is another topic that are not described in doc/develop/uefi.)
I have CONFIG_EFI_VARIABLES_PRESEED working, but while generating the file
ubootefi.var for the first time (without CONFIG_EFI_VARIABLES_PRESEED set) you
have to follow a specific order, or the file gets overwritten eg:
Working:
efidebug boot order 1 2
efidebug boot add -b 1 Signed mmc 0:1 /ImageSig.efi
efidebug boot add -b 2 UnSigned mmc 0:1 /Image
fatload mmc 0:1 ${loadaddr} PK.aut
setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize PK
fatload mmc 0:1 ${loadaddr} KEK.aut
setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize KEK
fatload mmc 0:1 ${loadaddr} DB.aut
setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize db
Failing:
setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize PK
fatload mmc 0:1 ${loadaddr} KEK.aut
setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize KEK
fatload mmc 0:1 ${loadaddr} DB.aut
setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize db
efidebug boot order 1 2 ### This command overwrites the keys just loaded
Cheers,
Neil
>
>Thanks,
>-Takahiro Akashi
>
>> => efidebug boot order 2 1
>> => fatls mmc 0:1
>> 440 ubootefi.var
>>
>> (Size drops from 3040 to 440 bytes and keys have gone)
>
> From: AKASHI Takahiro
> Sent: 29 June 2023 02:01
> To: Neil Jones
> Cc: u-boot@lists.denx.de
> Subject: Re: EFI Secure boot default keys
>
> On Wed, Jun 28, 2023 at 04:26:58PM +, Neil Jones wrote:
> > Please can someone describe the format of the file needed for the default /
> > built-in EFI secure boot keys (ubootefi.var)
> >
> > The only docs I have found suggest its best to enroll the keys from within
> > u-boot onto some removable media, then copy this off and use this as the
> > default, this is not very helpful and doesn't work for me:
> >
> > => fatload mmc 0:1 ${loadaddr} PK.aut
> > 2053 bytes read in 18 ms (111.3 KiB/s)
> > => setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize PK
> > setenv - set environment variables
> >
> > Usage:
> > setenv setenv [-f] name value ...
> > - [forcibly] set environment variable 'name' to 'value ...'
> > setenv [-f] name
> > - [forcibly] delete environment variable 'name'
> >
> > my setenv doesn't support all the extra switches ? This is with 2022.04,
> > all other EFI options seem to be in this release and I can boot unsigned
> > EFI images ok.
>
> Please turn on CONFIG_CMD_NVEDIT_EFI when building your U-Boot.
>
> This option was disabled by the commit:
> commit 3b728f8728fa (tag: efi-2020-01-rc1)
> Author: Heinrich Schuchardt
> Date: Sun Oct 6 15:44:22 2019 +0200
>
> cmd: disable CMD_NVEDIT_EFI by default
Re: [PATCH v4 2/2] arm: dts: am335x-evm-u-boot: Remove usb0 mode configuration
On 12:40-20230706, Julien Panis wrote:
> USB0 dual-role feature is now handled as peripheral only
> in ti-musb driver.
>
> Signed-off-by: Julien Panis
> ---
> arch/arm/dts/am335x-evm-u-boot.dtsi | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/arch/arm/dts/am335x-evm-u-boot.dtsi
> b/arch/arm/dts/am335x-evm-u-boot.dtsi
> index 82a483ae3e28..42eeca8c0499 100644
> --- a/arch/arm/dts/am335x-evm-u-boot.dtsi
> +++ b/arch/arm/dts/am335x-evm-u-boot.dtsi
> @@ -23,10 +23,6 @@
> status = "disabled";
> };
>
> - {
> - dr_mode = "peripheral";
> -};
> -
> {
> bootph-all;
> };
>
> --
> 2.37.3
>
Reviewed-by: Nishanth Menon
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH v4 1/2] musb-new: ti-musb: Handle usb dual-role feature as peripheral
On 12:40-20230706, Julien Panis wrote:
> This prevents from getting some 'No USB device found' error,
> in usb_ether_init() function for instance.
>
> Signed-off-by: Julien Panis
> ---
> drivers/usb/musb-new/ti-musb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/musb-new/ti-musb.c b/drivers/usb/musb-new/ti-musb.c
> index 3be3f93dd85d..44697dc31387 100644
> --- a/drivers/usb/musb-new/ti-musb.c
> +++ b/drivers/usb/musb-new/ti-musb.c
> @@ -302,6 +302,7 @@ static int ti_musb_wrapper_bind(struct udevice *parent)
> dr_mode = usb_get_dr_mode(node);
> switch (dr_mode) {
> case USB_DR_MODE_PERIPHERAL:
> + case USB_DR_MODE_OTG:
> /* Bind MUSB device */
> ret = device_bind_driver_to_node(parent,
>"ti-musb-peripheral",
>
> --
> 2.37.3
>
Reviewed-by: Nishanth Menon
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH 3/6] arm: dts: k3-am642: Sync main_i2c0 with kernel
On 21:10-20230704, Roger Quadros wrote:
> main_i2c0 and pinmux should be in k3-am642-evm.dts.
> Also add the I2C EEPROM.
>
> Signed-off-by: Roger Quadros
> ---
> arch/arm/dts/k3-am642-evm-u-boot.dtsi | 11 ---
> arch/arm/dts/k3-am642-evm.dts | 20
> 2 files changed, 20 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
> b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
> index 64857b0909..80c04d0117 100644
> --- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
> +++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
> @@ -34,21 +34,10 @@
>
> _pmx0 {
> bootph-pre-ram;
> - main_i2c0_pins_default: main-i2c0-pins-default {
> - bootph-pre-ram;
> - pinctrl-single,pins = <
> - AM64X_IOPAD(0x0260, PIN_INPUT_PULLUP, 0) /* (A18)
> I2C0_SCL */
> - AM64X_IOPAD(0x0264, PIN_INPUT_PULLUP, 0) /* (B18)
> I2C0_SDA */
> - >;
> - };
> };
>
> _i2c0 {
> - status = "okay";
> bootph-pre-ram;
> - pinctrl-names = "default";
> - pinctrl-0 = <_i2c0_pins_default>;
> - clock-frequency = <40>;
> };
>
> _uart0 {
> diff --git a/arch/arm/dts/k3-am642-evm.dts b/arch/arm/dts/k3-am642-evm.dts
> index 39feea78a0..529eb81538 100644
> --- a/arch/arm/dts/k3-am642-evm.dts
> +++ b/arch/arm/dts/k3-am642-evm.dts
> @@ -233,6 +233,13 @@
> >;
> };
>
> + main_i2c0_pins_default: main-i2c0-default-pins {
> + pinctrl-single,pins = <
> + AM64X_IOPAD(0x0260, PIN_INPUT_PULLUP, 0) /* (A18)
> I2C0_SCL */
> + AM64X_IOPAD(0x0264, PIN_INPUT_PULLUP, 0) /* (B18)
> I2C0_SDA */
> + >;
> + };
> +
> main_i2c1_pins_default: main-i2c1-pins-default {
> pinctrl-single,pins = <
> AM64X_IOPAD(0x0268, PIN_INPUT_PULLUP, 0) /* (C18)
> I2C1_SCL */
> @@ -335,6 +342,19 @@
> status = "reserved";
> };
>
> +_i2c0 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c0_pins_default>;
> + clock-frequency = <40>;
> +
> + eeprom@50 {
> + /* AT24CM01 */
> + compatible = "atmel,24c1024";
> + reg = <0x50>;
> + };
> +};
> +
> _i2c1 {
> status = "okay";
> pinctrl-names = "default";
> --
> 2.34.1
>
We should be getting this change again as part of sync back from kernel.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH 4/6] arm: dts: k3-am642-r5-evm: Add I2C0 and Card detect GPIOs
On 21:10-20230704, Roger Quadros wrote:
> Card detect GPIOs are on I2C GPIO Expander on I2C0.
> Enable I2C0 and GPIO Expander for r5-evm.
>
> Signed-off-by: Roger Quadros
> ---
> arch/arm/dts/k3-am642-r5-evm.dts | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm/dts/k3-am642-r5-evm.dts
> b/arch/arm/dts/k3-am642-r5-evm.dts
> index e870492a69..01b4a61852 100644
> --- a/arch/arm/dts/k3-am642-r5-evm.dts
> +++ b/arch/arm/dts/k3-am642-r5-evm.dts
> @@ -209,6 +209,13 @@
> AM64X_IOPAD(0x0144, PIN_OUTPUT, 4) /* (Y11)
> PRG1_PRU1_GPO15.RGMII2_TX_CTL */
> >;
> };
> +
> + main_i2c0_pins_default: main-i2c0-default-pins {
> + pinctrl-single,pins = <
> + AM64X_IOPAD(0x0260, PIN_INPUT_PULLUP, 0) /* (A18)
> I2C0_SCL */
> + AM64X_IOPAD(0x0264, PIN_INPUT_PULLUP, 0) /* (B18)
> I2C0_SDA */
> + >;
> + };
> };
>
> {
> @@ -267,6 +274,18 @@
> /* EEPROM might be read before SYSFW is available */
> _i2c0 {
> /delete-property/ power-domains;
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c0_pins_default>;
> + clock-frequency = <40>;
> +
> + tca9554: gpio@38 {
> + /* TCA9554 */
> + compatible = "nxp,pca9554";
> + reg = <0x38>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> };
>
> {
> --
> 2.34.1
>
NAK - Upstream kernel first please, we should get this change as part of
sync from kernel.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH 2/2] board: rockchip: Add Hardkernel ODROID-M1
On 2023-07-06 07:08, Jonas Karlman wrote: > On 2023-07-06 01:27, Stefan Agner wrote: >> On 2023-07-02 22:47, Jonas Karlman wrote: >>> Hardkernel ODROID-M1 is a single board computer with a RK3568B2 SoC, >>> a slightly modified version of the RK3568 SoC. >>> >>> Features tested on a ODROID-M1 8GB v1.0 2022-06-13: >>> - SD-card boot >>> - eMMC boot >>> - SPI Flash boot >>> - PCIe/NVMe/AHCI >>> - SATA port >>> - USB host >>> >>> Device tree is imported from linux v6.4. >>> >>> Signed-off-by: Jonas Karlman >> >> Thanks for you patch! I've compared it to my version, and did not notice >> any downside/anything missing. If anything, your version is more feature >> complete. I've also tested it on an ODORID-M1 with 8GB of memory, it >> boots fine from SD card. >> >> Reviewed-by: Stefan Agner >> Tested-by: Stefan Agner > > Thanks for review and testing! > >> >> One thing I've noticed is that USB isn't working when I use the stock >> SPL (2017.09) running from the SPI RAM and upstream U-Boot (by writing >> u-boot.itb to a raw GPT partition named "uboot" to the SD-card). That is >> the same in my patchset. If the upstream SPL is used, things work. It >> seems that something is not (re)initialized in U-Boot. Not sure if we >> typically rely on the state the SPL leaves the HW at, but it would be >> nice if we are able to make that combination work. This allows to boot >> an upstream U-Boot from an SD-card without having to reflash the onboard >> SPI. > > Trying to use a combo of vendor u-boot SPL and mainline U-Boot proper is > not something I have tested or something I would recommend anyone to use. > To make use of all features one should press the "SPI recovery switch" > during boot or erase/replace U-Boot in SPI flash. Yeah I understand that this is the correct way of doing things. For Home Assistant OS we try to build an easy to use image which can be flashed to the SD card/eMMC and then booted directly. Unfortunately, the board doesn't allow to boot straight from eMMC/SD card. I'd prefer if we don't have to touch the SPI flash to avoid complexity and allow users to easily switch back to whatever the vendor offers. In a way, this is similar to how things work on x86-64, to leave the BIOS (in this case SPL on SPI flash) up to the hardware vendor. I understand that this gets into out-of-scope/unsupported territory. I posing the question opportunistically: Since you worked with the platform quite a bit maybe you have a good guess/idea what could be the culprit. > > Does this USB issue only affect U-Boot proper or also leave USB unusable > in linux? Booting OS from USB3 have been a little bit random when I have > tested, some of my USB3 devices work if plugged in from cold start > others needs to be removed and plugged in again for U-Boot to recognize > them. USB2 ports have been much more stable during my testing. USB is usable on Linux, so this is just U-Boot. I've tested with a USB 2.0 flash drive. > >> >> On a different note: Do you know if PCIe/NVMe support in SPL is >> something which is in the cards for this board? > > As mentioned in the cover-letter this series has some dependencies for > all features enabled in defconfig to work, most notably PCIe/NVMe. > > You can use my rk3568-2023.07-rc6 branch at [1] that have all > dependencies included or test with an artifact from my github actions > test build workflow at [2]. > > Or do you mean SPL to load FIT (U-Boot proper and TF-A) from NVMe? Yes, I meant using the SPL to load the U-Boot FIT image from NVMe. -- Stefan > > [1] https://github.com/Kwiboo/u-boot-rockchip/commits/rk3568-2023.07-rc6 > [2] https://github.com/Kwiboo/u-boot-build/actions/runs/5448465108 > > Regards, > Jonas > >> >> -- >> Stefan >> >>> --- >>> arch/arm/dts/Makefile | 1 + >>> arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi | 46 ++ >>> arch/arm/dts/rk3568-odroid-m1.dts | 744 ++ >>> board/rockchip/evb_rk3568/MAINTAINERS | 7 + >>> configs/odroid-m1-rk3568_defconfig| 103 +++ >>> doc/board/rockchip/rockchip.rst | 1 + >>> 6 files changed, 902 insertions(+) >>> create mode 100644 arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi >>> create mode 100644 arch/arm/dts/rk3568-odroid-m1.dts >>> create mode 100644 configs/odroid-m1-rk3568_defconfig >>>[...]
Re: [PATCH v4 1/2] musb-new: ti-musb: Handle usb dual-role feature as peripheral
* Julien Panis [230706 10:41]: > This prevents from getting some 'No USB device found' error, > in usb_ether_init() function for instance. Looks good to me: Reviewed-by: Tony Lindgren
Re: [PATCH u-boot 0/4] mmc: Explain and cleanup partition selection
On Monday 03 July 2023 21:16:37 Jaehoon Chung wrote: > Hi, > > On 4/14/23 06:10, Pali Rohár wrote: > > Some people do not want to read review comments in emails. So put > > comments and explanation into the source code itself; make emmc > > partition selection code more explicit and validate configuration in > > bubt command. > > Sorry for too late. > After applied this patch-set, some board are failed with spl's size > overflowed > > The below is one of failed log. > > +arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 352 bytes > +make[2]: *** [scripts/Makefile.spl:527: spl/u-boot-spl] Error 1 > +make[1]: *** [Makefile:2049: spl/u-boot-spl] Error 2 Crap, and again we have there same issue. Patch after months does not apply anymore. And resending the patch would again result in the same problem that it would not apply anymore after half of the year... Anyway, only first patch is SPL specific, other should apply without any problem. > > Best Regards, > Jaehoon Chung > > > > > Pali Rohár (4): > > mmc: spl: Make partition choice in > > default_spl_mmc_emmc_boot_partition() more explicit > > cmd: mvebu/bubt: Validate EXT_CSD[179] eMMC register in > > mmc_burn_image() > > sunxi: eMMC: Add comments explaining mapping between bootpart and > > mmc_switch_part() > > board: purism: Use U-Boot mmc function for converting boot part to > > part access > > > > arch/arm/mach-sunxi/board.c| 12 ++- > > board/purism/librem5/librem5.c | 6 +- > > cmd/mvebu/bubt.c | 24 +++-- > > common/spl/spl_mmc.c | 38 +++--- > > 4 files changed, 64 insertions(+), 16 deletions(-) >
[PULL] u-boot-riscv/riscv-for-next
Hi Tom,
The following changes since commit e80f4079b3a3db0961b73fa7a96e6c90242d8d25:
Merge tag 'v2023.07-rc6' into next (2023-07-05 11:28:55 -0400)
are available in the Git repository at:
https://source.denx.de/u-boot/custodians/u-boot-riscv.git riscv-for-next
for you to fetch changes up to 12f66e2197c59e500d1e2ee359bb2ce22d748290:
board: ae350: Add missing env variables for booti (2023-07-06 17:28:08 +0800)
CI result shows no issue:
https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/16799
- RISC-V CI OpenSBI version update
- Andes ae350 board modification
- Sync PolarFire SoC dts with Linux
- Support building ubifs
Ben Dooks (4):
riscv: add generic link for
riscv: implement local_irq_{save,restore} macros
riscv: define test_and_{set,clear}_bit in asm/bitops.h
clk: sifive: only build sifive-prci.o for CONFIG_CLK_SIFIVE_PRCI
Bin Meng (1):
ci: riscv: Update OpenSBI to v1.2
Conor Dooley (3):
riscv: dts: drop microchip from dts filenames
riscv: dts: sync mpfs-icicle devicetree with linux
board: microchip: set mac address for ethernet1 on icicle
Heinrich Schuchardt (2):
cmd/sbi: display new extensions
RISC-V: CONFIG_SPL_OPENSBI_SCRATCH_OPTIONS description
Hoegeun Kwon (1):
clk: starfive: pll: Fix to use postdiv1_mask
Yu Chien Peter Lin (2):
riscv: andes_plicsw: Fix IPI during OpenSBI invocation
board: ae350: Add missing env variables for booti
.azure-pipelines.yml
| 8 +--
.gitlab-ci.yml
| 8 +--
arch/riscv/dts/Makefile
| 2 +-
arch/riscv/dts/microchip-mpfs-icicle-kit.dts
| 136 ---
arch/riscv/dts/mpfs-icicle-kit-fabric.dtsi
| 71 +++
arch/riscv/dts/{microchip-mpfs-icicle-kit-u-boot.dtsi =>
mpfs-icicle-kit-u-boot.dtsi} | 0
arch/riscv/dts/mpfs-icicle-kit.dts
| 208 ++
arch/riscv/dts/{microchip-mpfs.dtsi => mpfs.dtsi}
| 434
--
arch/riscv/include/asm/atomic.h
| 14 +
arch/riscv/include/asm/bitops.h
| 3 +
arch/riscv/include/asm/sbi.h
| 9 +++
arch/riscv/include/asm/system.h
| 17 --
arch/riscv/lib/andes_plicsw.c
| 25 +++-
board/microchip/mpfs_icicle/mpfs_icicle.c
| 15 -
cmd/riscv/sbi.c
| 3 +
common/spl/Kconfig
| 6 +-
configs/microchip_mpfs_icicle_defconfig
| 2 +-
doc/board/microchip/mpfs_icicle.rst
| 6 +-
drivers/clk/sifive/Makefile
| 4 +-
drivers/clk/starfive/clk-jh7110-pll.c
| 2 +-
include/configs/ae350.h
| 14 +++--
include/dt-bindings/clock/microchip-mpfs-clock.h
| 29 +-
include/dt-bindings/interrupt-controller/microchip-mpfs-plic.h
| 196 --
include/dt-bindings/interrupt-controller/riscv-hart.h
| 17 --
24 files changed, 597 insertions(+), 632 deletions(-)
delete mode 100644 arch/riscv/dts/microchip-mpfs-icicle-kit.dts
create mode 100644 arch/riscv/dts/mpfs-icicle-kit-fabric.dtsi
rename arch/riscv/dts/{microchip-mpfs-icicle-kit-u-boot.dtsi =>
mpfs-icicle-kit-u-boot.dtsi} (100%)
create mode 100644 arch/riscv/dts/mpfs-icicle-kit.dts
rename arch/riscv/dts/{microchip-mpfs.dtsi => mpfs.dtsi} (57%)
create mode 100644 arch/riscv/include/asm/atomic.h
delete mode 100644
include/dt-bindings/interrupt-controller/microchip-mpfs-plic.h
delete mode 100644 include/dt-bindings/interrupt-controller/riscv-hart.h
Best regards,
Leo
[PATCH v4 2/2] arm: dts: am335x-evm-u-boot: Remove usb0 mode configuration
USB0 dual-role feature is now handled as peripheral only
in ti-musb driver.
Signed-off-by: Julien Panis
---
arch/arm/dts/am335x-evm-u-boot.dtsi | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/dts/am335x-evm-u-boot.dtsi
b/arch/arm/dts/am335x-evm-u-boot.dtsi
index 82a483ae3e28..42eeca8c0499 100644
--- a/arch/arm/dts/am335x-evm-u-boot.dtsi
+++ b/arch/arm/dts/am335x-evm-u-boot.dtsi
@@ -23,10 +23,6 @@
status = "disabled";
};
- {
- dr_mode = "peripheral";
-};
-
{
bootph-all;
};
--
2.37.3
[PATCH v4 1/2] musb-new: ti-musb: Handle usb dual-role feature as peripheral
This prevents from getting some 'No USB device found' error,
in usb_ether_init() function for instance.
Signed-off-by: Julien Panis
---
drivers/usb/musb-new/ti-musb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/musb-new/ti-musb.c b/drivers/usb/musb-new/ti-musb.c
index 3be3f93dd85d..44697dc31387 100644
--- a/drivers/usb/musb-new/ti-musb.c
+++ b/drivers/usb/musb-new/ti-musb.c
@@ -302,6 +302,7 @@ static int ti_musb_wrapper_bind(struct udevice *parent)
dr_mode = usb_get_dr_mode(node);
switch (dr_mode) {
case USB_DR_MODE_PERIPHERAL:
+ case USB_DR_MODE_OTG:
/* Bind MUSB device */
ret = device_bind_driver_to_node(parent,
"ti-musb-peripheral",
--
2.37.3
[PATCH v4 0/2] Fix 'no USB device found' error.
This series fixes the "No USB device found" error for am335x-icev2 and am335x-evmsk. USB0 dual-role feature is now handled as peripheral only in the driver. The error was not produced for am335x-evm because usb0 dr_mode was configured as peripheral in 'am335x-evm-u-boot.dtsi'. This fragment is no longer needed. Signed-off-by: Julien Panis --- Changes in v4: - Handle usb dual-role feature as peripheral in ti-musb driver. - Link to v3: https://lore.kernel.org/r/20230621-fix_usb_ether_init-v3-1-40493e1d7...@baylibre.com Changes in v3: - Remove usb0 dr_mode configuration from 'am335x-evm-u-boot.dtsi'. - Link to v2: https://lore.kernel.org/r/20230621-fix_usb_ether_init-v2-0-ff121f0e8...@baylibre.com Changes in v2: - Drop the modification made in arch/arm/mach-omap2/am33xx/board.c - Configure usb0 dr_mode as peripheral in 'am335x-icev2-u-boot.dtsi' and 'am335x-evmsk-u-boot.dtsi' device trees. - Link to v1: https://lore.kernel.org/r/20230621-fix_usb_ether_init-v1-1-215692399...@baylibre.com --- Julien Panis (2): musb-new: ti-musb: Handle usb dual-role feature as peripheral arm: dts: am335x-evm-u-boot: Remove usb0 mode configuration arch/arm/dts/am335x-evm-u-boot.dtsi | 4 drivers/usb/musb-new/ti-musb.c | 1 + 2 files changed, 1 insertion(+), 4 deletions(-) --- base-commit: 19b77d3d23966a0d6dbb3c86187765f11100fb6f change-id: 20230621-fix_usb_ether_init-4bf4f1135113 Best regards, -- Julien Panis
Re: [PATCH] lib: sparse: allocate blkcnt instead of arbitrary small number
On lun., juin 19, 2023 at 10:21, Mattijs Korpershoek
wrote:
> Hi Qianfan,
>
> Thank you for your review.
>
> On lun., juin 19, 2023 at 14:19, qianfan wrote:
>
>> 在 2023/6/16 21:26, Mattijs Korpershoek 写道:
>>> Commit 62649165cb02 ("lib: sparse: Make CHUNK_TYPE_RAW buffer aligned")
>>> fixed cache alignment for systems with a D-CACHE.
>>>
>>> However it introduced some performance regressions [1] on system
>>> flashing huge images, such as Android.
>>>
>>> On AM62x SK EVM, we also observe such performance penalty:
>>> Sending sparse 'super' 1/2 (768793 KB) OKAY [ 23.954s]
>>> Writing 'super'OKAY [ 75.926s]
>>> Sending sparse 'super' 2/2 (629819 KB) OKAY [ 19.641s]
>>> Writing 'super'OKAY [ 62.849s]
>>> Finished. Total time: 182.474s
>>>
>>> The reason for this is that we use an arbitrary small buffer
>>> (info->blksz * 100) for transferring.
>>>
>>> Fix it by using a bigger buffer (info->blksz * blkcnt) as suggested in
>>> the original's patch review [2].
>>>
>>> With this patch, performance impact is mitigated:
>>> Sending sparse 'super' 1/2 (768793 KB) OKAY [ 24.006s]
>>> Writing 'super'OKAY [ 15.920s]
>>> Sending sparse 'super' 2/2 (629819 KB) OKAY [ 19.651s]
>>> Writing 'super'OKAY [ 14.665s]
>>> Finished. Total time: 74.346s
>>>
>>> [1]
>>> https://lore.kernel.org/r/20221118121323.4009193-1-gary.bis...@boundarydevices.com
>>> [2]
>>> https://lore.kernel.org/r/all/43e4c17c-4483-ec8e-f843-9b4c5569b...@seco.com/
>>>
>>> Fixes: 62649165cb02 ("lib: sparse: Make CHUNK_TYPE_RAW buffer aligned")
>>> Signed-off-by: Mattijs Korpershoek
>>> ---
>>> lib/image-sparse.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/lib/image-sparse.c b/lib/image-sparse.c
>>> index 5ec0f94ab3eb..25aed0604192 100644
>>> --- a/lib/image-sparse.c
>>> +++ b/lib/image-sparse.c
>>> @@ -55,7 +55,7 @@ static lbaint_t write_sparse_chunk_raw(struct
>>> sparse_storage *info,
>>>void *data,
>>>char *response)
>>> {
>>> - lbaint_t n = blkcnt, write_blks, blks = 0, aligned_buf_blks = 100;
>>> + lbaint_t n = blkcnt, write_blks, blks = 0, aligned_buf_blks = blkcnt;
>> Hi:
>>
>> It's a good point that this code report the performance was affected by
>> write large small
>> mmc blks, not memory copy.
>
> I believe memory copy also affects performance, but in my case,
> it has less impact than small mmc blks.
>
> With 62649165cb02 reverted:
> Sending sparse 'super' 1/2 (768793 KB) OKAY [ 23.947s]
> Writing 'super'OKAY [ 12.983s]
> Sending sparse 'super' 2/2 (629819 KB) OKAY [ 19.600s]
> Writing 'super'OKAY [ 12.796s]
> Finished. Total time: 69.430s
>
> With aligned_buf_blks = blkcnt:
> Sending sparse 'super' 1/2 (768793 KB) OKAY [ 24.072s]
> Writing 'super'OKAY [ 16.177s]
> Sending sparse 'super' 2/2 (629819 KB) OKAY [ 19.681s]
> Writing 'super'OKAY [ 14.845s]
> Finished. Total time: 74.919s
>
>>
>> And I can not make sure whether memalign can always alloc such huge
>> memory when we change the
>> aligned_buf_blks to blkcnt.
>
> Could you clarify the concern here? I've dumped blkcnt for my board
> (AM62x SK EVK) and the biggest blkcnt I found was: 131072
>
> With info->blksz = 512, this gives me: 512 * 131072 = 67108864
>
> Which is a memalign (memory alloc) of 64MB. Is 64MB really that big? (I
> don't realize it's that much)
>
>>
>> Could you please set aligned_buf_blks to FASTBOOT_MAX_BLK_WRITE(16384)
>> and test again?
>
> With aligned_buf_blks = FASTBOOT_MAX_BLK_WRITE(16384):
> Sending sparse 'super' 1/2 (768793 KB) OKAY [ 23.912s]
> Writing 'super'OKAY [ 15.780s]
> Sending sparse 'super' 2/2 (629819 KB) OKAY [ 19.581s]
> Writing 'super'OKAY [ 17.192s]
> Finished. Total time: 76.569s
>
> So using FASTBOOT_MAX_BLK_WRITE is slightly worse than using blkcnt.
> But allocations (for blksz = 512) are smaller: 8MB instead of 64MB in my
> example.
>
> I can spin up a v2 with FASTBOOT_MAX_BLK_WRITE but i'm waiting a little
> more feedback before doing so.
Hi Marek, Tom,
What's your take on this ? Can we keep blkcnt or should I respin using
FASTBOOT_MAX_BLK_WRITE ?
I have also tested this on VIM3, on
U-Boot 2023.07-rc6-3-g923de765ee1a:
Sending sparse 'super' 1/13 (114684 KB)OKAY [ 5.442s]
Writing 'super'OKAY [ 5.791s]
Sending sparse 'super' 2/13 (114684 KB)OKAY [ 5.706s]
Writing 'super'OKAY [ 5.607s]
Sending sparse 'super' 3/13 (114684 KB)OKAY [
Re: EFI Secure boot default keys
On Thu, Jul 06, 2023 at 08:23:06AM +, Neil Jones wrote:
> >> >> Please can someone describe the format of the file needed for the
> >> >> default / built-in EFI secure boot keys (ubootefi.var)
> >> >>
> >> >> The only docs I have found suggest its best to enroll the keys from
> >> >> within u-boot onto some removable media, then copy this off and use
> >> >> this as the default, this is not very helpful and doesn't work for me:
> >> >>
> >> >> => fatload mmc 0:1 ${loadaddr} PK.aut
> >> >> 2053 bytes read in 18 ms (111.3 KiB/s)
> >> >> => setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize PK
> >> >> setenv - set environment variables
> >> >>
> >> >> Usage:
> >> >> setenv setenv [-f] name value ...
> >> >> - [forcibly] set environment variable 'name' to 'value ...'
> >> >> setenv [-f] name
> >> >> - [forcibly] delete environment variable 'name'
> >> >>
> >> >> my setenv doesn't support all the extra switches ? This is with
> >> >> 2022.04, all other EFI options seem to be in this release and I can
> >> >> boot unsigned EFI images ok.
> >> >
> >> >Please turn on CONFIG_CMD_NVEDIT_EFI when building your U-Boot.
> >> >
> >> >This option was disabled by the commit:
> >> > commit 3b728f8728fa (tag: efi-2020-01-rc1)
> >> > Author: Heinrich Schuchardt
> >> > Date: Sun Oct 6 15:44:22 2019 +0200
> >> >
> >> > cmd: disable CMD_NVEDIT_EFI by default
> >> >
> >> >The binary size of efi has grown much since in the past, though.
> >> >
> >> >-Takahiro Akashi
> >>
> >> Thanks, I have secure boot working now. A tool to generate the
> >> ubootefi.var offline or even just a description of the file format would
> >> be very useful.
> >
> >Thank you for the suggestion. While I'd like to defer to Heinrich,
> >the C definition of the file format can be found as struct efi_var_file
> >in include/efi_variable.h
> >
>
> Thanks!
>
> >> I have noticed one issue when using ubootefi.var on mmc, when I switch
> >> boot order it wipes out the keys and I have to re-enrol them:
> >>
> >> => fatls mmc 0:1
> >> 3040 ubootefi.var
> >>
> >> 1 file(s), 0 dir(s)
> >
> >I'm not sure that secure boot related variables have been loaded
> >at this point.
>
> This is during initial generation / enrollment of the variables
>
> >Anyhow, please try to enable CONFIG_EFI_VARIABLES_PRESEED with
> >EFI_VAR_FILE_NAME set. Otherwise, those variables will never be
> >restored.
> >(This is another topic that are not described in doc/develop/uefi.)
>
> I have CONFIG_EFI_VARIABLES_PRESEED working, but while generating the file
> ubootefi.var for the first time (without CONFIG_EFI_VARIABLES_PRESEED set)
> you have to follow a specific order, or the file gets overwritten eg:
>
> Working:
>
> efidebug boot order 1 2
> efidebug boot add -b 1 Signed mmc 0:1 /ImageSig.efi
> efidebug boot add -b 2 UnSigned mmc 0:1 /Image
> fatload mmc 0:1 ${loadaddr} PK.aut
> setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize PK
> fatload mmc 0:1 ${loadaddr} KEK.aut
> setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize KEK
> fatload mmc 0:1 ${loadaddr} DB.aut
> setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize db
>
>
> Failing:
>
> setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize PK
> fatload mmc 0:1 ${loadaddr} KEK.aut
> setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize KEK
> fatload mmc 0:1 ${loadaddr} DB.aut
> setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize db
> efidebug boot order 1 2 ### This command overwrites the keys just loaded
Are you sure that "env print -e" shows all the variables including
PK, KEK and db at this point?
Since I don't have enough time to examine this issue, can you please
try to trace efi_var_collect() in efi_var_file.c which is responsible
for enumerating all the non-volatile variables to be saved at each
SET_VARIABLE api call?
-Takahiro Akashi
> Cheers,
>
> Neil
>
> >
> >Thanks,
> >-Takahiro Akashi
> >
> >> => efidebug boot order 2 1
> >> => fatls mmc 0:1
> >> 440 ubootefi.var
> >>
> >> (Size drops from 3040 to 440 bytes and keys have gone)
>
> >
> > From: AKASHI Takahiro
> > Sent: 29 June 2023 02:01
> > To: Neil Jones
> > Cc: u-boot@lists.denx.de
> > Subject: Re: EFI Secure boot default keys
> >
> > On Wed, Jun 28, 2023 at 04:26:58PM +, Neil Jones wrote:
> > > Please can someone describe the format of the file needed for the default
> > > / built-in EFI secure boot keys (ubootefi.var)
> > >
> > > The only docs I have found suggest its best to enroll the keys from
> > > within u-boot onto some removable media, then copy this off and use this
> > > as the default, this is not very helpful and doesn't work for me:
> > >
> > > => fatload mmc 0:1 ${loadaddr} PK.aut
> > > 2053 bytes read in 18 ms (111.3 KiB/s)
> > > => setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize PK
> > > setenv - set environment variables
> > >
> > > Usage:
> > > setenv
Re: [PATCH 3/5] ARM: dts: at91: sam9x60: Change i2c compatible
Hello,
Am Thu, Jul 06, 2023 at 08:32:41AM + schrieb durai.manicka...@microchip.com:
> Hi Alexander,
>
> sam9x60_curiosity and sam9x60ek belongs to same SOC family. So the
> compatible string is updated as "microchip,sam9x60-i2c" in the
> sam9x60.dtsi file. These changes are available in linux-6.4.y branch.
Maybe I was not clear enough. We are talking about U-Boot here. The
whole patch series is for U-Boot and based on U-Boot v2023.07-rc6.
I'm on Linux v6.4 already and things work in Linux. The problem I
have is with EEPROM access in U-Boot.
Greets
Alex
>
> On 06/07/23 01:46, Alexander Dahl wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > From: Alexander Dahl
> >
> > There's a more specific compatible string for the i2c interface, use it.
> >
> > Signed-off-by: Alexander Dahl
> > ---
> >
> > Notes:
> > I²C access to the eeprom did not work though, neither before nor after
> > this change.
> >
> > arch/arm/dts/at91-sam9x60_curiosity.dts | 2 +-
> > arch/arm/dts/sam9x60ek.dts | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/dts/at91-sam9x60_curiosity.dts
> > b/arch/arm/dts/at91-sam9x60_curiosity.dts
> > index da5e19b66b..ae707dd64b 100644
> > --- a/arch/arm/dts/at91-sam9x60_curiosity.dts
> > +++ b/arch/arm/dts/at91-sam9x60_curiosity.dts
> > @@ -21,7 +21,7 @@
> > status = "okay";
> >
> > i2c@600 {
> > - compatible = "atmel,sama5d2-i2c";
> > + compatible =
> > "microchip,sam9x60-i2c";
> > reg = <0x600 0x200>;
> > pinctrl-names = "default";
> > pinctrl-0 = <_flx0>;
> > diff --git a/arch/arm/dts/sam9x60ek.dts b/arch/arm/dts/sam9x60ek.dts
> > index 45e2f4cc40..74016f5e28 100644
> > --- a/arch/arm/dts/sam9x60ek.dts
> > +++ b/arch/arm/dts/sam9x60ek.dts
> > @@ -62,7 +62,7 @@
> > status = "okay";
> >
> > i2c@600 {
> > - compatible = "atmel,sama5d2-i2c";
> > + compatible =
> > "microchip,sam9x60-i2c";
> > reg = <0x600 0x200>;
> > pinctrl-names = "default";
> > pinctrl-0 = <_flx0>;
> > --
> > 2.30.2
> >
--
/"\ ASCII RIBBON | »With the first link, the chain is forged. The first
\ / CAMPAIGN | speech censured, the first thought forbidden, the
X AGAINST | first freedom denied, chains us all irrevocably.«
/ \ HTML MAIL| (Jean-Luc Picard, quoting Judge Aaron Satie)
signature.asc
Description: PGP signature
[PATCH v2 09/11] binman: btool: Add Xilinx Bootgen btool
From: Lukas Funke Add the Xilinx Bootgen as bintool. Xilinx Bootgen is used to create bootable SPL (FSBL in Xilinx terms) images for Zynq/ZynqMP devices. The btool creates a signed version of the SPL. Additionally to signing the key source for the decryption engine can be passend to the boot image. Signed-off-by: Lukas Funke --- Changes in v2: - Pass additional 'keysrc_enc' parameter to Bootgen - Added more information and terms to documentation tools/binman/btool/bootgen.py | 136 ++ 1 file changed, 136 insertions(+) create mode 100644 tools/binman/btool/bootgen.py diff --git a/tools/binman/btool/bootgen.py b/tools/binman/btool/bootgen.py new file mode 100644 index 00..a30268c964 --- /dev/null +++ b/tools/binman/btool/bootgen.py @@ -0,0 +1,136 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2023 Weidmüller Interface GmbH & Co. KG +# Lukas Funke +# +"""Bintool implementation for bootgen + +bootgen allows creating bootable SPL for Zynq(MP) + +Documentation is available via:: +https://www.xilinx.com/support/documents/sw_manuals/xilinx2022_1/ug1283-bootgen-user-guide.pdf + +Source code is available at: + +https://github.com/Xilinx/bootgen + +""" +import tempfile + +from binman import bintool +from u_boot_pylib import tools + +# pylint: disable=C0103 +class Bintoolbootgen(bintool.Bintool): +"""Generate bootable fsbl image for zynq/zynqmp + +This bintools supports running Xilinx "bootgen" in order +to generate a bootable, authenticated image form an SPL. + +""" +def __init__(self, name): +super().__init__(name, 'Xilinx Bootgen', + version_regex=r'^\*\*\*\*\*\* Xilinx Bootgen', + version_args='') + +# pylint: disable=R0913 +def sign(self, arch, spl_elf_fname, pmufw_elf_fname, + psk_fname, ssk_fname, fsbl_config, auth_params, keysrc_enc, + output_fname): +""" Sign SPL elf file and bundle it PMU firmware into an image + +The method bundels the SPL together with a 'Platform Management Unit' +(PMU)[1] firmware into a single bootable image. The image in turn is +signed with the provided 'secondary secret key' (ssk), which in turn is +signed with the 'primary secret key' (ppk). In order to verify the +authenticity of the ppk, it's hash has to be fused into the device +itself. + +In Xilinx terms the SPL is usually called 'FSBL' +(First Stage Boot Loder). The jobs of the SPL and the FSBL are mostly +the same: load bitstream, bootstrap u-boot. + +Args: +arch (str): Xilinx SoC architecture. Currently only 'zynqmp' is +supported. +spl_elf_fname (str): Filename of SPL ELF file. The filename must end +with '.elf' in order for bootgen to recognized it as an ELF +file. Otherwise the start address field is missinterpreted. +pmufw_elf_fname (str): Filename PMU ELF firmware. +psk_fname (str): Filename of the primary secret key (psk). The psk +is a .pem file which holds the RSA private key used for signing +the secondardy secret key. +ssk_fname (str): Filename of the secondary secret key. The ssk +is a .pem file which holds the RSA private key used for signing +the aktual boot firmware. +fsbl_config (str): FSBL config options. A string list of fsbl config +options. Valid values according to [2] are: +"bh_auth_enable": Boot Header Authentication Enable: RSA +authentication of the bootimage is done +excluding the verification of PPK hash and SPK ID. This is +useful for debugging before bricking a device. +"auth_only": Boot image is only RSA signed. FSBL should not be +decrypted. See the +Zynq UltraScale+ Device Technical Reference Manual (UG1085) +for more information. +There are more options which relate to PUF (physical unclonable +functions). Please refer to Xilinx manuals for fruther info. +auth_params (str): Authentication parameter. A semicolon separated +list of authentication parameters. Valid values according to [3] +are: +"ppk_select=<0|1>" - Select which ppk to use +"spk_id=<32-bit spk id>" - Specifies which SPK can be +used or revoked, default is 0x0 +"spk_select=" - To differentiate spk and +user efuses. +"auth_header" - To authenticate headers when no partition +is authenticated. +keysrc_enc (str): This specifies the Key source for encryption. +Valid values according to [3] are: +
[PATCH v2 11/11] binman: etype: Add xilinx_fsbl_auth etype
From: Lukas Funke
This adds a new etype 'xilinx_fsbl_auth'. Using this etype it is possible
to created an authenticated SPL (FSBL in Xilinx terms) for ZynqMP boards.
The etype uses Xilinx Bootgen tools in order to transform the SPL into
a bootable image and sign the image with a given primary and seconrady
public key. For more information to signing the FSBL please refer to the
Xilinx Bootgen documentation.
Here is an example of the etype in use:
spl {
filename = "boot.signed.bin";
xilinx_fsbl_auth {
psk-filename = "psk0.pem";
ssk-filename = "ssk0.pem";
auth-params = "ppk_select=0", "spk_id=0x";
u_boot_spl_nodtb {
};
u_boot_spl_dtb {
};
};
};
For this to work the hash of the primary public key has to be fused
into the ZynqMP device and authentication (RSA_EN) has to be set.
For testing purposes: if ppk hash check should be skipped one can add
the property 'fsbl_config = "bh_auth_enable";' to the etype. However,
this should only be used for testing(!).
Signed-off-by: Lukas Funke
---
Changes in v2:
- Add 'keysrc-enc' property to pass down to Bootgen
- Improved documentation
- Use predictable output names for intermediated results
tools/binman/entries.rst | 53 ++
tools/binman/etype/xilinx_fsbl_auth.py | 213 +
2 files changed, 266 insertions(+)
create mode 100644 tools/binman/etype/xilinx_fsbl_auth.py
diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index c3c5bda881..98ec3c82a5 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -2462,3 +2462,56 @@ may be used instead.
+.. _etype_xilinx_fsbl_auth:
+
+Entry: xilinx-fsbl-auth: Authenticated SPL for booting Xilinx ZynqMP devices
+
+
+Properties / Entry arguments:
+- auth-params: (Optional) Authentication parameters passed to bootgen
+- fsbl-config: (Optional) FSBL parameters passed to bootgen
+- keysrc-enc: (Optional) Key source when using decryption engine
+- pmufw-filename: Filename of PMU firmware. Default: pmu-firmware.elf
+- psk-filename: Filename of primary public key
+- ssk-filename: Filename of secondary public key
+
+The following example builds an authenticated boot image. The fuses of
+the primary public key (ppk) should be fused together with the RSA_EN flag.
+
+Example node::
+
+spl {
+filename = "boot.signed.bin";
+
+xilinx-fsbl-auth {
+psk-filename = "psk0.pem";
+ssk-filename = "ssk0.pem";
+auth-params = "ppk_select=0", "spk_id=0x";
+
+u-boot-spl-nodtb {
+};
+u-boot-spl-pubkey-dtb {
+algo = "sha384,rsa4096";
+required = "conf";
+key-name = "dev";
+};
+};
+};
+
+For testing purposes, e.g. if no RSA_EN should be fused, one could add
+the "bh_auth_enable" flag in the fsbl-config field. This will skip the
+verification of the ppk fuses and boot the image, even if ppk hash is
+invalid.
+
+Example node::
+
+xilinx-fsbl-auth {
+psk-filename = "psk0.pem";
+ssk-filename = "ssk0.pem";
+...
+fsbl-config = "bh_auth_enable";
+...
+};
+
+
+
diff --git a/tools/binman/etype/xilinx_fsbl_auth.py
b/tools/binman/etype/xilinx_fsbl_auth.py
new file mode 100644
index 00..72794ad2bc
--- /dev/null
+++ b/tools/binman/etype/xilinx_fsbl_auth.py
@@ -0,0 +1,213 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (c) 2023 Weidmueller GmbH
+# Written by Lukas Funke
+#
+# Entry-type module for signed ZynqMP boot images (boot.bin)
+#
+
+import tempfile
+
+from collections import OrderedDict
+
+from binman import elf
+from binman.entry import Entry
+
+from dtoc import fdt_util
+
+from u_boot_pylib import tools
+from u_boot_pylib import command
+
+# pylint: disable=C0103
+class Entry_xilinx_fsbl_auth(Entry):
+"""Authenticated SPL for booting Xilinx ZynqMP devices
+
+Properties / Entry arguments:
+- auth-params: (Optional) Authentication parameters passed to bootgen
+- fsbl-config: (Optional) FSBL parameters passed to bootgen
+- keysrc-enc: (Optional) Key source when using decryption engine
+- pmufw-filename: Filename of PMU firmware. Default: pmu-firmware.elf
+- psk-filename: Filename of primary public key
+- ssk-filename: Filename of secondary public key
+
+The following example builds an authenticated boot image. The fuses of
+the primary public key (ppk) should be fused together with the RSA_EN flag.
+
+Example node::
+
+spl {
+filename = "boot.signed.bin";
+
+xilinx-fsbl-auth {
+psk-filename = "psk0.pem";
+ssk-filename = "ssk0.pem";
+auth-params = "ppk_select=0", "spk_id=0x";
+
[PATCH v2 07/11] binman: etype: Add u_boot_spl_pubkey_dtb etype
From: Lukas Funke
This adds a new etype 'u_boot_spl_pubkey_dtb'. The etype adds the public
key from a certificate to the dtb. This creates a '/signature' node which
is turn contains the fields which make up the public key. Usually this
is done by 'mkimage -K'. However, 'binman sign' does not add the public
key to the SPL. This is why the pubkey is added using this etype.
The etype calls the underlying 'fdt_add_pubkey' tool.
Signed-off-by: Lukas Funke
Reviewed-by: Simon Glass
---
Changes in v2:
- Improved rst/python documentation
- Changed u_boot_spl_pubkey_dtb to u-boot-spl-pubkey-dtb in example
tools/binman/entries.rst| 39 +++
tools/binman/etype/u_boot_spl_pubkey_dtb.py | 109
2 files changed, 148 insertions(+)
create mode 100644 tools/binman/etype/u_boot_spl_pubkey_dtb.py
diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index b71af801fd..c3c5bda881 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -1912,6 +1912,45 @@ binman uses that to look up symbols to write into the
SPL binary.
+.. _etype_u_boot_spl_pubkey_dtb:
+
+Entry: u-boot-spl-pubkey-dtb: U-Boot SPL device tree including public key
+-
+
+Properties / Entry arguments:
+- key-name: Public key name without extension (e.g. .crt). Default is
+determined by underlying bintool (fdt_add_pubkey),
+usually 'key'
+- algo: (Optional) Algorithm used for signing. Default is determined by
+underlying bintool (fdt_add_pubkey), usually 'sha1,rsa2048'
+- required: (Optional) If present this indicates that the key must be
+verified for the image / configuration to be
+considered valid
+
+The following example shows an image containing an SPL which
+is packed together with the dtb. Binman will add a signature
+node to the dtb.
+
+Example node::
+
+image {
+...
+spl {
+filename = "spl.bin"
+
+u-boot-spl-nodtb {
+};
+u-boot-spl-pubkey-dtb {
+algo = "sha384,rsa4096";
+required = "conf";
+key-name = "dev";
+};
+};
+...
+}
+
+
+
.. _etype_u_boot_spl_with_ucode_ptr:
Entry: u-boot-spl-with-ucode-ptr: U-Boot SPL with embedded microcode pointer
diff --git a/tools/binman/etype/u_boot_spl_pubkey_dtb.py
b/tools/binman/etype/u_boot_spl_pubkey_dtb.py
new file mode 100644
index 00..e043001b11
--- /dev/null
+++ b/tools/binman/etype/u_boot_spl_pubkey_dtb.py
@@ -0,0 +1,109 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (c) 2023 Weidmueller GmbH
+# Written by Lukas Funke
+#
+# Entry-type module for 'u-boot-spl-pubkey.dtb'
+#
+
+import tempfile
+import os
+
+from binman.etype.blob_dtb import Entry_blob_dtb
+
+from dtoc import fdt_util
+
+from u_boot_pylib import tools
+
+# pylint: disable=C0103
+class Entry_u_boot_spl_pubkey_dtb(Entry_blob_dtb):
+"""U-Boot SPL device tree including public key
+
+Properties / Entry arguments:
+- key-name: Public key name without extension (e.g. .crt). Default is
+determined by underlying bintool (fdt_add_pubkey),
+usually 'key'
+- algo: (Optional) Algorithm used for signing. Default is determined by
+underlying bintool (fdt_add_pubkey), usually 'sha1,rsa2048'
+- required: (Optional) If present this indicates that the key must be
+verified for the image / configuration to be
+considered valid
+
+The following example shows an image containing an SPL which
+is packed together with the dtb. Binman will add a signature
+node to the dtb.
+
+Example node::
+
+image {
+...
+spl {
+filename = "spl.bin"
+
+u-boot-spl-nodtb {
+};
+u-boot-spl-pubkey-dtb {
+algo = "sha384,rsa4096";
+required = "conf";
+key-name = "dev";
+};
+};
+...
+}
+"""
+
+def __init__(self, section, etype, node):
+# Put this here to allow entry-docs and help to work without libfdt
+global state
+from binman import state
+
+super().__init__(section, etype, node)
+self.required_props = ['key-name']
+self.fdt_add_pubkey = None
+self._algo = fdt_util.GetString(self._node, 'algo')
+self._required = fdt_util.GetString(self._node, 'required')
+self._keyname = fdt_util.GetString(self._node, 'key-name')
+
+def ObtainContents(self, fake_size=0):
+""" Add public key to SPL dtb
+
+Add public key which is pointed out by
+'key-name' to node 'signature' in the spl-dtb
+
+This is equivalent to the '-K' option of 'mkimage'
+
+
[PATCH v2 10/11] binman: ftest: Add test for xilinx_fsbl_auth etype
From: Lukas Funke
Add test for the 'xilinx_fsbl_auth' etype
Signed-off-by: Lukas Funke
---
Changes in v2:
- Fixed typo in dts name
tools/binman/ftest.py | 8
tools/binman/test/280_xilinx_fsbl_auth.dts | 23 ++
2 files changed, 31 insertions(+)
create mode 100644 tools/binman/test/280_xilinx_fsbl_auth.dts
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 0ee0ce1155..27a8a37864 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -6686,6 +6686,14 @@ fdt fdtmapExtract the devicetree
blob from the fdtmap
['fit'])
self.assertIn("Node '/fit': Missing tool: 'mkimage'", str(e.exception))
+def testXilinxFsblAuth(self):
+"""Test xilinx_fsbl_auth etype"""
+data = tools.read_file(self.TestFile("key.key"))
+self._MakeInputFile("psk.pem", data)
+self._MakeInputFile("ssk.pem", data)
+self._SetupPmuFwlElf()
+self._SetupSplElf()
+self._DoReadFileRealDtb('280_xilinx_fsbl_auth.dts')
def testSplPubkeyDtb(self):
"""Test u_boot_spl_pubkey_dtb etype"""
diff --git a/tools/binman/test/280_xilinx_fsbl_auth.dts
b/tools/binman/test/280_xilinx_fsbl_auth.dts
new file mode 100644
index 00..a37c5aa072
--- /dev/null
+++ b/tools/binman/test/280_xilinx_fsbl_auth.dts
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/dts-v1/;
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ binman {
+ xilinx-fsbl-auth {
+ filename = "boot.bin";
+
+ psk-filename = "psk.pem";
+ ssk-filename = "ssk.pem";
+ auth-params = "ppk_select=0", "spk_id=0x";
+
+ u-boot-spl-nodtb {
+ };
+ u-boot-spl-dtb {
+ };
+ };
+ };
+};
--
2.30.2
[PATCH v2 08/11] binman: doc: Add documentation for Xilinx Bootgen bintool
From: Lukas Funke Add documentation for the 'bootgen' bintool Signed-off-by: Lukas Funke Reviewed-by: Simon Glass --- (no changes since v1) tools/binman/bintools.rst | 12 1 file changed, 12 insertions(+) diff --git a/tools/binman/bintools.rst b/tools/binman/bintools.rst index 88221adbe1..c8d69f7177 100644 --- a/tools/binman/bintools.rst +++ b/tools/binman/bintools.rst @@ -193,3 +193,15 @@ Normally signing is done using `mkimage` in context of `binman sign`. However, in this process the public key is not added to the stage before u-boot proper. Using `fdt_add_pubkey` the key can be injected to the SPL independent of `mkimage` + + + +Bintool: bootgen: Sign ZynqMP FSBL image +- + +This bintool supports running `bootgen` in order to sign a SPL for ZynqMP +devices. + +The bintool automatically creates an appropriate input image file (.bif) for +bootgen based on the passed arguments. The output is a bootable, +authenticated `boot.bin` file. -- 2.30.2
[PATCH v2 06/11] binman: btool: Add fdt_add_pubkey as btool
From: Lukas Funke
Add btool which calls 'fdt_add_pubkey'
Signed-off-by: Lukas Funke
Reviewed-by: Simon Glass
---
(no changes since v1)
tools/binman/btool/fdt_add_pubkey.py | 67
1 file changed, 67 insertions(+)
create mode 100644 tools/binman/btool/fdt_add_pubkey.py
diff --git a/tools/binman/btool/fdt_add_pubkey.py
b/tools/binman/btool/fdt_add_pubkey.py
new file mode 100644
index 00..a50774200c
--- /dev/null
+++ b/tools/binman/btool/fdt_add_pubkey.py
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2023 Weidmüller Interface GmbH & Co. KG
+# Lukas Funke
+#
+"""Bintool implementation for fdt_add_pubkey"""
+
+from binman import bintool
+
+class Bintoolfdt_add_pubkey(bintool.Bintool):
+"""Add public key to control dtb (spl or u-boot proper)
+
+This bintool supports running `fdt_add_pubkey`.
+
+Normally mkimage adds signature information to the control dtb. However
+binman images are built independent from each other. Thus it is required
+to add the public key separately from mkimage.
+"""
+def __init__(self, name):
+super().__init__(name, 'Generate image for U-Boot')
+
+# pylint: disable=R0913
+def run(self, input_fname, keydir, keyname, required, algo):
+"""Run fdt_add_pubkey
+
+Args:
+input_fname (str): dtb file to sign
+keydir (str): Directory with public key. Optional parameter,
+default value: '.' (current directory)
+keyname (str): Public key name. Optional parameter,
+default value: key
+required (str): If present this indicates that the key must be
+verified for the image / configuration to be considered valid.
+algo (str): Cryptographic algorithm. Optional parameter,
+default value: sha1,rsa2048
+"""
+args = []
+if algo:
+args += ['-a', algo]
+if keydir:
+args += ['-k', keydir]
+if keyname:
+args += ['-n', keyname]
+if required:
+args += ['-r', required]
+
+args += [ input_fname ]
+
+return self.run_cmd(*args)
+
+def fetch(self, method):
+"""Fetch handler for fdt_add_pubkey
+
+This installs fdt_add_pubkey using the apt utility.
+
+Args:
+method (FETCH_...): Method to use
+
+Returns:
+True if the file was fetched and now installed, None if a method
+other than FETCH_BIN was requested
+
+Raises:
+Valuerror: Fetching could not be completed
+"""
+if method != bintool.FETCH_BIN:
+return None
+return self.apt_install('u-boot-tools')
--
2.30.2
[PATCH v2 04/11] binman: doc: Add documentation for fdt_add_pubkey bintool
From: Lukas Funke Add documentation for btool which calls 'fdt_add_pubkey' Signed-off-by: Lukas Funke Reviewed-by: Simon Glass --- (no changes since v1) tools/binman/bintools.rst | 10 ++ 1 file changed, 10 insertions(+) diff --git a/tools/binman/bintools.rst b/tools/binman/bintools.rst index c30e7eb9ff..88221adbe1 100644 --- a/tools/binman/bintools.rst +++ b/tools/binman/bintools.rst @@ -183,3 +183,13 @@ Documentation is available via:: +Bintool: fdt_add_pubkey: Add public key to device tree +- + +This bintool supports running `fdt_add_pubkey` in order to add a public +key coming from a certificate to a device-tree. + +Normally signing is done using `mkimage` in context of `binman sign`. However, +in this process the public key is not added to the stage before u-boot proper. +Using `fdt_add_pubkey` the key can be injected to the SPL independent of +`mkimage` -- 2.30.2
[PATCH v2 00/11] Sign Xilinx ZynqMP SPL/FSBL boot images using binman
From: Lukas Funke
This series adds two etypes to create a verified boot chain for
Xilinx ZynqMP devices. The first etype 'xilinx_fsbl_auth' is used to
create a bootable, signed image for ZynqMP boards using the Xilinx
Bootgen tool. The second etype 'u_boot_spl_pubkey_dtb' is used to add
a '/signature' node to the SPL. The public key in the signature is read
from a certificate file and added using the 'fdt_add_pubkey' tool. The
series also contains the corresponding btool for calling 'bootgen' and
'fdt_add_pubkey'
The following block shows an example on how to use this functionality:
spl {
filename = "boot.signed.bin";
xilinx_fsbl_auth {
psk-filename = "psk0.pem";
ssk-filename = "ssk0.pem";
auth-params = "ppk_select=0", "spk_id=0x";
u_boot_spl_nodtb {
};
u_boot_spl_pubkey_dtb {
algo = "sha384,rsa4096";
required = "conf";
key-name = "dev";
};
};
};
Changes in v2:
- Changed u_boot_spl_pubkey_dtb to u-boot-spl-pubkey-dtb
- Improved rst/python documentation
- Changed u_boot_spl_pubkey_dtb to u-boot-spl-pubkey-dtb in example
- Pass additional 'keysrc_enc' parameter to Bootgen
- Added more information and terms to documentation
- Fixed typo in dts name
- Add 'keysrc-enc' property to pass down to Bootgen
- Improved documentation
- Use predictable output names for intermediated results
Lukas Funke (11):
binman: elf: Check for ELF_TOOLS availability and remove extra
semicolon
binman: Don't decompress data while signing
binman: blob_dtb: Add fake_size argument to ObtainContents()
binman: doc: Add documentation for fdt_add_pubkey bintool
binman: ftest: Add test for u_boot_spl_pubkey_dtb
binman: btool: Add fdt_add_pubkey as btool
binman: etype: Add u_boot_spl_pubkey_dtb etype
binman: doc: Add documentation for Xilinx Bootgen bintool
binman: btool: Add Xilinx Bootgen btool
binman: ftest: Add test for xilinx_fsbl_auth etype
binman: etype: Add xilinx_fsbl_auth etype
tools/binman/bintools.rst | 22 ++
tools/binman/btool/bootgen.py | 136 +
tools/binman/btool/fdt_add_pubkey.py| 67 ++
tools/binman/control.py | 2 +-
tools/binman/elf.py | 10 +-
tools/binman/entries.rst| 92 +
tools/binman/etype/blob_dtb.py | 2 +-
tools/binman/etype/u_boot_spl_pubkey_dtb.py | 109 ++
tools/binman/etype/xilinx_fsbl_auth.py | 213
tools/binman/ftest.py | 42 +++-
tools/binman/test/280_xilinx_fsbl_auth.dts | 23 +++
tools/binman/test/281_spl_pubkey_dtb.dts| 16 ++
12 files changed, 727 insertions(+), 7 deletions(-)
create mode 100644 tools/binman/btool/bootgen.py
create mode 100644 tools/binman/btool/fdt_add_pubkey.py
create mode 100644 tools/binman/etype/u_boot_spl_pubkey_dtb.py
create mode 100644 tools/binman/etype/xilinx_fsbl_auth.py
create mode 100644 tools/binman/test/280_xilinx_fsbl_auth.dts
create mode 100644 tools/binman/test/281_spl_pubkey_dtb.dts
--
2.30.2
[PATCH v2 03/11] binman: blob_dtb: Add fake_size argument to ObtainContents()
From: Lukas Funke
The method 'connect_contents_to_file()' calls ObtainsContents() with
'fake_size' argument. Without providing the argument in the blob_dtb
we are not able to call this method without error.
Signed-off-by: Lukas Funke
Reviewed-by: Simon Glass
---
(no changes since v1)
tools/binman/etype/blob_dtb.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/binman/etype/blob_dtb.py b/tools/binman/etype/blob_dtb.py
index 6a3fbc4775..d543de9f75 100644
--- a/tools/binman/etype/blob_dtb.py
+++ b/tools/binman/etype/blob_dtb.py
@@ -38,7 +38,7 @@ class Entry_blob_dtb(Entry_blob):
self.Raise("Invalid prepend in '%s': '%s'" %
(self._node.name, self.prepend))
-def ObtainContents(self):
+def ObtainContents(self, fake_size=0):
"""Get the device-tree from the list held by the 'state' module"""
self._filename = self.GetDefaultFilename()
self._pathname, _ = state.GetFdtContents(self.GetFdtEtype())
--
2.30.2
[PATCH v2 05/11] binman: ftest: Add test for u_boot_spl_pubkey_dtb
From: Lukas Funke
Add test for u_boot_spl_pubkey_dtb. The test adds a public key to the
dtb and checks if the required nodes will be added to the images dtb.
Signed-off-by: Lukas Funke
Reviewed-by: Simon Glass
---
Changes in v2:
- Changed u_boot_spl_pubkey_dtb to u-boot-spl-pubkey-dtb
tools/binman/ftest.py| 32
tools/binman/test/281_spl_pubkey_dtb.dts | 16
2 files changed, 48 insertions(+)
create mode 100644 tools/binman/test/281_spl_pubkey_dtb.dts
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 43b4f850a6..0ee0ce1155 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -638,6 +638,16 @@ class TestFunctional(unittest.TestCase):
TestFunctional._MakeInputFile('vpl/u-boot-vpl',
tools.read_file(cls.ElfTestFile(src_fname)))
+@classmethod
+def _SetupPmuFwlElf(cls, src_fname='bss_data'):
+"""Set up an ELF file with a '_dt_ucode_base_size' symbol
+
+Args:
+Filename of ELF file to use as VPL
+"""
+TestFunctional._MakeInputFile('pmu-firmware.elf',
+tools.read_file(cls.ElfTestFile(src_fname)))
+
@classmethod
def _SetupDescriptor(cls):
with open(cls.TestFile('descriptor.bin'), 'rb') as fd:
@@ -6677,5 +6687,27 @@ fdt fdtmapExtract the devicetree
blob from the fdtmap
self.assertIn("Node '/fit': Missing tool: 'mkimage'", str(e.exception))
+def testSplPubkeyDtb(self):
+ """Test u_boot_spl_pubkey_dtb etype"""
+ data = tools.read_file(self.TestFile("key.pem"))
+ self._MakeInputFile("key.crt", data)
+ self._DoReadFileRealDtb('281_spl_pubkey_dtb.dts')
+ image = control.images['image']
+ entries = image.GetEntries()
+ dtb_entry = entries['u-boot-spl-pubkey-dtb']
+ dtb_data = dtb_entry.GetData()
+ dtb = fdt.Fdt.FromData(dtb_data)
+ dtb.Scan()
+
+ signature_node = dtb.GetNode('/signature')
+ self.assertIsNotNone(signature_node)
+ key_node = signature_node.FindNode("key-key")
+ self.assertIsNotNone(key_node)
+ self.assertEqual(fdt_util.GetString(key_node, "required"),
+ "conf")
+ self.assertEqual(fdt_util.GetString(key_node, "algo"),
+ "sha384,rsa4096")
+ self.assertEqual(fdt_util.GetString(key_node, "key-name-hint"),
+ "key")
if __name__ == "__main__":
unittest.main()
diff --git a/tools/binman/test/281_spl_pubkey_dtb.dts
b/tools/binman/test/281_spl_pubkey_dtb.dts
new file mode 100644
index 00..f845db66f5
--- /dev/null
+++ b/tools/binman/test/281_spl_pubkey_dtb.dts
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/dts-v1/;
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ binman {
+ u-boot-spl-pubkey-dtb {
+ algo = "sha384,rsa4096";
+ required = "conf";
+ key-name = "key";
+ };
+ };
+};
--
2.30.2
[PATCH v2 02/11] binman: Don't decompress data while signing
From: Lukas Funke While signing a fit compressed data (i.e. 'blob-ext') is decompressed, but never compressed again. When compressed data was wrapped in a section, decompression leads to an error because the outer section had the original compressed size but the inner entry has the uncompressed size now. While singing there is no reason to decompress data. Thus, decompression should be disabled. Furthermore, bintools should be collected before loading the data. This way bintools are available if processing is required on a node. Signed-off-by: Lukas Funke Reviewed-by: Simon Glass --- (no changes since v1) tools/binman/control.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/binman/control.py b/tools/binman/control.py index 68597c4e77..affc33ff3d 100644 --- a/tools/binman/control.py +++ b/tools/binman/control.py @@ -306,8 +306,8 @@ def BeforeReplace(image, allow_resize): image: Image to prepare """ state.PrepareFromLoadedData(image) -image.LoadData() image.CollectBintools() +image.LoadData(decomp=False) # If repacking, drop the old offset/size values except for the original # ones, so we are only left with the constraints. -- 2.30.2
[PATCH v2 01/11] binman: elf: Check for ELF_TOOLS availability and remove extra semicolon
From: Lukas Funke
Check if elf tools are available when running DecodeElf(). Also
remove superfuous semicolon at line ending.
Signed-off-by: Lukas Funke
Reviewed-by: Simon Glass
---
(no changes since v1)
tools/binman/elf.py | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/tools/binman/elf.py b/tools/binman/elf.py
index 5816284c32..a53f4b9c4f 100644
--- a/tools/binman/elf.py
+++ b/tools/binman/elf.py
@@ -438,13 +438,15 @@ def DecodeElf(data, location):
Returns:
ElfInfo object containing information about the decoded ELF file
"""
+if not ELF_TOOLS:
+raise ValueError("Python: No module named 'elftools'")
file_size = len(data)
with io.BytesIO(data) as fd:
elf = ELFFile(fd)
-data_start = 0x;
-data_end = 0;
-mem_end = 0;
-virt_to_phys = 0;
+data_start = 0x
+data_end = 0
+mem_end = 0
+virt_to_phys = 0
for i in range(elf.num_segments()):
segment = elf.get_segment(i)
--
2.30.2
Re: [PATCH 2/5] ARM: dts: at91: sam9x60-curiosity: Fix EEPROM type
On 7/6/23 11:06, Eugen Hristev wrote:
On 7/5/23 23:16, Alexander Dahl wrote:
From: Alexander Dahl
The user guide says it's a Microchip 24AA025E48 serial EEPROM, which is
a 2-Kbit I2C Serial EEPROM with EUI-48™ Identity. This is the chip
actually populated on board EV40E67A rev 4.
Signed-off-by: Alexander Dahl
---
Notes:
Sadly this did not fix the problem, that I could not access that
eeprom through I²C.
arch/arm/dts/at91-sam9x60_curiosity.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/at91-sam9x60_curiosity.dts
b/arch/arm/dts/at91-sam9x60_curiosity.dts
index d6ae3d648d..da5e19b66b 100644
--- a/arch/arm/dts/at91-sam9x60_curiosity.dts
+++ b/arch/arm/dts/at91-sam9x60_curiosity.dts
@@ -31,7 +31,7 @@
status = "okay";
eeprom@53 {
- compatible = "atmel,24c32";
+ compatible = "atmel,24c02";
reg = <0x53>;
pagesize = <16>;
};
Hello Alexander,
Thank you for the patch.
I remember I tested this a while back and I remember that the 24c32
compatible is not correct for this eeprom.
I have this commit that fixed it for sam9x60ek board:
commit 5ae89b3cfe842ecbb5153a95e2e3ac404abe543c
Author: Eugen Hristev
Date: Thu May 26 17:04:56 2022 +0300
ARM: dts: at91: sam9x60ek: fix eeprom compatible
24c32 should be 32K and 24c02 is 2K .
I remember that with 24c32 it works, but when you read , the offset
changes, and then you read the same data multiple times, as if the 2K is
multiplied to have the 32K the driver thinks it has.
Do you have any reasoning for wanting to change the compatible to 24c32 ?
I am trying to understand how you found that 24c32 is better.
Eugen
I am sorry, I misread your patch. You are doing the exact opposite,
which appears to be correct ! Ignore the noise.
Re: [PATCH 2/5] ARM: dts: at91: sam9x60-curiosity: Fix EEPROM type
On 7/5/23 23:16, Alexander Dahl wrote:
From: Alexander Dahl
The user guide says it's a Microchip 24AA025E48 serial EEPROM, which is
a 2-Kbit I2C Serial EEPROM with EUI-48™ Identity. This is the chip
actually populated on board EV40E67A rev 4.
Signed-off-by: Alexander Dahl
---
Notes:
Sadly this did not fix the problem, that I could not access that
eeprom through I²C.
arch/arm/dts/at91-sam9x60_curiosity.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/at91-sam9x60_curiosity.dts
b/arch/arm/dts/at91-sam9x60_curiosity.dts
index d6ae3d648d..da5e19b66b 100644
--- a/arch/arm/dts/at91-sam9x60_curiosity.dts
+++ b/arch/arm/dts/at91-sam9x60_curiosity.dts
@@ -31,7 +31,7 @@
status = "okay";
eeprom@53 {
- compatible = "atmel,24c32";
+ compatible = "atmel,24c02";
reg = <0x53>;
pagesize = <16>;
};
Hello Alexander,
Thank you for the patch.
I remember I tested this a while back and I remember that the 24c32
compatible is not correct for this eeprom.
I have this commit that fixed it for sam9x60ek board:
commit 5ae89b3cfe842ecbb5153a95e2e3ac404abe543c
Author: Eugen Hristev
Date: Thu May 26 17:04:56 2022 +0300
ARM: dts: at91: sam9x60ek: fix eeprom compatible
24c32 should be 32K and 24c02 is 2K .
I remember that with 24c32 it works, but when you read , the offset
changes, and then you read the same data multiple times, as if the 2K is
multiplied to have the 32K the driver thinks it has.
Do you have any reasoning for wanting to change the compatible to 24c32 ?
I am trying to understand how you found that 24c32 is better.
Eugen
Re: [PATCH] ARM: dts: imx: Fix eMMC boot on Data Modul i.MX8M Plus eDM SBC
On 7/6/2023 7:26 AM, Marek Vasut wrote:
In case the i.MX8M Plus starts from eMMC BOOT1/BOOT2 HW partitions, the
flash.bin container is stored at offset 0 from the start, that means the
fitImage itb is at offset 0x2c0 instead of 0x300 sectors from the start.
Handle this difference in custom spl_mmc_get_uboot_raw_sector() .
Signed-off-by: Marek Vasut
Reviewed-by: Peng Fan
---
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Stefano Babic
---
board/data_modul/imx8mp_edm_sbc/spl.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/board/data_modul/imx8mp_edm_sbc/spl.c
b/board/data_modul/imx8mp_edm_sbc/spl.c
index c30185e48d4..2fdd95a730c 100644
--- a/board/data_modul/imx8mp_edm_sbc/spl.c
+++ b/board/data_modul/imx8mp_edm_sbc/spl.c
@@ -107,6 +107,20 @@ void board_boot_order(u32 *spl_boot_list)
spl_boot_list[4] = BOOT_DEVICE_NONE;
}
+unsigned long spl_mmc_get_uboot_raw_sector(struct mmc *mmc, unsigned long sect)
+{
+ const u32 boot_dev = spl_boot_device();
+ int part;
+
+ if (boot_dev == BOOT_DEVICE_MMC2) { /* eMMC */
+ part = spl_mmc_emmc_boot_partition(mmc);
+ if (part == 1 || part == 2) /* eMMC BOOT1/BOOT2 HW
partitions */
+ return sect - 0x40;
+ }
+
+ return sect;
+}
+
static struct dram_timing_info *dram_timing_info[8] = {
_imx8mp_sbc_dram_timing_32_32, /* 32 Gbit x32 */
NULL, /* 32 Gbit x16 */
RE: [GIT PULL] Please pull u-boot-mmc master
Dear Tom, > -Original Message- > From: U-Boot On Behalf Of Jaehoon Chung > Sent: Tuesday, July 4, 2023 10:29 AM > To: U-Boot Mailing List > Cc: Tom Rini ; Hai Pham ; Marek > Vasut ; > Pali Rohár ; alentine Barshak > ; Jae hoon Chung > ; Peng Fan > Subject: [GIT PULL] Please pull u-boot-mmc master > > Dear Tom, > > Please pull u-boot-mmc master into u-boot master branch. > If there is any problem, let me know, plz. Sorry for too late. > > Those patches are the fixing reensas-sdhi tuning command error and improve > the comment. > (I have also tested with this patchset on my board.) Discard this PR. I will resend PR for next with other patches. Best Regards, Jaehoon Chung > > Best Regards, > Jaehoon Chung > > CI: > https://protect2.fireeye.com/v1/url?k=3413c387-6b8feaad-341248c8-000babe598f7- > 1d8ae2363cc60248=1=aa47dcdd-bf48-4c74-8476-5a86c94862a1=https%3A%2F%2Fsource.denx.de%2Fu- > boot%2Fcustodians%2Fu-boot-mmc%2F-%2Fpipelines%2F16765 > > > The following changes since commit e1bebc16e1d9aa0ddd56c53c0b781f7186dce557: > > Prepare v2023.07-rc6 (2023-07-03 13:48:58 -0400) > > are available in the Git repository at: > > g...@source.denx.de:u-boot/custodians/u-boot-mmc.git master > > for you to fetch changes up to 40825dbac96542e914df4baa3aa0252a503b6b88: > > mmc: Set clock when reverting to safe bus mode (2023-07-04 08:14:18 +0900) > > > Hai Pham (2): > mmc: Introduce mmc_send_stop_transmission() > mmc: renesas-sdhi: Send stop when MMC tuning command fails > > Marek Vasut (1): > mmc: Fix MMC_CMD_STOP_TRANSMISSION response type and add comment > > Pali Rohár (1): > mmc: spl: Add comments for default_spl_mmc_emmc_boot_partition() > > Valentine Barshak (1): > mmc: Set clock when reverting to safe bus mode > > common/spl/spl_mmc.c | 42 +++--- > drivers/mmc/mmc.c | 26 ++ > drivers/mmc/renesas-sdhi.c | 11 +++ > include/mmc.h | 2 ++ > 4 files changed, 74 insertions(+), 7 deletions(-)
Re: [PATCH v2 0/2] Fix 'no USB device found' error.
On 06/07/2023 06:53, Tony Lindgren wrote: > * Tom Rini [230703 16:22]: >> On Mon, Jul 03, 2023 at 07:12:47PM +0300, Roger Quadros wrote: >>> Linux DT files are correct. USB0 is a dual-role port so it sets it to 'otg'. >>> u-boot doesn't support 'otg' so we need to override it to 'peripheral' in >>> -u-boot.dtsi >> >> Ah, thanks, that was the missing bit of background information. > > It would be best to parse dual-role feature in the driver to handle it as > peripheral only and keep the dts the same. +1 -- cheers, -roger
