April 2022 - U-Boot

[PATCH 1/6] led: Move OF "label" property parsing to core
by Marek Vasut 15 Apr '22

15 Apr '22

Every driver in drivers/led/ currently does some form of "label" OF property parsing in its bind() callback. Move this label parsing to LED core, since this "label" OF property is a generic property. This permits code deduplication in subseuqent patches. Signed-off-by: Marek Vasut <marex(a)denx.de> Cc: Alex Nemirovsky <alex.nemirovsky(a)cortina-access.com> Cc: Patrick Delaunay <patrick.delaunay(a)foss.st.com> Cc: Philippe Reynes <philippe.reynes(a)softathome.com> Cc: Sean Anderson <seanga2(a)gmail.com> Cc: Simon Glass <sjg(a)chromium.org> Cc: Steven Lawrance <steven.lawrance(a)softathome.com> --- drivers/led/led-uclass.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/led/led-uclass.c b/drivers/led/led-uclass.c index 7e298dbb06f..2f4aa18fb10 100644 --- a/drivers/led/led-uclass.c +++ b/drivers/led/led-uclass.c @@ -95,8 +95,20 @@ int led_default_state(void) return ret; } +static int led_post_bind(struct udevice *dev) +{ + struct led_uc_plat *uc_plat = dev_get_uclass_plat(dev); + + uc_plat->label = dev_read_string(dev, "label"); + if (!uc_plat->label) + uc_plat->label = ofnode_get_name(dev_ofnode(dev)); + + return 0; +} + UCLASS_DRIVER(led) = { .id = UCLASS_LED, .name = "led", .per_device_plat_auto = sizeof(struct led_uc_plat), + .post_bind = led_post_bind, }; -- 2.35.1

2 15

[PATCH] misc: atsha204a: Fix big endian support
by Pali Rohár 15 Apr '22

15 Apr '22

Callers of function atsha204a_crc16() expect to return value in host cpu endianity. So remove cpu_to_le16() conversion. Signed-off-by: Pali Rohár <pali(a)kernel.org> --- drivers/misc/atsha204a-i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/misc/atsha204a-i2c.c b/drivers/misc/atsha204a-i2c.c index b89463babb56..63fe541dade3 100644 --- a/drivers/misc/atsha204a-i2c.c +++ b/drivers/misc/atsha204a-i2c.c @@ -146,7 +146,7 @@ static u16 atsha204a_crc16(const u8 *buffer, size_t len) while (len--) crc = crc16_byte(crc, *buffer++); - return cpu_to_le16(crc); + return crc; } static int atsha204a_send(struct udevice *dev, const u8 *buf, u8 len) -- 2.20.1

4 7

[PATCH] power: domain: ti: Extend use of PTCMD and PTSTAT registers for high PDs
by Dave Gerlach 15 Apr '22

15 Apr '22

It is possible for power domain IDs to be great than 31. If this happens, the PTCMD and PTSTAT registers must overflow into adjacent corresponding PTCMD_H and PTSTAT_H registers for each. Update the driver to account for this. Signed-off-by: Dave Gerlach <d-gerlach(a)ti.com> --- drivers/power/domain/ti-power-domain.c | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/drivers/power/domain/ti-power-domain.c b/drivers/power/domain/ti-power-domain.c index b45e9b824539..cf20acd1a322 100644 --- a/drivers/power/domain/ti-power-domain.c +++ b/drivers/power/domain/ti-power-domain.c @@ -16,7 +16,9 @@ #include <linux/iopoll.h> #define PSC_PTCMD 0x120 +#define PSC_PTCMD_H 0x124 #define PSC_PTSTAT 0x128 +#define PSC_PTSTAT_H 0x12C #define PSC_PDSTAT 0x200 #define PSC_PDCTL 0x300 #define PSC_MDSTAT 0x800 @@ -115,10 +117,17 @@ static int ti_power_domain_probe(struct udevice *dev) static int ti_pd_wait(struct ti_pd *pd) { u32 ptstat; + u32 pdoffset = 0; + u32 ptstatreg = PSC_PTSTAT; int ret; - ret = readl_poll_timeout(pd->psc->base + PSC_PTSTAT, ptstat, - !(ptstat & BIT(pd->id)), PD_TIMEOUT); + if (pd->id > 31) { + pdoffset = 32; + ptstatreg = PSC_PTSTAT_H; + } + + ret = readl_poll_timeout(pd->psc->base + ptstatreg, ptstat, + !(ptstat & BIT(pd->id - pdoffset)), PD_TIMEOUT); if (ret) printf("%s: psc%d, pd%d failed to transition.\n", __func__, @@ -129,7 +138,15 @@ static int ti_pd_wait(struct ti_pd *pd) static void ti_pd_transition(struct ti_pd *pd) { - psc_write(BIT(pd->id), pd->psc, PSC_PTCMD); + u32 pdoffset = 0; + u32 ptcmdreg = PSC_PTCMD; + + if (pd->id > 31) { + pdoffset = 32; + ptcmdreg = PSC_PTCMD_H; + } + + psc_write(BIT(pd->id - pdoffset), pd->psc, ptcmdreg); } u8 ti_pd_state(struct ti_pd *pd) -- 2.35.0

2 1

[PATCH v3 01/12] rockchip: rk3228-power: sync power domain dt-binding header from Linux
by Johan Jonker 15 Apr '22

15 Apr '22

In order to update the DT for rk3228 sync the power domain dt-binding header. This is the state as of v5.17 in Linux. Signed-off-by: Johan Jonker <jbx6244(a)gmail.com> Reviewed-by: Simon Glass <sjg(a)chromium.org> --- include/dt-bindings/power/rk3228-power.h | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 include/dt-bindings/power/rk3228-power.h diff --git a/include/dt-bindings/power/rk3228-power.h b/include/dt-bindings/power/rk3228-power.h new file mode 100644 index 00000000..6a8dc1bf --- /dev/null +++ b/include/dt-bindings/power/rk3228-power.h @@ -0,0 +1,21 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef __DT_BINDINGS_POWER_RK3228_POWER_H__ +#define __DT_BINDINGS_POWER_RK3228_POWER_H__ + +/** + * RK3228 idle id Summary. + */ + +#define RK3228_PD_CORE 0 +#define RK3228_PD_MSCH 1 +#define RK3228_PD_BUS 2 +#define RK3228_PD_SYS 3 +#define RK3228_PD_VIO 4 +#define RK3228_PD_VOP 5 +#define RK3228_PD_VPU 6 +#define RK3228_PD_RKVDEC 7 +#define RK3228_PD_GPU 8 +#define RK3228_PD_PERI 9 +#define RK3228_PD_GMAC 10 + +#endif -- 2.20.1

4 29

[PATCH v4 00/12] efi_loader: more tightly integrate UEFI disks to driver model
by AKASHI Takahiro 15 Apr '22

15 Apr '22

With this patch set[1] applied, UEFI subsystem maintains a list of its disk objects dynamically at runtime based on block device's probing. (See "issues" and "prerequisite" below.) [1] https://github.com/t-akashi/u-boot/tree/efi/dm_disk For instance, => dm tree Class Index Probed Driver Name ----------------------------------------------------------- root 0 [ + ] root_driver root_driver ... pci 0 [ + ] pci_generic_ecam |-- pcie@10000000 ... ahci 0 [ ] ahci_pci | |-- ahci_pci scsi 0 [ ] ahci_scsi | | `-- ahci_scsi usb 0 [ ] xhci_pci | `-- xhci_pci ... => efi devices Missing RNG device for EFI_RNG_PROTOCOL No EFI system partition Unable to find TPMv2 device Device Device Path ================ ==================== 000000013eee88d0 /VenHw(..) 000000013ffeb798 /VenHw(..)/Uart(0,0,D,D) 000000013eeeb810 /VenHw(..)/MAC(525252525252,1) => scsi rescan ... => efi devices Device Device Path ================ ==================== 000000013eee88d0 /VenHw(..) 000000013ffeb798 /VenHw(..)/Uart(0,0,D,D) 000000013eeeb810 /VenHw(..)/MAC(525252525252,1) 000000013eefb730 /VenHw(..)/Scsi(0,0) 000000013eefb840 /VenHw(..)/Scsi(0,0)/HD(1,GPT,ce86c5a7-b32a-488f-a346-88fe698e0edc,0x22,0x4c2a) 000000013eefbc80 /VenHw(..)/Scsi(0,0)/HD(2,GPT,aa80aab9-33e6-42b6-b5db-def2cb8d7844,0x5000,0x1a800) => usb start ... => efi devices Device Device Path ================ ==================== 000000013eee88d0 /VenHw(..) 000000013ffeb798 /VenHw(..)/Uart(0,0,D,D) 000000013eeeb810 /VenHw(..)/MAC(525252525252,1) 000000013eefb730 /VenHw(..)/Scsi(0,0) 000000013eefb840 /VenHw(..)/Scsi(0,0)/HD(1,GPT,ce86c5a7-b32a-488f-a346-88fe698e0edc,0x22,0x4c2a) 000000013eefbc80 /VenHw(..)/Scsi(0,0)/HD(2,GPT,aa80aab9-33e6-42b6-b5db-def2cb8d7844,0x5000,0x1a800) 000000013ef01330 /VenHw(..)/UsbClass(0x0,0x0,0x9,0x0,0x3)/UsbClass(0x46f4,0x1,0x0,0x0,0x0) 000000013ef014b0 /VenHw(..)/UsbClass(0x0,0x0,0x9,0x0,0x3)/UsbClass(0x46f4,0x1,0x0,0x0,0x0)/HD(1,GPT,ce86c5a7-b32a-488f-a346-88fe698e0edc,0x22,0x4c2a) 000000013ef018f0 /VenHw(..)/UsbClass(0x0,0x0,0x9,0x0,0x3)/UsbClass(0x46f4,0x1,0x0,0x0,0x0)/HD(2,GPT,aa80aab9-33e6-42b6-b5db-def2cb8d7844,0x5000,0x1a800) => dm tree ... pci 0 [ + ] pci_generic_ecam |-- pcie@10000000 ... ahci 0 [ + ] ahci_pci | |-- ahci_pci scsi 0 [ + ] ahci_scsi | | `-- ahci_scsi blk 2 [ + ] scsi_blk | | `-- ahci_scsi.id0lun0 partition 0 [ + ] blk_partition | | |-- ahci_scsi.id0lun0:1 partition 1 [ + ] blk_partition | | `-- ahci_scsi.id0lun0:2 usb 0 [ + ] xhci_pci | `-- xhci_pci usb_hub 0 [ + ] usb_hub | `-- usb_hub usb_mass_s 0 [ + ] usb_mass_storage | |-- usb_mass_storage blk 3 [ + ] usb_storage_blk | | `-- usb_mass_storage.lun0 partition 2 [ + ] blk_partition | | |-- usb_mass_storage.lun0:1 partition 3 [ + ] blk_partition | | `-- usb_mass_storage.lun0:2 ... => usb stop stopping USB.. => efi devices Device Device Path ================ ==================== 000000013eee88d0 /VenHw(..) 000000013ffeb798 /VenHw(..)/Uart(0,0,D,D) 000000013eeeb810 /VenHw(..)/MAC(525252525252,1) 000000013eefb730 /VenHw(..)/Scsi(0,0) 000000013eefb840 /VenHw(..)/Scsi(0,0)/HD(1,GPT,ce86c5a7-b32a-488f-a346-88fe698e0edc,0x22,0x4c2a) 000000013eefbc80 /VenHw(..)/Scsi(0,0)/HD(2,GPT,aa80aab9-33e6-42b6-b5db-def2cb8d7844,0x5000,0x1a800) Issues: ======= * Some (UEFI-unrelated) UT tests still fail for a unknown reason. As I reported[2], this might happen due to U-Boot itself or UT framework. * For removal case, we may need more consideration since removing handles unconditionally may end up breaking integrity of handles (as some may still be held and referenced to by a UEFI app). [2] https://lists.denx.de/pipermail/u-boot/2022-April/481405.html Prerequisite: ============= * my patch, "disk: don't compile in partition support for spl/tpl if not really necessary"[3] [3] https://lists.denx.de/pipermail/u-boot/2022-April/481531.html Patchs: ======= For easy understandings, patches may be categorized into separate groups of changes. Patch#1-#3: DM: add a new feature (DM tag) Patch#4-#10: UEFI: dynamically create/remove efi_disk's for a raw disk and its partitions Patch#11-#12: UEFI: use udevice read/write interfaces Change history: =============== v4 (Apr, 15, 2022) * rebased on pre-2022.07-rc1 * removed already-merged patches * added patch#1 (for better error code) * merged v3's patch#19 to patch#7 to make bisect work * split v3's patch#13 into patch#8(create) and patch#10(delete) * move a function prototype out of "#ifdef CONFIG_PARTITIONS" (patch#4) * move function prototypes out of "#ifdef CONFIG_PARTITIONS" (patch#11) v3 (Mar 8, 2022) * rebased on 2022.04-rc3 * rebased on v2 of Simon's event patch (hence removed his patch from this patch set) * fix a spl-build error in mmc_blk_probe() (patch#3) * fix a build warning in fsl_ata_probe()/sil_pci_probe() (patch#5) * remove a problematic log message in efi_disk_probe() (patch#14) v2 (Feb 10, 2022) * add/revise an error message if device_probe() fails (patch#3,#5) * fix a build error in sandbox_spl_defconfig (patch#8) * fix warnings in 'make htmldocs' (patch#8,#9,#18) * new commit: split efi_init_obj_list() (patch#14) * new commit: simplify efi_capsule pytest (patch#21) v1 (Feb 2, 2022) * rebased on 2022.04-rc1 * drop patches that have already been merged * modify a tag-range check with "tag >= DM_TAG_COUNT" (patch#9) * move dmtag_list to GD (global data) (patch#9) * add function descriptions and a document about DM tag feature (patch#9,10) * add tests for DM tag support (patch#11) * change 'depends on EVENT' to 'select EVENT' for EFI_LOADER (patch#14) * migrate IF_TYPE_EFI to IF_TYPE_EFI_LOADER (patch#18) RFCv2 (Dec 10, 2021) * rebased on 2022-rc3 * re-order and merge some related commits into ones * call device_probe() in MMC (not bind, but) probe hook (patch#5) * fix a wrong name of variable (patch#7) * add patch#9 * invoke device_probe() for virtio devices (patch#10) * add DM event notification (from Simon) (patch#11) * add DM tag support (patch#12) * move UCLASS_PARTITION driver under disk/ (patch#13) * create partition's dp using its parent's. This change is necessary in particular for 'efi_blk' efi_disk (patch#13) * modify the code so that we will use new features like tags and event notification (patch#13,15,16,20) * rename new functions from blk_read/write() to dev_read/write() (patch#17,18) * isolate changes in efi_driver from the rest (in efi_loader) (patch#19) * drop the previous patch#22 ("efi_selftest: block device: adjust dp for a test") due to the fix in patch#13 RFC (Nov 16, 2021) * initial RFC AKASHI Takahiro (12): dm: tag: change ENOSPC to ENOMEM dm: tag: add some document test: dm: add tests for tag support dm: disk: add UCLASS_PARTITION dm: blk: add a device-probe hook for scanning disk partitions efi_loader: split efi_init_obj_list() into two stages efi_loader: disk: a helper function to create efi_disk objects from udevice efi_loader: disk: not create BLK device for BLK(IF_TYPE_EFI_LOADER) devices efi_loader: disk: a helper function to delete efi_disk objects efi_loader: disk: not delete BLK device for BLK(IF_TYPE_EFI_LOADER) devices dm: disk: add read/write interfaces with udevice efi_loader: disk: use udevice instead of blk_desc common/board_r.c | 2 +- common/main.c | 7 +- disk/Makefile | 3 + disk/disk-uclass.c | 247 ++++++++++++++++++++++ doc/develop/driver-model/design.rst | 20 ++ drivers/block/blk-uclass.c | 4 + drivers/core/tag.c | 4 +- include/dm/uclass-id.h | 1 + include/efi_loader.h | 6 +- include/part.h | 17 ++ lib/efi_driver/efi_block_device.c | 34 +-- lib/efi_loader/Kconfig | 3 + lib/efi_loader/efi_disk.c | 314 +++++++++++++++++++++------- lib/efi_loader/efi_setup.c | 62 ++++-- test/dm/Makefile | 1 + test/dm/tag.c | 84 ++++++++ 16 files changed, 685 insertions(+), 124 deletions(-) create mode 100644 disk/disk-uclass.c create mode 100644 test/dm/tag.c -- 2.33.0

3 14

[PATCH v8 0/8] efi: capsule: Capsule Update fixes and enhancements
by Sughosh Ganu 15 Apr '22

15 Apr '22

This series is cleaning up the usage of the image GUIDs that are used in capsule update and the EFI System Resource Table(ESRT). There are some other enhancements being made to the capsule update code to make it more robust. Firstly, an overview of the fixes being made. Currently, there are two instances of the Firmware Management Protocol(FMP), one defined for updating the FIT images, and the other for updating raw images. The FMP code defines two GUID values, one for all FIT images, and one for raw images. Depending on the FMP instance used on a platform, the platform needs to use the corresponding image GUID value for all images on the platform, and also across platforms. A few issues are being fixed through the patch series. One, that an image for a different platform can be flashed on another platform if both the platforms are using the same FMP instance. So, for e.g. a capsule generated for the Socionext DeveloperBox platform can be flashed on the ZynqMP platform, since both the platforms use the CONFIG_EFI_CAPSULE_FIRMWARE_RAW instance of the FMP. This can be corrected if each firmware image that can be updated through the capsule update mechanism has it's own unique image GUID. The second issue that this patch series fixes is the value of FwClass in the ESRT. With the current logic, all firmware image entries in the ESRT display the same GUID value -- either the FIT GUID or the raw GUID. This is not in compliance with the UEFI specification, as the specification requires all entries to have unique GUID values. The third issue being fixed is the population of the EFI_FIRMWARE_IMAGE_DESCRIPTOR array. The current code uses the dfu framework for populating the image descriptor array. However, there might be other images that are not to be updated through the capsule update mechanism also registered with the dfu framework. As a result of this, the ESRT will show up entries of images that are not to be targeted by the capsule update mechanism. These issues are being fixed by defining a structure, efi_fw_images. A platform can then define image related information like the image GUID and image name. Every platform that uses capsule update mechanism needs to define fw_images array. This array will then be used to populate the image descriptor array, and also in determining if a particular capsule's payload can be used for updating an image on the platform. The other part of the patches are some enhancements being made to the capsule update code to make it more robust. The first enhancement being made is to have a check for the image index being passed through the capsule header. The capsule update code uses the image index value as the dfu alt number, which points to the partition to which the update must be made. The platform is supposed to define the image index value for the updatable firmare images as part of the fw_images array. This value must correspond to the dfu alt num for the corresponding image, and can be obtained by checking the output of the 'dfu list' u-boot command. At the time of update, the image index being passed through the capsule is checked against the image index value obtained from the platform. The second enhancement made is the retrieval of the dfu_alt_info variable from the set_dfu_alt_info function instead of using the value defined in the environment. The dfu framework checks for the existence of this function, and if the function is not defined, gets the value from the environment. This can cause in an incorrect update if the environment variable value is incorrect. A weak function is defined for populating dfu_alt_info from the information obtained from the platform. This function gets invoked on all platforms which enabled capsule update feature. The first patch adds the structure efi_capsule_update_info and initialises the structure on all platforms which enable capsule update feature The second patch populates the image descriptor array in the GetImageInfo function with the values from the fw_images array defined in the board file The third patch adds a check for the image index value from the capsule header against the value obtained from the fw_images array for the corresponding image The fourth patch defines a weak function set_dfu_alt_info which is used to populate dfu_alt_info to be used for capsule updates. The fifth patch splits the capsule update test script into two, one for FMP for raw images, and one for FMP for FIT images. The test for FIT images is being enabled on the sandbox_flattree variant. The sixth patch removes the now unused FIT and raw image GUID values from the FMP module. The seventh patch removes the --raw and --fit command line parameters in the mkeficapsule utility. The eighth patch makes corresponding changes in the capsule update related documentation. Changes since V7: ----------------- * Fix a typo in the function description of efi_fill_image_desc_array * Add a comment about using update_info variable Changes since V6: ----------------- * Renamed struct efi_fw_images as struct efi_fw_image as suggested by Takahiro * Made corresponding change in all board files based on the rename done * Use renamed struct efi_fw_image instead of struct efi_fw_images * Reword the commit message to highlight the reason for removing --fit and --raw options as suggested by Takahiro * Remove the --fit and --raw description in the mkeficapsule man page * Add example for the struct efi_fw_image array and struct efi_capsule_update_info as suggested by Takahiro Changes since V5: ----------------- * Create a separate entry in fw_images array per config for boards with multiple configs as suggested by Heinrich. * Removed CONFIG_IS_ENABLED(EFI_HAVE_CAPSULE_SUPPORT) check in the board config headers, as suggested by Heinrich. * Add a check in the set_dfu_alt_info functions for the xilinx and qemu platforms to get the board defined value of dfu_alt_info when capsule update feature is enabled. * Simplify the set_dfu_alt_info function definition to set the variable directly from dfu_string, as suggested by Heinrich. * Restart the platform before starting the tests. This is done to clear out any stale state from a previously run test. Changes since V4: ----------------- * Define a structure efi_capsule_update_info which includes the string for populating dfu_alt_info * Initialise the string for dfu_alt_info in the board file * Drop the image_count variable as was suggested by Ilias * Drop another unused variable names_len * Define a weak function set_dfu_alt_info for setting the variable in a non board specific file as suggested by Ilias * Drop the definitions of set_dfu_alt_info that were being added in the board files * Change the description of the platform data based on the changes made in earlier patches Changes since V3: ----------------- * Do not remove the existing dfu_alt_info definitions made by platforms in the config files, as discussed with Masami. * Squash the selection of the SET_DFU_ALT_INFO config symbol for capsule update feature as part of this patch. * Rephrase the commit message to indicate that the doc changes are not just limited to adding the GUID values, but other info as well. * Elaborate with an example on the relation between the dfu alt number and the image index Changes since V2: ----------------- * Add a new member image_index to the struct efi_fw_images to allow the platforms to define the values for images. * Address review comments from Michal Simek for the xilinx boards. * Fix double inclusion of efi_loader.h as was pointed out by Heiko Thiery. * Use the image index values defined in the platform's fw_images array for the image descriptors * Add a description for adding image index value and definition of set_dfu_alt_info function for the capsule updates. Changes since V1: ----------------- * Make changes for the xilinx boards as suggested by Michal Simek. * Add a GUID for the sandbox FIT image. * Split the capsule update test cases into two scripts, one for raw images and one for FIT images. * Add the capsule update test case for FIT images on sandbox64 and sandbox_flattree variants. * Add capsule update support on sandbox_flattree variant for enabling FIT capsule update testing as part of the python tests Sughosh Ganu (8): capsule: board: Add information needed for capsule updates capsule: FMP: Populate the image descriptor array from platform data capsule: Put a check for image index before the update efi: Define set_dfu_alt_info() for boards with UEFI capsule update enabled test: capsule: Modify the capsule tests to use GUID values for sandbox FMP: Remove GUIDs for FIT and raw images mkeficapsule: Remove raw and FIT GUID types doc: uefi: Update the capsule update related documentation .../imx8mp_rsb3720a1/imx8mp_rsb3720a1.c | 29 +++ .../imx8mm-cl-iot-gate/imx8mm-cl-iot-gate.c | 28 +++ board/emulation/common/qemu_dfu.c | 3 +- board/emulation/qemu-arm/qemu-arm.c | 28 +++ board/kontron/pitx_imx8m/pitx_imx8m.c | 21 +- board/kontron/sl-mx8mm/sl-mx8mm.c | 20 ++ board/kontron/sl28/sl28.c | 21 ++ board/sandbox/sandbox.c | 34 ++++ board/socionext/developerbox/developerbox.c | 33 +++ board/xilinx/common/board.c | 28 +++ board/xilinx/zynq/board.c | 3 +- board/xilinx/zynqmp/zynqmp.c | 3 +- configs/sandbox64_defconfig | 1 - configs/sandbox_defconfig | 1 - configs/sandbox_flattree_defconfig | 5 + doc/develop/uefi/uefi.rst | 100 ++++++++- doc/mkeficapsule.1 | 12 -- include/configs/imx8mm-cl-iot-gate.h | 9 + include/configs/imx8mp_rsb3720.h | 9 + include/configs/kontron-sl-mx8mm.h | 5 + include/configs/kontron_pitx_imx8m.h | 5 + include/configs/kontron_sl28.h | 5 + include/configs/qemu-arm.h | 9 + include/configs/sandbox.h | 13 ++ include/configs/synquacer.h | 13 ++ include/configs/xilinx_versal.h | 5 + include/configs/xilinx_zynqmp.h | 9 + include/configs/zynq-common.h | 9 + include/efi_api.h | 8 - include/efi_loader.h | 36 ++++ lib/efi_loader/Kconfig | 2 + lib/efi_loader/efi_capsule.c | 8 +- lib/efi_loader/efi_firmware.c | 107 ++++------ test/py/tests/test_efi_capsule/conftest.py | 21 +- .../test_capsule_firmware_fit.py | 191 ++++++++++++++++++ ...rmware.py => test_capsule_firmware_raw.py} | 167 ++++++--------- tools/eficapsule.h | 8 - tools/mkeficapsule.c | 26 +-- 38 files changed, 784 insertions(+), 251 deletions(-) create mode 100644 test/py/tests/test_efi_capsule/test_capsule_firmware_fit.py rename test/py/tests/test_efi_capsule/{test_capsule_firmware.py => test_capsule_firmware_raw.py} (75%) -- 2.25.1

1 8

[PATCH v3] board: gateworks: venice: enable DM_SERIAL
by Tim Harvey 15 Apr '22

15 Apr '22

Enable DM_SERIAL for both U_Boot and the SPL. The uart2 and its pinmux are already marked with u-boot,dm-spl but we need to move the call to preloader_console_init() after spl_early_init() to avoid a board hang as dm can't be used until after spl_early_init(). Remove the manual config of the UART pinmux now that it is no longer needed. Signed-off-by: Tim Harvey <tharvey(a)gateworks.com> Cc: Michael Nazzareno Trimarchi <michael(a)amarulasolutions.com> --- v3: enable DM_SERIAL for SPL as well per Michael's suggestion v2: rebase on imx/master --- board/gateworks/venice/spl.c | 17 ++--------------- configs/imx8mm_venice_defconfig | 1 + configs/imx8mn_venice_defconfig | 1 + 3 files changed, 4 insertions(+), 15 deletions(-) diff --git a/board/gateworks/venice/spl.c b/board/gateworks/venice/spl.c index b56e1b607d58..59a6a29f70d8 100644 --- a/board/gateworks/venice/spl.c +++ b/board/gateworks/venice/spl.c @@ -87,25 +87,14 @@ static void spl_dram_init(int size) ddr_init(dram_timing); } -#define UART_PAD_CTRL (PAD_CTL_DSE6 | PAD_CTL_FSEL1) #define WDOG_PAD_CTRL (PAD_CTL_DSE6 | PAD_CTL_ODE | PAD_CTL_PUE | PAD_CTL_PE) #ifdef CONFIG_IMX8MM -static iomux_v3_cfg_t const uart_pads[] = { - IMX8MM_PAD_UART2_RXD_UART2_RX | MUX_PAD_CTRL(UART_PAD_CTRL), - IMX8MM_PAD_UART2_TXD_UART2_TX | MUX_PAD_CTRL(UART_PAD_CTRL), -}; - static iomux_v3_cfg_t const wdog_pads[] = { IMX8MM_PAD_GPIO1_IO02_WDOG1_WDOG_B | MUX_PAD_CTRL(WDOG_PAD_CTRL), }; #endif #ifdef CONFIG_IMX8MN -static const iomux_v3_cfg_t uart_pads[] = { - IMX8MN_PAD_UART2_RXD__UART2_DCE_RX | MUX_PAD_CTRL(UART_PAD_CTRL), - IMX8MN_PAD_UART2_TXD__UART2_DCE_TX | MUX_PAD_CTRL(UART_PAD_CTRL), -}; - static const iomux_v3_cfg_t wdog_pads[] = { IMX8MN_PAD_GPIO1_IO02__WDOG1_WDOG_B | MUX_PAD_CTRL(WDOG_PAD_CTRL), }; @@ -119,8 +108,6 @@ int board_early_init_f(void) set_wdog_reset(wdog); - imx_iomux_v3_setup_multiple_pads(uart_pads, ARRAY_SIZE(uart_pads)); - return 0; } @@ -232,8 +219,6 @@ void board_init_f(ulong dummy) timer_init(); - preloader_console_init(); - /* Clear the BSS. */ memset(__bss_start, 0, __bss_end - __bss_start); @@ -243,6 +228,8 @@ void board_init_f(ulong dummy) hang(); } + preloader_console_init(); + ret = uclass_get_device_by_name(UCLASS_CLK, "clock-controller@30380000", &dev); diff --git a/configs/imx8mm_venice_defconfig b/configs/imx8mm_venice_defconfig index dd61ec9b70fb..1ccbe9970a6c 100644 --- a/configs/imx8mm_venice_defconfig +++ b/configs/imx8mm_venice_defconfig @@ -110,6 +110,7 @@ CONFIG_SPL_DM_PMIC_MP5416=y CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y +CONFIG_DM_SERIAL=y CONFIG_MXC_UART=y CONFIG_SYSRESET=y CONFIG_SPL_SYSRESET=y diff --git a/configs/imx8mn_venice_defconfig b/configs/imx8mn_venice_defconfig index c3a96a378553..ff926dac0e18 100644 --- a/configs/imx8mn_venice_defconfig +++ b/configs/imx8mn_venice_defconfig @@ -108,6 +108,7 @@ CONFIG_SPL_DM_PMIC_MP5416=y CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y +CONFIG_DM_SERIAL=y CONFIG_MXC_UART=y CONFIG_SYSRESET=y CONFIG_SPL_SYSRESET=y -- 2.17.1

4 6

[PATCH v7 0/8] efi: capsule: Capsule Update fixes and enhancements
by Sughosh Ganu 15 Apr '22

15 Apr '22

This series is cleaning up the usage of the image GUIDs that are used in capsule update and the EFI System Resource Table(ESRT). There are some other enhancements being made to the capsule update code to make it more robust. Firstly, an overview of the fixes being made. Currently, there are two instances of the Firmware Management Protocol(FMP), one defined for updating the FIT images, and the other for updating raw images. The FMP code defines two GUID values, one for all FIT images, and one for raw images. Depending on the FMP instance used on a platform, the platform needs to use the corresponding image GUID value for all images on the platform, and also across platforms. A few issues are being fixed through the patch series. One, that an image for a different platform can be flashed on another platform if both the platforms are using the same FMP instance. So, for e.g. a capsule generated for the Socionext DeveloperBox platform can be flashed on the ZynqMP platform, since both the platforms use the CONFIG_EFI_CAPSULE_FIRMWARE_RAW instance of the FMP. This can be corrected if each firmware image that can be updated through the capsule update mechanism has it's own unique image GUID. The second issue that this patch series fixes is the value of FwClass in the ESRT. With the current logic, all firmware image entries in the ESRT display the same GUID value -- either the FIT GUID or the raw GUID. This is not in compliance with the UEFI specification, as the specification requires all entries to have unique GUID values. The third issue being fixed is the population of the EFI_FIRMWARE_IMAGE_DESCRIPTOR array. The current code uses the dfu framework for populating the image descriptor array. However, there might be other images that are not to be updated through the capsule update mechanism also registered with the dfu framework. As a result of this, the ESRT will show up entries of images that are not to be targeted by the capsule update mechanism. These issues are being fixed by defining a structure, efi_fw_images. A platform can then define image related information like the image GUID and image name. Every platform that uses capsule update mechanism needs to define fw_images array. This array will then be used to populate the image descriptor array, and also in determining if a particular capsule's payload can be used for updating an image on the platform. The other part of the patches are some enhancements being made to the capsule update code to make it more robust. The first enhancement being made is to have a check for the image index being passed through the capsule header. The capsule update code uses the image index value as the dfu alt number, which points to the partition to which the update must be made. The platform is supposed to define the image index value for the updatable firmare images as part of the fw_images array. This value must correspond to the dfu alt num for the corresponding image, and can be obtained by checking the output of the 'dfu list' u-boot command. At the time of update, the image index being passed through the capsule is checked against the image index value obtained from the platform. The second enhancement made is the retrieval of the dfu_alt_info variable from the set_dfu_alt_info function instead of using the value defined in the environment. The dfu framework checks for the existence of this function, and if the function is not defined, gets the value from the environment. This can cause in an incorrect update if the environment variable value is incorrect. A weak function is defined for populating dfu_alt_info from the information obtained from the platform. This function gets invoked on all platforms which enabled capsule update feature. The first patch adds the structure efi_capsule_update_info and initialises the structure on all platforms which enable capsule update feature The second patch populates the image descriptor array in the GetImageInfo function with the values from the fw_images array defined in the board file The third patch adds a check for the image index value from the capsule header against the value obtained from the fw_images array for the corresponding image The fourth patch defines a weak function set_dfu_alt_info which is used to populate dfu_alt_info to be used for capsule updates. The fifth patch splits the capsule update test script into two, one for FMP for raw images, and one for FMP for FIT images. The test for FIT images is being enabled on the sandbox_flattree variant. The sixth patch removes the now unused FIT and raw image GUID values from the FMP module. The seventh patch removes the --raw and --fit command line parameters in the mkeficapsule utility. The eighth patch makes corresponding changes in the capsule update related documentation. Changes since V6: ----------------- * Renamed struct efi_fw_images as struct efi_fw_image as suggested by Takahiro * Made corresponding change in all board files based on the rename done * Use renamed struct efi_fw_image instead of struct efi_fw_images * Reword the commit message to highlight the reason for removing --fit and --raw options as suggested by Takahiro * Remove the --fit and --raw description in the mkeficapsule man page * Add example for the struct efi_fw_image array and struct efi_capsule_update_info as suggested by Takahiro Changes since V5: ----------------- * Create a separate entry in fw_images array per config for boards with multiple configs as suggested by Heinrich. * Removed CONFIG_IS_ENABLED(EFI_HAVE_CAPSULE_SUPPORT) check in the board config headers, as suggested by Heinrich. * Add a check in the set_dfu_alt_info functions for the xilinx and qemu platforms to get the board defined value of dfu_alt_info when capsule update feature is enabled. * Simplify the set_dfu_alt_info function definition to set the variable directly from dfu_string, as suggested by Heinrich. * Restart the platform before starting the tests. This is done to clear out any stale state from a previously run test. Changes since V4: ----------------- * Define a structure efi_capsule_update_info which includes the string for populating dfu_alt_info * Initialise the string for dfu_alt_info in the board file * Drop the image_count variable as was suggested by Ilias * Drop another unused variable names_len * Define a weak function set_dfu_alt_info for setting the variable in a non board specific file as suggested by Ilias * Drop the definitions of set_dfu_alt_info that were being added in the board files * Change the description of the platform data based on the changes made in earlier patches Changes since V3: ----------------- * Do not remove the existing dfu_alt_info definitions made by platforms in the config files, as discussed with Masami. * Squash the selection of the SET_DFU_ALT_INFO config symbol for capsule update feature as part of this patch. * Rephrase the commit message to indicate that the doc changes are not just limited to adding the GUID values, but other info as well. * Elaborate with an example on the relation between the dfu alt number and the image index Changes since V2: ----------------- * Add a new member image_index to the struct efi_fw_images to allow the platforms to define the values for images. * Address review comments from Michal Simek for the xilinx boards. * Fix double inclusion of efi_loader.h as was pointed out by Heiko Thiery. * Use the image index values defined in the platform's fw_images array for the image descriptors * Add a description for adding image index value and definition of set_dfu_alt_info function for the capsule updates. Changes since V1: ----------------- * Make changes for the xilinx boards as suggested by Michal Simek. * Add a GUID for the sandbox FIT image. * Split the capsule update test cases into two scripts, one for raw images and one for FIT images. * Add the capsule update test case for FIT images on sandbox64 and sandbox_flattree variants. * Add capsule update support on sandbox_flattree variant for enabling FIT capsule update testing as part of the python tests Sughosh Ganu (8): capsule: board: Add information needed for capsule updates capsule: FMP: Populate the image descriptor array from platform data capsule: Put a check for image index before the update efi: Define set_dfu_alt_info() for boards with UEFI capsule update enabled test: capsule: Modify the capsule tests to use GUID values for sandbox FMP: Remove GUIDs for FIT and raw images mkeficapsule: Remove raw and FIT GUID types doc: uefi: Update the capsule update related documentation .../imx8mp_rsb3720a1/imx8mp_rsb3720a1.c | 29 +++ .../imx8mm-cl-iot-gate/imx8mm-cl-iot-gate.c | 28 +++ board/emulation/common/qemu_dfu.c | 3 +- board/emulation/qemu-arm/qemu-arm.c | 28 +++ board/kontron/pitx_imx8m/pitx_imx8m.c | 21 +- board/kontron/sl-mx8mm/sl-mx8mm.c | 20 ++ board/kontron/sl28/sl28.c | 21 ++ board/sandbox/sandbox.c | 34 ++++ board/socionext/developerbox/developerbox.c | 33 +++ board/xilinx/common/board.c | 28 +++ board/xilinx/zynq/board.c | 3 +- board/xilinx/zynqmp/zynqmp.c | 3 +- configs/sandbox64_defconfig | 1 - configs/sandbox_defconfig | 1 - configs/sandbox_flattree_defconfig | 5 + doc/develop/uefi/uefi.rst | 98 ++++++++- doc/mkeficapsule.1 | 12 -- include/configs/imx8mm-cl-iot-gate.h | 9 + include/configs/imx8mp_rsb3720.h | 9 + include/configs/kontron-sl-mx8mm.h | 5 + include/configs/kontron_pitx_imx8m.h | 5 + include/configs/kontron_sl28.h | 5 + include/configs/qemu-arm.h | 9 + include/configs/sandbox.h | 13 ++ include/configs/synquacer.h | 13 ++ include/configs/xilinx_versal.h | 5 + include/configs/xilinx_zynqmp.h | 9 + include/configs/zynq-common.h | 9 + include/efi_api.h | 8 - include/efi_loader.h | 36 ++++ lib/efi_loader/Kconfig | 2 + lib/efi_loader/efi_capsule.c | 8 +- lib/efi_loader/efi_firmware.c | 104 +++------- test/py/tests/test_efi_capsule/conftest.py | 21 +- .../test_capsule_firmware_fit.py | 191 ++++++++++++++++++ ...rmware.py => test_capsule_firmware_raw.py} | 167 ++++++--------- tools/eficapsule.h | 8 - tools/mkeficapsule.c | 26 +-- 38 files changed, 781 insertions(+), 249 deletions(-) create mode 100644 test/py/tests/test_efi_capsule/test_capsule_firmware_fit.py rename test/py/tests/test_efi_capsule/{test_capsule_firmware.py => test_capsule_firmware_raw.py} (75%) -- 2.25.1

3 12

[PATCH 0/6] Add MV88E61xx DSA driver and use on gwventana
by Tim Harvey 14 Apr '22

14 Apr '22

This series adds a DSA driver for the MV88E61xx based on drivers/net/phy/mv88e61xx and uses in on the gwventana_gw5904_defconfig. The hope is that the other three boards that use the MV88E61xx driver can move to this as well eventually so that we can remove the non-dm driver and the 4 Kconfig options it requires. The MV88E61xx has an MDIO interface this DM_MDIO must be used so support for a UCLASS_MDIO driver is added to the fec_mxc ethernet driver in a way that allows a fallback to the previous non DM_MDIO case as there are many boards out there using this driver that define DM_MDIO but do not have the required dt props for a DM_MDIO driver which would cause a regression. Additionally a patch to ensure MDIO children are scanned on post-bind is needed. I'm making use of the dm_mdio_read/dm_mdio_write wrapper from Merak that is pending so it is in this series as well. Best Regards, Tim Tim Harvey (6): net: mdio-uclass: scan for dm mdio children on post-bind net: dsa: move cpu port probe to dsa_post_probe net: mdio-uclass: add wrappers for read/write/reset operations net: fec: add support for DM_MDIO net: add MV88E61xx DSA driver board: gw_ventana: enable MV88E61XX DSA support arch/arm/dts/imx6qdl-gw5904.dtsi | 35 + board/gateworks/gw_ventana/gw_ventana.c | 50 +- configs/gwventana_gw5904_defconfig | 7 +- drivers/net/Kconfig | 7 + drivers/net/Makefile | 1 + drivers/net/fec_mxc.c | 113 ++- drivers/net/fec_mxc.h | 1 + drivers/net/mv88e61xx.c | 982 ++++++++++++++++++++++++ include/miiphy.h | 31 + net/dsa-uclass.c | 14 +- net/mdio-uclass.c | 35 + 11 files changed, 1227 insertions(+), 49 deletions(-) create mode 100644 drivers/net/mv88e61xx.c -- 2.17.1

5 26

[PATCH] pci: fsl: Change compatible string for mpc8548 to "fsl, mpc8548-pcie"
by Pali Rohár 14 Apr '22

14 Apr '22

Upstream Linux kernel uses for mpc8548-based PCIe controllers compatible string "fsl,mpc8548-pcie". So change U-Boot fsl PCIe driver and all DTS files to use "fsl,mpc8548-pcie" instead of "fsl,pcie-mpc8548" to be compatible with Linux kernel. Signed-off-by: Pali Rohár <pali(a)kernel.org> --- arch/powerpc/dts/mpc8548-post.dtsi | 2 +- drivers/pci/pcie_fsl.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/dts/mpc8548-post.dtsi b/arch/powerpc/dts/mpc8548-post.dtsi index 2206f2da9feb..97c3ce6e74d6 100644 --- a/arch/powerpc/dts/mpc8548-post.dtsi +++ b/arch/powerpc/dts/mpc8548-post.dtsi @@ -27,7 +27,7 @@ }; &pcie { - compatible = "fsl,pcie-mpc8548", "fsl,pcie-fsl-qoriq"; + compatible = "fsl,mpc8548-pcie", "fsl,pcie-fsl-qoriq"; law_trgt_if = <2>; #address-cells = <3>; #size-cells = <2>; diff --git a/drivers/pci/pcie_fsl.c b/drivers/pci/pcie_fsl.c index cc6efdd5b464..be156daf8d49 100644 --- a/drivers/pci/pcie_fsl.c +++ b/drivers/pci/pcie_fsl.c @@ -646,7 +646,7 @@ static struct fsl_pcie_data t2080_data = { }; static const struct udevice_id fsl_pcie_ids[] = { - { .compatible = "fsl,pcie-mpc8548", .data = (ulong)&p1_p2_data }, + { .compatible = "fsl,mpc8548-pcie", .data = (ulong)&p1_p2_data }, { .compatible = "fsl,pcie-p1_p2", .data = (ulong)&p1_p2_data }, { .compatible = "fsl,pcie-p2041", .data = (ulong)&p2041_data }, { .compatible = "fsl,pcie-p3041", .data = (ulong)&p2041_data }, -- 2.20.1

1 0