persistent environment
Hello, I'm struggling to setup u-boot to be able to save the environment. The board is Pine64 QuartzPro64. ATF is collabora's: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/trusted-firmware-a.git collabora-enablement-tfa/master 44418fce30938ee483fbfc79cc32fde33753d1aa rkbin is https://github.com/rockchip-linux/rkbin.git master a2a0b89b6c8c612dca5ed9ed8a68db8a07f68bc0 U-boot is: https://source.denx.de/u-boot/u-boot.git master 1630ff26cc960439b5949b80cfc604a2c8aa47dd export BL31=../trusted-firmware-a/build/rk3588/release/bl31/bl31.elf export ROCKCHIP_TPL=../rkbin/bin/rk35/rk3588_ddr_lp4_2112MHz_lp5_2736MHz_eyescan_v1.11.bin make quartzpro64-rk3588_defconfig make CROSS_COMPILE=aarch64-linux-gnu- SD card is GPT partitionned: Device Start End Sectors Size Type /dev/mmcblk1p1 64 16383 163208M Linux filesystem /dev/mmcblk1p2 16384 32767 163848M Linux filesystem /dev/mmcblk1p3 32768 65535 32768 16M Linux filesystem /dev/mmcblk1p4 65536 1114111 1048576 512M EFI System /dev/mmcblk1p5 1114112 8388607 7274496 3.5G Linux filesystem I put on: * mmcblk1p1: idbloader.img * mmcblk1p2: u-boot.itb environment should be on : mmcblk1p3 I tried to use: CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_MMC_ENV_DEV=1 CONFIG_SYS_MMC_ENV_PART=3 CONFIG_ENV_SIZE=0x1f000 CONFIG_ENV_OFFSET=0x3f8000 I tried to add: * USE_ENV_MMC_PARTITION I tried to change ENV_OFFSET to 0x0 I'm getting: Loading Environment from MMC... MMC partition switch failed *** Warning - MMC partition switch failed, using default environment [...] => env info env_valid = valid env_ready = true env_use_default = true => env erase Erasing Environment on MMC... MMC partition switch failed MMC partition switch failed Failed (1) => env select MMC Select Environment on MMC: OK => env select MMC 1:3 Select Environment on MMC: OK => env erase Erasing Environment on MMC... MMC partition switch failed MMC partition switch failed Failed (1) I've attached the config and a more complete serial console log. I'm probably doing something wrong, but I can't see it. I'd like some hints about how to get further. Thanks -- Vincent Legoll DDR 9fffbe1e78 cym 24/02/04-10:09:20,fwver: v1.16 LPDDR4X, 2112MHz channel[0] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=4096MB channel[1] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=4096MB channel[2] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=4096MB channel[3] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=4096MB Manufacturer ID:0x6 CH0 RX Vref:29.3%, TX Vref:22.8%,21.8% CH1 RX Vref:27.9%, TX Vref:23.8%,23.8% CH2 RX Vref:29.7%, TX Vref:22.8%,22.8% CH3 RX Vref:31.8%, TX Vref:22.8%,22.8% change to F1: 528MHz change to F2: 1068MHz change to F3: 1560MHz change to F0: 2112MHz out U-Boot SPL board init U-Boot SPL 2017.09-ge4e124926e-230922 #lxh (Sep 25 2023 - 10:58:38), fwver: v1.13 unknown raw ID 0 0 0 unrecognized JEDEC id bytes: 00, 00, 00 Trying to boot from MMC2 No misc partition Trying fit image at 0x4000 sector ## Verified-boot: 0 ## Checking atf-1 0x0004 ... sha256(ac29204a02...) + OK ## Checking u-boot 0x00a0 ... sha256(c7f492bdd7...) + OK ## Checking fdt-1 0x00ad39e0 ... sha256(e0dcab4e7d...) + OK ## Checking atf-2 0xff10 ... sha256(7341f9cf77...) + OK Jumping to U-Boot(0x00a0) via ARM Trusted Firmware(0x0004) Total: 311.670/475.856 ms NOTICE: BL31: v2.11.0(release):v2.11.0-533-g44418fce3 NOTICE: BL31: Built : 10:42:36, Sep 8 2024 U-Boot 2024.10-rc4-4-g1630ff26cc96 (Sep 08 2024 - 18:41:36 +0200) Model: Pine64 QuartzPro64 DRAM: 16 GiB Core: 338 devices, 31 uclasses, devicetree: separate MMC: mmc@fe2c: 1, mmc@fe2e: 0 Loading Environment from MMC... MMC partition switch failed *** Warning - MMC partition switch failed, using default environment In:serial@feb5 Out: serial@feb5 Err: serial@feb5 Model: Pine64 QuartzPro64 Net: eth0: ethernet@fe1b Hit any key to stop autoboot: 0 => env info env_valid = valid env_ready = true env_use_default = true => env save Saving Environment to MMC... MMC partition switch failed MMC partition switch failed Failed (1) => env erase Erasing Environment on MMC... MMC partition switch failed MMC partition switch failed Failed (1) => env select MMC Select Environment on MMC: OK => env erase Erasing Environment on MMC... MMC partition switch failed MMC partition switch failed Failed (1) => env select MMC 1:3 Select Environment on MMC: OK => env erase Erasing Environment on MMC... MMC partition switch failed MMC partition switch failed Failed (1) => mmc dev 1 switch to partitions #0, OK mmc1 is current device => mmc dev 0 switch to partitions #0, OK mmc0(part 0) is current device => mmc dev 1 switch to partitions #0, OK mmc1 is current device => env select MMC 1:3 Select Environment on MMC: OK => env erase Erasing Environment on MMC... MMC par
Re: [PATCH v3 0/3] efi: Start tidying up memory management
On Sun, Sep 01, 2024 at 04:22:56PM -0600, Simon Glass wrote: > We have been discussing the state of EFI memory management for some > years so I thought it might be best to send a short series showing some > of the issues we have talked about. > > This one just deals with memory allocation. It provides a way to detect > EFI 'page allocations' when U-Boot' malloc() should be used. It should > help us to clean up this area of U-Boot. > > It also updates EFI to use U-Boot memory allocation for the pool. Most > functions use that anyway and it is much more efficient. It also avoids > allocating things 'in space' in conflict with the loaded images. Hi Simon, Thank you for this series. I did test it on top of v2024.10-rc4 with AArch64 simulators (FVP & Qemu), with OS boots and ACS-IR, and I see no regression. Same with sandbox on x86 and the python tests. Best regards, Vincent. > > This series also includes a little patch to show more information in > the index for the EFI pages. > > Note that this series is independent from Sugosh's lmb series[1], > although I believe it will point the way to simplifying some of the > later patches in that series. > > Overall, some issues which should be resolved are: > - allocation inconsistency, e.g. efi_add_protocol() uses malloc() but > efi_dp_dup() does not (this series makes a start) > - change efi_bl_init() to register events later, when the devices are > actually used > - rather than efi_set_bootdev(), provide a bootstd way to take note of > the device images came from and allow EFI to query that when needed > - EFI_LOADER_BOUNCE_BUFFER - can use U-Boot bounce buffers? > > Minor questions on my mind: > - is unaligned access useful? Is there a performance penalty? > - API confusion about whether something is an address or a pointer > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=416441 > > Changes in v3: > - Add new patch to drop the memset() from efi_alloc() > - Drop patch to convert device_path allocation to use malloc() > > Changes in v2: > - Drop patch 'Show more information in efi index' > - Drop patch 'Avoid pool allocation in efi_get_memory_map_alloc()' > - Add the word 'warning', use log_warning() and show the end address > > Simon Glass (3): > efi: Drop the memset() from efi_alloc() > efi: Allow use of malloc() for the EFI pool > efi: Show the location of the bounce buffer > > common/dlmalloc.c| 7 +++ > include/efi_loader.h | 29 - > include/malloc.h | 7 +++ > lib/efi_loader/efi_bootbin.c | 11 > lib/efi_loader/efi_memory.c | 119 --- > 5 files changed, 136 insertions(+), 37 deletions(-) > > -- > 2.34.1 >
Re: [PATCH v4 09/10] tools: mkeficapsule: support generating dynamic GUIDs
On Tue, Jul 02, 2024 at 03:30:49PM +0200, Caleb Connolly wrote:
Hi Caleb,
Thanks for re-spinning this series; it looks very good.
My comments below.
Best regards,
Vincent.
> Add a tool that can generate GUIDs that match those generated internally
> by U-Boot for capsule update fw_images.
Nit picking: I think you are not "adding a tool" anymore but rather, modifying
an existing one.
>
> Dynamic UUIDs in U-Boot work by taking a namespace UUID and hashing it
> with the board compatible and fw_image name.
>
> This tool accepts the same inputs and will produce the same GUID as
> U-Boot would at runtime.
Same here for "this tool".
>
> Signed-off-by: Caleb Connolly
> ---
> doc/mkeficapsule.1 | 23
> tools/Makefile | 3 +
> tools/mkeficapsule.c | 157
> +--
> 3 files changed, 178 insertions(+), 5 deletions(-)
>
> diff --git a/doc/mkeficapsule.1 b/doc/mkeficapsule.1
> index c4c2057d5c7a..bf735295effa 100644
> --- a/doc/mkeficapsule.1
> +++ b/doc/mkeficapsule.1
> @@ -9,8 +9,11 @@ mkeficapsule \- Generate EFI capsule file for U-Boot
> .SH SYNOPSIS
> .B mkeficapsule
> .RI [ options ] " " [ image-blob ] " " capsule-file
>
> +.B mkeficapsule
> +.RI guidgen " " [ GUID ] " " DTB " " IMAGE_NAME...
> +
> .SH "DESCRIPTION"
> The
> .B mkeficapsule
> command is used to create an EFI capsule file to be used by U-Boot for
> firmware
> @@ -41,8 +44,12 @@ format is the same as used in the new uImage format and
> allows for
> multiple binary blobs in a single capsule file.
> This type of image file can be generated by
> .BR mkimage .
>
> +mkeficapsule can also be used to simulate the dynamic GUID generation used to
> +identify firmware images in capsule updates by providing the namespace guid,
> dtb
> +for the board, and a list of firmware images.
> +
> .SH "OPTIONS"
>
> .TP
> .BI "-g\fR,\fB --guid " guid-string
> @@ -112,8 +119,24 @@ at every firmware update.
> .TP
> .B "-d\fR,\fB --dump_sig"
> Dump signature data into *.p7 file
>
> +.SH "GUIDGEN OPTIONS"
> +
> +.TP
> +.B "[GUID]"
> +The namespace/salt GUID, by default this is EFI_CAPSULE_NAMESPACE_GUID.
> +The format is:
> +----
> +
> +.TP
> +.B DTB
> +The device tree blob file for the board.
> +
> +.TP
> +.B IMAGE_NAME...
> +The names of the firmware images to generate GUIDs for.
> +
> .PP
> .SH FILES
> .TP
> .I /EFI/UpdateCapsule
> diff --git a/tools/Makefile b/tools/Makefile
> index ee08a9675df8..7d1b29943471 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -253,8 +253,11 @@ mkeficapsule-objs := generated/lib/uuid.o \
> $(LIBFDT_OBJS) \
> mkeficapsule.o
> hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule
>
> +genguid-objs := generated/lib/uuid.o generated/lib/sha1.o genguid.o
> +hostprogs-$(CONFIG_TOOLS_GENGUID) += genguid
> +
As far as I can tell those lines above should be removed, now that you have
integrated genguid into mkeficapsule.
> mkfwumdata-objs := mkfwumdata.o generated/lib/crc32.o
> HOSTLDLIBS_mkfwumdata += -luuid
> hostprogs-$(CONFIG_TOOLS_MKFWUMDATA) += mkfwumdata
>
> diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
> index 54fb4dee3ee5..593380e4236a 100644
> --- a/tools/mkeficapsule.c
> +++ b/tools/mkeficapsule.c
> @@ -19,12 +19,16 @@
> #include
> #include
> #include
>
> +#include
> #include
>
> #include "eficapsule.h"
>
> +// Matches CONFIG_EFI_CAPSULE_NAMESPACE_GUID
> +#define DEFAULT_NAMESPACE_GUID "8c9f137e-91dc-427b-b2d6-b420faebaf2a"
> +
> static const char *tool_name = "mkeficapsule";
>
> efi_guid_t efi_guid_fm_capsule = EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
> efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID;
> @@ -38,8 +42,9 @@ enum {
> } capsule_type;
>
> static struct option options[] = {
> {"guid", required_argument, NULL, 'g'},
> + {"dtb", required_argument, NULL, 'd'},
I think this option entry should be removed. This seems unused and the existing
`-d' option of mkeficapsule means something completely unrelated ("dump
signature").
> {"index", required_argument, NULL, 'i'},
> {"instance", required_argument, NULL, 'I'},
> {"fw-version", required_argument, NULL, 'v'},
> {"private-key", required_argument, NULL, 'p'},
> @@ -53
[PATCH v2 2/2] bootstd: cros: store partition type in an efi_guid_t
The scan_part() function uses a struct uuid to store the little-endian
partition type GUID, but this structure should be used only to contain a
big-endian UUID. Use an efi_guid_t instead and use guidcmp() for the
comparison.
Suggested-by: Heinrich Schuchardt
Signed-off-by: Vincent Stehlé
Cc: Simon Glass
Cc: Tom Rini
---
Changes for v2:
- Use guidcmp() for the comparison, as suggested by Heinrich.
boot/bootmeth_cros.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/boot/bootmeth_cros.c b/boot/bootmeth_cros.c
index 645b8bed102..676f550ca25 100644
--- a/boot/bootmeth_cros.c
+++ b/boot/bootmeth_cros.c
@@ -147,7 +147,7 @@ static int scan_part(struct udevice *blk, int partnum,
{
struct blk_desc *desc = dev_get_uclass_plat(blk);
struct vb2_keyblock *hdr;
- struct uuid type;
+ efi_guid_t type;
ulong num_blks;
int ret;
@@ -160,10 +160,10 @@ static int scan_part(struct udevice *blk, int partnum,
/* Check for kernel partition type */
log_debug("part %x: type=%s\n", partnum, info->type_guid);
- if (uuid_str_to_bin(info->type_guid, (u8 *)&type, UUID_STR_FORMAT_GUID))
+ if (uuid_str_to_bin(info->type_guid, type.b, UUID_STR_FORMAT_GUID))
return log_msg_ret("typ", -EINVAL);
- if (memcmp(&cros_kern_type, &type, sizeof(type)))
+ if (guidcmp(&cros_kern_type, &type))
return log_msg_ret("typ", -ENOEXEC);
/* Make a buffer for the header information */
--
2.43.0
[PATCH v2 1/2] efi: move guid helper functions to efi.h
Move the guidcmp() and guidcpy() functions to efi.h, near the definition of
the efi_guid_t type those functions deal with.
Signed-off-by: Vincent Stehlé
Cc: Heinrich Schuchardt
Cc: Ilias Apalodimas
Cc: Tom Rini
---
include/efi.h| 10 ++
include/efi_loader.h | 10 --
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/include/efi.h b/include/efi.h
index c3c4b93f860..d5af2139946 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -78,6 +78,16 @@ typedef struct {
u8 b[16];
} efi_guid_t __attribute__((aligned(4)));
+static inline int guidcmp(const void *g1, const void *g2)
+{
+ return memcmp(g1, g2, sizeof(efi_guid_t));
+}
+
+static inline void *guidcpy(void *dst, const void *src)
+{
+ return memcpy(dst, src, sizeof(efi_guid_t));
+}
+
#define EFI_BITS_PER_LONG (sizeof(long) * 8)
/* Bit mask for EFI status code with error */
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 6c993e1a694..ca8fc0820f6 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -21,16 +21,6 @@
struct blk_desc;
struct jmp_buf_data;
-static inline int guidcmp(const void *g1, const void *g2)
-{
- return memcmp(g1, g2, sizeof(efi_guid_t));
-}
-
-static inline void *guidcpy(void *dst, const void *src)
-{
- return memcpy(dst, src, sizeof(efi_guid_t));
-}
-
#if CONFIG_IS_ENABLED(EFI_LOADER)
/**
--
2.43.0
[PATCH v2 0/2] Respin bootstd cros patch into a series of two
Hi, This is a respin of this patch [1] after discussion [2]. Thanks to Simon and Heinrich for their reviews. To use the guidcmp() function, as suggested by Heinrich, we need to make it available to bootmeth_cros.c and I think that the cleanest way to do that is (arguably) to move the guid helper functions to efi.h near the efi_guid_t definition; this is why the original patch has now become a series of two patches. The alternative would be to include efi_loader.h from bootmeth_cros.c but I think this does not sound "right". If this is in fact the preferred approach just let me know and I will respin. There is no difference in the sandbox binaries before/after this series on Arm and on PC, and all the tests I have run on the sandbox are unchanged. Best regards, Vincent. [1] https://patchwork.ozlabs.org/project/uboot/patch/20240627170629.2696427-1-vincent.ste...@arm.com/ [2] https://lists.denx.de/pipermail/u-boot/2024-June/557588.html Vincent Stehlé (2): efi: move guid helper functions to efi.h bootstd: cros: store partition type in an efi_guid_t boot/bootmeth_cros.c | 6 +++--- include/efi.h| 10 ++ include/efi_loader.h | 10 -- 3 files changed, 13 insertions(+), 13 deletions(-) -- 2.43.0
Re: [PATCH] bootstd: cros: store partition type in an efi_guid_t
On Thu, Jun 27, 2024 at 09:28:04PM +0200, Heinrich Schuchardt wrote:
>
Hi Heinrich,
Thanks for your review.
My comments below.
Best regards,
Vincent.
>
> Am 27. Juni 2024 19:06:29 MESZ schrieb "Vincent Stehlé"
> :
> >The scan_part() function uses a struct uuid to store the little-endian
> >partition type GUID, but this structure should be used only to contain a
> >big-endian UUID. Use an efi_guid_t instead.
> >
> >Signed-off-by: Vincent Stehlé
> >Cc: Simon Glass
> >Cc: Tom Rini
> >---
> > boot/bootmeth_cros.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> >diff --git a/boot/bootmeth_cros.c b/boot/bootmeth_cros.c
> >index f015f2e1c75..1f83c14aeab 100644
> >--- a/boot/bootmeth_cros.c
> >+++ b/boot/bootmeth_cros.c
> >@@ -148,7 +148,7 @@ static int scan_part(struct udevice *blk, int partnum,
> > {
> > struct blk_desc *desc = dev_get_uclass_plat(blk);
> > struct vb2_keyblock *hdr;
> >-struct uuid type;
> >+efi_guid_t type;
>
> Does Chrome OS only support GPT partitioning?
>
> > ulong num_blks;
> > int ret;
> >
> >@@ -161,7 +161,7 @@ static int scan_part(struct udevice *blk, int partnum,
> >
> > /* Check for kernel partition type */
> > log_debug("part %x: type=%s\n", partnum, info->type_guid);
> >-if (uuid_str_to_bin(info->type_guid, (u8 *)&type, UUID_STR_FORMAT_GUID))
> >+if (uuid_str_to_bin(info->type_guid, type.b, UUID_STR_FORMAT_GUID))
> > return log_msg_ret("typ", -EINVAL);
>
> struct disk_partition containing a string which is only needed in the CLI
> instead of the 16 byte GUID was a bad idea to start with. Shouldn't we
> replace it or add least add a GUID field instead of first converting to
> string and than back to GUID?
I had a quick look and it seems that converting all those UUIDs from strings to
binary would indeed impact many places; let's separate this longer-term effort
from this change if you agree.
>
> >
> > if (memcmp(&cros_kern_type, &type, sizeof(type)))
>
> You could use the guidcmp() macro here.
Thanks for the tip; I will send a v2 series.
>
> Best regards
>
> Heinrich
>
[PATCH] bootstd: cros: store partition type in an efi_guid_t
The scan_part() function uses a struct uuid to store the little-endian
partition type GUID, but this structure should be used only to contain a
big-endian UUID. Use an efi_guid_t instead.
Signed-off-by: Vincent Stehlé
Cc: Simon Glass
Cc: Tom Rini
---
boot/bootmeth_cros.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/boot/bootmeth_cros.c b/boot/bootmeth_cros.c
index f015f2e1c75..1f83c14aeab 100644
--- a/boot/bootmeth_cros.c
+++ b/boot/bootmeth_cros.c
@@ -148,7 +148,7 @@ static int scan_part(struct udevice *blk, int partnum,
{
struct blk_desc *desc = dev_get_uclass_plat(blk);
struct vb2_keyblock *hdr;
- struct uuid type;
+ efi_guid_t type;
ulong num_blks;
int ret;
@@ -161,7 +161,7 @@ static int scan_part(struct udevice *blk, int partnum,
/* Check for kernel partition type */
log_debug("part %x: type=%s\n", partnum, info->type_guid);
- if (uuid_str_to_bin(info->type_guid, (u8 *)&type, UUID_STR_FORMAT_GUID))
+ if (uuid_str_to_bin(info->type_guid, type.b, UUID_STR_FORMAT_GUID))
return log_msg_ret("typ", -EINVAL);
if (memcmp(&cros_kern_type, &type, sizeof(type)))
--
2.43.0
[PATCH] Proposed changes to dynamic UUIDs v3
Here are the changes that I would like to suggest for the "efi:
CapsuleUpdate: support for dynamic UUIDs" v3 patch series:
- Convert from big-endian UUID to little-endian GUID in
efi_capsule_update_info_gen_ids().
- Fix tmp size and masking in gen_uuid_v5().
- Use UUID_STR_FORMAT_STD in all places where we are dealing with a
big-endian UUID.
- Update all GUIDs constants in the code and in the tests accordingly. This
gets rid of the following broken UUIDs:
5af91295-5a99-f62b-80d7-e9574de87170
8ee418dc-7e00-e156-80a7-274fbbc05ba8
935fe837-fac8-4394-c008-737d8852c60d
fd5db83c-12f3-a46b-80a9-e3007c7ff56e
ffd97379-0956-fa94-c003-8bfcf5cc097b
- Also, a few minor modifications here and there.
Signed-off-by: Vincent Stehlé
Cc: Caleb Connolly
Cc: Tom Rini
Cc: Heinrich Schuchardt
Cc: Ilias Apalodimas
Cc: Simon Glass
Cc: Mario Six
Cc: Alper Nebi Yasak
Cc: Abdellatif El Khlifi
Cc: Richard Hughes
---
include/sandbox_efi_capsule.h | 6 +++---
lib/efi_loader/efi_firmware.c | 14 +++---
lib/uuid.c | 8
test/lib/uuid.c| 12 ++--
.../test_efi_capsule/test_capsule_firmware_fit.py | 4 ++--
.../test_efi_capsule/test_capsule_firmware_raw.py | 8
.../test_capsule_firmware_signed_fit.py| 2 +-
.../test_capsule_firmware_signed_raw.py| 4 ++--
test/py/tests/test_efi_capsule/version.dts | 6 +++---
tools/.gitignore | 1 +
tools/binman/etype/efi_capsule.py | 2 +-
tools/binman/ftest.py | 2 +-
tools/genguid.c| 7 +++
13 files changed, 42 insertions(+), 34 deletions(-)
diff --git a/include/sandbox_efi_capsule.h b/include/sandbox_efi_capsule.h
index 25ac496ea24..6f0de5a1e25 100644
--- a/include/sandbox_efi_capsule.h
+++ b/include/sandbox_efi_capsule.h
@@ -6,9 +6,9 @@
#if !defined(_SANDBOX_EFI_CAPSULE_H_)
#define _SANDBOX_EFI_CAPSULE_H_
-#define SANDBOX_UBOOT_IMAGE_GUID "fd5db83c-12f3-a46b-80a9-e3007c7ff56e"
-#define SANDBOX_UBOOT_ENV_IMAGE_GUID "935fe837-fac8-4394-c008-737d8852c60d"
-#define SANDBOX_FIT_IMAGE_GUID "ffd97379-0956-fa94-c003-8bfcf5cc097b"
+#define SANDBOX_UBOOT_IMAGE_GUID "50980990-5af9-5522-86e2-8f05f4d7313c"
+#define SANDBOX_UBOOT_ENV_IMAGE_GUID "3554b655-b9f0-5240-ace2-6f34c2f7fcca"
+#define SANDBOX_FIT_IMAGE_GUID "8b38adc7-df0c-5769-8b89-c090ca3d07a7"
#define SANDBOX_INCORRECT_GUID "058b7d83-50d5-4c47-a195-60d86ad341c4"
#define UBOOT_FIT_IMAGE"u-boot_bin_env.itb"
diff --git a/lib/efi_loader/efi_firmware.c b/lib/efi_loader/efi_firmware.c
index a8dafe4f01a..f0d0c3fa972 100644
--- a/lib/efi_loader/efi_firmware.c
+++ b/lib/efi_loader/efi_firmware.c
@@ -258,7 +258,7 @@ void efi_firmware_fill_version_info(struct
efi_firmware_image_descriptor *image_
static efi_status_t efi_capsule_update_info_gen_ids(void)
{
int ret, i;
- struct uuid namespace;
+ struct uuid namespace, type;
const char *compatible; /* Full array including null bytes */
struct efi_fw_image *fw_array;
@@ -269,7 +269,7 @@ static efi_status_t efi_capsule_update_info_gen_ids(void)
return EFI_SUCCESS;
ret = uuid_str_to_bin(CONFIG_EFI_CAPSULE_NAMESPACE_UUID,
- (unsigned char *)&namespace, UUID_STR_FORMAT_GUID);
+ (unsigned char *)&namespace, UUID_STR_FORMAT_STD);
if (ret) {
log_debug("%s: CONFIG_EFI_CAPSULE_NAMESPACE_UUID is invalid:
%d\n", __func__, ret);
return EFI_UNSUPPORTED;
@@ -289,12 +289,20 @@ static efi_status_t efi_capsule_update_info_gen_ids(void)
for (i = 0; i < update_info.num_images; i++) {
gen_uuid_v5(&namespace,
- (struct uuid *)&fw_array[i].image_type_id,
+ &type,
compatible, strlen(compatible),
fw_array[i].fw_name,
u16_strsize(fw_array[i].fw_name)
- sizeof(uint16_t),
NULL);
+ /* Convert to little-endian GUID. */
+ fw_array[i].image_type_id = (efi_guid_t)EFI_GUID(
+ be32_to_cpu(type.time_low), be16_to_cpu(type.time_mid),
+ be16_to_cpu(type.time_hi_and_version),
+ type.clock_seq_hi_and_reserved, type.clock_seq_low,
+ type.node[0], type.node[1], type.node[2], type.node[3],
+ type.node[4], type.node[5]);
+
log_debug("Image %ls UUID %pUs\n", fw_array[i].fw_name,
&fw
Re: [PATCH v3 0/7] efi: CapsuleUpdate: support for dynamic UUIDs
On Fri, Jun 21, 2024 at 07:11:28PM +0200, Caleb Connolly wrote:
> On Fri, 21 Jun 2024, 19:06 Vincent Stehlé, wrote:
>
> > On Fri, Jun 21, 2024 at 01:00:51PM +0200, Heinrich Schuchardt wrote:
> > (..)
> > > The current specification is in RFC 9562, 4.1, "Variant field"
> > >
> > > "The variant field consists of a variable number of the most significant
> > > bits of octet 8 of the UUID.
> > >
> > > ...
> > >
> > > Specifically for UUIDs in this document, bits 64 and 65 of the UUID
> > > (bits 0 and 1 of octet 8) MUST be set to 1 and 0 as specified in row 2
> > > of Table 1."
> > >
> > > This reference to byte 8 does not depend on endianness.
> >
> > Hi Heinrich,
> >
> > Agreed, variant is not concerned by the endianness.
> >
> > >
> > > U-Boot's include/uuid.h has:
> > >
> > > /* This is structure is in big-endian */
> > > struct uuid {
> > >
> > > The field time_hi_and_version needs to be stored in big-endian fashion.
> >
> > Thanks! I thought this structure was used to hold either a big-endian UUID
> > or a
> > little-endian GUID, but now you have convinced me.
> >
> > This confirms that the generation of the dynamic GUID is missing something:
> >
> > gen_uuid_v5(&namespace,
> > (struct uuid *)&fw_array[i].image_type_id,
> > compatible, strlen(compatible),
> > fw_array[i].fw_name, u16_strsize(fw_array[i].fw_name)
> > - sizeof(uint16_t),
> > NULL);
> >
> > It is not possible to cast the little-endian efi_guid_t .image_type_id as
> > the
> > big-endian struct uuid output of gen_uuid_v5() like this; we need to
> > convert the
> > three time fields from big to little endianness.
> >
>
> I'm inclined to disagree, the comment above struct uuid in include/uuid.h
> state clearly that the format in memory is always big endian, but that a
> GUID when printed has some fields converted to little endian.
Hi Caleb,
I read the comments above struct uuid differently: the GUID has some fields
little-endian when stored in memory (and can thus not be stored in a struct
uuid after Heinrich's comments).
This is consistent with how it is done in U-Boot in various locations; for
example, the EFI_GUID() macro stores a GUID with its time fields little-endian
in memory. Similarly, the callers of uuid_str_to_bin() or uuid_bin_to_str() with
format UUID_STR_FORMAT_GUID have indeed a little-endian GUID in memory (most
often an efi_guid_t). This is also consistent with the UEFI specification's
16-byte buffer format. [1]
When you have a big-endian UUID in memory, the version field is stored in byte
6, which is consistent with the RFC 9562. [2]
If you convert this big-endian UUID with uuid_bin_to_str() and
UUID_STR_FORMAT_GUID as in genguid, the "time high and version" field's bytes
will be printed with byte 7 first and then byte 6, as per guid_char_order[].
This is in contradiction with the RFC, which shows that the version field ("M")
should be printed first.
If you print the UUID with format 'STD, you will indeed have byte 6 containing
the version field printed first as it should (uuid_char_order[]).
This is confirmed by "uuid -d".
Best regards,
Vincent.
[1] https://uefi.org/specs/UEFI/2.10/Apx_A_GUID_and_Time_Formats.html
[2] https://www.rfc-editor.org/rfc/rfc9562
>
>
> > >
> > >
> > > tools/genguid uses UUID_STR_FORMAT_GUID which prints low-endian which is
> > > typical in the EFI context but not understood by 'uuid -d'. Maybe we
> > > should add a parameter for the output format.
> >
> > My understanding is that there is a single universal string format for both
> > UUIDs and GUIDs, which uuid -d understands, and which has no notion of
> > endianness. (Only the structures in memory have an endianness.)
> > This means we do not need an output format parameter.
> >
> > genguid is calling the new gen_uuid_v5() function, which outputs a
> > big-endian
> > struct uuid. Therefore, genguid should print it with 'STD format, not
> > 'GUID.
> >
> > Best regards,
> > Vincent.
> >
> > >
> > > Best regards
> > >
> > > Heinrich
> >
Re: [PATCH v3 0/7] efi: CapsuleUpdate: support for dynamic UUIDs
On Fri, Jun 21, 2024 at 01:00:51PM +0200, Heinrich Schuchardt wrote:
(..)
> The current specification is in RFC 9562, 4.1, "Variant field"
>
> "The variant field consists of a variable number of the most significant
> bits of octet 8 of the UUID.
>
> ...
>
> Specifically for UUIDs in this document, bits 64 and 65 of the UUID
> (bits 0 and 1 of octet 8) MUST be set to 1 and 0 as specified in row 2
> of Table 1."
>
> This reference to byte 8 does not depend on endianness.
Hi Heinrich,
Agreed, variant is not concerned by the endianness.
>
> U-Boot's include/uuid.h has:
>
> /* This is structure is in big-endian */
> struct uuid {
>
> The field time_hi_and_version needs to be stored in big-endian fashion.
Thanks! I thought this structure was used to hold either a big-endian UUID or a
little-endian GUID, but now you have convinced me.
This confirms that the generation of the dynamic GUID is missing something:
gen_uuid_v5(&namespace,
(struct uuid *)&fw_array[i].image_type_id,
compatible, strlen(compatible),
fw_array[i].fw_name, u16_strsize(fw_array[i].fw_name)
- sizeof(uint16_t),
NULL);
It is not possible to cast the little-endian efi_guid_t .image_type_id as the
big-endian struct uuid output of gen_uuid_v5() like this; we need to convert the
three time fields from big to little endianness.
>
>
> tools/genguid uses UUID_STR_FORMAT_GUID which prints low-endian which is
> typical in the EFI context but not understood by 'uuid -d'. Maybe we
> should add a parameter for the output format.
My understanding is that there is a single universal string format for both
UUIDs and GUIDs, which uuid -d understands, and which has no notion of
endianness. (Only the structures in memory have an endianness.)
This means we do not need an output format parameter.
genguid is calling the new gen_uuid_v5() function, which outputs a big-endian
struct uuid. Therefore, genguid should print it with 'STD format, not 'GUID.
Best regards,
Vincent.
>
> Best regards
>
> Heinrich
Re: [PATCH v3 0/7] efi: CapsuleUpdate: support for dynamic UUIDs
On Wed, Jun 19, 2024 at 10:15:32PM +0300, Ilias Apalodimas wrote:
> Allô Vincent,
Hi Ilias :)
>
> Thanks for testing!
>
> On Wed, 19 Jun 2024 at 17:02, Vincent Stehlé wrote:
> >
> > On Fri, May 31, 2024 at 03:50:34PM +0200, Caleb Connolly wrote:
> > > As more boards adopt support for the EFI CapsuleUpdate mechanism, there
> > > is a growing issue of being able to target updates to them properly. The
> > > current mechanism of hardcoding UUIDs for each board at compile time is
> > > unsustainable, and maintaining lists of GUIDs is similarly cumbersome.
> > >
> > > In this series, I propose that we adopt v5 GUIDs, these are generated
> > > by using a well-known salt GUID as well as board specific information
> > > (like the model/revision), these are hashed together and the result is
> > > truncated to form a new UUID.
> >
> > Dear Caleb,
> >
> > Thank you for working on this proposal, this looks very useful.
> > Indeed, we found out during SystemReady certifications that it is easy for
> > unique ids to be inadvertently re-used, making them thus non-unique.
> >
> > I have a doubt regarding the format of the generated UUIDs, which end up in
> > the
> > ESRT, though.
> >
> > Here is a quick experiment on the sandbox booting with a DTB using the
> > efidebug
> > command.
> >
> > With the patch series, rebased on the master branch:
> >
> > $ make sandbox_defconfig
> > $ make
> > $ ./u-boot --default_fdt
> > ...
> > U-Boot 2024.07-rc4-00028-g1c96225b0b3 (Jun 19 2024 - 15:29:04 +0200)
> > ...
> > Model: sandbox
> > ...
> > Hit any key to stop autoboot: 0
> > => efidebug capsule esrt
> > ...
> >
> > ESRT: fw_resource_count=2
> > ESRT: fw_resource_count_max=2
> > ESRT: fw_resource_version=1
> > [entry 0]==
> > ESRT: fw_class=FD5DB83C-12F3-A46B-80A9-E3007C7FF56E
> > ...
> > [entry 1]==
> > ESRT: fw_class=935FE837-FAC8-4394-C008-737D8852C60D
> > ...
> >
> >
> > $ uuid -d FD5DB83C-12F3-A46B-80A9-E3007C7FF56E
> > encode: STR: fd5db83c-12f3-a46b-80a9-e3007c7ff56e
> > SIV: 336781303264349553179461347850802165102
> > decode: variant: DCE 1.1, ISO/IEC 11578:1996
> > version: 10 (unknown)
> > content: FD:5D:B8:3C:12:F3:04:6B:00:A9:E3:00:7C:7F:F5:6E
> >(not decipherable: unknown UUID version)
> >
> > Version 10 does not look right.
>
> So, this seems to be an endianess problem.
> Looking at RFC4122 only the space ID needs to be in BE.
>
> >
> > $ uuid -d 935FE837-FAC8-4394-C008-737D8852C60D
> > encode: STR: 935fe837-fac8-4394-c008-737d8852c60d
> > SIV: 195894493536133784175416063449172723213
> > decode: variant: reserved (Microsoft GUID)
> > version: 4 (random data based)
> > content: 93:5F:E8:37:FA:C8:03:94:00:08:73:7D:88:52:C6:0D
> >(no semantics: random data only)
> >
> > A reserved Microsoft GUID variant does not look right.
>
> This seems like an existing bug. RFC4122 defines the MS reserved GUIDs
> in the variant as
> 1 1 0Reserved, Microsoft Corporation backward
> compatibility and the existing UUID_VARIANT_MASK is defined as 0xc0...
I think the variant mask 0xc0 is correct:
- The variant field is in the top three bits of the "clock seq high and
reserved" byte, but...
- The variant we want is 1 0 x (do not care for bit 5, a.k.a. "Msb2").
With the mask 0xc0 we can clear the top two bits as we set the top most bit just
after anyway.
...the mask needs to be used correctly, though; see below.
>
> The patch below should work for you (on top of Calebs')
>
> diff --git a/include/uuid.h b/include/uuid.h
> index b38b20d957ef..78ed5839d2d6 100644
> --- a/include/uuid.h
> +++ b/include/uuid.h
> @@ -81,7 +81,7 @@ struct uuid {
> #define UUID_VERSION_SHIFT 12
> #define UUID_VERSION 0x4
>
> -#define UUID_VARIANT_MASK 0xc0
> +#define UUID_VARIANT_MASK 0xb0
> #define UUID_VARIANT_SHIFT 7
> #define UUID_VARIANT 0x1
>
> diff --git a/lib/uuid.c b/lib/uuid.c
> index 89911b06ccc0..73251eaa397e 100644
> --- a/lib/uuid.c
> +++ b/lib/uuid.c
> @@ -411,9 +411,9 @@ void gen_uuid_v5(const struct uuid *namespace,
> struct uuid *uuid, ...)
> memcpy(uuid, hash, sizeof(*uuid));
&
Re: [PATCH v3 6/7] tools: add genguid tool
On Fri, May 31, 2024 at 03:50:40PM +0200, Caleb Connolly wrote:
> Add a tool that can generate GUIDs that match those generated internally
> by U-Boot for capsule update fw_images.
Hi Caleb,
Thanks for working on this.
I think there is a leftover "dtb" option; see below.
Best regards,
Vincent.
>
> Dynamic UUIDs in U-Boot work by taking a namespace UUID and hashing it
> with the board model, compatible, and fw_image name.
>
> This tool accepts the same inputs and will produce the same GUID as
> U-Boot would at runtime.
>
> Signed-off-by: Caleb Connolly
> ---
> doc/genguid.1 | 52 +++
> tools/Kconfig | 7 +++
> tools/Makefile | 3 ++
> tools/genguid.c | 154
>
> 4 files changed, 216 insertions(+)
(...)
> diff --git a/tools/genguid.c b/tools/genguid.c
> new file mode 100644
> index ..e71bc1d48f95
> --- /dev/null
> +++ b/tools/genguid.c
> @@ -0,0 +1,154 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2024 Linaro Ltd.
> + * Author: Caleb Connolly
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +static struct option options[] = {
> + {"dtb", required_argument, NULL, 'd'},
I think this is unused.
> + {"compat", required_argument, NULL, 'c'},
> + {"help", no_argument, NULL, 'h'},
> + {"verbose", no_argument, NULL, 'v'},
> + {"json", no_argument, NULL, 'j'},
> + {NULL, 0, NULL, 0},
> +};
> +
> +static void usage(const char *progname)
> +{
> + fprintf(stderr, "Usage: %s GUID [-v] -c COMPAT NAME...\n", progname);
> + fprintf(stderr,
> + "Generate a v5 GUID for one of more U-Boot fw_images the same
> way U-Boot does at runtime.\n");
> + fprintf(stderr,
> + "\nOptions:\n"
> + " GUID namespace/salt GUID in 8-4-4-4-12
> format\n"
> + " -h, --help display this help and exit\n"
> + " -c, --compat=COMPAT first compatible property in the
> board devicetree\n"
> + " -v, --verboseprint debug messages\n"
> + " -j, --json output in JSON format\n"
> + " NAME... one or more names of fw_images to
> generate GUIDs for\n"
> + );
> + fprintf(stderr, "\nExample:\n");
> + fprintf(stderr, " %s 2a5aa852-b856-4d97-baa9-5c5f4421551f \\\n"
> + "\t-c \"qcom,qrb4210-rb2\" \\\n"
> + "\tQUALCOMM-UBOOT\n", progname);
> +}
> +
> +static size_t u16_strsize(const uint16_t *in)
> +{
> + size_t i = 0, count = UINT16_MAX;
> +
> + while (count-- && in[i])
> + i++;
> +
> + return (i + 1) * sizeof(uint16_t);
> +}
> +
> +int main(int argc, char **argv)
> +{
> + struct uuid namespace;
> + char *namespace_str;
> + char uuid_str[37];
> + char **image_uuids;
> + char *compatible = NULL;
> + uint16_t **images_u16;
> + char **images;
> + int c, n_images;
> + bool debug = false, json = false;
> +
> + if (argc < 2) {
> + usage(argv[0]);
> + return 1;
> + }
> +
> + namespace_str = argv[1];
> +
> + /* The first arg is the GUID so skip it */
> + while ((c = getopt_long(argc, argv, "c:hvj", options, NULL)) != -1) {
> + switch (c) {
> + case 'c':
> + compatible = strdup(optarg);
> + break;
> + case 'h':
> + usage(argv[0]);
> + return 0;
> + case 'v':
> + debug = true;
> + break;
> + case 'j':
> + json = true;
> + break;
> + default:
> + usage(argv[0]);
> + return 1;
> + }
> + }
> +
> + if (!compatible) {
> + fprintf(stderr, "ERROR: Please specify the compatible
> property.\n\n");
> + usage(argv[0]);
> + return 1;
> + }
> +
> + if (uuid_str_to_bin(namespace_str, (unsigned char *)&namespace,
> UUID_STR_FORMAT_GUID)) {
> + fprintf(stderr,
Re: [PATCH v3 0/7] efi: CapsuleUpdate: support for dynamic UUIDs
On Fri, May 31, 2024 at 03:50:34PM +0200, Caleb Connolly wrote: > As more boards adopt support for the EFI CapsuleUpdate mechanism, there > is a growing issue of being able to target updates to them properly. The > current mechanism of hardcoding UUIDs for each board at compile time is > unsustainable, and maintaining lists of GUIDs is similarly cumbersome. > > In this series, I propose that we adopt v5 GUIDs, these are generated > by using a well-known salt GUID as well as board specific information > (like the model/revision), these are hashed together and the result is > truncated to form a new UUID. Dear Caleb, Thank you for working on this proposal, this looks very useful. Indeed, we found out during SystemReady certifications that it is easy for unique ids to be inadvertently re-used, making them thus non-unique. I have a doubt regarding the format of the generated UUIDs, which end up in the ESRT, though. Here is a quick experiment on the sandbox booting with a DTB using the efidebug command. With the patch series, rebased on the master branch: $ make sandbox_defconfig $ make $ ./u-boot --default_fdt ... U-Boot 2024.07-rc4-00028-g1c96225b0b3 (Jun 19 2024 - 15:29:04 +0200) ... Model: sandbox ... Hit any key to stop autoboot: 0 => efidebug capsule esrt ... ESRT: fw_resource_count=2 ESRT: fw_resource_count_max=2 ESRT: fw_resource_version=1 [entry 0]== ESRT: fw_class=FD5DB83C-12F3-A46B-80A9-E3007C7FF56E ... [entry 1]== ESRT: fw_class=935FE837-FAC8-4394-C008-737D8852C60D ... $ uuid -d FD5DB83C-12F3-A46B-80A9-E3007C7FF56E encode: STR: fd5db83c-12f3-a46b-80a9-e3007c7ff56e SIV: 336781303264349553179461347850802165102 decode: variant: DCE 1.1, ISO/IEC 11578:1996 version: 10 (unknown) content: FD:5D:B8:3C:12:F3:04:6B:00:A9:E3:00:7C:7F:F5:6E (not decipherable: unknown UUID version) Version 10 does not look right. $ uuid -d 935FE837-FAC8-4394-C008-737D8852C60D encode: STR: 935fe837-fac8-4394-c008-737d8852c60d SIV: 195894493536133784175416063449172723213 decode: variant: reserved (Microsoft GUID) version: 4 (random data based) content: 93:5F:E8:37:FA:C8:03:94:00:08:73:7D:88:52:C6:0D (no semantics: random data only) A reserved Microsoft GUID variant does not look right. With the master branch, the (hardcoded) GUIDs are ok: $ ./u-boot --default_fdt ... U-Boot 2024.07-rc4-00021-gfe2ce09a075 (Jun 19 2024 - 15:35:08 +0200) ... Model: sandbox ... => efidebug capsule esrt ... ESRT: fw_resource_count=2 ESRT: fw_resource_count_max=2 ESRT: fw_resource_version=1 [entry 0]== ESRT: fw_class=09D7CF52-0720-4710-91D1-08469B7FE9C8 ... [entry 1]== ESRT: fw_class=5A7021F5-FEF2-48B4-AABA-832E777418C0 ... $ uuid -d 09D7CF52-0720-4710-91D1-08469B7FE9C8 encode: STR: 09d7cf52-0720-4710-91d1-08469b7fe9c8 SIV: 13083600744351929150374221048734280136 decode: variant: DCE 1.1, ISO/IEC 11578:1996 version: 4 (random data based) content: 09:D7:CF:52:07:20:07:10:11:D1:08:46:9B:7F:E9:C8 (no semantics: random data only) $ uuid -d 5A7021F5-FEF2-48B4-AABA-832E777418C0 encode: STR: 5a7021f5-fef2-48b4-aaba-832e777418c0 SIV: 120212745678117161641696128857923655872 decode: variant: DCE 1.1, ISO/IEC 11578:1996 version: 4 (random data based) content: 5A:70:21:F5:FE:F2:08:B4:2A:BA:83:2E:77:74:18:C0 (no semantics: random data only) Also, this is what to expect for a v5 UUID [1]: $ uuid -d a8f6ae40-d8a7-58f0-be05-a22f94eca9ec encode: STR: a8f6ae40-d8a7-58f0-be05-a22f94eca9ec SIV: 224591142595989943290477237735758014956 decode: variant: DCE 1.1, ISO/IEC 11578:1996 version: 5 (name based, SHA-1) content: A8:F6:AE:40:D8:A7:08:F0:3E:05:A2:2F:94:EC:A9:EC (not decipherable: truncated SHA-1 message digest only) Best regards, Vincent. [1] https://uuid.ramsey.dev/en/stable/rfc4122/version5.html > > The well-known salt GUID can be specific to the architecture (SoC > vendor), or OEM. It is defined in the board defconfig so that vendors > can easily bring their own. > > Specifically, the following fields are used to generate a GUID for a > particular fw_image: > > * namespace salt > * board compatible (usually the first entry in the dt root compatible > array). > * fw_image name (the string identifying the specific image, especially > relevant for board that can update multiple images). > > == Usag
[PATCH] Fix references to trace doc
The README.trace has been moved and converted to rst in commit dce26c7d56ed
("doc: move README.trace to HTML documentation"); fix all the remaining
references to this file.
Signed-off-by: Vincent Stehlé
Cc: Tom Rini
Cc: Simon Glass
Cc: Heinrich Schuchardt
---
cmd/Kconfig | 4 ++--
doc/develop/tests_sandbox.rst | 2 +-
lib/Kconfig | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 38305197602..f9f271616d3 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -2832,8 +2832,8 @@ config CMD_TRACE
Enables a command to control using of function tracing within
U-Boot. This allows recording of call traces including timing
information. The command can write data to memory for exporting
- for analysis (e.g. using bootchart). See doc/README.trace for full
- details.
+ for analysis (e.g. using bootchart). See doc/develop/trace.rst
+ for full details.
config CMD_AVB
bool "avb - Android Verified Boot 2.0 operations"
diff --git a/doc/develop/tests_sandbox.rst b/doc/develop/tests_sandbox.rst
index bfd3bdb9270..c2824834d07 100644
--- a/doc/develop/tests_sandbox.rst
+++ b/doc/develop/tests_sandbox.rst
@@ -29,7 +29,7 @@ Some of the available tests are:
- test/image/test-imagetools.sh - multi-file images
- test/py/tests/test-fit.py - FIT images
- tracing: test/trace/test-trace.sh tests the tracing system (see
- README.trace)
+ doc/develop/trace.rst)
- verified boot: test/py/tests/test_vboot.py
If you change or enhance any U-Boot subsystem, you should write or expand a
diff --git a/lib/Kconfig b/lib/Kconfig
index 37ac14f7bab..efb77978a65 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -348,7 +348,7 @@ config TRACE
Enables function tracing within U-Boot. This allows recording of call
traces including timing information. The command can write data to
memory for exporting for analysis (e.g. using bootchart).
- See doc/README.trace for full details.
+ See doc/develop/trace.rst for full details.
config TRACE_BUFFER_SIZE
hex "Size of trace buffer in U-Boot"
--
2.43.0
[PATCH] trace: use dynamic string buffer in make_flamegraph()
The str[] buffer declared in make_flamegraph() is used to hold strings
representing the full call-stacks recorded in traces. The size of this
buffer is currently 500 characters and this works well for the documented
examples.
However, it is possible to exhaust this buffer when processing traces
captured when running the UEFI shell on aarch64 sandbox for example.
Indeed, the maximum length needed for such traces can reach 780 characters.
As it is difficult to evaluate the maximum size that would ever be needed
for all the possible traces, let's use a dynamically allocated `abuf'
instead, which we reallocate when needed.
This fixes the following error:
String too short (500 chars)
While at it, fix a few typos in strings and comments.
Signed-off-by: Vincent Stehlé
Cc: Tom Rini
Cc: Simon Glass
Cc: Michal Simek
---
Hi,
This can be verified using the `test_trace.py' pytest as a starting point.
Configure with `sandbox_defconfig' plus the following options:
CONFIG_TRACE=y
CONFIG_TRACE_BUFFER_SIZE=0x0200
CONFIG_TRACE_EARLY=y
CONFIG_TRACE_EARLY_SIZE=0x0100
Build with:
make FTRACE=1 NO_LTO=1
Run the test with:
./test/py/test.py --bd sandbox --build-dir . -k trace -s
Note that no reallocation happens during the test as the initial size of
500 characters is never exhausted; reduce the size manually if you want to
force re-allocation.
Also, make sure to delete /tmp/test_trace between tests.
Best regards,
Vincent Stehlé
tools/proftool.c | 58
1 file changed, 39 insertions(+), 19 deletions(-)
diff --git a/tools/proftool.c b/tools/proftool.c
index fca45e4a5af..c2e38099354 100644
--- a/tools/proftool.c
+++ b/tools/proftool.c
@@ -290,7 +290,7 @@ static void usage(void)
"Options:\n"
" -c \tSpecify config file\n"
" -f \tSpecify output subtype\n"
- " -m \tSpecify Systen.map file\n"
+ " -m \tSpecify System.map file\n"
" -o \tSpecify output file\n"
" -t \tSpecify trace data file (from U-Boot 'trace
calls')\n"
" -v <0-4>\tSpecify verbosity\n"
@@ -306,7 +306,7 @@ static void usage(void)
}
/**
- * h_cmp_offset - bsearch() function to compare two functions bny their offset
+ * h_cmp_offset - bsearch() function to compare two functions by their offset
*
* @v1: Pointer to first function (struct func_info)
* @v2: Pointer to second function (struct func_info)
@@ -431,7 +431,7 @@ static struct func_info *find_func_by_offset(uint offset)
static struct func_info *find_caller_by_offset(uint offset)
{
int low;/* least function that could be a match */
- int high; /* greated function that could be a match */
+ int high; /* greatest function that could be a match */
struct func_info key;
low = 0;
@@ -1352,7 +1352,7 @@ static int write_pages(struct twriter *tw, enum
out_format_t out_format,
}
if (!(func->flags & FUNCF_TRACE)) {
- debug("Funcion '%s' is excluded from trace\n",
+ debug("Function '%s' is excluded from trace\n",
func->name);
skip_count++;
continue;
@@ -1781,7 +1781,8 @@ static int make_flame_tree(enum out_format_t out_format,
*
* This works by maintaining a string shared across all recursive calls. The
* function name for this node is added to the existing string, to make up the
- * full call-stack description. For example, on entry, @str might contain:
+ * full call-stack description. For example, on entry, @str_buf->data might
+ * contain:
*
*"initf_bootstage;bootstage_mark_name"
*^ @base
@@ -1795,18 +1796,18 @@ static int make_flame_tree(enum out_format_t out_format,
* @fout: Output file
* @out_format: Output format to use
* @node: Node to output (pass the whole tree at first)
- * @str: String to use to build the output line (e.g. 500 charas long)
- * @maxlen: Maximum length of string
+ * @str_buf: String buffer to use to build the output line
* @base: Current base position in the string
* @treep: Returns the resulting flamegraph tree
* Returns 0 if OK, -1 on error
*/
static int output_tree(FILE *fout, enum out_format_t out_format,
- const struct flame_node *node, char *str, int maxlen,
+ const struct flame_node *node, struct abuf *str_buf,
int base)
{
const struct flame_node *child;
int pos;
+ char *str = abuf_data(str_buf);
if (node->count) {
if (out_format == OUT_FMT_FLAMEGRAPH_CALLS) {
@@ -1832,18 +1833,29 @@ s
RE: [External] - Re: Issues with bcm2835-host: let firmware manage the clock divisor
Stefan > -Original Message- > From: Stefan Wahren > Sent: Tuesday, May 16, 2023 12:54 AM > To: Vincent Fazio ; Nuno Gonçalves > ; u-boot@lists.denx.de; pbrobin...@gmail.com > Subject: Re: [External] - Re: Issues with bcm2835-host: let firmware manage > the clock divisor > > Am 15.05.23 um 19:57 schrieb Vincent Fazio: > > Stefan > > > > > I'm not sure I understand the question here re DT/OF. The "regression" in > the RPi firmware was noticed both in EDK2 and in U-Boot when reading from > the SD card. The regression was _not_ apparent in RPi Linux, at least from > what I recall from my testing at the time, meaning that whatever the RPi > Linux kernel was doing was working around the issue, which is probably why > the regression happened in the first place since U-Boot/EDK2 are not targets > for support from RPF. > > Okay, are you able to list the effected bootchains (starting from RPi firmware > to Linux)? > > Example for a bootchain: > > RPi firmware -> U-Boot -> Linux As far as I'm aware, the issue [0] documents : RPi Firmware -> U-Boot RPi Firmware -> EDK2 RPi Firmware -> Ultibo I did not notice degraded performance in RPi Linux, presumably due to clock delegation [1] If someone is using linux-stable vs RPi Linux, there may be some variation. This was nearly 2 years ago however, I'm heavily relying on what's been documented in the GH issue [0]. [0] https://github.com/raspberrypi/firmware/issues/1619 [1] https://github.com/raspberrypi/firmware/issues/1619#issuecomment-917370376 -Vincent
RE: [External] - Re: Issues with bcm2835-host: let firmware manage the clock divisor
Stefan > -Original Message- > From: Stefan Wahren > Sent: Monday, May 15, 2023 11:35 AM > To: Vincent Fazio ; Nuno Gonçalves > ; u-boot@lists.denx.de; pbrobin...@gmail.com > Subject: Re: [External] - Re: Issues with bcm2835-host: let firmware manage > the clock divisor > > Hi Vincent, > > Am 15.05.23 um 14:10 schrieb Vincent Fazio: > > All > > > >> -Original Message- > >> From: Stefan Wahren > >> Sent: Sunday, May 14, 2023 1:55 PM > >> To: Nuno Gonçalves ; u-boot@lists.denx.de; Vincent > >> Fazio ; pbrobin...@gmail.com > >> Subject: [External] - Re: Issues with bcm2835-host: let firmware > >> manage the clock divisor > >> > >> Hi Nuno, > >> > >> Am 14.05.23 um 14:06 schrieb Nuno Gonçalves: > >>> Hi, after 85bdd28d2bb0827f311913e00e4e338f8e4e6565 (bcm2835-host: > >>> let firmware manage the clock divisor), Linux fails to start the > >>> eMMC memory on a CM3 most times (but it sometimes also works). > >> > >> thanks for your report. > >> > >>> > >>> I am using Linux mainline and I wonder if this assumes the change in > >>> which this was based also needs to be used in Linux? > >> > >> Yes, this is very likely. But how can U-Boot assume that at least > >> Linux is booting afterwards. How about the other OSes with devicetree > support? > >> > > > > To be fair, I never tested with a linux kernel that was _not_ the RPi > > kernel, > but I did test on test this on 3b+ and CM3. > > > > Feel free to revert; I honestly thought these patches died on the vine a > year or more ago. > > > >>> > >>> In that case I would think it's fair to revert until it comes to mainline. > >> > >> Actually from the original commit i wasn't able to see a real benefit > >> from the change. Shorter boot time? > > > > The purpose of this commit and the previous (0a36afa) was to work > > around an issue with a regression in RPi firmware [0] > > > > Since we couldn't guarantee what firmware payload was being used on an > RPi or that RPF wouldn't make a similar change in the future, it was important > to set the clock to something sane so mmc speeds didn't tank. The first > commit in the series may have been the only necessary commit to work > around the firmware regression, but I heard no negative responses on this > list [1] nor on the related GH issue[2] where others tested them. > > thanks for clarifying. So the regression occured only in EFI and not in Device > Tree / OF use case? I'm not sure I understand the question here re DT/OF. The "regression" in the RPi firmware was noticed both in EDK2 and in U-Boot when reading from the SD card. The regression was _not_ apparent in RPi Linux, at least from what I recall from my testing at the time, meaning that whatever the RPi Linux kernel was doing was working around the issue, which is probably why the regression happened in the first place since U-Boot/EDK2 are not targets for support from RPF. > > > > > [0] https://github.com/raspberrypi/firmware/issues/1619 > > [1] https://lists.denx.de/pipermail/u-boot/2021-November/465992.html > > [2] > > https://github.com/raspberrypi/firmware/issues/1619#issuecomment- > 93175 > > 0755 > > > >> > >>> > >>> Thanks, > >>> Nuno > >> CAUTION: This email originated from outside of the organization. Do > >> not click links or open attachments unless you recognize the sender > >> and know the content is safe. > >
RE: [External] - Re: Issues with bcm2835-host: let firmware manage the clock divisor
All > -Original Message- > From: Stefan Wahren > Sent: Sunday, May 14, 2023 1:55 PM > To: Nuno Gonçalves ; u-boot@lists.denx.de; Vincent > Fazio ; pbrobin...@gmail.com > Subject: [External] - Re: Issues with bcm2835-host: let firmware manage the > clock divisor > > Hi Nuno, > > Am 14.05.23 um 14:06 schrieb Nuno Gonçalves: > > Hi, after 85bdd28d2bb0827f311913e00e4e338f8e4e6565 (bcm2835-host: let > > firmware manage the clock divisor), Linux fails to start the eMMC > > memory on a CM3 most times (but it sometimes also works). > > thanks for your report. > > > > > I am using Linux mainline and I wonder if this assumes the change in > > which this was based also needs to be used in Linux? > > Yes, this is very likely. But how can U-Boot assume that at least Linux is > booting afterwards. How about the other OSes with devicetree support? > To be fair, I never tested with a linux kernel that was _not_ the RPi kernel, but I did test on test this on 3b+ and CM3. Feel free to revert; I honestly thought these patches died on the vine a year or more ago. > > > > In that case I would think it's fair to revert until it comes to mainline. > > Actually from the original commit i wasn't able to see a real benefit from the > change. Shorter boot time? The purpose of this commit and the previous (0a36afa) was to work around an issue with a regression in RPi firmware [0] Since we couldn't guarantee what firmware payload was being used on an RPi or that RPF wouldn't make a similar change in the future, it was important to set the clock to something sane so mmc speeds didn't tank. The first commit in the series may have been the only necessary commit to work around the firmware regression, but I heard no negative responses on this list [1] nor on the related GH issue[2] where others tested them. [0] https://github.com/raspberrypi/firmware/issues/1619 [1] https://lists.denx.de/pipermail/u-boot/2021-November/465992.html [2] https://github.com/raspberrypi/firmware/issues/1619#issuecomment-931750755 > > > > > Thanks, > > Nuno > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe.
Passing ethaddr and eth1addr from FSBL @ 0xfffffc00 not working anymore
Hi, I hope this is the right mailing list to ask beginners questions. I've asked this question also a the Xilinxs forum (Petalinux based board), without much help.. but it must be something simple, but I don't know much about u-boot yet. Previously using Petalinux 2019.1 (not sure which u-boot version, I guess 2019?), I would write environment variables in the FSBL @ address 0xfc00 (ethaddr, and eth1addr) and when u-boot was loaded these variables where automatically added to the u-boot environment, and also use for DCHP etc. Currently this does not seem to happen anymore in Petalinux 2022.2 (u-boot reports version 2022.1). Now, I can add `env import -t 0xfc00 0x300` to the bootcmd, but this appears to me to be post-factum. I.e. I don't think u-boot will not use these variables for TFTP or so. How do I configure u-boot to load the environment again from the above address or is there another way of loading the two MAC addresses from an EEPROM and putting them in the environment at u-boot start-up? Any pointers or advice would be welcome. Thanks! Kind regards, Vincent -- National Institute for Subatomic Physics Nikhef Department of Computer Technology Mobile: +31 (0)646812032 E-mail:v.van.beve...@nikhef.nl
Re: [BUG] issues with new bootflow, uefi and virtio
On Fri, Apr 07, 2023 at 05:31:06PM +1200, Simon Glass wrote:
..
> > When combined with the patch from Mathew[1], it does indeed repair the case
> > of
> > efi boot with two virtio disks, specifically when the first virtio disk is
> > the
> > one we want to boot from.
> > FWIW, the system will not boot when I invert the two virtio disks.
>
> Is this because it only uses the first virtio device? You could check
> your boot_targets variable. With standard boot you can use 'virtio'
> instead of 'vritio0' and it will find any virtio devices.
Hi Simon,
Thank you for the tips; I did not know that you could use a generic `virtio' or
a more specific `virtio0' specification in boot_targets.
By default the boot_targets variable does indeed contain the generic `virtio' in
my case.
Quick tests matrix:
disk image virtio
(#num) blk index
boot_targets (#30) 0 (#31) 1
--- ---
virtio ok FAIL
virtio0 ok (fail)
virtio1 (fail) ok
This is with both patches, on Qemu.
The fails between () are expected.
I find it interesting that specifying `virtio1' does work when the bootable
image is on the second virtio disk, while auto-detection with `virtio' does not
seem to:
virtio1
~~~
=> setenv boot_targets virtio1
=> boot
Scanning for bootflows in all bootdevs
Seq Method State Uclass Part Name Filename
--- -- - --
Scanning global bootmeth 'efi_mgr':
Scanning bootdev 'virtio-blk#31.bootdev':
0 efiready virtio1 virtio-blk#31.bootdev.par efi/boot/bootaa64.efi
** Booting bootflow 'virtio-blk#31.bootdev.part_1' with efi
Using prior-stage device tree
Missing TPMv2 device for EFI_TCG_PROTOCOL
Booting /efi\boot\bootaa64.efi
virtio
~~
=> setenv boot_targets virtio
=> boot
Scanning for bootflows in all bootdevs
Seq Method State Uclass Part Name Filename
--- -- - --
Scanning global bootmeth 'efi_mgr':
Scanning bootdev 'virtio-blk#30.bootdev':
No more bootdevs
--- -- - --
(0 bootflows, 0 valid)
The messages seem to indicate that virtio #31 / 1 was not even considered when
specifying `virtio'.
(Note that I have edited the logs a bit to avoid wrapping lines.)
Best regards,
Vincent.
>
> >
> > Best regards,
> > Vincent.
> >
> > [1]: https://lists.denx.de/pipermail/u-boot/2023-April/514527.html
>
> Regards,
> Simon
Re: [BUG] issues with new bootflow, uefi and virtio
On Thu, Apr 06, 2023 at 06:38:16AM +1200, Simon Glass wrote: (virtio device number 31 vs. blk index 0) > This is strange. Can you try 'dm uclass' to see the sequence number > for the virtio device? I would expect it to be 0, but I might not > fully understand virtio. Hi Simon, Thank you for looking into this. Here is the `dm uclass' extract corresponding to virtio on this Qemu system: uclass 126: virtio 0 * virtio_mmio@a00 @ 7ee977d0, seq 0 1 * virtio_mmio@a000200 @ 7ee97870, seq 1 2 * virtio_mmio@a000400 @ 7ee97910, seq 2 3 * virtio_mmio@a000600 @ 7ee979b0, seq 3 4 * virtio_mmio@a000800 @ 7ee97a50, seq 4 5 * virtio_mmio@a000a00 @ 7ee97af0, seq 5 6 * virtio_mmio@a000c00 @ 7ee97b90, seq 6 7 * virtio_mmio@a000e00 @ 7ee97c30, seq 7 8 * virtio_mmio@a001000 @ 7ee97cd0, seq 8 9 * virtio_mmio@a001200 @ 7ee97d70, seq 9 10 * virtio_mmio@a001400 @ 7ee97e10, seq 10 11 * virtio_mmio@a001600 @ 7ee97eb0, seq 11 12 * virtio_mmio@a001800 @ 7ee97f50, seq 12 13 * virtio_mmio@a001a00 @ 7ee97ff0, seq 13 14 * virtio_mmio@a001c00 @ 7ee98090, seq 14 15 * virtio_mmio@a001e00 @ 7ee98130, seq 15 16 * virtio_mmio@a002000 @ 7ee981d0, seq 16 17 * virtio_mmio@a002200 @ 7ee98270, seq 17 18 * virtio_mmio@a002400 @ 7ee98310, seq 18 19 * virtio_mmio@a002600 @ 7ee983b0, seq 19 20 * virtio_mmio@a002800 @ 7ee98450, seq 20 21 * virtio_mmio@a002a00 @ 7ee984f0, seq 21 22 * virtio_mmio@a002c00 @ 7ee98590, seq 22 23 * virtio_mmio@a002e00 @ 7ee98630, seq 23 24 * virtio_mmio@a003000 @ 7ee986d0, seq 24 25 * virtio_mmio@a003200 @ 7ee98770, seq 25 26 * virtio_mmio@a003400 @ 7ee98810, seq 26 27 * virtio_mmio@a003600 @ 7ee988b0, seq 27 28 * virtio_mmio@a003800 @ 7ee98950, seq 28 29 * virtio_mmio@a003a00 @ 7ee989f0, seq 29 30 * virtio_mmio@a003c00 @ 7ee98a90, seq 30 31 * virtio_mmio@a003e00 @ 7ee98b30, seq 31 (issue with multiple virtio devices) > Please also see this: > > https://patchwork.ozlabs.org/project/uboot/patch/20230402140231.v7.3.Ifa423a8f295b3c11e50821222b0db1e869d0c051@changeid/ > > (or the whole series) Thank you for this patch! When combined with the patch from Mathew[1], it does indeed repair the case of efi boot with two virtio disks, specifically when the first virtio disk is the one we want to boot from. FWIW, the system will not boot when I invert the two virtio disks. Best regards, Vincent. [1]: https://lists.denx.de/pipermail/u-boot/2023-April/514527.html
Re: [BUG] issues with new bootflow, uefi and virtio
On Thu, Apr 06, 2023 at 10:25:15AM +1000, Mathew McBride wrote: .. > I came across the exact same issue a few days ago. Below is a patch which I > believe fixes the problem, by using the devnum of blk uclass (virtio 0) > instead of the sequence number of the parent udevice (e.g virtio-blk#35). Hi Mathew, Thank you for this patch; it works for me and is much simpler that what I had in mind. - Your patch repairs efi with virtio, for Qemu arm and aarch64. - It does not break efi on USB and NVMe (on Qemu). Best regards, Vincent.
[BUG] issues with new bootflow, uefi and virtio
Hi, I am hitting an issue with the new bootflow when booting with UEFI from a virtio device on Qemu Arm. It seems the device number computation in efiload_read_file() does not work in the general virtio case, where it will pick the virtio device number instead of the block device index. On Qemu arm virt machine, many virtio mmio devices are provisioned in the memory map and no assumption can be made on the number of the actual virtio device in use in the general case. This is an extract of the output of `dm tree' on this platform, focused on the virtio device from which I would like to boot: virtio31 [ + ] virtio-mmio |-- virtio_mmio@a003e00 blk0 [ + ] virtio-blk | |-- virtio-blk#31 partition 0 [ + ] blk_partition | | |-- virtio-blk#31:1 partition 1 [ + ] blk_partition | | `-- virtio-blk#31:2 bootdev2 [ + ] virtio_bootdev | `-- virtio-blk#31.bootdev In this extract the actual virtio device number is 31, as will be picked by efiload_read_file(), but the desired block device index is zero, as would be used with e.g. `ls virtio 0'. This can be reproduced for example with Buildroot qemu_aarch64_ebbr_defconfig or qemu_arm_ebbr_defconfig and updating the U-Boot version to v2023.04. This was working properly with U-Boot versions up to v2023.01. This seems to be very specific to virtio, as the numbers align much more nicely for e.g. USB mass storage or NVMe. To help debugging, the following patch forces the device number to zero in the case of virtio, which allows to boot again with UEFI and virtio on Qemu Arm. Hopefully this should give a hint of what is going on. I tried to create a fix by looking for the first child device of UCLASS_BLK, and use its devnum instead in the case of virtio. Sadly, I am not able to confirm if this is a proper fix as I am hitting other boot issues in the case of multiple boot devices of the same class it seems... Vincent. [1]: https://buildroot.org --- boot/bootmeth_efi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c index 6a97ac02ff5..e5b0d8614ff 100644 --- a/boot/bootmeth_efi.c +++ b/boot/bootmeth_efi.c @@ -117,7 +117,9 @@ static int efiload_read_file(struct blk_desc *desc, struct bootflow *bflow) * this can go away. */ media_dev = dev_get_parent(bflow->dev); - snprintf(devnum_str, sizeof(devnum_str), "%x", dev_seq(media_dev)); + snprintf(devnum_str, sizeof(devnum_str), "%x", +device_get_uclass_id(media_dev) == UCLASS_VIRTIO ? 0 : +dev_seq(media_dev)); strlcpy(dirname, bflow->fname, sizeof(dirname)); last_slash = strrchr(dirname, '/'); -- 2.39.2
[PATCH] doc: uefi: fix links
Fix a couple of links so that they are rendered correctly with sphinx. Signed-off-by: Vincent Stehlé Cc: Heinrich Schuchardt Cc: Ilias Apalodimas --- doc/develop/uefi/fwu_updates.rst | 3 ++- doc/develop/uefi/uefi.rst| 4 ++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/doc/develop/uefi/fwu_updates.rst b/doc/develop/uefi/fwu_updates.rst index 72c850a7908..e4709d82b41 100644 --- a/doc/develop/uefi/fwu_updates.rst +++ b/doc/develop/uefi/fwu_updates.rst @@ -27,7 +27,8 @@ metadata. Individual drivers can be added based on the type of storage media, and its partitioning method. Details of the storage device containing the FWU metadata partitions are specified through a U-Boot specific device tree property `fwu-mdata-store`. Please refer to -U-Boot `doc `__ +U-Boot :download:`fwu-mdata-gpt.yaml +` for the device tree bindings. Enabling the FWU Multi Bank Update feature diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst index a944c0fb803..ffe25ca2318 100644 --- a/doc/develop/uefi/uefi.rst +++ b/doc/develop/uefi/uefi.rst @@ -386,8 +386,8 @@ is because the FWU feature supports multiple partitions(banks) of updatable images, and the actual dfu alt number to which the image is to be written to is determined at runtime, based on the value of the update bank to which the image is to be written. For more information -on the FWU Multi Bank Update feature, please refer `doc -`__. +on the FWU Multi Bank Update feature, please refer to +:doc:`/develop/uefi/fwu_updates`. When using the FMP for FIT images, the image index value needs to be set to 1. -- 2.39.1
[PATCH 2/2] efi_selftest: add hii set keyboard layout test case
Add a test for the case when the HII database protocol
set_keyboard_layout() function is called with a NULL key_guid argument.
Signed-off-by: Vincent Stehlé
Cc: Heinrich Schuchardt
Cc: Ilias Apalodimas
---
lib/efi_selftest/efi_selftest_hii.c | 12
1 file changed, 12 insertions(+)
diff --git a/lib/efi_selftest/efi_selftest_hii.c
b/lib/efi_selftest/efi_selftest_hii.c
index eaf3b0995d4..f4b55889e29 100644
--- a/lib/efi_selftest/efi_selftest_hii.c
+++ b/lib/efi_selftest/efi_selftest_hii.c
@@ -564,7 +564,19 @@ out:
*/
static int test_hii_database_set_keyboard_layout(void)
{
+ efi_status_t ret;
+
PRINT_TESTNAME;
+
+ /* Invalid key guid. */
+ ret = hii_database_protocol->set_keyboard_layout(
+ hii_database_protocol, NULL);
+ if (ret != EFI_INVALID_PARAMETER) {
+ efi_st_error("set_keyboard_layout returned %u not invalid\n",
+(unsigned int)ret);
+ return EFI_ST_FAILURE;
+ }
+
/* set_keyboard_layout() not implemented yet */
return EFI_ST_SUCCESS;
}
--
2.39.0
[PATCH 1/2] efi_loader: refine set_keyboard_layout() status
As per the EFI specification, the HII database protocol function
set_keyboard_layout() must return EFI_INVALID_PARAMETER when it is called
with a NULL key_guid argument. Modify the function accordingly to improve
conformance.
Signed-off-by: Vincent Stehlé
Cc: Heinrich Schuchardt
Cc: Ilias Apalodimas
---
lib/efi_loader/efi_hii.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/efi_loader/efi_hii.c b/lib/efi_loader/efi_hii.c
index 27db3be6a17..3b54ecb11ac 100644
--- a/lib/efi_loader/efi_hii.c
+++ b/lib/efi_loader/efi_hii.c
@@ -758,6 +758,9 @@ set_keyboard_layout(const struct efi_hii_database_protocol
*this,
{
EFI_ENTRY("%p, %pUs", this, key_guid);
+ if (!key_guid)
+ return EFI_EXIT(EFI_INVALID_PARAMETER);
+
return EFI_EXIT(EFI_NOT_FOUND);
}
--
2.39.0
[PATCH 0/2] efi: small hii set_keyboard_layout conformance improvement
Hi, The following couple of patches make UEFI HII set_keyboard_layout() more conforming in the case of invalid input parameter and add a selftest. This is sent in this order to avoid breaking `bootefi selftest' in the middle but feel free to apply in any order if preferred. Best regards, Vincent. Vincent Stehlé (2): efi_loader: refine set_keyboard_layout() status efi_selftest: add hii set keyboard layout test case lib/efi_loader/efi_hii.c| 3 +++ lib/efi_selftest/efi_selftest_hii.c | 12 2 files changed, 15 insertions(+) -- 2.39.0
[PATCH v2] efi_selftest: add hii database protocol test cases
Add a couple of tests for the cases when the HII database protocol
get_package_list_handle() function is called with invalid parameters.
Signed-off-by: Vincent Stehlé
Cc: Heinrich Schuchardt
Cc: Ilias Apalodimas
---
Hi,
Thanks Heinrich for your review and feedbacks; here is v2 of this patch.
Best regards,
Vincent.
Changes in v2:
- Change initialization of driver_handle to a non-NULL value, which will
never get allocated.
- Add a second test for the case when driver handle is invalid.
v1 reference(s):
- https://lists.denx.de/pipermail/u-boot/2022-December/502213.html
- https://lists.denx.de/pipermail/u-boot/2023-January/503718.html
lib/efi_selftest/efi_selftest_hii.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/lib/efi_selftest/efi_selftest_hii.c
b/lib/efi_selftest/efi_selftest_hii.c
index eaf3b0995d4..608e3982399 100644
--- a/lib/efi_selftest/efi_selftest_hii.c
+++ b/lib/efi_selftest/efi_selftest_hii.c
@@ -605,6 +605,25 @@ static int test_hii_database_get_package_list_handle(void)
goto out;
}
+ /* Invalid package list handle. */
+ driver_handle = (efi_handle_t)~1UL;
+ ret = hii_database_protocol->get_package_list_handle(
+ hii_database_protocol, NULL, &driver_handle);
+ if (ret != EFI_INVALID_PARAMETER) {
+ efi_st_error("get_package_list_handle returned %u not
invalid\n",
+(unsigned int)ret);
+ goto out;
+ }
+
+ /* Invalid driver handle. */
+ ret = hii_database_protocol->get_package_list_handle(
+ hii_database_protocol, handle, NULL);
+ if (ret != EFI_INVALID_PARAMETER) {
+ efi_st_error("get_package_list_handle returned %u not
invalid\n",
+(unsigned int)ret);
+ goto out;
+ }
+
result = EFI_ST_SUCCESS;
out:
--
2.39.0
Re: [PATCH 2/2] efi_selftest: add hii database protocol test case
On Thu, Dec 22, 2022 at 10:45:22AM +0100, Heinrich Schuchardt wrote:
Hi Heinrich,
Happy new year, and thank you for the reviews.
More comments below.
> On 12/13/22 22:39, Vincent Stehlé wrote:
> > Add a test for the case when the HII database protocol
> > get_package_list_handle() function is called with an invalid package list
> > handle.
> >
> > Signed-off-by: Vincent Stehlé
> > Cc: Heinrich Schuchardt
> > Cc: Ilias Apalodimas
> > ---
> > lib/efi_selftest/efi_selftest_hii.c | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/lib/efi_selftest/efi_selftest_hii.c
> > b/lib/efi_selftest/efi_selftest_hii.c
> > index eaf3b0995d4..8a038d9f534 100644
> > --- a/lib/efi_selftest/efi_selftest_hii.c
> > +++ b/lib/efi_selftest/efi_selftest_hii.c
> > @@ -605,6 +605,16 @@ static int
> > test_hii_database_get_package_list_handle(void)
> > goto out;
> > }
> >
> > + /* Invalid package list handle. */
> > + driver_handle = NULL;
> > + ret = hii_database_protocol->get_package_list_handle(
> > + hii_database_protocol, NULL, &driver_handle);
> > + if (ret != EFI_INVALID_PARAMETER) {
>
> Here it is unclear, if you get EFI_INVALID_PARAMETER because the
> PackageListHandle is invalid or DriverHandle is NULL.
In principle, the value used to initialize the (output) parameter driver_handle
should not affect the test. Also, we are initializing driver_handle in exactly
the same way as was done in the previous test, which we know succeeded.
Anyway, if you think it makes the test more readable I can change the
initialization to something like the following:
driver_handle = (efi_handle_t)0x23456789; /* dummy */
>
> We should test both cases separately.
Would you prefer something like the following couple of tests?
/* Invalid package list handle. */
driver_handle = (efi_handle_t)0x23456789; /* dummy */
ret = hii_database_protocol->get_package_list_handle(
hii_database_protocol, NULL, &driver_handle);
/* Invalid driver handle. */
ret = hii_database_protocol->get_package_list_handle(
hii_database_protocol, handle, NULL);
I could verify that EFI_INVALID_PARAMETER is indeed returned in both cases.
Just let me know and I will post a v2.
Best regards,
Vincent.
>
> Best regards
>
> Heinrich
>
> > + efi_st_error("get_package_list_handle returned %u not
> > invalid\n",
> > +(unsigned int)ret);
> > + goto out;
> > + }
> > +
> > result = EFI_ST_SUCCESS;
> >
> > out:
>
[PATCH] efi: adjust ebbr to v2.1 in conformance profile
The EFI Conformance Profile Table entry for EBBR appears in v2.1.0 of the
EBBR specification[1]. Update naming accordingly.
While at it, update the EBBR version referenced in the documentation.
[1]: https://github.com/ARM-software/ebbr/releases/tag/v2.1.0
Signed-off-by: Vincent Stehlé
Cc: Heinrich Schuchardt
Cc: Ilias Apalodimas
---
doc/develop/uefi/uefi.rst| 6 +++---
include/efi_api.h| 2 +-
lib/efi_loader/Kconfig | 6 +++---
lib/efi_loader/efi_conformance.c | 8
lib/efi_selftest/efi_selftest_ecpt.c | 6 +++---
5 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index e0835beba41..a944c0fb803 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -14,7 +14,7 @@ Development target
--
The implementation of UEFI in U-Boot strives to reach the requirements
described
-in the "Embedded Base Boot Requirements (EBBR) Specification - Release v1.0"
+in the "Embedded Base Boot Requirements (EBBR) Specification - Release v2.1.0"
[2]. The "Server Base Boot Requirements System Software on ARM Platforms" [3]
describes a superset of the EBBR specification and may be used as further
reference.
@@ -799,8 +799,8 @@ Links
-
* [1] http://uefi.org/specifications - UEFI specifications
-* [2]
https://github.com/ARM-software/ebbr/releases/download/v1.0/ebbr-v1.0.pdf -
- Embedded Base Boot Requirements (EBBR) Specification - Release v1.0
+* [2]
https://github.com/ARM-software/ebbr/releases/download/v2.1.0/ebbr-v2.1.0.pdf -
+ Embedded Base Boot Requirements (EBBR) Specification - Release v2.1.0
* [3]
https://developer.arm.com/docs/den0044/latest/server-base-boot-requirements-system-software-on-arm-platforms-version-11
-
Server Base Boot Requirements System Software on ARM Platforms - Version 1.1
* [4] :doc:`iscsi`
diff --git a/include/efi_api.h b/include/efi_api.h
index 9bb0d44ac8d..00c98e0984d 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -232,7 +232,7 @@ enum efi_reset_type {
#define EFI_CONFORMANCE_PROFILES_TABLE_VERSION 1
-#define EFI_CONFORMANCE_PROFILE_EBBR_2_0_GUID \
+#define EFI_CONFORMANCE_PROFILE_EBBR_2_1_GUID \
EFI_GUID(0xcce33c35, 0x74ac, 0x4087, 0xbc, 0xe7, \
0x8b, 0x29, 0xb0, 0x2e, 0xeb, 0x27)
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index e2b643871bf..b498c72206f 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -384,8 +384,8 @@ config EFI_ECPT
help
Enabling this option created the ECPT UEFI table.
-config EFI_EBBR_2_0_CONFORMANCE
- bool "Add the EBBRv2.0 conformance entry to the ECPT table"
+config EFI_EBBR_2_1_CONFORMANCE
+ bool "Add the EBBRv2.1 conformance entry to the ECPT table"
depends on EFI_ECPT
depends on EFI_LOADER_HII
depends on EFI_RISCV_BOOT_PROTOCOL || !RISCV
@@ -393,7 +393,7 @@ config EFI_EBBR_2_0_CONFORMANCE
depends on EFI_UNICODE_COLLATION_PROTOCOL2
default y
help
- Enabling this option adds the EBBRv2.0 conformance entry to the ECPT
UEFI table.
+ Enabling this option adds the EBBRv2.1 conformance entry to the ECPT
UEFI table.
config EFI_RISCV_BOOT_PROTOCOL
bool "RISCV_EFI_BOOT_PROTOCOL support"
diff --git a/lib/efi_loader/efi_conformance.c b/lib/efi_loader/efi_conformance.c
index a49aae92497..3036d46349a 100644
--- a/lib/efi_loader/efi_conformance.c
+++ b/lib/efi_loader/efi_conformance.c
@@ -12,8 +12,8 @@
#include
static const efi_guid_t efi_ecpt_guid = EFI_CONFORMANCE_PROFILES_TABLE_GUID;
-static const efi_guid_t efi_ebbr_2_0_guid =
- EFI_CONFORMANCE_PROFILE_EBBR_2_0_GUID;
+static const efi_guid_t efi_ebbr_2_1_guid =
+ EFI_CONFORMANCE_PROFILE_EBBR_2_1_GUID;
/**
* efi_ecpt_register() - Install the ECPT system table.
@@ -38,9 +38,9 @@ efi_status_t efi_ecpt_register(void)
return ret;
}
- if (CONFIG_IS_ENABLED(EFI_EBBR_2_0_CONFORMANCE))
+ if (CONFIG_IS_ENABLED(EFI_EBBR_2_1_CONFORMANCE))
guidcpy(&ecpt->conformance_profiles[num_entries++],
- &efi_ebbr_2_0_guid);
+ &efi_ebbr_2_1_guid);
ecpt->version = EFI_CONFORMANCE_PROFILES_TABLE_VERSION;
ecpt->number_of_profiles = num_entries;
diff --git a/lib/efi_selftest/efi_selftest_ecpt.c
b/lib/efi_selftest/efi_selftest_ecpt.c
index e8cc13545db..09c5e96c5e1 100644
--- a/lib/efi_selftest/efi_selftest_ecpt.c
+++ b/lib/efi_selftest/efi_selftest_ecpt.c
@@ -10,7 +10,7 @@
#include
static const efi_guid_t guid_ecpt = EFI_CONFORMANCE_PROFILES_TABLE_GUID;
-static const efi_guid_t guid_ebbr_2_0 = EFI_CONFORMANCE_PROFILE_EBBR_2_0_GUID;
+static const efi_guid_t guid_ebbr_2_1 = EFI_CONFORMANCE_PROFILE_EBBR_2_1_GUID;
/*
* ecpt_find_guid() - find GUID in EFI Conformanc
[PATCH 2/2] efi_selftest: add hii database protocol test case
Add a test for the case when the HII database protocol
get_package_list_handle() function is called with an invalid package list
handle.
Signed-off-by: Vincent Stehlé
Cc: Heinrich Schuchardt
Cc: Ilias Apalodimas
---
lib/efi_selftest/efi_selftest_hii.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/lib/efi_selftest/efi_selftest_hii.c
b/lib/efi_selftest/efi_selftest_hii.c
index eaf3b0995d4..8a038d9f534 100644
--- a/lib/efi_selftest/efi_selftest_hii.c
+++ b/lib/efi_selftest/efi_selftest_hii.c
@@ -605,6 +605,16 @@ static int test_hii_database_get_package_list_handle(void)
goto out;
}
+ /* Invalid package list handle. */
+ driver_handle = NULL;
+ ret = hii_database_protocol->get_package_list_handle(
+ hii_database_protocol, NULL, &driver_handle);
+ if (ret != EFI_INVALID_PARAMETER) {
+ efi_st_error("get_package_list_handle returned %u not
invalid\n",
+(unsigned int)ret);
+ goto out;
+ }
+
result = EFI_ST_SUCCESS;
out:
--
2.35.1
[PATCH 1/2] efi_loader: fix get_package_list_handle() status
When the HII protocol function get_package_list_handle() is called with an
invalid package list handle, it returns EFI_NOT_FOUND but this is not in
its list of possible status codes as per the EFI specification.
Return EFI_INVALID_PARAMETER instead to fix conformance.
Signed-off-by: Vincent Stehlé
Cc: Heinrich Schuchardt
Cc: Ilias Apalodimas
---
lib/efi_loader/efi_hii.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_hii.c b/lib/efi_loader/efi_hii.c
index 75ff58aafa5..27db3be6a17 100644
--- a/lib/efi_loader/efi_hii.c
+++ b/lib/efi_loader/efi_hii.c
@@ -780,7 +780,7 @@ get_package_list_handle(const struct
efi_hii_database_protocol *this,
}
}
- return EFI_EXIT(EFI_NOT_FOUND);
+ return EFI_EXIT(EFI_INVALID_PARAMETER);
}
const struct efi_hii_database_protocol efi_hii_database = {
--
2.35.1
[PATCH 0/2] efi: small hii conformance fix
Hi, The following couple of patches fixes a small UEFI HII conformance issue and adds a selftest demonstrating the issue. This is sent in this order to avoid breaking `bootefi selftest' in the middle but feel free to apply in any order if preferred. Best regards, Vincent. Vincent Stehlé (2): efi_loader: fix get_package_list_handle() status efi_selftest: add hii database protocol test case lib/efi_loader/efi_hii.c| 2 +- lib/efi_selftest/efi_selftest_hii.c | 10 ++ 2 files changed, 11 insertions(+), 1 deletion(-) -- 2.35.1
[PATCH] efi: test/py: repair authenticated capsules tests
The UEFI console initialisation has been modified by commit 68edbed454b8
("efi_loader: initialize console size late"). A corresponding workaround is
now necessary for the automated tests, as added to some of the tests
already by commit e05bd68ed5fc ("test: work around for EFI terminal size
probing").
Add the same workaround to the UEFI authenticated capsules tests to repair
them.
This can be tested with sandbox_defconfig, sandbox64_defconfig or
sandbox_flattree_defconfig, plus CONFIG_EFI_CAPSULE_AUTHENTICATE=y.
Signed-off-by: Vincent Stehlé
Cc: Heinrich Schuchardt
---
.../tests/test_efi_capsule/test_capsule_firmware_signed_fit.py | 3 +++
.../tests/test_efi_capsule/test_capsule_firmware_signed_raw.py | 2 ++
2 files changed, 5 insertions(+)
diff --git a/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_fit.py
b/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_fit.py
index 4400b8f1368..d6ca9b16745 100644
--- a/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_fit.py
+++ b/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_fit.py
@@ -40,6 +40,7 @@ class TestEfiCapsuleFirmwareSignedFit(object):
with u_boot_console.log.section('Test Case 1-a, before reboot'):
output = u_boot_console.run_command_list([
'host bind 0 %s' % disk_img,
+'printenv -e PlatformLangCodes', # workaround for terminal
size determination
'efidebug boot add -b 1 TEST host 0:1 /helloworld.efi',
'efidebug boot order 1',
'env set -e -nv -bs -rt OsIndications =0x0004',
@@ -115,6 +116,7 @@ class TestEfiCapsuleFirmwareSignedFit(object):
with u_boot_console.log.section('Test Case 2-a, before reboot'):
output = u_boot_console.run_command_list([
'host bind 0 %s' % disk_img,
+'printenv -e PlatformLangCodes', # workaround for terminal
size determination
'efidebug boot add -b 1 TEST host 0:1 /helloworld.efi',
'efidebug boot order 1',
'env set -e -nv -bs -rt OsIndications =0x0004',
@@ -192,6 +194,7 @@ class TestEfiCapsuleFirmwareSignedFit(object):
with u_boot_console.log.section('Test Case 3-a, before reboot'):
output = u_boot_console.run_command_list([
'host bind 0 %s' % disk_img,
+'printenv -e PlatformLangCodes', # workaround for terminal
size determination
'efidebug boot add -b 1 TEST host 0:1 /helloworld.efi',
'efidebug boot order 1',
'env set -e -nv -bs -rt OsIndications =0x0004',
diff --git a/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_raw.py
b/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_raw.py
index 1b5a1bb42eb..2bbaa9cc55f 100644
--- a/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_raw.py
+++ b/test/py/tests/test_efi_capsule/test_capsule_firmware_signed_raw.py
@@ -112,6 +112,7 @@ class TestEfiCapsuleFirmwareSignedRaw(object):
with u_boot_console.log.section('Test Case 2-a, before reboot'):
output = u_boot_console.run_command_list([
'host bind 0 %s' % disk_img,
+'printenv -e PlatformLangCodes', # workaround for terminal
size determination
'efidebug boot add -b 1 TEST host 0:1 /helloworld.efi',
'efidebug boot order 1',
'env set -e -nv -bs -rt OsIndications =0x0004',
@@ -189,6 +190,7 @@ class TestEfiCapsuleFirmwareSignedRaw(object):
with u_boot_console.log.section('Test Case 3-a, before reboot'):
output = u_boot_console.run_command_list([
'host bind 0 %s' % disk_img,
+'printenv -e PlatformLangCodes', # workaround for terminal
size determination
'efidebug boot add -b 1 TEST host 0:1 /helloworld.efi',
'efidebug boot order 1',
'env set -e -nv -bs -rt OsIndications =0x0004',
--
2.35.1
[PATCH 2/2] efi: test/py: authenticate fit capsules
Add support for the authentication of UEFI capsules containing FIT images.
The authentication code is moved out of the function handling raw images
into a new function efi_firmware_capsule_authenticate(). The special case
for the FMP header coming from edk2 tools is preserved. There is no
functional change for capsules containing raw images.
The python test for signed capsules with raw images is renamed with no
functional change and a new test is added for signed capsules containing
FIT images.
This can be tested with sandbox64_defconfig or sandbox_flattree_defconfig,
plus CONFIG_EFI_CAPSULE_AUTHENTICATE=y.
Signed-off-by: Vincent Stehlé
Cc: Heinrich Schuchardt
---
lib/efi_loader/efi_firmware.c | 115 +++---
test/py/tests/test_efi_capsule/conftest.py| 21 +++-
...py => test_capsule_firmware_signed_fit.py} | 41 ---
...py => test_capsule_firmware_signed_raw.py} | 6 +-
4 files changed, 117 insertions(+), 66 deletions(-)
copy test/py/tests/test_efi_capsule/{test_capsule_firmware_signed.py =>
test_capsule_firmware_signed_fit.py} (89%)
rename test/py/tests/test_efi_capsule/{test_capsule_firmware_signed.py =>
test_capsule_firmware_signed_raw.py} (98%)
diff --git a/lib/efi_loader/efi_firmware.c b/lib/efi_loader/efi_firmware.c
index fe4e084106d..cbe29e90789 100644
--- a/lib/efi_loader/efi_firmware.c
+++ b/lib/efi_loader/efi_firmware.c
@@ -178,6 +178,70 @@ static efi_status_t efi_fill_image_desc_array(
return EFI_SUCCESS;
}
+/**
+ * efi_firmware_capsule_authenticate - authenticate the capsule if enabled
+ * @p_image: Pointer to new image
+ * @p_image_size: Pointer to size of new image
+ *
+ * Authenticate the capsule if authentication is enabled.
+ * The image pointer and the image size are updated in case of success.
+ *
+ * Return: status code
+ */
+static
+efi_status_t efi_firmware_capsule_authenticate(const void **p_image,
+ efi_uintn_t *p_image_size)
+{
+ const void *image = *p_image;
+ efi_uintn_t image_size = *p_image_size;
+ u32 fmp_hdr_signature;
+ struct fmp_payload_header *header;
+ void *capsule_payload;
+ efi_status_t status;
+ efi_uintn_t capsule_payload_size;
+
+ if (IS_ENABLED(CONFIG_EFI_CAPSULE_AUTHENTICATE)) {
+ capsule_payload = NULL;
+ capsule_payload_size = 0;
+ status = efi_capsule_authenticate(image, image_size,
+ &capsule_payload,
+ &capsule_payload_size);
+
+ if (status == EFI_SECURITY_VIOLATION) {
+ printf("Capsule authentication check failed. Aborting
update\n");
+ return status;
+ } else if (status != EFI_SUCCESS) {
+ return status;
+ }
+
+ debug("Capsule authentication successful\n");
+ image = capsule_payload;
+ image_size = capsule_payload_size;
+ } else {
+ debug("Capsule authentication disabled. ");
+ debug("Updating capsule without authenticating.\n");
+ }
+
+ fmp_hdr_signature = FMP_PAYLOAD_HDR_SIGNATURE;
+ header = (void *)image;
+
+ if (!memcmp(&header->signature, &fmp_hdr_signature,
+ sizeof(fmp_hdr_signature))) {
+ /*
+* When building the capsule with the scripts in
+* edk2, a FMP header is inserted above the capsule
+* payload. Compensate for this header to get the
+* actual payload that is to be updated.
+*/
+ image += header->header_size;
+ image_size -= header->header_size;
+ }
+
+ *p_image = image;
+ *p_image_size = image_size;
+ return EFI_SUCCESS;
+}
+
#ifdef CONFIG_EFI_CAPSULE_FIRMWARE_FIT
/*
* This FIRMWARE_MANAGEMENT_PROTOCOL driver provides a firmware update
@@ -266,12 +330,18 @@ efi_status_t EFIAPI efi_firmware_fit_set_image(
efi_status_t (*progress)(efi_uintn_t completion),
u16 **abort_reason)
{
+ efi_status_t status;
+
EFI_ENTRY("%p %d %p %zu %p %p %p\n", this, image_index, image,
image_size, vendor_code, progress, abort_reason);
if (!image || image_index != 1)
return EFI_EXIT(EFI_INVALID_PARAMETER);
+ status = efi_firmware_capsule_authenticate(&image, &image_size);
+ if (status != EFI_SUCCESS)
+ return EFI_EXIT(status);
+
if (fit_update(image))
return EFI_EXIT(EFI_DEVICE_ERROR);
@@ -372,11 +442,7 @@ efi_status_t EFIAPI efi_firmware_raw_set_image(
efi_status_t (*progress)(efi_uintn_t completion),
u16 **abort_reason)
{
-
[PATCH 1/2] test/py: efi_capsule: repair image authentication test
Repair the python tests for authenticated EFI capsules, which can be run
with sandbox_defconfig plus CONFIG_EFI_CAPSULE_AUTHENTICATE=y.
- Account for the reset changes done by commit 3e6f81000672 ("efi_loader:
test/py: Reset system after capsule update on disk").
- Fix the capsule GUID typo introduced by commit 2e9c3c6965ba ("test:
capsule: Modify the capsule tests to use GUID values for sandbox").
Signed-off-by: Vincent Stehlé
Cc: Heinrich Schuchardt
---
test/py/tests/test_efi_capsule/conftest.py | 4 ++--
.../tests/test_efi_capsule/test_capsule_firmware_signed.py | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/test/py/tests/test_efi_capsule/conftest.py
b/test/py/tests/test_efi_capsule/conftest.py
index d757415c881..5a8826a5a6b 100644
--- a/test/py/tests/test_efi_capsule/conftest.py
+++ b/test/py/tests/test_efi_capsule/conftest.py
@@ -101,7 +101,7 @@ def efi_capsule_data(request, u_boot_config):
check_call('cd %s; '
'%s/tools/mkeficapsule --index 1 --monotonic-count 1 '
'--private-key SIGNER.key --certificate SIGNER.crt
'
-'--guid 09D7DF52-0720-4710-91D1-08469B7FE9C8 '
+'--guid 09D7CF52-0720-4710-91D1-08469B7FE9C8 '
'u-boot.bin.new Test11'
% (data_dir, u_boot_config.build_dir),
shell=True)
@@ -110,7 +110,7 @@ def efi_capsule_data(request, u_boot_config):
'%s/tools/mkeficapsule --index 1 --monotonic-count 1 '
'--private-key SIGNER2.key '
'--certificate SIGNER2.crt '
-'--guid 09D7DF52-0720-4710-91D1-08469B7FE9C8 '
+'--guid 09D7CF52-0720-4710-91D1-08469B7FE9C8 '
'u-boot.bin.new Test12'
% (data_dir, u_boot_config.build_dir),
shell=True)
diff --git a/test/py/tests/test_efi_capsule/test_capsule_firmware_signed.py
b/test/py/tests/test_efi_capsule/test_capsule_firmware_signed.py
index 593b032e901..a0b6a1ac86f 100644
--- a/test/py/tests/test_efi_capsule/test_capsule_firmware_signed.py
+++ b/test/py/tests/test_efi_capsule/test_capsule_firmware_signed.py
@@ -85,7 +85,7 @@ class TestEfiCapsuleFirmwareSigned(object):
# need to run uefi command to initiate capsule handling
output = u_boot_console.run_command(
-'env print -e Capsule')
+'env print -e Capsule', wait_for_reboot = True)
output = u_boot_console.run_command_list([
'host bind 0 %s' % disk_img,
@@ -160,7 +160,7 @@ class TestEfiCapsuleFirmwareSigned(object):
# need to run uefi command to initiate capsule handling
output = u_boot_console.run_command(
-'env print -e Capsule')
+'env print -e Capsule', wait_for_reboot = True)
# deleted any way
output = u_boot_console.run_command_list([
@@ -237,7 +237,7 @@ class TestEfiCapsuleFirmwareSigned(object):
# need to run uefi command to initiate capsule handling
output = u_boot_console.run_command(
-'env print -e Capsule')
+'env print -e Capsule', wait_for_reboot = True)
# deleted any way
output = u_boot_console.run_command_list([
--
2.35.1
[PATCH 2/2] efi: fix documentation warnings
This fixes the following warnings:
./lib/efi_loader/efi_firmware.c:283: warning: Function parameter or member
'package_version' not described in 'efi_firmware_fit_get_image_info'
./lib/efi_loader/efi_firmware.c:283: warning: Function parameter or member
'package_version_name' not described in 'efi_firmware_fit_get_image_info'
./lib/efi_loader/efi_firmware.c:369: warning: bad line: firmware image
./lib/efi_loader/efi_firmware.c:395: warning: Function parameter or member
'package_version' not described in 'efi_firmware_raw_get_image_info'
./lib/efi_loader/efi_firmware.c:395: warning: Function parameter or member
'package_version_name' not described in 'efi_firmware_raw_get_image_info'
Signed-off-by: Vincent Stehlé
Cc: Heinrich Schuchardt
---
lib/efi_loader/efi_firmware.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/efi_loader/efi_firmware.c b/lib/efi_loader/efi_firmware.c
index 27953fe7699..fe4e084106d 100644
--- a/lib/efi_loader/efi_firmware.c
+++ b/lib/efi_loader/efi_firmware.c
@@ -197,8 +197,8 @@ static efi_status_t efi_fill_image_desc_array(
* @descriptor_version:Pointer to version number
* @descriptor_count: Pointer to number of descriptors
* @descriptor_size: Pointer to descriptor size
- * package_version:Package version
- * package_version_name: Package version's name
+ * @package_version: Package version
+ * @package_version_name: Package version's name
*
* Return information bout the current firmware image in @image_info.
* @image_info will consist of a number of descriptors.
@@ -296,15 +296,15 @@ const struct efi_firmware_management_protocol efi_fmp_fit
= {
/**
* efi_firmware_raw_get_image_info - return information about the current
-firmware image
+ * firmware image
* @this: Protocol instance
* @image_info_size: Size of @image_info
* @image_info:Image information
* @descriptor_version:Pointer to version number
* @descriptor_count: Pointer to number of descriptors
* @descriptor_size: Pointer to descriptor size
- * package_version:Package version
- * package_version_name: Package version's name
+ * @package_version: Package version
+ * @package_version_name: Package version's name
*
* Return information bout the current firmware image in @image_info.
* @image_info will consist of a number of descriptors.
--
2.35.1
[PATCH 1/2] doc/efi: add firmware management protocol to the documentation
The firmware management protocol can be used to manage device firmware. U-Boot can be configured to provide an implementation. Document the related functions in the API section. Signed-off-by: Vincent Stehlé Cc: Heinrich Schuchardt --- doc/api/efi.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/doc/api/efi.rst b/doc/api/efi.rst index cb2a1c897e6..2b96783828b 100644 --- a/doc/api/efi.rst +++ b/doc/api/efi.rst @@ -166,6 +166,12 @@ Unicode Collation protocol .. kernel-doc:: lib/efi_loader/efi_unicode_collation.c :internal: +Firmware management protocol + + +.. kernel-doc:: lib/efi_loader/efi_firmware.c + :internal: + Unit testing -- 2.35.1
RE: [External] - Raspberry Pi Boot 1b / Uboot boot failure with large initramfs
Frederick
> -Original Message-
> From: U-Boot On Behalf Of Frederik Lotter
> Sent: Monday, December 6, 2021 12:55 AM
> To: u-boot@lists.denx.de
> Subject: [External] - Raspberry Pi Boot 1b / Uboot boot failure with large
> initramfs
>
> Hi,
>
> I am facing intermittend boot failures resulting in a data abort. Boot log and
> environment attached below. The uboot is built with rpi_defconfig with
> OF_BOARD to get uboot to pass through the FDT.
>
> Note:
>
> (1) If I boot this image directly using the RPI bootloader, the kernel (with
> initramfs embedded) boots fine consistently.
>
> (2) However, I get inconsistent failures with uboot. My gut tells me memory
> is getting corrupted.
>
> (3) Sometimes just adding one option to the bootargs breaks the next boot.
>
> (4) It seems the FDT address changes slightly (see failed vs OK). Not sure if
> this is expected from start.elf (I assume the FDT address is supplied to u-
> boot).
>
> (5) Is the size of the image overwriting anything in u-boot? I am not that
> familiar with the u-boot memory map.
>
> I boot using the following environment changes:
> bootargs=bootslot=a console=ttyAMA0,115200 root=/dev/null
> bootcmd=fatload mmc 0:1 ${kernel_addr_r} kernel.a.img ; bootz
> ${kernel_addr_r} - ${fdtcontroladdr}
Do you have the same problems when using ${fdt_addr}?
>
> Any ideas?
>
> Regards,
> Fred
>
> BOOT:
>
> DRAM: 448 MiB
> RPI Model B rev2 (0xe)
> MMC: mmc@7e202000: 0
> Loading Environment from FAT... OK
> In:serial
> Out: vidconsole
> Err: vidconsole
> Net: No ethernet found.
> starting USB...
> Bus usb@7e98: usb dr_mode not found
> USB DWC2
> scanning bus usb@7e98 for devices... 3 USB Device(s) found
>scanning usb for storage devices... 0 Storage Device(s) found Hit any
> key
> to stop autoboot: 0
> 70746744 bytes read in 2940 ms (22.9 MiB/s) Kernel image @ 0x08 [
> 0x00 - 0x4378278 ] ## Flattened Device Tree blob at 1bb500e0
>Booting using the fdt blob at 0x1bb500e0
>Using Device Tree in place at 1bb500e0, end 1bb59ebe data abort
> pc : [<1bf5c4ec>] lr : [<1bf5c7c4>]
> reloc pc : [<94ec>]lr : [<97c4>]
> sp : 1bb4fdb8 ip : 000c fp : 0003
> r10: r9 : 1bb56ec0 r8 : 1bb6bad4
> r7 : r6 : 0008 r5 : 1bfc5874 r4 : 0400
> r3 : 0074616d r2 : 1bb6bad4 r1 : 0400 r0 : 1bfc5874
> Flags: nzcv IRQs off FIQs off Mode SVC_32
> Code: e12fff1e e92d4073 e5993000 e5906060 (e5933038) Resetting CPU ...
>
> resetting ...
>
> ENV:
>
> arch=arm
> baudrate=115200
> board=rpi
> board_name=Model B rev2
> board_rev=0xE
> board_rev_scheme=0
> board_revision=0xE
> boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr}
> ${prefix}${script}; source ${scriptaddr} boot_efi_binary=load ${devtype}
> ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootarm.efi; if fdt
> addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else
> bootefi ${kernel_addr_r} ${fdtcontroladdr};fi boot_efi_bootmgr=if fdt addr
> ${fdt_addr_r}; then bootefi bootmgr ${fdt_addr_r};else bootefi bootmgr;fi
> boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any
> ${scriptaddr} ${prefix}${boot_syslinux_conf} boot_net_usb_start=usb start
> boot_prefixes=/ /boot/ boot_script_dhcp=boot.scr.uimg
> boot_scripts=boot.scr.uimg boot.scr
> boot_syslinux_conf=extlinux/extlinux.conf
> boot_targets=mmc0 mmc1 usb0 pxe dhcp
> bootargs=bootslot=a console=ttyAMA0,115200 root=/dev/null
> bootcmd=fatload mmc 0:1 ${kernel_addr_r} kernel.a.img ; bootz
> ${kernel_addr_r} - ${fdtcontroladdr} bootcmd_dhcp=devtype=dhcp; run
> boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source
> ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; if test -z "${fdtfile}" -a -n
> "${soc}"; then setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; fi; setenv
> efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv
> bootp_vci PXEClient:Arch:00010:UNDI:003000;setenv bootp_arch 0xa;if dhcp
> ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr
> ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi
> ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci
> ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv
> efi_old_arch;setenv efi_old_vci; bootcmd_mmc0=devnum=0; run
> mmc_boot bootcmd_mmc1=devnum=1; run mmc_boot bootcmd_pxe=run
> boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi
> bootcmd_usb0=devnum=0; run usb_boot
> bootdelay=2
> cpu=arm1176
> dhcpuboot=usb start; dhcp u-boot.uimg; bootm distro_bootcmd=for target
> in ${boot_targets}; do run bootcmd_${target}; done efi_dtb_prefixes=/
> /dtb/ /dtb/current/
> ethaddr=b8:27:eb:46:ba:40
> fdt_addr=1bfe9200
> fdt_addr_r=0x0260
> fdt_high=
> fdtcontroladdr=1bb500e0
> fdtfile=bcm2835-rpi-b-rev2.dtb
> initrd_high=
> kernel_addr_r=0x0008
> load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} $
[PATCH] qemu: common: Fix build with update capsule
The common emulation Makefile has a dependency on a non-existent
qemu_capsule.o when building with support for capsule update enabled
(CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y).
The code which was in qemu_capsule.c has been completely moved to
lib/efi_loader/efi_capsule.c by commit 7a6fb28c8e4b ("efi_loader: capsule:
add back efi_get_public_key_data()").
Remove the false dependency.
This fixes the following build error:
make[1]: *** No rule to make target 'board/emulation/common/qemu_capsule.o',
needed by 'board/emulation/common/built-in.o'. Stop.
Fixes: commit 47a25e81d35c ("Revert "efi_capsule: Move signature from DTB to
.rodata"")
Signed-off-by: Vincent Stehlé
Cc: Simon Glass
---
board/emulation/common/Makefile | 1 -
1 file changed, 1 deletion(-)
diff --git a/board/emulation/common/Makefile b/board/emulation/common/Makefile
index 7ed447a69dc..c5b452e7e34 100644
--- a/board/emulation/common/Makefile
+++ b/board/emulation/common/Makefile
@@ -2,4 +2,3 @@
obj-$(CONFIG_SYS_MTDPARTS_RUNTIME) += qemu_mtdparts.o
obj-$(CONFIG_SET_DFU_ALT_INFO) += qemu_dfu.o
-obj-$(CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT) += qemu_capsule.o
--
2.33.0
RE: [External] - Slow MMC IO with Raspberry CM3+ Module
Ivan, > -Original Message- > From: Ivan T. Ivanov > Sent: Wednesday, November 10, 2021 4:01 AM > To: Vincent Fazio > Cc: Mario Lombardo ; u-boot@lists.denx.de > Subject: Re: [External] - Slow MMC IO with Raspberry CM3+ Module > > On 11-03 20:57, Vincent Fazio wrote: > > Date: Wed, 3 Nov 2021 20:57:13 + > > From: Vincent Fazio > > To: Mario Lombardo , "u-boot@lists.denx.de" > > > > Subject: RE: [External] - Slow MMC IO with Raspberry CM3+ Module > > Message-ID: > > > 0.PROD.OUT > > LOOK.COM> > Tags: all uboot > > Hi Vincent, > > > > > Mario, > > > > > -Original Message- > > > From: U-Boot On Behalf Of Mario > > > Lombardo > > > Sent: Wednesday, November 3, 2021 5:40 AM > > > To: u-boot@lists.denx.de > > > Subject: [External] - Slow MMC IO with Raspberry CM3+ Module > > > > > > Dear u-boot list, > > > > > > I recently compiled (latest: 2021.10) code of uboot as a boot loader > > > for the Compute Module 3+ (Raspberry). Everything works fine except > one issue: > > > the IO from the storage is extreme slow. I read about issues in the > > > past related to ext file systems. However the present issue relates > > > to both ext and fat file systems so I assume its cause is different. > > > > Please see this series: > > https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Fpat > > > chwork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D262375&am > p;da > > > ta=04%7C01%7C%7Ca736ee7a8d7446c34adb08d9a430fdf3%7C2925f1cdbdc34 > a76bb3 > > > 86159e20a17f1%7C0%7C0%7C637721352603649117%7CUnknown%7CTWFpb > GZsb3d8eyJ > > > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D% > 7C1000 > > > &sdata=4snQV571x4aGlf7NwXnR%2B%2F5RgkyZ2MOMax%2FudbP6xu > w%3D&re > > served=0 And this RPi issue: > > https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Fgit > > > hub.com%2Fraspberrypi%2Ffirmware%2Fissues%2F1619&data=04%7C0 > 1%7C%7 > > > Ca736ee7a8d7446c34adb08d9a430fdf3%7C2925f1cdbdc34a76bb386159e20a1 > 7f1%7 > > > C0%7C0%7C637721352603659112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > MC4wLjAwMD > > > AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata= > das1 > > lOBGq%2BMDOz7OlqbEbyBS9eXtrp7W5SQ25VteYLk%3D&reserved=0 > > Are your patches still needed? If I read the comments on the issue it was > fixed in RPi firmware and your workaround is not needed, correct? I think this is a fair question. The patches are still needed for certain tagged versions of the RPi firmware. Later tags may resolve this problem but may also introduce their own regressions which force users back to a previous tag where this is a problem. I think I would recommend including the patches so U-Boot works across all revisions of firmware and to future proof against subsequent changes in the clock API. Ultimately, I defer to the maintainers' choice. > > Regards, > Ivan > > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. Vincent Fazio Embedded Software Engineer - ATS Extreme Engineering Solutions, Inc http://www.xes-inc.com
RE: [External] - Slow MMC IO with Raspberry CM3+ Module
Mario,
> -Original Message-
> From: U-Boot On Behalf Of Mario
> Lombardo
> Sent: Wednesday, November 3, 2021 5:40 AM
> To: u-boot@lists.denx.de
> Subject: [External] - Slow MMC IO with Raspberry CM3+ Module
>
> Dear u-boot list,
>
> I recently compiled (latest: 2021.10) code of uboot as a boot loader
> for the Compute Module 3+ (Raspberry). Everything works fine except one issue:
> the IO from the storage is extreme slow. I read about issues in the
> past related to ext file systems. However the present issue relates to
> both ext and fat file systems so I assume its cause is different.
Please see this series:
https://patchwork.ozlabs.org/project/uboot/list/?series=262375
And this RPi issue: https://github.com/raspberrypi/firmware/issues/1619
>
> This is what I did:
>
> U-Boot> setenv pio_kernel "recovery/kernel.img"
> U-Boot> setenv pio_initrd "recovery/initrd.img"
> U-Boot> fatload mmc 0:1 ${kernel_addr_r} ${pio_kernel}
> 5299624 bytes read in 45262 ms (114.3 KiB/s)
> U-Boot> fatload mmc 0:1 ${ramdisk_addr_r} ${pio_initrd}
> 24239932 bytes read in 206978 ms (114.3 KiB/s)
>
> The configuration of by build is attached.
>
> Is there anyone else experiencing this kind of issues?
>
> Thank you very much.
>
> Mario
>
>
> CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you recognize the sender
> and know the content is safe.
-Vincent
Re: [PATCH] efi_loader: Fix loaded image alignment
On Mon, Oct 11, 2021 at 03:10:23PM +0300, Ilias Apalodimas wrote: > We are ignoring the alignment communicated via the PE/COFF header. > Starting 5.10 the Linux kernel will loudly complain about it. For more > details look at [1] (in linux kernel). > > So add a function that can allocate aligned EFI memory and use it for our > relocated loaded image. Hi Ilias, Thank you for this fix. I verified that Linux v5.14.3 EFI stub complains about not being aligned to 64k without this fix and is happy with it, on the following systems: - qemu with U-Boot latest (after v2021.10) - Pine64 ROCKPro64 with U-Boot "near" v2021.07[1] - Lenovo Leez P710 with U-Boot v2021.07[2] - Compulab IOT-GATE-iMX8 with U-Boot "near" v2021.10-rc3[3] Feel free to add (or not): Tested-by: Vincent Stehlé Best regards, Vincent Stehlé System Architect - Arm [1]: https://gitlab.arm.com/systemready/firmware-build/rk3399-manifest/-/blob/rockpro64-21.09/README.md [2]: https://gitlab.arm.com/systemready/firmware-build/rk3399-manifest/-/blob/leez-21.08/README.md [3]: https://git.linaro.org/people/paul.liu/systemready/build-scripts.git/tree/docs/iotgateimx8_building_running.md
Re: MMC speed issue with RaspberryPi 3b, 3a+
All, On 10/1/21 8:22 AM, Mark Kettenis wrote: From: Sergey Suloev Date: Fri, 1 Oct 2021 11:01:18 +0300 Hello, I have a problem with MMC speed while using U-boot 2021.07 with raspberryPi - it takes about 2 min to fatload 15MB kernel file. Please also see this rpi-firmware issue [1] and patchwork series [2]. The series may not be necessary with newer firmware. Any suggestions ? Do you have a USB keyboard plugged in? [1] https://github.com/raspberrypi/firmware/issues/1619 [2] https://patchwork.ozlabs.org/project/uboot/list/?series=262375 -- Vincent Fazio Embedded Software Engineer - ATS Extreme Engineering Solutions, Inc http://www.xes-inc.com
Re: [GIT PULL] rpi: updates for v2021.10
Peter,
On 9/15/21 11:32 AM, Peter Robinson wrote:
On Wed, Sep 15, 2021 at 4:40 PM Matthias Brugger wrote:
Hi Tom,
I know, quite a bit late but here come the updates for RPi for v2021.10.
Actually most of the patches are fixes.
Ivan's patch fixes a kernel warning when booting RPi2, as the firmware already
provides a frambebuffer node.
Marek's patch fixes random crashes on 32 bit RPi4 with newer firmware.
My SMBIOS patchesfixes an issue that show up with
e4f8e543f1 ("smbios: Drop the unused Kconfig options").
Basically the SMBIOS table broke and wasn't readable anymore.
I think we can argue if the last one is a real fix. In case you just want to
take the first two so late in the cycle, let me know and I can provide you with
a separate pull request.
It would also be good to get these[1] , although it doesn't seem like
they were also posted to the list. It fixes a regression with U-Boot
and recent RPi firmwares [2] so will likely come up sooner rather than
later post release.
Peter
I did send these to the u-boot list but received an "awaiting moderator
approval" response.
Is there a different list i should have submitted this to, just for
future reference?
[1] https://patchwork.ozlabs.org/project/uboot/list/?series=262375
[2] https://github.com/raspberrypi/firmware/issues/1619
Regards,
Matthias
---
The following changes since commit bb92678ced0b1594b93ab2f10b2c17750c789c96:
Prepare v2021.10-rc4 (2021-09-14 18:58:10 -0400)
are available in the Git repository at:
https://source.denx.de/u-boot/custodians/u-boot-raspberrypi.git/ rpi-next
for you to fetch changes up to acc6987e59137485dbac0ee4a07cc349210954f3:
rpi: Conditionally add simple-framebuffer node (2021-09-15 13:34:06 +0200)
Ivan T. Ivanov (1):
rpi: Conditionally add simple-framebuffer node
Marek Szyprowski (1):
ARM: bcm283x: change the virtual address of the XHCI PCI device base
Matthias Brugger (2):
arm: dts: bcm283x: Add minimal smbios information
configs: rpi: Enable SMBIOS sysinfo driver
arch/arm/dts/bcm283x-u-boot.dtsi | 19 +++
arch/arm/mach-bcm283x/init.c | 4 ++--
board/raspberrypi/rpi/rpi.c | 11 +--
configs/rpi_0_w_defconfig| 2 ++
configs/rpi_2_defconfig | 2 ++
configs/rpi_3_32b_defconfig | 2 ++
configs/rpi_3_b_plus_defconfig | 2 ++
configs/rpi_3_defconfig | 2 ++
configs/rpi_4_32b_defconfig | 2 ++
configs/rpi_4_defconfig | 2 ++
configs/rpi_arm64_defconfig | 2 ++
configs/rpi_defconfig| 2 ++
12 files changed, 44 insertions(+), 8 deletions(-)
--
Vincent Fazio
Embedded Software Engineer - ATS
Extreme Engineering Solutions, Inc
http://www.xes-inc.com
[PATCH 2/2] mmc: bcm2835-host: let firmware manage the clock divisor
Newer firmware can manage the SDCDIV clock divisor register, allowing
the divisor to scale with the core as necessary.
Leverage this ability if the firmware supports it.
Adapted from the following raspberrypi Linux kernel commit:
bcm2835-sdhost: Firmware manages the clock divisor
https://github.com/raspberrypi/linux/commit/08532d242d7702ae0add95096aa49c5e96e066e2
Signed-off-by: Vincent Fazio
---
arch/arm/mach-bcm283x/include/mach/mbox.h | 16 +++
arch/arm/mach-bcm283x/include/mach/msg.h | 10 +
arch/arm/mach-bcm283x/msg.c | 28
drivers/mmc/bcm2835_sdhost.c | 53 ++-
4 files changed, 86 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-bcm283x/include/mach/mbox.h
b/arch/arm/mach-bcm283x/include/mach/mbox.h
index 7dcac583cc..490664f878 100644
--- a/arch/arm/mach-bcm283x/include/mach/mbox.h
+++ b/arch/arm/mach-bcm283x/include/mach/mbox.h
@@ -252,6 +252,22 @@ struct bcm2835_mbox_tag_get_clock_rate {
} body;
};
+#define BCM2835_MBOX_TAG_SET_SDHOST_CLOCK 0x00038042
+
+struct bcm2835_mbox_tag_set_sdhost_clock {
+ struct bcm2835_mbox_tag_hdr tag_hdr;
+ union {
+ struct {
+ u32 rate_hz;
+ } req;
+ struct {
+ u32 rate_hz;
+ u32 rate_1;
+ u32 rate_2;
+ } resp;
+ } body;
+};
+
#define BCM2835_MBOX_TAG_ALLOCATE_BUFFER 0x00040001
struct bcm2835_mbox_tag_allocate_buffer {
diff --git a/arch/arm/mach-bcm283x/include/mach/msg.h
b/arch/arm/mach-bcm283x/include/mach/msg.h
index e45c1bf010..ab37abdb6c 100644
--- a/arch/arm/mach-bcm283x/include/mach/msg.h
+++ b/arch/arm/mach-bcm283x/include/mach/msg.h
@@ -22,6 +22,16 @@ int bcm2835_power_on_module(u32 module);
*/
int bcm2835_get_mmc_clock(u32 clock_id);
+/**
+ * bcm2835_set_sdhost_clock() - determine if firmware controls sdhost cdiv
+ *
+ * @rate_hz: Input clock frequency
+ * @rate_1: Returns a clock frequency
+ * @rate_2: Returns a clock frequency
+ * @return 0 of OK, -EIO on error
+ */
+int bcm2835_set_sdhost_clock(u32 rate_hz, u32 *rate_1, u32 *rate_2);
+
/**
* bcm2835_get_video_size() - get the current display size
*
diff --git a/arch/arm/mach-bcm283x/msg.c b/arch/arm/mach-bcm283x/msg.c
index ae85e9159e..adab15da4e 100644
--- a/arch/arm/mach-bcm283x/msg.c
+++ b/arch/arm/mach-bcm283x/msg.c
@@ -21,6 +21,12 @@ struct msg_get_clock_rate {
u32 end_tag;
};
+struct msg_set_sdhost_clock {
+ struct bcm2835_mbox_hdr hdr;
+ struct bcm2835_mbox_tag_set_sdhost_clock set_sdhost_clock;
+ u32 end_tag;
+};
+
struct msg_query {
struct bcm2835_mbox_hdr hdr;
struct bcm2835_mbox_tag_physical_w_h physical_w_h;
@@ -110,6 +116,28 @@ int bcm2835_get_mmc_clock(u32 clock_id)
return clock_rate;
}
+int bcm2835_set_sdhost_clock(u32 rate_hz, u32 *rate_1, u32 *rate_2)
+{
+ ALLOC_CACHE_ALIGN_BUFFER(struct msg_set_sdhost_clock, msg_sdhost_clk,
1);
+ int ret;
+
+ BCM2835_MBOX_INIT_HDR(msg_sdhost_clk);
+ BCM2835_MBOX_INIT_TAG(&msg_sdhost_clk->set_sdhost_clock,
SET_SDHOST_CLOCK);
+
+ msg_sdhost_clk->set_sdhost_clock.body.req.rate_hz = rate_hz;
+
+ ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN,
&msg_sdhost_clk->hdr);
+ if (ret) {
+ printf("bcm2835: Could not query sdhost clock rate\n");
+ return -EIO;
+ }
+
+ *rate_1 = msg_sdhost_clk->set_sdhost_clock.body.resp.rate_1;
+ *rate_2 = msg_sdhost_clk->set_sdhost_clock.body.resp.rate_2;
+
+ return 0;
+}
+
int bcm2835_get_video_size(int *widthp, int *heightp)
{
ALLOC_CACHE_ALIGN_BUFFER(struct msg_query, msg_query, 1);
diff --git a/drivers/mmc/bcm2835_sdhost.c b/drivers/mmc/bcm2835_sdhost.c
index 894dbdd686..5c23c03d10 100644
--- a/drivers/mmc/bcm2835_sdhost.c
+++ b/drivers/mmc/bcm2835_sdhost.c
@@ -181,6 +181,7 @@ struct bcm2835_host {
struct udevice *dev;
struct mmc *mmc;
struct bcm2835_plat *plat;
+ unsigned intfirmware_sets_cdiv:1;
};
static void bcm2835_dumpregs(struct bcm2835_host *host)
@@ -233,7 +234,7 @@ static void bcm2835_reset_internal(struct bcm2835_host
*host)
msleep(20);
host->clock = 0;
writel(host->hcfg, host->ioaddr + SDHCFG);
- writel(host->cdiv, host->ioaddr + SDCDIV);
+ writel(SDCDIV_MAX_CDIV, host->ioaddr + SDCDIV);
}
static int bcm2835_wait_transfer_complete(struct bcm2835_host *host)
@@ -598,6 +599,7 @@ static int bcm2835_transmit(struct bcm2835_host *host)
static void bcm2835_set_clock(struct bcm2835_host *host, unsigned int clock)
{
int div;
+ u32 clock_rate[2] = { 0 };
/* The SDCDIV register has 11 bits, and holds (div - 2). But
* in data mode the max is 50MHz wihout a minimum, and only
@@ -620
[PATCH 1/2] arm: rpi: fallback to max clock rate for MMC clock
In rpi-firmware 25e2b597ebfb2495eab4816a276758dcc6ea21f1,
the GET_CLOCK_RATE mailbox property was changed to return the last
value set by SET_CLOCK_RATE.
https://github.com/raspberrypi/firmware/issues/1619#issuecomment-917025502
Due to this change in firmware behavior, bcm2835_get_mmc_clock now
returns a clock rate of zero since we do not issue SET_CLOCK_RATE.
This results in degraded MMC performance.
SET_CLOCK_RATE fixes the clock to a specific value and disables scaling
so is not an ideal solution.
Instead, fallback to GET_MAX_CLOCK_RATE in bcm2835_get_mmc_clock if
GET_CLOCK_RATE returns zero.
Signed-off-by: Vincent Fazio
---
arch/arm/mach-bcm283x/include/mach/mbox.h | 2 ++
arch/arm/mach-bcm283x/msg.c | 19 ++-
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-bcm283x/include/mach/mbox.h
b/arch/arm/mach-bcm283x/include/mach/mbox.h
index 2ae2d3d97c..7dcac583cc 100644
--- a/arch/arm/mach-bcm283x/include/mach/mbox.h
+++ b/arch/arm/mach-bcm283x/include/mach/mbox.h
@@ -224,6 +224,8 @@ struct bcm2835_mbox_tag_set_power_state {
};
#define BCM2835_MBOX_TAG_GET_CLOCK_RATE0x00030002
+#define BCM2835_MBOX_TAG_GET_MAX_CLOCK_RATE0x00030004
+#define BCM2835_MBOX_TAG_GET_MIN_CLOCK_RATE0x00030007
#define BCM2835_MBOX_CLOCK_ID_EMMC 1
#define BCM2835_MBOX_CLOCK_ID_UART 2
diff --git a/arch/arm/mach-bcm283x/msg.c b/arch/arm/mach-bcm283x/msg.c
index 347aece3cd..ae85e9159e 100644
--- a/arch/arm/mach-bcm283x/msg.c
+++ b/arch/arm/mach-bcm283x/msg.c
@@ -75,6 +75,7 @@ int bcm2835_get_mmc_clock(u32 clock_id)
{
ALLOC_CACHE_ALIGN_BUFFER(struct msg_get_clock_rate, msg_clk, 1);
int ret;
+ u32 clock_rate = 0;
ret = bcm2835_power_on_module(BCM2835_MBOX_POWER_DEVID_SDHCI);
if (ret)
@@ -90,7 +91,23 @@ int bcm2835_get_mmc_clock(u32 clock_id)
return -EIO;
}
- return msg_clk->get_clock_rate.body.resp.rate_hz;
+ clock_rate = msg_clk->get_clock_rate.body.resp.rate_hz;
+
+ if (clock_rate == 0) {
+ BCM2835_MBOX_INIT_HDR(msg_clk);
+ BCM2835_MBOX_INIT_TAG(&msg_clk->get_clock_rate,
GET_MAX_CLOCK_RATE);
+ msg_clk->get_clock_rate.body.req.clock_id = clock_id;
+
+ ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN,
&msg_clk->hdr);
+ if (ret) {
+ printf("bcm2835: Could not query max eMMC clock
rate\n");
+ return -EIO;
+ }
+
+ clock_rate = msg_clk->get_clock_rate.body.resp.rate_hz;
+ }
+
+ return clock_rate;
}
int bcm2835_get_video_size(int *widthp, int *heightp)
--
2.25.1
[PATCH 0/2] mmc: bcm2835_sdhost: use fallback clock rate
Recent raspberry pi firmware has modified the behavior of GET_CLOCK_RATE to return zero (0) when there is no previous call to SET_CLOCK_RATE. This affects callers of bcm2835_get_mmc_clock and can lead to degraded MMC performance. Now, return the result of GET_MAX_CLOCK_RATE if GET_CLOCK_RATE is zero. Additionally, let the firmware manage SDCDIV when possible. Vincent Fazio (2): arm: rpi: fallback to max clock rate for MMC clock mmc: bcm2835-host: let firmware manage the clock divisor arch/arm/mach-bcm283x/include/mach/mbox.h | 18 arch/arm/mach-bcm283x/include/mach/msg.h | 10 + arch/arm/mach-bcm283x/msg.c | 47 +++- drivers/mmc/bcm2835_sdhost.c | 53 ++- 4 files changed, 106 insertions(+), 22 deletions(-) -- 2.25.1
Re: [BUG] USB boot issue on ROCKPro64 with UEFI
On Fri, Sep 03, 2021 at 07:02:13PM +0200, Arnaud Patard wrote: .. > I may be wrong but seems like the issue solved by > https://patchwork.ozlabs.org/project/uboot/patch/20210406151059.1187379-1-icen...@aosc.io/ > Unfortunately, I think that there has been no progress since the > submission of this patch. Hi Arnaud, You are right, this patch solves the issue I am seeing on the ROCKPro64. Thanks for the pointer. Best regards, Vincent Stehlé System Architect - Arm
[PATCH WORKAROUND] clk: rk3399: do not disable the USB2PHY clk
When booting from USB with UEFI on the ROCKPro64, the Linux kernel EFI stub will hang in efi_exit_boot_services due to OHCI hc_reset accessing the hardware registers after the USB2PHY clocks have been disabled. As a workaround, prevent the USB2PHY clocks from being disabled to repair the boot. Signed-off-by: Vincent Stehlé --- THIS IS A WORKAROUND PLEASE DO NOT APPLY! drivers/clk/rockchip/clk_rk3399.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/clk/rockchip/clk_rk3399.c b/drivers/clk/rockchip/clk_rk3399.c index f8cbda44551..9cf7d26a026 100644 --- a/drivers/clk/rockchip/clk_rk3399.c +++ b/drivers/clk/rockchip/clk_rk3399.c @@ -1213,10 +1213,10 @@ static int rk3399_clk_disable(struct clk *clk) rk_setreg(&priv->cru->clkgate_con[5], BIT(6)); break; case SCLK_USB2PHY0_REF: - rk_setreg(&priv->cru->clkgate_con[6], BIT(5)); + /* WORKAROUND: leave enabled */ break; case SCLK_USB2PHY1_REF: - rk_setreg(&priv->cru->clkgate_con[6], BIT(6)); + /* WORKAROUND: leave enabled */ break; case ACLK_GMAC: rk_setreg(&priv->cru->clkgate_con[32], BIT(0)); -- 2.30.2
[BUG] USB boot issue on ROCKPro64 with UEFI
Hi U-Boot folks,
Hopefully this is the right way to report bugs. If not, please do not hesitate
to let me know.
I am hitting an issue with U-Boot v2021.07 on the ROCKPro64, when booting Linux
with UEFI from USB. The kernel EFI stub will hang:
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
After tracking it down, it appears efi_exit_boot_services() is ultimately
calling OHCI hc_reset(), which hangs at this line:
1804 if (ohci_readl(&ohci->regs->control) & OHCI_CTRL_IR) {
This seems to indicate reading the OHCI hardware control register cannot
complete, which hints at a clocking issue.
Looking in more details at the clocks changes performed on the
efi_exit_boot_services() path, a workaround is indeed to prevent the USB2PHY
clocks from being disabled (see the patch following this e-mail).
I don't know enough about the RK3399 clock tree to fully understand what is
going on here, and what would be a proper fix. Hopefully others will be able to
continue from there.
Best regards,
Vincent Stehlé
System Architect - Arm
Vincent Stehlé (1):
clk: rk3399: do not disable the USB2PHY clk
drivers/clk/rockchip/clk_rk3399.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
2.30.2
Re: [PATCH 0/2] board: sifive: unmatched: reset multiple devices in SPL
Just a gentle ping. If this patchset has any problems, please let me know. I am willing to modify it. Thank you. On Thu, Jul 8, 2021 at 9:08 AM Vincent Chen wrote: > > In SiFive unmatched board, the reset of the USB hub, PCIe-USB bridge, and > ULPI rely on the power-cycling. However, sometimes the rebooting is without > power-cycling. To ensure these devices will be reset in each rebooting, > here always reset these devices in the spl_board_init_f(). > > In addition, because the reset pint of these four devices incluing GEMGXL > connects to the GPIO, the 1st patch creates a new wrapper, > spl_reset_device_by_gpio(), to address the GPIO operation during the reset. > > Vincent Chen (2): > board: sifive: unmatched: refine GEMGXL initialized function in SPL > board: sifive: unmatched: reset USB hub, PCIe-USB bridge, and ULPI > device in SPL > > board/sifive/unmatched/spl.c | 90 > +++- > 1 file changed, 73 insertions(+), 17 deletions(-) > > -- > 2.7.4 >
[PATCH 2/2] board: sifive: unmatched: reset USB hub, PCIe-USB bridge, and ULPI device in SPL
Ensure USB hub, PCIe-USB bridge, and ULPI device to be reset
even if the rebooting is without power-cycling.
Signed-off-by: Vincent Chen
---
board/sifive/unmatched/spl.c | 36
1 file changed, 36 insertions(+)
diff --git a/board/sifive/unmatched/spl.c b/board/sifive/unmatched/spl.c
index b598f9f..d566327 100644
--- a/board/sifive/unmatched/spl.c
+++ b/board/sifive/unmatched/spl.c
@@ -16,6 +16,9 @@
#include
#include
+#define UBRDG_RESETSIFIVE_GENERIC_GPIO_NR(0, 7)
+#define ULPI_RESET SIFIVE_GENERIC_GPIO_NR(0, 9)
+#define UHUB_RESET SIFIVE_GENERIC_GPIO_NR(0, 11)
#define GEM_PHY_RESET SIFIVE_GENERIC_GPIO_NR(0, 12)
#define MODE_SELECT_REG0x1000
@@ -61,6 +64,21 @@ static inline int spl_gemgxl_init(void)
return ret;
}
+static inline int spl_usb_pcie_bridge_init(void)
+{
+ return spl_reset_device_by_gpio("usb_pcie_bridge_reset", UBRDG_RESET,
3000);
+}
+
+static inline int spl_usb_hub_init(void)
+{
+ return spl_reset_device_by_gpio("usb_hub_reset", UHUB_RESET, 100);
+}
+
+static inline int spl_ulpi_init(void)
+{
+ return spl_reset_device_by_gpio("ulpi_reset", ULPI_RESET, 1);
+}
+
int spl_board_init_f(void)
{
int ret;
@@ -77,6 +95,24 @@ int spl_board_init_f(void)
goto end;
}
+ ret = spl_usb_pcie_bridge_init();
+ if (ret) {
+ debug("USB Bridge (ASM1042A) init failed: %d\n", ret);
+ goto end;
+ }
+
+ ret = spl_usb_hub_init();
+ if (ret) {
+ debug("USB Hub (ASM1074) init failed: %d\n", ret);
+ goto end;
+ }
+
+ ret = spl_ulpi_init();
+ if (ret) {
+ debug("USB 2.0 PHY (USB3320C) init failed: %d\n", ret);
+ goto end;
+ }
+
end:
return ret;
}
--
2.7.4
[PATCH 1/2] board: sifive: unmatched: refine GEMGXL initialized function in SPL
Create a new function spl_reset_device_by_gpio to reset the device
whose reset pin is connected to the GPIO. Then, using this function
to initialize GEMGXL.
Signed-off-by: Vincent Chen
---
board/sifive/unmatched/spl.c | 58 +---
1 file changed, 39 insertions(+), 19 deletions(-)
diff --git a/board/sifive/unmatched/spl.c b/board/sifive/unmatched/spl.c
index 5e1333b..b598f9f 100644
--- a/board/sifive/unmatched/spl.c
+++ b/board/sifive/unmatched/spl.c
@@ -22,43 +22,63 @@
#define MODE_SELECT_SD 0xb
#define MODE_SELECT_MASK GENMASK(3, 0)
-int spl_board_init_f(void)
+static inline int spl_reset_device_by_gpio(const char *label, int pin, int
low_width)
{
int ret;
- ret = spl_soc_init();
+ ret = gpio_request(pin, label);
if (ret) {
- debug("HiFive Unmatched FU740 SPL init failed: %d\n", ret);
+ debug("%s gpio request failed: %d\n", label, ret);
+ return ret;
+ }
+
+ ret = gpio_direction_output(pin, 1);
+ if (ret) {
+ debug("%s gpio direction set failed: %d\n", label, ret);
return ret;
}
+ udelay(1);
+
+ gpio_set_value(pin, 0);
+ udelay(low_width);
+ gpio_set_value(pin, 1);
+
+ return ret;
+}
+
+static inline int spl_gemgxl_init(void)
+{
+ int ret;
/*
* GEMGXL init VSC8541 PHY reset sequence;
* leave pull-down active for 2ms
*/
udelay(2000);
- ret = gpio_request(GEM_PHY_RESET, "gem_phy_reset");
+ ret = spl_reset_device_by_gpio("gem_phy_reset", GEM_PHY_RESET, 1);
+ mdelay(15);
+
+ return ret;
+}
+
+int spl_board_init_f(void)
+{
+ int ret;
+
+ ret = spl_soc_init();
if (ret) {
- debug("gem_phy_reset gpio request failed: %d\n", ret);
- return ret;
+ debug("HiFive Unmatched FU740 SPL init failed: %d\n", ret);
+ goto end;
}
- /* Set GPIO 12 (PHY NRESET) */
- ret = gpio_direction_output(GEM_PHY_RESET, 1);
+ ret = spl_gemgxl_init();
if (ret) {
- debug("gem_phy_reset gpio direction set failed: %d\n", ret);
- return ret;
+ debug("Gigabit ethernet PHY (VSC8541) init failed: %d\n", ret);
+ goto end;
}
- udelay(1);
-
- /* Reset PHY again to enter unmanaged mode */
- gpio_set_value(GEM_PHY_RESET, 0);
- udelay(1);
- gpio_set_value(GEM_PHY_RESET, 1);
- mdelay(15);
-
- return 0;
+end:
+ return ret;
}
u32 spl_boot_device(void)
--
2.7.4
[PATCH 0/2] board: sifive: unmatched: reset multiple devices in SPL
In SiFive unmatched board, the reset of the USB hub, PCIe-USB bridge, and ULPI rely on the power-cycling. However, sometimes the rebooting is without power-cycling. To ensure these devices will be reset in each rebooting, here always reset these devices in the spl_board_init_f(). In addition, because the reset pint of these four devices incluing GEMGXL connects to the GPIO, the 1st patch creates a new wrapper, spl_reset_device_by_gpio(), to address the GPIO operation during the reset. Vincent Chen (2): board: sifive: unmatched: refine GEMGXL initialized function in SPL board: sifive: unmatched: reset USB hub, PCIe-USB bridge, and ULPI device in SPL board/sifive/unmatched/spl.c | 90 +++- 1 file changed, 73 insertions(+), 17 deletions(-) -- 2.7.4
[PATCH] efi_loader: check update capsule parameters
UpdateCapsule() must return EFI_INVALID_PARAMETER in a number of cases,
listed by the UEFI specification and tested by the SCT. Add a common
function to do that.
This fixes SCT UpdateCapsule_Conf failures.
Reviewed-by: Grant Likely
Signed-off-by: Vincent Stehlé
Cc: Heinrich Schuchardt
Cc: Alexander Graf
---
include/efi_loader.h | 24
lib/efi_loader/efi_capsule.c | 8
lib/efi_loader/efi_runtime.c | 8
3 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 0a9c82a257e..426d1c72d7d 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -910,6 +910,30 @@ extern const struct efi_firmware_management_protocol
efi_fmp_fit;
extern const struct efi_firmware_management_protocol efi_fmp_raw;
/* Capsule update */
+static inline efi_status_t
+efi_valid_update_capsule_params(struct efi_capsule_header
+ **capsule_header_array,
+ efi_uintn_t capsule_count,
+ u64 scatter_gather_list)
+{
+ u32 flags;
+
+ if (!capsule_count)
+ return EFI_INVALID_PARAMETER;
+
+ flags = capsule_header_array[0]->flags;
+
+ if (((flags & CAPSULE_FLAGS_PERSIST_ACROSS_RESET) &&
+!scatter_gather_list) ||
+ ((flags & CAPSULE_FLAGS_POPULATE_SYSTEM_TABLE) &&
+!(flags & CAPSULE_FLAGS_PERSIST_ACROSS_RESET)) ||
+ ((flags & CAPSULE_FLAGS_INITIATE_RESET) &&
+!(flags & CAPSULE_FLAGS_PERSIST_ACROSS_RESET)))
+ return EFI_INVALID_PARAMETER;
+
+ return EFI_SUCCESS;
+}
+
efi_status_t EFIAPI efi_update_capsule(
struct efi_capsule_header **capsule_header_array,
efi_uintn_t capsule_count,
diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
index 60309d4a07d..380cfd70290 100644
--- a/lib/efi_loader/efi_capsule.c
+++ b/lib/efi_loader/efi_capsule.c
@@ -442,12 +442,12 @@ efi_status_t EFIAPI efi_update_capsule(
EFI_ENTRY("%p, %zu, %llu\n", capsule_header_array, capsule_count,
scatter_gather_list);
- if (!capsule_count) {
- ret = EFI_INVALID_PARAMETER;
+ ret = efi_valid_update_capsule_params(capsule_header_array,
+ capsule_count,
+ scatter_gather_list);
+ if (ret != EFI_SUCCESS)
goto out;
- }
- ret = EFI_SUCCESS;
for (i = 0, capsule = *capsule_header_array; i < capsule_count;
i++, capsule = *(++capsule_header_array)) {
/* sanity check */
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 93a695fc27e..449ad8b9f36 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -467,6 +467,14 @@ efi_status_t __efi_runtime EFIAPI
efi_update_capsule_unsupported(
efi_uintn_t capsule_count,
u64 scatter_gather_list)
{
+ efi_status_t ret;
+
+ ret = efi_valid_update_capsule_params(capsule_header_array,
+ capsule_count,
+ scatter_gather_list);
+ if (ret != EFI_SUCCESS)
+ return ret;
+
return EFI_UNSUPPORTED;
}
--
2.30.2
Re: [PATCH 1/1] sandbox: fix sandbox_reset()
On Wed, May 12, 2021 at 06:38:51PM +0200, Heinrich Schuchardt wrote: > state_uninit() and dm_uninit() are mutually exclusive: > > state_uninit() prints via drivers. So it cannot be executed after > dm_uninit(). > > dm_uninit() requires memory. So it cannot be executed after state_uninit() > which releases all memory. > > Just skip dm_uninit() when resetting the sandbox. We will wake up in a new > process and allocate new memory. So this cleanup is not required. We don't > do it in sandbox_exit() either. > > This avoids a segmentation error when efi_reset_system_boottime() is > invoked by a UEFI application. Hi Heinrich, Thanks for fixing this! Before, I was hitting the following segfault with the sandbox under qemu arm64 when running the UEFI SCT: Boot services test: ExitBootServices_Conf Iterations: 1/1 System will cold reset after 2 second and test will be resumed after reboot.resetting ... Writing sandbox state qemu: uncaught target signal 11 (Segmentation fault) - core dumped With your patch I do not hit this segfault anymore. FWIW, feel free to add (or not): Tested-by: Vincent Stehlé Best regards, Vincent. > > Signed-off-by: Heinrich Schuchardt > --- > arch/sandbox/cpu/start.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c > index e87365e800..4ffd97ccbc 100644 > --- a/arch/sandbox/cpu/start.c > +++ b/arch/sandbox/cpu/start.c > @@ -425,9 +425,6 @@ void sandbox_reset(void) > if (state_uninit()) > os_exit(2); > > - if (dm_uninit()) > - os_exit(2); > - > /* Restart U-Boot */ > os_relaunch(os_argv); > } > -- > 2.30.2 >
[PATCH] pwm: sifive: make set_config() and set_enable() work properly
The pwm_sifive_set_config() and pwm_sifive_set_enable() cannot work
properly due to the wrong implementations. It will cause the u-boot
PWM command to not work as expected. The bugs will be resolved in this
patch.
Signed-off-by: Vincent Chen
---
drivers/pwm/pwm-sifive.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c
index 01212d6..b9813a3 100644
--- a/drivers/pwm/pwm-sifive.c
+++ b/drivers/pwm/pwm-sifive.c
@@ -38,6 +38,9 @@
#define PWM_SIFIVE_SIZE_PWMCMP 4
#define PWM_SIFIVE_CMPWIDTH 16
+#define PWM_SIFIVE_CHANNEL_ENABLE_VAL 0
+#define PWM_SIFIVE_CHANNEL_DISABLE_VAL 0x
+
DECLARE_GLOBAL_DATA_PTR;
struct pwm_sifive_regs {
@@ -77,7 +80,7 @@ static int pwm_sifive_set_config(struct udevice *dev, uint
channel,
*/
scale_pow = lldiv((uint64_t)priv->freq * period_ns, 10);
scale = clamp(ilog2(scale_pow) - PWM_SIFIVE_CMPWIDTH, 0, 0xf);
- val |= FIELD_PREP(PWM_SIFIVE_PWMCFG_SCALE, scale);
+ val |= (FIELD_PREP(PWM_SIFIVE_PWMCFG_SCALE, scale) |
PWM_SIFIVE_PWMCFG_EN_ALWAYS);
/*
* The problem of output producing mixed setting as mentioned at top,
@@ -88,6 +91,7 @@ static int pwm_sifive_set_config(struct udevice *dev, uint
channel,
num = (u64)duty_ns * (1U << PWM_SIFIVE_CMPWIDTH);
frac = DIV_ROUND_CLOSEST_ULL(num, period_ns);
frac = min(frac, (1U << PWM_SIFIVE_CMPWIDTH) - 1);
+ frac = (1U << PWM_SIFIVE_CMPWIDTH) - 1 - frac;
writel(val, priv->base + regs->cfg);
writel(frac, priv->base + regs->cmp0 + channel *
@@ -100,18 +104,15 @@ static int pwm_sifive_set_enable(struct udevice *dev,
uint channel, bool enable)
{
struct pwm_sifive_priv *priv = dev_get_priv(dev);
const struct pwm_sifive_regs *regs = &priv->data->regs;
- u32 val;
debug("%s: Enable '%s'\n", __func__, dev->name);
- if (enable) {
- val = readl(priv->base + regs->cfg);
- val |= PWM_SIFIVE_PWMCFG_EN_ALWAYS;
- writel(val, priv->base + regs->cfg);
- } else {
- writel(0, priv->base + regs->cmp0 + channel *
- PWM_SIFIVE_SIZE_PWMCMP);
- }
+ if (enable)
+ writel(PWM_SIFIVE_CHANNEL_ENABLE_VAL, priv->base +
+ regs->cmp0 + channel * PWM_SIFIVE_SIZE_PWMCMP);
+ else
+ writel(PWM_SIFIVE_CHANNEL_DISABLE_VAL, priv->base +
+ regs->cmp0 + channel * PWM_SIFIVE_SIZE_PWMCMP);
return 0;
}
--
2.7.4
[PATCH] efi_loader: check query_variable_info attributes
QueryVariableInfo() must return EFI_INVALID_PARAMETER when an invalid
combination of attribute bits is supplied.
This fixes three SCT QueryVariableInfo_Conf failures.
Signed-off-by: Vincent Stehlé
Reviewed-by: Grant Likely
Cc: Heinrich Schuchardt
Cc: Alexander Graf
Changes since v1:
- Remove if/else and return directly
---
lib/efi_loader/efi_var_common.c | 4
1 file changed, 4 insertions(+)
diff --git a/lib/efi_loader/efi_var_common.c b/lib/efi_loader/efi_var_common.c
index b11ed91a74a..cbf8685fad5 100644
--- a/lib/efi_loader/efi_var_common.c
+++ b/lib/efi_loader/efi_var_common.c
@@ -160,6 +160,10 @@ efi_status_t EFIAPI efi_query_variable_info(
EFI_ENTRY("%x %p %p %p", attributes, maximum_variable_storage_size,
remaining_variable_storage_size, maximum_variable_size);
+ if (!attributes || ((attributes & EFI_VARIABLE_RUNTIME_ACCESS) &&
+ !(attributes & EFI_VARIABLE_BOOTSERVICE_ACCESS)))
+ return EFI_EXIT(EFI_INVALID_PARAMETER);
+
ret = efi_query_variable_info_int(attributes,
maximum_variable_storage_size,
remaining_variable_storage_size,
--
2.30.2
[PATCH] pwm: sifive: make set_config() and set_enable() work properly
The pwm_sifive_set_config() and pwm_sifive_set_enable() cannot work
properly due to the wrong implementations. It will cause the u-boot
PWM command to not work as expected. The bugs will be resolved in this
patch.
Signed-off-by: Vincent Chen
---
drivers/pwm/pwm-sifive.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c
index 01212d6..b9813a3 100644
--- a/drivers/pwm/pwm-sifive.c
+++ b/drivers/pwm/pwm-sifive.c
@@ -38,6 +38,9 @@
#define PWM_SIFIVE_SIZE_PWMCMP 4
#define PWM_SIFIVE_CMPWIDTH 16
+#define PWM_SIFIVE_CHANNEL_ENABLE_VAL 0
+#define PWM_SIFIVE_CHANNEL_DISABLE_VAL 0x
+
DECLARE_GLOBAL_DATA_PTR;
struct pwm_sifive_regs {
@@ -77,7 +80,7 @@ static int pwm_sifive_set_config(struct udevice *dev, uint
channel,
*/
scale_pow = lldiv((uint64_t)priv->freq * period_ns, 10);
scale = clamp(ilog2(scale_pow) - PWM_SIFIVE_CMPWIDTH, 0, 0xf);
- val |= FIELD_PREP(PWM_SIFIVE_PWMCFG_SCALE, scale);
+ val |= (FIELD_PREP(PWM_SIFIVE_PWMCFG_SCALE, scale) |
PWM_SIFIVE_PWMCFG_EN_ALWAYS);
/*
* The problem of output producing mixed setting as mentioned at top,
@@ -88,6 +91,7 @@ static int pwm_sifive_set_config(struct udevice *dev, uint
channel,
num = (u64)duty_ns * (1U << PWM_SIFIVE_CMPWIDTH);
frac = DIV_ROUND_CLOSEST_ULL(num, period_ns);
frac = min(frac, (1U << PWM_SIFIVE_CMPWIDTH) - 1);
+ frac = (1U << PWM_SIFIVE_CMPWIDTH) - 1 - frac;
writel(val, priv->base + regs->cfg);
writel(frac, priv->base + regs->cmp0 + channel *
@@ -100,18 +104,15 @@ static int pwm_sifive_set_enable(struct udevice *dev,
uint channel, bool enable)
{
struct pwm_sifive_priv *priv = dev_get_priv(dev);
const struct pwm_sifive_regs *regs = &priv->data->regs;
- u32 val;
debug("%s: Enable '%s'\n", __func__, dev->name);
- if (enable) {
- val = readl(priv->base + regs->cfg);
- val |= PWM_SIFIVE_PWMCFG_EN_ALWAYS;
- writel(val, priv->base + regs->cfg);
- } else {
- writel(0, priv->base + regs->cmp0 + channel *
- PWM_SIFIVE_SIZE_PWMCMP);
- }
+ if (enable)
+ writel(PWM_SIFIVE_CHANNEL_ENABLE_VAL, priv->base +
+ regs->cmp0 + channel * PWM_SIFIVE_SIZE_PWMCMP);
+ else
+ writel(PWM_SIFIVE_CHANNEL_DISABLE_VAL, priv->base +
+ regs->cmp0 + channel * PWM_SIFIVE_SIZE_PWMCMP);
return 0;
}
--
2.7.4
[PATCH] sandbox: dtsi: add rng
Having an rng in the sandbox is useful not only for tests but also for e.g.
UEFI. Therefore, copy the rng node from test.dts to sandbox.dtsi.
In the case of UEFI, it can then be verified with `efidebug dh' that a
"Random Number Generator" protocol is indeed present.
This also fixes the following `bootefi' error:
Missing RNG device for EFI_RNG_PROTOCOL
Signed-off-by: Vincent Stehlé
Cc: Simon Glass
---
arch/sandbox/dts/sandbox.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/sandbox/dts/sandbox.dtsi b/arch/sandbox/dts/sandbox.dtsi
index dc933f3bfc7..43b9342ce56 100644
--- a/arch/sandbox/dts/sandbox.dtsi
+++ b/arch/sandbox/dts/sandbox.dtsi
@@ -196,6 +196,10 @@
compatible = "sandbox,reset";
};
+ rng {
+ compatible = "sandbox,sandbox-rng";
+ };
+
sound {
compatible = "sandbox,sound";
cpu {
--
2.30.1
[PATCH] virtio: fix off by one device id comparison
VIRTIO_ID_MAX_NUM is the largest device ID plus 1. Therefore a device id
cannot be greater or equal to VIRTIO_ID_MAX_NUM. Fix the comparison
accordingly.
Fixes: 8fb49b4c7a82 ("dm: Add a new uclass driver for VirtIO transport devices")
Signed-off-by: Vincent Stehlé
Cc: Simon Glass
Cc: Bin Meng
---
drivers/virtio/virtio-uclass.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/virtio/virtio-uclass.c b/drivers/virtio/virtio-uclass.c
index cf2cfaef2cf..0379536c542 100644
--- a/drivers/virtio/virtio-uclass.c
+++ b/drivers/virtio/virtio-uclass.c
@@ -227,7 +227,7 @@ static int virtio_uclass_post_probe(struct udevice *udev)
struct udevice *vdev;
int ret;
- if (uc_priv->device > VIRTIO_ID_MAX_NUM) {
+ if (uc_priv->device >= VIRTIO_ID_MAX_NUM) {
debug("(%s): virtio device ID %d exceeds maximum num\n",
udev->name, uc_priv->device);
return 0;
--
2.29.2
Re: [U-Boot] imx6: USB SDP failed for u-boot-dtb.img
I put my log here https://pastebin.com/5aPjntnb , but i use standard DT-less u-boot.img. Maybe it could be easier to talk in u-boot IRC? 2018-03-06 15:55 GMT+01:00 Jagan Teki : > Hi Michael, Vincent, > > On Tue, Mar 6, 2018 at 7:57 PM, Vincent Prince > wrote: > > Hi all, > > > > Jagan , do you confirm your mx6_usb_sdp_spl.conf contains the 3rd line? > > > > mx6_spl_sdp > > hid,uboot_header,1024,0x91,0x1000,512M,0x0090,0x4 > > u-boot-dtb.img:jump header2 > > > > 2018-03-06 15:18 GMT+01:00 Michael Nazzareno Trimarchi < > > mich...@amarulasolutions.com>: > > > >> Hi Jagan > >> > >> There is a git log for that configuration file. I have the impression > >> that is done in two steps > > Yes, I've verified the single command to download SPL and u-boot-dtb.img > > imx_usb.conf > 0x15a2:0x0054, mx6_usb_rom.conf, 0x0525:0xb4a4, mx6_usb_sdp_spl.conf > > mx6_usb_rom.conf > mx6_qsb > hid,1024,0x91,0x1000,512M,0x0090,0x4 > SPL:jump header2 > > mx6_usb_sdp_spl.conf > mx6_spl_sdp > hid,uboot_header,1024,0x91,0x1000,512M,0x0090,0x4 > u-boot-dtb.img:jump header2 > > Here is the download log [1], seems like the load_size and load_addr > were mismatch or unrecognised > > Can anyone send the working download log? > > [1] https://paste.ubuntu.com/p/mrSmdPRHb7/ > > Jagan. > > -- > Jagan Teki > Free Software Engineer | www.openedev.com > U-Boot, Linux | Upstream Maintainer > Hyderabad, India. > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] imx6: USB SDP failed for u-boot-dtb.img
Hi all, Jagan , do you confirm your mx6_usb_sdp_spl.conf contains the 3rd line? mx6_spl_sdp hid,uboot_header,1024,0x91,0x1000,512M,0x0090,0x4 u-boot-dtb.img:jump header2 BR, Vincent 2018-03-06 15:18 GMT+01:00 Michael Nazzareno Trimarchi < mich...@amarulasolutions.com>: > Hi Jagan > > There is a git log for that configuration file. I have the impression > that is done in two steps > > Michael > > On Tue, Mar 6, 2018 at 3:16 PM, Stefano Babic wrote: > > On 06/03/2018 15:12, Jagan Teki wrote: > >> On Tue, Mar 6, 2018 at 6:46 PM, Fabio Estevam > wrote: > >>> Hi Jagan, > >>> > >>> On Tue, Mar 6, 2018 at 9:25 AM, Jagan Teki > wrote: > >>>> Hi, > >>>> > >>>> U-Boot SPL 2018.03-rc3-00111-g0cb2734156-dirty (Mar 06 2018 - > 17:19:36 +0530) > >>>> Trying to boot from USB SDP > >>>> SDP: initialize... > >>>> SDP: handle requests... > >>>> > >>>> and SPL reenumerated USB VID/PID as > >>>> [24774.255201] usb 1-2: new high-speed USB device number 101 using > xhci_hcd > >>>> [24774.425174] usb 1-2: New USB device found, idVendor=0525, > idProduct=b4a4 > >>>> [24774.425181] usb 1-2: New USB device strings: Mfr=1, Product=2, > SerialNumber=0 > >>>> [24774.425185] usb 1-2: Product: USB download gadget > >>>> [24774.425189] usb 1-2: Manufacturer: FSL > >>>> [24774.433598] hid-generic 0003:0525:B4A4.005C: hiddev97,hidraw2: USB > >>>> HID v1.10 Device [FSL USB download gadget] > >>>> > >>>> Now I've launched u-boot-dtb.img > >>>> > >>>> $ imx_usb u-boot-dtb.img > >>>> ... > >>>> vid=0x0525 pid=0xb4a4 file_name=mx6_usb_sdp_spl.conf > >>>> config file <.//mx6_usb_sdp_spl.conf> > >>>> parse .//mx6_usb_sdp_spl.conf > >>>> Trying to open device vid=0x0525 pid=0xb4a4 > >>>> Interface 0 claimed > >>>> HAB security state: development mode (0x56787856) > >>>> == work item > >>>> filename /work/code/u-boot/u-boot-dtb.img > >>>> load_size 0 bytes > >>>> load_addr 0x > >>>> dcd 1 > >>>> clear_dcd 0 > >>>> plug 1 > >>>> jump_mode 2 > >>>> jump_addr 0x > >>>> == end work item > >>>> > >>>> unknown load address > >>>> DoIRomDownload failed, err=-3 > >>>> HAB security state: development mode (0x56787856) > >>>> > >>>> Here is mx6_usb_sdp_spl.conf file > >>>>mx6_spl_sdp > >>>>hid,uboot_header,1024,0x91,0x1000,512M,0x0090,0x4 > >>>> > >>>> Look like the u-boot-dtb.img has FIT header and imx_usb can't process > >>>> the same, any help? > >>> > >>> Is this a regression? If so, are you able to run a 'git bisect'? > >> > >> I don't think it's regression, I'm guessing this is first test with > >> u-boot-dtb.img or did you tested the similar image type? > >> > > > > Never tested with u-boot-dtb.img, it worked fine with u-boot.img > > > > Best regards, > > Stefano > > > > -- > > = > > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > > Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de > > = > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > https://lists.denx.de/listinfo/u-boot > > > > -- > | Michael Nazzareno Trimarchi Amarula Solutions BV | > | COO - Founder Cruquiuskade 47 | > | +31(0)851119172 Amsterdam 1018 AM NL | > | [`as] http://www.amarulasolutions.com | > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] Re: [PATCH v3 13/20] Revert: arm64: allwinner: a64: pine64: Use dcdc1 regulator for mmc0
Hi, On Fri, Mar 2, 2018 at 5:24 PM, Andre Przywara wrote: > Regarding the whole forward/backward compatibility: > I clearly see the difficulty in coming up with a "perfect" DT from day > one, especially for badly documented SoCs, where mainlining is driven by > hobbyists. So I was wondering if we introduce a grace period, where we > declare the DT "unstable" or "subject to incompatible changes" for some > releases (not too many). In hindsight we might declare 4.12 the stable > DT base for the A64, for instance. > This would allow us to start upstreaming early, with a small feature set > only (just serial + clocks + pinctrl, as for the H6). Additional > features (PMIC) might then add small incompatibilities (like this one > here), until we are reasonably confident about the DT. > Does that sound useful? Kind of "staging" for DT ? -- Vincent Legoll ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] On writing .ext4 image to MMC
Hi, I think you can also create an ext4 image with extra space in it. You can use bmap tool if size is a concern. Regards, Vincent 2018-01-12 19:22 GMT+01:00 Adam Lee : > I was hoping to get this done in the bootloader otherwise I have to change > the rootfs ;) > > On Fri, Jan 12, 2018 at 1:18 PM Michael Nazzareno Trimarchi < > mich...@amarulasolutions.com> wrote: > > > Hi > > > > On 12 Jan. 2018 7:15 pm, "Adam Lee" wrote: > > > > Hi Michael, I used gparted to fix the issue. I am just wondering if I can > > do all this in U-Boot. > > If there is no good solution, I will put one-time script in my rootfs to > > do this task. > > > > > > Sorry most of the system on first boot create a first instance of > > something like ssd for keys. I think that just use resize FS should do > the > > trick. Why is should be done in bootloader? > > > > Michael > > > > > > Adam > > > > On Fri, Jan 12, 2018 at 10:18 AM Michael Nazzareno Trimarchi < > > mich...@amarulasolutions.com> wrote: > > > >> Hi > >> > >> > >> resize2fs from linux? > >> > >> Michael > >> > >> On Fri, Jan 12, 2018 at 4:15 PM, Adam Lee > wrote: > >> > Hello everyone, > >> > > >> > I am able to download a .ext4 image over tftp and write it to my SD > >> card. > >> > The system boots fine. > >> > One last thing I have to figure out is to expand this .ext4 file > system > >> > that I just populated. > >> > If the image is 600MB, the partition size itself is 600MB, leaving no > >> room. > >> > > >> > Is there anything I can do to remedy this in U-Boot? > >> > > >> > Adam > >> > ___ > >> > U-Boot mailing list > >> > U-Boot@lists.denx.de > >> > https://lists.denx.de/listinfo/u-boot > >> > >> > >> > >> -- > >> | Michael Nazzareno Trimarchi Amarula Solutions BV | > >> | COO - Founder Cruquiuskade 47 > >> <https://maps.google.com/?q=Cruquiuskade+47&entry=gmail&source=g> | > >> | +31(0)851119172 <+31%2085%20111%209172> > >> Amsterdam 1018 AM NL | > >> | [`as] http://www.amarulasolutions.com > | > >> > > > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-boot][SDP] Trigger watchdog before calling usb_gadget_handle_interrupts
Hi all,
It's my first patch contribution, do I need to do anything more ?
Best regards,
Vincent
2017-10-26 13:52 GMT+02:00 Stefan Agner :
>
>
> On 26.10.2017 13:25, Lukasz Majewski wrote:
> > Hi Vincent,
> >
> >> This prevents board resets when calling sdp command on boards which
> >> have a watchdog.
> >>
> >> Signed-off-by: Vincent Prince
> >> ---
> >> drivers/usb/gadget/f_sdp.c | 4
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_sdp.c
> >> index 0fae66b..c3eba6d 100644
> >> --- a/drivers/usb/gadget/f_sdp.c
> >> +++ b/drivers/usb/gadget/f_sdp.c
> >> @@ -32,6 +32,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >>
> >> #define HID_REPORT_ID_MASK 0x00ff
> >>
> >> @@ -602,6 +603,8 @@ int sdp_init(int controller_index)
> >> puts("\rCTRL+C - Operation aborted.\n");
> >> return 1;
> >> }
> >> +
> >> +WATCHDOG_RESET();
> >> usb_gadget_handle_interrupts(controller_index);
> >> }
> >>
> >> @@ -712,6 +715,7 @@ void sdp_handle(int controller_index)
> >> return;
> >> }
> >>
> >> +WATCHDOG_RESET();
> >> usb_gadget_handle_interrupts(controller_index);
> >>
> >> sdp_handle_in_ep();
> > Reviewed-by: Lukasz Majewski
>
> Thanks for the patch! Looks good to me too.
> Reviewed-by: Stefan Agner
>
> Best regards,
> Stefan
>
> >
> >
> > Best regards,
> >
> > Lukasz Majewski
> >
> > --
> >
> > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [U-boot][SDP] Trigger watchdog before calling usb_gadget_handle_interrupts
This prevents board resets when calling sdp command on boards which have a
watchdog.
Signed-off-by: Vincent Prince
---
drivers/usb/gadget/f_sdp.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_sdp.c
index 0fae66b..c3eba6d 100644
--- a/drivers/usb/gadget/f_sdp.c
+++ b/drivers/usb/gadget/f_sdp.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#define HID_REPORT_ID_MASK 0x00ff
@@ -602,6 +603,8 @@ int sdp_init(int controller_index)
puts("\rCTRL+C - Operation aborted.\n");
return 1;
}
+
+ WATCHDOG_RESET();
usb_gadget_handle_interrupts(controller_index);
}
@@ -712,6 +715,7 @@ void sdp_handle(int controller_index)
return;
}
+ WATCHDOG_RESET();
usb_gadget_handle_interrupts(controller_index);
sdp_handle_in_ep();
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [U-boot][SDP] Trigger watchdog before calling usb_gadget_handle_interrupts
This prevents board resets when calling sdp command on boards which have a
watchdog.
Signed-off-by: Vincent Prince
---
drivers/usb/gadget/f_sdp.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_sdp.c
index 0fae66b..c3eba6d 100644
--- a/drivers/usb/gadget/f_sdp.c
+++ b/drivers/usb/gadget/f_sdp.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#define HID_REPORT_ID_MASK 0x00ff
@@ -602,6 +603,8 @@ int sdp_init(int controller_index)
puts("\rCTRL+C - Operation aborted.\n");
return 1;
}
+
+ WATCHDOG_RESET();
usb_gadget_handle_interrupts(controller_index);
}
@@ -712,6 +715,7 @@ void sdp_handle(int controller_index)
return;
}
+ WATCHDOG_RESET();
usb_gadget_handle_interrupts(controller_index);
sdp_handle_in_ep();
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Ethernet problem with u-boot for APF27
Hello, Thank you for your answers. I found a solution. The problem came from the environment variables. I just used the wrong argument with the command "setenv". Know I have "eth0:on" everywhere and I reach to do all the run update again. Vincent > Hi Vincent, > > Which U-Boot version do you use? > Do you have any boot message related to the ethernet FEC device? > > You could check your environment variables and validate them with a ping. > If you suspect your environment variables are corrupted you can reset them > with the command: > > env default -f -a; saveenv > > then set them again manually and try to ping a device on the network. > > A ping 127.0.0.1 should also work to test the local loop. > > Regards, > Eric ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Ethernet problem with u-boot for APF27
Hello everybody,
I have an APF27 and I have a problem with ethernet. I first did all the run
update correctly through a working tftp server (run update_uboot, run
update_dtb, run update_kernel and run update_rootfs). Then, when I restarted
the board, it was impossible to obtain files from tftp server. I can ping
from my computer to my virtual machin but not from my board to my virtual
machin. When I print the environement (printenv), the first line indicates:
addipargs=setenv bootargs ${bootargs}
p=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:eth0:off
Moreover, the led on the swith and on the board for ethernet is not turned
on.
When I try run update_dtb for example, I have the following message:
FEC: Autonegotiation timeout
Using FEC device
TFTP from server 192.168.1.38; our IP address is 192.168.1.246
Filename 'apf27.dtb'.
Load address: 0xa00
Loading: *
ARP Retry count exceeded; starting again
I tried with three different APF27 board that were working previously.
Therefore, it seems that it is a problem of the u-boot or a configuration
done later that turns off ethernet.
Does someone have any idea to solve this problem?
Thanks
Vincent
--
Sent from: http://u-boot.10912.n7.nabble.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] Re: [PATCH v3 2/3] video: add an option for video simplefb via DT
> SIMPLEFB is also used by other platforms, but most platforms also > won't use it. > > Adding an imply VIDEO_DT_SIMPLEFB to VIDEO_DE2 would make everyone > happy I guess. You meant adding a "select VIDEO_DT_SIMPLEFB" to VIDEO_DE2 ? -- Vincent Legoll ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/8] imx: add USB Serial Download Protocol (SDP) support
Hi Stefan,
It was probably a Windows bug as it is almost working now.
I was wondering why sdp command is expecting a jump ?
Is it necessary to jump after USB transfer, or we should download
anything we want and jump if asked ?
Regards,
Vincent
2017-09-08 18:37 GMT+02:00 Stefan Agner :
> Hi Vincent,
>
> On 2017-09-08 01:27, Vincent Prince wrote:
>> Hi everyone,
>>
>> I managed to get SDP protocol to work with on my custom i.MX6 board,
>> so big thanks to Stefan for your work!
>>
>> I'm now trying to load swupdate ramdisk with u-boot sdp command,
>> without success.
>> Is it a possible use case ?
>
> Yes it should work, we use the U-Boot sdp command to download a squashfs
> based ramdisk in our Toradex Easy Installer:
> http://developer.toradex.com/software/toradex-easy-installer
>
>>
>> Here my steps:
>>
>> In u-boot:
>> => sdp 0
>>
>> On Host,
>> $ imx_usb
>>
>> config file
>> vid=0x15a2 pid=0x0061 file_name=mx6_usb_rom.conf -> vid=0x0525
>> pid=0xb4a4 file_name=mx6_usb_sdp_spl.conf
>> vid=0x0525 pid=0xa4a5 file_name=mx6_usb_uboot.conf
>> config file
>> parse C:\Users\vpr\IMXUSBLOADER2\delivery\\mx6_usb_uboot.conf
>> Trying to open device vid=0x0525 pid=0xa4a5.
>> Could not open device vid=0x0525 pid=0xa4a5
>
> Is VID/PID showing up in Device Manager?
>
> We did saw some problems with certain USB host implementation, so it
> might be a device dependency... I would also try a different
> machine/maybe Linux machine...
>
>>
>> VID/PID in imx_usb.conf are correctly detected, and correct
>> configuration file is launched (mx6_usb_uboot.conf),
>> it contains:
>>
>> mx6_usb_sdp_uboot
>> hid,1024,0x1000,1G,0x00907000,0x31000
>> test.txt:load 0x1210
>>
>> My imx_usb.conf is the following:
>>
>> #vid:pid, config_file
>> 0x15a2:0x0061, mx6_usb_rom.conf, 0x0525:0xb4a4, mx6_usb_sdp_spl.conf
>> 0x0525:0xa4a5, mx6_usb_uboot.conf
>
> Yeah assuming you use the Toradex branch of imx_loader currently this
> should work.
>
> Our script looks like this:
> mx6_usb_sdp_uboot
> #hid/bulk,[old_header,]max packet size, {ram start, ram size}(repeat
> valid ram areas)
> hid,1024,0x1000,1G,0x00907000,0x31000
> #Load complete FIT image to $ramdisk_addr_r
> tezi.itb:load 0x1210
> #Load script to $loadaddr and jump to it
> boot-sdp.scr:load 0x1200,jump 0x1200
>
> --
> Stefan
>
>
>>
>> Am I missing something,
>> Thanks,
>> Vincent
>>
>> 2017-09-01 22:09 GMT+02:00 Stefan Agner :
>>>
>>>
>>> On September 1, 2017 12:25:44 PM PDT, Fabio Estevam
>>> wrote:
>>>>On Fri, Sep 1, 2017 at 3:54 PM, Fabio Estevam
>>>>wrote:
>>>>
>>>>> I have tested this method and it works, thanks.
>>>>>
>>>>> Do you plan to usptream this method?
>>>>
>>>>Or I can also put your patch as part of my series that adds SDP
>>>>support for imx6qsabresd if you prefer.
>>>
>>> Let me do a separate, I guess it could be controversial...
>>>
>>> --
>>> Stefan
>>> --
>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>> ___
>>> U-Boot mailing list
>>> U-Boot@lists.denx.de
>>> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/8] imx: add USB Serial Download Protocol (SDP) support
Hi everyone, I managed to get SDP protocol to work with on my custom i.MX6 board, so big thanks to Stefan for your work! I'm now trying to load swupdate ramdisk with u-boot sdp command, without success. Is it a possible use case ? Here my steps: In u-boot: => sdp 0 On Host, $ imx_usb config file vid=0x15a2 pid=0x0061 file_name=mx6_usb_rom.conf -> vid=0x0525 pid=0xb4a4 file_name=mx6_usb_sdp_spl.conf vid=0x0525 pid=0xa4a5 file_name=mx6_usb_uboot.conf config file parse C:\Users\vpr\IMXUSBLOADER2\delivery\\mx6_usb_uboot.conf Trying to open device vid=0x0525 pid=0xa4a5. Could not open device vid=0x0525 pid=0xa4a5 VID/PID in imx_usb.conf are correctly detected, and correct configuration file is launched (mx6_usb_uboot.conf), it contains: mx6_usb_sdp_uboot hid,1024,0x1000,1G,0x00907000,0x31000 test.txt:load 0x1210 My imx_usb.conf is the following: #vid:pid, config_file 0x15a2:0x0061, mx6_usb_rom.conf, 0x0525:0xb4a4, mx6_usb_sdp_spl.conf 0x0525:0xa4a5, mx6_usb_uboot.conf Am I missing something, Thanks, Vincent 2017-09-01 22:09 GMT+02:00 Stefan Agner : > > > On September 1, 2017 12:25:44 PM PDT, Fabio Estevam > wrote: >>On Fri, Sep 1, 2017 at 3:54 PM, Fabio Estevam >>wrote: >> >>> I have tested this method and it works, thanks. >>> >>> Do you plan to usptream this method? >> >>Or I can also put your patch as part of my series that adds SDP >>support for imx6qsabresd if you prefer. > > Let me do a separate, I guess it could be controversial... > > -- > Stefan > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCHv6 00/28] Retrieve MAC address from EEPROM
Hello, > * Renamed sunxi_[eg]mac to sun[47]_mac to be more clear and allowing preparing > to merge common parts into sunxi_common Wouldn't those better renamed to sun[47]i_mac instead, for consistency ? -- Vincent Legoll ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Booting Wandboard through USB
Hi Fabio, Stefan, Indeed i saw it this morning with great enthusiasm, I'm currently in vacation, I'll test it in two weeks when I'll back to work. Thanks, Vincent 2017-08-05 14:22 GMT+02:00 Fabio Estevam : > Hi Vincent, > > On Thu, Jul 27, 2017 at 6:05 AM, Vincent Prince > wrote: > > following: > > - https://lists.denx.de/pipermail/u-boot/2015-May/215573.html > > - https://lists.denx.de/pipermail/u-boot/2015-June/215606.html > > > > > > Hi everyone, > > > > I'd like to know if something is going on regarding this topic ? > > > > I managed to flash a yocto BSP with SPL with USB+serial with Fabio help, > > but I found it a bit painful, and hard to automate. > > > > - Go into serial console to reboot, interrupt uboot, and type bmode usb. > > - Quit serial console > > - Launch imx_usb_loader, > > - Send u-boot.bin with ymodem (teraterm on windows, kermit on linux) > > - Go back to serial console, interrupt u-boot > > - Mount Usb OTG (ums 1 mmc 0) > > - Flash wic.gz image > > - Reset u-boot. > > > > What is a bit annoying is the use of ymodem to load u-boot.bin. > > Anybody has a cleaner solution ? > > Stefan has sent a patch series that seems to really help on loading > SPL + u-boot.img via USB: > > https://www.mail-archive.com/u-boot@lists.denx.de/msg259052.html > > I haven't had a chance to test it yet as I am currently out of office > without hardware access. > > Please give it a try and provide your feedback. > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Booting Wandboard through USB
following: - https://lists.denx.de/pipermail/u-boot/2015-May/215573.html - https://lists.denx.de/pipermail/u-boot/2015-June/215606.html Hi everyone, I'd like to know if something is going on regarding this topic ? I managed to flash a yocto BSP with SPL with USB+serial with Fabio help, but I found it a bit painful, and hard to automate. - Go into serial console to reboot, interrupt uboot, and type bmode usb. - Quit serial console - Launch imx_usb_loader, - Send u-boot.bin with ymodem (teraterm on windows, kermit on linux) - Go back to serial console, interrupt u-boot - Mount Usb OTG (ums 1 mmc 0) - Flash wic.gz image - Reset u-boot. What is a bit annoying is the use of ymodem to load u-boot.bin. Anybody has a cleaner solution ? Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] tools/fw_env: use fsync to ensure that data is physically stored
For completness, here is the original post url : https://patchwork.ozlabs.org/patch/245097/ https://lists.denx.de/pipermail/u-boot/2013-May/154752.html 2017-07-13 15:11 GMT+02:00 Vincent Prince : > Hi all, > > We had the same issue on our custom board, and this patch fixed it. > > We use fw_setenv for updating our BSP, and before the patch, 100 boards > over 170 didn't work, > and after, 170/170 did get the update. > > This patches worked well for us, > Thanks Michael > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] tools/fw_env: use fsync to ensure that data is physically stored
Hi all, We had the same issue on our custom board, and this patch fixed it. We use fw_setenv for updating our BSP, and before the patch, 100 boards over 170 didn't work, and after, 170/170 did get the update. This patches worked well for us, Thanks Michael ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH RFC] sun50i: a64: Add A64-OLinuXino initial support
Hello, On Mon, Jun 12, 2017 at 9:23 AM, Jagan Teki wrote: > From: Jagan Teki > > OLimex A64-OLinuXino is an open-source hardware board > using the Allwinner A64 SOC. > > A64 Orangepi Win/WinPlus has Cut'n'pasted ? This does not look like $SUBJECT, or are those boards related ? -- Vincent Legoll ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH] sunxi: set up PLL1 on sun6i+ without use dividers
Hello, On Sun, Apr 9, 2017 at 6:19 PM, Icenowy Zheng wrote: > This patch is an original work by Ondrej Jirman, however, he didn't add > a Signed-off-by tag here to his commit. So I take this code and added my > Signed-off-by. Isn't adding a "From:" header line the way to reflect that ? -- Vincent Legoll ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] HAB and fuse reading
Hi ! I'm wondering why the is_hab_enabled function (see arch/arm/imx-common/hab.c) is reading the fuses rather than the OCOTP shadow registers ? During my attempts at secure boot I realized two things: - by default, if secure boot is not enabled, the HAB rom will block any authenticate code - if the secure boot fuse is not burnt, but the shadow register is written by software before calling the HAB entry point, authenticate works fine. Since the ROM seems to read the shadow register rather than the fuse, why is u-boot doing differently ? Best regards, Vincent ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-BOOT for I960 Board
___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/3] arm: Fix SCFG ICID reg addresses
On the LS102x boards, in order to initialize the ICID values of masters,
the dev_stream_id array holds absolute offsets from the base of SCFG.
In ls102xa_config_ssmu_stream_id, the base pointer is cast to uint32_t *
before adding the offset, leading to an invalid address. Casting it to
void * solves the issue.
Signed-off-by: Vincent Siles
---
Changes in v3: None
Changes in v2: None
board/freescale/common/ls102xa_stream_id.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/freescale/common/ls102xa_stream_id.c
b/board/freescale/common/ls102xa_stream_id.c
index f434269..39e7b30 100644
--- a/board/freescale/common/ls102xa_stream_id.c
+++ b/board/freescale/common/ls102xa_stream_id.c
@@ -10,11 +10,11 @@
void ls102xa_config_smmu_stream_id(struct smmu_stream_id *id, uint32_t num)
{
- uint32_t *scfg = (uint32_t *)CONFIG_SYS_FSL_SCFG_ADDR;
+ void *scfg = (void *)CONFIG_SYS_FSL_SCFG_ADDR;
int i;
for (i = 0; i < num; i++)
- out_be32(scfg + id[i].offset, id[i].stream_id);
+ out_be32((u32 *)(scfg + id[i].offset), id[i].stream_id);
}
void ls1021x_config_caam_stream_id(struct liodn_id_table *tbl, int size)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/3] Fix ICID setup
LS102A ref manual dictates that ICID have to be written to the MSB
of the ICID register, not to the LSB.
Signed-off-by: Vincent Siles
---
Changes in v3:
- Fix another issue with ICID setup: the value is not written at the
correct location (LSB instead of MSB)
Changes in v2:
- Casting to void * instead of u8 *
- Splitted commit into two seperate ones
board/freescale/common/ls102xa_stream_id.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/board/freescale/common/ls102xa_stream_id.c
b/board/freescale/common/ls102xa_stream_id.c
index 3d5404e..0abaffb 100644
--- a/board/freescale/common/ls102xa_stream_id.c
+++ b/board/freescale/common/ls102xa_stream_id.c
@@ -12,9 +12,12 @@ void ls102xa_config_smmu_stream_id(struct smmu_stream_id
*id, uint32_t num)
{
void *scfg = (void *)CONFIG_SYS_FSL_SCFG_ADDR;
int i;
+ u32 icid;
- for (i = 0; i < num; i++)
- out_be32((u32 *)(scfg + id[i].offset), id[i].stream_id);
+ for (i = 0; i < num; i++) {
+ icid = (id[i].stream_id & 0xff) << 24;
+ out_be32((u32 *)(scfg + id[i].offset), icid);
+ }
}
void ls1021x_config_caam_stream_id(struct liodn_id_table *tbl, int size)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/3] arm: uniform usage of u32 in ls102x caam config
Mix usage of uint32_t and u32 fixed in favor of u32 Signed-off-by: Vincent Siles --- Changes in v3: None Changes in v2: None board/freescale/common/ls102xa_stream_id.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/freescale/common/ls102xa_stream_id.c b/board/freescale/common/ls102xa_stream_id.c index 39e7b30..3d5404e 100644 --- a/board/freescale/common/ls102xa_stream_id.c +++ b/board/freescale/common/ls102xa_stream_id.c @@ -28,6 +28,6 @@ void ls1021x_config_caam_stream_id(struct liodn_id_table *tbl, int size) else liodn = tbl[i].id[0]; - out_le32((uint32_t *)(tbl[i].reg_offset), liodn); + out_le32((u32 *)(tbl[i].reg_offset), liodn); } } -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] mkimage: spl address computation seems weird in PBL
The behavior of the global variable "pbl_cmd_initaddr" seems wrong, and prevent to use some address depending on the size of the SPL. This is maybe due to some alignment constraints but I didn't find any documentation that would explain it. The variable is initialized like this: 288 pbl_cmd_initaddr = params->addr & PBL_ADDR_24BIT_MASK; 289 pbl_cmd_initaddr |= PBL_ACS_CONT_CMD; 290 pbl_cmd_initaddr |= uboot_size; Then, during the computation of the addresses of the 64 bytes chunk, it is used like this: 84 next_pbl_cmd = pbl_cmd_initaddr - uboot_size; So basically, if the size of the SPL is using n bits, we can't use the first n bits of the address range. In my particular case, I wanted to copy the SPL at address 0x1000_0a00 and mkimage computed 0x1000_0800 instead. Why is "size" embedded like this in "pbl_cmd_initaddr" when it is a global variable too ? Best, Vincent ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] arm: Fix SCFG ICID reg addresses
On the LS102x boards, in order to initialize the ICID values of masters,
the dev_stream_id array holds absolute offsets from the base of SCFG.
In ls102xa_config_ssmu_stream_id, the base pointer is cast to uint32_t *
before adding the offset, leading to an invalid address. Casting it to
void * solves the issue.
Signed-off-by: Vincent Siles
---
Changes in v2:
- switch from (u8 *) to (void *)
- split modifications in two patches
board/freescale/common/ls102xa_stream_id.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/freescale/common/ls102xa_stream_id.c
b/board/freescale/common/ls102xa_stream_id.c
index f434269..39e7b30 100644
--- a/board/freescale/common/ls102xa_stream_id.c
+++ b/board/freescale/common/ls102xa_stream_id.c
@@ -10,11 +10,11 @@
void ls102xa_config_smmu_stream_id(struct smmu_stream_id *id, uint32_t num)
{
- uint32_t *scfg = (uint32_t *)CONFIG_SYS_FSL_SCFG_ADDR;
+ void *scfg = (void *)CONFIG_SYS_FSL_SCFG_ADDR;
int i;
for (i = 0; i < num; i++)
- out_be32(scfg + id[i].offset, id[i].stream_id);
+ out_be32((u32 *)(scfg + id[i].offset), id[i].stream_id);
}
void ls1021x_config_caam_stream_id(struct liodn_id_table *tbl, int size)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] arm: uniform usage of u32 in ls102x caam config
Mix usage of uint32_t and u32 fixed in favor of u32 Signed-off-by: Vincent Siles --- Changes in v2: - Casting to void * instead of u8 * - Splitted commit into two seperate ones board/freescale/common/ls102xa_stream_id.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/freescale/common/ls102xa_stream_id.c b/board/freescale/common/ls102xa_stream_id.c index 39e7b30..3d5404e 100644 --- a/board/freescale/common/ls102xa_stream_id.c +++ b/board/freescale/common/ls102xa_stream_id.c @@ -28,6 +28,6 @@ void ls1021x_config_caam_stream_id(struct liodn_id_table *tbl, int size) else liodn = tbl[i].id[0]; - out_le32((uint32_t *)(tbl[i].reg_offset), liodn); + out_le32((u32 *)(tbl[i].reg_offset), liodn); } } -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Fix SCFG ICID reg addresses
On 21-04-16 15:45:05, york sun wrote:
>I prefer to use void *.
>
>York
I'm not sure what you mean by "use void *". We need to compute the
address of the registers, so you can't directly use void * as it does not
allow pointer arithmetic. Either you use unsigned char * with full
offset, uint32_t * with offset/sizeof(uint32_t) or the direct mapping
using struct ccsr_scfg * and field access.
Could you elaborate ?
Vincent
>
>Sent from my phone
>
>---- Original Message
>From: Vincent Siles
>Sent: Thursday, April 21, 2016 12:53 AM
>To: york sun
>Subject: Re: [U-Boot] [PATCH] arm: Fix SCFG ICID reg addresses
>CC: u-boot@lists.denx.de,Alison Wang
>
>Hi !
>
>On 20-04-16 09:53:32, York Sun wrote:
>> On 04/12/2016 05:28 AM, Vincent Siles wrote:
>> > On the LS102x boards, in order to initialize the ICID values of
>masters,
>> > the dev_stream_id array holds absolute offsets from the base of SCFG.
>> >
>> > In ls102xa_config_ssmu_stream_id, the base pointer is cast to uint32_t
>*
>> > before adding the offset, leading to an invalid address. Casting it to
>> > unsigned char * solves the issue.
>> >
>> > Also minor cosmetic renaming of uint32_t into u32 to be consistent in
>> > the whole file.
>> >
>> > Signed-off-by: Vincent Siles
>> > ---
>> >
>> > board/freescale/common/ls102xa_stream_id.c | 6 +++---
>> > 1 file changed, 3 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/board/freescale/common/ls102xa_stream_id.c
>b/board/freescale/common/ls102xa_stream_id.c
>> > index f434269..2a4ef3e 100644
>> > --- a/board/freescale/common/ls102xa_stream_id.c
>> > +++ b/board/freescale/common/ls102xa_stream_id.c
>> > @@ -10,11 +10,11 @@
>> >
>> > void ls102xa_config_smmu_stream_id(struct smmu_stream_id *id,
>uint32_t num)
>> > {
>> > - uint32_t *scfg = (uint32_t *)CONFIG_SYS_FSL_SCFG_ADDR;
>> > + unsigned char *scfg = (unsigned char *)CONFIG_SYS_FSL_SCFG_ADDR;
>> > int i;
>> >
>> > for (i = 0; i < num; i++)
>> > - out_be32(scfg + id[i].offset, id[i].stream_id);
>> > + out_be32((u32 *)(scfg + id[i].offset), id[i].stream_id);
>> > }
>> >
>> > void ls1021x_config_caam_stream_id(struct liodn_id_table *tbl, int
>size)
>> > @@ -28,6 +28,6 @@ void ls1021x_config_caam_stream_id(struct
>liodn_id_table *tbl, int size)
>> > else
>> > liodn = tbl[i].id[0];
>> >
>> > - out_le32((uint32_t *)(tbl[i].reg_offset), liodn);
>> > + out_le32((u32 *)(tbl[i].reg_offset), liodn);
>> > }
>> > }
>> >
>>
>> If the size of the pointer is an issue, maybe you ca use "void *"? Can
>you check
>> if "struct ccsr_scfg" should/can be used?
>>
>> York
>
>By using the 'struct ccsr_scfg' type we won't be able to have the same
>kind of loop. Since the code is board dependent, I'm not sure it really
>matters.
>
>Here what I would do instead. Tell me which style do you prefer.
>
>Best,
>Vincent
>
>---
>
>diff --git a/arch/arm/cpu/armv7/ls102xa/soc.c
>b/arch/arm/cpu/armv7/ls102xa/soc.c
>index b1b0c71..9c78efc 100644
>--- a/arch/arm/cpu/armv7/ls102xa/soc.c
>+++ b/arch/arm/cpu/armv7/ls102xa/soc.c
>@@ -30,21 +30,21 @@ struct liodn_id_table sec_liodn_tbl[] = {
>SET_SEC_DECO_LIODN_ENTRY(7, 0x10, 0x10),
>};
>
>-struct smmu_stream_id dev_stream_id[] = {
>- { 0x100, 0x01, "ETSEC MAC1" },
>- { 0x104, 0x02, "ETSEC MAC2" },
>- { 0x108, 0x03, "ETSEC MAC3" },
>- { 0x10c, 0x04, "PEX1" },
>- { 0x110, 0x05, "PEX2" },
>- { 0x114, 0x06, "qDMA" },
>- { 0x118, 0x07, "SATA" },
>- { 0x11c, 0x08, "USB3" },
>- { 0x120, 0x09, "QE" },
>- { 0x124, 0x0a, "eSDHC" },
>- { 0x128, 0x0b, "eMA" },
>- { 0x14c, 0x0c, "2D-ACE" },
>- { 0x150, 0x0d, "USB2" },
>- { 0x18c, 0x0e, "DEBUG" },
>+struct smmu_stream_id dev_stream_id = {
>+ .mac1 = 0x01,
>+ .mac2 = 0x02,
>+ .mac3 = 0x03,
>+ .pex1 = 0x04,
>+ .pex2 = 0x05,
>+ .dma = 0x06
Re: [U-Boot] [PATCH] arm: Fix SCFG ICID reg addresses
Hi !
On 20-04-16 09:53:32, York Sun wrote:
> On 04/12/2016 05:28 AM, Vincent Siles wrote:
> > On the LS102x boards, in order to initialize the ICID values of masters,
> > the dev_stream_id array holds absolute offsets from the base of SCFG.
> >
> > In ls102xa_config_ssmu_stream_id, the base pointer is cast to uint32_t *
> > before adding the offset, leading to an invalid address. Casting it to
> > unsigned char * solves the issue.
> >
> > Also minor cosmetic renaming of uint32_t into u32 to be consistent in
> > the whole file.
> >
> > Signed-off-by: Vincent Siles
> > ---
> >
> > board/freescale/common/ls102xa_stream_id.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/board/freescale/common/ls102xa_stream_id.c
> > b/board/freescale/common/ls102xa_stream_id.c
> > index f434269..2a4ef3e 100644
> > --- a/board/freescale/common/ls102xa_stream_id.c
> > +++ b/board/freescale/common/ls102xa_stream_id.c
> > @@ -10,11 +10,11 @@
> >
> > void ls102xa_config_smmu_stream_id(struct smmu_stream_id *id, uint32_t num)
> > {
> > - uint32_t *scfg = (uint32_t *)CONFIG_SYS_FSL_SCFG_ADDR;
> > + unsigned char *scfg = (unsigned char *)CONFIG_SYS_FSL_SCFG_ADDR;
> > int i;
> >
> > for (i = 0; i < num; i++)
> > - out_be32(scfg + id[i].offset, id[i].stream_id);
> > + out_be32((u32 *)(scfg + id[i].offset), id[i].stream_id);
> > }
> >
> > void ls1021x_config_caam_stream_id(struct liodn_id_table *tbl, int size)
> > @@ -28,6 +28,6 @@ void ls1021x_config_caam_stream_id(struct liodn_id_table
> > *tbl, int size)
> > else
> > liodn = tbl[i].id[0];
> >
> > - out_le32((uint32_t *)(tbl[i].reg_offset), liodn);
> > + out_le32((u32 *)(tbl[i].reg_offset), liodn);
> > }
> > }
> >
>
> If the size of the pointer is an issue, maybe you ca use "void *"? Can you
> check
> if "struct ccsr_scfg" should/can be used?
>
> York
By using the 'struct ccsr_scfg' type we won't be able to have the same
kind of loop. Since the code is board dependent, I'm not sure it really
matters.
Here what I would do instead. Tell me which style do you prefer.
Best,
Vincent
---
diff --git a/arch/arm/cpu/armv7/ls102xa/soc.c b/arch/arm/cpu/armv7/ls102xa/soc.c
index b1b0c71..9c78efc 100644
--- a/arch/arm/cpu/armv7/ls102xa/soc.c
+++ b/arch/arm/cpu/armv7/ls102xa/soc.c
@@ -30,21 +30,21 @@ struct liodn_id_table sec_liodn_tbl[] = {
SET_SEC_DECO_LIODN_ENTRY(7, 0x10, 0x10),
};
-struct smmu_stream_id dev_stream_id[] = {
- { 0x100, 0x01, "ETSEC MAC1" },
- { 0x104, 0x02, "ETSEC MAC2" },
- { 0x108, 0x03, "ETSEC MAC3" },
- { 0x10c, 0x04, "PEX1" },
- { 0x110, 0x05, "PEX2" },
- { 0x114, 0x06, "qDMA" },
- { 0x118, 0x07, "SATA" },
- { 0x11c, 0x08, "USB3" },
- { 0x120, 0x09, "QE" },
- { 0x124, 0x0a, "eSDHC" },
- { 0x128, 0x0b, "eMA" },
- { 0x14c, 0x0c, "2D-ACE" },
- { 0x150, 0x0d, "USB2" },
- { 0x18c, 0x0e, "DEBUG" },
+struct smmu_stream_id dev_stream_id = {
+ .mac1 = 0x01,
+ .mac2 = 0x02,
+ .mac3 = 0x03,
+ .pex1 = 0x04,
+ .pex2 = 0x05,
+ .dma = 0x06,
+ .sata = 0x07,
+ .usb3 = 0x08,
+ .qe = 0x09,
+ .sdhc = 0x0a,
+ .adma = 0x0b,
+ .dcu = 0x0c,
+ .usb2 = 0x0d,
+ .debug = 0x0e
};
unsigned int get_soc_major_rev(void)
@@ -131,8 +131,7 @@ int ls102xa_smmu_stream_id_init(void)
ls1021x_config_caam_stream_id(sec_liodn_tbl,
ARRAY_SIZE(sec_liodn_tbl));
- ls102xa_config_smmu_stream_id(dev_stream_id,
- ARRAY_SIZE(dev_stream_id));
+ ls102xa_config_smmu_stream_id(&dev_stream_id);
return 0;
}
diff --git a/arch/arm/include/asm/arch-ls102xa/ls102xa_stream_id.h
b/arch/arm/include/asm/arch-ls102xa/ls102xa_stream_id.h
index fa571b3..3815673 100644
--- a/arch/arm/include/asm/arch-ls102xa/ls102xa_stream_id.h
+++ b/arch/arm/include/asm/arch-ls102xa/ls102xa_stream_id.h
@@ -64,11 +64,22 @@ struct liodn_id_table {
};
struct smmu_stream_id {
- uint16_t offset;
- uint16_t stream_id;
- char dev_name[32];
+ uint16_t mac1;
+ uint16_t mac2;
+ uint16_t mac3;
+ uint16_t pex1;
+ uint16_t pex2;
+ uint16_t dma;
+ uint16_t sata;
+ uint16_t usb3;
+ uint16_t qe;
+ uint16_t sdhc;
+ uint16_t adma;
+ uint16_t dcu;
+ u
[U-Boot] [PATCH 0/1]
In order to activate the TZASC for the LS1021a board, one need to
correctly configure the SMMU, by setting ICID for each peripherals in
the SCFG ICID registers. The computation of the addresses of such
registers is invalid due to wrong pointer arithmetic.
Also please note that there is no mention of the following entry in the
Reference manual of the LS1021A board.
arch/arm/cpu/armv7/ls102xa/soc.c:138
struct smmu_stream_id dev_stream_id[] = {
...
{ 0x114, 0x06, "qDMA" },
...
Vincent Siles (1):
arm: Fix SCFG ICID reg addresses
board/freescale/common/ls102xa_stream_id.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: Fix SCFG ICID reg addresses
On the LS102x boards, in order to initialize the ICID values of masters,
the dev_stream_id array holds absolute offsets from the base of SCFG.
In ls102xa_config_ssmu_stream_id, the base pointer is cast to uint32_t *
before adding the offset, leading to an invalid address. Casting it to
unsigned char * solves the issue.
Also minor cosmetic renaming of uint32_t into u32 to be consistent in
the whole file.
Signed-off-by: Vincent Siles
---
board/freescale/common/ls102xa_stream_id.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/board/freescale/common/ls102xa_stream_id.c
b/board/freescale/common/ls102xa_stream_id.c
index f434269..2a4ef3e 100644
--- a/board/freescale/common/ls102xa_stream_id.c
+++ b/board/freescale/common/ls102xa_stream_id.c
@@ -10,11 +10,11 @@
void ls102xa_config_smmu_stream_id(struct smmu_stream_id *id, uint32_t num)
{
- uint32_t *scfg = (uint32_t *)CONFIG_SYS_FSL_SCFG_ADDR;
+ unsigned char *scfg = (unsigned char *)CONFIG_SYS_FSL_SCFG_ADDR;
int i;
for (i = 0; i < num; i++)
- out_be32(scfg + id[i].offset, id[i].stream_id);
+ out_be32((u32 *)(scfg + id[i].offset), id[i].stream_id);
}
void ls1021x_config_caam_stream_id(struct liodn_id_table *tbl, int size)
@@ -28,6 +28,6 @@ void ls1021x_config_caam_stream_id(struct liodn_id_table
*tbl, int size)
else
liodn = tbl[i].id[0];
- out_le32((uint32_t *)(tbl[i].reg_offset), liodn);
+ out_le32((u32 *)(tbl[i].reg_offset), liodn);
}
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issue with ALLOC_CACHE_ALIGN_BUFFER in env_relocate_spec and
Hi, In the end, it seems that the issue is neither MMC nor Normal/Secure world related, but cache related. Between SPL and u-boot, I run a small piece of secure software, which turns on the ACTLR.SMP bit. According to cortex a7 TRM, this is mandatory to enable caching. Setting the MMU is not enough. With ACTLR.SMP bit set to 1, I get strange behavior in several places in u-boot (I can witness CAAM & MMC at least). Could it be that u-boot was running without cache on cortex-a7 and activating this bit made cache related issues arise ? Best, Vincent 2016-03-25 18:33 GMT+01:00 Vincent : > Hi, > I am having some issue with several instances of > ALLOC_CACHE_ALIGN_BUFFER in (at least): > - common/env_mmc: env_relocate_spec > - disk/part_dos: test_part_dos > > U-boot (ls1021atwr) is build in SPL mode, SPL part is in Secure World, > u-boot is in Normal World. > In the SPL part, there is no problem, MMC access are fine. In the > normal world, I experience what I think is stack corruption: > > At these locations, calls to the MMC to read partition info mostly > read 0 or garbages. Garbage looks like stack overflow/corruption. For > example, in the first function, checking the CRC of u-boot's env > stored in the MMC fails because the buffer is correct until the last > kb where there is values instead of zeroes, which looks like RAM > addresses and data. > > I tried several fix, but I still don't understand what's happening: > - I tried to allocate the buffer where MMC data is read into the head > -> it works fine > - I tried to allocate more room to these buffer on the stack -> > sometimes it works, but not always. > > Maybe it's my compiler (NXP's SDK 1.9, based on yocto) which is buggy, > I don't know. > I can provide some custom dump of memory if necessary, but the buffers > at these locations are quite huge I'm afraid. > > Best regards, > Vincent ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: Fix order of CSU indexes in ns_access.h
This patch aims to fix the order of CSU slave index for the LS1021a
board.
Signed-off-by: Vincent Siles
---
arch/arm/include/asm/arch-ls102xa/ns_access.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-ls102xa/ns_access.h
b/arch/arm/include/asm/arch-ls102xa/ns_access.h
index a921fb6..44acfd2 100644
--- a/arch/arm/include/asm/arch-ls102xa/ns_access.h
+++ b/arch/arm/include/asm/arch-ls102xa/ns_access.h
@@ -82,12 +82,12 @@ enum csu_cslx_ind {
CSU_CSLX_FTM5,
CSU_CSLX_FTM8,
CSU_CSLX_FTM7,
- CSU_CSLX_COP_DCSR,
CSU_CSLX_EPU,
- CSU_CSLX_GDI,
+ CSU_CSLX_COP_DCSR,
CSU_CSLX_DDI,
+ CSU_CSLX_GDI,
CSU_CSLX_RESERVED1,
- CSU_CSLX_USB3_PHY = 117,
+ CSU_CSLX_USB3_PHY = 116,
CSU_CSLX_RESERVED2,
CSU_CSLX_MAX,
};
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/1] ls102xa: Indexes of CSU slave is incorrect
In [1], we can see that the order of CSU slave indexes is a bit scrambled at the end. The ns_access.h file does not represent this ordering correctly. This patch aims to fix that. [1]: http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/qoriq-arm-processors/qoriq-ls1021a-dual-core-communications-processor-with-lcd-controller:LS1021A?fpsp=1&tab=Documentation_Tab Vincent Siles (1): arm: Fix order of CSU indexes in ns_access.h arch/arm/include/asm/arch-ls102xa/ns_access.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Issue with ALLOC_CACHE_ALIGN_BUFFER in env_relocate_spec and
Hi, I am having some issue with several instances of ALLOC_CACHE_ALIGN_BUFFER in (at least): - common/env_mmc: env_relocate_spec - disk/part_dos: test_part_dos U-boot (ls1021atwr) is build in SPL mode, SPL part is in Secure World, u-boot is in Normal World. In the SPL part, there is no problem, MMC access are fine. In the normal world, I experience what I think is stack corruption: At these locations, calls to the MMC to read partition info mostly read 0 or garbages. Garbage looks like stack overflow/corruption. For example, in the first function, checking the CRC of u-boot's env stored in the MMC fails because the buffer is correct until the last kb where there is values instead of zeroes, which looks like RAM addresses and data. I tried several fix, but I still don't understand what's happening: - I tried to allocate the buffer where MMC data is read into the head -> it works fine - I tried to allocate more room to these buffer on the stack -> sometimes it works, but not always. Maybe it's my compiler (NXP's SDK 1.9, based on yocto) which is buggy, I don't know. I can provide some custom dump of memory if necessary, but the buffers at these locations are quite huge I'm afraid. Best regards, Vincent ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Possible mistake in the csu_cslx_ind enum (ns_access.h)
Hi, I started to port my kernel to the secure world on a LS1021a board, so I started to read the reference manual on the CSU component. In Table 9.8, we can see that - Debug EPU is CSL47[24:16] - DDDI is CSL48[24:16] - Debug GDI is CSL48[8:0] but in ns_access.h the order doesn't seem to fit. If I understand correctly: - CSU_CSLX_EPU and CSU_CSLX_COP_DCSR should be exchanged - CSU_CSLX_DDI and CSU_CSLX_GDI should be exchanged - CSU_CSLX_USB3_PHY should be = 116, not 117 I don't have any Errata yet, and I might be wrong, so I'd rather have a confirmation. By the way, there are a lot of 'Reserved' entry that have a name (like CSU_CSLX_GIC for example), am I lacking some information ? Best regards, Vincent ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Building SPL version of u-boot (imx6 Sabre Lite)
Hi, I am currently experimenting with Trustzone on Freescale boards, having Android/Linux in the normal world (NW) and a custom baremetal mini-os in the secure world (SW). My first board was a sabre imx6Q-SDP [1]. In order to boot both OS, we used the mx6sabresd_spl_defconfig configuration (with a few patches to support our system) so the SPL (in Secure mode) loads u-boot/Linux and our OS in memory, gives control to our OS, which at some point makes a switch to NW and start the second u-boot (which will start Linux). I am now trying to port our work to another imx6 board [2] based on a imx6Q-lite, using Boundary Devices clone of u-boot [3]. In this setting, u-boot starts a Linux in the SW. I made a few attempts at patching u-boot to start Linux in NW, but I failed. Since neither in the mainline u-boot nor their patched version provides a "SPL" configuration for the sabre lite, I am looking for a way to build it myself. Is there a roadmap to build a "SPL" configuration from a "normal" configuration in u-boot ? Or is there a way to configure u-boot so that Linux is started in the NW instead of the SW ? Best regards, Vincent [1]: http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/i.mx-applications-processors-based-on-arm-cores/i.mx-6-processors/i.mx6qp/sabre-platform-for-smart-devices-reference-design-based-on-the-i.mx-6-series:RDIMX6SABREPLAT [2]: https://boundarydevices.com/product/sabre-lite-imx6-sbc/ [3]: https://github.com/boundarydevices/u-boot-imx6 nitrogen6q_defconfig ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
