Re: [PATCH v2 0/9] efi_loader: booting via short-form device-path
Heinrich, I made the same complaint several times in the past. If I made some comments on your patches, don't merge them until we have reached the agreement even you are the maintainer. It's not the way how the community development should work. This happened again with this patch series. -Takahiro Akashi On Sat, Mar 19, 2022 at 10:11:39AM +0100, Heinrich Schuchardt wrote: > The GUID of partitions is sufficient for identification and will stay > constant in the lifetime of a boot option. The preceding path of the > device-path may change due to changes in the enumeration of devices. > Therefore it is preferable to use the short-form of device-paths in load > options. > > > With this series booting via short-form device-paths is reenable. > The 'efidebug boot add' command is adjusted to create either short-form > or long-form device paths. > > The check for the EFI System Partition used for capsule updates is > corrected. > > A unit test for the boot manager is added. > > v2: > merge multiple patches to a series > fix ESP detection > > Heinrich Schuchardt (9): > efi_loader: export efi_dp_shorten() > efi_loader: fix efi_dp_find_obj() > efi_loader: efi_dp_find_obj() add protocol check > efi_loader: support booting via short-form device-path > efi_loader: use short-form DP for load options > efi_loader: export efi_system_partition_guid > efi_loader: remove efi_disk_is_system_part() > efi_loader: move dtbdump.c, initrddump.c to lib/efi_loader > test: test UEFI boot manager > > cmd/efidebug.c| 70 ++- > include/efi_loader.h | 12 +- > lib/efi_loader/Makefile | 12 + > lib/efi_loader/dtbdump.c | 539 ++ > lib/efi_loader/efi_boottime.c | 22 +- > lib/efi_loader/efi_capsule.c | 13 +- > lib/efi_loader/efi_device_path.c | 138 +++-- > lib/efi_loader/efi_disk.c | 31 +- > lib/efi_loader/initrddump.c | 449 +++ > lib/efi_selftest/Makefile | 12 - > lib/efi_selftest/dtbdump.c| 539 -- > lib/efi_selftest/initrddump.c | 449 --- > test/py/tests/test_efi_bootmgr/conftest.py| 42 ++ > .../test_efi_bootmgr/test_efi_bootmgr.py | 31 + > 14 files changed, 1232 insertions(+), 1127 deletions(-) > create mode 100644 lib/efi_loader/dtbdump.c > create mode 100644 lib/efi_loader/initrddump.c > delete mode 100644 lib/efi_selftest/dtbdump.c > delete mode 100644 lib/efi_selftest/initrddump.c > create mode 100644 test/py/tests/test_efi_bootmgr/conftest.py > create mode 100644 test/py/tests/test_efi_bootmgr/test_efi_bootmgr.py > > -- > 2.34.1 >
Re: [PATCH 08/11] pci: Check region ranges are addressable
On Sun, Mar 20, 2022 at 7:42 PM Andrew Scull wrote: > > When parsing the `ranges` DT node, check that both extremes of the > regions are addressable without overflow. This assumption can then be > safely made when processing the regions. > > Signed-off-by: Andrew Scull > --- > drivers/pci/pci-uclass.c | 17 - > 1 file changed, 16 insertions(+), 1 deletion(-) > Reviewed-by: Bin Meng
Re: [PATCH 09/11] pci: Add function to validate PCI address range
On Sun, Mar 20, 2022 at 7:42 PM Andrew Scull wrote: > > Add a function to convert a PCI address range to a physical address > range. The address range is validated to ensure it is contained within > one of the PCI address regions and that the whole range can be indexed > from the resulting physical address. I am not sure if we need to provide such an API given there is already dm_pci_bus_to_phys() and friends. Not sure we really need this new API to add a check against the range. > > Signed-off-by: Andrew Scull > --- > drivers/pci/pci-uclass.c | 30 ++ > include/pci.h| 16 > 2 files changed, 46 insertions(+) > > diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c > index 54a05d7567..efab8916e2 100644 > --- a/drivers/pci/pci-uclass.c > +++ b/drivers/pci/pci-uclass.c > @@ -1452,6 +1452,36 @@ phys_addr_t dm_pci_bus_to_phys(struct udevice *dev, > pci_addr_t bus_addr, > return phys_addr; > } > > +phys_addr_t dm_pci_bus_range_to_phys(struct udevice *dev, pci_addr_t > bus_addr, > +size_t size, unsigned long mask, > +unsigned long flags) > +{ > + struct udevice *ctlr = pci_get_controller(dev); > + struct pci_controller *hose = dev_get_uclass_priv(ctlr); > + struct pci_region *res; > + size_t offset; > + int i; > + > + for (i = 0; i < hose->region_count; i++) { > + res = &hose->regions[i]; > + > + if ((res->flags & mask) != flags) > + continue; > + > + if (bus_addr < res->bus_start) > + continue; > + > + offset = bus_addr - res->bus_start; > + if (offset >= res->size || size > res->size - offset) > + continue; > + > + return res->phys_start + offset; > + } > + > + puts("pci_bus_range_to_phys: invalid address range\n"); > + return 0; > +} If we really need this, I believe we can do some refactoring on the existing _dm_pci_bus_to_phys() to provide the new capability you wanted. > + > static int _dm_pci_phys_to_bus(struct udevice *dev, phys_addr_t phys_addr, >unsigned long flags, unsigned long skip_mask, >pci_addr_t *ba) > diff --git a/include/pci.h b/include/pci.h > index 673c95c6bb..15b3031c1f 100644 > --- a/include/pci.h > +++ b/include/pci.h > @@ -1446,6 +1446,22 @@ u32 dm_pci_read_bar32(const struct udevice *dev, int > barnum); > phys_addr_t dm_pci_bus_to_phys(struct udevice *dev, pci_addr_t addr, >unsigned long flags); > > +/** > + * dm_pci_bus_range_to_phys() - convert a PCI bus address range to a physical > + * address. > + * > + * @dev: Device containing the PCI address > + * @addr: PCI address to convert > + * @size: Size of the addressrange need a space before 'range' > + * @mask: Mask of flags to match > + * @flags: Flags for the region type (PCI_REGION_...) > + * Return: physical address corresponding to that PCI bus address range or 0 > if > + *the range could not be converted > + */ > +phys_addr_t dm_pci_bus_range_to_phys(struct udevice *dev, pci_addr_t > bus_addr, > +size_t size, unsigned long mask, > +unsigned long flags); > + > /** > * dm_pci_phys_to_bus() - convert a physical address to a PCI bus address > * Please add a test case in test/dm/pci.c to cover this new API. Regards, Bin
Re: [PATCH 10/11] virtio: pci: Check mapped range is in a PCI region
On Sun, Mar 20, 2022 at 7:42 PM Andrew Scull wrote: > > The virtio PCI capabilities describe a region of memory that should be > mapped. Ensure those are valid PCI regions before accessing them. > > Signed-off-by: Andrew Scull > --- > drivers/virtio/virtio_pci_modern.c | 23 +++ > 1 file changed, 19 insertions(+), 4 deletions(-) > > diff --git a/drivers/virtio/virtio_pci_modern.c > b/drivers/virtio/virtio_pci_modern.c > index 2f1a1cedbc..84750e2b27 100644 > --- a/drivers/virtio/virtio_pci_modern.c > +++ b/drivers/virtio/virtio_pci_modern.c > @@ -457,8 +457,9 @@ static int virtio_pci_find_capability(struct udevice > *udev, u8 cfg_type, > static void __iomem *virtio_pci_map_capability(struct udevice *udev, >const struct virtio_pci_cap > *cap) > { > - ulong base; > - void __iomem *p; > + unsigned long mask, flags; > + phys_addr_t phys_addr; > + u32 base; > > if (!cap) > return NULL; > @@ -470,9 +471,23 @@ static void __iomem *virtio_pci_map_capability(struct > udevice *udev, > * For simplicity, only read the BAR address as 32-bit. > */ > base = dm_pci_read_bar32(udev, cap->bar); > - p = (void __iomem *)base + cap->offset; > > - return p; > + if (U32_MAX - base < cap->offset) > + return NULL; > + base += cap->offset; > + > + if (U32_MAX - base < cap->length) > + return NULL; > + > + /* Find the corresponding memory region that isn't system memory. */ > + mask = PCI_REGION_TYPE | PCI_REGION_SYS_MEMORY; > + flags = PCI_REGION_MEM; > + phys_addr = dm_pci_bus_range_to_phys(dev_get_parent(udev), base, > +cap->length, mask, flags); > + if (!phys_addr) > + return NULL; > + > + return (void __iomem *)map_physmem(phys_addr, cap->length, > MAP_NOCACHE); Could we use dm_pci_map_bar() instead? I understand the way the current patch does is to add some sanity checks against buggy virtio device implementations, but is it really necessary, or can we move such check somewhere else, like in the probe()? > } > > static int virtio_pci_bind(struct udevice *udev) > -- Regards, Bin
Re: [PATCH 11/11] virtio: pci: Allow exclusion of legacy driver
On Sun, Mar 20, 2022 at 7:42 PM Andrew Scull wrote: > > Add a new config to control whether the driver for legacy virtio PCI > devices is included in the build. VIRTIO_PCI_LEGACY is included by > default when VIRTIO_PCI is selected, but it can also be indepedently typo: independently > toggled. > > Signed-off-by: Andrew Scull > --- > drivers/virtio/Kconfig | 9 + > drivers/virtio/Makefile | 3 ++- > 2 files changed, 11 insertions(+), 1 deletion(-) > Otherwise, Reviewed-by: Bin Meng
Re: [PATCH] arm64: zynqmp: enable the PMUFW watchdog
On 3/24/22 22:03, Jorge Ramirez-Ortiz, Foundries wrote: On 24/03/22, Michal Simek wrote: On 3/23/22 15:04, Jorge Ramirez-Ortiz wrote: From 528b3117a36b7b4eea1839afbea7191d60638b0c Mon Sep 17 00:00:00 2001 From: Jorge Ramirez-Ortiz Date: Wed, 23 Mar 2022 14:41:15 +0100 Subject: [PATCH] arm64: zynqmp: enable the PMUFW watchdog If the PMUFW was built with support for the CSU watchdog we must let the firmware know that it can be started. We do this by faking the FSBL done state. Reference code in PMUFW: https://github.com/Xilinx/embeddedsw/blob/master/lib/sw_apps/zynqmp_pmufw/src/xpfw_mod_common.c#L36 It needs this fix on the PMUFW https://github.com/Xilinx/embeddedsw/pull/190 /* FSBL might not be running anywhere - i.e: SPL boots PMUFW */ SPL doesn't boot PMUFW. It is the first firmware in BOOT.BIN which is loaded by bootrom to PMU. It means comment is not correct. FSBL or SPL just sending PMU configuration object to PMUFW. yeah I guess it depends what you mean by boot - unless SPL configures it, it wont really boot to a functional state. but anyway ok, will change. Signed-off-by: Jorge Ramirez-Ortiz --- arch/arm/mach-zynqmp/include/mach/hardware.h | 5 - board/xilinx/zynqmp/zynqmp.c | 4 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-zynqmp/include/mach/hardware.h b/arch/arm/mach-zynqmp/include/mach/hardware.h index a70d6d611b..24c3ef3d7d 100644 --- a/arch/arm/mach-zynqmp/include/mach/hardware.h +++ b/arch/arm/mach-zynqmp/include/mach/hardware.h @@ -174,8 +174,11 @@ struct csu_regs { #define ZYNQMP_PMU_BASEADDR 0xFFD8 +#define FSBL_COMPLETION0x1 + struct pmu_regs { - u32 reserved[18]; + u32 reserved[17]; + u32 gen_storage5; /* 0x44 */ u32 gen_storage6; /* 0x48 */ }; diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c index 70b3c81f12..c88c5fb8ea 100644 --- a/board/xilinx/zynqmp/zynqmp.c +++ b/board/xilinx/zynqmp/zynqmp.c @@ -419,6 +419,10 @@ int board_init(void) zynqmp_pm_cfg_obj_size); printf("Silicon version:\t%d\n", zynqmp_get_silicon_version()); + /* fake FSBL completion to start the PMUFW watchdog when enabled */ + writel(readl(&pmu_base->gen_storage5) | FSBL_COMPLETION, + &pmu_base->gen_storage5); I look at the code in FSBL and it set it up XFsbl_HandoffExit which is at the end of FSBL. It means this should be setup in SPL not in U-Boot proper. not sure what you mean. This piece of code I am posting only executes in SPL, doesn it? ah. ok. Then fine. M
Re: [PATCH 07/11] virtio: pci: Check virtio configs are mapped
On Fri, Mar 25, 2022 at 3:07 PM Andrew Scull wrote: > > On Fri, 25 Mar 2022 at 04:38, Bin Meng wrote: > > > > On Sun, Mar 20, 2022 at 7:42 PM Andrew Scull wrote: > > > > > > The calls to `virtio_pci_map_capability()` return NULL on error. If this > > > happens, later accesses to the pointers would be unsafe. Avoid this by > > > failing if the configs were not successfully mapped. > > > > > > Signed-off-by: Andrew Scull > > > --- > > > drivers/virtio/virtio_pci_modern.c | 25 - > > > 1 file changed, 20 insertions(+), 5 deletions(-) > > > > > > diff --git a/drivers/virtio/virtio_pci_modern.c > > > b/drivers/virtio/virtio_pci_modern.c > > > index 38a0da0a84..2f1a1cedbc 100644 > > > --- a/drivers/virtio/virtio_pci_modern.c > > > +++ b/drivers/virtio/virtio_pci_modern.c > > > @@ -534,7 +534,19 @@ static int virtio_pci_probe(struct udevice *udev) > > > return -EINVAL; > > > } > > > > > > + /* Map configuration structures */ > > > + priv->common = virtio_pci_map_capability(udev, &common_cap); > > > + if (!priv->common) { > > > > This can't be NULL, as you did not pass a NULL capability pointer > > > > > + printf("(%s): could not map common config\n", udev->name); > > > + return -EINVAL; > > > + } > > > + > > > priv->notify_len = notify_cap.length; > > > + priv->notify_base = virtio_pci_map_capability(udev, ¬ify_cap); > > > + if (!priv->notify_base) { > > > + printf("(%s): could not map notify config\n", udev->name); > > > + return -EINVAL; > > > + } > > > > > > /* > > > * Device capability is only mandatory for devices that have > > > @@ -543,13 +555,16 @@ static int virtio_pci_probe(struct udevice *udev) > > > device = virtio_pci_find_capability(udev, > > > VIRTIO_PCI_CAP_DEVICE_CFG, > > > sizeof(struct virtio_pci_cap), > > > &device_cap); > > > - if (device) > > > + if (device) { > > > priv->device_len = device_cap.length; > > > + priv->device = virtio_pci_map_capability(udev, > > > &device_cap); > > > + if (!priv->device) { > > > + printf("(%s): could not map device config\n", > > > + udev->name); > > > + return -EINVAL; > > > + } > > > + } > > > > > > - /* Map configuration structures */ > > > - priv->common = virtio_pci_map_capability(udev, &common_cap); > > > - priv->notify_base = virtio_pci_map_capability(udev, ¬ify_cap); > > > - priv->device = virtio_pci_map_capability(udev, &device_cap); > > > debug("(%p): common @ %p, notify base @ %p, device @ %p\n", > > > udev, priv->common, priv->notify_base, priv->device); > > > > > > > I don't think adding these checks is necessary. > > See later patches in the series that validate the address range is > within the declared PCI ranges and not an arbitrary range chosen, > accidently or maliciously, by the device. If those checks fail, the > memory will not have been mapped and the probe should fail. Yep, I see additional checks being added in patch 10, so the patch order should be adjusted to let this patch come later. Regards, Bin
Re: [PATCH 06/11] virtio: pci: Read entire capability into memory
On Fri, Mar 25, 2022 at 3:03 PM Andrew Scull wrote: > > On Fri, 25 Mar 2022 at 04:31, Bin Meng wrote: > > > > On Sun, Mar 20, 2022 at 7:42 PM Andrew Scull wrote: > > > > > > Read the virtio PCI capability out of the device configuration space to > > > a struct rather than accessing fields directly from the configuration > > > space as they are needed. This both makes access to the fields easier > > > and avoids re-reading fields. > > > > > > Re-reading fields could result in time-of-check to time-of-use problems, > > > should the value in the configuration space change. The range check of > > > the `bar` field and the later call to `dm_pci_read_bar32()` is an > > > example of where this could happen. > > > > I don't see the need to avoid the time-of-check to time-of-use > > problems, as it can only happen with the PCI configuration access > > capability, which U-Boot driver does not touch. > > > > Am I missing something? > > U-Boot doesn't touch the configuration space but the device could > have, whether that be accidently or maliciously. Linux has taken > similar precautions [1] to add more safety checks and I'll be looking > to do the same in other parts of the u-boot virtio drivers. > > [1] -- https://lwn.net/Articles/865216 > Got it. So basically the problem is that we don't trust the host that implements the virtio device :) I am curious that under such a guideline, probably lots of device drivers need to be enhanced to do the sanity check, no? Regards, Bin
Re: [RFC PATCH 0/6] efi: capsule: Image GUID usage cleanup
hi Takahiro, On Fri, 25 Mar 2022 at 10:23, AKASHI Takahiro wrote: > > Sughosh, > > On Thu, Mar 24, 2022 at 06:08:55PM +0530, Sughosh Ganu wrote: > > > > This series is cleaning up the usage of the image GUIDs that are used > > in capsule update and the EFI System Resource Table(ESRT). > > > > 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. > > Ok although the specification doesn't explicitly require the uniqueness > "across platforms". Yes, but unless we have a single image running on multiple platforms, we do need different GUID values across platforms. > > > 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. > > Well, this is *not* a problem of fit FMP driver, but a matter of how > ESRT is populated. Table 23-16 "ESRT and FMP Fields" says, > The ImageTypeId GUID from the Firmware > Management Protocol instance for a device is > used as the Firmware Class GUID in the ESRT. > Where there are multiple identical devices in > the system, system firmware must create a > mapping to ensure that the ESRT FwClass > GUIDs are unique and consistent. > The second sentence suggests that UEFI implementation, i.e. > efi_esrt_populate(), may and should allow some *mapping*. > > That said, I basically accept the requirement that you mention above. > > > 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. > > When ESRT support patch was posted, I proposed that we should have > a kind of configuration table that defines all the firmware on the system > for ESRT, but this proposal was rejected. > Your efi_fw_images[] looks quite similar as what I had in mind. > Why not define efi_fw_images[] as ESRT itself. > (Of course, some fields in an entry can still be populated through > GetImageInfo API.) Currently, with this patch series, that is what is happening. The efi_fw_images array gets read by the GetImageInfo function, and that information gets used for populating the ESRT. Btw, I also want to extend this structure as part of a separate task, where we have information related to the dfu framework as part of the structure. Then the capsule related dfu information can be populated from this structure, instead of the dfu_alt_info env variable. This is what Ilias has suggested. But I will take this up as a separate exercise. > > > The first patch of this series adds the fw_images array in all > > platforms which are using UEFI capsule updates > > > > The second patch of the series changes the logic for populating the > > image descriptor array, using the information from the fw_images array > > defined by the platform. > > So a FIT image can still work as a single binary of firmware > under FIT FMP driver. Correct? Yes, this will still work. Only change is that every platform will have a separate image GUID for the FIT image. > > > The third patch of the series removes the test cases using the --raw >
[PATCH] Fix URLs to old freescale git repos
Freescale git repos are now on source.codeaurora.org. Signed-off-by: Pali Rohár --- doc/README.mpc85xx-sd-spi-boot | 2 +- drivers/misc/mxc_ocotp.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/README.mpc85xx-sd-spi-boot b/doc/README.mpc85xx-sd-spi-boot index e3f580446a1c..329de4e6c4c1 100644 --- a/doc/README.mpc85xx-sd-spi-boot +++ b/doc/README.mpc85xx-sd-spi-boot @@ -14,7 +14,7 @@ Where to get boot_format: you can browse it online at: -http://git.freescale.com/git/cgit.cgi/ppc/sdk/boot-format.git/ +https://source.codeaurora.org/external/qoriq/qoriq-yocto-sdk/boot-format Building diff --git a/drivers/misc/mxc_ocotp.c b/drivers/misc/mxc_ocotp.c index b1893a5c7eba..8ee18f29d9be 100644 --- a/drivers/misc/mxc_ocotp.c +++ b/drivers/misc/mxc_ocotp.c @@ -6,7 +6,7 @@ * Based on Dirk Behme's * https://github.com/dirkbehme/u-boot-imx6/blob/28b17e9/drivers/misc/imx_otp.c, * which is based on Freescale's - * http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/drivers/misc/imx_otp.c?h=imx_v2009.08_1.1.0&id=9aa74e6, + * https://source.codeaurora.org/external/imx/uboot-imx/tree/drivers/misc/imx_otp.c?id=9aa74e6, * which is: * Copyright (C) 2011 Freescale Semiconductor, Inc. */ -- 2.20.1
Re: [RFC PATCH 1/6] capsule: Add Image GUIDs for platforms using capsule updates
hi Masami, On Fri, 25 Mar 2022 at 10:58, Masami Hiramatsu wrote: > > Hi Sughosh, > > OK I understand that if the platform uses the FIT capsule, the > fw_images[] must have 1 entry and it is completely non relationship > with dfu_alt_info... We may need a document for this case too. Actually, what you are stating above applies to both raw images as well as FIT images. I have added a paragraph in the capsule update related section in the uefi.rst. Can you check my patch 4 of this series. Thanks. -sughosh > > Thanks, > > 2022年3月25日(金) 10:09 Masami Hiramatsu : > > > > Hi Sughosh, > > > > 2022年3月24日(木) 23:40 Sughosh Ganu : > > > > > > hi Masami, > > > > > > On Thu, 24 Mar 2022 at 19:14, Masami Hiramatsu > > > wrote: > > > > > > > > Hi Sughosh, > > > > > > > > 2022年3月24日(木) 21:39 Sughosh Ganu : > > > > > > > > > > Currently, all platforms that enable capsule updates do so using > > > > > either EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID or > > > > > EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID. This is based on the Firmware > > > > > Management Protocol(FMP) instance used on the platform. However, this > > > > > means that all platforms that enable a particular FMP instance have > > > > > the same GUID value for all the updatable images, either the FIT image > > > > > GUID or the raw image GUID, and that an image for some platform can be > > > > > updated on any other platform which uses the same FMP instance. > > > > > Another > > > > > issue with this implementation is that the ESRT table shows the same > > > > > GUID value for all images on the platform and also across platforms, > > > > > which is not in compliance with the UEFI specification. > > > > > > > > > > Fix this by defining image GUID values and firmware names for > > > > > individual images per platform. The GetImageInfo FMP hook would then > > > > > populate these values in the image descriptor array. > > > > > > > > OK, so you have generated GUIDs for each "dfu_alt_info" entry on the > > > > platforms, correct? > > > > > > No, I have generated the fw_images array based on the information that > > > I found in the dfu_alt_info variable for the platform. But this is not > > > correlated to the dfu_alt_info variable. If you think that the array > > > should have more/different entries for your platform, please let me > > > know, and I will change it. > > > > At least for the DeveloperBox, it looks good to me. > > (Hopefully, if you comment the string formatted GUID in the code for > > mkeficapsule, that is perfect. :) ) > > > > > > I think you should explain that those GUIDs (fw_images[] entries) must > > > > be corresponding to the dfu_alt_info entries, in the same order. > > > > > > The dfu_alt_info can have more entries than the firmware images that > > > are updatable through capsule update. One example is the ST platforms > > > which have additional entries in the dfu_alt_info. The image > > > descriptor array should only contain entries of images which are > > > updatable through capsule update, since the same information is also > > > used for generating the ESRT. Which is why I have changed the logic to > > > populate the image descriptors through the fw_images array rather than > > > the dfu_alt_info. > > > > I meant, the order of the fw_images array needs to be same as > > dfu_alt_info entries and the firmware entries for dfu_alt_info must be > > the first, because finally we will use the index of the fw_images > > array, which matched to given image type GUID, for specifying > > dfu_alt_info entry. > > Or, without dfu_alt_info, your new fw_images can update the firmware? > > I would like to see such *relationship* at least in the patch > > description and the documentation. > > > > Thank you, > > > > > > > > > > -sughosh > > > > > > > Without that, it is hard to understand why the next patch ([2/6]) works > > > > :-) > > > > > > > > Thank you, > > > > > > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > > --- > > > > > .../imx8mp_rsb3720a1/imx8mp_rsb3720a1.c | 19 +++ > > > > > .../imx8mm-cl-iot-gate/imx8mm-cl-iot-gate.c | 18 +++ > > > > > board/emulation/qemu-arm/qemu-arm.c | 20 > > > > > board/kontron/pitx_imx8m/pitx_imx8m.c | 15 +++- > > > > > board/kontron/sl-mx8mm/sl-mx8mm.c | 14 +++ > > > > > board/kontron/sl28/sl28.c | 14 +++ > > > > > board/sandbox/sandbox.c | 17 ++ > > > > > board/socionext/developerbox/developerbox.c | 23 > > > > > +++ > > > > > board/xilinx/common/board.h | 18 +++ > > > > > board/xilinx/zynq/board.c | 18 +++ > > > > > board/xilinx/zynqmp/zynqmp.c | 18 +++ > > > > > include/configs/imx8mm-cl-iot-gate.h | 10 > > > > > include/configs/imx8mp_rsb3720.h | 10 > > > > > include/configs/kontron-sl-mx8m
Re: data abort when run 'dhcp'
It's very strange. And I can't detect it's a bug of usb or dlmalloc. 1. Starting u-boot and dhcp via am335x's ethernet(cpsw driver), it's ok. 2. Starting u-boot and dhcp via am335x's usb net, data abort. 3. start fastboot, and CTRL C right now, dhcp via am335x's usb net, it's ok. 在 2022/3/24 17:33, qianfan 写道: 在 2022/3/23 18:12, Heinrich Schuchardt 写道: On 3/23/22 11:07, qianfan wrote: 在 2022/3/23 17:51, Heinrich Schuchardt 写道: On 3/23/22 10:13, qianfan wrote: 在 2022/3/23 16:02, qianfan 写道: 在 2022/3/23 15:45, qianfan 写道: 在 2022/3/23 10:28, qianfan 写道: Hi: I had a custom AM335X board connected my computer by usbnet. It always report data abort when 'dhcp': Next it the log: U-Boot 2022.01-rc1-00183-gfa5b4e2d19-dirty (Feb 25 2022 - 15:45:02 +0800) CPU : AM335X-GP rev 2.1 Model: WISDOM AM335X CCT DRAM: 512 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0 Loading Environment from NAND... *** Warning - bad CRC, using default environment Net: Could not get PHY for ethernet@4a10: addr 0 eth2: ethernet@4a10, eth3: usb_ether Hit any key to stop autoboot: 0 => setenv autoload no => dhcp using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in MAC de:ad:be:ef:00:01 HOST MAC de:ad:be:ef:00:00 RNDIS ready musb-hdrc: peripheral reset irq lost! high speed config #2: 2 mA, Ethernet Gadget, using RNDIS USB RNDIS network up! BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 DHCP client bound to address 192.168.200.4 (757 ms) data abort pc : [<9fe9b0a2>] lr : [<9febbc3f>] reloc pc : [<808130a2>] lr : [<80833c3f>] sp : 9de53410 ip : 9de53578 fp : 0001 r10: 9de5345c r9 : 9de67e80 r8 : 9febbae5 r7 : 9de72c30 r6 : 9feec710 r5 : 000d r4 : 0018 r3 : 3fdd8e04 r2 : 0002 r1 : 9feec728 r0 : 9feec700 Flags: Nzcv IRQs off FIQs on Mode SVC_32 (T) Code: f023 0303 60ca 4403 (6091) 685a Resetting CPU ... resetting ... It's there has any doc about how to debug data abort? Or is the bug is already fixed? Thanks This bug doesn't fixed on master code. I found v2021.01 is good and v2021.04-rc2 is bad. Also I had tested this on beaglebone black with am335x_evm_defconfig, has the simliar problem. find the first bug commit via 'git bisect': it told me that commit e97eb638de0dc8f6e989e20eaeb0342f103cb917 broke it. But it is very strange due to this commit doesn't touch any dhcp or network code. ➜ u-boot-main git:(e97eb638de) ✗ git bisect bug e97eb638de0dc8f6e989e20eaeb0342f103cb917 is the first bug commit commit e97eb638de0dc8f6e989e20eaeb0342f103cb917 Author: Heinrich Schuchardt Date: Wed Jan 20 22:21:53 2021 +0100 fs: fat: consistent error handling for flush_dir() Provide function description for flush_dir(). Move all error messages for flush_dir() from the callers to the function. Move mapping of errors to -EIO to the function. Always check return value of flush_dir() (Coverity CID 316362). In fat_unlink() return -EIO if flush_dirty_fat_buffer() fails. Signed-off-by: Heinrich Schuchardt :04 04 2281a449f2d134078d7faa1ee735a367b55aad7e 77d188b1c99181fd71f2167fdeee3434a09db209 M fs 184aa6504143b452132e28cd3ebecc7b941cdfa1 is the first commit before e97eb638de0dc8f6e989e20eaeb0342f103cb917: * e97eb638de0dc8f6e989e20eaeb0342f103cb917 fs: fat: consistent error handling for flush_dir() * 184aa6504143b452132e28cd3ebecc7b941cdfa1 Merge tag 'u-boot-rockchip-20210121' of https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip |\ | * 9ddc0787bd660214366e386ce689dd78299ac9d0 pci: Add Rockchip dwc based PCIe controller driver I checked 184aa6504143b452132e28cd3ebecc7b941cdfa1 can work fine. U-Boot 2021.01-00688-g184aa65041-dirty (Mar 23 2022 - 15:07:56 +0800) CPU : AM335X-GP rev 2.1 Model: TI AM335x BeagleBone Black DRAM: 512 MiB WDT: Started with servicing (60s timeout) NAND: 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Loading Environment from FAT... not set. Validating first E-fuse MAC Net: eth2: ethernet@4a10, eth3: usb_ether Hit any key to stop autoboot: 0 => dhcp ethernet@4a10 Waiting for PHY auto negotiation to complete. TIMEOUT ! using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in MAC de:ad:be:ef:00:01 HOST MAC de:ad:be:ef:00:00 RNDIS ready musb-hdrc: peripheral reset irq lost! high speed config #2: 2 mA, Ethernet Gadget, using RNDIS USB RNDIS network up! BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 DHCP client bound to address 192.168.200.157 (757 ms) Using usb_ether device TFTP from server 192.168.200.1; our IP address is 192.168.200.157 Filename 'u-boot.img'. Load address: 0x8200 Loading: # # # # 2.5 MiB/s done Bytes transferred = 1123888 (112630 hex) => "data abort" messages: data abort pc : [<9ff8196c>] lr : [<9ffa1cd7>] reloc
Re: [PATCH 06/11] virtio: pci: Read entire capability into memory
On Fri, Mar 25, 2022 at 5:18 PM Andrew Scull wrote: > > On Fri, 25 Mar 2022 at 07:51, Bin Meng wrote: > > > > On Fri, Mar 25, 2022 at 3:03 PM Andrew Scull wrote: > > > > > > On Fri, 25 Mar 2022 at 04:31, Bin Meng wrote: > > > > > > > > On Sun, Mar 20, 2022 at 7:42 PM Andrew Scull wrote: > > > > > > > > > > Read the virtio PCI capability out of the device configuration space > > > > > to > > > > > a struct rather than accessing fields directly from the configuration > > > > > space as they are needed. This both makes access to the fields easier > > > > > and avoids re-reading fields. > > > > > > > > > > Re-reading fields could result in time-of-check to time-of-use > > > > > problems, > > > > > should the value in the configuration space change. The range check of > > > > > the `bar` field and the later call to `dm_pci_read_bar32()` is an > > > > > example of where this could happen. > > > > > > > > I don't see the need to avoid the time-of-check to time-of-use > > > > problems, as it can only happen with the PCI configuration access > > > > capability, which U-Boot driver does not touch. > > > > > > > > Am I missing something? > > > > > > U-Boot doesn't touch the configuration space but the device could > > > have, whether that be accidently or maliciously. Linux has taken > > > similar precautions [1] to add more safety checks and I'll be looking > > > to do the same in other parts of the u-boot virtio drivers. > > > > > > [1] -- https://lwn.net/Articles/865216 > > > > > > > Got it. So basically the problem is that we don't trust the host that > > implements the virtio device :) > > > > I am curious that under such a guideline, probably lots of device > > drivers need to be enhanced to do the sanity check, no? > > Absolutely, they do! My focus is going to be primarily on the modern > PCI driver, vring and block driver. This will lay a foundation for the > others but they will also need to be checked over carefully before > being relied on. Do you know if the Linux kernel has a plan to apply such a guideline to some other drivers than virtio, like usb or nvme? There are devices that can do bad things too so we should not trust them? Regards, Bin
Re: [PATCH 09/11] pci: Add function to validate PCI address range
On Fri, 25 Mar 2022 at 07:14, Bin Meng wrote: > > On Sun, Mar 20, 2022 at 7:42 PM Andrew Scull wrote: > > > > Add a function to convert a PCI address range to a physical address > > range. The address range is validated to ensure it is contained within > > one of the PCI address regions and that the whole range can be indexed > > from the resulting physical address. > > I am not sure if we need to provide such an API given there is already > dm_pci_bus_to_phys() and friends. Not sure we really need this new API > to add a check against the range. ... > If we really need this, I believe we can do some refactoring on the > existing _dm_pci_bus_to_phys() to provide the new capability you > wanted. A big reason is to check the range fits in the region, not just a single pointer. It looks like evolving the existing API might not be too tricky for that. The bit that really caused me trouble was that the PCI driver adds system memory as identity mapped regions. But that system memory hasn't been declared as part of the PCI bus so why is it being added? I want to remove that but don't know the background, or have the ability to test PCI will still work properly. We can't allow a virtio device to claim it has buffers in the middle of system memory and then have the driver blindly corrupt that region of memory, so there'll need to be a way to prevent that. > > + * @size: Size of the addressrange > > need a space before 'range' Ack. > Please add a test case in test/dm/pci.c to cover this new API. I was just learning about the sandbox testing, I'll take a look.
Re: [RFC PATCH 0/6] efi: capsule: Image GUID usage cleanup
Sughosh, On Fri, Mar 25, 2022 at 03:14:20PM +0530, Sughosh Ganu wrote: > hi Takahiro, > > On Fri, 25 Mar 2022 at 10:23, AKASHI Takahiro > wrote: > > > > Sughosh, > > > > On Thu, Mar 24, 2022 at 06:08:55PM +0530, Sughosh Ganu wrote: > > > > > > This series is cleaning up the usage of the image GUIDs that are used > > > in capsule update and the EFI System Resource Table(ESRT). > > > > > > 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. > > > > Ok although the specification doesn't explicitly require the uniqueness > > "across platforms". > > Yes, but unless we have a single image running on multiple platforms, > we do need different GUID values across platforms. > > > > > > 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. > > > > Well, this is *not* a problem of fit FMP driver, but a matter of how > > ESRT is populated. Table 23-16 "ESRT and FMP Fields" says, > > The ImageTypeId GUID from the Firmware > > Management Protocol instance for a device is > > used as the Firmware Class GUID in the ESRT. > > Where there are multiple identical devices in > > the system, system firmware must create a > > mapping to ensure that the ESRT FwClass > > GUIDs are unique and consistent. > > The second sentence suggests that UEFI implementation, i.e. > > efi_esrt_populate(), may and should allow some *mapping*. > > > > That said, I basically accept the requirement that you mention above. > > > > > 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. > > > > When ESRT support patch was posted, I proposed that we should have > > a kind of configuration table that defines all the firmware on the system > > for ESRT, but this proposal was rejected. > > Your efi_fw_images[] looks quite similar as what I had in mind. > > Why not define efi_fw_images[] as ESRT itself. > > (Of course, some fields in an entry can still be populated through > > GetImageInfo API.) > > Currently, with this patch series, that is what is happening. The > efi_fw_images array gets read by the GetImageInfo function, and that > information gets used for populating the ESRT. Btw, I also want to > extend this structure as part of a separate task, where we have > information related to the dfu framework as part of the structure. > Then the capsule related dfu information can be populated from this > structure, instead of the dfu_alt_info env variable. This is what > Ilias has suggested. But I will take this up as a separate exercise. > > > > > > The first patch of this series adds the fw_images array in all > > > platforms which are using UEFI capsule updates > > > > > > The second patch of the series changes the logic for populating the > > > image descriptor array, using the information from the fw_images array > > > defined by the platform. > > > > So a FIT image can s
[PATCH] serial: zynq: Change fifor behavior in debug mode
Serial IP has output buffer which status is indicated by two bits. If fifo if empty or full. Default configuration is that chars are pushed to fifo till it is full. Time to time it is visible that chars are scambled and logs are not visible. Not sure what it is exactly happening but all the time it helps to change driver behavior to write only one char at a time. That's why enable this mode when debug uart is enabled not to see scrambled chars in debug by default. Signed-off-by: Michal Simek --- drivers/serial/serial_zynq.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/serial/serial_zynq.c b/drivers/serial/serial_zynq.c index fd999368ab70..6bb003dc1558 100644 --- a/drivers/serial/serial_zynq.c +++ b/drivers/serial/serial_zynq.c @@ -21,6 +21,7 @@ #define ZYNQ_UART_SR_TXACTIVE BIT(11) /* TX active */ #define ZYNQ_UART_SR_TXFULLBIT(4) /* TX FIFO full */ +#define ZYNQ_UART_SR_TXEMPTY BIT(3) /* TX FIFO empty */ #define ZYNQ_UART_SR_RXEMPTY BIT(1) /* RX FIFO empty */ #define ZYNQ_UART_CR_TX_EN BIT(4) /* TX enabled */ @@ -107,8 +108,13 @@ static void _uart_zynq_serial_init(struct uart_zynq *regs) static int _uart_zynq_serial_putc(struct uart_zynq *regs, const char c) { - if (readl(®s->channel_sts) & ZYNQ_UART_SR_TXFULL) - return -EAGAIN; + if (CONFIG_IS_ENABLED(DEBUG_UART_ZYNQ)) { + if (!(readl(®s->channel_sts) & ZYNQ_UART_SR_TXEMPTY)) + return -EAGAIN; + } else { + if (readl(®s->channel_sts) & ZYNQ_UART_SR_TXFULL) + return -EAGAIN; + } writel(c, ®s->tx_rx_fifo); -- 2.35.1
[PATCH v4 0/9] imx8mm: add pwm-imx backlight support
Hi, This series add support for pwm/backlight on i.MX8MM evk, separe also CONFIG_DM_PWM pwm-imx implementation from non dm implementation moving pwm-imx-util into pwm-imx with driver refactoring. 1. add pwm ctrl registers fields for i.MX8MM SOC 2. add pwm_regs struct for i.MX8MM SOC 3. add pwm clocks support for i.MX8MM SOC 4. move pwm-imx-util into pwm-imx 5. get and enable per/ipg clock using dm 6. introduce pwm_dm_imx_get_parms 7. separe dm from non dm implementation into pwm-imx driver 8. add pwm1/backlight dts support for imx8mm_evk 9. add pwm backlight configs support for imx8mm_evk Tommaso Merciai (9): arch: mach-imx: imx8m: add pwm ctrl registers fields defines arch: mach-imx: imx8m: add pwm_regs struct in imx-regs clk: imx8mm: add pwm clocks support drivers: pwm: pwm-imx: move pwm-imx-util into pwm-imx driver: pwm: pwm-imx: get and enable per/ipg clock using dm driver: pwm: pwm-imx: introduce pwm_dm_imx_get_parms driver: pwm: pwm-imx: separe dm from non dm implementation arm: dts: imx8mm_evk: add pwm1/backlight support configs: imx8mm_evk: add pwm backlight support arch/arm/dts/imx8mm-evk.dtsi | 21 +++ arch/arm/include/asm/arch-imx8m/imx-regs.h | 17 +++ configs/imx8mm_evk_defconfig | 5 + drivers/clk/imx/clk-imx8mm.c | 28 drivers/pwm/Makefile | 2 +- drivers/pwm/pwm-imx-util.c | 80 --- drivers/pwm/pwm-imx-util.h | 15 -- drivers/pwm/pwm-imx.c | 155 +++-- 8 files changed, 213 insertions(+), 110 deletions(-) delete mode 100644 drivers/pwm/pwm-imx-util.c delete mode 100644 drivers/pwm/pwm-imx-util.h -- 2.25.1
[PATCH v4 1/9] arch: mach-imx: imx8m: add pwm ctrl registers fields defines
Add pwm control registers fields defines into imx-regs.h: - prescaler - dozeen - waiten - dbgen - clksrc_ipg_high - clksrc_ipg, en field References: - iMX8MMRM.pdf p 3884 Signed-off-by: Tommaso Merciai --- arch/arm/include/asm/arch-imx8m/imx-regs.h | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm/include/asm/arch-imx8m/imx-regs.h b/arch/arm/include/asm/arch-imx8m/imx-regs.h index 11389a0f4d..57a95de1b8 100644 --- a/arch/arm/include/asm/arch-imx8m/imx-regs.h +++ b/arch/arm/include/asm/arch-imx8m/imx-regs.h @@ -351,6 +351,14 @@ struct src { u32 ddr2_rcr; }; +#define PWMCR_PRESCALER(x) (((x - 1) & 0xFFF) << 4) +#define PWMCR_DOZEEN (1 << 24) +#define PWMCR_WAITEN (1 << 23) +#define PWMCR_DBGEN(1 << 22) +#define PWMCR_CLKSRC_IPG_HIGH (2 << 16) +#define PWMCR_CLKSRC_IPG (1 << 16) +#define PWMCR_EN (1 << 0) + #define WDOG_WDT_MASK BIT(3) #define WDOG_WDZST_MASKBIT(0) struct wdog_regs { -- 2.25.1
[PATCH v4 2/9] arch: mach-imx: imx8m: add pwm_regs struct in imx-regs
Add pwm_regs struct for i.MX8MM SOC Signed-off-by: Tommaso Merciai --- arch/arm/include/asm/arch-imx8m/imx-regs.h | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/arm/include/asm/arch-imx8m/imx-regs.h b/arch/arm/include/asm/arch-imx8m/imx-regs.h index 57a95de1b8..f31f54ad0c 100644 --- a/arch/arm/include/asm/arch-imx8m/imx-regs.h +++ b/arch/arm/include/asm/arch-imx8m/imx-regs.h @@ -359,6 +359,15 @@ struct src { #define PWMCR_CLKSRC_IPG (1 << 16) #define PWMCR_EN (1 << 0) +struct pwm_regs { + u32 cr; + u32 sr; + u32 ir; + u32 sar; + u32 pr; + u32 cnr; +}; + #define WDOG_WDT_MASK BIT(3) #define WDOG_WDZST_MASKBIT(0) struct wdog_regs { -- 2.25.1
[PATCH v4 3/9] clk: imx8mm: add pwm clocks support
Add clocks support for the PWM controllers. This is ported from Linux v5.17-rc8. Signed-off-by: Tommaso Merciai --- drivers/clk/imx/clk-imx8mm.c | 28 1 file changed, 28 insertions(+) diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c index 3aa8c641f9..964a778934 100644 --- a/drivers/clk/imx/clk-imx8mm.c +++ b/drivers/clk/imx/clk-imx8mm.c @@ -116,6 +116,18 @@ static const char *imx8mm_i2c3_sels[] = {"clock-osc-24m", "sys_pll1_160m", "sys_ static const char *imx8mm_i2c4_sels[] = {"clock-osc-24m", "sys_pll1_160m", "sys_pll2_50m", "sys_pll3_out", "audio_pll1_out", "video_pll1_out", "audio_pll2_out", "sys_pll1_133m", }; +static const char *imx8mm_pwm1_sels[] = {"clock-osc-24m", "sys_pll2_100m", "sys_pll1_160m", "sys_pll1_40m", +"sys_pll3_out", "clk_ext1", "sys_pll1_80m", "video_pll1_out", }; + +static const char *imx8mm_pwm2_sels[] = {"clock-osc-24m", "sys_pll2_100m", "sys_pll1_160m", "sys_pll1_40m", +"sys_pll3_out", "clk_ext1", "sys_pll1_80m", "video_pll1_out", }; + +static const char *imx8mm_pwm3_sels[] = {"clock-osc-24m", "sys_pll2_100m", "sys_pll1_160m", "sys_pll1_40m", +"sys_pll3_out", "clk_ext2", "sys_pll1_80m", "video_pll1_out", }; + +static const char *imx8mm_pwm4_sels[] = {"clock-osc-24m", "sys_pll2_100m", "sys_pll1_160m", "sys_pll1_40m", +"sys_pll3_out", "clk_ext2", "sys_pll1_80m", "video_pll1_out", }; + static const char *imx8mm_wdog_sels[] = {"clock-osc-24m", "sys_pll1_133m", "sys_pll1_160m", "vpu_pll_out", "sys_pll2_125m", "sys_pll3_out", "sys_pll1_80m", "sys_pll2_166m", }; @@ -391,6 +403,14 @@ static int imx8mm_clk_probe(struct udevice *dev) imx8m_clk_composite("i2c3", imx8mm_i2c3_sels, base + 0xae00)); clk_dm(IMX8MM_CLK_I2C4, imx8m_clk_composite("i2c4", imx8mm_i2c4_sels, base + 0xae80)); + clk_dm(IMX8MM_CLK_PWM1, + imx8m_clk_composite("pwm1", imx8mm_pwm1_sels, base + 0xb380)); + clk_dm(IMX8MM_CLK_PWM2, + imx8m_clk_composite("pwm2", imx8mm_pwm2_sels, base + 0xb400)); + clk_dm(IMX8MM_CLK_PWM3, + imx8m_clk_composite("pwm3", imx8mm_pwm3_sels, base + 0xb480)); + clk_dm(IMX8MM_CLK_PWM4, + imx8m_clk_composite("pwm4", imx8mm_pwm4_sels, base + 0xb500)); clk_dm(IMX8MM_CLK_WDOG, imx8m_clk_composite("wdog", imx8mm_wdog_sels, base + 0xb900)); clk_dm(IMX8MM_CLK_USDHC3, @@ -425,6 +445,14 @@ static int imx8mm_clk_probe(struct udevice *dev) imx_clk_gate4("i2c4_root_clk", "i2c4", base + 0x41a0, 0)); clk_dm(IMX8MM_CLK_OCOTP_ROOT, imx_clk_gate4("ocotp_root_clk", "ipg_root", base + 0x4220, 0)); + clk_dm(IMX8MM_CLK_PWM1_ROOT, + imx_clk_gate4("pwm1_root_clk", "pwm1", base + 0x4280, 0)); + clk_dm(IMX8MM_CLK_PWM2_ROOT, + imx_clk_gate4("pwm2_root_clk", "pwm2", base + 0x4290, 0)); + clk_dm(IMX8MM_CLK_PWM3_ROOT, + imx_clk_gate4("pwm3_root_clk", "pwm3", base + 0x42a0, 0)); + clk_dm(IMX8MM_CLK_PWM4_ROOT, + imx_clk_gate4("pwm4_root_clk", "pwm4", base + 0x42b0, 0)); clk_dm(IMX8MM_CLK_USDHC1_ROOT, imx_clk_gate4("usdhc1_root_clk", "usdhc1", base + 0x4510, 0)); clk_dm(IMX8MM_CLK_USDHC2_ROOT, -- 2.25.1
[PATCH v4 6/9] driver: pwm: pwm-imx: introduce pwm_dm_imx_get_parms
Introduce pwm_dm_imx_get_parms, dm version of pwm_imx_get_parms. This function get clock rate using clk dm api Signed-off-by: Tommaso Merciai --- Changes since v4: - Fix clk_get_rate call drivers/pwm/pwm-imx.c | 32 +++- 1 file changed, 31 insertions(+), 1 deletion(-) diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c index 74b0817a05..1d656e726f 100644 --- a/drivers/pwm/pwm-imx.c +++ b/drivers/pwm/pwm-imx.c @@ -153,6 +153,36 @@ struct imx_pwm_priv { struct clk ipg_clk; }; +int pwm_dm_imx_get_parms(struct imx_pwm_priv *priv, int period_ns, + int duty_ns, unsigned long *period_c, unsigned long *duty_c, + unsigned long *prescale) +{ + unsigned long long c; + + c = clk_get_rate(&priv->per_clk); + c = c * period_ns; + do_div(c, 10); + *period_c = c; + + *prescale = *period_c / 0x1 + 1; + + *period_c /= *prescale; + c = *period_c * (unsigned long long)duty_ns; + do_div(c, period_ns); + *duty_c = c; + + /* +* according to imx pwm RM, the real period value should be +* PERIOD value in PWMPR plus 2. +*/ + if (*period_c > 2) + *period_c -= 2; + else + *period_c = 0; + + return 0; +} + static int imx_pwm_set_invert(struct udevice *dev, uint channel, bool polarity) { @@ -173,7 +203,7 @@ static int imx_pwm_set_config(struct udevice *dev, uint channel, debug("%s: Config '%s' channel: %d\n", __func__, dev->name, channel); - pwm_imx_get_parms(period_ns, duty_ns, &period_cycles, &duty_cycles, + pwm_dm_imx_get_parms(priv, period_ns, duty_ns, &period_cycles, &duty_cycles, &prescale); return pwm_config_internal(regs, period_cycles, duty_cycles, prescale); -- 2.25.1
[PATCH v4 4/9] drivers: pwm: pwm-imx: move pwm-imx-util into pwm-imx
Move pwm_imx_get_parms, pwm_id_to_reg functions into pwm-imx.c and drop off pwm-imx-util.c Signed-off-by: Tommaso Merciai --- drivers/pwm/Makefile | 2 +- drivers/pwm/pwm-imx-util.c | 80 -- drivers/pwm/pwm-imx-util.h | 15 --- drivers/pwm/pwm-imx.c | 67 ++- 4 files changed, 67 insertions(+), 97 deletions(-) delete mode 100644 drivers/pwm/pwm-imx-util.c delete mode 100644 drivers/pwm/pwm-imx-util.h diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile index 55f2bc081d..5d696ec49c 100644 --- a/drivers/pwm/Makefile +++ b/drivers/pwm/Makefile @@ -13,7 +13,7 @@ obj-$(CONFIG_DM_PWM) += pwm-uclass.o obj-$(CONFIG_PWM_AT91) += pwm-at91.o obj-$(CONFIG_PWM_CROS_EC) += cros_ec_pwm.o obj-$(CONFIG_PWM_EXYNOS) += exynos_pwm.o -obj-$(CONFIG_PWM_IMX) += pwm-imx.o pwm-imx-util.o +obj-$(CONFIG_PWM_IMX) += pwm-imx.o obj-$(CONFIG_PWM_MESON)+= pwm-meson.o obj-$(CONFIG_PWM_MTK) += pwm-mtk.o obj-$(CONFIG_PWM_ROCKCHIP) += rk_pwm.o diff --git a/drivers/pwm/pwm-imx-util.c b/drivers/pwm/pwm-imx-util.c deleted file mode 100644 index 823a9d2d6b..00 --- a/drivers/pwm/pwm-imx-util.c +++ /dev/null @@ -1,80 +0,0 @@ -// SPDX-License-Identifier: GPL-2.0 -/* - * (C) Copyright 2014 - * Heiko Schocher, DENX Software Engineering, h...@denx.de. - * - * Basic support for the pwm module on imx6. - * - * Based on linux:drivers/pwm/pwm-imx.c - * from - * Sascha Hauer - */ - -#include -#include -#include - -/* pwm_id from 0..7 */ -struct pwm_regs *pwm_id_to_reg(int pwm_id) -{ - switch (pwm_id) { - case 0: - return (struct pwm_regs *)PWM1_BASE_ADDR; - case 1: - return (struct pwm_regs *)PWM2_BASE_ADDR; -#ifdef CONFIG_MX6 - case 2: - return (struct pwm_regs *)PWM3_BASE_ADDR; - case 3: - return (struct pwm_regs *)PWM4_BASE_ADDR; -#endif -#ifdef CONFIG_MX6SX - case 4: - return (struct pwm_regs *)PWM5_BASE_ADDR; - case 5: - return (struct pwm_regs *)PWM6_BASE_ADDR; - case 6: - return (struct pwm_regs *)PWM7_BASE_ADDR; - case 7: - return (struct pwm_regs *)PWM8_BASE_ADDR; -#endif - default: - printf("unknown pwm_id: %d\n", pwm_id); - break; - } - return NULL; -} - -int pwm_imx_get_parms(int period_ns, int duty_ns, unsigned long *period_c, - unsigned long *duty_c, unsigned long *prescale) -{ - unsigned long long c; - - /* -* we have not yet a clock framework for imx6, so add the clock -* value here as a define. Replace it when we have the clock -* framework. -*/ - c = CONFIG_IMX6_PWM_PER_CLK; - c = c * period_ns; - do_div(c, 10); - *period_c = c; - - *prescale = *period_c / 0x1 + 1; - - *period_c /= *prescale; - c = *period_c * (unsigned long long)duty_ns; - do_div(c, period_ns); - *duty_c = c; - - /* -* according to imx pwm RM, the real period value should be -* PERIOD value in PWMPR plus 2. -*/ - if (*period_c > 2) - *period_c -= 2; - else - *period_c = 0; - - return 0; -} diff --git a/drivers/pwm/pwm-imx-util.h b/drivers/pwm/pwm-imx-util.h deleted file mode 100644 index 82c61d774d..00 --- a/drivers/pwm/pwm-imx-util.h +++ /dev/null @@ -1,15 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 */ -/* - * (C) Copyright 2014 - * Heiko Schocher, DENX Software Engineering, h...@denx.de. - * - * Basic support for the pwm module on imx6. - */ - -#ifndef _pwm_imx_util_h_ -#define _pwm_imx_util_h_ - -struct pwm_regs *pwm_id_to_reg(int pwm_id); -int pwm_imx_get_parms(int period_ns, int duty_ns, unsigned long *period_c, - unsigned long *duty_c, unsigned long *prescale); -#endif diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c index 2008c1520e..67dad21295 100644 --- a/drivers/pwm/pwm-imx.c +++ b/drivers/pwm/pwm-imx.c @@ -13,7 +13,6 @@ #include #include #include -#include "pwm-imx-util.h" int pwm_init(int pwm_id, int div, int invert) { @@ -44,6 +43,72 @@ int pwm_config_internal(struct pwm_regs *pwm, unsigned long period_cycles, return 0; } +/* pwm_id from 0..7 */ +struct pwm_regs *pwm_id_to_reg(int pwm_id) +{ + + switch (pwm_id) { + case 0: + return (struct pwm_regs *)PWM1_BASE_ADDR; + case 1: + return (struct pwm_regs *)PWM2_BASE_ADDR; +#ifdef CONFIG_MX6 + case 2: + return (struct pwm_regs *)PWM3_BASE_ADDR; + case 3: + return (struct pwm_regs *)PWM4_BASE_ADDR; +#endif +#ifdef CONFIG_MX6SX + case 4: + return (struct pwm_regs *)PWM5_BASE_ADDR; + case 5: + return (struct pwm_regs *)PWM6_BASE_ADDR; +
[PATCH v4 5/9] driver: pwm: pwm-imx: get and enable per/ipg clock using dm
Get and enable ipg/per pwms clocks using dm api into imx_pwm_of_to_plat and imx_pwm_probe driver function Signed-off-by: Tommaso Merciai --- Changes since v4: - Fix ipg/per clk declaration - Fix clk_get_by_name call - Fix clk_enable call drivers/pwm/pwm-imx.c | 31 +++ 1 file changed, 31 insertions(+) diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c index 67dad21295..74b0817a05 100644 --- a/drivers/pwm/pwm-imx.c +++ b/drivers/pwm/pwm-imx.c @@ -24,6 +24,7 @@ int pwm_init(int pwm_id, int div, int invert) writel(0, &pwm->ir); return 0; } +#include int pwm_config_internal(struct pwm_regs *pwm, unsigned long period_cycles, unsigned long duty_cycles, unsigned long prescale) @@ -148,6 +149,8 @@ void pwm_disable(int pwm_id) struct imx_pwm_priv { struct pwm_regs *regs; bool invert; + struct clk per_clk; + struct clk ipg_clk; }; static int imx_pwm_set_invert(struct udevice *dev, uint channel, @@ -193,15 +196,43 @@ static int imx_pwm_set_enable(struct udevice *dev, uint channel, bool enable) static int imx_pwm_of_to_plat(struct udevice *dev) { + int ret; struct imx_pwm_priv *priv = dev_get_priv(dev); priv->regs = dev_read_addr_ptr(dev); + ret = clk_get_by_name(dev, "per", &priv->per_clk); + if (ret) { + printf("Failed to get per_clk\n"); + return ret; + } + + ret = clk_get_by_name(dev, "ipg", &priv->ipg_clk); + if (ret) { + printf("Failed to get ipg_clk\n"); + return ret; + } + return 0; } static int imx_pwm_probe(struct udevice *dev) { + int ret; + struct imx_pwm_priv *priv = dev_get_priv(dev); + + ret = clk_enable(&priv->per_clk); + if (ret) { + printf("Failed to enable per_clk\n"); + return ret; + } + + ret = clk_enable(&priv->ipg_clk); + if (ret) { + printf("Failed to enable ipg_clk\n"); + return ret; + } + return 0; } -- 2.25.1
[PATCH v4 7/9] driver: pwm: pwm-imx: separe dm from non dm implementation
Separe dm implementation from non dm implementation of pwm-imx driver using CONFIG_DM_PWM Signed-off-by: Tommaso Merciai --- drivers/pwm/pwm-imx.c | 25 + 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c index 1d656e726f..9b8a8c189d 100644 --- a/drivers/pwm/pwm-imx.c +++ b/drivers/pwm/pwm-imx.c @@ -13,17 +13,6 @@ #include #include #include - -int pwm_init(int pwm_id, int div, int invert) -{ - struct pwm_regs *pwm = (struct pwm_regs *)pwm_id_to_reg(pwm_id); - - if (!pwm) - return -1; - - writel(0, &pwm->ir); - return 0; -} #include int pwm_config_internal(struct pwm_regs *pwm, unsigned long period_cycles, @@ -44,6 +33,7 @@ int pwm_config_internal(struct pwm_regs *pwm, unsigned long period_cycles, return 0; } +#ifndef CONFIG_DM_PWM /* pwm_id from 0..7 */ struct pwm_regs *pwm_id_to_reg(int pwm_id) { @@ -110,6 +100,17 @@ int pwm_imx_get_parms(int period_ns, int duty_ns, unsigned long *period_c, return 0; } +int pwm_init(int pwm_id, int div, int invert) +{ + struct pwm_regs *pwm = (struct pwm_regs *)pwm_id_to_reg(pwm_id); + + if (!pwm) + return -1; + + writel(0, &pwm->ir); + return 0; +} + int pwm_config(int pwm_id, int duty_ns, int period_ns) { struct pwm_regs *pwm = (struct pwm_regs *)pwm_id_to_reg(pwm_id); @@ -145,7 +146,7 @@ void pwm_disable(int pwm_id) clrbits_le32(&pwm->cr, PWMCR_EN); } -#if defined(CONFIG_DM_PWM) +#else struct imx_pwm_priv { struct pwm_regs *regs; bool invert; -- 2.25.1
[PATCH v4 9/9] configs: imx8mm_evk: add pwm backlight support
Enable support for backlight/pwm-imx driver Signed-off-by: Tommaso Merciai --- configs/imx8mm_evk_defconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/configs/imx8mm_evk_defconfig b/configs/imx8mm_evk_defconfig index 01395fc7eb..cfba6cc673 100644 --- a/configs/imx8mm_evk_defconfig +++ b/configs/imx8mm_evk_defconfig @@ -84,3 +84,8 @@ CONFIG_SYSRESET_PSCI=y CONFIG_SYSRESET_WATCHDOG=y CONFIG_DM_THERMAL=y CONFIG_IMX_WATCHDOG=y +CONFIG_DM_VIDEO=y +CONFIG_BACKLIGHT=y +CONFIG_BACKLIGHT_PWM=y +CONFIG_DM_PWM=y +CONFIG_PWM_IMX=y \ No newline at end of file -- 2.25.1
[PATCH v4 8/9] arm: dts: imx8mm_evk: add pwm1/backlight support
Add pwm1/backlight support nodes for imx8mm_evk board Signed-off-by: Tommaso Merciai --- arch/arm/dts/imx8mm-evk.dtsi | 21 + 1 file changed, 21 insertions(+) diff --git a/arch/arm/dts/imx8mm-evk.dtsi b/arch/arm/dts/imx8mm-evk.dtsi index 60179e006d..e7a2bd8a64 100644 --- a/arch/arm/dts/imx8mm-evk.dtsi +++ b/arch/arm/dts/imx8mm-evk.dtsi @@ -41,6 +41,15 @@ enable-active-high; }; + backlight: backlight { + status = "disabled"; + compatible = "pwm-backlight"; + pwms = <&pwm1 0 500>; + brightness-levels = <0 255>; + num-interpolated-steps = <255>; + default-brightness-level = <250>; + }; + ir-receiver { compatible = "gpio-ir-receiver"; gpios = <&gpio1 13 GPIO_ACTIVE_LOW>; @@ -350,6 +359,12 @@ status = "okay"; }; +&pwm1 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_backlight>; + status = "disabled"; +}; + &iomuxc { pinctrl_fec1: fec1grp { fsl,pins = < @@ -491,4 +506,10 @@ MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B0x166 >; }; + + pinctrl_backlight: backlightgrp { + fsl,pins = < + MX8MM_IOMUXC_GPIO1_IO01_PWM1_OUT0x06 + >; + }; }; -- 2.25.1
[PATCH] mmc: zynq_sdhci: Fix SDx_BASECLK configuration
From: Ashok Reddy Soma The DLL mode supported SD reference clocks are 50 MHz, 100 MHz and 200 MHz. When user select SD frequency as 200MHz in the design, the actual frequency is going to come around ~187MHz (<= 200MHz considering the parent clock and divisor selection). We need to set SDx_BASECLK as 200 in this case, setting 187 will result in tuning failures in mmc. Set SDx_BASECLK to exact value of 200, 100 or 50 based on the frequency range. Signed-off-by: Ashok Reddy Soma Signed-off-by: Michal Simek --- drivers/mmc/zynq_sdhci.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c index d96f5d543f54..a59d96c6bdad 100644 --- a/drivers/mmc/zynq_sdhci.c +++ b/drivers/mmc/zynq_sdhci.c @@ -765,6 +765,15 @@ static int sdhci_zynqmp_set_dynamic_config(struct arasan_sdhci_priv *priv, mhz = DIV64_U64_ROUND_UP(clock, 100); + if (mhz > 100 && mhz <= 200) + mhz = 200; + else if (mhz > 50 && mhz <= 100) + mhz = 100; + else if (mhz > 25 && mhz <= 50) + mhz = 50; + else + mhz = 25; + ret = zynqmp_pm_set_sd_config(node_id, SD_CONFIG_BASECLK, mhz); if (ret) { dev_err(dev, "SD_CONFIG_BASECLK failed\n"); -- 2.35.1
[PATCH] CI: Pin pylint version to 2.12.2
For consistency in runs, we need to always use the same pylint version. Pin to 2.12.2 as this is what we have been using so far. Signed-off-by: Tom Rini --- .azure-pipelines.yml | 2 +- .gitlab-ci.yml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml index 0f1a1bd86326..cd5461d7 100644 --- a/.azure-pipelines.yml +++ b/.azure-pipelines.yml @@ -214,7 +214,7 @@ stages: cd ${WORK_DIR} export USER=azure pip install -r test/py/requirements.txt - pip install asteval pylint pyopenssl + pip install asteval pylint==2.12.2 pyopenssl export PATH=${PATH}:~/.local/bin echo "[MASTER]" >> .pylintrc echo "load-plugins=pylint.extensions.docparams" >> .pylintrc diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 388e666ec9e3..7df7e939f542 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -220,7 +220,7 @@ Run pylint: stage: testsuites script: - pip install -r test/py/requirements.txt -- pip install asteval pylint pyopenssl +- pip install asteval pylint==2.12.2 pyopenssl - export PATH=${PATH}:~/.local/bin - echo "[MASTER]" >> .pylintrc - echo "load-plugins=pylint.extensions.docparams" >> .pylintrc -- 2.25.1
[PATCH 1/1] doc: update doc/sphinx/requirements.txt
Pin all dependencies as reported by 'pip freeze'. Signed-off-by: Heinrich Schuchardt --- doc/sphinx/requirements.txt | 25 +++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/doc/sphinx/requirements.txt b/doc/sphinx/requirements.txt index 44c187880d..5baec4d93e 100644 --- a/doc/sphinx/requirements.txt +++ b/doc/sphinx/requirements.txt @@ -1,4 +1,25 @@ +alabaster==0.7.12 +Babel==2.9.1 +certifi==2021.10.8 +charset-normalizer==2.0.12 docutils==0.16 -sphinx==3.4.3 -sphinx_rtd_theme==1.0.0 +idna==3.3 +imagesize==1.3.0 +Jinja2==3.0.3 +MarkupSafe==2.1.1 +packaging==21.3 +Pygments==2.11.2 +pyparsing==3.0.7 +pytz==2022.1 +requests==2.27.1 six==1.16.0 +snowballstemmer==2.2.0 +Sphinx==3.4.3 +sphinx-rtd-theme==1.0.0 +sphinxcontrib-applehelp==1.0.2 +sphinxcontrib-devhelp==1.0.2 +sphinxcontrib-htmlhelp==2.0.0 +sphinxcontrib-jsmath==1.0.1 +sphinxcontrib-qthelp==1.0.3 +sphinxcontrib-serializinghtml==1.1.5 +urllib3==1.26.9 -- 2.34.1
Re: [PATCH 1/1] doc: update doc/sphinx/requirements.txt
On Fri, Mar 25, 2022 at 01:40:54PM +0100, Heinrich Schuchardt wrote: > Pin all dependencies as reported by 'pip freeze'. > > Signed-off-by: Heinrich Schuchardt Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH v4] mtd: gpmi: fix the bch setting backward compatible issue
Previous u-boot code changed the default bch setting behavior and caused backward compatible issue. This fix choose the legacy bch geometry back again as the default option. If the minimum ecc strength that NAND chips required need to be chosen, it can be enabled by either adding DT flag "fsl,use-minimum-ecc" or CONFIG_NAND_MXS_USE_MINIMUM_ECC in configs. The unused flag "fsl,legacy-bch-geometry" get removed. Fixes: 51cdf83eea (mtd: gpmi: provide the option to use legacy bch geometry) Fixes: 616f03daba (mtd: gpmi: change the BCH layout setting for large oob NAND) Tested-by: Tim Harvey Tested-by: Sean Nyekjaer Signed-off-by: Han Xu --- Changes in v2: - change the commit log about backward compatible issue is in u-boot - removed the unused flag - add fixes and test tag Changes in v3: - fix the fixes syntax - fix the change log syntax - add more test tag Changes in v4: - change the fix tag to single line --- drivers/mtd/nand/raw/mxs_nand.c| 71 ++ drivers/mtd/nand/raw/mxs_nand_dt.c | 2 - include/mxs_nand.h | 2 - 3 files changed, 62 insertions(+), 13 deletions(-) diff --git a/drivers/mtd/nand/raw/mxs_nand.c b/drivers/mtd/nand/raw/mxs_nand.c index 748056a43e..ee5d7fde9c 100644 --- a/drivers/mtd/nand/raw/mxs_nand.c +++ b/drivers/mtd/nand/raw/mxs_nand.c @@ -195,6 +195,7 @@ static inline int mxs_nand_legacy_calc_ecc_layout(struct bch_geometry *geo, struct nand_chip *chip = mtd_to_nand(mtd); struct mxs_nand_info *nand_info = nand_get_controller_data(chip); unsigned int block_mark_bit_offset; + int corr, ds_corr; /* The default for the length of Galois Field. */ geo->gf_len = 13; @@ -225,6 +226,17 @@ static inline int mxs_nand_legacy_calc_ecc_layout(struct bch_geometry *geo, geo->ecc_strength = min(round_down(geo->ecc_strength, 2), nand_info->max_ecc_strength_supported); + /* check ecc strength, same as nand_ecc_is_strong_enough() did*/ + if (chip->ecc_step_ds) { + corr = mtd->writesize * geo->ecc_strength / + geo->ecc_chunkn_size; + ds_corr = mtd->writesize * chip->ecc_strength_ds / + chip->ecc_step_ds; + if (corr < ds_corr || + geo->ecc_strength < chip->ecc_strength_ds) + return -EINVAL; + } + block_mark_bit_offset = mtd->writesize * 8 - (geo->ecc_strength * geo->gf_len * (geo->ecc_chunk_count - 1) + MXS_NAND_METADATA_SIZE * 8); @@ -,6 +1123,7 @@ static int mxs_nand_set_geometry(struct mtd_info *mtd, struct bch_geometry *geo) struct nand_chip *chip = mtd_to_nand(mtd); struct nand_chip *nand = mtd_to_nand(mtd); struct mxs_nand_info *nand_info = nand_get_controller_data(nand); + int err; if (chip->ecc_strength_ds > nand_info->max_ecc_strength_supported) { printf("unsupported NAND chip, minimum ecc required %d\n" @@ -1118,19 +1131,57 @@ static int mxs_nand_set_geometry(struct mtd_info *mtd, struct bch_geometry *geo) return -EINVAL; } - if ((!(chip->ecc_strength_ds > 0 && chip->ecc_step_ds > 0) && -mtd->oobsize < 1024) || nand_info->legacy_bch_geometry) { - dev_warn(mtd->dev, "use legacy bch geometry\n"); - return mxs_nand_legacy_calc_ecc_layout(geo, mtd); + /* use the legacy bch setting by default */ + if ((!nand_info->use_minimum_ecc && mtd->oobsize < 1024) || + !(chip->ecc_strength_ds > 0 && chip->ecc_step_ds > 0)) { + dev_dbg(mtd->dev, "use legacy bch geometry\n"); + err = mxs_nand_legacy_calc_ecc_layout(geo, mtd); + if (!err) + return 0; } - if (mtd->oobsize > 1024 || chip->ecc_step_ds < mtd->oobsize) - return mxs_nand_calc_ecc_for_large_oob(geo, mtd); + /* for large oob nand */ + if (mtd->oobsize > 1024) { + dev_dbg(mtd->dev, "use large oob bch geometry\n"); + err = mxs_nand_calc_ecc_for_large_oob(geo, mtd); + if (!err) + return 0; + } - return mxs_nand_calc_ecc_layout_by_info(geo, mtd, - chip->ecc_strength_ds, chip->ecc_step_ds); + /* otherwise use the minimum ecc nand chips required */ + dev_dbg(mtd->dev, "use minimum ecc bch geometry\n"); + err = mxs_nand_calc_ecc_layout_by_info(geo, mtd, chip->ecc_strength_ds, + chip->ecc_step_ds); - return 0; + if (err) + dev_err(mtd->dev, "none of the bch geometry setting works\n"); + + return err; +} + +void mxs_nand_dump_geo(struct mtd_info *mtd) +{ + struct nand_chip *nand = mtd_to_nand(mtd); + struct mxs_nand_info *nand_info = nand_get_controller_d
Re: [PATCH] CI: Pin pylint version to 2.12.2
On Fri, Mar 25, 2022 at 08:28:20AM -0400, Tom Rini wrote: > For consistency in runs, we need to always use the same pylint version. > Pin to 2.12.2 as this is what we have been using so far. > > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: ubifs: fix journal replay wrt. xattr nodes
On Fri, Mar 11, 2022 at 12:21:01PM +, Ville Baillie wrote: > Hi all > > Has there been any thought about bringing this fix into the u-boot ubifs > layer? > > https://github.com/torvalds/linux/commit/1cb51a15b576ee325d527726afff40947218fd5e > > > This fixes something that can break boot if you rely on UBIFS to load your > kernel images. If someone would port and post it, it would come in, yes. -- Tom signature.asc Description: PGP signature
Re: [PATCH 01/15] Convert CONFIG_AT91_LED to Kconfig
On Fri, Mar 18, 2022 at 08:38:18AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_AT91_LED > > Cc: Eugen Hristev > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 02/15] Convert CONFIG_AT91_WANTS_COMMON_PHY to Kconfig
On Fri, Mar 18, 2022 at 08:38:19AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_AT91_WANTS_COMMON_PHY > > Cc: Eugen Hristev > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 03/15] Convert CONFIG_RESET_PHY_R to Kconfig
On Fri, Mar 18, 2022 at 08:38:20AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_RESET_PHY_R > > Cc: Ramon Fried > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 04/15] Convert CONFIG_SYS_FAULT_ECHO_LINK_DOWN to Kconfig
On Fri, Mar 18, 2022 at 08:38:21AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_SYS_FAULT_ECHO_LINK_DOWN > > Cc: Ramon Fried > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 05/15] Convert CONFIG_RMII to Kconfig
On Fri, Mar 18, 2022 at 08:38:22AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_RMII > > Cc: Ramon Fried > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 06/15] Convert CONFIG_TFTP_PORT to Kconfig
On Fri, Mar 18, 2022 at 08:38:23AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_TFTP_PORT > > Cc: Ramon Fried > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 07/15] Convert CONFIG_LPC32XX_ETH to Kconfig
On Fri, Mar 18, 2022 at 08:38:24AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_LPC32XX_ETH > > Cc: Ramon Fried > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 08/15] Convert CONFIG_SYS_RX_ETH_BUFFER to Kconfig
On Fri, Mar 18, 2022 at 08:38:25AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_SYS_RX_ETH_BUFFER > > Cc: Ramon Fried > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 09/15] Convert CONFIG_PHY_RESET_DELAY to Kconfig
On Fri, Mar 18, 2022 at 08:38:26AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_PHY_RESET_DELAY > > Cc: Ramon Fried > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 10/15] Convert CONFIG_MII_INIT to Kconfig
On Fri, Mar 18, 2022 at 08:38:27AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_MII_INIT > > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 11/15] Convert CONFIG_ATMEL_LCD et al to Kconfig
On Fri, Mar 18, 2022 at 08:38:28AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_ATMEL_LCD >CONFIG_ATMEL_LCD_BGR555 >CONFIG_ATMEL_LCD_RGB565 >CONFIG_GURNARD_SPLASH > > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 12/15] Convert CONFIG_LCD_INFO et al to Kconfig
On Fri, Mar 18, 2022 at 08:38:29AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_LCD_INFO >CONFIG_LCD_LOGO >CONFIG_LCD_INFO_BELOW_LOGO >CONFIG_LCD_IN_PSRAM > > Cc: Anatolij Gustschin > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 13/15] lcd: Remove LCD_TEST_PATTERN code
On Fri, Mar 18, 2022 at 08:38:30AM -0400, Tom Rini wrote: > This is a legacy driver and the value is set in board config headers > without a CONFIG prefix. Remove the code. > > Cc: Anatolij Gustschin > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 14/15] vinco: Remove CONFIG_ATMEL_SPI0
On Fri, Mar 18, 2022 at 08:38:31AM -0400, Tom Rini wrote: > This is not referenced anywhere, remove. > > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 15/15] Convert CONFIG_BACKSIDE_L2_CACHE to Kconfig
On Fri, Mar 18, 2022 at 08:38:32AM -0400, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_BACKSIDE_L2_CACHE > > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH 5/6] FMP: Remove GUIDs for FIT and raw images
On Thu, 24 Mar 2022 at 14:39, Sughosh Ganu wrote: > > The capsule update code has been modified for getting the image GUID > values from the platform code. With this, each image now has a unique > GUID value. With this change, there is no longer a need for defining > GUIDs for FIT and raw images. Remove these GUID values. > > Signed-off-by: Sughosh Ganu > --- > include/efi_api.h | 8 > lib/efi_loader/efi_firmware.c | 4 > 2 files changed, 12 deletions(-) > > diff --git a/include/efi_api.h b/include/efi_api.h > index 982c200172..c7f7873b5d 100644 > --- a/include/efi_api.h > +++ b/include/efi_api.h > @@ -1967,14 +1967,6 @@ struct efi_signature_list { > EFI_GUID(0x86c77a67, 0x0b97, 0x4633, 0xa1, 0x87, \ > 0x49, 0x10, 0x4d, 0x06, 0x85, 0xc7) > > -#define EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID \ > - EFI_GUID(0xae13ff2d, 0x9ad4, 0x4e25, 0x9a, 0xc8, \ > -0x6d, 0x80, 0xb3, 0xb2, 0x21, 0x47) > - > -#define EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID \ > - EFI_GUID(0xe2bb9c06, 0x70e9, 0x4b14, 0x97, 0xa3, \ > -0x5a, 0x79, 0x13, 0x17, 0x6e, 0x3f) > - > #define IMAGE_ATTRIBUTE_IMAGE_UPDATABLE0x0001 > #define IMAGE_ATTRIBUTE_RESET_REQUIRED 0x0002 > #define IMAGE_ATTRIBUTE_AUTHENTICATION_REQUIRED0x0004 > diff --git a/lib/efi_loader/efi_firmware.c b/lib/efi_loader/efi_firmware.c > index 13cb492092..9fbedaf023 100644 > --- a/lib/efi_loader/efi_firmware.c > +++ b/lib/efi_loader/efi_firmware.c > @@ -185,8 +185,6 @@ static efi_status_t efi_fill_image_desc_array( > * - versioning of firmware image > * - package information > */ > -const efi_guid_t efi_firmware_image_type_uboot_fit = > - EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID; > > /** > * efi_firmware_fit_get_image_info - return information about the current > @@ -293,8 +291,6 @@ const struct efi_firmware_management_protocol efi_fmp_fit > = { > * This FIRMWARE_MANAGEMENT_PROTOCOL driver provides a firmware update > * method with raw data. > */ > -const efi_guid_t efi_firmware_image_type_uboot_raw = > - EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID; > > /** > * efi_firmware_raw_get_image_info - return information about the current > -- > 2.25.1 > Reviewed-by: Ilias Apalodimas
Re: [PATCH v4 00/33] Initial implementation of standard boot
Hi Tom On Wed, Mar 23, 2022 at 9:07 PM Tom Rini wrote: > > On Wed, Mar 23, 2022 at 08:57:36PM +0100, Michael Nazzareno Trimarchi wrote: > > Hi Tom > > > > On Wed, Mar 23, 2022 at 8:30 PM Tom Rini wrote: > > > > > > On Wed, Mar 23, 2022 at 08:21:22PM +0100, Michael Nazzareno Trimarchi > > > wrote: > > > > Hi Tom > > > > > > > > On Wed, Mar 23, 2022 at 7:46 PM Simon Glass wrote: > > > > > > > > > > Hi Tom, > > > > > > > > > > On Wed, 23 Mar 2022 at 08:05, Tom Rini wrote: > > > > > > > > > > > > On Sun, Mar 06, 2022 at 05:49:43AM -0700, Simon Glass wrote: > > > > > > > > > > > > > > The bootflow feature provide a built-in way for U-Boot to > > > > > > > automatically > > > > > > > boot an Operating System without custom scripting and other > > > > > > > customisation. > > > > > > > This is called 'standard boot' since it provides a standard way > > > > > > > for > > > > > > > U-Boot to boot a distro, without scripting. > > > > > > > > > > > > > > It introduces the following concepts: > > > > > > > > > > > > > >- bootdev - a device which can hold a distro > > > > > > >- bootmeth - a method to scan a bootdev to find bootflows > > > > > > > (owned by > > > > > > > U-Boot) > > > > > > >- bootflow - a description of how to boot (owned by the distro) > > > > > > > > > > > > > > This series provides an implementation of these, enabled to scan > > > > > > > for > > > > > > > bootflows from MMC, USB and Ethernet. It supports the existing > > > > > > > distro > > > > > > > boot as well as the EFI loader flow (bootefi/bootmgr). It works > > > > > > > similiarly to the existing script-based approach, but is native to > > > > > > > U-Boot. > > > > > > > > > > > > > > With this we can boot on a Raspberry Pi 3 with just one command: > > > > > > > > > > > > > >bootflow scan -lb > > > > > > > > > > > > > > which means to scan, listing (-l) each bootflow and trying to > > > > > > > boot each > > > > > > > one (-b). The final patch shows this. > > > > > > > > > > > > > > With a standard way to identify boot devices, booting become > > > > > > > easier. It > > > > > > > also should be possible to support U-Boot scripts, for backwards > > > > > > > compatibility only. > > > > > > > > > > > > > > This series relies on the PXE clean-up series, posted here: > > > > > > > > > > > > > >https://patchwork.ozlabs.org/project/uboot/list/?series=267078 > > > > > > > > > > > > > > For documentation, see the 'doc' patch. > > > > > > > > > > > > > > For version 2, a new naming scheme is used as above: > > > > > > > > > > > > > >- bootdev is used instead of bootdevice, because 'device' is > > > > > > > overused, > > > > > > >is everywhere in U-Boot, can be confused with udevice > > > > > > >- bootmeth - because 'method' is too vanilla, appears 1300 > > > > > > > times in > > > > > > >U-Boot > > > > > > > > > > > > > > Also in version 2, drivers are introduced for the boot methods, > > > > > > > to make > > > > > > > it more extensible. Booting a custom OS is simply a matter of > > > > > > > creating a > > > > > > > bootmeth for it and implementing the read_file() and boot() > > > > > > > methods. > > > > > > > > > > > > > > Version 4 makes some minor improvements and leaves out the RFC > > > > > > > patch for > > > > > > > rpi conversion, in the hope of getting the base support applied > > > > > > > sooner > > > > > > > rather than later. > > > > > > > > > > > > > > The design is described in these two documents: > > > > > > > > > > > > > > https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2dav4ZkNC12/view?usp=sharing > > > > > > > > > > > > > > https://drive.google.com/file/d/1kTrflO9vvGlKp-ZH_jlgb9TY3WYG6FF9/view?usp=sharing > > > > > > > > > > > > I keep putting off commenting more here, but, I still feel this is > > > > > > the > > > > > > wrong direction. What problems do we have today with distro boot? > > > > > > Well, we haven't figured out how to move configuring it out of the > > > > > > board > > > > > > config.h file. But that's just one of a half dozen or so examples > > > > > > of > > > > > > how we haven't figured out a good solution to configuring the > > > > > > default > > > > > > environment. And only some of those other examples are boot related > > > > > > (the NXP chain of trust booting stuff is another boot example, > > > > > > ETHPRIME, > > > > > > HOSTNAME, etc, are non-boot examples). > > > > > > > > > > > > We also aren't improving testing of "can we boot" here, because what > > > > > > THAT needs is setting up LAVA and booting some installers on some > > > > > > hardware (and some QEMU). That's testing that Linux boot works. > > > > > > Today > > > > > > we have tests for hush parsing, and if distro boot makes use of > > > > > > something we don't have a test for, we need a test for it. This > > > > > > adds > > > > > > tests for itself, which is good. > > > > > > > > > > > > And I still don't see an example of where t
Re: [PATCH v4 00/33] Initial implementation of standard boot
On Fri, Mar 25, 2022 at 03:36:24PM +0100, Michael Nazzareno Trimarchi wrote: > Hi Tom > > > On Wed, Mar 23, 2022 at 9:07 PM Tom Rini wrote: > > > > On Wed, Mar 23, 2022 at 08:57:36PM +0100, Michael Nazzareno Trimarchi wrote: > > > Hi Tom > > > > > > On Wed, Mar 23, 2022 at 8:30 PM Tom Rini wrote: > > > > > > > > On Wed, Mar 23, 2022 at 08:21:22PM +0100, Michael Nazzareno Trimarchi > > > > wrote: > > > > > Hi Tom > > > > > > > > > > On Wed, Mar 23, 2022 at 7:46 PM Simon Glass wrote: > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > On Wed, 23 Mar 2022 at 08:05, Tom Rini wrote: > > > > > > > > > > > > > > On Sun, Mar 06, 2022 at 05:49:43AM -0700, Simon Glass wrote: > > > > > > > > > > > > > > > > The bootflow feature provide a built-in way for U-Boot to > > > > > > > > automatically > > > > > > > > boot an Operating System without custom scripting and other > > > > > > > > customisation. > > > > > > > > This is called 'standard boot' since it provides a standard way > > > > > > > > for > > > > > > > > U-Boot to boot a distro, without scripting. > > > > > > > > > > > > > > > > It introduces the following concepts: > > > > > > > > > > > > > > > >- bootdev - a device which can hold a distro > > > > > > > >- bootmeth - a method to scan a bootdev to find bootflows > > > > > > > > (owned by > > > > > > > > U-Boot) > > > > > > > >- bootflow - a description of how to boot (owned by the > > > > > > > > distro) > > > > > > > > > > > > > > > > This series provides an implementation of these, enabled to > > > > > > > > scan for > > > > > > > > bootflows from MMC, USB and Ethernet. It supports the existing > > > > > > > > distro > > > > > > > > boot as well as the EFI loader flow (bootefi/bootmgr). It works > > > > > > > > similiarly to the existing script-based approach, but is native > > > > > > > > to > > > > > > > > U-Boot. > > > > > > > > > > > > > > > > With this we can boot on a Raspberry Pi 3 with just one command: > > > > > > > > > > > > > > > >bootflow scan -lb > > > > > > > > > > > > > > > > which means to scan, listing (-l) each bootflow and trying to > > > > > > > > boot each > > > > > > > > one (-b). The final patch shows this. > > > > > > > > > > > > > > > > With a standard way to identify boot devices, booting become > > > > > > > > easier. It > > > > > > > > also should be possible to support U-Boot scripts, for backwards > > > > > > > > compatibility only. > > > > > > > > > > > > > > > > This series relies on the PXE clean-up series, posted here: > > > > > > > > > > > > > > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/list/?series=267078 > > > > > > > > > > > > > > > > For documentation, see the 'doc' patch. > > > > > > > > > > > > > > > > For version 2, a new naming scheme is used as above: > > > > > > > > > > > > > > > >- bootdev is used instead of bootdevice, because 'device' is > > > > > > > > overused, > > > > > > > >is everywhere in U-Boot, can be confused with udevice > > > > > > > >- bootmeth - because 'method' is too vanilla, appears 1300 > > > > > > > > times in > > > > > > > >U-Boot > > > > > > > > > > > > > > > > Also in version 2, drivers are introduced for the boot methods, > > > > > > > > to make > > > > > > > > it more extensible. Booting a custom OS is simply a matter of > > > > > > > > creating a > > > > > > > > bootmeth for it and implementing the read_file() and boot() > > > > > > > > methods. > > > > > > > > > > > > > > > > Version 4 makes some minor improvements and leaves out the RFC > > > > > > > > patch for > > > > > > > > rpi conversion, in the hope of getting the base support applied > > > > > > > > sooner > > > > > > > > rather than later. > > > > > > > > > > > > > > > > The design is described in these two documents: > > > > > > > > > > > > > > > > https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2dav4ZkNC12/view?usp=sharing > > > > > > > > > > > > > > > > https://drive.google.com/file/d/1kTrflO9vvGlKp-ZH_jlgb9TY3WYG6FF9/view?usp=sharing > > > > > > > > > > > > > > I keep putting off commenting more here, but, I still feel this > > > > > > > is the > > > > > > > wrong direction. What problems do we have today with distro boot? > > > > > > > Well, we haven't figured out how to move configuring it out of > > > > > > > the board > > > > > > > config.h file. But that's just one of a half dozen or so > > > > > > > examples of > > > > > > > how we haven't figured out a good solution to configuring the > > > > > > > default > > > > > > > environment. And only some of those other examples are boot > > > > > > > related > > > > > > > (the NXP chain of trust booting stuff is another boot example, > > > > > > > ETHPRIME, > > > > > > > HOSTNAME, etc, are non-boot examples). > > > > > > > > > > > > > > We also aren't improving testing of "can we boot" here, because > > > > > > > what > > > > > > > THAT needs is setting up LAVA and booting some installers on some > >
Re: [RFC PATCH 6/6] mkeficapsule: Remove raw and FIT GUID types
Hi, On Thu, 24 Mar 2022 at 17:34, Sughosh Ganu wrote: > > On Thu, 24 Mar 2022 at 20:40, Michal Simek wrote: > > > > > > > > On 3/24/22 15:51, Sughosh Ganu wrote: > > > On Thu, 24 Mar 2022 at 19:55, Michal Simek > > > wrote: > > >> > > >> > > >> > > >> On 3/24/22 13:39, Sughosh Ganu wrote: > > >>> While building a capsule, the GUID value of that specific image is to > > >>> be passed through the --guid command option to the mkeficapsule > > >>> tool. This renders the EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID and > > >>> EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID values superfluous. Remove the > > >>> --raw and --fit command line options as well. > > >>> > > >>> Signed-off-by: Sughosh Ganu > > >>> --- > > >>>tools/eficapsule.h | 8 > > >>>tools/mkeficapsule.c | 26 +- > > >>>2 files changed, 1 insertion(+), 33 deletions(-) > > >>> > > >>> diff --git a/tools/eficapsule.h b/tools/eficapsule.h > > >>> index 69c9c58c2f..d63b831443 100644 > > >>> --- a/tools/eficapsule.h > > >>> +++ b/tools/eficapsule.h > > >>> @@ -37,14 +37,6 @@ typedef struct { > > >>>EFI_GUID(0x6dcbd5ed, 0xe82d, 0x4c44, 0xbd, 0xa1, \ > > >>> 0x71, 0x94, 0x19, 0x9a, 0xd9, 0x2a) > > >>> > > >>> -#define EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID \ > > >>> - EFI_GUID(0xae13ff2d, 0x9ad4, 0x4e25, 0x9a, 0xc8, \ > > >>> - 0x6d, 0x80, 0xb3, 0xb2, 0x21, 0x47) > > >>> - > > >>> -#define EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID \ > > >>> - EFI_GUID(0xe2bb9c06, 0x70e9, 0x4b14, 0x97, 0xa3, \ > > >>> - 0x5a, 0x79, 0x13, 0x17, 0x6e, 0x3f) > > >>> - > > >>>#define EFI_CERT_TYPE_PKCS7_GUID \ > > >>>EFI_GUID(0x4aafd29d, 0x68df, 0x49ee, 0x8a, 0xa9, \ > > >>> 0x34, 0x7d, 0x37, 0x56, 0x65, 0xa7) > > >>> diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c > > >>> index c118335b93..5f74d23b9e 100644 > > >>> --- a/tools/mkeficapsule.c > > >>> +++ b/tools/mkeficapsule.c > > >>> @@ -27,17 +27,11 @@ > > >>>static const char *tool_name = "mkeficapsule"; > > >>> > > >>>efi_guid_t efi_guid_fm_capsule = > > >>> EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID; > > >>> -efi_guid_t efi_guid_image_type_uboot_fit = > > >>> - EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID; > > >>> -efi_guid_t efi_guid_image_type_uboot_raw = > > >>> - EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID; > > >>>efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID; > > >>> > > >>> -static const char *opts_short = "frg:i:I:v:p:c:m:dh"; > > >>> +static const char *opts_short = "g:i:I:v:p:c:m:dh"; > > >>> > > >>>static struct option options[] = { > > >>> - {"fit", no_argument, NULL, 'f'}, > > >>> - {"raw", no_argument, NULL, 'r'}, > > >>>{"guid", required_argument, NULL, 'g'}, > > >>>{"index", required_argument, NULL, 'i'}, > > >>>{"instance", required_argument, NULL, 'I'}, > > >>> @@ -54,8 +48,6 @@ static void print_usage(void) > > >>>fprintf(stderr, "Usage: %s [options] > >>> file>\n" > > >>>"Options:\n" > > >>> > > >>> - "\t-f, --fit FIT image type\n" > > >>> - "\t-r, --raw raw image type\n" > > >>>"\t-g, --guid guid for image blob > > >>> type\n" > > >>>"\t-i, --index update image index\n" > > >>>"\t-I, --instanceupdate hardware > > >>> instance\n" > > >>> @@ -606,22 +598,6 @@ int main(int argc, char **argv) > > >>>break; > > >>> > > >>>switch (c) { > > >>> - case 'f': > > >>> - if (guid) { > > >>> - fprintf(stderr, > > >>> - "Image type already specified\n"); > > >>> - exit(EXIT_FAILURE); > > >>> - } > > >>> - guid = &efi_guid_image_type_uboot_fit; > > >>> - break; > > >>> - case 'r': > > >>> - if (guid) { > > >>> - fprintf(stderr, > > >>> - "Image type already specified\n"); > > >>> - exit(EXIT_FAILURE); > > >>> - } > > >>> - guid = &efi_guid_image_type_uboot_raw; > > >>> - break; > > >>>case 'g': > > >>>if (guid) { > > >>>fprintf(stderr, > > >> > > >> Can you please find a way how to export guid based on what you build? > > >> I think the best would be when capsules are enable to generated them > > >> directly as > > >> the part of build process with proper guids. > > > > > > I don't know how that can be done in a generic way. A platform might > > > have more than one updatable image. So for doing what you are > > > suggesting, we will need to a) pass the board for which the capsule is > > > g
Re: [PATCH v3 1/3] efi_loader: nocolor command line attr for initrddump.efi
Hi Heinrich, On Tue, 22 Mar 2022 at 22:58, Heinrich Schuchardt wrote: > > initrddump.efi uses colored output and clear the screen. This is not > helpful for integration into Python tests. Allow specifying 'nocolor' in > the load option data to suppress color output and clearing the screen. > > Signed-off-by: Heinrich Schuchardt > --- > v3: > new patch > --- > lib/efi_loader/initrddump.c | 77 - > 1 file changed, 68 insertions(+), 9 deletions(-) > > diff --git a/lib/efi_loader/initrddump.c b/lib/efi_loader/initrddump.c > index 7de43bcfff..25dbd635e5 100644 > --- a/lib/efi_loader/initrddump.c > +++ b/lib/efi_loader/initrddump.c > @@ -4,6 +4,9 @@ > * > * initrddump.efi saves the initial RAM disk provided via the > * EFI_LOAD_FILE2_PROTOCOL. > + * > + * Specifying 'nocolor' as load option data suppresses colored output and > + * clearing of the screen. > */ > > #include > @@ -25,6 +28,7 @@ static const efi_guid_t guid_simple_file_system_protocol = > EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID; > static const efi_guid_t load_file2_guid = EFI_LOAD_FILE2_PROTOCOL_GUID; > static efi_handle_t handle; > +static bool nocolor; > > /* > * Device path defined by Linux to identify the handle providing the > @@ -46,6 +50,17 @@ static const struct efi_initrd_dp initrd_dp = { > } > }; > > +/** > + * color() - set foreground color > + * > + * @color: foreground color > + */ > +static void color(u8 color) > +{ > + if (!nocolor) > + cout->set_attribute(cout, color | EFI_BACKGROUND_BLACK); > +} > + > /** > * print() - print string > * > @@ -56,6 +71,17 @@ static void print(u16 *string) > cout->output_string(cout, string); > } > > +/** > + * cls() - clear screen > + */ > +static void cls(void) > +{ > + if (nocolor) > + print(u"\r\n"); > + else > + cout->clear_screen(cout); > +} > + > /** > * error() - print error string > * > @@ -63,9 +89,9 @@ static void print(u16 *string) > */ > static void error(u16 *string) > { > - cout->set_attribute(cout, EFI_LIGHTRED | EFI_BACKGROUND_BLACK); > + color(EFI_LIGHTRED); > print(string); > - cout->set_attribute(cout, EFI_LIGHTBLUE | EFI_BACKGROUND_BLACK); > + color(EFI_LIGHTBLUE); > } > > /* > @@ -215,10 +241,13 @@ static u16 *skip_whitespace(u16 *pos) > * > * @string:string to search for keyword > * @keyword: keyword to be searched > - * Return: true fi @string starts with the keyword > + * Return: true if @string starts with the keyword > */ > static bool starts_with(u16 *string, u16 *keyword) > { > + if (!string || !keyword) > + return false; > + > for (; *keyword; ++string, ++keyword) { > if (*string != *keyword) > return false; > @@ -400,6 +429,30 @@ out: > return ret; > } > > +/** > + * get_load_options() - get load options > + * > + * Return: load options or NULL > + */ > +u16 *get_load_options(void) > +{ > + efi_status_t ret; > + struct efi_loaded_image *loaded_image; > + > + ret = bs->open_protocol(handle, &loaded_image_guid, > + (void **)&loaded_image, NULL, NULL, > + EFI_OPEN_PROTOCOL_GET_PROTOCOL); > + if (ret != EFI_SUCCESS) { > + error(u"Loaded image protocol not found\r\n"); > + return NULL; > + } > + > + if (!loaded_image->load_options_size || !loaded_image->load_options) > + return NULL; > + > + return loaded_image->load_options; > +} > + > /** > * efi_main() - entry point of the EFI application. > * > @@ -410,18 +463,23 @@ out: > efi_status_t EFIAPI efi_main(efi_handle_t image_handle, > struct efi_system_table *systab) > { > + u16 *load_options; > + > handle = image_handle; > systable = systab; > cerr = systable->std_err; > cout = systable->con_out; > cin = systable->con_in; > bs = systable->boottime; > + load_options = get_load_options(); Don't we need to check for NULL here? > > - cout->set_attribute(cout, EFI_LIGHTBLUE | EFI_BACKGROUND_BLACK); > - cout->clear_screen(cout); > - cout->set_attribute(cout, EFI_WHITE | EFI_BACKGROUND_BLACK); > + if (starts_with(load_options, u"nocolor")) > + nocolor = true; > + > + color(EFI_WHITE); > + cls(); > print(u"INITRD Dump\r\n===\r\n\r\n"); > - cout->set_attribute(cout, EFI_LIGHTBLUE | EFI_BACKGROUND_BLACK); > + color(EFI_LIGHTBLUE); > > for (;;) { > u16 command[BUFFER_SIZE]; > @@ -443,7 +501,8 @@ efi_status_t EFIAPI efi_main(efi_handle_t image_handle, > do_help(); > } > > - cout->set_attribute(cout, EFI_LIGHTGRAY | EFI_BACKGROUND_BLACK
Re: [PATCH v3 2/3] efi_loader: initrddump: drain input before prompt
On Tue, 22 Mar 2022 at 22:58, Heinrich Schuchardt wrote: > > Up to now the initrddump.efi application has drained the input after > showing the prompt. This works for humans but leads to problems when > automating testing. If the input is drained, this should be done before > showing the prompt. > > Signed-off-by: Heinrich Schuchardt > --- > v3: > new patch > --- > lib/efi_loader/initrddump.c | 14 ++ > 1 file changed, 10 insertions(+), 4 deletions(-) > > diff --git a/lib/efi_loader/initrddump.c b/lib/efi_loader/initrddump.c > index 25dbd635e5..4dd40eb0d3 100644 > --- a/lib/efi_loader/initrddump.c > +++ b/lib/efi_loader/initrddump.c > @@ -120,6 +120,14 @@ static void printx(u64 val, u32 prec) > print(buf); > } > > +/** > + * efi_drain_input() - drain console input > + */ > +static void efi_drain_input(void) > +{ > + cin->reset(cin, true); > +} > + > /** > * efi_input_yn() - get answer to yes/no question > * > @@ -137,8 +145,6 @@ static efi_status_t efi_input_yn(void) > efi_uintn_t index; > efi_status_t ret; > > - /* Drain the console input */ > - ret = cin->reset(cin, true); > for (;;) { > ret = bs->wait_for_event(1, &cin->wait_for_key, &index); > if (ret != EFI_SUCCESS) > @@ -179,8 +185,6 @@ static efi_status_t efi_input(u16 *buffer, efi_uintn_t > buffer_size) > u16 outbuf[2] = u" "; > efi_status_t ret; > > - /* Drain the console input */ > - ret = cin->reset(cin, true); > *buffer = 0; > for (;;) { > ret = bs->wait_for_event(1, &cin->wait_for_key, &index); > @@ -393,6 +397,7 @@ static efi_status_t do_save(u16 *filename) > ret = root->open(root, &file, filename, EFI_FILE_MODE_READ, 0); > if (ret == EFI_SUCCESS) { > file->close(file); > + efi_drain_input(); > print(u"Overwrite existing file (y/n)? "); > ret = efi_input_yn(); > print(u"\r\n"); > @@ -486,6 +491,7 @@ efi_status_t EFIAPI efi_main(efi_handle_t image_handle, > u16 *pos; > efi_uintn_t ret; > > + efi_drain_input(); > print(u"=> "); > ret = efi_input(command, sizeof(command)); > if (ret == EFI_ABORTED) > -- > 2.34.1 > Acked-by: Ilias Apalodimas
[PATCH] spi: rockchip_sfc: Add missing include for dm/device_compat.h
From: Chris Morgan Add missing include for dm/device_compat.h. Without this include the SFC driver fails to compile because dev_err and dev_dbg are not defined. Signed-off-by: Chris Morgan --- drivers/spi/rockchip_sfc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/spi/rockchip_sfc.c b/drivers/spi/rockchip_sfc.c index e098ac..851a648298 100644 --- a/drivers/spi/rockchip_sfc.c +++ b/drivers/spi/rockchip_sfc.c @@ -12,6 +12,7 @@ #include #include #include +#include #include #include #include -- 2.25.1
Re: [PATCH 1/2] net: dsa: fix phydev->speed being uninitialized for the CPU port fixed PHY
On Sat, Dec 4, 2021 at 3:01 PM Vladimir Oltean wrote: > > If the DSA API is going to allow drivers to do things such as: > > - phy_config in dsa_ops :: port_probe > - phy_startup in dsa_ops :: port_enable > > then it would actually be good if the ->port_probe() method would > actually be called in all cases before the ->port_enable() is. > > Currently this is true for user ports, but not true for the CPU port, > because the CPU port does not have a udevice registered for it (this is > all part of DSA's design). So the current issue is that after > phy_startup has finished for the CPU port, its phydev->speed is an > uninitialized value, because phy_config() was never called for the > priv->cpu_port_fixed_phy, and it is precisely phy_config() who copies > the speed into the phydev in the case of the fixed PHY driver. > > So we need to simulate a probing event for the CPU port by manually > calling the driver's ->port_probe() method for the CPU port. > > Fixes: 8a2982574854 ("net: dsa: introduce a .port_probe() method in struct > dsa_ops") > Signed-off-by: Vladimir Oltean > --- > net/dsa-uclass.c | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c > index 606b1539a776..9ff55a02fb23 100644 > --- a/net/dsa-uclass.c > +++ b/net/dsa-uclass.c > @@ -466,6 +466,8 @@ static int dsa_pre_probe(struct udevice *dev) > { > struct dsa_pdata *pdata = dev_get_uclass_plat(dev); > struct dsa_priv *priv = dev_get_uclass_priv(dev); > + struct dsa_ops *ops = dsa_get_ops(dev); > + int err; > > priv->num_ports = pdata->num_ports; > priv->cpu_port = pdata->cpu_port; > @@ -477,6 +479,15 @@ static int dsa_pre_probe(struct udevice *dev) > > uclass_find_device_by_ofnode(UCLASS_ETH, pdata->master_node, > &priv->master_dev); > + > + /* Simulate a probing event for the CPU port */ > + if (ops->port_probe) { > + err = ops->port_probe(dev, priv->cpu_port, > + priv->cpu_port_fixed_phy); > + if (err) > + return err; > + } > + > return 0; > } > > -- > 2.25.1 > Vladimir, I came across this while looking for the best place to configure cpu port interface mode (ie rgmii id) for the mv88e61xx dsa driver I'm working on. Note that this patch causes port_probe to be called on the cpu port 'before' the master device has been probed. I'm not sure if this is intended or not? In my case I was looking to configure the cpu port interface mode when the port was probed but I can't do that because it happens before the switch is probed because of some things that need to happen there. Best Regards, Tim
[PATCH] doc: man-page for the wdt command
Describe the wdt command. Signed-off-by: Heinrich Schuchardt --- doc/usage/index.rst | 1 + doc/usage/wdt.rst | 77 + 2 files changed, 78 insertions(+) create mode 100644 doc/usage/wdt.rst diff --git a/doc/usage/index.rst b/doc/usage/index.rst index 0aacf531b2..630a6cb28a 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -52,3 +52,4 @@ Shell commands size true ums + wdt diff --git a/doc/usage/wdt.rst b/doc/usage/wdt.rst new file mode 100644 index 00..8d80433c1f --- /dev/null +++ b/doc/usage/wdt.rst @@ -0,0 +1,77 @@ +.. SPDX-License-Identifier: GPL-2.0+: + +wdt command + + +Synopsis + + +:: + +wdt list +wdt dev [] +wdt start [flags] +wdt stop +wdt reset +wdt expirer [flags] + +Description +--- + +The wdt command is used to control watchdog timers. + +The 'wdt list' command shows a list of all watchdog devices. + +The 'wdt dev' command called without argument shows the current watchdog device. +The current device is set when passing the name of the device as argument. + +The 'wdt start' command starts the current watchdog timer. + +The 'wdt stop' command stops the current watchdog timer. + +The 'wdt reset' command resets the current watchdog timer without stopping it. + +The 'wdt expire' command let's the current watchdog timer expire immediately. +This will lead to a reset. + +name +name of the watchdog device + +timeout_ms +timeout interval in milliseconds + +flags +unsigned long value passed to the driver. The usage is driver specific. +The value is ignored by most drivers. + +Example +--- + +:: + +=> wdt dev +No watchdog timer device set! +=> wdt list +watchdog@1c20ca0 (sunxi_wdt) +=> wdt dev watchdog@1c20ca0 +=> wdt dev +dev: watchdog@1c20ca0 +=> wdt start 3000 +=> wdt reset +=> wdt stop +=> wdt expire + +U-Boot SPL 2022.04-rc3 (Mar 25 2022 - 13:48:33 +) + + In the example above '(sunxi_wdt)' refers to the driver for the watchdog + device. + +Configuration +- + +The command is only available if CONFIG_CMD_WDT=y. + +Return value + + +The return value $? is 0 if the command succeeds, 1 upon failure. -- 2.34.1
[PATCH] rockchip: clk: add clocks to px30_clk_enable
From: Chris Morgan Add the HCLK_OTG, HCLK_SFC, and SCLK_SFC clocks to px30_clk_enable. Without this change U-Boot reports an error of "Enable clock-controller@ff2b failed" on boot when using the SFC or USB in U-Boot. Signed-off-by: Chris Morgan --- drivers/clk/rockchip/clk_px30.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/clk/rockchip/clk_px30.c b/drivers/clk/rockchip/clk_px30.c index ea874e3f4b..5d467447a1 100644 --- a/drivers/clk/rockchip/clk_px30.c +++ b/drivers/clk/rockchip/clk_px30.c @@ -1403,10 +1403,13 @@ static int px30_clk_enable(struct clk *clk) { switch (clk->id) { case HCLK_HOST: + case HCLK_OTG: + case HCLK_SFC: case SCLK_GMAC: case SCLK_GMAC_RX_TX: case SCLK_MAC_REF: case SCLK_MAC_REFOUT: + case SCLK_SFC: case ACLK_GMAC: case PCLK_GMAC: case SCLK_GMAC_RMII: -- 2.25.1
Re: [PATCH v7 14/16] test: py: vboot: add test for global image signature
On Mon, Mar 14, 2022 at 03:57:43PM +0100, Philippe Reynes wrote: > Adds test units for the pre-load header signature. > > Signed-off-by: Philippe Reynes > --- > test/py/tests/test_vboot.py | 145 -- > test/py/tests/vboot/sandbox-binman-pss.dts| 25 +++ > test/py/tests/vboot/sandbox-binman.dts| 24 +++ > .../tests/vboot/sandbox-u-boot-global-pss.dts | 28 > test/py/tests/vboot/sandbox-u-boot-global.dts | 27 > test/py/tests/vboot/simple-images.its | 36 + > 6 files changed, 269 insertions(+), 16 deletions(-) > create mode 100644 test/py/tests/vboot/sandbox-binman-pss.dts > create mode 100644 test/py/tests/vboot/sandbox-binman.dts > create mode 100644 test/py/tests/vboot/sandbox-u-boot-global-pss.dts > create mode 100644 test/py/tests/vboot/sandbox-u-boot-global.dts > create mode 100644 test/py/tests/vboot/simple-images.its This leads to CI failures such as: https://source.denx.de/u-boot/u-boot/-/jobs/412046 and I guess maybe we need something new in test/py/requirements.txt maybe? The rest of the series seems fine, btw. -- Tom signature.asc Description: PGP signature
[PATCH] ARM: imx: Decode ECSPI env location from i.MX8M ROMAPI tables
Decode ECSPI boot device in env_get_location() from i.MX8M ROMAPI tables. This is necessary to correctly identify env is in SPI NOR when the system boots from SPI NOR attached to ECSPI. Signed-off-by: Marek Vasut Cc: Fabio Estevam Cc: Peng Fan Cc: Stefano Babic --- arch/arm/include/asm/mach-imx/sys_proto.h | 1 + arch/arm/mach-imx/imx8m/soc.c | 4 2 files changed, 5 insertions(+) diff --git a/arch/arm/include/asm/mach-imx/sys_proto.h b/arch/arm/include/asm/mach-imx/sys_proto.h index 0c0c7814fb2..309f8d17959 100644 --- a/arch/arm/include/asm/mach-imx/sys_proto.h +++ b/arch/arm/include/asm/mach-imx/sys_proto.h @@ -159,6 +159,7 @@ enum boot_dev_type_e { BT_DEV_TYPE_MMC = 2, BT_DEV_TYPE_NAND = 3, BT_DEV_TYPE_FLEXSPINOR = 4, + BT_DEV_TYPE_SPI_NOR = 6, BT_DEV_TYPE_USB = 0xE, BT_DEV_TYPE_MEM_DEV = 0xF, diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c index 1a5a391443d..ccbbe545810 100644 --- a/arch/arm/mach-imx/imx8m/soc.c +++ b/arch/arm/mach-imx/imx8m/soc.c @@ -597,6 +597,9 @@ enum boot_device get_boot_device(void) case BT_DEV_TYPE_FLEXSPINOR: boot_dev = QSPI_BOOT; break; + case BT_DEV_TYPE_SPI_NOR: + boot_dev = SPI_NOR_BOOT; + break; case BT_DEV_TYPE_USB: boot_dev = USB_BOOT; break; @@ -1335,6 +1338,7 @@ enum env_location env_get_location(enum env_operation op, int prio) switch (dev) { case QSPI_BOOT: + case SPI_NOR_BOOT: if (IS_ENABLED(CONFIG_ENV_IS_IN_SPI_FLASH)) return ENVL_SPI_FLASH; return ENVL_NOWHERE; -- 2.35.1
Re: [PATCH 1/2] net: dsa: fix phydev->speed being uninitialized for the CPU port fixed PHY
Hi Tim, On Fri, Mar 25, 2022 at 09:53:20AM -0700, Tim Harvey wrote: > Vladimir, > > I came across this while looking for the best place to configure cpu > port interface mode (ie rgmii id) for the mv88e61xx dsa driver I'm > working on. Note that this patch causes port_probe to be called on the > cpu port 'before' the master device has been probed. I'm not sure if > this is intended or not? > > In my case I was looking to configure the cpu port interface mode when > the port was probed but I can't do that because it happens before the > switch is probed because of some things that need to happen there. > Best Regards, > > Tim You're past the DM_MDIO probing issues now? Glad to hear that. Probing the DSA CPU port before the master wasn't necessarily the intention, but then again, I'm not sure that there's a strict ordering guarantee between the two that needs to be satisfied? What do you need exactly? We could probably always reverse the device_probe(master) call with the probing of the CPU port if the ordering turns out to be a real problem. I can regression-test the change on my boards, but I'd like to understand the need you have, maybe even document it so that future changes are aware of it.
Re: [PATCH v4 9/9] configs: imx8mm_evk: add pwm backlight support
Hi Tommaso, On Fri, Mar 25, 2022 at 9:04 AM Tommaso Merciai wrote: > > Enable support for backlight/pwm-imx driver > > Signed-off-by: Tommaso Merciai > --- > configs/imx8mm_evk_defconfig | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/configs/imx8mm_evk_defconfig b/configs/imx8mm_evk_defconfig > index 01395fc7eb..cfba6cc673 100644 > --- a/configs/imx8mm_evk_defconfig > +++ b/configs/imx8mm_evk_defconfig > @@ -84,3 +84,8 @@ CONFIG_SYSRESET_PSCI=y > CONFIG_SYSRESET_WATCHDOG=y > CONFIG_DM_THERMAL=y > CONFIG_IMX_WATCHDOG=y > +CONFIG_DM_VIDEO=y There is no video driver for imx8mm yet, so you could drop this one, right?
Re: [PATCH] ARM: imx: Decode ECSPI env location from i.MX8M ROMAPI tables
Hi Marek, On 25/03/2022 14:59, Marek Vasut wrote: Decode ECSPI boot device in env_get_location() from i.MX8M ROMAPI tables. This is necessary to correctly identify env is in SPI NOR when the system boots from SPI NOR attached to ECSPI. Signed-off-by: Marek Vasut Cc: Fabio Estevam Cc: Peng Fan Cc: Stefano Babic Reviewed-by: Fabio Estevam
Re: [1/3] pinctrl: mediatek: rewrite mtk_pinconf_set and related functions
On Thu, Mar 10, 2022 at 12:31:43PM +0800, Sam Shih wrote: > There are many pins in a SoCs, and different pin may belong > to different "io_type", For example: some pins of MT7622 belongs > to "io_type A", the other belongs to "io_type B", and pinctrl "V0" > means handle pinconf via "io_type A" or "io_type B", so SoCs that > contain "io_type A" and "io_type B" pins, use "V0" in pinctrl driver. > > This patch separates the implementation of register operations > (e.g: "bias-pull-up/down", "driving" and "input-enable") into > different functions, and lets the original V0/V1 > ops to call the new functions. > > Signed-off-by: Sam Shih This series breaks mt7623a_unielec_u7623_02 and other mediatek platforms, please retest and resubmit, thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] net: dsa: fix phydev->speed being uninitialized for the CPU port fixed PHY
On Fri, Mar 25, 2022 at 11:07 AM Vladimir Oltean wrote: > > Hi Tim, > > On Fri, Mar 25, 2022 at 09:53:20AM -0700, Tim Harvey wrote: > > Vladimir, > > > > I came across this while looking for the best place to configure cpu > > port interface mode (ie rgmii id) for the mv88e61xx dsa driver I'm > > working on. Note that this patch causes port_probe to be called on the > > cpu port 'before' the master device has been probed. I'm not sure if > > this is intended or not? > > > > In my case I was looking to configure the cpu port interface mode when > > the port was probed but I can't do that because it happens before the > > switch is probed because of some things that need to happen there. > > Best Regards, > > > > Tim > > You're past the DM_MDIO probing issues now? Glad to hear that. > Probing the DSA CPU port before the master wasn't necessarily the > intention, but then again, I'm not sure that there's a strict ordering > guarantee between the two that needs to be satisfied? > > What do you need exactly? We could probably always reverse the > device_probe(master) call with the probing of the CPU port if the > ordering turns out to be a real problem. I can regression-test the > change on my boards, but I'd like to understand the need you have, maybe > even document it so that future changes are aware of it. Yes, I've got the mdio probing working now. The mv88e61xx driver supports several chips that have different register offsets that need to be known before indirect read/write and port read/write can be used. That detection happens early on so I have it in the dsa_probe. I would prefer to configure the cpu port interface mode (mac mode, link speed/duplex etc) once instead of doing it every time the cpu port gets enabled so I want to put that in the dsa_probe but at that time I don't have the phy_device to determine interface mode (I suppose I could get it from dt?). I noticed dsa_class calls ops->port_probe for the cpu port early so that seemed like a great place to do all that, but then I found my switch dsa_probe hadn't been called yet so I haven't identified the switch and set the register offsets yet. I have worked around the fact that the port_probe is called for the cpu port before the switch is probed I just wasn't sure if something in this patch should be changed in case others fall into this trap in the future. dsa_port_probe probes the master before calling ops->port_probe with the comment 'We depend on the master device for proper operation' so I just figured the same should be done for the pre_probe. I hope to send a series in the next few days but I do have a few items I still need to fix: 1. my board currently uses the mv88e61xx_hw_reset weak override to configure LEDs, GPIO's using direct register writes as I need one of the GPIO's to be configured as a 125MHz RGMII_RCLK and configure MAC interface mode(rgmii delays). I've moved the mac interface config into the driver based on the dt props (phy-mode and fixed-link subnode) but am still not sure how to go about dealing with the 'very custom' LED and GPIO config without the hassle of defining new dt bindings. I was hoping to use board_phy_config() but when that is called for the switch the phy_id is a generic PHY_FIXED_ID and when called for the ports the phydev->bus uses indirect register writes which can't be used to configure the gpios. 2. While my switch mdio bus is probing now as well as my fec_dm_mdio bus I'm not clear how to properly get the struct mii_dev * associated with the fec_dm_mdio from the dsa switch. Currently I'm using miiphy_get_dev_by_name("mdio") which is horrible. How do I get the mii_bus or even the udevice of an dm_mdio bus associated with a dm_eth device? Best Regards, Tim
Re: [PATCH v7 14/16] test: py: vboot: add test for global image signature
Hi Tom, Le 25/03/2022 à 18:11, Tom Rini a écrit : On Mon, Mar 14, 2022 at 03:57:43PM +0100, Philippe Reynes wrote: Adds test units for the pre-load header signature. Signed-off-by: Philippe Reynes --- test/py/tests/test_vboot.py | 145 -- test/py/tests/vboot/sandbox-binman-pss.dts| 25 +++ test/py/tests/vboot/sandbox-binman.dts| 24 +++ .../tests/vboot/sandbox-u-boot-global-pss.dts | 28 test/py/tests/vboot/sandbox-u-boot-global.dts | 27 test/py/tests/vboot/simple-images.its | 36 + 6 files changed, 269 insertions(+), 16 deletions(-) create mode 100644 test/py/tests/vboot/sandbox-binman-pss.dts create mode 100644 test/py/tests/vboot/sandbox-binman.dts create mode 100644 test/py/tests/vboot/sandbox-u-boot-global-pss.dts create mode 100644 test/py/tests/vboot/sandbox-u-boot-global.dts create mode 100644 test/py/tests/vboot/simple-images.its This leads to CI failures such as: https://source.denx.de/u-boot/u-boot/-/jobs/412046 and I guess maybe we need something new in test/py/requirements.txt maybe? I think that this issue should be fixed with this patch : https://patchwork.ozlabs.org/project/uboot/patch/20220127140314.10264-2-philippe.rey...@softathome.com/ The rest of the series seems fine, btw. great, thanks a lot Regards, Philippe
Re: [PATCH v7 14/16] test: py: vboot: add test for global image signature
On Fri, Mar 25, 2022 at 11:54:18PM +0100, Philippe REYNES wrote: > Hi Tom, > > > Le 25/03/2022 à 18:11, Tom Rini a écrit : > > On Mon, Mar 14, 2022 at 03:57:43PM +0100, Philippe Reynes wrote: > > > > > Adds test units for the pre-load header signature. > > > > > > Signed-off-by: Philippe Reynes > > > --- > > > test/py/tests/test_vboot.py | 145 -- > > > test/py/tests/vboot/sandbox-binman-pss.dts| 25 +++ > > > test/py/tests/vboot/sandbox-binman.dts| 24 +++ > > > .../tests/vboot/sandbox-u-boot-global-pss.dts | 28 > > > test/py/tests/vboot/sandbox-u-boot-global.dts | 27 > > > test/py/tests/vboot/simple-images.its | 36 + > > > 6 files changed, 269 insertions(+), 16 deletions(-) > > > create mode 100644 test/py/tests/vboot/sandbox-binman-pss.dts > > > create mode 100644 test/py/tests/vboot/sandbox-binman.dts > > > create mode 100644 test/py/tests/vboot/sandbox-u-boot-global-pss.dts > > > create mode 100644 test/py/tests/vboot/sandbox-u-boot-global.dts > > > create mode 100644 test/py/tests/vboot/simple-images.its > > This leads to CI failures such as: > > https://source.denx.de/u-boot/u-boot/-/jobs/412046 > > and I guess maybe we need something new in test/py/requirements.txt > > maybe? > > I think that this issue should be fixed with this patch : > > https://patchwork.ozlabs.org/project/uboot/patch/20220127140314.10264-2-philippe.rey...@softathome.com/ OK, but that's a rather specific hard-coded path to add, and won't work in my setup for example since I use mktemp to make the base dir for all my tests. -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] sandbox: video: Replace PCI_CLASS_* macros by one from pci_ids.h
On Fri, Feb 18, 2022 at 01:16:18PM +0100, Pali Rohár wrote: > Replace old macros PCI_CLASS_CODE_COMM and PCI_CLASS_SUB_CODE_COMM_SERIAL > by new macros defined in pci_ids.h. Old macros would be deleted in followup > commit. > > Signed-off-by: Pali Rohár > Reviewed-by: Stefan Roese Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/2] pci: Remove duplicate PCI_CLASS_CODE_* and PCI_CLASS_SUB_CODE_* macros
On Fri, Feb 18, 2022 at 01:16:19PM +0100, Pali Rohár wrote: > Macros PCI_CLASS_CODE_* and PCI_CLASS_SUB_CODE_* are unused and are > duplication of PCI_CLASS_* macros defined in pci_ids.h header file. > So remove them. > > Signed-off-by: Pali Rohár > Reviewed-by: Stefan Roese Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] pci: Add defines for normal and subtractive PCI bridges
On Fri, Feb 18, 2022 at 01:18:40PM +0100, Pali Rohár wrote: > Add following two new PCI class codes defines into pci_ids.h include file: > > PCI_CLASS_BRIDGE_PCI_NORMAL > PCI_CLASS_BRIDGE_PCI_SUBTRACTIVE > > And use these defines in all U-Boot code for describing PCI class codes for > normal and subtractive PCI bridges. > > Signed-off-by: Pali Rohár > Reviewed-by: Stefan Roese Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Pull request: u-boot-sunxi/master fix for v2022.04
Hi Tom, please pull the master branch from u-boot-sunxi, containing two regression fixes for 2022.04, related to Allwinner networking: - - Fix A20 GBit Ethernet operation - Update board .dts files to provide correct RGMII PHY mode - Tested on BananaPi M1, Pine64 LTS, and Pine H64. Thanks, Andre === The following changes since commit cbc05bba8cb7da62eae65f41e1b0ddbcadc06bba: doc: update doc/sphinx/requirements.txt (2022-03-25 08:59:49 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master for you to fetch changes up to 85da5587629b12220c2f19ac0780ca8f4c482f16: sunxi: dts: Update RGMII phy-mode properties (2022-03-26 00:16:44 +) Andre Przywara (2): sunxi: Fix old GMAC pinmux setup sunxi: dts: Update RGMII phy-mode properties arch/arm/dts/sun50i-a64-sopine-baseboard.dts | 2 +- arch/arm/dts/sun50i-h5-nanopi-neo2.dts| 2 +- arch/arm/dts/sun50i-h5-orangepi-zero-plus.dts | 2 +- arch/arm/dts/sun6i-a31-hummingbird.dts| 2 +- arch/arm/dts/sun7i-a20-bananapi-m1-plus.dts | 2 +- arch/arm/dts/sun7i-a20-bananapi.dts | 2 +- arch/arm/dts/sun7i-a20-bananapro.dts | 2 +- arch/arm/dts/sun7i-a20-cubietruck.dts | 2 +- arch/arm/dts/sun7i-a20-olinuxino-lime2.dts| 2 +- arch/arm/dts/sun7i-a20-pcduino3-nano.dts | 2 +- arch/arm/dts/sun8i-a83t-bananapi-m3.dts | 2 +- arch/arm/dts/sun8i-a83t-cubietruck-plus.dts | 2 +- arch/arm/dts/sun8i-h3-orangepi-plus.dts | 2 +- arch/arm/dts/sunxi-bananapi-m2-plus.dtsi | 2 +- arch/arm/mach-sunxi/board.c | 1 - board/sunxi/board.c | 3 +++ 16 files changed, 17 insertions(+), 15 deletions(-)
Re: [PATCH] arm: kirkwood: Add nas440 board, Marvell 88SE6121 AHCI
Hi Hajo, General comments: - You're missing a file in this patch set: arch/arm/mach-kirkwood/Kconfig. - There are numerous style problems. You should run scripts/checkpatch.pl on each file to cleanup. Also look into using patman to create patches, and possibly sending patches too. It takes a bit of getting used to, but patman is very useful. Especially sending patch series and revisions. - Please use the canonical form for nas440_defconfig. make nas440_deconfig make savedefconfig mv defconfig configs/nas440_defconfig - This is a board that is not yet supported in mainline Linux (i.e. there is no legacy dependency). Thus, we don't want to use ATAGS. Remove: > > > +CONFIG_SUPPORT_PASSING_ATAGS=y > > > +CONFIG_CMDLINE_TAG=y > > > +CONFIG_INITRD_TAG=y - This patch will need a revision after Tom's patch is merged to master. See: https://lists.denx.de/pipermail/u-boot/2022-March/478823.html Thanks, Tony On Thu, Mar 24, 2022 at 3:04 PM Tony Dinh wrote: > > Hi Hajo, > > I've added Stefan. > > When you send patches for Kirkwood or other Marvell boards, please > also send it directly to Stefan (Stefan is the maintainer of Marvell > u-boots). > > Tony > > On Thu, Mar 24, 2022 at 3:11 AM Pali Rohár wrote: > > > > Hello! > > > > On Thursday 24 March 2022 10:55:38 Hajo Noerenberg wrote: > > > This adds support for the Seagate Blackarmor NAS440 (4-bay Kirkwood NAS > > > box). > > > > > > Does it make sense to include support for a 10+ year old device? > > > > If these old devices are still in use and you would like to maintain > > this support then I think that there is no issue with it. > > > > > If yes, I would be willing to discuss and finalize this patch. If no, it > > > will be archived here for the public, which is fine with me. > > > > > > For the NAS440 is the something special that hard disk drives 1 and 2 are > > > connected to a 88SE6121 SATA-II controller, which is connected via PCIe. > > > Hard disk drives 3 and 4 are directly connected to the 88F6281 SoC. > > > > > > - Add NAS440 dtb and associated files/configs > > > * Includes support for HD44780 front LCD > > > * Includes support for device LEDs (via 74AHC164 shift register) > > > - Add Marvell 88SE6121 AHCI support. Thanks to Pali Rohár for recently > > > adding the necessary Kirkwood PCIe driver. It works :) > > > > Perfect! > > > > > - Tested with my NAS440 hardware: ETH/USB/SATA/AHCI-SCSI/GPIO/LCD/LEDs ok > > > > > > As far as I can see this fully implements the support for this board > > > within U-Boot. With the Linux kernel however there are problems, the > > > kernel AHCI driver fails with "failed to IDENTIFY" messages for the > > > 88SE6121 drive ports, which I could not solve yet despite comparison with > > > the GPL sources from Seagate. > > > > > > Note: I am collecting various information and patches for the family of > > > Blackarmor NAS boards at https://github.com/hn/seagate-blackarmor-nas > > > > > > Hajo > > > > > > > > > --- > > > arch/arm/dts/kirkwood-blackarmor-nas440.dts | 166 + > > > board/Seagate/nas440/Kconfig| 12 + > > > board/Seagate/nas440/MAINTAINERS| 7 + > > > board/Seagate/nas440/Makefile | 7 + > > > board/Seagate/nas440/kwbimage.cfg | 156 > > > board/Seagate/nas440/nas440.c | 378 > > > configs/nas440_defconfig| 89 + > > > drivers/ata/ahci-pci.c | 1 + > > > include/configs/nas440.h| 50 +++ > > > 9 files changed, 866 insertions(+) > > > create mode 100644 arch/arm/dts/kirkwood-blackarmor-nas440.dts > > > create mode 100644 board/Seagate/nas440/Kconfig > > > create mode 100644 board/Seagate/nas440/MAINTAINERS > > > create mode 100644 board/Seagate/nas440/Makefile > > > create mode 100644 board/Seagate/nas440/kwbimage.cfg > > > create mode 100644 board/Seagate/nas440/nas440.c > > > create mode 100644 configs/nas440_defconfig > > > create mode 100644 include/configs/nas440.h > > > > > > diff --git a/arch/arm/dts/kirkwood-blackarmor-nas440.dts > > > b/arch/arm/dts/kirkwood-blackarmor-nas440.dts > > > new file mode 100644 > > > index 00..60e3fe6f0d > > > --- /dev/null > > > +++ b/arch/arm/dts/kirkwood-blackarmor-nas440.dts > > > @@ -0,0 +1,166 @@ > > > +// SPDX-License-Identifier: GPL-2.0+ > > > +/* > > > + * Device Tree file for Seagate Blackarmor NAS440 > > > + * > > > + * Copyright (C) 2021 Hajo Noerenberg > > > + * Copyright (C) 2015 Andreas Fischer > > > + * Copyright (C) 2014 Evgeni Dobrev > > > + */ > > > + > > > +/dts-v1/; > > > + > > > +#include > > > +#include > > > +#include "kirkwood.dtsi" > > > +#include "kirkwood-6281.dtsi" > > > + > > > +/ { > > > + model = "Seagate Blackarmor NAS440"; > > > + compatible = "seagate,blackarmor-nas440","marvell,kirkwood-88f6281", > > > + "marvell,kirkwood"; > > > + > > > + memory { /* 256 MB */ > > > + device_type =
Re: [PATCH 1/2] Split CONFIG_CC_OPTIMIZE_FOR_SIZE into two configs
On Tue, Feb 22, 2022 at 12:19:24PM -0500, Sean Anderson wrote: > This adds a separate CONFIG_CC_OPTIMIZE_FOR_SPEED option in a choice, > in preparation for adding another optimization option. Also convert SH's > makefile to use this new option. > > Signed-off-by: Sean Anderson > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/2] Add option to use -Og
On Tue, Feb 22, 2022 at 12:19:25PM -0500, Sean Anderson wrote: > This adds support for using -Og when building U-Boot. According to the > gcc man page: > > > -Og should be the optimization level of choice for the standard > > edit-compile-debug cycle, offering a reasonable level of optimization > > while maintaining fast compilation and a good debugging experience. > > This optimization level is roughly -O1 minus a few additional > optimizations. It provides a noticably better debugging experience, with > many fewer variables . > > Signed-off-by: Sean Anderson > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] cmd: test: pinmux: Do not check all empty spaces
On Mon, Mar 07, 2022 at 04:48:17PM +0100, Michal Simek wrote: > There is really no value to check empty spaces. That's why use > ut_assert_nextlinen() instead of ut_assert_nextline(). > This change ensures that PINMUX_SIZE can be increased without changing > tests. > > Signed-off-by: Michal Simek > Reviewed-by: Patrice Chotard Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/3] pwm: Add Aspeed ast2600 PWM support
On Tue, Mar 08, 2022 at 11:04:05AM +0800, Billy Tsai wrote: > This patch add the support of PWM controller which can be found at aspeed > ast2600 soc. The pwm supoorts up to 16 channels and it's part function > of multi-function device "pwm-tach controller". > > Signed-off-by: Billy Tsai > Reviewed-by: Simon Glass > Reviewed-by: Chia-Wei Wang Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/3] pinctrl: Add the pinctrl setting for PWM.
On Tue, Mar 08, 2022 at 11:04:06AM +0800, Billy Tsai wrote: > This patchs add the signal description array for PWM pinctrl settings. > > Signed-off-by: Billy Tsai > Reviewed-by: Simon Glass > Reviewed-by: Chia-Wei Wang Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/3] ARM: dts: ast2600: Add PWM to device tree
On Tue, Mar 08, 2022 at 11:04:07AM +0800, Billy Tsai wrote: > Add the PWM node and enable it for AST2600 EVB > > Signed-off-by: Billy Tsai > Reviewed-by: Simon Glass > Reviewed-by: Chia-Wei Wang Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/5] disk: Add an option for partitions in SPL
On Fri, Mar 11, 2022 at 12:10:01PM -0700, Simon Glass wrote: > In some cases we do not want to enable partition support in SPL. Add an > option to allow this. > > Signed-off-by: Simon Glass With a slight tweak (as disk/disk-uclass.c isn't in yet), applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/2] power: pfuze100: Add MEMx register definitions
On Fri, Mar 18, 2022 at 12:04:37PM +0100, Philip Oberfichtner wrote: > Add missing MEMA - MEMD register definitions for PFUZE100. > > Based on work from Heiko Schocher . > Signed-off-by: Philip Oberfichtner Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 2/2] bootcount: Add pmic pfuze100 bootcount driver
On Fri, Mar 18, 2022 at 12:04:38PM +0100, Philip Oberfichtner wrote: > Use the MEMA - MEMD registers on the PFUZE100 as bootcount > registers. > > Based on work from Heiko Schocher . > Signed-off-by: Philip Oberfichtner Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: Pull request: u-boot-sunxi/master fix for v2022.04
On Sat, Mar 26, 2022 at 01:13:22AM +, Andre Przywara wrote: > Hi Tom, > > please pull the master branch from u-boot-sunxi, containing two regression > fixes for 2022.04, related to Allwinner networking: Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH v2 0/6] efi: capsule: Image GUID usage cleanup
This series is cleaning up the usage of the image GUIDs that are used in capsule update and the EFI System Resource Table(ESRT). 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. 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 The first patch of this series adds the fw_images array in all platforms which are using UEFI capsule updates The second patch of the series changes the logic for populating the image descriptor array, using the information from the fw_images array defined by the platform. The third patch of the series removes the test cases using the --raw and --fit parameters, removes test case for FIT images, and refactors the test scripts, one for raw images, and one for FIT images. The FIT test case is enabled on sandbox_flattree variant. The fourth patch of the series makes corresponding changes in the capsule update related documentation. The fifth patch of the series removes the now unused FIT and raw image GUID values from the FMP module. The sixth patch of the series removes the --raw and --fit command line parameters in the mkeficapsule utility. Sughosh Ganu (6): capsule: Add Image GUIDs for platforms using capsule updates capsule: FMP: Populate the image descriptor array from platform data test: capsule: Modify the capsule tests to use GUID values for sandbox doc: uefi: Update the capsule update related documentation FMP: Remove GUIDs for FIT and raw images mkeficapsule: Remove raw and FIT GUID types .../imx8mp_rsb3720a1/imx8mp_rsb3720a1.c | 19 ++ .../imx8mm-cl-iot-gate/imx8mm-cl-iot-gate.c | 18 ++ board/emulation/qemu-arm/qemu-arm.c | 20 ++ board/kontron/pitx_imx8m/pitx_imx8m.c | 15 +- board/kontron/sl-mx8mm/sl-mx8mm.c | 14 ++ board/kontron/sl28/sl28.c | 14 ++ board/sandbox/sandbox.c | 25 +++ board/socionext/developerbox/developerbox.c | 23 +++ board/xilinx/common/board.c | 18 ++ configs/sandbox64_defconfig | 1 - configs/sandbox_defconfig | 1 - configs/sandbox_flattree_defconfig| 5 + doc/develop/uefi/uefi.rst | 10 +- include/configs/imx8mm-cl-iot-gate.h | 10 + include/configs/imx8mp_rsb3720.h | 10 + include/configs/kontron-sl-mx8mm.h| 6 + include/configs/kontron_pitx_imx8m.h | 6 + include/configs/kontron_sl28.h| 6 + include/configs/qemu-arm.h
[PATCH v2 1/6] capsule: Add Image GUIDs for platforms using capsule updates
Currently, all platforms that enable capsule updates do so using either EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID or EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID. This is based on the Firmware Management Protocol(FMP) instance used on the platform. However, this means that all platforms that enable a particular FMP instance have the same GUID value for all the updatable images, either the FIT image GUID or the raw image GUID, and that an image for some platform can be updated on any other platform which uses the same FMP instance. Another issue with this implementation is that the ESRT table shows the same GUID value for all images on the platform and also across platforms, which is not in compliance with the UEFI specification. Fix this by defining image GUID values and firmware names for individual images per platform. The GetImageInfo FMP hook would then populate these values in the image descriptor array. Signed-off-by: Sughosh Ganu --- Changes since V1: * Make changes for the xilinx boards as suggested by Michal Simek. * Add a GUID for the sandbox FIT image .../imx8mp_rsb3720a1/imx8mp_rsb3720a1.c | 19 ++ .../imx8mm-cl-iot-gate/imx8mm-cl-iot-gate.c | 18 + board/emulation/qemu-arm/qemu-arm.c | 20 +++ board/kontron/pitx_imx8m/pitx_imx8m.c | 15 ++- board/kontron/sl-mx8mm/sl-mx8mm.c | 14 +++ board/kontron/sl28/sl28.c | 14 +++ board/sandbox/sandbox.c | 25 +++ board/socionext/developerbox/developerbox.c | 23 + board/xilinx/common/board.c | 18 + include/configs/imx8mm-cl-iot-gate.h | 10 include/configs/imx8mp_rsb3720.h | 10 include/configs/kontron-sl-mx8mm.h| 6 + include/configs/kontron_pitx_imx8m.h | 6 + include/configs/kontron_sl28.h| 6 + include/configs/qemu-arm.h| 10 include/configs/sandbox.h | 14 +++ include/configs/synquacer.h | 14 +++ include/configs/xilinx_versal.h | 10 include/configs/xilinx_zynqmp.h | 10 include/configs/zynq-common.h | 10 include/efi_loader.h | 15 +++ 21 files changed, 286 insertions(+), 1 deletion(-) diff --git a/board/advantech/imx8mp_rsb3720a1/imx8mp_rsb3720a1.c b/board/advantech/imx8mp_rsb3720a1/imx8mp_rsb3720a1.c index 16566092bd..6b534660fe 100644 --- a/board/advantech/imx8mp_rsb3720a1/imx8mp_rsb3720a1.c +++ b/board/advantech/imx8mp_rsb3720a1/imx8mp_rsb3720a1.c @@ -6,6 +6,8 @@ #include #include +#include +#include #include #include #include @@ -21,6 +23,7 @@ #include #include #include +#include #include DECLARE_GLOBAL_DATA_PTR; @@ -44,6 +47,22 @@ static void setup_gpmi_nand(void) } #endif +#if CONFIG_IS_ENABLED(EFI_HAVE_CAPSULE_SUPPORT) +struct efi_fw_images fw_images[] = { + { +#if defined(CONFIG_TARGET_IMX8MP_RSB3720A1_4G) + .image_type_id = IMX8MP_RSB3720A1_4G_FIT_IMAGE_GUID, +#elif defined(CONFIG_TARGET_IMX8MP_RSB3720A1_6G) + .image_type_id = IMX8MP_RSB3720A1_6G_FIT_IMAGE_GUID, +#endif + .fw_name = u"IMX8MP-RSB3720-FIT" + }, +}; + +u8 num_image_type_guids = ARRAY_SIZE(fw_images); +#endif /* EFI_HAVE_CAPSULE_SUPPORT */ + + int board_early_init_f(void) { struct wdog_regs *wdog = (struct wdog_regs *)WDOG1_BASE_ADDR; diff --git a/board/compulab/imx8mm-cl-iot-gate/imx8mm-cl-iot-gate.c b/board/compulab/imx8mm-cl-iot-gate/imx8mm-cl-iot-gate.c index 7e2d88f449..ec73d75db3 100644 --- a/board/compulab/imx8mm-cl-iot-gate/imx8mm-cl-iot-gate.c +++ b/board/compulab/imx8mm-cl-iot-gate/imx8mm-cl-iot-gate.c @@ -5,6 +5,8 @@ */ #include +#include +#include #include #include #include @@ -21,11 +23,27 @@ #include #include #include +#include #include "ddr/ddr.h" DECLARE_GLOBAL_DATA_PTR; +#if CONFIG_IS_ENABLED(EFI_HAVE_CAPSULE_SUPPORT) +struct efi_fw_images fw_images[] = { + { +#if defined(CONFIG_TARGET_IMX8MM_CL_IOT_GATE) + .image_type_id = IMX8MM_CL_IOT_GATE_FIT_IMAGE_GUID, +#elif defined(CONFIG_TARGET_IMX8MM_CL_IOT_GATE_OPTEE) + .image_type_id = IMX8MM_CL_IOT_GATE_OPTEE_FIT_IMAGE_GUID, +#endif + .fw_name = u"IMX8MM-CL-IOT-GATE-FIT", + }, +}; + +u8 num_image_type_guids = ARRAY_SIZE(fw_images); +#endif /* EFI_HAVE_CAPSULE_SUPPORT */ + int board_phys_sdram_size(phys_size_t *size) { struct lpddr4_tcm_desc *lpddr4_tcm_desc = diff --git a/board/emulation/qemu-arm/qemu-arm.c b/board/emulation/qemu-arm/qemu-arm.c index 16d5a97167..99872ce0b8 100644 --- a/board/emulation/qemu-arm/qemu-arm.c +++ b/board/emulation/qemu-arm/qemu-arm.c @@ -6,15 +6,35 @@ #include #include #include +#include +#include +#include #includ
[PATCH v2 2/6] capsule: FMP: Populate the image descriptor array from platform data
Currently, the image descriptor array that has been passed to the GetImageInfo function of the Firmware Management Protocol(FMP) gets populated through the data stored with the dfu framework. The dfu data is not restricted to contain information only of the images updatable through the capsule update mechanism, but it also contains information on other images. The image descriptor array is also parsed by the ESRT generation code, and thus the ESRT table contains entries for other images that are not being handled by the FMP for the capsule updates. The other issue fixed is assignment of a separate GUID for all images in the image descriptor array. The UEFI specification mandates that all entries in the ESRT table should have a unique GUID value as part of the FwClass member of the EFI_SYSTEM_RESOURCE_ENTRY. Currently, all images are assigned a single GUID value, either an FIT GUID or a raw image GUID. This is fixed by obtaining the GUID values from the efi_fw_images array defined per platform. Signed-off-by: Sughosh Ganu --- Changes since V1: None include/efi_loader.h | 3 ++ lib/efi_loader/efi_firmware.c | 91 +++ 2 files changed, 30 insertions(+), 64 deletions(-) diff --git a/include/efi_loader.h b/include/efi_loader.h index 1965b5a28f..e8f7234230 100644 --- a/include/efi_loader.h +++ b/include/efi_loader.h @@ -994,6 +994,9 @@ struct efi_fw_images { const u16 *fw_name; }; +extern struct efi_fw_images fw_images[]; +extern u8 num_image_type_guids; + /** * Install the ESRT system table. * diff --git a/lib/efi_loader/efi_firmware.c b/lib/efi_loader/efi_firmware.c index a5ff32f121..13cb492092 100644 --- a/lib/efi_loader/efi_firmware.c +++ b/lib/efi_loader/efi_firmware.c @@ -97,91 +97,60 @@ efi_status_t EFIAPI efi_firmware_set_package_info_unsupported( } /** - * efi_get_dfu_info - return information about the current firmware image + * efi_fill_image_desc_array - populate image descriptor array * @this: Protocol instance * @image_info_size: Size of @image_info * @image_info:Image information * @descriptor_version:Pointer to version number - * @descriptor_count: Pointer to number of descriptors + * @descriptor_count: Image count * @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 * * Return information bout the current firmware image in @image_info. * @image_info will consist of a number of descriptors. - * Each descriptor will be created based on "dfu_alt_info" variable. + * Each descriptor will be created based on "efi_fw_images" variable. * * Return status code */ -static efi_status_t efi_get_dfu_info( +static efi_status_t efi_fill_image_desc_array( efi_uintn_t *image_info_size, struct efi_firmware_image_descriptor *image_info, u32 *descriptor_version, u8 *descriptor_count, efi_uintn_t *descriptor_size, u32 *package_version, - u16 **package_version_name, - const efi_guid_t *image_type) + u16 **package_version_name) { - struct dfu_entity *dfu; size_t names_len, total_size; - int dfu_num, i; - u16 *name, *next; - int ret; - - ret = dfu_init_env_entities(NULL, NULL); - if (ret) - return EFI_SUCCESS; + struct efi_fw_images *fw_array; + u8 image_count; + int i; + fw_array = &fw_images[0]; + *descriptor_count = image_count = num_image_type_guids; names_len = 0; - dfu_num = 0; - list_for_each_entry(dfu, &dfu_list, list) { - names_len += (utf8_utf16_strlen(dfu->name) + 1) * 2; - dfu_num++; - } - if (!dfu_num) { - log_warning("No entities in dfu_alt_info\n"); - *image_info_size = 0; - dfu_free_entities(); - return EFI_SUCCESS; - } + total_size = sizeof(*image_info) * image_count; - total_size = sizeof(*image_info) * dfu_num + names_len; - /* -* we will assume that sizeof(*image_info) * dfu_name -* is, at least, a multiple of 2. So the start address for -* image_id_name would be aligned with 2 bytes. -*/ if (*image_info_size < total_size) { *image_info_size = total_size; - dfu_free_entities(); return EFI_BUFFER_TOO_SMALL; } *image_info_size = total_size; *descriptor_version = EFI_FIRMWARE_IMAGE_DESCRIPTOR_VERSION; - *descriptor_count = dfu_num; *descriptor_size = sizeof(*image_info); *package_version = 0x; /* not supported */ *p
[PATCH v2 4/6] doc: uefi: Update the capsule update related documentation
Update the capsule update functionality related documentation to refect the fact that a unique image GUID is to be used per image that forms part of the capsule file. Signed-off-by: Sughosh Ganu --- Changes since V1: None doc/develop/uefi/uefi.rst | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst index fe337c88bd..0d2825ce88 100644 --- a/doc/develop/uefi/uefi.rst +++ b/doc/develop/uefi/uefi.rst @@ -312,8 +312,8 @@ Run the following command .. code-block:: console $ mkeficapsule \ - --index 1 --instance 0 \ - [--fit | --raw ] \ + --index --instance 0 \ + --guid \ Performing the update @@ -333,6 +333,12 @@ won't be taken over across the reboot. If this is the case, you can skip this feature check with the Kconfig option (CONFIG_EFI_IGNORE_OSINDICATIONS) set. +Define GUID values of the images that are to be updated through the +capsule update feature in the platform file. The GUID values are to be +defined as part of the fw_images array. These GUID values would be +used by the Firmware Management Protocol(FMP) to populate the image +descriptor array and also displayed as part of the ESRT table. + Finally, the capsule update can be initiated by rebooting the board. Enabling Capsule Authentication -- 2.25.1
[PATCH v2 3/6] test: capsule: Modify the capsule tests to use GUID values for sandbox
The current UEFI capsule updation code uses two GUID values, one for FIT images, and one for raw images across platforms. This logic is being changed to have GUID values per image, per platform. Change the tests for the capsule update code to reflect this change. The GUID values now used are the ones specific to the sandbox platform -- one for the u-boot image, and another for the u-boot environment image. The UEFI specification does not allow installation of multiple Firmware Management Protocols(FMP) at the same time. Install the FMP instance for raw images on the sandbox variant for testing the capsule update code. Install the FMP instance for the FIT images on the sandbox64 and sandbox_flattree variant for testing capsule update for FIT images. This is being done by splitting the capsule update script for FIT and raw images. Signed-off-by: Sughosh Ganu --- Changes since V1: * 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 configs/sandbox64_defconfig | 1 - configs/sandbox_defconfig | 1 - configs/sandbox_flattree_defconfig| 5 + test/py/tests/test_efi_capsule/conftest.py| 21 +- .../test_capsule_firmware_fit.py | 186 ++ ...rmware.py => test_capsule_firmware_raw.py} | 169 ++-- 6 files changed, 264 insertions(+), 119 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} (76%) diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig index 7c157a23d0..1a0142795a 100644 --- a/configs/sandbox64_defconfig +++ b/configs/sandbox64_defconfig @@ -247,7 +247,6 @@ CONFIG_ERRNO_STR=y CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y CONFIG_EFI_CAPSULE_ON_DISK=y CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y -CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y CONFIG_EFI_SECURE_BOOT=y CONFIG_TEST_FDTDEC=y CONFIG_UNIT_TEST=y diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig index 7ebeb89264..0a601361b6 100644 --- a/configs/sandbox_defconfig +++ b/configs/sandbox_defconfig @@ -318,7 +318,6 @@ CONFIG_LZ4=y CONFIG_ERRNO_STR=y CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y CONFIG_EFI_CAPSULE_ON_DISK=y -CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y CONFIG_EFI_SECURE_BOOT=y CONFIG_TEST_FDTDEC=y diff --git a/configs/sandbox_flattree_defconfig b/configs/sandbox_flattree_defconfig index 217b0647bb..bbcf435ac6 100644 --- a/configs/sandbox_flattree_defconfig +++ b/configs/sandbox_flattree_defconfig @@ -29,6 +29,7 @@ CONFIG_CMD_BOOTEFI_HELLO=y CONFIG_CMD_ASKENV=y CONFIG_CMD_GREPENV=y CONFIG_CMD_ERASEENV=y +CONFIG_CMD_NVEDIT_EFI=y CONFIG_CMD_NVEDIT_INFO=y CONFIG_CMD_NVEDIT_LOAD=y CONFIG_CMD_NVEDIT_SELECT=y @@ -210,3 +211,7 @@ CONFIG_HEXDUMP=y CONFIG_UNIT_TEST=y CONFIG_UT_TIME=y CONFIG_UT_DM=y +CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y +CONFIG_EFI_CAPSULE_ON_DISK=y +CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y +CONFIG_DFU_SF=y diff --git a/test/py/tests/test_efi_capsule/conftest.py b/test/py/tests/test_efi_capsule/conftest.py index 9076087a12..d757415c88 100644 --- a/test/py/tests/test_efi_capsule/conftest.py +++ b/test/py/tests/test_efi_capsule/conftest.py @@ -72,7 +72,7 @@ def efi_capsule_data(request, u_boot_config): # Create capsule files # two regions: one for u-boot.bin and the other for u-boot.env -check_call('cd %s; echo -n u-boot:Old > u-boot.bin.old; echo -n u-boot:New > u-boot.bin.new; echo -n u-boot-env:Old -> u-boot.env.old; echo -n u-boot-env:New > u-boot.env.new' % data_dir, +check_call('cd %s; echo -n u-boot:Old > u-boot.bin.old; echo -n u-boot:New > u-boot.bin.new; echo -n u-boot-env:Old > u-boot.env.old; echo -n u-boot-env:New > u-boot.env.new' % data_dir, shell=True) check_call('sed -e \"s?BINFILE1?u-boot.bin.new?\" -e \"s?BINFILE2?u-boot.env.new?\" %s/test/py/tests/test_efi_capsule/uboot_bin_env.its > %s/uboot_bin_env.its' % (u_boot_config.source_dir, data_dir), @@ -80,21 +80,29 @@ def efi_capsule_data(request, u_boot_config): check_call('cd %s; %s/tools/mkimage -f uboot_bin_env.its uboot_bin_env.itb' % (data_dir, u_boot_config.build_dir), shell=True) -check_call('cd %s; %s/tools/mkeficapsule --index 1 --fit uboot_bin_env.itb Test01' % +check_call('cd %s; %s/tools/mkeficapsule --index 1 --guid 09D7CF52-0720-4710-91D1-08469B7FE9C8 u-boot.bin.new Test01' % (data_dir, u_boot_config.build_dir), shell=True) -check_call('cd %s; %s/tools/mkeficapsule --index 1 --raw u-boot.bin.new Test02' % +
[PATCH v2 5/6] FMP: Remove GUIDs for FIT and raw images
The capsule update code has been modified for getting the image GUID values from the platform code. With this, each image now has a unique GUID value. With this change, there is no longer a need for defining GUIDs for FIT and raw images. Remove these GUID values. Signed-off-by: Sughosh Ganu --- Changes since V1: None include/efi_api.h | 8 lib/efi_loader/efi_firmware.c | 4 2 files changed, 12 deletions(-) diff --git a/include/efi_api.h b/include/efi_api.h index 982c200172..c7f7873b5d 100644 --- a/include/efi_api.h +++ b/include/efi_api.h @@ -1967,14 +1967,6 @@ struct efi_signature_list { EFI_GUID(0x86c77a67, 0x0b97, 0x4633, 0xa1, 0x87, \ 0x49, 0x10, 0x4d, 0x06, 0x85, 0xc7) -#define EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID \ - EFI_GUID(0xae13ff2d, 0x9ad4, 0x4e25, 0x9a, 0xc8, \ -0x6d, 0x80, 0xb3, 0xb2, 0x21, 0x47) - -#define EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID \ - EFI_GUID(0xe2bb9c06, 0x70e9, 0x4b14, 0x97, 0xa3, \ -0x5a, 0x79, 0x13, 0x17, 0x6e, 0x3f) - #define IMAGE_ATTRIBUTE_IMAGE_UPDATABLE0x0001 #define IMAGE_ATTRIBUTE_RESET_REQUIRED 0x0002 #define IMAGE_ATTRIBUTE_AUTHENTICATION_REQUIRED0x0004 diff --git a/lib/efi_loader/efi_firmware.c b/lib/efi_loader/efi_firmware.c index 13cb492092..9fbedaf023 100644 --- a/lib/efi_loader/efi_firmware.c +++ b/lib/efi_loader/efi_firmware.c @@ -185,8 +185,6 @@ static efi_status_t efi_fill_image_desc_array( * - versioning of firmware image * - package information */ -const efi_guid_t efi_firmware_image_type_uboot_fit = - EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID; /** * efi_firmware_fit_get_image_info - return information about the current @@ -293,8 +291,6 @@ const struct efi_firmware_management_protocol efi_fmp_fit = { * This FIRMWARE_MANAGEMENT_PROTOCOL driver provides a firmware update * method with raw data. */ -const efi_guid_t efi_firmware_image_type_uboot_raw = - EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID; /** * efi_firmware_raw_get_image_info - return information about the current -- 2.25.1
[PATCH v2 6/6] mkeficapsule: Remove raw and FIT GUID types
While building a capsule, the GUID value of that specific image is to be passed through the --guid command option to the mkeficapsule tool. This renders the EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID and EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID values superfluous. Remove the --raw and --fit command line options as well. Signed-off-by: Sughosh Ganu --- Changes since V1: None tools/eficapsule.h | 8 tools/mkeficapsule.c | 26 +- 2 files changed, 1 insertion(+), 33 deletions(-) diff --git a/tools/eficapsule.h b/tools/eficapsule.h index 69c9c58c2f..d63b831443 100644 --- a/tools/eficapsule.h +++ b/tools/eficapsule.h @@ -37,14 +37,6 @@ typedef struct { EFI_GUID(0x6dcbd5ed, 0xe82d, 0x4c44, 0xbd, 0xa1, \ 0x71, 0x94, 0x19, 0x9a, 0xd9, 0x2a) -#define EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID \ - EFI_GUID(0xae13ff2d, 0x9ad4, 0x4e25, 0x9a, 0xc8, \ -0x6d, 0x80, 0xb3, 0xb2, 0x21, 0x47) - -#define EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID \ - EFI_GUID(0xe2bb9c06, 0x70e9, 0x4b14, 0x97, 0xa3, \ -0x5a, 0x79, 0x13, 0x17, 0x6e, 0x3f) - #define EFI_CERT_TYPE_PKCS7_GUID \ EFI_GUID(0x4aafd29d, 0x68df, 0x49ee, 0x8a, 0xa9, \ 0x34, 0x7d, 0x37, 0x56, 0x65, 0xa7) diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c index c118335b93..5f74d23b9e 100644 --- a/tools/mkeficapsule.c +++ b/tools/mkeficapsule.c @@ -27,17 +27,11 @@ static const char *tool_name = "mkeficapsule"; efi_guid_t efi_guid_fm_capsule = EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID; -efi_guid_t efi_guid_image_type_uboot_fit = - EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID; -efi_guid_t efi_guid_image_type_uboot_raw = - EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID; efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID; -static const char *opts_short = "frg:i:I:v:p:c:m:dh"; +static const char *opts_short = "g:i:I:v:p:c:m:dh"; static struct option options[] = { - {"fit", no_argument, NULL, 'f'}, - {"raw", no_argument, NULL, 'r'}, {"guid", required_argument, NULL, 'g'}, {"index", required_argument, NULL, 'i'}, {"instance", required_argument, NULL, 'I'}, @@ -54,8 +48,6 @@ static void print_usage(void) fprintf(stderr, "Usage: %s [options] \n" "Options:\n" - "\t-f, --fit FIT image type\n" - "\t-r, --raw raw image type\n" "\t-g, --guid guid for image blob type\n" "\t-i, --index update image index\n" "\t-I, --instanceupdate hardware instance\n" @@ -606,22 +598,6 @@ int main(int argc, char **argv) break; switch (c) { - case 'f': - if (guid) { - fprintf(stderr, - "Image type already specified\n"); - exit(EXIT_FAILURE); - } - guid = &efi_guid_image_type_uboot_fit; - break; - case 'r': - if (guid) { - fprintf(stderr, - "Image type already specified\n"); - exit(EXIT_FAILURE); - } - guid = &efi_guid_image_type_uboot_raw; - break; case 'g': if (guid) { fprintf(stderr, -- 2.25.1
Re: [PATCH v3 1/3] efi_loader: nocolor command line attr for initrddump.efi
On 3/25/22 15:58, Ilias Apalodimas wrote: Hi Heinrich, On Tue, 22 Mar 2022 at 22:58, Heinrich Schuchardt wrote: initrddump.efi uses colored output and clear the screen. This is not helpful for integration into Python tests. Allow specifying 'nocolor' in the load option data to suppress color output and clearing the screen. Signed-off-by: Heinrich Schuchardt --- v3: new patch --- lib/efi_loader/initrddump.c | 77 - 1 file changed, 68 insertions(+), 9 deletions(-) diff --git a/lib/efi_loader/initrddump.c b/lib/efi_loader/initrddump.c index 7de43bcfff..25dbd635e5 100644 --- a/lib/efi_loader/initrddump.c +++ b/lib/efi_loader/initrddump.c @@ -4,6 +4,9 @@ * * initrddump.efi saves the initial RAM disk provided via the * EFI_LOAD_FILE2_PROTOCOL. + * + * Specifying 'nocolor' as load option data suppresses colored output and + * clearing of the screen. */ #include @@ -25,6 +28,7 @@ static const efi_guid_t guid_simple_file_system_protocol = EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID; static const efi_guid_t load_file2_guid = EFI_LOAD_FILE2_PROTOCOL_GUID; static efi_handle_t handle; +static bool nocolor; /* * Device path defined by Linux to identify the handle providing the @@ -46,6 +50,17 @@ static const struct efi_initrd_dp initrd_dp = { } }; +/** + * color() - set foreground color + * + * @color: foreground color + */ +static void color(u8 color) +{ + if (!nocolor) + cout->set_attribute(cout, color | EFI_BACKGROUND_BLACK); +} + /** * print() - print string * @@ -56,6 +71,17 @@ static void print(u16 *string) cout->output_string(cout, string); } +/** + * cls() - clear screen + */ +static void cls(void) +{ + if (nocolor) + print(u"\r\n"); + else + cout->clear_screen(cout); +} + /** * error() - print error string * @@ -63,9 +89,9 @@ static void print(u16 *string) */ static void error(u16 *string) { - cout->set_attribute(cout, EFI_LIGHTRED | EFI_BACKGROUND_BLACK); + color(EFI_LIGHTRED); print(string); - cout->set_attribute(cout, EFI_LIGHTBLUE | EFI_BACKGROUND_BLACK); + color(EFI_LIGHTBLUE); } /* @@ -215,10 +241,13 @@ static u16 *skip_whitespace(u16 *pos) * * @string:string to search for keyword * @keyword: keyword to be searched - * Return: true fi @string starts with the keyword + * Return: true if @string starts with the keyword */ static bool starts_with(u16 *string, u16 *keyword) { + if (!string || !keyword) + return false; + for (; *keyword; ++string, ++keyword) { if (*string != *keyword) return false; @@ -400,6 +429,30 @@ out: return ret; } +/** + * get_load_options() - get load options + * + * Return: load options or NULL + */ +u16 *get_load_options(void) +{ + efi_status_t ret; + struct efi_loaded_image *loaded_image; + + ret = bs->open_protocol(handle, &loaded_image_guid, + (void **)&loaded_image, NULL, NULL, + EFI_OPEN_PROTOCOL_GET_PROTOCOL); + if (ret != EFI_SUCCESS) { + error(u"Loaded image protocol not found\r\n"); + return NULL; + } + + if (!loaded_image->load_options_size || !loaded_image->load_options) + return NULL; + + return loaded_image->load_options; +} + /** * efi_main() - entry point of the EFI application. * @@ -410,18 +463,23 @@ out: efi_status_t EFIAPI efi_main(efi_handle_t image_handle, struct efi_system_table *systab) { + u16 *load_options; + handle = image_handle; systable = systab; cerr = systable->std_err; cout = systable->con_out; cin = systable->con_in; bs = systable->boottime; + load_options = get_load_options(); Don't we need to check for NULL here? Thanks for reviewing. The check is in starts_with(). Best regards Heinrich - cout->set_attribute(cout, EFI_LIGHTBLUE | EFI_BACKGROUND_BLACK); - cout->clear_screen(cout); - cout->set_attribute(cout, EFI_WHITE | EFI_BACKGROUND_BLACK); + if (starts_with(load_options, u"nocolor")) + nocolor = true; + + color(EFI_WHITE); + cls(); print(u"INITRD Dump\r\n===\r\n\r\n"); - cout->set_attribute(cout, EFI_LIGHTBLUE | EFI_BACKGROUND_BLACK); + color(EFI_LIGHTBLUE); for (;;) { u16 command[BUFFER_SIZE]; @@ -443,7 +501,8 @@ efi_status_t EFIAPI efi_main(efi_handle_t image_handle, do_help(); } - cout->set_attribute(cout, EFI_LIGHTGRAY | EFI_BACKGROUND_BLACK); - cout->clear_screen(cout); + color(EFI_LIGHTGRAY); + cls(); + return EFI_SUCCESS; } -- 2.3
Re: [PATCH v3 3/3] test: test UEFI boot manager
On 3/23/22 07:32, AKASHI Takahiro wrote: On Tue, Mar 22, 2022 at 09:58:07PM +0100, Heinrich Schuchardt wrote: Provide a unit test for * efidebug boot add and other boot sub-commands as well? See below. Thanks for reviewing efidebug boot order - yes Properly testing the other sub-commands will require additional work. * efidebug bootmgr -> bootefi bootmgr yes Best regards Heinrich * initrd via EFI_LOAD_FILE2_PROTOCOL Signed-off-by: Heinrich Schuchardt --- v3: pass u"nocolor" as optional data to initrddump.efi v2: new patch --- test/py/tests/test_efi_bootmgr/conftest.py| 42 +++ .../test_efi_bootmgr/test_efi_bootmgr.py | 31 ++ 2 files changed, 73 insertions(+) create mode 100644 test/py/tests/test_efi_bootmgr/conftest.py create mode 100644 test/py/tests/test_efi_bootmgr/test_efi_bootmgr.py diff --git a/test/py/tests/test_efi_bootmgr/conftest.py b/test/py/tests/test_efi_bootmgr/conftest.py new file mode 100644 index 00..69008fddce --- /dev/null +++ b/test/py/tests/test_efi_bootmgr/conftest.py @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: GPL-2.0+ + +"""Fixture for UEFI bootmanager test +""" + +import os +import pytest +import shutil +from subprocess import call, check_call + +@pytest.fixture(scope='session') +def efi_bootmgr_data(u_boot_config): +"""Set up a file system to be used in UEFI bootmanager + tests + +Args: +u_boot_config: U-boot configuration. + +Return: +A path to disk image to be used for testing +""" +mnt_point = u_boot_config.persistent_data_dir + '/test_efi_bootmgr' +image_path = u_boot_config.persistent_data_dir + '/efi_bootmgr.img' + +shutil.rmtree(mnt_point, ignore_errors=True) +os.mkdir(mnt_point, mode = 0o755) + +with open(mnt_point + '/initrd-1.img', 'w', encoding = 'ascii') as file: +file.write("initrd 1") + +with open(mnt_point + '/initrd-2.img', 'w', encoding = 'ascii') as file: +file.write("initrd 2") + +shutil.copyfile(u_boot_config.build_dir + '/lib/efi_loader/initrddump.efi', +mnt_point + '/initrddump.efi') + +check_call('virt-make-fs --partition=gpt --size=+1M --type=vfat {} {}' + .format(mnt_point, image_path), shell=True) + +print(image_path) + +yield image_path diff --git a/test/py/tests/test_efi_bootmgr/test_efi_bootmgr.py b/test/py/tests/test_efi_bootmgr/test_efi_bootmgr.py new file mode 100644 index 00..feba306580 --- /dev/null +++ b/test/py/tests/test_efi_bootmgr/test_efi_bootmgr.py @@ -0,0 +1,31 @@ +# SPDX-License-Identifier: GPL-2.0+ + +import pytest + +@pytest.mark.boardspec('sandbox') +@pytest.mark.buildconfigspec('efi_loader') Obviously, this test depends on 'cmd_efidebug' and 'cmd_bootefi'. +def test_efi_bootmgr(u_boot_console, efi_bootmgr_data): +u_boot_console.run_command(cmd = 'host bind 0 {}'.format(efi_bootmgr_data)) + +u_boot_console.run_command(cmd = 'efidebug boot add ' \ +'-b 0001 label-1 host 0:1 initrddump.efi ' \ +'-i host 0:1 initrd-1.img -s nocolor') +u_boot_console.run_command(cmd = 'efidebug boot dump') Why do you call "boot dump" here? If you intend to test this sub-command, you should check the output. Or do you think it's enough to simply exercise the code for testing? +u_boot_console.run_command(cmd = 'efidebug boot order 0001') +u_boot_console.run_command(cmd = 'bootefi bootmgr') +response = u_boot_console.run_command(cmd = 'load', wait_for_echo=False) +assert 'crc32: 0x181464af' in response +u_boot_console.run_command(cmd = 'exit', wait_for_echo=False) + +u_boot_console.run_command(cmd = 'efidebug boot add ' \ +'-B 0002 label-2 host 0:1 initrddump.efi ' \ +'-I host 0:1 initrd-2.img -s nocolor') +u_boot_console.run_command(cmd = 'efidebug boot dump') +u_boot_console.run_command(cmd = 'efidebug boot order 0002') +u_boot_console.run_command(cmd = 'bootefi bootmgr') +response = u_boot_console.run_command(cmd = 'load', wait_for_echo=False) +assert 'crc32: 0x811d3515' in response +u_boot_console.run_command(cmd = 'exit', wait_for_echo=False) If you like, please add a test for "boot next" (or BootNext variable) as well. Thanks, -Takahiro Akashi + +u_boot_console.run_command(cmd = 'efidebug boot rm 0001') +u_boot_console.run_command(cmd = 'efidebug boot rm 0002') -- 2.34.1
Re: [PATCH v3 3/3] test: test UEFI boot manager
On 3/23/22 07:32, AKASHI Takahiro wrote: On Tue, Mar 22, 2022 at 09:58:07PM +0100, Heinrich Schuchardt wrote: Provide a unit test for * efidebug boot add and other boot sub-commands as well? See below. * efidebug bootmgr -> bootefi bootmgr ok * initrd via EFI_LOAD_FILE2_PROTOCOL Signed-off-by: Heinrich Schuchardt --- v3: pass u"nocolor" as optional data to initrddump.efi v2: new patch --- test/py/tests/test_efi_bootmgr/conftest.py| 42 +++ .../test_efi_bootmgr/test_efi_bootmgr.py | 31 ++ 2 files changed, 73 insertions(+) create mode 100644 test/py/tests/test_efi_bootmgr/conftest.py create mode 100644 test/py/tests/test_efi_bootmgr/test_efi_bootmgr.py diff --git a/test/py/tests/test_efi_bootmgr/conftest.py b/test/py/tests/test_efi_bootmgr/conftest.py new file mode 100644 index 00..69008fddce --- /dev/null +++ b/test/py/tests/test_efi_bootmgr/conftest.py @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: GPL-2.0+ + +"""Fixture for UEFI bootmanager test +""" + +import os +import pytest +import shutil +from subprocess import call, check_call + +@pytest.fixture(scope='session') +def efi_bootmgr_data(u_boot_config): +"""Set up a file system to be used in UEFI bootmanager + tests + +Args: +u_boot_config: U-boot configuration. + +Return: +A path to disk image to be used for testing +""" +mnt_point = u_boot_config.persistent_data_dir + '/test_efi_bootmgr' +image_path = u_boot_config.persistent_data_dir + '/efi_bootmgr.img' + +shutil.rmtree(mnt_point, ignore_errors=True) +os.mkdir(mnt_point, mode = 0o755) + +with open(mnt_point + '/initrd-1.img', 'w', encoding = 'ascii') as file: +file.write("initrd 1") + +with open(mnt_point + '/initrd-2.img', 'w', encoding = 'ascii') as file: +file.write("initrd 2") + +shutil.copyfile(u_boot_config.build_dir + '/lib/efi_loader/initrddump.efi', +mnt_point + '/initrddump.efi') + +check_call('virt-make-fs --partition=gpt --size=+1M --type=vfat {} {}' + .format(mnt_point, image_path), shell=True) + +print(image_path) + +yield image_path diff --git a/test/py/tests/test_efi_bootmgr/test_efi_bootmgr.py b/test/py/tests/test_efi_bootmgr/test_efi_bootmgr.py new file mode 100644 index 00..feba306580 --- /dev/null +++ b/test/py/tests/test_efi_bootmgr/test_efi_bootmgr.py @@ -0,0 +1,31 @@ +# SPDX-License-Identifier: GPL-2.0+ + +import pytest + +@pytest.mark.boardspec('sandbox') +@pytest.mark.buildconfigspec('efi_loader') Obviously, this test depends on 'cmd_efidebug' and 'cmd_bootefi'. yes these should be tested: @pytest.mark.buildconfigspec('cmd_efidebug') @pytest.mark.buildconfigspec('cmd_bootefi_bootmgr') +def test_efi_bootmgr(u_boot_console, efi_bootmgr_data): +u_boot_console.run_command(cmd = 'host bind 0 {}'.format(efi_bootmgr_data)) + +u_boot_console.run_command(cmd = 'efidebug boot add ' \ +'-b 0001 label-1 host 0:1 initrddump.efi ' \ +'-i host 0:1 initrd-1.img -s nocolor') +u_boot_console.run_command(cmd = 'efidebug boot dump') Why do you call "boot dump" here? If you intend to test this sub-command, you should check the output. Or do you think it's enough to simply exercise the code for testing? When the test breaks I want to see the output. +u_boot_console.run_command(cmd = 'efidebug boot order 0001') +u_boot_console.run_command(cmd = 'bootefi bootmgr') +response = u_boot_console.run_command(cmd = 'load', wait_for_echo=False) +assert 'crc32: 0x181464af' in response +u_boot_console.run_command(cmd = 'exit', wait_for_echo=False) + +u_boot_console.run_command(cmd = 'efidebug boot add ' \ +'-B 0002 label-2 host 0:1 initrddump.efi ' \ +'-I host 0:1 initrd-2.img -s nocolor') +u_boot_console.run_command(cmd = 'efidebug boot dump') +u_boot_console.run_command(cmd = 'efidebug boot order 0002') +u_boot_console.run_command(cmd = 'bootefi bootmgr') +response = u_boot_console.run_command(cmd = 'load', wait_for_echo=False) +assert 'crc32: 0x811d3515' in response +u_boot_console.run_command(cmd = 'exit', wait_for_echo=False) If you like, please add a test for "boot next" (or BootNext variable) as well. Thanks for reviewing. This is a patch is a starting point. We can and should expand what we are testing in a future patch. efidebug boot next is tested to some degree in test/py/tests/test_efi_secboot/test_signed.py Best regards Heinrich Thanks, -Takahiro Akashi + +u_boot_console.run_command(cmd = 'efidebug boot rm 0001') +u_boot_console.run_command(cmd = 'efidebug boot rm 0002') -- 2.34.1