Re: [RFC PATCH v2 6/8] FWU: Add boot time checks as highlighted by the FWU specification
hi Takahiro,
On Mon, 20 Dec 2021 at 11:39, AKASHI Takahiro
wrote:
> Sughosh,
>
> On Sun, Dec 19, 2021 at 12:36:03PM +0530, Sughosh Ganu wrote:
> > The FWU Multi Bank Update specification requires the Update Agent to
> > carry out certain checks at the time of platform boot. The Update
> > Agent is the component which is responsible for updating the firmware
> > components and maintaining and keeping the metadata in sync.
> >
> > The spec requires that the Update Agent perform the following checks
> > at the time of boot
> > * Sanity check of both the metadata copies maintained by the platform.
> > * Get the boot index passed to U-Boot by the prior stage bootloader
> > and use this value for metadata bookkeeping.
> > * Check if the system is booting in Trial State. If the system boots
> > in the Trial State for more than a specified number of boot counts,
> > change the Active Bank to be booting the platform from.
> >
> > Add these checks in the board initialisation sequence, invoked after
> > relocation.
> >
> > Signed-off-by: Sughosh Ganu
> > ---
> > Changes since V1:
> > * Define a funtion fwu_update_checks_pass to do the checks
> > before initiating the update
> > * Log the status of the boottime checks using boottime_check
> > variable and allow system to boot instead of hanging the
> > platform(fwu_boottime_checks)
> >
> > common/board_r.c | 6 ++
> > include/fwu.h | 3 +
> > lib/fwu_updates/fwu.c | 163 ++
> > 3 files changed, 172 insertions(+)
> > create mode 100644 lib/fwu_updates/fwu.c
> >
> > diff --git a/common/board_r.c b/common/board_r.c
> > index 31a59c585a..81678870b9 100644
> > --- a/common/board_r.c
> > +++ b/common/board_r.c
> > @@ -78,6 +78,9 @@
> > #ifdef CONFIG_EFI_SETUP_EARLY
> > #include
> > #endif
> > +#ifdef CONFIG_FWU_MULTI_BANK_UPDATE
> > +#include
> > +#endif
> >
> > DECLARE_GLOBAL_DATA_PTR;
> >
> > @@ -805,6 +808,9 @@ static init_fnc_t init_sequence_r[] = {
> > #endif
> > #ifdef CONFIG_EFI_SETUP_EARLY
> > (init_fnc_t)efi_init_obj_list,
> > +#endif
> > +#ifdef CONFIG_FWU_MULTI_BANK_UPDATE
> > + fwu_boottime_checks,
> > #endif
>
> Maybe I don't understand your code well.
> Why do you want to call fwu_boottime_checks() here?
> Why not in CONFIG_EFI_CAPSULE_UPDATE_EARLY (i.e. efi_launch_capsules()
> in main_loop())?
>
These are boot time checks which are to be carried out during platform
boot. Do you see any issue if we place the call to fwu_boottime_checks in
the init_sequence. I would like to avoid having the fwu boot time checks
tied up with CONFIG_EFI_CAPSULE_ON_DISK_EARLY.
-sughosh
>
> -Takahiro Akashi
>
> > run_main_loop,
> > };
> > diff --git a/include/fwu.h b/include/fwu.h
> > index 5ba437798d..2d2e674d6a 100644
> > --- a/include/fwu.h
> > +++ b/include/fwu.h
> > @@ -16,6 +16,9 @@
> > EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \
> >0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23)
> >
> > +int fwu_boottime_checks(void);
> > +u8 fwu_update_checks_pass(void);
> > +
> > int fwu_get_active_index(u32 *active_idx);
> > int fwu_update_active_index(u32 active_idx);
> > int fwu_get_image_alt_num(efi_guid_t image_type_id, u32 update_bank,
> > diff --git a/lib/fwu_updates/fwu.c b/lib/fwu_updates/fwu.c
> > new file mode 100644
> > index 00..e964f9b0b1
> > --- /dev/null
> > +++ b/lib/fwu_updates/fwu.c
> > @@ -0,0 +1,163 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (c) 2021, Linaro Limited
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +
> > +static u8 trial_state = 0;
> > +static u8 boottime_check = 0;
> > +
> > +static int fwu_trial_state_check(void)
> > +{
> > + int ret, i;
> > + efi_status_t status;
> > + efi_uintn_t var_size;
> > + u16 trial_state_ctr;
> > + u32 nimages, active_bank, var_attributes, active_idx;
> > + struct fwu_mdata *mdata = NULL;
> > + struct fwu_image_entry *img_entry;
> > + struct fwu_image_bank_info *img_bank_info;
> > +
> > + ret = fwu_get_mdata();
> > + if (ret < 0)
> > + return ret;
> > +
> > + ret = 0;
> > + nimages = CONFIG_FWU_NUM_IMAGES_PER_BANK;
> > + active_bank = mdata->active_index;
> > + img_entry = >img_entry[0];
> > + for (i = 0; i < nimages; i++) {
> > + img_bank_info = _entry[i].img_bank_info[active_bank];
> > + if (!img_bank_info->accepted) {
> > + trial_state = 1;
> > + break;
> > + }
> > + }
> > +
> > + if (trial_state) {
> > + var_size = (efi_uintn_t)sizeof(trial_state_ctr);
> > + log_info("System booting in Trial State\n");
> > + var_attributes = EFI_VARIABLE_NON_VOLATILE |
> > + EFI_VARIABLE_BOOTSERVICE_ACCESS |
> > + EFI_VARIABLE_RUNTIME_ACCESS;
> > +
Re: [RFC PATCH v2 7/8] FWU: Add support for FWU Multi Bank Update feature
Hi Sughosh, 2021年12月20日(月) 18:48 Sughosh Ganu : > > > On Mon, 20 Dec 2021 at 11:44, AKASHI Takahiro > wrote: >> >> On Sun, Dec 19, 2021 at 12:36:04PM +0530, Sughosh Ganu wrote: >> > The FWU Multi Bank Update feature supports updation of firmware images >> > to one of multiple sets(also called banks) of images. The firmware >> > images are clubbed together in banks, with the system booting images >> > from the active bank. Information on the images such as which bank >> > they belong to is stored as part of the metadata structure, which is >> > stored on the same storage media as the firmware images on a dedicated >> > partition. >> > >> > At the time of update, the metadata is read to identify the bank to >> > which the images need to be flashed(update bank). On a successful >> > update, the metadata is modified to set the updated bank as active >> > bank to subsequently boot from. >> > >> > Signed-off-by: Sughosh Ganu >> > --- >> > Changes since V1: >> > * Call function fwu_update_checks_pass to check if the >> > update can be initiated >> > * Do not allow firmware update from efi_init_obj_list as the >> > fwu boot-time checks need to be run >> > >> > include/fwu.h| 18 +++- >> > lib/Kconfig | 32 ++ >> > lib/Makefile | 1 + >> > lib/efi_loader/efi_capsule.c | 198 ++- >> > lib/efi_loader/efi_setup.c | 3 +- >> > lib/fwu_updates/Makefile | 11 ++ >> > lib/fwu_updates/fwu.c| 27 + >> > 7 files changed, 284 insertions(+), 6 deletions(-) >> > create mode 100644 lib/fwu_updates/Makefile >> > >> > diff --git a/include/fwu.h b/include/fwu.h >> > index 2d2e674d6a..bf50fe9277 100644 >> > --- a/include/fwu.h >> > +++ b/include/fwu.h >> > @@ -10,14 +10,28 @@ >> > >> > #include >> > >> > -#define FWU_MDATA_VERSION0x1 >> > +#define FWU_MDATA_GUID \ >> > + EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \ >> > + 0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23) >> > + >> > +#define FWU_OS_REQUEST_FW_REVERT_GUID \ >> > + EFI_GUID(0xacd58b4b, 0xc0e8, 0x475f, 0x99, 0xb5, \ >> > + 0x6b, 0x3f, 0x7e, 0x07, 0xaa, 0xf0) >> > + >> > +#define FWU_OS_REQUEST_FW_ACCEPT_GUID \ >> > + EFI_GUID(0x0c996046, 0xbcc0, 0x4d04, 0x85, 0xec, \ >> > + 0xe1, 0xfc, 0xed, 0xf1, 0xc6, 0xf8) >> > >> > #define FWU_MDATA_GUID \ >> > EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \ >> >0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23) >> > >> > -int fwu_boottime_checks(void); >> > +#define FWU_MDATA_VERSION0x1 >> > +#define FWU_IMAGE_ACCEPTED 0x1 >> > + >> > u8 fwu_update_checks_pass(void); >> > +int fwu_boottime_checks(void); >> > +int fwu_trial_state_ctr_start(void); >> > >> > int fwu_get_active_index(u32 *active_idx); >> > int fwu_update_active_index(u32 active_idx); >> > diff --git a/lib/Kconfig b/lib/Kconfig >> > index 807a4c6ade..7cb306317c 100644 >> > --- a/lib/Kconfig >> > +++ b/lib/Kconfig >> > @@ -835,3 +835,35 @@ config PHANDLE_CHECK_SEQ >> > When there are multiple device tree nodes with same name, >> >enable this config option to distinguish them using >> > phandles in fdtdec_get_alias_seq() function. >> > + >> > +config FWU_MULTI_BANK_UPDATE >> > + bool "Enable FWU Multi Bank Update Feature" >> > + depends on EFI_HAVE_CAPSULE_SUPPORT >> > + select PARTITION_TYPE_GUID >> > + select EFI_SETUP_EARLY >> > + help >> > + Feature for updating firmware images on platforms having >> > + multiple banks(copies) of the firmware images. One of the >> > + bank is selected for updating all the firmware components >> > + >> > +config FWU_NUM_BANKS >> > + int "Number of Banks defined by the platform" >> > + depends on FWU_MULTI_BANK_UPDATE >> > + help >> > + Define the number of banks of firmware images on a platform >> > + >> > +config FWU_NUM_IMAGES_PER_BANK >> > + int "Number of firmware images per bank" >> > + depends on FWU_MULTI_BANK_UPDATE >> > + help >> > + Define the number of firmware images per bank. This value >> > + should be the same for all the banks. >> > + >> > +config FWU_TRIAL_STATE_CNT >> > + int "Number of times system boots in Trial State" >> > + depends on FWU_MULTI_BANK_UPDATE >> > + default 3 >> > + help >> > + With FWU Multi Bank Update feature enabled, number of times >> > + the platform is allowed to boot in Trial State after an >> > + update. >> > diff --git a/lib/Makefile b/lib/Makefile >> > index 5ddbc77ed6..bc5c1e22fc 100644 >> > --- a/lib/Makefile >> > +++ b/lib/Makefile >> > @@ -9,6 +9,7 @@ obj-$(CONFIG_EFI) += efi/ >> > obj-$(CONFIG_EFI_LOADER) += efi_driver/ >> > obj-$(CONFIG_EFI_LOADER) += efi_loader/ >> > obj-$(CONFIG_CMD_BOOTEFI_SELFTEST) += efi_selftest/ >> > +obj-$(CONFIG_FWU_MULTI_BANK_UPDATE) += fwu_updates/ >> > obj-$(CONFIG_LZMA) += lzma/ >> > obj-$(CONFIG_BZIP2) += bzip2/ >> >
Re: [RFC PATCH v2 6/8] FWU: Add boot time checks as highlighted by the FWU specification
Hi Sughosh,
On Mon, Dec 20, 2021 at 03:36:37PM +0530, Sughosh Ganu wrote:
> hi Takahiro,
>
> On Mon, 20 Dec 2021 at 11:39, AKASHI Takahiro
> wrote:
>
> > Sughosh,
> >
> > On Sun, Dec 19, 2021 at 12:36:03PM +0530, Sughosh Ganu wrote:
> > > The FWU Multi Bank Update specification requires the Update Agent to
> > > carry out certain checks at the time of platform boot. The Update
> > > Agent is the component which is responsible for updating the firmware
> > > components and maintaining and keeping the metadata in sync.
> > >
> > > The spec requires that the Update Agent perform the following checks
> > > at the time of boot
> > > * Sanity check of both the metadata copies maintained by the platform.
> > > * Get the boot index passed to U-Boot by the prior stage bootloader
> > > and use this value for metadata bookkeeping.
> > > * Check if the system is booting in Trial State. If the system boots
> > > in the Trial State for more than a specified number of boot counts,
> > > change the Active Bank to be booting the platform from.
> > >
> > > Add these checks in the board initialisation sequence, invoked after
> > > relocation.
> > >
> > > Signed-off-by: Sughosh Ganu
> > > ---
> > > Changes since V1:
> > > * Define a funtion fwu_update_checks_pass to do the checks
> > > before initiating the update
> > > * Log the status of the boottime checks using boottime_check
> > > variable and allow system to boot instead of hanging the
> > > platform(fwu_boottime_checks)
> > >
> > > common/board_r.c | 6 ++
> > > include/fwu.h | 3 +
> > > lib/fwu_updates/fwu.c | 163 ++
> > > 3 files changed, 172 insertions(+)
> > > create mode 100644 lib/fwu_updates/fwu.c
> > >
> > > diff --git a/common/board_r.c b/common/board_r.c
> > > index 31a59c585a..81678870b9 100644
> > > --- a/common/board_r.c
> > > +++ b/common/board_r.c
> > > @@ -78,6 +78,9 @@
> > > #ifdef CONFIG_EFI_SETUP_EARLY
> > > #include
> > > #endif
> > > +#ifdef CONFIG_FWU_MULTI_BANK_UPDATE
> > > +#include
> > > +#endif
> > >
> > > DECLARE_GLOBAL_DATA_PTR;
> > >
> > > @@ -805,6 +808,9 @@ static init_fnc_t init_sequence_r[] = {
> > > #endif
> > > #ifdef CONFIG_EFI_SETUP_EARLY
> > > (init_fnc_t)efi_init_obj_list,
> > > +#endif
> > > +#ifdef CONFIG_FWU_MULTI_BANK_UPDATE
> > > + fwu_boottime_checks,
> > > #endif
> >
> > Maybe I don't understand your code well.
> > Why do you want to call fwu_boottime_checks() here?
> > Why not in CONFIG_EFI_CAPSULE_UPDATE_EARLY (i.e. efi_launch_capsules()
> > in main_loop())?
> >
>
> These are boot time checks which are to be carried out during platform
> boot. Do you see any issue if we place the call to fwu_boottime_checks in
> the init_sequence.
No, I don't see any specific issue right now.
> I would like to avoid having the fwu boot time checks
> tied up with CONFIG_EFI_CAPSULE_ON_DISK_EARLY.
My question was why you want to avoid that.
In main_loop(), update_tftp(), as well as efi capsule code, is put there.
It would be a good practice to have similar functionality called in one place.
-Takahiro Akashi
> -sughosh
>
>
> >
> > -Takahiro Akashi
> >
> > > run_main_loop,
> > > };
> > > diff --git a/include/fwu.h b/include/fwu.h
> > > index 5ba437798d..2d2e674d6a 100644
> > > --- a/include/fwu.h
> > > +++ b/include/fwu.h
> > > @@ -16,6 +16,9 @@
> > > EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \
> > >0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23)
> > >
> > > +int fwu_boottime_checks(void);
> > > +u8 fwu_update_checks_pass(void);
> > > +
> > > int fwu_get_active_index(u32 *active_idx);
> > > int fwu_update_active_index(u32 active_idx);
> > > int fwu_get_image_alt_num(efi_guid_t image_type_id, u32 update_bank,
> > > diff --git a/lib/fwu_updates/fwu.c b/lib/fwu_updates/fwu.c
> > > new file mode 100644
> > > index 00..e964f9b0b1
> > > --- /dev/null
> > > +++ b/lib/fwu_updates/fwu.c
> > > @@ -0,0 +1,163 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * Copyright (c) 2021, Linaro Limited
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#include
> > > +#include
> > > +
> > > +static u8 trial_state = 0;
> > > +static u8 boottime_check = 0;
> > > +
> > > +static int fwu_trial_state_check(void)
> > > +{
> > > + int ret, i;
> > > + efi_status_t status;
> > > + efi_uintn_t var_size;
> > > + u16 trial_state_ctr;
> > > + u32 nimages, active_bank, var_attributes, active_idx;
> > > + struct fwu_mdata *mdata = NULL;
> > > + struct fwu_image_entry *img_entry;
> > > + struct fwu_image_bank_info *img_bank_info;
> > > +
> > > + ret = fwu_get_mdata();
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + ret = 0;
> > > + nimages = CONFIG_FWU_NUM_IMAGES_PER_BANK;
> > > + active_bank = mdata->active_index;
> > > + img_entry = >img_entry[0];
> > > +
Re: [PATCH v7 01/24] efi: Locate all block devices in the app
On 12/18/21 19:28, Simon Glass wrote:
When starting the app, locate all block devices and make them available
to U-Boot. This allows listing partitions and accessing files in
filesystems.
EFI also has the concept of 'disks', meaning boot media. For now, this
is not obviously useful in U-Boot, but add code to at least locate these.
This can be expanded later as needed.
Signed-off-by: Simon Glass
---
(no changes since v6)
Changes in v6:
- Add comment for dm_scan_other()
- Add comment for free_memory()
- Drop setup_disks() as U-Boot does not support it
- Fix 'have have' typo
- Update comment format for devpath_is_partition()
Changes in v2:
- Don't export efi_bind_block()
- Only bind devices for media devices, not for partitions
- Show devices that are processed
- Store device path in struct efi_media_plat
- Update documentation
doc/develop/uefi/u-boot_on_efi.rst | 4 +-
include/efi.h | 6 +-
include/efi_api.h | 15 ++
lib/efi/efi_app.c | 216 +
4 files changed, 236 insertions(+), 5 deletions(-)
diff --git a/doc/develop/uefi/u-boot_on_efi.rst
b/doc/develop/uefi/u-boot_on_efi.rst
index 5f2f850f071..8f81b799072 100644
--- a/doc/develop/uefi/u-boot_on_efi.rst
+++ b/doc/develop/uefi/u-boot_on_efi.rst
@@ -265,9 +265,7 @@ This work could be extended in a number of ways:
- Figure out how to solve the interrupt problem
-- Add more drivers to the application side (e.g. block devices, USB,
- environment access). This would mostly be an academic exercise as a strong
- use case is not readily apparent, but it might be fun.
+- Add more drivers to the application side (e.g.USB, environment access).
- Avoid turning off boot services in the stub. Instead allow U-Boot to make
use of boot services in case it wants to. It is unclear what it might want
diff --git a/include/efi.h b/include/efi.h
index 0ec5913ddd1..908c5dc6ebd 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -419,10 +419,12 @@ struct efi_priv {
*
* @handle: handle of the controller on which this driver is installed
* @blkio: block io protocol proxied by this driver
+ * @device_path: EFI path to the device
*/
struct efi_media_plat {
- efi_handle_thandle;
- struct efi_block_io *blkio;
+ efi_handle_t handle;
+ struct efi_block_io *blkio;
+ struct efi_device_path *device_path;
};
/* Base address of the EFI image */
diff --git a/include/efi_api.h b/include/efi_api.h
index 80109f012bc..ec9fa89a935 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -2035,4 +2035,19 @@ struct efi_firmware_management_protocol {
const u16 *package_version_name);
};
+#define EFI_DISK_IO_PROTOCOL_GUID \
+ EFI_GUID(0xce345171, 0xba0b, 0x11d2, 0x8e, 0x4f, \
+0x00, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
+
+struct efi_disk {
+ u64 revision;
+ efi_status_t (EFIAPI *read_disk)(struct efi_disk *this, u32 media_id,
+u64 offset, efi_uintn_t buffer_size,
+void *buffer);
+
+ efi_status_t (EFIAPI *write_disk)(struct efi_disk *this, u32 media_id,
+ u64 offset, efi_uintn_t buffer_size,
+ void *buffer);
+};
+
#endif
diff --git a/lib/efi/efi_app.c b/lib/efi/efi_app.c
index f61665686c5..6a71cef7acb 100644
--- a/lib/efi/efi_app.c
+++ b/lib/efi/efi_app.c
@@ -21,6 +21,9 @@
#include
#include
#include
+#include
+#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -46,6 +49,64 @@ int efi_info_get(enum efi_entry_t type, void **datap, int
*sizep)
return -ENOSYS;
}
+/**
+ * efi_print_str() - Print a UFT-16 string to the U-Boot console
+ *
+ * @str: String to print
+ */
+static void efi_print_str(const u16 *str)
+{
+ while (*str) {
+ int ch = *str++;
+
+ if (ch > ' ' && ch < 127)
+ putc(ch);
This will lead to awkward results.
We don't need this function. Please, use printf("%ls", str) instead.
+ }
+}
+
+/**
+ * efi_bind_block() - bind a new block device to an EFI device
+ *
+ * Binds a new top-level EFI_MEDIA device as well as a child block device so
+ * that the block device can be accessed in U-Boot.
+ *
+ * The device can then be accessed using 'part list efi 0', 'fat ls efi 0:1',
+ * for example, just like any other interface type.
+ *
+ * @handle: handle of the controller on which this driver is installed
+ * @blkio: block io protocol proxied by this driver
+ * @device_path: EFI device path structure for this
+ * @len: Length of @device_path in bytes
+ * @devp: Returns the bound device
+ * @return 0 if OK, -ve on error
+ */
+int efi_bind_block(efi_handle_t handle, struct efi_block_io *blkio,
+ struct efi_device_path *device_path, int len,
+ struct udevice **devp)
+{
+ struct
Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hi Sahil, Am 2021-12-10 07:33, schrieb Sahil Malhotra (OSS): DT nodes can be statically disabled if we know that they are held by HAB and are not released to NS World. OP-TEE does set the status itself via dt_enable_secure_status(), which should present the properly configured FDT when U-Boot takes over. Yes, OP-TEE set the status by dt_enable_secure_status() in DTB overlay which gets merged with DTB provided for Linux bootup and then Linux boots with merged DTB. But u-boot uses the DTB embedded in its image. How can we modify that DTB or merge DTB overlay passed by OP-TEE with uboot DTB ? But then u-boot has the "wrong" dtb. What is the reason, there is an overlay instead of a whole dtb? what if the overlay doesn't match the dtb? -michael
Re: [RFC PATCH v2 7/8] FWU: Add support for FWU Multi Bank Update feature
On Mon, 20 Dec 2021 at 11:44, AKASHI Takahiro wrote: > On Sun, Dec 19, 2021 at 12:36:04PM +0530, Sughosh Ganu wrote: > > The FWU Multi Bank Update feature supports updation of firmware images > > to one of multiple sets(also called banks) of images. The firmware > > images are clubbed together in banks, with the system booting images > > from the active bank. Information on the images such as which bank > > they belong to is stored as part of the metadata structure, which is > > stored on the same storage media as the firmware images on a dedicated > > partition. > > > > At the time of update, the metadata is read to identify the bank to > > which the images need to be flashed(update bank). On a successful > > update, the metadata is modified to set the updated bank as active > > bank to subsequently boot from. > > > > Signed-off-by: Sughosh Ganu > > --- > > Changes since V1: > > * Call function fwu_update_checks_pass to check if the > > update can be initiated > > * Do not allow firmware update from efi_init_obj_list as the > > fwu boot-time checks need to be run > > > > include/fwu.h| 18 +++- > > lib/Kconfig | 32 ++ > > lib/Makefile | 1 + > > lib/efi_loader/efi_capsule.c | 198 ++- > > lib/efi_loader/efi_setup.c | 3 +- > > lib/fwu_updates/Makefile | 11 ++ > > lib/fwu_updates/fwu.c| 27 + > > 7 files changed, 284 insertions(+), 6 deletions(-) > > create mode 100644 lib/fwu_updates/Makefile > > > > diff --git a/include/fwu.h b/include/fwu.h > > index 2d2e674d6a..bf50fe9277 100644 > > --- a/include/fwu.h > > +++ b/include/fwu.h > > @@ -10,14 +10,28 @@ > > > > #include > > > > -#define FWU_MDATA_VERSION0x1 > > +#define FWU_MDATA_GUID \ > > + EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \ > > + 0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23) > > + > > +#define FWU_OS_REQUEST_FW_REVERT_GUID \ > > + EFI_GUID(0xacd58b4b, 0xc0e8, 0x475f, 0x99, 0xb5, \ > > + 0x6b, 0x3f, 0x7e, 0x07, 0xaa, 0xf0) > > + > > +#define FWU_OS_REQUEST_FW_ACCEPT_GUID \ > > + EFI_GUID(0x0c996046, 0xbcc0, 0x4d04, 0x85, 0xec, \ > > + 0xe1, 0xfc, 0xed, 0xf1, 0xc6, 0xf8) > > > > #define FWU_MDATA_GUID \ > > EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \ > >0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23) > > > > -int fwu_boottime_checks(void); > > +#define FWU_MDATA_VERSION0x1 > > +#define FWU_IMAGE_ACCEPTED 0x1 > > + > > u8 fwu_update_checks_pass(void); > > +int fwu_boottime_checks(void); > > +int fwu_trial_state_ctr_start(void); > > > > int fwu_get_active_index(u32 *active_idx); > > int fwu_update_active_index(u32 active_idx); > > diff --git a/lib/Kconfig b/lib/Kconfig > > index 807a4c6ade..7cb306317c 100644 > > --- a/lib/Kconfig > > +++ b/lib/Kconfig > > @@ -835,3 +835,35 @@ config PHANDLE_CHECK_SEQ > > When there are multiple device tree nodes with same name, > >enable this config option to distinguish them using > > phandles in fdtdec_get_alias_seq() function. > > + > > +config FWU_MULTI_BANK_UPDATE > > + bool "Enable FWU Multi Bank Update Feature" > > + depends on EFI_HAVE_CAPSULE_SUPPORT > > + select PARTITION_TYPE_GUID > > + select EFI_SETUP_EARLY > > + help > > + Feature for updating firmware images on platforms having > > + multiple banks(copies) of the firmware images. One of the > > + bank is selected for updating all the firmware components > > + > > +config FWU_NUM_BANKS > > + int "Number of Banks defined by the platform" > > + depends on FWU_MULTI_BANK_UPDATE > > + help > > + Define the number of banks of firmware images on a platform > > + > > +config FWU_NUM_IMAGES_PER_BANK > > + int "Number of firmware images per bank" > > + depends on FWU_MULTI_BANK_UPDATE > > + help > > + Define the number of firmware images per bank. This value > > + should be the same for all the banks. > > + > > +config FWU_TRIAL_STATE_CNT > > + int "Number of times system boots in Trial State" > > + depends on FWU_MULTI_BANK_UPDATE > > + default 3 > > + help > > + With FWU Multi Bank Update feature enabled, number of times > > + the platform is allowed to boot in Trial State after an > > + update. > > diff --git a/lib/Makefile b/lib/Makefile > > index 5ddbc77ed6..bc5c1e22fc 100644 > > --- a/lib/Makefile > > +++ b/lib/Makefile > > @@ -9,6 +9,7 @@ obj-$(CONFIG_EFI) += efi/ > > obj-$(CONFIG_EFI_LOADER) += efi_driver/ > > obj-$(CONFIG_EFI_LOADER) += efi_loader/ > > obj-$(CONFIG_CMD_BOOTEFI_SELFTEST) += efi_selftest/ > > +obj-$(CONFIG_FWU_MULTI_BANK_UPDATE) += fwu_updates/ > > obj-$(CONFIG_LZMA) += lzma/ > > obj-$(CONFIG_BZIP2) += bzip2/ > > obj-$(CONFIG_TIZEN) += tizen/ > > diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c > > index 8301eed631..6dfe56bb0f 100644 > > ---
Re: [PATCH] i2c: mvtwsi: Swab the register address if its size is > 1
Hello Stefan, On 18.12.21 14:42, Stefan Roese wrote: > Hi Heiko, > > On 11/18/21 09:18, Stefan Roese wrote: >> Testing on Armada XP with an EEPROM using register address with size >> of 2 has shown, that the register address bytes are sent to the I2C >> EEPROM in the incorrect order. This patch swabs the address bytes so >> that the correct address is transferred to the I2C device. >> >> BTW: This worked without any issues before migrating Armada XP to >> DM I2C. >> >> Signed-off-by: Stefan Roese >> Cc: Heiko Schocher >> Cc: Samuel Holland >> Cc: Baruch Siach >> Cc: Pali Rohár >> Cc: Marek Behún >> --- >> It would be good if other users of this I2C driver could test this change >> with e.g. I2C EEPROM devices using 2 bytes (or more) for addressing. > > Could you and other please take a look at this? Would be great, if this > could be pulled in the next merge window. Applied to u-boot-i2c master Thanks! bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH] fw_setenv: Unbreak fw_setenv caused by buggy MEMISLOCKED use
On Sat, 2021-12-18 at 18:23 +, Joakim Tjernlund wrote:
> Ping?
> Maybe just revert commit 8a726b852502 ("fw_setenv: lock the flash
> only if it was locked before") ?
>
>
> From: Joakim Tjernlund
> Sent: 13 December 2021 18:22
> To: u-boot@lists.denx.de; joe.hershber...@ni.com; fr0st6...@gmail.com
> Subject: Re: [PATCH] fw_setenv: Unbreak fw_setenv caused by buggy
> MEMISLOCKED use
>
> +Joe Hershberger
>
> Jocke
>
> On Wed, 2021-12-08 at 15:33 +0100, Joakim Tjernlund wrote:
> > Commit "fw_setenv: lock the flash only if it was locked before"
> > checks for Locked status with uninitialized erase data.
> > Address by moving the test for MEMISLOCKED.
> >
> > Fixes: 8a726b852502 ("fw_setenv: lock the flash only if it was
> > locked before")
> > Signed-off-by: Joakim Tjernlund
Joakim, can you provide more detailed description about what you want
to fix or revert, please? In which case you see problems with
8a726b852502?
Thanks.
Re: [PATCH v2 14/16] arm: dts: ls1028a-rdb: enable PCIe controllers from U-Boot dtsi
Am 2021-12-07 21:20, schrieb Vladimir Oltean: diff --git a/arch/arm/dts/fsl-ls1028a-rdb.dts b/arch/arm/dts/fsl-ls1028a-rdb.dts index 10070eab6e61..70fcf71dbd0e 100644 --- a/arch/arm/dts/fsl-ls1028a-rdb.dts +++ b/arch/arm/dts/fsl-ls1028a-rdb.dts @@ -9,6 +9,7 @@ /dts-v1/; #include "fsl-ls1028a.dtsi" +#include "fsl-ls1028a-rdb-u-boot.dtsi" This shouldn't be needed, as as the -u-boot.dtsi is automagically included (at least at board level dtbs). -michael
Please pull u-boot-i2c
Hello Tom, please pull from u-boot-i2c master: The following changes since commit d3213c26b56e564207515f1e28e663718e015dc3: Merge tag 'efi-2022-01-rc4-3' of https://source.denx.de/u-boot/custodians/u-boot-efi (2021-12-18 14:39:21 -0500) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-i2c.git tags/20211220-fixes-for-2022.01 for you to fetch changes up to ccea46c05b08b34ef829d460e50e2ce9bc17cdc7: i2c: mvtwsi: Swab the register address if its size is > 1 (2021-12-20 07:57:48 +0100) i2c changes for 20211220-fixes-for-2022.01 - mvtwsi: Swab the register address if its size is > 1 Stefan Roese (1): i2c: mvtwsi: Swab the register address if its size is > 1 drivers/i2c/mvtwsi.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) Azure build is fine: https://dev.azure.com/hs0298/hs/_build/results?buildId=77=results Thanks! bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH] arm: dts: stm32mp15: alignment with v5.16
Hi Patrick
On 12/17/21 4:30 PM, Patrick Delaunay wrote:
> Device tree alignment with Linux kernel v5.16-rc5
> - ARM: dts: stm32: set otg-rev on stm32mp151
> - ARM: dts: stm32: use usbphyc ck_usbo_48m as USBH OHCI clock on stm32mp151
> - ARM: dts: stm32: fix AV96 board SAI2 pin muxing on stm32mp15
> - ARM: dts: stm32: fix SAI sub nodes register range
> - ARM: dts: stm32: fix STUSB1600 Type-C irq level on stm32mp15xx-dkx
>
> Signed-off-by: Patrick Delaunay
> ---
>
> arch/arm/dts/stm32mp15-pinctrl.dtsi | 8
> arch/arm/dts/stm32mp151.dtsi| 19 ++-
> arch/arm/dts/stm32mp15xx-dkx.dtsi | 2 +-
> 3 files changed, 15 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/dts/stm32mp15-pinctrl.dtsi
> b/arch/arm/dts/stm32mp15-pinctrl.dtsi
> index 5b60ecbd71..d3553e0f01 100644
> --- a/arch/arm/dts/stm32mp15-pinctrl.dtsi
> +++ b/arch/arm/dts/stm32mp15-pinctrl.dtsi
> @@ -1179,7 +1179,7 @@
> };
> };
>
> - sai2a_pins_c: sai2a-4 {
> + sai2a_pins_c: sai2a-2 {
> pins {
> pinmux = , /* SAI2_SCK_A */
>, /* SAI2_SD_A */
> @@ -1190,7 +1190,7 @@
> };
> };
>
> - sai2a_sleep_pins_c: sai2a-5 {
> + sai2a_sleep_pins_c: sai2a-sleep-2 {
> pins {
> pinmux = , /* SAI2_SCK_A
> */
>, /* SAI2_SD_A
> */
> @@ -1235,14 +1235,14 @@
> };
> };
>
> - sai2b_pins_c: sai2a-4 {
> + sai2b_pins_c: sai2b-2 {
> pins1 {
> pinmux = ; /* SAI2_SD_B */
> bias-disable;
> };
> };
>
> - sai2b_sleep_pins_c: sai2a-sleep-5 {
> + sai2b_sleep_pins_c: sai2b-sleep-2 {
> pins {
> pinmux = ; /* SAI2_SD_B
> */
> };
> diff --git a/arch/arm/dts/stm32mp151.dtsi b/arch/arm/dts/stm32mp151.dtsi
> index 8e0a0bc1dd..5a2be00758 100644
> --- a/arch/arm/dts/stm32mp151.dtsi
> +++ b/arch/arm/dts/stm32mp151.dtsi
> @@ -842,7 +842,7 @@
> #sound-dai-cells = <0>;
>
> compatible = "st,stm32-sai-sub-a";
> - reg = <0x4 0x1c>;
> + reg = <0x4 0x20>;
> clocks = < SAI1_K>;
> clock-names = "sai_ck";
> dmas = < 87 0x400 0x01>;
> @@ -852,7 +852,7 @@
> sai1b: audio-controller@4400a024 {
> #sound-dai-cells = <0>;
> compatible = "st,stm32-sai-sub-b";
> - reg = <0x24 0x1c>;
> + reg = <0x24 0x20>;
> clocks = < SAI1_K>;
> clock-names = "sai_ck";
> dmas = < 88 0x400 0x01>;
> @@ -873,7 +873,7 @@
> sai2a: audio-controller@4400b004 {
> #sound-dai-cells = <0>;
> compatible = "st,stm32-sai-sub-a";
> - reg = <0x4 0x1c>;
> + reg = <0x4 0x20>;
> clocks = < SAI2_K>;
> clock-names = "sai_ck";
> dmas = < 89 0x400 0x01>;
> @@ -883,7 +883,7 @@
> sai2b: audio-controller@4400b024 {
> #sound-dai-cells = <0>;
> compatible = "st,stm32-sai-sub-b";
> - reg = <0x24 0x1c>;
> + reg = <0x24 0x20>;
> clocks = < SAI2_K>;
> clock-names = "sai_ck";
> dmas = < 90 0x400 0x01>;
> @@ -904,7 +904,7 @@
> sai3a: audio-controller@4400c004 {
> #sound-dai-cells = <0>;
> compatible = "st,stm32-sai-sub-a";
> - reg = <0x04 0x1c>;
> + reg = <0x04 0x20>;
> clocks = < SAI3_K>;
> clock-names = "sai_ck";
> dmas = < 113 0x400 0x01>;
> @@ -914,7 +914,7 @@
> sai3b: audio-controller@4400c024 {
> #sound-dai-cells = <0>;
> compatible = "st,stm32-sai-sub-b";
> - reg = <0x24 0x1c>;
> + reg = <0x24 0x20>;
> clocks = < SAI3_K>;
> clock-names = "sai_ck";
> dmas = < 114 0x400 0x01>;
> @@ -1103,6 +1103,7 @@
> g-np-tx-fifo-size = <32>;
> g-tx-fifo-size = <256 16 16 16 16 16 16 16>;
>
Re: [PATCH] sunxi: add board documentation
On Fri, 17 Dec 2021 09:37:08 -0700 Simon Glass wrote: Hi Simon, > On Sun, 12 Dec 2021 at 18:03, Andre Przywara wrote: > > > > Add some long overdue instructions for building and installing U-Boot on > > Allwinner SoC based boards. > > This describes the building process, including TF-A and crust, plus > > installation to SD card, eMMC and SPI flash, both from Linux and U-Boot > > itself. Also describe FEL booting. > > > > Signed-off-by: Andre Przywara > > --- > > Hi, > > > > please have a look whether this makes sense. Feel free to just try > > something, > > and point out ambiguities or missing bits. For missing topics, please > > send a follow-up patch ;-) > > > > Also this is quite long, shall this be split up in two (or more) files? > > > > This is what rst.ninjs.org made of it, if you prefer to read it formatted: > > https://paste.c-net.org/PleasantNeedy > > > > Cheers, > > Andre > > > > doc/board/allwinner/index.rst | 9 + > > doc/board/allwinner/sunxi.rst | 304 ++ > > 2 files changed, 313 insertions(+) > > create mode 100644 doc/board/allwinner/index.rst > > create mode 100644 doc/board/allwinner/sunxi.rst > > Reviewed-by: Simon Glass > > I agree that a follow-on patch to remove the duplicated files would be > helpful, but this patch is a big step forward on its own. Thanks! I will address the other comments ASAP. > It would be interesting to convert sunxi to use binman. But Samuel fixed that already, didn't he? Or is there anything left that binman should do? We even now use mkimage to generate the magic BROM SPL signature, and then let binman combine this with the FIT image into the final binary. Or am I missing something here? Or are you asking for patches that remove sunxi as the bad example from the existing documentation? ;-) Cheers, Andre
Re: [RESEND PATCH] Enable Fastboot(UUU) for O4-iMX6ULL-NANO boards
20.12.21 15:57, Tom Rini пише: On Mon, Dec 20, 2021 at 03:52:21PM +0200, Oleh Kravchenko wrote: Hello Tom, 20.12.21 15:50, Tom Rini пише: These dt changes are just whitespace? Are they resyncing with the upstream dts as well? But, unrelated, changes, yes? Yes, yes and yes :) OK, please v2 without them, thanks! I will do separate patch for this, ok? -- Best regards, Oleh Kravchenko
Re: [PATCH] doc: board: Add Calxeda Highbank/Midway documentation
On Fri, 17 Dec 2021 09:37:10 -0700
Simon Glass wrote:
Hi Simon,
> On Tue, 14 Dec 2021 at 10:47, Andre Przywara wrote:
> >
> > The Calxeda servers are using U-Boot as the primary bootloader, which
> > was shipped as part of a firmware upgrade package.
> > Even though the machines are considered legacy at this point, the port
> > still works, so deserves some documentation.
> >
> > Signed-off-by: Andre Przywara
> > ---
> > doc/board/highbank/highbank.rst | 78 +
> > doc/board/highbank/index.rst| 9
> > doc/board/index.rst | 1 +
> > 3 files changed, 88 insertions(+)
> > create mode 100644 doc/board/highbank/highbank.rst
> > create mode 100644 doc/board/highbank/index.rst
>
> Reviewed-by: Simon Glass
Thanks!
> nits below
>
> >
> > diff --git a/doc/board/highbank/highbank.rst
> > b/doc/board/highbank/highbank.rst
> > new file mode 100644
> > index 00..654ef8a026
> > --- /dev/null
> > +++ b/doc/board/highbank/highbank.rst
> > @@ -0,0 +1,78 @@
> > +Calxeda Highbank/Midway board support
> > +=
> > +
> > +The Calxeda ECX-1000 ("Highbank") and ECX-2000 ("Midway") were ARM based
>
> s/were/are/
>
> Present tense is much easier to understand.
Yeah, this was some poor attempt to signify that those systems are
considered obsolete by now.
> > +servers, providing high-density cluster systems. A single motherboard could
> > +host between 12 and 48 nodes, each with their own quad-core ARMv7
> > +processor, private DRAM and peripherals, connected through a high-bandwith
> > +and low-latency "fabric" network. Multiple motherboards could be connected
> > +together, to extend this fabric.
> > +
> > +For the purpose of U-Boot we just care about a single node, this can be
> > +used as a single system, just using the fabric to connect to some Ethernet
> > +network. Each node boots on its own, either from a local hard disk, or
> > +via the network.
> > +
> > +The earlier ECX-1000 nodes ("Highbank") contain four ARM Cortex-A9 cores,
> > +a Cortex-M3 system controller, three 10GBit/s MACs and five SATA
> > +controllers. The DRAM is limited to 4GB.
> > +
> > +The later ECX-2000 nodes ("Midway") use four Cortex-A15 cores, alongside
> > +two Cortex-A7 management cores, and support up to 32GB of DRAM, while
> > +keeping the other peripherals.
> > +
> > +For the purpose of U-Boot those two SoCs are very similar, so we offer
> > +one build target. The subtle differences are handled at runtime.
> > +Calxeda as a company is long defunct, and the remaining systems are
> > +considered legacy at this point.
> > +
> > +Bgilding U-Boot
>
> Building
>
> > +---
> > +There is only one defconfig to cover both systems::
> > +
> > +$ make highbank_defconfig
> > +$ make
> > +
> > +This will create ``u-boot.bin``, which could become part of the firmware
> > update
> > +package, or could be chainloaded by the existing U-Boot, see below for more
> > +details.
> > +
> > +Boot process
> > +
> > +Upon powering up a node (which would be controlled by some BMC style
>
> s/would be/is/
>
> We don't really care about tense, IMO. I suggest dropping 'would' and
> 'was', etc.
>
> > +management controller on the motherboard), the system controller ("ECME")
> > +would start and do some system initialisation (fabric registration,
> > +DRAM init, clock setup). It would load the device tree binary, some secure
> > +monitor code (``a9boot``/``a15boot``) and a U-Boot binary from SPI flash
> > +into DRAM, then power up the actual application cores (ARM Cortex-A9/A15).
> > +They would start executing ``a9boot``/``a15boot``, registering the PSCI SMC
> > +handlers, then dropping into U-Boot, but in non-secure state (HYP mode on
> > +the A15s).
> > +
> > +U-Boot would act as a mere loader, trying to find some ``boot.scr`` file on
> > +the local hard disks, or reverting to PXE boot.
> > +
> > +Updating U-Boot
> > +---
> > +The U-Boot binary is loaded from SPI flash, which is controlled exclusively
> > +by the ECME. This can be reached via IPMI using the LANplus transport
> > protocol.
> > +Updating the SPI flash content requires vendor specific additions to the
> > +IPMI protocol, support for which was never upstreamed to ipmitool or
> > +FreeIPMI. Some older repositories for `ipmitool`_, the `pyipmi`_ library
> > and
> > +a Python `management script`_ to update the SPI flash can be found on
> > Github.
> > +
> > +A simpler and safer way to get an up-to-date U-Boot running, is
> > chainloading
> > +it via the legacy U-Boot::
> > +
> > +$ mkimage -A arm -O u-boot -T standalone -C none -a 0x8000 -e 0x8000 \
> > + -n U-Boot -d u-boot.bin u-boot-highbank.img
> > +
> > +Then load this image file, either from hard disk, or via TFTP, from the
> > +existing U-Boot, and execute it with bootm::
> > +
> > +=> tftpboot 0x8000 u-boot-highbank.img
> > +=> bootm
> > +
> > +.. _`ipmitool`:
Re: [PATCH 1/2] doc: Add documentation for the Arm VExpress64 board configs
On Fri, 17 Dec 2021 09:37:12 -0700 Simon Glass wrote: Hi, > On Tue, 14 Dec 2021 at 10:55, Andre Przywara wrote: > > > > From: Peter Hoyes > > > > Create a new documentation section for Arm Ltd boards with a sub-page > > for the FVP VExpress64 system. > > > > Signed-off-by: Peter Hoyes > > [Andre: remove Juno stub] > > Signed-off-by: Andre Przywara > > --- > > doc/board/armltd/fvp64.rst | 30 ++ > > doc/board/armltd/index.rst | 10 ++ > > doc/board/index.rst| 1 + > > 3 files changed, 41 insertions(+) > > create mode 100644 doc/board/armltd/fvp64.rst > > create mode 100644 doc/board/armltd/index.rst > > > > diff --git a/doc/board/armltd/fvp64.rst b/doc/board/armltd/fvp64.rst > > new file mode 100644 > > index 00..9817b0aa3f > > --- /dev/null > > +++ b/doc/board/armltd/fvp64.rst > > @@ -0,0 +1,30 @@ > > +.. SPDX-License-Identifier: GPL-2.0 > > + > > +Fixed Virtual Platforms > > +=== > > + > > +The Fixed Virtual Platforms (FVP) are complete software simulations of an > > Arm > > +system, including processor, memory and peripherals. They are set out in a > > +"programmer's view", which gives a comprehensive model on which to build > > and > > +test software. > > + > > +The supported FVPs are available free of charge and can be downloaded from > > the > > +Arm developer site [1]_ (user registration might be required). > > + > > +Supported features: > > + > > + * GICv3 > > + * Generic timer > > + * PL011 UART > > + > > +The default configuration assumes that U-Boot is bootstrapped using a > > suitable > > +bootloader, such as Trusted Firmware-A [4]_. The u-boot binary can be > > passed > > TF-A has become a bootloader?! As much as U-Boot is firmware, yes :-P The full featured TF-A suite contains a whole loading stage (BL2), some platforms have MMC and even USB drivers. We can also put a Linux kernel directly into DRAM, then TF-A directly drops into Linux directly. The point is that for those virtual platforms a boot*loader* is strictly speaking not required, since you can much easier load through your host - either via semihosting or by letting the model programme put your binaries directly into the emulated DRAM. > > > +into the TF-A build: ``make PLAT= all fip BL33=u-boot.bin`` > > What is in this case? That depends on the exact model, but just "fvp" would probably be good enough to put in here. Cheers, Andre > > + > > +The FVPs can be debugged using Arm Development Studio [2]_. > > + > > +References > > +-- > > + > > +.. [1] > > https://developer.arm.com/tools-and-software/simulation-models/fixed-virtual-platforms > > +.. [2] > > https://developer.arm.com/tools-and-software/embedded/arm-development-studio > > diff --git a/doc/board/armltd/index.rst b/doc/board/armltd/index.rst > > new file mode 100644 > > index 00..caa6fd2bb0 > > --- /dev/null > > +++ b/doc/board/armltd/index.rst > > @@ -0,0 +1,10 @@ > > +.. SPDX-License-Identifier: GPL-2.0 > > +.. Copyright (C) 2021 Arm Ltd. > > + > > +ARM Ltd. boards and emulated systems > > + > > + > > +.. toctree:: > > + :maxdepth: 2 > > + > > + fvp64 > > diff --git a/doc/board/index.rst b/doc/board/index.rst > > index 74ea33e081..78b486538b 100644 > > --- a/doc/board/index.rst > > +++ b/doc/board/index.rst > > @@ -11,6 +11,7 @@ Board-specific doc > > AndesTech/index > > amlogic/index > > apple/index > > + armltd/index > > atmel/index > > congatec/index > > coreboot/index > > -- > > 2.25.1 > > > > Regards, > Simon
[PATCH v2 1/2] doc: Add documentation for the Arm VExpress64 board configs
From: Peter Hoyes Create a new documentation section for Arm Ltd boards with a sub-page for the FVP VExpress64 system. Signed-off-by: Peter Hoyes [Andre: remove Juno stub, RSTify] Signed-off-by: Andre Przywara --- doc/board/armltd/fvp64.rst | 30 ++ doc/board/armltd/index.rst | 10 ++ doc/board/index.rst| 1 + 3 files changed, 41 insertions(+) create mode 100644 doc/board/armltd/fvp64.rst create mode 100644 doc/board/armltd/index.rst diff --git a/doc/board/armltd/fvp64.rst b/doc/board/armltd/fvp64.rst new file mode 100644 index 00..4dc341bf2a --- /dev/null +++ b/doc/board/armltd/fvp64.rst @@ -0,0 +1,30 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Fixed Virtual Platforms +=== + +The Fixed Virtual Platforms (FVP) are complete software simulations of an Arm +system, including processor, memory and peripherals. They are set out in a +"programmer's view", which gives a comprehensive model on which to build and +test software. + +The supported FVPs are available free of charge and can be downloaded from the +`Arm developer site`_ (user registration might be required). + +Supported features: + + * GICv3 + * Generic timer + * PL011 UART + +The default configuration assumes that U-Boot is bootstrapped using a suitable +bootloader, such as `Trusted Firmware-A`_. The U-Boot binary can be passed +into the TF-A build:: + +make PLAT=fvp all fip BL33=/path/to/u-boot.bin + +The FVPs can be debugged using `Arm Development Studio`_. + +.. _`Arm developer site`: https://developer.arm.com/tools-and-software/simulation-models/fixed-virtual-platforms +.. _`Trusted Firmware-A`: https://www.trustedfirmware.org/projects/tf-a/ +.. _`Arm Development Studio`: https://developer.arm.com/tools-and-software/embedded/arm-development-studio diff --git a/doc/board/armltd/index.rst b/doc/board/armltd/index.rst new file mode 100644 index 00..caa6fd2bb0 --- /dev/null +++ b/doc/board/armltd/index.rst @@ -0,0 +1,10 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. Copyright (C) 2021 Arm Ltd. + +ARM Ltd. boards and emulated systems + + +.. toctree:: + :maxdepth: 2 + + fvp64 diff --git a/doc/board/index.rst b/doc/board/index.rst index 13f4db848e..d0a7838550 100644 --- a/doc/board/index.rst +++ b/doc/board/index.rst @@ -11,6 +11,7 @@ Board-specific doc AndesTech/index amlogic/index apple/index + armltd/index atmel/index congatec/index coreboot/index -- 2.25.1
[PATCH v2 2/2] doc: add Arm Juno board documentation
The Juno Arm development board is an open, vendor-neutral, Armv8-A development platform. Add documentation that briefly outlines the hardware, and describes building and installation of U-Boot. Signed-off-by: Andre Przywara --- doc/board/armltd/index.rst | 1 + doc/board/armltd/juno.rst | 114 + 2 files changed, 115 insertions(+) create mode 100644 doc/board/armltd/juno.rst diff --git a/doc/board/armltd/index.rst b/doc/board/armltd/index.rst index caa6fd2bb0..68d938c647 100644 --- a/doc/board/armltd/index.rst +++ b/doc/board/armltd/index.rst @@ -8,3 +8,4 @@ ARM Ltd. boards and emulated systems :maxdepth: 2 fvp64 + juno diff --git a/doc/board/armltd/juno.rst b/doc/board/armltd/juno.rst new file mode 100644 index 00..3d20ff129c --- /dev/null +++ b/doc/board/armltd/juno.rst @@ -0,0 +1,114 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. Copyright (C) 2021 Arm Ltd. + +Arm Juno development platform += + +The `Juno development board`_ is an open, vendor-neutral, Armv8-A development +platform, made by Arm Ltd. It is part of the Versatile Express family. +There are three revisions of the board: + +* Juno r0, with two Cortex-A57 and four Cortex-A53 cores, without PCIe. +* Juno r1, with two Cortex-A57 and four Cortex-A53 cores, in later silicon + revisions, and with PCIe slots, Gigabit Ethernet and two SATA ports. +* Juno r2, with two Cortex-A72 and four Cortex-A53 cores, otherwise the + same as r1. + +Among other things, the motherboard contains a management controller (MCC), +an FPGA providing I/O interfaces (IOFPGA) and 64MB of NOR flash. The provided +platform devices resemble the VExpress peripherals. +The actual SoC also contains a Cortex-M3 based System Control Processor (SCP). +The `V2M-Juno TRM`_ contains more technical details. + +U-Boot build + +There is only one defconfig and one binary build that covers all three board +revisions, so to generate the needed ``u-boot.bin``: + +.. code-block:: bash + +$ make vexpress_aemv8a_juno_defconfig +$ make + +The automatic distro boot sequence looks for UEFI boot applications and +``boot.scr`` scripts on various boot media, starting with USB, then on disks +connected to the two SATA ports, PXE, DHCP and eventually on the NOR flash. + +U-Boot installation +--- +This assumes there is some firmware on the SD card or NOR flash (see below +for more details). The U-Boot binary is included in the Trusted Firmware +FIP image, so after building U-Boot, this needs to be repackaged or recompiled. + +The NOR flash will be updated by the MCC, based on the content of a micro-SD +card, which is exported as a USB mass storage device via the rear USB-B +socket. So to access that SD card, connect a cable to some host computer, and +mount the FAT16 partition of the UMS device. +If there is no device, check the upper serial port for a prompt, and +explicitly enable the USB interface:: + +Cmd> usb_on +Enabling debug USB... + +Repackaging an existing FIP image +^ +To prevent problems, it is probably a good idea to backup the existing firmware, +for instance by just copying the entire ``SOFTWARE/`` directory, or at least +the current ``fip.bin``, beforehand. + +To just replace the BL33 image in the exising FIP image, you can use +`fiptool`_ from the Trusted Firmware repository, on the image file: + +.. code-block:: bash + +$ git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git +$ cd trusted-firmware-a +$ make fiptool +$ tools/fiptool/fiptool update --nt-fw=/path/to/your/u-boot.bin /mnt/juno/SOFTWARE/fip.bin + +Unmount the USB mass storage device and reboot the board, the new ``fip.bin`` +will be automatically written to the NOR flash and then used. + +Rebuilding Trusted Firmware +^^^ +You can also generate a new FIP image by compiling Arm Trusted Firmware, +and providing ``u-boot.bin`` as the BL33 file. For that you can either build +the required `SCP firmware`_ yourself, or just extract the existing +version from your ``fip.bin``, using `fiptool`_ (see above): + +.. code-block:: bash + +$ mkdir /tmp/juno; cd /tmp/juno +$ fiptool unpack /mnt/juno/SOFTWARE/fip.bin + +Then build TF-A: + +.. code-block:: bash + +$ git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git +$ cd trusted-firmware-a +$ make CROSS_COMPILE=aarch64-linux-gnu- PLAT=juno DEBUG=1 \ + SCP_BL2=/tmp/juno/scp-fw.bin BL33=/path/to/your/u-boot.bin fiptool all fip +$ cp build/juno/debug/bl1.bin build/juno/debug/fip.bin /mnt/juno/SOFTWARE + +Then umount the USB device, and reboot, as above. + +Device trees + +The device tree files for the boards are maintained in the Linux kernel +repository. They end up in the ``SOFTWARE/`` directory of the SD card, as +``juno.dtb``, ``juno-r1.dtb``, and ``juno-r2.dtb``, respectively. The MCC +firmware will look into
[PATCH v2 0/2] Arm Juno board documentation
Hi, The Arm Ltd. Juno development board is an open, vendor-neutral, Armv8-A development platform. U-Boot is one of the two supported normal world payloads in the firmware design, though U-Boot never really described the process of building or installing it. Fix that by adding documentation for the board in the doc/board directory. Cheers, Andre Changelog: v1 ... v2: - fvp64: RST improvements (links, make command line) - fvp64: use most common platform name in TF-A build command - juno: use more precise naming for Juno development *platform* - juno: fix wrong naming of MCC management controller - juno: mention and link to Juno TRM - juno: simplify SD card connection instructions - juno: use fiptool update instead of complicated explicit re-packaging - juno: describe devicetree selection more precisely Andre Przywara (1): doc: add Arm Juno board documentation Peter Hoyes (1): doc: Add documentation for the Arm VExpress64 board configs doc/board/armltd/fvp64.rst | 30 ++ doc/board/armltd/index.rst | 11 doc/board/armltd/juno.rst | 114 + doc/board/index.rst| 1 + 4 files changed, 156 insertions(+) create mode 100644 doc/board/armltd/fvp64.rst create mode 100644 doc/board/armltd/index.rst create mode 100644 doc/board/armltd/juno.rst -- 2.25.1
Re: [RFC PATCH v2 1/8] FWU: Add FWU metadata structure and functions for accessing metadata
On Tue, 21 Dec 2021 at 10:33, AKASHI Takahiro
wrote:
> On Tue, Dec 21, 2021 at 10:05:57AM +0530, Sughosh Ganu wrote:
> > hi Masami,
> >
> > On Tue, 21 Dec 2021 at 05:40, Masami Hiramatsu <
> masami.hirama...@linaro.org>
> > wrote:
> >
> > > Hi Sughosh,
> > >
> > > 2021年12月19日(日) 16:06 Sughosh Ganu :
> > > >
> > > > In the FWU Multi Bank Update feature, the information about the
> > > > updatable images is stored as part of the metadata, which is stored
> on
> > > > a dedicated partition. Add the metadata structure, and functions to
> > > > access the metadata. These are generic API's, and implementations can
> > > > be added based on parameters like how the metadata partition is
> > > > accessed and what type of storage device houses the metadata.
> > > >
> > > > Signed-off-by: Sughosh Ganu
> > > > ---
> > > > Changes since V1:
> > > > * Move all function declarations to a separate header fwu.h
> > > > * Rename metadata with mdata for all symbols
> > > > * Drop the parameter in the function fwu_revert_boot_index
> > > > as suggested by Etienne
> > > >
> > > > include/fwu.h | 28 +
> > > > include/fwu_mdata.h | 102
> > > > lib/fwu_updates/fwu_mdata.c | 236
>
> > > > 3 files changed, 366 insertions(+)
> > > > create mode 100644 include/fwu.h
> > > > create mode 100644 include/fwu_mdata.h
> > > > create mode 100644 lib/fwu_updates/fwu_mdata.c
> > > >
> > > > diff --git a/include/fwu.h b/include/fwu.h
> > > > new file mode 100644
> > > > index 00..e6bc3e6b73
> > > > --- /dev/null
> > > > +++ b/include/fwu.h
> > > > @@ -0,0 +1,28 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0+ */
> > > > +/*
> > > > + * Copyright (c) 2021, Linaro Limited
> > > > + */
> > > > +
> > > > +#if !defined _FWU_H_
> > > > +#define _FWU_H_
> > > > +
> > > > +#include
> > > > +
> > > > +#include
> > > > +
> > > > +#define FWU_MDATA_VERSION 0x1
> > > > +
> > > > +#define FWU_MDATA_GUID \
> > > > + EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \
> > > > +0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23)
> > > > +
> > > > +int fwu_get_active_index(u32 *active_idx);
> > > > +int fwu_update_active_index(u32 active_idx);
> > > > +int fwu_get_image_alt_num(efi_guid_t image_type_id, u32 update_bank,
> > > > + int *alt_num);
> > > > +int fwu_mdata_check(void);
> > > > +int fwu_revert_boot_index(void);
> > > > +int fwu_accept_image(efi_guid_t *img_type_id);
> > > > +int fwu_clear_accept_image(efi_guid_t *img_type_id, u32 bank);
> > > > +
> > > > +#endif /* _FWU_H_ */
> > > > diff --git a/include/fwu_mdata.h b/include/fwu_mdata.h
> > > > new file mode 100644
> > > > index 00..11eb570012
> > > > --- /dev/null
> > > > +++ b/include/fwu_mdata.h
> > > > @@ -0,0 +1,102 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0+ */
> > > > +/*
> > > > + * Copyright (c) 2021, Linaro Limited
> > > > + */
> > > > +
> > > > +#if !defined _FWU_MDATA_H_
> > > > +#define _FWU_MDATA_H_
> > > > +
> > > > +#include
> > > > +#include
> > > > +
> > > > +#include
> > > > +
> > > > +/**
> > > > + * struct fwu_image_bank_info - firmware image information
> > > > + * @image_uuid: Guid value of the image in this bank
> > > > + * @accepted: Acceptance status of the image
> > > > + * @reserved: Reserved
> > > > + *
> > > > + * The structure contains image specific fields which are
> > > > + * used to identify the image and to specify the image's
> > > > + * acceptance status
> > > > + */
> > > > +struct fwu_image_bank_info {
> > > > + efi_guid_t image_uuid;
> > > > + u32 accepted;
> > > > + u32 reserved;
> > > > +};
> > >
> > > Could you explicitly pack these metadata data structures?
> > > Since these metadata will be shared among bootloaders (TF-A,
> SCP-firmware),
> > > it is better to ensure that those are packed and fixed offset for each
> > > field.
> > >
> >
> > Okay. WIll do it.
> >
> >
> > >
> > > > +
> > > > +/**
> > > > + * struct fwu_image_entry - information for a particular type of
> image
> > > > + * @image_type_uuid: Guid value for identifying the image type
> > > > + * @location_uuid: Guid of the storage volume where the image is
> located
> > > > + * @img_bank_info: Array containing properties of images
> > > > + *
> > > > + * This structure contains information on various types of updatable
> > > > + * firmware images. Each image type then contains an array of image
> > > > + * information per bank.
> > > > + */
> > > > +struct fwu_image_entry {
> > > > + efi_guid_t image_type_uuid;
> > > > + efi_guid_t location_uuid;
> > > > + struct fwu_image_bank_info
> img_bank_info[CONFIG_FWU_NUM_BANKS];
> > > > +};
> > > > +
> > > > +/**
> > > > + * struct fwu_mdata - FWU metadata structure for multi-bank updates
> > > > + * @crc32: crc32 value for the FWU metadata
> > > > + * @version: FWU metadata version
> > > > + * @active_index: Index of the bank currently used for booting
> images
Re: [RFC PATCH v2 1/8] FWU: Add FWU metadata structure and functions for accessing metadata
On Tue, Dec 21, 2021 at 11:17:47AM +0530, Sughosh Ganu wrote:
> On Tue, 21 Dec 2021 at 10:33, AKASHI Takahiro
> wrote:
>
> > On Tue, Dec 21, 2021 at 10:05:57AM +0530, Sughosh Ganu wrote:
> > > hi Masami,
> > >
> > > On Tue, 21 Dec 2021 at 05:40, Masami Hiramatsu <
> > masami.hirama...@linaro.org>
> > > wrote:
> > >
> > > > Hi Sughosh,
> > > >
> > > > 2021年12月19日(日) 16:06 Sughosh Ganu :
> > > > >
> > > > > In the FWU Multi Bank Update feature, the information about the
> > > > > updatable images is stored as part of the metadata, which is stored
> > on
> > > > > a dedicated partition. Add the metadata structure, and functions to
> > > > > access the metadata. These are generic API's, and implementations can
> > > > > be added based on parameters like how the metadata partition is
> > > > > accessed and what type of storage device houses the metadata.
> > > > >
> > > > > Signed-off-by: Sughosh Ganu
> > > > > ---
> > > > > Changes since V1:
> > > > > * Move all function declarations to a separate header fwu.h
> > > > > * Rename metadata with mdata for all symbols
> > > > > * Drop the parameter in the function fwu_revert_boot_index
> > > > > as suggested by Etienne
> > > > >
> > > > > include/fwu.h | 28 +
> > > > > include/fwu_mdata.h | 102
> > > > > lib/fwu_updates/fwu_mdata.c | 236
> >
> > > > > 3 files changed, 366 insertions(+)
> > > > > create mode 100644 include/fwu.h
> > > > > create mode 100644 include/fwu_mdata.h
> > > > > create mode 100644 lib/fwu_updates/fwu_mdata.c
> > > > >
> > > > > diff --git a/include/fwu.h b/include/fwu.h
> > > > > new file mode 100644
> > > > > index 00..e6bc3e6b73
> > > > > --- /dev/null
> > > > > +++ b/include/fwu.h
> > > > > @@ -0,0 +1,28 @@
> > > > > +/* SPDX-License-Identifier: GPL-2.0+ */
> > > > > +/*
> > > > > + * Copyright (c) 2021, Linaro Limited
> > > > > + */
> > > > > +
> > > > > +#if !defined _FWU_H_
> > > > > +#define _FWU_H_
> > > > > +
> > > > > +#include
> > > > > +
> > > > > +#include
> > > > > +
> > > > > +#define FWU_MDATA_VERSION 0x1
> > > > > +
> > > > > +#define FWU_MDATA_GUID \
> > > > > + EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \
> > > > > +0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23)
> > > > > +
> > > > > +int fwu_get_active_index(u32 *active_idx);
> > > > > +int fwu_update_active_index(u32 active_idx);
> > > > > +int fwu_get_image_alt_num(efi_guid_t image_type_id, u32 update_bank,
> > > > > + int *alt_num);
> > > > > +int fwu_mdata_check(void);
> > > > > +int fwu_revert_boot_index(void);
> > > > > +int fwu_accept_image(efi_guid_t *img_type_id);
> > > > > +int fwu_clear_accept_image(efi_guid_t *img_type_id, u32 bank);
> > > > > +
> > > > > +#endif /* _FWU_H_ */
> > > > > diff --git a/include/fwu_mdata.h b/include/fwu_mdata.h
> > > > > new file mode 100644
> > > > > index 00..11eb570012
> > > > > --- /dev/null
> > > > > +++ b/include/fwu_mdata.h
> > > > > @@ -0,0 +1,102 @@
> > > > > +/* SPDX-License-Identifier: GPL-2.0+ */
> > > > > +/*
> > > > > + * Copyright (c) 2021, Linaro Limited
> > > > > + */
> > > > > +
> > > > > +#if !defined _FWU_MDATA_H_
> > > > > +#define _FWU_MDATA_H_
> > > > > +
> > > > > +#include
> > > > > +#include
> > > > > +
> > > > > +#include
> > > > > +
> > > > > +/**
> > > > > + * struct fwu_image_bank_info - firmware image information
> > > > > + * @image_uuid: Guid value of the image in this bank
> > > > > + * @accepted: Acceptance status of the image
> > > > > + * @reserved: Reserved
> > > > > + *
> > > > > + * The structure contains image specific fields which are
> > > > > + * used to identify the image and to specify the image's
> > > > > + * acceptance status
> > > > > + */
> > > > > +struct fwu_image_bank_info {
> > > > > + efi_guid_t image_uuid;
> > > > > + u32 accepted;
> > > > > + u32 reserved;
> > > > > +};
> > > >
> > > > Could you explicitly pack these metadata data structures?
> > > > Since these metadata will be shared among bootloaders (TF-A,
> > SCP-firmware),
> > > > it is better to ensure that those are packed and fixed offset for each
> > > > field.
> > > >
> > >
> > > Okay. WIll do it.
> > >
> > >
> > > >
> > > > > +
> > > > > +/**
> > > > > + * struct fwu_image_entry - information for a particular type of
> > image
> > > > > + * @image_type_uuid: Guid value for identifying the image type
> > > > > + * @location_uuid: Guid of the storage volume where the image is
> > located
> > > > > + * @img_bank_info: Array containing properties of images
> > > > > + *
> > > > > + * This structure contains information on various types of updatable
> > > > > + * firmware images. Each image type then contains an array of image
> > > > > + * information per bank.
> > > > > + */
> > > > > +struct fwu_image_entry {
> > > > > + efi_guid_t image_type_uuid;
> > > > > + efi_guid_t location_uuid;
> > > > > + struct
Re: [PATCH v7 04/24] x86: Don't process the kernel command line unless enabled
On 12/18/21 19:28, Simon Glass wrote:
If the 'bootm' command is not enabled then this code is not available and
this causes a link error. Fix it.
Note that for the EFI app, there is no indication of missing code. It just
hangs!
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/x86/lib/zimage.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index 7ce02226ef9..9cc04490307 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -365,11 +365,14 @@ int setup_zimage(struct boot_params *setup_base, char
*cmd_line, int auto_boot,
strcpy(cmd_line, (char *)cmdline_force);
else
build_command_line(cmd_line, auto_boot);
- ret = bootm_process_cmdline(cmd_line, max_size, BOOTM_CL_ALL);
- if (ret) {
- printf("Cmdline setup failed (max_size=%x, bootproto=%x,
err=%d)\n",
- max_size, bootproto, ret);
- return ret;
+ if (IS_ENABLED(CONFIG_CMD_BOOTM)) {
For zImages we have command bootz. Why would you disable this if
CONFIG_CMD_BOOTZ=y?
The module is called zimage.c. Is this code used when booting via bootm
at all?
Best regards
Heinrich
+ ret = bootm_process_cmdline(cmd_line, max_size,
+ BOOTM_CL_ALL);
+ if (ret) {
+ printf("Cmdline setup failed (max_size=%x,
bootproto=%x, err=%d)\n",
+ max_size, bootproto, ret);
+ return ret;
+ }
}
printf("Kernel command line: \"");
puts(cmd_line);
Re: [RFC PATCH v2 1/8] FWU: Add FWU metadata structure and functions for accessing metadata
Hi Sughosh,
2021年12月21日(火) 14:47 Sughosh Ganu :
>
>
> On Tue, 21 Dec 2021 at 10:33, AKASHI Takahiro
> wrote:
>>
>> On Tue, Dec 21, 2021 at 10:05:57AM +0530, Sughosh Ganu wrote:
>> > hi Masami,
>> >
>> > On Tue, 21 Dec 2021 at 05:40, Masami Hiramatsu
>> >
>> > wrote:
>> >
>> > > Hi Sughosh,
>> > >
>> > > 2021年12月19日(日) 16:06 Sughosh Ganu :
>> > > >
>> > > > In the FWU Multi Bank Update feature, the information about the
>> > > > updatable images is stored as part of the metadata, which is stored on
>> > > > a dedicated partition. Add the metadata structure, and functions to
>> > > > access the metadata. These are generic API's, and implementations can
>> > > > be added based on parameters like how the metadata partition is
>> > > > accessed and what type of storage device houses the metadata.
>> > > >
>> > > > Signed-off-by: Sughosh Ganu
>> > > > ---
>> > > > Changes since V1:
>> > > > * Move all function declarations to a separate header fwu.h
>> > > > * Rename metadata with mdata for all symbols
>> > > > * Drop the parameter in the function fwu_revert_boot_index
>> > > > as suggested by Etienne
>> > > >
>> > > > include/fwu.h | 28 +
>> > > > include/fwu_mdata.h | 102
>> > > > lib/fwu_updates/fwu_mdata.c | 236
>> > > > 3 files changed, 366 insertions(+)
>> > > > create mode 100644 include/fwu.h
>> > > > create mode 100644 include/fwu_mdata.h
>> > > > create mode 100644 lib/fwu_updates/fwu_mdata.c
>> > > >
>> > > > diff --git a/include/fwu.h b/include/fwu.h
>> > > > new file mode 100644
>> > > > index 00..e6bc3e6b73
>> > > > --- /dev/null
>> > > > +++ b/include/fwu.h
>> > > > @@ -0,0 +1,28 @@
>> > > > +/* SPDX-License-Identifier: GPL-2.0+ */
>> > > > +/*
>> > > > + * Copyright (c) 2021, Linaro Limited
>> > > > + */
>> > > > +
>> > > > +#if !defined _FWU_H_
>> > > > +#define _FWU_H_
>> > > > +
>> > > > +#include
>> > > > +
>> > > > +#include
>> > > > +
>> > > > +#define FWU_MDATA_VERSION 0x1
>> > > > +
>> > > > +#define FWU_MDATA_GUID \
>> > > > + EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \
>> > > > +0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23)
>> > > > +
>> > > > +int fwu_get_active_index(u32 *active_idx);
>> > > > +int fwu_update_active_index(u32 active_idx);
>> > > > +int fwu_get_image_alt_num(efi_guid_t image_type_id, u32 update_bank,
>> > > > + int *alt_num);
>> > > > +int fwu_mdata_check(void);
>> > > > +int fwu_revert_boot_index(void);
>> > > > +int fwu_accept_image(efi_guid_t *img_type_id);
>> > > > +int fwu_clear_accept_image(efi_guid_t *img_type_id, u32 bank);
>> > > > +
>> > > > +#endif /* _FWU_H_ */
>> > > > diff --git a/include/fwu_mdata.h b/include/fwu_mdata.h
>> > > > new file mode 100644
>> > > > index 00..11eb570012
>> > > > --- /dev/null
>> > > > +++ b/include/fwu_mdata.h
>> > > > @@ -0,0 +1,102 @@
>> > > > +/* SPDX-License-Identifier: GPL-2.0+ */
>> > > > +/*
>> > > > + * Copyright (c) 2021, Linaro Limited
>> > > > + */
>> > > > +
>> > > > +#if !defined _FWU_MDATA_H_
>> > > > +#define _FWU_MDATA_H_
>> > > > +
>> > > > +#include
>> > > > +#include
>> > > > +
>> > > > +#include
>> > > > +
>> > > > +/**
>> > > > + * struct fwu_image_bank_info - firmware image information
>> > > > + * @image_uuid: Guid value of the image in this bank
>> > > > + * @accepted: Acceptance status of the image
>> > > > + * @reserved: Reserved
>> > > > + *
>> > > > + * The structure contains image specific fields which are
>> > > > + * used to identify the image and to specify the image's
>> > > > + * acceptance status
>> > > > + */
>> > > > +struct fwu_image_bank_info {
>> > > > + efi_guid_t image_uuid;
>> > > > + u32 accepted;
>> > > > + u32 reserved;
>> > > > +};
>> > >
>> > > Could you explicitly pack these metadata data structures?
>> > > Since these metadata will be shared among bootloaders (TF-A,
>> > > SCP-firmware),
>> > > it is better to ensure that those are packed and fixed offset for each
>> > > field.
>> > >
>> >
>> > Okay. WIll do it.
>> >
>> >
>> > >
>> > > > +
>> > > > +/**
>> > > > + * struct fwu_image_entry - information for a particular type of image
>> > > > + * @image_type_uuid: Guid value for identifying the image type
>> > > > + * @location_uuid: Guid of the storage volume where the image is
>> > > > located
>> > > > + * @img_bank_info: Array containing properties of images
>> > > > + *
>> > > > + * This structure contains information on various types of updatable
>> > > > + * firmware images. Each image type then contains an array of image
>> > > > + * information per bank.
>> > > > + */
>> > > > +struct fwu_image_entry {
>> > > > + efi_guid_t image_type_uuid;
>> > > > + efi_guid_t location_uuid;
>> > > > + struct fwu_image_bank_info img_bank_info[CONFIG_FWU_NUM_BANKS];
>> > > > +};
>> > > > +
>> > > > +/**
>> > > > + * struct fwu_mdata - FWU metadata structure for multi-bank updates
>> >
[PATCH] cmd: Add pause command
This command is being introduced with the goal of allowing user-friendly
"generic use case" U-Boot builds to pause until user input under some
situations.
The main use case would be when a boot failure happens, to pause until
the user has had time to acknowledge the current state.
Signed-off-by: Samuel Dionne-Riel
---
cmd/Kconfig | 7 +++
cmd/Makefile | 1 +
cmd/pause.c | 35 +++
3 files changed, 43 insertions(+)
create mode 100644 cmd/pause.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 5b30b13e43..26d5707f75 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1807,6 +1807,13 @@ config CMD_GETTIME
milliseconds. See also the 'bootstage' command which provides more
flexibility for boot timing.
+config CMD_PAUSE
+ bool "pause command"
+ default y
+ help
+ Delay execution waiting for any user input.
+ Useful to allow the user to read a failure log.
+
config CMD_RNG
bool "rng command"
depends on DM_RNG
diff --git a/cmd/Makefile b/cmd/Makefile
index 891819ae0f..6c4db4ed2e 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -98,6 +98,7 @@ obj-$(CONFIG_CMD_MFSL) += mfsl.o
obj-$(CONFIG_CMD_MII) += mii.o
obj-$(CONFIG_CMD_MISC) += misc.o
obj-$(CONFIG_CMD_MDIO) += mdio.o
+obj-$(CONFIG_CMD_PAUSE) += pause.o
obj-$(CONFIG_CMD_SLEEP) += sleep.o
obj-$(CONFIG_CMD_MMC) += mmc.o
obj-$(CONFIG_CMD_OPTEE_RPMB) += optee_rpmb.o
diff --git a/cmd/pause.c b/cmd/pause.c
new file mode 100644
index 00..0a7ea35ebe
--- /dev/null
+++ b/cmd/pause.c
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2021
+ * Samuel Dionne-Riel
+ */
+
+#include
+#include
+
+static int do_pause(struct cmd_tbl *cmdtp, int flag, int argc, char *const
argv[])
+{
+ char *message = "Press any key to continue...";
+
+ if (argc > 2)
+ return CMD_RET_USAGE;
+
+ if (argc == 2)
+ message = argv[1];
+
+ /* No newline, so it sticks to the bottom of the screen */
+ printf("%s", message);
+
+ /* Wait on "any" key... */
+ (void) getchar();
+
+ /* Since there was no newline, we need it now. */
+ printf("\n");
+
+ return CMD_RET_SUCCESS;
+}
+
+U_BOOT_CMD(pause, 2, 1, do_pause,
+ "delay until user input",
+ "pause [prompt] - Wait until users presses any key. [prompt] can be
used to customize the message.\n"
+);
--
2.34.0
--
Samuel Dionne-Riel
Re: [RFC PATCH v2 5/8] EFI: FMP: Add provision to update image's ImageTypeId in image descriptor
Sughosh,
On Sun, Dec 19, 2021 at 12:36:02PM +0530, Sughosh Ganu wrote:
> The FWU Multi Banks Update feature allows updating different types of
> updatable firmware images on the platform. These image types are
> identified using the ImageTypeId GUID value. Add support in the
> GetImageInfo function of the FMP protocol to get the GUID values for
> the individual images and populate these in the image descriptor for
> the corresponding images.
>
> Signed-off-by: Sughosh Ganu
> ---
> Changes since V1:
> * Define a new function fwu_plat_get_alt_num for filling up
> all the dfu partitions with a preset ImageTypeId guid
> * Remove the distinction made in the earlier version for
> setting image_type_id as suggested by Heinrich
>
> lib/efi_loader/efi_firmware.c | 90 ---
> 1 file changed, 83 insertions(+), 7 deletions(-)
>
> diff --git a/lib/efi_loader/efi_firmware.c b/lib/efi_loader/efi_firmware.c
> index a1b88dbfc2..648342ae72 100644
> --- a/lib/efi_loader/efi_firmware.c
> +++ b/lib/efi_loader/efi_firmware.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -96,6 +97,46 @@ efi_status_t EFIAPI
> efi_firmware_set_package_info_unsupported(
> return EFI_EXIT(EFI_UNSUPPORTED);
> }
>
> +static efi_status_t fill_part_guid_array(const efi_guid_t *guid,
> + efi_guid_t **part_guid_arr)
> +{
> + int i;
> + int dfu_num = 0;
> + efi_guid_t *guid_arr;
> + struct dfu_entity *dfu;
> + efi_status_t ret = EFI_SUCCESS;
> +
> + dfu_init_env_entities(NULL, NULL);
> +
> + dfu_num = 0;
> + list_for_each_entry(dfu, _list, list) {
> + dfu_num++;
> + }
> +
> + if (!dfu_num) {
> + log_warning("Probably dfu_alt_info not defined\n");
> + ret = EFI_NOT_READY;
> + goto out;
> + }
> +
> + *part_guid_arr = malloc(sizeof(efi_guid_t) * dfu_num);
> + if (!*part_guid_arr) {
> + ret = EFI_OUT_OF_RESOURCES;
> + goto out;
> + }
> +
> + guid_arr = *part_guid_arr;
> + for (i = 0; i < dfu_num; i++) {
> + guidcpy(guid_arr, guid);
> + ++guid_arr;
> + }
> +
> +out:
> + dfu_free_entities();
> +
> + return ret;
> +}
> +
> /**
> * efi_get_dfu_info - return information about the current firmware image
> * @this:Protocol instance
> @@ -104,9 +145,9 @@ efi_status_t EFIAPI
> efi_firmware_set_package_info_unsupported(
> * @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
> - * image_type: Image type GUID
> + * @package_version: Package version
> + * @package_version_name:Package version's name
> + * @guid_array: Image type GUID array
If I understand your code correctly, a guid in descriptor for any image
(I mean any part defined by dfu_alto_info) will have the same value
even with this change.
If so, why do we have to take an array of GUIDs as a parameter?
On your previous version, Heinrich made a comment like:
! The sequence of GUIDs in a capsule should not influence the update. The
! design lacks a configuration defining which GUID maps to which DFU part.
!
! Please, get rid of all DFU environment variables and describe the update
! in a configuration file that you add to the capsule.
Have you addressed this issue in this series?
(To do that, we may have to introduce a new format of capsule file.)
-Takahiro Akashi
> *
> * Return information bout the current firmware image in @image_info.
> * @image_info will consist of a number of descriptors.
> @@ -122,7 +163,7 @@ static efi_status_t efi_get_dfu_info(
> efi_uintn_t *descriptor_size,
> u32 *package_version,
> u16 **package_version_name,
> - const efi_guid_t *image_type)
> + const efi_guid_t *guid_array)
> {
> struct dfu_entity *dfu;
> size_t names_len, total_size;
> @@ -172,7 +213,7 @@ static efi_status_t efi_get_dfu_info(
> next = name;
> list_for_each_entry(dfu, _list, list) {
> image_info[i].image_index = dfu->alt + 1;
> - image_info[i].image_type_id = *image_type;
> + image_info[i].image_type_id = guid_array[i];
> image_info[i].image_id = dfu->alt;
>
> /* copy the DFU entity name */
> @@ -250,6 +291,7 @@ efi_status_t EFIAPI efi_firmware_fit_get_image_info(
> u16 **package_version_name)
> {
> efi_status_t ret;
> + efi_guid_t *part_guid_arr = NULL;
>
> EFI_ENTRY("%p %p %p %p %p %p %p %p\n", this,
> image_info_size, image_info,
> @@ -264,12 +306,19 @@ efi_status_t EFIAPI efi_firmware_fit_get_image_info(
>
Re: [RFC PATCH v2 1/8] FWU: Add FWU metadata structure and functions for accessing metadata
hi Masami,
On Tue, 21 Dec 2021 at 05:40, Masami Hiramatsu
wrote:
> Hi Sughosh,
>
> 2021年12月19日(日) 16:06 Sughosh Ganu :
> >
> > In the FWU Multi Bank Update feature, the information about the
> > updatable images is stored as part of the metadata, which is stored on
> > a dedicated partition. Add the metadata structure, and functions to
> > access the metadata. These are generic API's, and implementations can
> > be added based on parameters like how the metadata partition is
> > accessed and what type of storage device houses the metadata.
> >
> > Signed-off-by: Sughosh Ganu
> > ---
> > Changes since V1:
> > * Move all function declarations to a separate header fwu.h
> > * Rename metadata with mdata for all symbols
> > * Drop the parameter in the function fwu_revert_boot_index
> > as suggested by Etienne
> >
> > include/fwu.h | 28 +
> > include/fwu_mdata.h | 102
> > lib/fwu_updates/fwu_mdata.c | 236
> > 3 files changed, 366 insertions(+)
> > create mode 100644 include/fwu.h
> > create mode 100644 include/fwu_mdata.h
> > create mode 100644 lib/fwu_updates/fwu_mdata.c
> >
> > diff --git a/include/fwu.h b/include/fwu.h
> > new file mode 100644
> > index 00..e6bc3e6b73
> > --- /dev/null
> > +++ b/include/fwu.h
> > @@ -0,0 +1,28 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Copyright (c) 2021, Linaro Limited
> > + */
> > +
> > +#if !defined _FWU_H_
> > +#define _FWU_H_
> > +
> > +#include
> > +
> > +#include
> > +
> > +#define FWU_MDATA_VERSION 0x1
> > +
> > +#define FWU_MDATA_GUID \
> > + EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \
> > +0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23)
> > +
> > +int fwu_get_active_index(u32 *active_idx);
> > +int fwu_update_active_index(u32 active_idx);
> > +int fwu_get_image_alt_num(efi_guid_t image_type_id, u32 update_bank,
> > + int *alt_num);
> > +int fwu_mdata_check(void);
> > +int fwu_revert_boot_index(void);
> > +int fwu_accept_image(efi_guid_t *img_type_id);
> > +int fwu_clear_accept_image(efi_guid_t *img_type_id, u32 bank);
> > +
> > +#endif /* _FWU_H_ */
> > diff --git a/include/fwu_mdata.h b/include/fwu_mdata.h
> > new file mode 100644
> > index 00..11eb570012
> > --- /dev/null
> > +++ b/include/fwu_mdata.h
> > @@ -0,0 +1,102 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Copyright (c) 2021, Linaro Limited
> > + */
> > +
> > +#if !defined _FWU_MDATA_H_
> > +#define _FWU_MDATA_H_
> > +
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +/**
> > + * struct fwu_image_bank_info - firmware image information
> > + * @image_uuid: Guid value of the image in this bank
> > + * @accepted: Acceptance status of the image
> > + * @reserved: Reserved
> > + *
> > + * The structure contains image specific fields which are
> > + * used to identify the image and to specify the image's
> > + * acceptance status
> > + */
> > +struct fwu_image_bank_info {
> > + efi_guid_t image_uuid;
> > + u32 accepted;
> > + u32 reserved;
> > +};
>
> Could you explicitly pack these metadata data structures?
> Since these metadata will be shared among bootloaders (TF-A, SCP-firmware),
> it is better to ensure that those are packed and fixed offset for each
> field.
>
Okay. WIll do it.
>
> > +
> > +/**
> > + * struct fwu_image_entry - information for a particular type of image
> > + * @image_type_uuid: Guid value for identifying the image type
> > + * @location_uuid: Guid of the storage volume where the image is located
> > + * @img_bank_info: Array containing properties of images
> > + *
> > + * This structure contains information on various types of updatable
> > + * firmware images. Each image type then contains an array of image
> > + * information per bank.
> > + */
> > +struct fwu_image_entry {
> > + efi_guid_t image_type_uuid;
> > + efi_guid_t location_uuid;
> > + struct fwu_image_bank_info img_bank_info[CONFIG_FWU_NUM_BANKS];
> > +};
> > +
> > +/**
> > + * struct fwu_mdata - FWU metadata structure for multi-bank updates
> > + * @crc32: crc32 value for the FWU metadata
> > + * @version: FWU metadata version
> > + * @active_index: Index of the bank currently used for booting images
> > + * @previous_active_inde: Index of the bank used before the current bank
> > + *being used for booting
> > + * @img_entry: Array of information on various firmware images that can
> > + * be updated
> > + *
> > + * This structure is used to store all the needed information for
> performing
> > + * multi bank updates on the platform. This contains info on the bank
> being
> > + * used to boot along with the information needed for identification of
> > + * individual images
> > + */
> > +struct fwu_mdata {
> > + u32 crc32;
> > + u32 version;
> > + u32 active_index;
> > + u32 previous_active_index;
> > +
> > + struct
Re: [RFC PATCH v2 1/8] FWU: Add FWU metadata structure and functions for accessing metadata
On Tue, Dec 21, 2021 at 10:05:57AM +0530, Sughosh Ganu wrote:
> hi Masami,
>
> On Tue, 21 Dec 2021 at 05:40, Masami Hiramatsu
> wrote:
>
> > Hi Sughosh,
> >
> > 2021年12月19日(日) 16:06 Sughosh Ganu :
> > >
> > > In the FWU Multi Bank Update feature, the information about the
> > > updatable images is stored as part of the metadata, which is stored on
> > > a dedicated partition. Add the metadata structure, and functions to
> > > access the metadata. These are generic API's, and implementations can
> > > be added based on parameters like how the metadata partition is
> > > accessed and what type of storage device houses the metadata.
> > >
> > > Signed-off-by: Sughosh Ganu
> > > ---
> > > Changes since V1:
> > > * Move all function declarations to a separate header fwu.h
> > > * Rename metadata with mdata for all symbols
> > > * Drop the parameter in the function fwu_revert_boot_index
> > > as suggested by Etienne
> > >
> > > include/fwu.h | 28 +
> > > include/fwu_mdata.h | 102
> > > lib/fwu_updates/fwu_mdata.c | 236
> > > 3 files changed, 366 insertions(+)
> > > create mode 100644 include/fwu.h
> > > create mode 100644 include/fwu_mdata.h
> > > create mode 100644 lib/fwu_updates/fwu_mdata.c
> > >
> > > diff --git a/include/fwu.h b/include/fwu.h
> > > new file mode 100644
> > > index 00..e6bc3e6b73
> > > --- /dev/null
> > > +++ b/include/fwu.h
> > > @@ -0,0 +1,28 @@
> > > +/* SPDX-License-Identifier: GPL-2.0+ */
> > > +/*
> > > + * Copyright (c) 2021, Linaro Limited
> > > + */
> > > +
> > > +#if !defined _FWU_H_
> > > +#define _FWU_H_
> > > +
> > > +#include
> > > +
> > > +#include
> > > +
> > > +#define FWU_MDATA_VERSION 0x1
> > > +
> > > +#define FWU_MDATA_GUID \
> > > + EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \
> > > +0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23)
> > > +
> > > +int fwu_get_active_index(u32 *active_idx);
> > > +int fwu_update_active_index(u32 active_idx);
> > > +int fwu_get_image_alt_num(efi_guid_t image_type_id, u32 update_bank,
> > > + int *alt_num);
> > > +int fwu_mdata_check(void);
> > > +int fwu_revert_boot_index(void);
> > > +int fwu_accept_image(efi_guid_t *img_type_id);
> > > +int fwu_clear_accept_image(efi_guid_t *img_type_id, u32 bank);
> > > +
> > > +#endif /* _FWU_H_ */
> > > diff --git a/include/fwu_mdata.h b/include/fwu_mdata.h
> > > new file mode 100644
> > > index 00..11eb570012
> > > --- /dev/null
> > > +++ b/include/fwu_mdata.h
> > > @@ -0,0 +1,102 @@
> > > +/* SPDX-License-Identifier: GPL-2.0+ */
> > > +/*
> > > + * Copyright (c) 2021, Linaro Limited
> > > + */
> > > +
> > > +#if !defined _FWU_MDATA_H_
> > > +#define _FWU_MDATA_H_
> > > +
> > > +#include
> > > +#include
> > > +
> > > +#include
> > > +
> > > +/**
> > > + * struct fwu_image_bank_info - firmware image information
> > > + * @image_uuid: Guid value of the image in this bank
> > > + * @accepted: Acceptance status of the image
> > > + * @reserved: Reserved
> > > + *
> > > + * The structure contains image specific fields which are
> > > + * used to identify the image and to specify the image's
> > > + * acceptance status
> > > + */
> > > +struct fwu_image_bank_info {
> > > + efi_guid_t image_uuid;
> > > + u32 accepted;
> > > + u32 reserved;
> > > +};
> >
> > Could you explicitly pack these metadata data structures?
> > Since these metadata will be shared among bootloaders (TF-A, SCP-firmware),
> > it is better to ensure that those are packed and fixed offset for each
> > field.
> >
>
> Okay. WIll do it.
>
>
> >
> > > +
> > > +/**
> > > + * struct fwu_image_entry - information for a particular type of image
> > > + * @image_type_uuid: Guid value for identifying the image type
> > > + * @location_uuid: Guid of the storage volume where the image is located
> > > + * @img_bank_info: Array containing properties of images
> > > + *
> > > + * This structure contains information on various types of updatable
> > > + * firmware images. Each image type then contains an array of image
> > > + * information per bank.
> > > + */
> > > +struct fwu_image_entry {
> > > + efi_guid_t image_type_uuid;
> > > + efi_guid_t location_uuid;
> > > + struct fwu_image_bank_info img_bank_info[CONFIG_FWU_NUM_BANKS];
> > > +};
> > > +
> > > +/**
> > > + * struct fwu_mdata - FWU metadata structure for multi-bank updates
> > > + * @crc32: crc32 value for the FWU metadata
> > > + * @version: FWU metadata version
> > > + * @active_index: Index of the bank currently used for booting images
> > > + * @previous_active_inde: Index of the bank used before the current bank
> > > + *being used for booting
> > > + * @img_entry: Array of information on various firmware images that can
> > > + * be updated
> > > + *
> > > + * This structure is used to store all the needed information for
> > performing
> > > + * multi
Re: [RFC PATCH v2 5/8] EFI: FMP: Add provision to update image's ImageTypeId in image descriptor
hi Takahiro,
On Tue, 21 Dec 2021 at 10:23, AKASHI Takahiro
wrote:
> Sughosh,
>
> On Sun, Dec 19, 2021 at 12:36:02PM +0530, Sughosh Ganu wrote:
> > The FWU Multi Banks Update feature allows updating different types of
> > updatable firmware images on the platform. These image types are
> > identified using the ImageTypeId GUID value. Add support in the
> > GetImageInfo function of the FMP protocol to get the GUID values for
> > the individual images and populate these in the image descriptor for
> > the corresponding images.
> >
> > Signed-off-by: Sughosh Ganu
> > ---
> > Changes since V1:
> > * Define a new function fwu_plat_get_alt_num for filling up
> > all the dfu partitions with a preset ImageTypeId guid
> > * Remove the distinction made in the earlier version for
> > setting image_type_id as suggested by Heinrich
> >
> > lib/efi_loader/efi_firmware.c | 90 ---
> > 1 file changed, 83 insertions(+), 7 deletions(-)
> >
> > diff --git a/lib/efi_loader/efi_firmware.c
> b/lib/efi_loader/efi_firmware.c
> > index a1b88dbfc2..648342ae72 100644
> > --- a/lib/efi_loader/efi_firmware.c
> > +++ b/lib/efi_loader/efi_firmware.c
> > @@ -10,6 +10,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -96,6 +97,46 @@ efi_status_t EFIAPI
> efi_firmware_set_package_info_unsupported(
> > return EFI_EXIT(EFI_UNSUPPORTED);
> > }
> >
> > +static efi_status_t fill_part_guid_array(const efi_guid_t *guid,
> > + efi_guid_t **part_guid_arr)
> > +{
> > + int i;
> > + int dfu_num = 0;
> > + efi_guid_t *guid_arr;
> > + struct dfu_entity *dfu;
> > + efi_status_t ret = EFI_SUCCESS;
> > +
> > + dfu_init_env_entities(NULL, NULL);
> > +
> > + dfu_num = 0;
> > + list_for_each_entry(dfu, _list, list) {
> > + dfu_num++;
> > + }
> > +
> > + if (!dfu_num) {
> > + log_warning("Probably dfu_alt_info not defined\n");
> > + ret = EFI_NOT_READY;
> > + goto out;
> > + }
> > +
> > + *part_guid_arr = malloc(sizeof(efi_guid_t) * dfu_num);
> > + if (!*part_guid_arr) {
> > + ret = EFI_OUT_OF_RESOURCES;
> > + goto out;
> > + }
> > +
> > + guid_arr = *part_guid_arr;
> > + for (i = 0; i < dfu_num; i++) {
> > + guidcpy(guid_arr, guid);
> > + ++guid_arr;
> > + }
> > +
> > +out:
> > + dfu_free_entities();
> > +
> > + return ret;
> > +}
> > +
> > /**
> > * efi_get_dfu_info - return information about the current firmware
> image
> > * @this:Protocol instance
> > @@ -104,9 +145,9 @@ efi_status_t EFIAPI
> efi_firmware_set_package_info_unsupported(
> > * @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
> > - * image_type: Image type GUID
> > + * @package_version: Package version
> > + * @package_version_name:Package version's name
> > + * @guid_array: Image type GUID array
>
> If I understand your code correctly, a guid in descriptor for any image
> (I mean any part defined by dfu_alto_info) will have the same value
> even with this change.
> If so, why do we have to take an array of GUIDs as a parameter?
>
One of Heinrich's comments in my previous version was not to distinguish
between the FWU case and the normal case when setting the image_type_id.
The existing code sets the same GUID value(image_type) for all images. I
have kept this consistent. With the FWU feature enabled,
fwu_plat_fill_partition_guids is called and this function fills in the
array with the relevant values of partition GUIDs.
fwu_plat_fill_partition_guids has been defined for the ST board in patch
3/8.
> On your previous version, Heinrich made a comment like:
>
> ! The sequence of GUIDs in a capsule should not influence the update. The
> ! design lacks a configuration defining which GUID maps to which DFU part.
> !
> ! Please, get rid of all DFU environment variables and describe the update
> ! in a configuration file that you add to the capsule.
>
> Have you addressed this issue in this series?
> (To do that, we may have to introduce a new format of capsule file.)
>
No, Ilias and I had replied back that detaching capsule update from DFU is
a separate effort, not related to the addition of the FWU functionality and
should be taken up as a separate activity.
-sughosh
>
> -Takahiro Akashi
>
>
>
> > *
> > * Return information bout the current firmware image in @image_info.
> > * @image_info will consist of a number of descriptors.
> > @@ -122,7 +163,7 @@ static efi_status_t efi_get_dfu_info(
> > efi_uintn_t *descriptor_size,
> > u32
Re: [RFC PATCH v2 1/8] FWU: Add FWU metadata structure and functions for accessing metadata
hi Masami,
On Tue, 21 Dec 2021 at 11:31, Masami Hiramatsu
wrote:
> Hi Sughosh,
>
>
> 2021年12月21日(火) 14:47 Sughosh Ganu :
> >
> >
> > On Tue, 21 Dec 2021 at 10:33, AKASHI Takahiro <
> takahiro.aka...@linaro.org> wrote:
> >>
> >> On Tue, Dec 21, 2021 at 10:05:57AM +0530, Sughosh Ganu wrote:
> >> > hi Masami,
> >> >
> >> > On Tue, 21 Dec 2021 at 05:40, Masami Hiramatsu <
> masami.hirama...@linaro.org>
> >> > wrote:
> >> >
> >> > > Hi Sughosh,
> >> > >
> >> > > 2021年12月19日(日) 16:06 Sughosh Ganu :
> >> > > >
> >> > > > In the FWU Multi Bank Update feature, the information about the
> >> > > > updatable images is stored as part of the metadata, which is
> stored on
> >> > > > a dedicated partition. Add the metadata structure, and functions
> to
> >> > > > access the metadata. These are generic API's, and implementations
> can
> >> > > > be added based on parameters like how the metadata partition is
> >> > > > accessed and what type of storage device houses the metadata.
> >> > > >
> >> > > > Signed-off-by: Sughosh Ganu
> >> > > > ---
> >> > > > Changes since V1:
> >> > > > * Move all function declarations to a separate header fwu.h
> >> > > > * Rename metadata with mdata for all symbols
> >> > > > * Drop the parameter in the function fwu_revert_boot_index
> >> > > > as suggested by Etienne
> >> > > >
> >> > > > include/fwu.h | 28 +
> >> > > > include/fwu_mdata.h | 102
> >> > > > lib/fwu_updates/fwu_mdata.c | 236
>
> >> > > > 3 files changed, 366 insertions(+)
> >> > > > create mode 100644 include/fwu.h
> >> > > > create mode 100644 include/fwu_mdata.h
> >> > > > create mode 100644 lib/fwu_updates/fwu_mdata.c
> >> > > >
> >> > > > diff --git a/include/fwu.h b/include/fwu.h
> >> > > > new file mode 100644
> >> > > > index 00..e6bc3e6b73
> >> > > > --- /dev/null
> >> > > > +++ b/include/fwu.h
> >> > > > @@ -0,0 +1,28 @@
> >> > > > +/* SPDX-License-Identifier: GPL-2.0+ */
> >> > > > +/*
> >> > > > + * Copyright (c) 2021, Linaro Limited
> >> > > > + */
> >> > > > +
> >> > > > +#if !defined _FWU_H_
> >> > > > +#define _FWU_H_
> >> > > > +
> >> > > > +#include
> >> > > > +
> >> > > > +#include
> >> > > > +
> >> > > > +#define FWU_MDATA_VERSION 0x1
> >> > > > +
> >> > > > +#define FWU_MDATA_GUID \
> >> > > > + EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \
> >> > > > +0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23)
> >> > > > +
> >> > > > +int fwu_get_active_index(u32 *active_idx);
> >> > > > +int fwu_update_active_index(u32 active_idx);
> >> > > > +int fwu_get_image_alt_num(efi_guid_t image_type_id, u32
> update_bank,
> >> > > > + int *alt_num);
> >> > > > +int fwu_mdata_check(void);
> >> > > > +int fwu_revert_boot_index(void);
> >> > > > +int fwu_accept_image(efi_guid_t *img_type_id);
> >> > > > +int fwu_clear_accept_image(efi_guid_t *img_type_id, u32 bank);
> >> > > > +
> >> > > > +#endif /* _FWU_H_ */
> >> > > > diff --git a/include/fwu_mdata.h b/include/fwu_mdata.h
> >> > > > new file mode 100644
> >> > > > index 00..11eb570012
> >> > > > --- /dev/null
> >> > > > +++ b/include/fwu_mdata.h
> >> > > > @@ -0,0 +1,102 @@
> >> > > > +/* SPDX-License-Identifier: GPL-2.0+ */
> >> > > > +/*
> >> > > > + * Copyright (c) 2021, Linaro Limited
> >> > > > + */
> >> > > > +
> >> > > > +#if !defined _FWU_MDATA_H_
> >> > > > +#define _FWU_MDATA_H_
> >> > > > +
> >> > > > +#include
> >> > > > +#include
> >> > > > +
> >> > > > +#include
> >> > > > +
> >> > > > +/**
> >> > > > + * struct fwu_image_bank_info - firmware image information
> >> > > > + * @image_uuid: Guid value of the image in this bank
> >> > > > + * @accepted: Acceptance status of the image
> >> > > > + * @reserved: Reserved
> >> > > > + *
> >> > > > + * The structure contains image specific fields which are
> >> > > > + * used to identify the image and to specify the image's
> >> > > > + * acceptance status
> >> > > > + */
> >> > > > +struct fwu_image_bank_info {
> >> > > > + efi_guid_t image_uuid;
> >> > > > + u32 accepted;
> >> > > > + u32 reserved;
> >> > > > +};
> >> > >
> >> > > Could you explicitly pack these metadata data structures?
> >> > > Since these metadata will be shared among bootloaders (TF-A,
> SCP-firmware),
> >> > > it is better to ensure that those are packed and fixed offset for
> each
> >> > > field.
> >> > >
> >> >
> >> > Okay. WIll do it.
> >> >
> >> >
> >> > >
> >> > > > +
> >> > > > +/**
> >> > > > + * struct fwu_image_entry - information for a particular type of
> image
> >> > > > + * @image_type_uuid: Guid value for identifying the image type
> >> > > > + * @location_uuid: Guid of the storage volume where the image is
> located
> >> > > > + * @img_bank_info: Array containing properties of images
> >> > > > + *
> >> > > > + * This structure contains information on various types of
> updatable
> >> > > > + * firmware images. Each image type then contains an array of
Re: [RFC PATCH v2 1/8] FWU: Add FWU metadata structure and functions for accessing metadata
On Tue, 21 Dec 2021 at 11:46, AKASHI Takahiro
wrote:
> On Tue, Dec 21, 2021 at 11:17:47AM +0530, Sughosh Ganu wrote:
> > On Tue, 21 Dec 2021 at 10:33, AKASHI Takahiro <
> takahiro.aka...@linaro.org>
> > wrote:
> >
> > > On Tue, Dec 21, 2021 at 10:05:57AM +0530, Sughosh Ganu wrote:
> > > > hi Masami,
> > > >
> > > > On Tue, 21 Dec 2021 at 05:40, Masami Hiramatsu <
> > > masami.hirama...@linaro.org>
> > > > wrote:
> > > >
> > > > > Hi Sughosh,
> > > > >
> > > > > 2021年12月19日(日) 16:06 Sughosh Ganu :
> > > > > >
> > > > > > In the FWU Multi Bank Update feature, the information about the
> > > > > > updatable images is stored as part of the metadata, which is
> stored
> > > on
> > > > > > a dedicated partition. Add the metadata structure, and functions
> to
> > > > > > access the metadata. These are generic API's, and
> implementations can
> > > > > > be added based on parameters like how the metadata partition is
> > > > > > accessed and what type of storage device houses the metadata.
> > > > > >
> > > > > > Signed-off-by: Sughosh Ganu
> > > > > > ---
> > > > > > Changes since V1:
> > > > > > * Move all function declarations to a separate header fwu.h
> > > > > > * Rename metadata with mdata for all symbols
> > > > > > * Drop the parameter in the function fwu_revert_boot_index
> > > > > > as suggested by Etienne
> > > > > >
> > > > > > include/fwu.h | 28 +
> > > > > > include/fwu_mdata.h | 102
> > > > > > lib/fwu_updates/fwu_mdata.c | 236
> > >
> > > > > > 3 files changed, 366 insertions(+)
> > > > > > create mode 100644 include/fwu.h
> > > > > > create mode 100644 include/fwu_mdata.h
> > > > > > create mode 100644 lib/fwu_updates/fwu_mdata.c
> > > > > >
> > > > > > diff --git a/include/fwu.h b/include/fwu.h
> > > > > > new file mode 100644
> > > > > > index 00..e6bc3e6b73
> > > > > > --- /dev/null
> > > > > > +++ b/include/fwu.h
> > > > > > @@ -0,0 +1,28 @@
> > > > > > +/* SPDX-License-Identifier: GPL-2.0+ */
> > > > > > +/*
> > > > > > + * Copyright (c) 2021, Linaro Limited
> > > > > > + */
> > > > > > +
> > > > > > +#if !defined _FWU_H_
> > > > > > +#define _FWU_H_
> > > > > > +
> > > > > > +#include
> > > > > > +
> > > > > > +#include
> > > > > > +
> > > > > > +#define FWU_MDATA_VERSION 0x1
> > > > > > +
> > > > > > +#define FWU_MDATA_GUID \
> > > > > > + EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \
> > > > > > +0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23)
> > > > > > +
> > > > > > +int fwu_get_active_index(u32 *active_idx);
> > > > > > +int fwu_update_active_index(u32 active_idx);
> > > > > > +int fwu_get_image_alt_num(efi_guid_t image_type_id, u32
> update_bank,
> > > > > > + int *alt_num);
> > > > > > +int fwu_mdata_check(void);
> > > > > > +int fwu_revert_boot_index(void);
> > > > > > +int fwu_accept_image(efi_guid_t *img_type_id);
> > > > > > +int fwu_clear_accept_image(efi_guid_t *img_type_id, u32 bank);
> > > > > > +
> > > > > > +#endif /* _FWU_H_ */
> > > > > > diff --git a/include/fwu_mdata.h b/include/fwu_mdata.h
> > > > > > new file mode 100644
> > > > > > index 00..11eb570012
> > > > > > --- /dev/null
> > > > > > +++ b/include/fwu_mdata.h
> > > > > > @@ -0,0 +1,102 @@
> > > > > > +/* SPDX-License-Identifier: GPL-2.0+ */
> > > > > > +/*
> > > > > > + * Copyright (c) 2021, Linaro Limited
> > > > > > + */
> > > > > > +
> > > > > > +#if !defined _FWU_MDATA_H_
> > > > > > +#define _FWU_MDATA_H_
> > > > > > +
> > > > > > +#include
> > > > > > +#include
> > > > > > +
> > > > > > +#include
> > > > > > +
> > > > > > +/**
> > > > > > + * struct fwu_image_bank_info - firmware image information
> > > > > > + * @image_uuid: Guid value of the image in this bank
> > > > > > + * @accepted: Acceptance status of the image
> > > > > > + * @reserved: Reserved
> > > > > > + *
> > > > > > + * The structure contains image specific fields which are
> > > > > > + * used to identify the image and to specify the image's
> > > > > > + * acceptance status
> > > > > > + */
> > > > > > +struct fwu_image_bank_info {
> > > > > > + efi_guid_t image_uuid;
> > > > > > + u32 accepted;
> > > > > > + u32 reserved;
> > > > > > +};
> > > > >
> > > > > Could you explicitly pack these metadata data structures?
> > > > > Since these metadata will be shared among bootloaders (TF-A,
> > > SCP-firmware),
> > > > > it is better to ensure that those are packed and fixed offset for
> each
> > > > > field.
> > > > >
> > > >
> > > > Okay. WIll do it.
> > > >
> > > >
> > > > >
> > > > > > +
> > > > > > +/**
> > > > > > + * struct fwu_image_entry - information for a particular type of
> > > image
> > > > > > + * @image_type_uuid: Guid value for identifying the image type
> > > > > > + * @location_uuid: Guid of the storage volume where the image is
> > > located
> > > > > > + * @img_bank_info: Array containing properties of images
> > > > > > + *
> > > > > > + * This
'bmp display' convert 24bit bmp to 16bit lcd format
Hi: I had tested 'bmp display' command with 24bits bmp picture, **video_bmp_display** function always convert 24bits picture to RGB555 format if the lcd is 16bits. But most of all lcd controller is RGB565 format. Should we improve this? Thanks
[PATCH] BRCMNAND: Fix reporting of uncorrectable errors on subpages during page read
Previously, a subpage with an uncorrectable error followed by a subpage
with a correctable error would return an erroneous correctable status.
Signed-off-by: Joel Peshkin
Cc: Simon Glass
---
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
index f8434ca..74c9348 100644
--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
@@ -1632,7 +1632,7 @@ static int brcmnand_read_by_pio(struct mtd_info *mtd,
struct nand_chip *chip,
mtd->oobsize / trans,
host->hwcfg.sector_size_1k);
- if (!ret) {
+ if (ret != -EBADMSG) {
*err_addr = brcmnand_read_reg(ctrl,
BRCMNAND_UNCORR_ADDR) |
((u64)(brcmnand_read_reg(ctrl,
--
1.8.3.1
Re: efi bootmenu
Hi Takahiro, On Tue, 21 Dec 2021 at 11:47, Takahiro Akashi wrote: > > On Mon, Dec 20, 2021 at 06:25:05PM +0900, Masahisa Kojima wrote: > > Hi Heinrich, Ilias, Akashi-san, > > > > Ilias and I are now discussing to create efi bootmenu, almost similar > > to UiApp in EDK2. > > Why not discuss this topic openly in ML? Yes, I included U-Boot ML.(Sorry, I should include from the the beginning.) > > How is this feature related to Simon's bootmethod proposal? If I correctly understand Simon's bootmethod proposal, the difference is that efi bootmenu only targets to implement the menu based UI to select/edit/add/delete "Boot" and "BootOrder". > > > Here is some background. > > === > > U-Boot's command line should be completely disabled on secure devices. > > However since U-Boot doesn't (yet) support EFI runtime SetVariable > > for all supported devices, disabling the command line is hard, if even > > possible. > > If we provide a boot menu, with access to very limited functionality, e.g > > select > > a boot option and allow users to add/edit/delete existing options, > > we can enhance security and provide a usable alternative to the users. > > > > In addition, if we can add options for managing EFI keys and enabling > > disabling secure boot, we can completely get rid of the u-boot cmd line, > > greatly enhancing platform security > > Basically, it will be a good idea. > Please keep in mind, however, that add/deleting boot options, > [en|dis]abling secure boot or modifying secure variables should > belong to some sort of privileged operations. > I think that we need to have some mechanism to distinguish them > from other menus. It might be system specific, though. > > > === > > > > I am planning to hook the existing "bootefi bootmgr" boot process. > > In "bootefi bootmgr", the planned process will be as follows. > > 1) check "BootNext" > > What do you mean by "check"? I meant the existing bootmgr implementation. If "BootNext" is specified, system boots with "BootNext". > > > 2) show efi bootmenu (*NEW*) > > 3) if user quits efi bootmenu, then boot in accordance with "BootOrder" > > It means efi bootmenu is native u-boot program. > > > > I would like to hear your opinion how this efi bootmenu should be > > implemented. > > Is it better to implement as EFI application? > > In my personal opinion, we should implement the feature as a separate > EFI application. One of benefits of UEFI interfaces are the ability > to expand functionality with driver modules and applications without > modifying the core. > (One example is iPXE boot that Heinrich often picks up in his comments.) > > If it is an EFI application, it can be easily replaced with others > per system and we may be able to use secure boot to authorise the app > itself. Thank you, I understand the benefit of implementing as EFI App. > > But implementing it as an EFI app is not the goal, and I think you can > start with what you want to do first. > > > Note that I tried to run edk2 UiApp on U-Boot, I found that the > > following protocol > > are required and assertion occurs in DEBUG build. > > gEfiHiiConfigRoutingProtocolGuid > > gEfiHiiFontProtocolGuid > > gEfiHiiImageProtocolGuid > > Probably these protocols can be implemented as dummy stub. > > If I run UiApp in RELEASE build, I encounter exception on UiApp, > > I have not debugged it. > > I didn't investigate this failure in details before, but it might be > related to a (bogus) device path installed into the efi image which > is to be loaded into and invoked from the main memory. > > -Takahiro Akashi > > > Regards, > > Masahisa Kojima Thanks, Masahisa Kojima
Re: [RESEND PATCH] Enable Fastboot(UUU) for O4-iMX6ULL-NANO boards
On Sun, Dec 19, 2021 at 11:47:21PM +0200, Oleh Kravchenko wrote:
> Make O4-iMX6ULL-NANO-based board compatible with Yocto layer meta-out4 and
> fix device flashing by UUU (aka MFG Tools).
>
> Signed-off-by: Oleh Kravchenko
> ---
> arch/arm/dts/o4-imx-nano.dts | 4 ++--
> configs/ev-imx280-nano-x-mb_defconfig | 5 +
> configs/o4-imx6ull-nano_defconfig | 5 +
> 3 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/dts/o4-imx-nano.dts b/arch/arm/dts/o4-imx-nano.dts
> index 54d32f9dd4..8cc3d46997 100644
> --- a/arch/arm/dts/o4-imx-nano.dts
> +++ b/arch/arm/dts/o4-imx-nano.dts
> @@ -29,7 +29,7 @@
> gpios = < 0 GPIO_ACTIVE_LOW>;
> };
>
> - led1{
> + led1 {
> color = ;
> gpios = < 1 GPIO_ACTIVE_LOW>;
> };
> @@ -44,7 +44,7 @@
> gpios = < 3 GPIO_ACTIVE_LOW>;
> };
>
> - led4{
> + led4 {
> color = ;
> gpios = < 4 GPIO_ACTIVE_LOW>;
> };
These dt changes are just whitespace? Are they resyncing with the
upstream dts as well? But, unrelated, changes, yes?
--
Tom
signature.asc
Description: PGP signature
Re: [RESEND PATCH] Enable Fastboot(UUU) for O4-iMX6ULL-NANO boards
On Mon, Dec 20, 2021 at 03:52:21PM +0200, Oleh Kravchenko wrote: > Hello Tom, > > 20.12.21 15:50, Tom Rini пише: > > > > These dt changes are just whitespace? Are they resyncing with the > > upstream dts as well? But, unrelated, changes, yes? > > > > Yes, yes and yes :) OK, please v2 without them, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] phy: Track power-on and init counts in uclass
On 15/12/2021 06:26, Simon Glass wrote:
> On Sat, 11 Dec 2021 at 02:02, Alper Nebi Yasak
> wrote:
>> diff --git a/drivers/phy/phy-uclass.c b/drivers/phy/phy-uclass.c
>> index 59683a080cd7..48b4b24db674 100644
>> --- a/drivers/phy/phy-uclass.c
>> +++ b/drivers/phy/phy-uclass.c
>> @@ -11,12 +11,65 @@
>> #include
>> #include
>> #include
>> +#include
>> +
>> +struct phy_id_priv {
>> + unsigned long id;
>> + int power_on_count;
>> + int init_count;
>> + struct list_head list;
>> +};
>>
>> static inline struct phy_ops *phy_dev_ops(struct udevice *dev)
>> {
>> return (struct phy_ops *)dev->driver->ops;
>> }
>>
>> +static struct phy_id_priv *phy_get_uclass_priv(struct phy *phy)
>
> This name is very confusing as it is similar to one used by DM, but
> does something different.
What I thought is: if we replaced these "struct phy" handles with child
udevices, the counts would be their uclass_priv, and this function would
be just dev_get_uclass_priv() on those child udevices. (Or maybe it
would be parent_priv?). So I tried to pick names similar to those.
> Do you think this function should be split into something that adds
> the data and something that reads it?
I can split and rename things into:
- struct phy_counts
- phy_alloc_counts(struct phy *phy)
- phy_get_counts(struct phy *phy)
>> +{
>> + struct list_head *uc_priv;
>> + struct phy_id_priv *id_priv;
>> +
>> + if (!generic_phy_valid(phy))
>> + return NULL;
>> +
>> + uc_priv = dev_get_uclass_priv(phy->dev);
>> + list_for_each_entry(id_priv, uc_priv, list)
>> + if (id_priv->id == phy->id)
>> + return id_priv;
>> +
>> + id_priv = kzalloc(sizeof(*id_priv), GFP_KERNEL);
>> + if (!id_priv)
>> + return NULL;
>> +
>> + id_priv->id = phy->id;
>> + id_priv->power_on_count = 0;
>> + id_priv->init_count = 0;
>> + list_add(_priv->list, uc_priv);
>> +
>> + return id_priv;
>> +}
Re: Please pull u-boot-marvell/next v2
On Sun, Dec 19, 2021 at 02:41:24PM +0100, Stefan Roese wrote: > Hi Tom, > > please pull the following Marvell MVEBU related patches into next, > this time really against upstream next: > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH u-boot-marvell 00/10] PCI mvebu and aardvark changes
On Saturday 18 December 2021 14:53:52 Stefan Roese wrote: > Hi Pali, > > On 12/16/21 11:28, Pali Rohár wrote: > > On Wednesday 15 December 2021 09:10:50 Stefan Roese wrote: > > > Hi Pali, > > > > > > On 12/13/21 11:27, Pali Rohár wrote: > > > > On Monday 13 December 2021 08:41:30 Stefan Roese wrote: > > > > > Hi Pali, > > > > > > > > > > On 12/12/21 12:23, Pali Rohár wrote: > > > > > > On Thursday 11 November 2021 16:35:39 Marek Behún wrote: > > > > > > > From: Marek Behún > > > > > > > > > > > > > > Hello Stefan, > > > > > > > > > > > > > > we have some more fixes for PCI (mvebu and aardvark), and one > > > > > > > patch > > > > > > > for Turris MOX board code. > > > > > > > > > > > > > > Marek > > > > > > > > > > > > Hello Stefan, patches 1, 2 and 7 still needs some modifications. But > > > > > > other remaining patches should be OK. Would you merge remaining > > > > > > patches? > > > > > > And then we can focus on issues with link initialization. > > > > > > > > > > Sure, I can pull the "remaining patches" into next (for master it's > > > > > too > > > > > late in the release cycle) if this helps. Just let me know and I'll go > > > > > through the patch queue in the next days to push more Marvell related > > > > > patches into next. > > > > > > > > Ok. But please consider applying patches 5, 6 and 9 to master as they > > > > have Fixes tag for commits which are already in master branch. > > > > > > Okay, thanks for the reminder. The Azure world build is running. So I'll > > > send the pull request for these 3 patches most likely later today. > > > > Hello and thank you! Could you include patches prepared for next into > > some branch, so I can prepare new patches on top of that branch to so > > patches would be correctly rebased? > > Done. As you will have noticed, I've pulled a bunch of patches into next > and did send a pull request just a few minutes ago. Perfect! > Please let me know if I forgot something. Once all this lands in Tom's > next branch, this should be a good base for your rebase. Could you include into next branch also other patches from this patch series which you have already reviewed, which are OK? Patches 1, 2 and 7 are those which need modifications and are not ready yet. > Thanks, > Stefan > > > > Thanks, > > > Stefan > > > > > > > > > > > Thanks, > > > > > Stefan > > > > > > > > > > > > Marek Behún (2): > > > > > > > pci: pci_mvebu, pci_aardvark: Fix size of configuration cache > > > > > > > arm: mvebu: turris_mox: Remove extra newline after module > > > > > > > topology > > > > > > > > > > > > > > Pali Rohár (8): > > > > > > > pci: pci_mvebu: Wait 100ms for Link Up in mvebu_pcie_probe() > > > > > > > arm: mvebu: a38x: serdes: Move non-serdes PCIe code to > > > > > > > pci_mvebu.c > > > > > > > pci: pci_mvebu: Move setup for BAR[0] where other BARs are > > > > > > > setup > > > > > > > pci: pci_mvebu: Replace MBUS_PCI_*_SIZE by resource_size() > > > > > > > pci: pci_mvebu: Do not allow setting ROM BAR on PCI Bridge > > > > > > > pci: pci_mvebu: Fix PCIe MEM and IO resources assignment and > > > > > > > mbus > > > > > > >mapping > > > > > > > pci: pci_mvebu: Remove unused DECLARE_GLOBAL_DATA_PTR > > > > > > > arm: a37xx: pci: Do not allow setting ROM BAR on PCI Bridge > > > > > > > > > > > > > > arch/arm/mach-mvebu/include/mach/cpu.h| 4 +- > > > > > > > arch/arm/mach-mvebu/serdes/a38x/ctrl_pex.h| 4 - > > > > > > > .../serdes/a38x/high_speed_env_spec.c | 15 -- > > > > > > > board/CZ.NIC/turris_mox/turris_mox.c | 3 - > > > > > > > drivers/pci/pci-aardvark.c| 54 +++-- > > > > > > > drivers/pci/pci_mvebu.c | 205 > > > > > > > -- > > > > > > > 6 files changed, 175 insertions(+), 110 deletions(-) > > > > > > > > > > > > > > -- > > > > > > > 2.32.0 > > > > > > > > > > > > > > > > > Viele Grüße, > > > > > Stefan Roese > > > > > > > > > > -- > > > > > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > > > > > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > > > > > Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: > > > > > s...@denx.de > > > > > > Viele Grüße, > > > Stefan Roese > > > > > > -- > > > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > > > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > > > Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de > > Viele Grüße, > Stefan Roese > > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2 0/4] rockchip: Improve support for Bob chromebook and add support for Kevin
On 19/12/2021 20:14, Simon Glass wrote: > Thanks for the info. I tested on kevin and bob again, with the eMMC > series. I see an MMC problem on bob but kevin seems to be OK > (intermittent?) I have no idea why you get different results with bob vs kevin. But I can disable the higher-speed configs and send a v3, then try enabling those later after figuring out and fixing whatever's wrong. > U-Boot 2022.01-rc3-8-g144d40cc2f5 (Dec 19 2021 - 08:49:57 -0700) > > Model: Google Bob > DRAM: 3.9 GiB > MMC: mmc@fe32: 1, mmc@fe33: 0 > Loading Environment from MMC... unable to select a mode : -70 > *** Warning - No block device, using default environment So this is -ECOMM with a message from mmc_select_mode_and_width(), probably originating from sdhci_send_command(), but I don't exactly know what calls what in between...
Re: [PATCH 1/6] udoo_spl: Initialize the eSDHC controller in SPL
On Sat, Dec 18, 2021 at 9:10 PM Fabio Estevam wrote:
>
> Currently, imx6q udoo board fails to boot like this:
>
> U-Boot SPL 2022.01-rc3-00061-g95ca715adad3 (Dec 18 2021 - 18:04:40 -0300)
> Trying to boot from MMC1
>
> The reason is that the eSDHC controller is not initialized in SPL.
>
> Initialize the eSDHC controller in SPL via C code as DM is not
> used in SPL.
>
> Signed-off-by: Fabio Estevam
> ---
> board/udoo/udoo_spl.c | 35 +++
> 1 file changed, 35 insertions(+)
>
> diff --git a/board/udoo/udoo_spl.c b/board/udoo/udoo_spl.c
> index d9afbbb74198..754bd9dfe21e 100644
> --- a/board/udoo/udoo_spl.c
> +++ b/board/udoo/udoo_spl.c
> @@ -254,4 +254,39 @@ void board_init_f(ulong dummy)
> /* DDR initialization */
> spl_dram_init();
> }
> +
> +#define USDHC3_CD_GPIO IMX_GPIO_NR(7, 0)
> +
> +#define USDHC_PAD_CTRL (PAD_CTL_PUS_47K_UP | \
> + PAD_CTL_SPEED_LOW | PAD_CTL_DSE_80ohm | \
> + PAD_CTL_SRE_FAST | PAD_CTL_HYS)
> +
> +static struct fsl_esdhc_cfg usdhc_cfg[2] = {
> + {USDHC3_BASE_ADDR},
> +};
> +
> +static const iomux_v3_cfg_t usdhc3_pads[] = {
> + IOMUX_PADS(PAD_SD3_CLK__SD3_CLK| MUX_PAD_CTRL(USDHC_PAD_CTRL)),
> + IOMUX_PADS(PAD_SD3_CMD__SD3_CMD| MUX_PAD_CTRL(USDHC_PAD_CTRL)),
> + IOMUX_PADS(PAD_SD3_DAT0__SD3_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
> + IOMUX_PADS(PAD_SD3_DAT1__SD3_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
> + IOMUX_PADS(PAD_SD3_DAT2__SD3_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
> + IOMUX_PADS(PAD_SD3_DAT3__SD3_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
> + IOMUX_PADS(PAD_SD3_DAT5__GPIO7_IO00 | MUX_PAD_CTRL(NO_PAD_CTRL)),
> +};
> +
> +int board_mmc_getcd(struct mmc *mmc)
> +{
> + return !gpio_get_value(USDHC3_CD_GPIO);
> +}
> +
> +int board_mmc_init(struct bd_info *bis)
> +{
> + SETUP_IOMUX_PADS(usdhc3_pads);
> + usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);
> + usdhc_cfg[0].max_bus_width = 4;
Shouldn't there be a gpio_request here before you set direction like
in your first patch?
> + gpio_direction_input(USDHC3_CD_GPIO);
> +
> + return fsl_esdhc_initialize(bis, _cfg[0]);
> +}
> #endif
Reviewed-by: Peter Robinson
Re: Please pull u-boot-i2c
On Mon, Dec 20, 2021 at 11:14:16AM +0100, Heiko Schocher wrote: > Hello Tom, > > please pull from u-boot-i2c master: > > The following changes since commit d3213c26b56e564207515f1e28e663718e015dc3: > > Merge tag 'efi-2022-01-rc4-3' of > https://source.denx.de/u-boot/custodians/u-boot-efi (2021-12-18 > 14:39:21 -0500) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-i2c.git > tags/20211220-fixes-for-2022.01 > > for you to fetch changes up to ccea46c05b08b34ef829d460e50e2ce9bc17cdc7: > > i2c: mvtwsi: Swab the register address if its size is > 1 (2021-12-20 > 07:57:48 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] fw_setenv: Unbreak fw_setenv caused by buggy MEMISLOCKED use
On Wed, Dec 08, 2021 at 03:33:11PM +0100, Joakim Tjernlund wrote:
> Commit "fw_setenv: lock the flash only if it was locked before"
> checks for Locked status with uninitialized erase data.
> Address by moving the test for MEMISLOCKED.
>
> Fixes: 8a726b852502 ("fw_setenv: lock the flash only if it was locked before")
> Signed-off-by: Joakim Tjernlund
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
[ANN] U-Boot v2022.01-rc4 released
Hey all, I'm late with v2022.01-rc4, but, here it is. The next branch is still open and if people have things ready for there, please send them. In terms of a changelog, git log --merges v2022.01-rc3..v2022.01-rc4 contains what I've pulled but as always, better PR messages and tags will provide better results here. I'm going to o -rc5 on January 3rd and release on January 10th, 2022. Thanks alll! -- Tom signature.asc Description: PGP signature
Re: [PATCH] Revert "image: Remove #ifdefs from select_ramdisk()"
On Mon, Dec 20, 2021 at 09:38:23AM -0500, Tom Rini wrote: > This reverts commit f33a2c1bd0fb371511a485cac1f182ba50db51be. > > This causes a crash on some platforms as seen here: > https://lore.kernel.org/r/f153017b-c41a-0d32-67b9-f288e695f...@baylibre.com/ > > Reported-by: Neil Armstrong > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [RESEND PATCH] Enable Fastboot(UUU) for O4-iMX6ULL-NANO boards
Hello Tom, 20.12.21 15:50, Tom Rini пише: These dt changes are just whitespace? Are they resyncing with the upstream dts as well? But, unrelated, changes, yes? Yes, yes and yes :) -- Best regards, Oleh Kravchenko
[PATCH v2] Enable Fastboot(UUU) for O4-iMX6ULL-NANO boards
Make O4-iMX6ULL-NANO-based board compatible with Yocto layer meta-out4 and fix device flashing by UUU (aka MFG Tools). Signed-off-by: Oleh Kravchenko --- configs/ev-imx280-nano-x-mb_defconfig | 5 + configs/o4-imx6ull-nano_defconfig | 5 + 2 files changed, 10 insertions(+) diff --git a/configs/ev-imx280-nano-x-mb_defconfig b/configs/ev-imx280-nano-x-mb_defconfig index 10f2ec9333..4188286825 100644 --- a/configs/ev-imx280-nano-x-mb_defconfig +++ b/configs/ev-imx280-nano-x-mb_defconfig @@ -49,3 +49,8 @@ CONFIG_USB=y CONFIG_USB_GADGET=y CONFIG_CI_UDC=y CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_FASTBOOT_MMC_BOOT_SUPPORT=y +CONFIG_FASTBOOT_MMC_USER_SUPPORT=y +CONFIG_FASTBOOT_UUU_SUPPORT=y +CONFIG_USB_GADGET_PRODUCT_NUM=0x0001 +CONFIG_USB_GADGET_VENDOR_NUM=0x3016 diff --git a/configs/o4-imx6ull-nano_defconfig b/configs/o4-imx6ull-nano_defconfig index 384e6826a7..e8071cb791 100644 --- a/configs/o4-imx6ull-nano_defconfig +++ b/configs/o4-imx6ull-nano_defconfig @@ -57,3 +57,8 @@ CONFIG_USB=y CONFIG_USB_GADGET=y CONFIG_CI_UDC=y CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_FASTBOOT_MMC_BOOT_SUPPORT=y +CONFIG_FASTBOOT_MMC_USER_SUPPORT=y +CONFIG_FASTBOOT_UUU_SUPPORT=y +CONFIG_USB_GADGET_PRODUCT_NUM=0x0001 +CONFIG_USB_GADGET_VENDOR_NUM=0x3016 -- 2.32.0
[PATCH] Revert "image: Remove #ifdefs from select_ramdisk()"
This reverts commit f33a2c1bd0fb371511a485cac1f182ba50db51be.
This causes a crash on some platforms as seen here:
https://lore.kernel.org/r/f153017b-c41a-0d32-67b9-f288e695f...@baylibre.com/
Reported-by: Neil Armstrong
Signed-off-by: Tom Rini
---
boot/image-board.c | 139 ++---
1 file changed, 67 insertions(+), 72 deletions(-)
diff --git a/boot/image-board.c b/boot/image-board.c
index bf8817165cab..251885c9038d 100644
--- a/boot/image-board.c
+++ b/boot/image-board.c
@@ -27,6 +27,7 @@
DECLARE_GLOBAL_DATA_PTR;
+#if CONFIG_IS_ENABLED(LEGACY_IMAGE_FORMAT)
/**
* image_get_ramdisk - get and verify ramdisk image
* @rd_addr: ramdisk image start address
@@ -85,6 +86,7 @@ static const image_header_t *image_get_ramdisk(ulong rd_addr,
u8 arch,
return rd_hdr;
}
+#endif
/*/
/* Shared dual-format routines */
@@ -325,18 +327,16 @@ int genimg_has_config(bootm_headers_t *images)
static int select_ramdisk(bootm_headers_t *images, const char *select, u8 arch,
ulong *rd_datap, ulong *rd_lenp)
{
- ulong rd_addr = 0;
+ ulong rd_addr;
char *buf;
- const char *fit_uname_config = images->fit_uname_cfg;
- const char *fit_uname_ramdisk = NULL;
- bool processed;
- int rd_noffset;
- if (select) {
- ulong default_addr;
- bool done = true;
+#if CONFIG_IS_ENABLED(FIT)
+ const char *fit_uname_config = images->fit_uname_cfg;
+ const char *fit_uname_ramdisk = NULL;
+ int rd_noffset;
- if (CONFIG_IS_ENABLED(FIT)) {
+ if (select) {
+ ulong default_addr;
/*
* If the init ramdisk comes from the FIT image and
* the FIT image address is omitted in the command
@@ -348,8 +348,8 @@ static int select_ramdisk(bootm_headers_t *images, const
char *select, u8 arch,
else
default_addr = image_load_addr;
- if (fit_parse_conf(select, default_addr, _addr,
- _uname_config)) {
+ if (fit_parse_conf(select, default_addr,
+ _addr, _uname_config)) {
debug("* ramdisk: config '%s' from image at
0x%08lx\n",
fit_uname_config, rd_addr);
} else if (fit_parse_subimage(select, default_addr,
@@ -357,58 +357,60 @@ static int select_ramdisk(bootm_headers_t *images, const
char *select, u8 arch,
_uname_ramdisk)) {
debug("* ramdisk: subimage '%s' from image at
0x%08lx\n",
fit_uname_ramdisk, rd_addr);
- } else {
- done = false;
+ } else
+#endif
+ {
+ rd_addr = hextoul(select, NULL);
+ debug("* ramdisk: cmdline image address =
0x%08lx\n",
+ rd_addr);
}
+#if CONFIG_IS_ENABLED(FIT)
+ } else {
+ /* use FIT configuration provided in first bootm
+* command argument. If the property is not defined,
+* quit silently (with -ENOPKG)
+*/
+ rd_addr = map_to_sysmem(images->fit_hdr_os);
+ rd_noffset = fit_get_node_from_config(images,
+ FIT_RAMDISK_PROP,
+ rd_addr);
+ if (rd_noffset == -ENOENT)
+ return -ENOPKG;
+ else if (rd_noffset < 0)
+ return rd_noffset;
}
- if (!done) {
- rd_addr = hextoul(select, NULL);
- debug("* ramdisk: cmdline image address = 0x%08lx\n",
- rd_addr);
- }
- } else if (CONFIG_IS_ENABLED(FIT)) {
- /* use FIT configuration provided in first bootm
-* command argument. If the property is not defined,
-* quit silently (with -ENOPKG )
-*/
- rd_addr = map_to_sysmem(images->fit_hdr_os);
- rd_noffset = fit_get_node_from_config(images, FIT_RAMDISK_PROP,
- rd_addr);
- if (rd_noffset == -ENOENT)
- return -ENOPKG;
- else if (rd_noffset < 0)
- return
Re: [RFC PATCH v2 7/8] FWU: Add support for FWU Multi Bank Update feature
On Mon, Dec 20, 2021 at 10:13:35PM +0900, Masami Hiramatsu wrote: > Hi Sughosh, > > 2021年12月20日(月) 18:48 Sughosh Ganu : > > > > > > On Mon, 20 Dec 2021 at 11:44, AKASHI Takahiro > > wrote: > >> > >> On Sun, Dec 19, 2021 at 12:36:04PM +0530, Sughosh Ganu wrote: > >> > The FWU Multi Bank Update feature supports updation of firmware images > >> > to one of multiple sets(also called banks) of images. The firmware > >> > images are clubbed together in banks, with the system booting images > >> > from the active bank. Information on the images such as which bank > >> > they belong to is stored as part of the metadata structure, which is > >> > stored on the same storage media as the firmware images on a dedicated > >> > partition. > >> > > >> > At the time of update, the metadata is read to identify the bank to > >> > which the images need to be flashed(update bank). On a successful > >> > update, the metadata is modified to set the updated bank as active > >> > bank to subsequently boot from. > >> > > >> > Signed-off-by: Sughosh Ganu > >> > --- > >> > Changes since V1: > >> > * Call function fwu_update_checks_pass to check if the > >> > update can be initiated > >> > * Do not allow firmware update from efi_init_obj_list as the > >> > fwu boot-time checks need to be run > >> > > >> > include/fwu.h| 18 +++- > >> > lib/Kconfig | 32 ++ > >> > lib/Makefile | 1 + > >> > lib/efi_loader/efi_capsule.c | 198 ++- > >> > lib/efi_loader/efi_setup.c | 3 +- > >> > lib/fwu_updates/Makefile | 11 ++ > >> > lib/fwu_updates/fwu.c| 27 + > >> > 7 files changed, 284 insertions(+), 6 deletions(-) > >> > create mode 100644 lib/fwu_updates/Makefile > >> > > >> > diff --git a/include/fwu.h b/include/fwu.h > >> > index 2d2e674d6a..bf50fe9277 100644 > >> > --- a/include/fwu.h > >> > +++ b/include/fwu.h > >> > @@ -10,14 +10,28 @@ > >> > > >> > #include > >> > > >> > -#define FWU_MDATA_VERSION0x1 > >> > +#define FWU_MDATA_GUID \ > >> > + EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \ > >> > + 0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23) > >> > + > >> > +#define FWU_OS_REQUEST_FW_REVERT_GUID \ > >> > + EFI_GUID(0xacd58b4b, 0xc0e8, 0x475f, 0x99, 0xb5, \ > >> > + 0x6b, 0x3f, 0x7e, 0x07, 0xaa, 0xf0) > >> > + > >> > +#define FWU_OS_REQUEST_FW_ACCEPT_GUID \ > >> > + EFI_GUID(0x0c996046, 0xbcc0, 0x4d04, 0x85, 0xec, \ > >> > + 0xe1, 0xfc, 0xed, 0xf1, 0xc6, 0xf8) > >> > > >> > #define FWU_MDATA_GUID \ > >> > EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \ > >> >0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23) > >> > > >> > -int fwu_boottime_checks(void); > >> > +#define FWU_MDATA_VERSION0x1 > >> > +#define FWU_IMAGE_ACCEPTED 0x1 > >> > + > >> > u8 fwu_update_checks_pass(void); > >> > +int fwu_boottime_checks(void); > >> > +int fwu_trial_state_ctr_start(void); > >> > > >> > int fwu_get_active_index(u32 *active_idx); > >> > int fwu_update_active_index(u32 active_idx); > >> > diff --git a/lib/Kconfig b/lib/Kconfig > >> > index 807a4c6ade..7cb306317c 100644 > >> > --- a/lib/Kconfig > >> > +++ b/lib/Kconfig > >> > @@ -835,3 +835,35 @@ config PHANDLE_CHECK_SEQ > >> > When there are multiple device tree nodes with same name, > >> >enable this config option to distinguish them using > >> > phandles in fdtdec_get_alias_seq() function. > >> > + > >> > +config FWU_MULTI_BANK_UPDATE > >> > + bool "Enable FWU Multi Bank Update Feature" > >> > + depends on EFI_HAVE_CAPSULE_SUPPORT > >> > + select PARTITION_TYPE_GUID > >> > + select EFI_SETUP_EARLY > >> > + help > >> > + Feature for updating firmware images on platforms having > >> > + multiple banks(copies) of the firmware images. One of the > >> > + bank is selected for updating all the firmware components > >> > + > >> > +config FWU_NUM_BANKS > >> > + int "Number of Banks defined by the platform" > >> > + depends on FWU_MULTI_BANK_UPDATE > >> > + help > >> > + Define the number of banks of firmware images on a platform > >> > + > >> > +config FWU_NUM_IMAGES_PER_BANK > >> > + int "Number of firmware images per bank" > >> > + depends on FWU_MULTI_BANK_UPDATE > >> > + help > >> > + Define the number of firmware images per bank. This value > >> > + should be the same for all the banks. > >> > + > >> > +config FWU_TRIAL_STATE_CNT > >> > + int "Number of times system boots in Trial State" > >> > + depends on FWU_MULTI_BANK_UPDATE > >> > + default 3 > >> > + help > >> > + With FWU Multi Bank Update feature enabled, number of times > >> > + the platform is allowed to boot in Trial State after an > >> > + update. > >> > diff --git a/lib/Makefile b/lib/Makefile > >> > index 5ddbc77ed6..bc5c1e22fc 100644 > >> > --- a/lib/Makefile > >> > +++ b/lib/Makefile > >> > @@ -9,6 +9,7 @@
Re: [PATCH 3/6] udoo: Call gpio_request()
On Sat, Dec 18, 2021 at 9:10 PM Fabio Estevam wrote:
>
> Calling gpio_request() prior to its usage is now mandatory.
>
> This fixes the following GPIO errors:
>
> U-Boot SPL 2022.01-rc3-00067-g7a5be871c0ec (Dec 18 2021 - 17:45:07 -0300)
> Trying to boot from MMC1
>
>
> U-Boot 2022.01-rc3-00067-g7a5be871c0ec (Dec 18 2021 - 17:45:07 -0300)
>
> CPU: Freescale i.MX6Q rev1.2 at 792 MHz
> Reset cause: WDOG
> Model: Udoo i.MX6 Quad Board
> Board: Udoo Quad
> DRAM: 1 GiB
> MMC: FSL_SDHC: 2
> Loading Environment from MMC... OK
> In:serial
> Out: serial
> Err: serial
> gpio@20a: set_dir_flags: error: gpio GPIO2_31 not reserved
> gpio@20a4000: set_dir_flags: error: gpio GPIO3_23 not reserved
> gpio@20b: set_dir_flags: error: gpio GPIO6_24 not reserved
> gpio@20b: set_dir_flags: error: gpio GPIO6_25 not reserved
> gpio@20b: set_dir_flags: error: gpio GPIO6_27 not reserved
> gpio@20b: set_dir_flags: error: gpio GPIO6_28 not reserved
> gpio@20b: set_dir_flags: error: gpio GPIO6_29 not reserved
> gpio@20a4000: set_value: error: gpio GPIO3_23 not reserved
> Net: Could not get PHY for FEC0: addr -2
> No ethernet found.
>
> Signed-off-by: Fabio Estevam
Reviewed-by: Peter Robinson
> ---
> board/udoo/udoo.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/board/udoo/udoo.c b/board/udoo/udoo.c
> index 5c49388cbfbe..9e0365615d6d 100644
> --- a/board/udoo/udoo.c
> +++ b/board/udoo/udoo.c
> @@ -90,6 +90,14 @@ int mx6_rgmii_rework(struct phy_device *phydev)
>
> static void setup_iomux_enet(void)
> {
> + gpio_request(IMX_GPIO_NR(2, 31), "eth_power");
> + gpio_request(IMX_GPIO_NR(3, 23), "eth_phy_reset");
> + gpio_request(IMX_GPIO_NR(6, 24), "strap1");
> + gpio_request(IMX_GPIO_NR(6, 25), "strap2");
> + gpio_request(IMX_GPIO_NR(6, 27), "strap3");
> + gpio_request(IMX_GPIO_NR(6, 28), "strap4");
> + gpio_request(IMX_GPIO_NR(6, 29), "strap5");
> +
> gpio_direction_output(IMX_GPIO_NR(2, 31), 1); /* Power supply on */
>
> gpio_direction_output(IMX_GPIO_NR(3, 23), 0); /* assert PHY rst */
> --
> 2.25.1
>
[PATCH] lib: export vsscanf
The function was missing from exports, even though it loooks like the intent of the implementation in sscanf.c was to have it exported. Signed-off-by: Samuel Dionne-Riel Cc: Simon Glass --- This is needed for porting an external library to U-Boot, in WIP changes. It builds with a warning, and does link since the symbol is present. Though when treating warnings as errors during development, it becomes an issue. include/vsprintf.h | 8 1 file changed, 8 insertions(+) diff --git a/include/vsprintf.h b/include/vsprintf.h index b474630146..8bfafa0d33 100644 --- a/include/vsprintf.h +++ b/include/vsprintf.h @@ -307,6 +307,14 @@ char *strmhz(char *buf, unsigned long hz); */ void str_to_upper(const char *in, char *out, size_t len); +/** + * vsscanf - Unformat a buffer into a list of arguments + * @buf: input buffer + * @fmt: format of buffer + * @args: arguments + */ +int vsscanf(const char *inp, char const *fmt0, va_list ap); + /** * sscanf - Unformat a buffer into a list of arguments * @buf: input buffer -- 2.34.0 -- Samuel Dionne-Riel
[PATCH] cmd: adc: Report return value on error
Reporting the return value should always be done on error conditions,
this way the developer can start debugging issues with more knowledge
in-hand.
Signed-off-by: Samuel Dionne-Riel
---
cmd/adc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cmd/adc.c b/cmd/adc.c
index 16f914a030..75739bc8ee 100644
--- a/cmd/adc.c
+++ b/cmd/adc.c
@@ -81,8 +81,8 @@ static int do_adc_single(struct cmd_tbl *cmdtp, int flag, int
argc,
ret = adc_channel_single_shot(argv[1], simple_strtol(argv[2], NULL, 0),
);
if (ret) {
- printf("Error getting single shot for device %s channel %s\n",
- argv[1], argv[2]);
+ printf("Error getting single shot for device %s channel %s
(ret=%d)\n",
+ argv[1], argv[2], ret);
return CMD_RET_FAILURE;
}
--
2.34.0
--
Samuel Dionne-Riel
Re: [RFC PATCH v2 7/8] FWU: Add support for FWU Multi Bank Update feature
Hi Tom, 2021年12月21日(火) 1:36 Tom Rini : > > On Mon, Dec 20, 2021 at 10:13:35PM +0900, Masami Hiramatsu wrote: > > Hi Sughosh, > > > > 2021年12月20日(月) 18:48 Sughosh Ganu : > > > > > > > > > On Mon, 20 Dec 2021 at 11:44, AKASHI Takahiro > > > wrote: > > >> > > >> On Sun, Dec 19, 2021 at 12:36:04PM +0530, Sughosh Ganu wrote: > > >> > The FWU Multi Bank Update feature supports updation of firmware images > > >> > to one of multiple sets(also called banks) of images. The firmware > > >> > images are clubbed together in banks, with the system booting images > > >> > from the active bank. Information on the images such as which bank > > >> > they belong to is stored as part of the metadata structure, which is > > >> > stored on the same storage media as the firmware images on a dedicated > > >> > partition. > > >> > > > >> > At the time of update, the metadata is read to identify the bank to > > >> > which the images need to be flashed(update bank). On a successful > > >> > update, the metadata is modified to set the updated bank as active > > >> > bank to subsequently boot from. > > >> > > > >> > Signed-off-by: Sughosh Ganu > > >> > --- > > >> > Changes since V1: > > >> > * Call function fwu_update_checks_pass to check if the > > >> > update can be initiated > > >> > * Do not allow firmware update from efi_init_obj_list as the > > >> > fwu boot-time checks need to be run > > >> > > > >> > include/fwu.h| 18 +++- > > >> > lib/Kconfig | 32 ++ > > >> > lib/Makefile | 1 + > > >> > lib/efi_loader/efi_capsule.c | 198 ++- > > >> > lib/efi_loader/efi_setup.c | 3 +- > > >> > lib/fwu_updates/Makefile | 11 ++ > > >> > lib/fwu_updates/fwu.c| 27 + > > >> > 7 files changed, 284 insertions(+), 6 deletions(-) > > >> > create mode 100644 lib/fwu_updates/Makefile > > >> > > > >> > diff --git a/include/fwu.h b/include/fwu.h > > >> > index 2d2e674d6a..bf50fe9277 100644 > > >> > --- a/include/fwu.h > > >> > +++ b/include/fwu.h > > >> > @@ -10,14 +10,28 @@ > > >> > > > >> > #include > > >> > > > >> > -#define FWU_MDATA_VERSION0x1 > > >> > +#define FWU_MDATA_GUID \ > > >> > + EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \ > > >> > + 0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23) > > >> > + > > >> > +#define FWU_OS_REQUEST_FW_REVERT_GUID \ > > >> > + EFI_GUID(0xacd58b4b, 0xc0e8, 0x475f, 0x99, 0xb5, \ > > >> > + 0x6b, 0x3f, 0x7e, 0x07, 0xaa, 0xf0) > > >> > + > > >> > +#define FWU_OS_REQUEST_FW_ACCEPT_GUID \ > > >> > + EFI_GUID(0x0c996046, 0xbcc0, 0x4d04, 0x85, 0xec, \ > > >> > + 0xe1, 0xfc, 0xed, 0xf1, 0xc6, 0xf8) > > >> > > > >> > #define FWU_MDATA_GUID \ > > >> > EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \ > > >> >0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23) > > >> > > > >> > -int fwu_boottime_checks(void); > > >> > +#define FWU_MDATA_VERSION0x1 > > >> > +#define FWU_IMAGE_ACCEPTED 0x1 > > >> > + > > >> > u8 fwu_update_checks_pass(void); > > >> > +int fwu_boottime_checks(void); > > >> > +int fwu_trial_state_ctr_start(void); > > >> > > > >> > int fwu_get_active_index(u32 *active_idx); > > >> > int fwu_update_active_index(u32 active_idx); > > >> > diff --git a/lib/Kconfig b/lib/Kconfig > > >> > index 807a4c6ade..7cb306317c 100644 > > >> > --- a/lib/Kconfig > > >> > +++ b/lib/Kconfig > > >> > @@ -835,3 +835,35 @@ config PHANDLE_CHECK_SEQ > > >> > When there are multiple device tree nodes with same name, > > >> >enable this config option to distinguish them using > > >> > phandles in fdtdec_get_alias_seq() function. > > >> > + > > >> > +config FWU_MULTI_BANK_UPDATE > > >> > + bool "Enable FWU Multi Bank Update Feature" > > >> > + depends on EFI_HAVE_CAPSULE_SUPPORT > > >> > + select PARTITION_TYPE_GUID > > >> > + select EFI_SETUP_EARLY > > >> > + help > > >> > + Feature for updating firmware images on platforms having > > >> > + multiple banks(copies) of the firmware images. One of the > > >> > + bank is selected for updating all the firmware components > > >> > + > > >> > +config FWU_NUM_BANKS > > >> > + int "Number of Banks defined by the platform" > > >> > + depends on FWU_MULTI_BANK_UPDATE > > >> > + help > > >> > + Define the number of banks of firmware images on a platform > > >> > + > > >> > +config FWU_NUM_IMAGES_PER_BANK > > >> > + int "Number of firmware images per bank" > > >> > + depends on FWU_MULTI_BANK_UPDATE > > >> > + help > > >> > + Define the number of firmware images per bank. This value > > >> > + should be the same for all the banks. > > >> > + > > >> > +config FWU_TRIAL_STATE_CNT > > >> > + int "Number of times system boots in Trial State" > > >> > + depends on FWU_MULTI_BANK_UPDATE > > >> > + default 3 > > >> > + help > > >> > + With FWU Multi Bank Update feature enabled, number of
[PATCH] cmd: env: Add `indirect` to indirectly set values
This allows an ergonomic-enough approximation of ${!variable} expansion.
This could be used the following way:
```
for target in ${boot_targets}; do
env indirect target_name target_name_${target}
# ...
done
```
Assuming `target_name_mmc0` and similar are set appropriately.
A default value can be optionally provided.
Note: this acts on environment variables, not hush variables.
Signed-off-by: Samuel Dionne-Riel
Cc: Simon Glass
Cc: "Marek Behún"
---
cmd/Kconfig | 4
cmd/nvedit.c | 45 +
2 files changed, 49 insertions(+)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 26d5707f75..e538e69a11 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -508,6 +508,10 @@ config CMD_NVEDIT_EFI
If enabled, we are allowed to set/print UEFI variables using
"env" command with "-e" option without knowing details.
+config CMD_NVEDIT_INDIRECT
+ bool "env indirect - Sets environment value from another"
+ default y
+
config CMD_NVEDIT_INFO
bool "env info - print or evaluate environment information"
help
diff --git a/cmd/nvedit.c b/cmd/nvedit.c
index 3bb6e764c0..53e6b57b60 100644
--- a/cmd/nvedit.c
+++ b/cmd/nvedit.c
@@ -1018,6 +1018,45 @@ sep_err:
}
#endif
+#if defined(CONFIG_CMD_NVEDIT_INDIRECT)
+static int do_env_indirect(struct cmd_tbl *cmdtp, int flag,
+ int argc, char *const argv[])
+{
+ char *to = argv[1];
+ char *from = argv[2];
+ char *default_value = NULL;
+ int ret = 0;
+
+ if (argc < 3 || argc > 4) {
+ return CMD_RET_USAGE;
+ }
+
+ if (argc == 4) {
+ default_value = argv[3];
+ }
+
+ if (env_get(from) == NULL && default_value == NULL) {
+ printf("## env indirect: Environment variable for (%s)
does not exist.\n", from);
+
+ return CMD_RET_FAILURE;
+ }
+
+ if (env_get(from) == NULL) {
+ ret = env_set(to, default_value);
+ }
+ else {
+ ret = env_set(to, env_get(from));
+ }
+
+ if (ret == 0) {
+ return CMD_RET_SUCCESS;
+ }
+ else {
+ return CMD_RET_FAILURE;
+ }
+}
+#endif
+
#if defined(CONFIG_CMD_NVEDIT_INFO)
/*
* print_env_info - print environment information
@@ -1181,6 +1220,9 @@ static struct cmd_tbl cmd_env_sub[] = {
#if defined(CONFIG_CMD_IMPORTENV)
U_BOOT_CMD_MKENT(import, 5, 0, do_env_import, "", ""),
#endif
+#if defined(CONFIG_CMD_NVEDIT_INDIRECT)
+ U_BOOT_CMD_MKENT(indirect, 3, 0, do_env_indirect, "", ""),
+#endif
#if defined(CONFIG_CMD_NVEDIT_INFO)
U_BOOT_CMD_MKENT(info, 3, 0, do_env_info, "", ""),
#endif
@@ -1265,6 +1307,9 @@ static char env_help_text[] =
#if defined(CONFIG_CMD_IMPORTENV)
"env import [-d] [-t [-r] | -b | -c] addr [size] [var ...] - import
environment\n"
#endif
+#if defined(CONFIG_CMD_NVEDIT_INDIRECT)
+ "env indirect [default] - sets to the value of ,
using [default] when unset\n"
+#endif
#if defined(CONFIG_CMD_NVEDIT_INFO)
"env info - display environment information\n"
"env info [-d] [-p] [-q] - evaluate environment information\n"
--
2.34.0
--
Samuel Dionne-Riel
Re: [RFC PATCH v2 7/8] FWU: Add support for FWU Multi Bank Update feature
On Tue, Dec 21, 2021 at 08:30:02AM +0900, Masami Hiramatsu wrote: > Hi Tom, > > 2021年12月21日(火) 1:36 Tom Rini : > > > > On Mon, Dec 20, 2021 at 10:13:35PM +0900, Masami Hiramatsu wrote: > > > Hi Sughosh, > > > > > > 2021年12月20日(月) 18:48 Sughosh Ganu : > > > > > > > > > > > > On Mon, 20 Dec 2021 at 11:44, AKASHI Takahiro > > > > wrote: > > > >> > > > >> On Sun, Dec 19, 2021 at 12:36:04PM +0530, Sughosh Ganu wrote: > > > >> > The FWU Multi Bank Update feature supports updation of firmware > > > >> > images > > > >> > to one of multiple sets(also called banks) of images. The firmware > > > >> > images are clubbed together in banks, with the system booting images > > > >> > from the active bank. Information on the images such as which bank > > > >> > they belong to is stored as part of the metadata structure, which is > > > >> > stored on the same storage media as the firmware images on a > > > >> > dedicated > > > >> > partition. > > > >> > > > > >> > At the time of update, the metadata is read to identify the bank to > > > >> > which the images need to be flashed(update bank). On a successful > > > >> > update, the metadata is modified to set the updated bank as active > > > >> > bank to subsequently boot from. > > > >> > > > > >> > Signed-off-by: Sughosh Ganu > > > >> > --- > > > >> > Changes since V1: > > > >> > * Call function fwu_update_checks_pass to check if the > > > >> > update can be initiated > > > >> > * Do not allow firmware update from efi_init_obj_list as the > > > >> > fwu boot-time checks need to be run > > > >> > > > > >> > include/fwu.h| 18 +++- > > > >> > lib/Kconfig | 32 ++ > > > >> > lib/Makefile | 1 + > > > >> > lib/efi_loader/efi_capsule.c | 198 > > > >> > ++- > > > >> > lib/efi_loader/efi_setup.c | 3 +- > > > >> > lib/fwu_updates/Makefile | 11 ++ > > > >> > lib/fwu_updates/fwu.c| 27 + > > > >> > 7 files changed, 284 insertions(+), 6 deletions(-) > > > >> > create mode 100644 lib/fwu_updates/Makefile > > > >> > > > > >> > diff --git a/include/fwu.h b/include/fwu.h > > > >> > index 2d2e674d6a..bf50fe9277 100644 > > > >> > --- a/include/fwu.h > > > >> > +++ b/include/fwu.h > > > >> > @@ -10,14 +10,28 @@ > > > >> > > > > >> > #include > > > >> > > > > >> > -#define FWU_MDATA_VERSION0x1 > > > >> > +#define FWU_MDATA_GUID \ > > > >> > + EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \ > > > >> > + 0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23) > > > >> > + > > > >> > +#define FWU_OS_REQUEST_FW_REVERT_GUID \ > > > >> > + EFI_GUID(0xacd58b4b, 0xc0e8, 0x475f, 0x99, 0xb5, \ > > > >> > + 0x6b, 0x3f, 0x7e, 0x07, 0xaa, 0xf0) > > > >> > + > > > >> > +#define FWU_OS_REQUEST_FW_ACCEPT_GUID \ > > > >> > + EFI_GUID(0x0c996046, 0xbcc0, 0x4d04, 0x85, 0xec, \ > > > >> > + 0xe1, 0xfc, 0xed, 0xf1, 0xc6, 0xf8) > > > >> > > > > >> > #define FWU_MDATA_GUID \ > > > >> > EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \ > > > >> >0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23) > > > >> > > > > >> > -int fwu_boottime_checks(void); > > > >> > +#define FWU_MDATA_VERSION0x1 > > > >> > +#define FWU_IMAGE_ACCEPTED 0x1 > > > >> > + > > > >> > u8 fwu_update_checks_pass(void); > > > >> > +int fwu_boottime_checks(void); > > > >> > +int fwu_trial_state_ctr_start(void); > > > >> > > > > >> > int fwu_get_active_index(u32 *active_idx); > > > >> > int fwu_update_active_index(u32 active_idx); > > > >> > diff --git a/lib/Kconfig b/lib/Kconfig > > > >> > index 807a4c6ade..7cb306317c 100644 > > > >> > --- a/lib/Kconfig > > > >> > +++ b/lib/Kconfig > > > >> > @@ -835,3 +835,35 @@ config PHANDLE_CHECK_SEQ > > > >> > When there are multiple device tree nodes with same name, > > > >> >enable this config option to distinguish them using > > > >> > phandles in fdtdec_get_alias_seq() function. > > > >> > + > > > >> > +config FWU_MULTI_BANK_UPDATE > > > >> > + bool "Enable FWU Multi Bank Update Feature" > > > >> > + depends on EFI_HAVE_CAPSULE_SUPPORT > > > >> > + select PARTITION_TYPE_GUID > > > >> > + select EFI_SETUP_EARLY > > > >> > + help > > > >> > + Feature for updating firmware images on platforms having > > > >> > + multiple banks(copies) of the firmware images. One of the > > > >> > + bank is selected for updating all the firmware components > > > >> > + > > > >> > +config FWU_NUM_BANKS > > > >> > + int "Number of Banks defined by the platform" > > > >> > + depends on FWU_MULTI_BANK_UPDATE > > > >> > + help > > > >> > + Define the number of banks of firmware images on a platform > > > >> > + > > > >> > +config FWU_NUM_IMAGES_PER_BANK > > > >> > + int "Number of firmware images per bank" > > > >> > + depends on FWU_MULTI_BANK_UPDATE > > > >> > + help > > > >> > + Define the number of firmware images per bank. This value > > > >> > +
Re: [RFC PATCH v2 1/8] FWU: Add FWU metadata structure and functions for accessing metadata
Hi Sughosh,
2021年12月19日(日) 16:06 Sughosh Ganu :
>
> In the FWU Multi Bank Update feature, the information about the
> updatable images is stored as part of the metadata, which is stored on
> a dedicated partition. Add the metadata structure, and functions to
> access the metadata. These are generic API's, and implementations can
> be added based on parameters like how the metadata partition is
> accessed and what type of storage device houses the metadata.
>
> Signed-off-by: Sughosh Ganu
> ---
> Changes since V1:
> * Move all function declarations to a separate header fwu.h
> * Rename metadata with mdata for all symbols
> * Drop the parameter in the function fwu_revert_boot_index
> as suggested by Etienne
>
> include/fwu.h | 28 +
> include/fwu_mdata.h | 102
> lib/fwu_updates/fwu_mdata.c | 236
> 3 files changed, 366 insertions(+)
> create mode 100644 include/fwu.h
> create mode 100644 include/fwu_mdata.h
> create mode 100644 lib/fwu_updates/fwu_mdata.c
>
> diff --git a/include/fwu.h b/include/fwu.h
> new file mode 100644
> index 00..e6bc3e6b73
> --- /dev/null
> +++ b/include/fwu.h
> @@ -0,0 +1,28 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (c) 2021, Linaro Limited
> + */
> +
> +#if !defined _FWU_H_
> +#define _FWU_H_
> +
> +#include
> +
> +#include
> +
> +#define FWU_MDATA_VERSION 0x1
> +
> +#define FWU_MDATA_GUID \
> + EFI_GUID(0x8a7a84a0, 0x8387, 0x40f6, 0xab, 0x41, \
> +0xa8, 0xb9, 0xa5, 0xa6, 0x0d, 0x23)
> +
> +int fwu_get_active_index(u32 *active_idx);
> +int fwu_update_active_index(u32 active_idx);
> +int fwu_get_image_alt_num(efi_guid_t image_type_id, u32 update_bank,
> + int *alt_num);
> +int fwu_mdata_check(void);
> +int fwu_revert_boot_index(void);
> +int fwu_accept_image(efi_guid_t *img_type_id);
> +int fwu_clear_accept_image(efi_guid_t *img_type_id, u32 bank);
> +
> +#endif /* _FWU_H_ */
> diff --git a/include/fwu_mdata.h b/include/fwu_mdata.h
> new file mode 100644
> index 00..11eb570012
> --- /dev/null
> +++ b/include/fwu_mdata.h
> @@ -0,0 +1,102 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (c) 2021, Linaro Limited
> + */
> +
> +#if !defined _FWU_MDATA_H_
> +#define _FWU_MDATA_H_
> +
> +#include
> +#include
> +
> +#include
> +
> +/**
> + * struct fwu_image_bank_info - firmware image information
> + * @image_uuid: Guid value of the image in this bank
> + * @accepted: Acceptance status of the image
> + * @reserved: Reserved
> + *
> + * The structure contains image specific fields which are
> + * used to identify the image and to specify the image's
> + * acceptance status
> + */
> +struct fwu_image_bank_info {
> + efi_guid_t image_uuid;
> + u32 accepted;
> + u32 reserved;
> +};
Could you explicitly pack these metadata data structures?
Since these metadata will be shared among bootloaders (TF-A, SCP-firmware),
it is better to ensure that those are packed and fixed offset for each field.
> +
> +/**
> + * struct fwu_image_entry - information for a particular type of image
> + * @image_type_uuid: Guid value for identifying the image type
> + * @location_uuid: Guid of the storage volume where the image is located
> + * @img_bank_info: Array containing properties of images
> + *
> + * This structure contains information on various types of updatable
> + * firmware images. Each image type then contains an array of image
> + * information per bank.
> + */
> +struct fwu_image_entry {
> + efi_guid_t image_type_uuid;
> + efi_guid_t location_uuid;
> + struct fwu_image_bank_info img_bank_info[CONFIG_FWU_NUM_BANKS];
> +};
> +
> +/**
> + * struct fwu_mdata - FWU metadata structure for multi-bank updates
> + * @crc32: crc32 value for the FWU metadata
> + * @version: FWU metadata version
> + * @active_index: Index of the bank currently used for booting images
> + * @previous_active_inde: Index of the bank used before the current bank
> + *being used for booting
> + * @img_entry: Array of information on various firmware images that can
> + * be updated
> + *
> + * This structure is used to store all the needed information for performing
> + * multi bank updates on the platform. This contains info on the bank being
> + * used to boot along with the information needed for identification of
> + * individual images
> + */
> +struct fwu_mdata {
> + u32 crc32;
> + u32 version;
> + u32 active_index;
> + u32 previous_active_index;
> +
> + struct fwu_image_entry img_entry[CONFIG_FWU_NUM_IMAGES_PER_BANK];
> +};
> +
> +/**
> + * @get_active_index: get the current active_index value
> + * @update_active_index: update the active_index value
> + * @get_image_alt_num: get the alt number to be used for the image
> + * @mdata_check: check the validity of the FWU metadata partitions
> + * @revert_boot_index: set the
Re: [PATCH 2/8] arm: kirkwood: Pogoplug V4 : Add board defconfig file
On Sun, Dec 19, 2021 at 11:18 PM Stefan Roese wrote: > > Hi Tony, > > On 12/18/21 22:41, Tony Dinh wrote: > > Hi Pali, > > > > On Sat, Dec 18, 2021 at 5:17 AM Pali Rohár wrote: > >> > >> On Friday 17 December 2021 20:23:28 Tony Dinh wrote: > >>> Add board defconfig file for Pogoplug V4 board > >>> > >>> Signed-off-by: Tony Dinh > >>> --- > >>> > >>> configs/pogo_v4_defconfig | 97 +++ > >>> 1 file changed, 97 insertions(+) > >>> create mode 100644 configs/pogo_v4_defconfig > >>> > >>> diff --git a/configs/pogo_v4_defconfig b/configs/pogo_v4_defconfig > >>> new file mode 100644 > >>> index 00..b183c9c46f > >>> --- /dev/null > >>> +++ b/configs/pogo_v4_defconfig > >>> @@ -0,0 +1,97 @@ > >>> +# SPDX-License-Identifier: GPL-2.0+ > >>> +# > >>> +# (C) Copyright 2017-2021 Tony Dinh > >>> +# > >>> +CONFIG_ARM=y > >>> +CONFIG_SKIP_LOWLEVEL_INIT=y > >>> +CONFIG_SYS_DCACHE_OFF=y > >>> +CONFIG_ARCH_CPU_INIT=y > >>> +CONFIG_SYS_THUMB_BUILD=y > >>> +CONFIG_ARCH_KIRKWOOD=y > >>> +CONFIG_SYS_TEXT_BASE=0x60 > >>> +CONFIG_TARGET_POGO_V4=y > >>> +CONFIG_ENV_SIZE=0x2 > >>> +CONFIG_ENV_OFFSET=0xC > >>> +CONFIG_DEFAULT_DEVICE_TREE="kirkwood-pogoplug_v4" > >>> +CONFIG_BOOTDELAY=10 > >>> +CONFIG_BOOTSTAGE=y > >>> +CONFIG_SHOW_BOOT_PROGRESS=y > >>> +CONFIG_USE_PREBOOT=y > >>> +CONFIG_HUSH_PARSER=y > >>> +CONFIG_SYS_PROMPT="Pogo_V4> " > >>> +CONFIG_IDENT_STRING="\nPogoplug V4" > >>> +CONFIG_SYS_LOAD_ADDR=0x80 > >>> +CONFIG_VERSION_VARIABLE=y > >>> +# CONFIG_CMD_FLASH is not set > >>> +CONFIG_CMD_SETEXPR=y > >>> +CONFIG_CMD_NAND=y > >>> +CONFIG_CMD_MMC=y > >>> +CONFIG_CMD_USB=y > >>> +CONFIG_CMD_DHCP=y > >>> +CONFIG_CMD_MII=y > >>> +CONFIG_CMD_PING=y > >>> +CONFIG_CMD_EXT2=y > >>> +CONFIG_CMD_EXT4=y > >>> +CONFIG_CMD_FAT=y > >>> +CONFIG_CMD_JFFS2=y > >>> +CONFIG_CMD_FS_GENERIC=y > >>> +CONFIG_CMD_MTDPARTS=y > >>> +CONFIG_MTDPARTS_DEFAULT="mtdparts=orion_nand:2M(u-boot),3M(uImage),3M(uImage2),8M(failsafe),112M(root)" > >>> +CONFIG_MTDIDS_DEFAULT="nand0=orion_nand" > >>> +CONFIG_CMD_UBI=y > >>> +CONFIG_ISO_PARTITION=y > >>> +CONFIG_EFI_PARTITION=y > >>> +CONFIG_PARTITION_UUIDS=y > >>> +CONFIG_PARTITION_TYPE_GUID=y > >>> +CONFIG_ENV_OVERWRITE=y > >>> +CONFIG_ENV_IS_IN_NAND=y > >>> +CONFIG_SYS_NS16550=y > >>> +CONFIG_USB=y > >>> +CONFIG_USB_STORAGE=y > >>> +CONFIG_USB_EHCI_HCD=y > >>> +CONFIG_OF_LIBFDT=y > >>> +CONFIG_CMD_FDT=y > >>> +CONFIG_CMD_BOOTZ=y > >>> +CONFIG_NETCONSOLE=y > >>> +CONFIG_MTD=y > >>> +CONFIG_MTD_RAW_NAND=y > >>> +CONFIG_CMD_MTD=y > >>> +CONFIG_MTD_PARTITIONS=y > >>> +CONFIG_MTD_DEVICE=y > >>> +CONFIG_NET=y > >>> +CONFIG_NETDEVICES=y > >>> +CONFIG_MVGBE=y > >>> +CONFIG_MII=y > >>> +CONFIG_DM=y > >>> +CONFIG_DM_USB=y > >>> +CONFIG_OF_CONTROL=y > >>> +CONFIG_DM_ETH=y > >>> +CONFIG_NET_RANDOM_ETHADDR=y > >>> +CONFIG_BLK=y > >>> +CONFIG_CMD_SATA=y > >>> +CONFIG_SATA_MV=y > >>> +CONFIG_DM_MMC=y > >>> +CONFIG_MVEBU_MMC=y > >>> +CONFIG_CMD_PCI=y > >>> +CONFIG_PCI=y > >>> +CONFIG_PCI_MVEBU=y > >>> +CONFIG_PCI_PNP=y > >>> +CONFIG_USB_XHCI_HCD=y > >>> +CONFIG_USB_XHCI_PCI=y > >>> +CONFIG_BOARD_LATE_INIT=y > >>> +# > >>> +# RTC emulation > >>> +# > >>> +CONFIG_CMD_DATE=y > >>> +CONFIG_PROT_UDP=y > >>> +CONFIG_CMD_SNTP=y > >>> +CONFIG_CMD_DNS=y > >>> +CONFIG_DM_RTC=y > >>> +CONFIG_RTC_EMULATION=y > >>> +# > >>> +# Turn off unused capabilities to save space > >>> +# > >>> +# CONFIG_BOOTM_PLAN9 is not set > >>> +# CONFIG_BOOTM_RTEMS is not set > >>> +# CONFIG_BOOTM_VXWORKS is not set > >>> +# CONFIG_MMC_HW_PARTITIONING is not set > >>> -- > >>> 2.20.1 > >>> > >> > >> Hello! Please regenerate this defconfig file to its canonical form. You > >> can do it by commands: > >> > >>make pogo_v4_defconfig > >>make savedefconfig > >>mv defconfig configs/pogo_v4_defconfig > > > > Yes, it's a bit harder to read, but it should be done. > > It's not a matter of "harder to read". It's the only way, this file > should be generated. Otherwise this will very likely generate merge > problems when other changes might get introduced to the config files > (e.g. by using moveconfig.py). I see. Thanks for the explanation! Tony > Thanks, > Stefan
Re: [PATCH 6/8] arm: kirkwood: Pogoplug-V4 : Add board implementation header
On Sun, Dec 19, 2021 at 11:23 PM Stefan Roese wrote: > > Hi Tony, > > On 12/18/21 22:47, Tony Dinh wrote: > > Hi Pali, > > > > On Sat, Dec 18, 2021 at 5:09 AM Pali Rohár wrote: > >> > >> On Friday 17 December 2021 20:23:32 Tony Dinh wrote: > >>> Add board implementation header and Makefile for Pogoplug V4 > >>> > >>> Signed-off-by: Tony Dinh > >>> --- > >>> > >>> board/cloudengines/pogo_v4/Makefile | 10 > >>> board/cloudengines/pogo_v4/pogo_v4.h | 36 > >>> 2 files changed, 46 insertions(+) > >>> create mode 100644 board/cloudengines/pogo_v4/Makefile > >>> create mode 100644 board/cloudengines/pogo_v4/pogo_v4.h > >>> > >>> diff --git a/board/cloudengines/pogo_v4/Makefile > >>> b/board/cloudengines/pogo_v4/Makefile > >>> new file mode 100644 > >>> index 00..511bf5ff7e > >>> --- /dev/null > >>> +++ b/board/cloudengines/pogo_v4/Makefile > >>> @@ -0,0 +1,10 @@ > >>> +# SPDX-License-Identifier: GPL-2.0+ > >>> +# > >>> +# (C) Copyright 2014-2021 Tony Dinh > >>> +# > >>> +# Based on > >>> +# Marvell Semiconductor > >>> +# Written-by: Prafulla Wadaskar > >>> +# > >>> + > >>> +obj-y:= pogo_v4.o > >>> diff --git a/board/cloudengines/pogo_v4/pogo_v4.h > >>> b/board/cloudengines/pogo_v4/pogo_v4.h > >>> new file mode 100644 > >>> index 00..bf3060de60 > >>> --- /dev/null > >>> +++ b/board/cloudengines/pogo_v4/pogo_v4.h > >>> @@ -0,0 +1,36 @@ > >>> +/* SPDX-License-Identifier: GPL-2.0+ */ > >>> +/* > >>> + * Copyright (C) 2014-2021 Tony Dinh > >>> + * > >>> + * Based on > >>> + * Copyright (C) 2012 David Purdy > >>> + * > >>> + * Based on Kirkwood support: > >>> + * (C) Copyright 2009 > >>> + * Marvell Semiconductor > >>> + * Written-by: Prafulla Wadaskar > >>> + */ > >>> + > >>> +#ifndef __POGO_V4_H > >>> +#define __POGO_V4_H > >>> + > >>> +#include > >>> + > >>> +/* GPIO configuration */ > >>> +#define POGO_V4_OE_LOW (~(0)) > >>> +#define POGO_V4_OE_HIGH (~(0)) > >>> +#define POGO_V4_OE_VAL_LOW BIT(29) > >>> +#define POGO_V4_OE_VAL_HIGH 0 > >>> + > >>> +/* PHY related */ > >>> +#define MV88E1116_LED_FCTRL_REG 10 > >>> +#define MV88E1116_CPRSP_CR3_REG 21 > >>> +#define MV88E1116_MAC_CTRL_REG 21 > >>> +#define MV88E1116_PGADR_REG 22 > >>> +#define MV88E1116_RGMII_TXTM_CTRLBIT(4) > >>> +#define MV88E1116_RGMII_RXTM_CTRLBIT(5) > >>> + > >>> +/* button */ > >>> +#define BTN_EJECT29 > >>> + > >>> +#endif /* __POGO_V4_H */ > >> > >> Hello! As this pogo_v4.h include file is used only in pogo_v4.c source > >> file and contains only few defines, you can move all these defines > >> directly into pogo_v4.c source file. There is no need to export these > >> constants if they are not used by other files or modules. > > > > Sure, but that'll make the .c file harder to read? We've been using > > the .h file since the old days, I think mostly for readability. This > > is a small header file, but for some other boards, the header file is > > quite large. > > I fail to see why moving these few lines from the header to the .c file > makes the code harder to read. Especially if the macros / defines are > only used in one specific file, it makes sense to place them in this > file IMHO. Concur with you and Pali! Will merge the constants to .c file. Thanks, Tony > > Thanks, > Stefan
[PATCH] arm: socfpga: vining: Unmount UBIFS and detach UBI in ubi_load script
Clean up in ubiload script. Unmount UBIFS from which kernel image was
loaded and detach UBI on which the UBIFS is located, otherwise message
similar to the following is printed just before booting kernel:
Removing MTD device #7 (rootfs) with use count 1
Error when deleting partition "rootfs" (-16)
Signed-off-by: Marek Vasut
Cc: Siew Chin Lim
Cc: Simon Goldschmidt
Cc: Tien Fong Chee
---
include/configs/socfpga_vining_fpga.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/configs/socfpga_vining_fpga.h
b/include/configs/socfpga_vining_fpga.h
index d9d0a4af5ac..5c0ed07c427 100644
--- a/include/configs/socfpga_vining_fpga.h
+++ b/include/configs/socfpga_vining_fpga.h
@@ -118,7 +118,8 @@
"addargs=run addcons addmtd addmisc\0" \
"ubiload=" \
"ubi part ${ubimtd} ; ubifsmount ${ubipart} ; " \
- "ubifsload ${kernel_addr_r} /boot/${bootfile}\0"\
+ "ubifsload ${kernel_addr_r} /boot/${bootfile} ; " \
+ "ubifsumount ; ubi detach\0"\
"netload=" \
"tftp ${kernel_addr_r} ${hostname}/${bootfile}\0" \
"miscargs=nohlt panic=1\0" \
--
2.34.1
Re: [PATCH 1/1] mmc: unconditionally define mmc_deinit()
On 12/18/21 6:53 PM, Heinrich Schuchardt wrote: > We want to replace '#ifdef' by 'if (IS_ENABLED(CONFIG_...))' in our code. > Therefore functions should be defined unconditionally even if they are not > implemented. > > Signed-off-by: Heinrich Schuchardt Reviewed-by: Jaehoon Chung Best Regards, Jaehoon Chung > --- > include/mmc.h | 5 - > 1 file changed, 5 deletions(-) > > diff --git a/include/mmc.h b/include/mmc.h > index b92e255340..244d2dc592 100644 > --- a/include/mmc.h > +++ b/include/mmc.h > @@ -786,12 +786,7 @@ int mmc_init_device(int num); > int mmc_init(struct mmc *mmc); > int mmc_send_tuning(struct mmc *mmc, u32 opcode, int *cmd_error); > int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct mmc_data > *data); > - > -#if CONFIG_IS_ENABLED(MMC_UHS_SUPPORT) || \ > -CONFIG_IS_ENABLED(MMC_HS200_SUPPORT) || \ > -CONFIG_IS_ENABLED(MMC_HS400_SUPPORT) > int mmc_deinit(struct mmc *mmc); > -#endif > > /** > * mmc_of_parse() - Parse the device tree to get the capabilities of the host >
Re: [PATCH 0/3] Apple M1 power management controller support
Dear Mark, On 12/7/21 4:03 AM, Mark Kettenis wrote: > This series adds support for the power management controller found on > Apple SoCs based on the device tree bindings submitted to upstream > Linux. This is needed to enable power domains for devices that > haven't been enabled by earlier boot stages. Is there any patch before applied this patchset? Best Regards, Jaehoon Chung > > > Mark Kettenis (3): > arm: dts: apple: Update Apple M1 device trees > arm: dts: apple: Add u-boot,dm-pre-reloc properties > power: domain: Add Apple pmgr driver > > arch/arm/Kconfig|4 + > arch/arm/dts/Makefile |5 +- > arch/arm/dts/t8103-j274-u-boot.dtsi |1 + > arch/arm/dts/t8103-j274.dts | 122 +-- > arch/arm/dts/t8103-j293-u-boot.dtsi |1 + > arch/arm/dts/t8103-j293.dts | 92 +-- > arch/arm/dts/t8103-j313-u-boot.dtsi |1 + > arch/arm/dts/t8103-j313.dts | 57 ++ > arch/arm/dts/t8103-j456-u-boot.dtsi |1 + > arch/arm/dts/t8103-j456.dts | 71 ++ > arch/arm/dts/t8103-j457-u-boot.dtsi |1 + > arch/arm/dts/t8103-j457.dts | 59 ++ > arch/arm/dts/t8103-jxxx.dtsi| 140 > arch/arm/dts/t8103-pmgr.dtsi| 1136 +++ > arch/arm/dts/t8103-u-boot.dtsi | 25 + > arch/arm/dts/t8103.dtsi | 585 +++--- > drivers/mailbox/Kconfig |9 + > drivers/mailbox/Makefile|1 + > drivers/power/domain/Kconfig|8 + > drivers/power/domain/Makefile |1 + > drivers/power/domain/apple-pmgr.c | 113 +++ > 21 files changed, 2005 insertions(+), 428 deletions(-) > create mode 100644 arch/arm/dts/t8103-j274-u-boot.dtsi > create mode 100644 arch/arm/dts/t8103-j293-u-boot.dtsi > create mode 100644 arch/arm/dts/t8103-j313-u-boot.dtsi > create mode 100644 arch/arm/dts/t8103-j313.dts > create mode 100644 arch/arm/dts/t8103-j456-u-boot.dtsi > create mode 100644 arch/arm/dts/t8103-j456.dts > create mode 100644 arch/arm/dts/t8103-j457-u-boot.dtsi > create mode 100644 arch/arm/dts/t8103-j457.dts > create mode 100644 arch/arm/dts/t8103-jxxx.dtsi > create mode 100644 arch/arm/dts/t8103-pmgr.dtsi > create mode 100644 arch/arm/dts/t8103-u-boot.dtsi > create mode 100644 drivers/power/domain/apple-pmgr.c >
