Re: Pull request: please pull u-boot-imx-20230503
> Am 03.05.2023 um 23:25 schrieb Fabio Estevam :
>
> --- a/configs/imx8qm_dmsse20a1_defconfig
> +++ b/configs/imx8qm_dmsse20a1_defconfig
> @@ -16,6 +16,7 @@ CONFIG_SPL_SERIAL=y
> CONFIG_SPL_DRIVERS_MISC=y
> CONFIG_ENV_OFFSET=0x8
> CONFIG_ENV_SECT_SIZE=0x2
> +CONFIG_SPL_STACK=0x13e000
> CONFIG_SPL=y
> CONFIG_SYS_LOAD_ADDR=0x8028
> CONFIG_SYS_MEMTEST_START=0xA000
> @@ -38,11 +39,17 @@ CONFIG_USE_BOOTCOMMAND=y
> CONFIG_BOOTCOMMAND="mmc dev ${mmcdev}; if mmc rescan; then if run
> loadbootscript; then run bootscript; else if run loadimage; then run
> mmcboot; else run netboot; fi; fi; else booti ${loadaddr} -
> ${fdt_addr}; fi"
> CONFIG_LOG=y
> CONFIG_BOARD_EARLY_INIT_F=y
> -CONFIG_SPL_BSS_START_ADDR=0x00128000
> CONFIG_SPL_MAX_SIZE=0x1f000
> +CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
> +CONFIG_SPL_BSS_START_ADDR=0x128000
> CONFIG_SPL_BSS_MAX_SIZE=0x1000
> CONFIG_SPL_BOARD_INIT=y
> -CONFIG_SPL_SEPARATE_BSS=y
> +CONFIG_SPL_SYS_MALLOC_SIMPLE=y
> +# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
> +CONFIG_SYS_SPL_MALLOC=y
> +CONFIG_HAS_CUSTOM_SPL_MALLOC_START=y
> +CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x12
> +CONFIG_SYS_SPL_MALLOC_SIZE=0x3000
> CONFIG_SPL_POWER_SUPPORT=y
> CONFIG_SPL_POWER_DOMAIN=y
> CONFIG_SPL_WATCHDOG_SUPPORT=y
Hello Fabio,
just tested this change and its working fine on the dmsse20a1 board.
Tested-by: Oliver Graute
Best regards,
Oliver
Re: [PATCH v3 00/19] Migration to using binman for bootloader
On 04.05.23 08:13, Neha Malcom Francis wrote: > Hi Jan > > On 04/05/23 10:13, Neha Malcom Francis wrote: >> Hi Jan, >> >> On 03/05/23 22:04, Jan Kiszka wrote: >>> On 03.05.23 14:56, Neha Malcom Francis wrote: Hi Jan, On 03/05/23 12:57, Neha Malcom Francis wrote: > Hi Tom > > On 27/04/23 04:07, Tom Rini wrote: >> On Fri, Apr 21, 2023 at 06:01:44PM +0530, Neha Malcom Francis wrote: >> >>> This series aims to eliminate the use of additional custom >>> repositories >>> such as k3-image-gen (K3 Image Generation) repo and >>> core-secdev-k3 (K3 >>> Security Development Tools) that was plumbed into the U-Boot >>> build flow >>> to generate boot images for TI K3 platform devices. And instead, we >>> move >>> towards using binman that aligns better with the community standard >>> build >>> flow. >>> >>> This series uses binman for all K3 platforms supported on U-Boot >>> currently; >>> both HS (High Security, both SE and FS) and GP (General Purpose) >>> devices. >>> >>> Background on using k3-image-gen: >>> * TI K3 devices require a SYSFW (System Firmware) image >>> consisting >>> of a signed system firmware image and board configuration >>> binaries, >>> this is needed to bring up system firmware during U-Boot R5 SPL >>> startup. >>> * Board configuration data contain board-specific information >>> such as resource management, power management and security. >>> >>> Background on using core-secdev-k3: >>> * Contains resources to sign x509 certificates for HS devices >>> >>> Series intends to use binman to take over the packaging and >>> signing for >>> the R5 bootloader images tiboot3.bin (and sysfw.itb, for >>> non-combined >>> boot flow) instead of k3-image-gen. >>> >>> Series also packages the A72/A53 bootloader images (tispl.bin and >>> u-boot.img) using ATF, OPTEE and DM (Device Manager) >> >> So, next up is fixing this in CI. After taking Andrew's patch to >> fix the >> typedef issue, and after my patches to ensure we can get >> pyyaml/jsonschema for python, there's problems still: > > > Thanks for checking this! Couple things: > >> Over at https://source.denx.de/u-boot/u-boot/-/jobs/617966: >> binman: Filename 'spl/dts/k3-am68-sk-base-board.dtb' not found in >> input >> path (.,/builds/u-boot/u-boot,board/ti/j721s2,arch/arm/dts) >> (cwd='/tmp/.bm-work/j721s2_hs_evm_a72') > > 1. This is dependent on the patch merging J721S2 HS and GP configs > [1]. However it has been reverted on -next, seen in the same thread. > >> >> And then: >> https://source.denx.de/u-boot/u-boot/-/jobs/617965#L1328 >> Error: arch/arm/dts/k3-am62a-sk-binman.dtsi:167.1-8 syntax error >> I've fixed this, minor but serious change. > > 2. Regarding iot2050, build fails since it uses > arch/arm/mach-k3/config.mk which is now entirely binman based. Will > try moving iot2050 to binman as well. I'll need some help with this, might need to know the bootloader flow to make a clean migration. >>> >>> Where do I have to look at? Is there a git repo with that experiment >>> somewhere? >>> >>> Jan >>> >> >> There's no experiment yet, I will send one today; but I do not have >> complete understanding of the booting; whether the tispl.bin (which I >> assume is the only boot component that is affecting iot2050 boot since >> k3_fit_atf.sh is no longer there) has any concept of signing? Is >> core-secdev-k3 ever used? >> > > I have a tree posted here [2] that builds flash.bin with no error for > me. Please confirm whether your build flow does the same and also let me > know if the binary actually boots. > > [2] > https://github.com/nehamalcom/u-boot/tree/migration-to-binman-cicd-iot2050 > FWIW, dependencies, signing procedure etc. are all documented in u-boot/doc/board/siemens/iot2050.rst. I will try to have a look at that patch as well. Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH] usb: ehci-mx6: replace regulator_set_enable with *_if_allowed
On 5/4/23 00:52, Marek Vasut wrote:
On 5/2/23 18:13, Tim Harvey wrote:
On Mon, May 1, 2023 at 11:51 PM Eugen Hristev
wrote:
regulator_set_enable_if_allowed already handles cases when the
regulator is already enabled, or already disabled, and does not
treat these as errors.
With this change, the driver can work correctly even if the regulator
is already taken or already disabled by another consumer.
Signed-off-by: Eugen Hristev
---
Hi Tim,
I have not tested this as I do not have a mx6 board. can you please
try it ?
Thanks,
Eugen
Eugen,
This does resolve the issue that occurs after your refcount series [1].
However after thinking about this more and seeing Marek's responses
this wasn't an issue of multiple consumers sharing the same regulator.
Instead this particular issue was that the vbus regulator is getting
enabled twice without being disabled.
This kind of issues can be uncovered when we add the refcounter :)
On one hand I am happy to uncover such bugs.
However, this leads me to wonder, even without a refcount, even without
my series, enabling a regulator that is already enabled should return
-EALREADY
On the other hand, it appears it will take longer to get the refcount
applied though.
Adding a print in
regulator_set_enable shows me:
--- a/drivers/power/regulator/regulator-uclass.c
+++ b/drivers/power/regulator/regulator-uclass.c
@@ -165,6 +165,7 @@ int regulator_set_enable(struct udevice *dev, bool
enable)
struct dm_regulator_uclass_plat *uc_pdata;
int ret, old_enable = 0;
+printf("%s %s %s\n", __func__, dev->name, enable ? "enable" :
"disable");
if (!ops || !ops->set_enable)
return -ENOSYS;
u-boot=> usb start
starting USB...
Bus usb@32e4: regulator_set_enable regulator-usb-otg1 enable
^^^ from ehci_usb_probe
Bus usb@32e5: regulator_set_enable regulator-usb-otg2 enable
^^^ from ehci_usb_probe
regulator_set_enable regulator-usb-otg2 enable
^^^ from mx6_init_after_reset - 2nd enable without a disable
So while I think this patch does make sense to cover the case where a
regulator could be shared
Does such a case really still exist after the discovery you made above ?
there probably is a follow-on patch needed
to balance the regulator calls (unrelated to your series).
Marek,
Should vbus regulator enable really be in init_after_reset call?
Yes, but I am not entirely convinced the VBUS should be enabled in
ehci_usb_probe(), because in ehci_usb_probe() resp. in ehci_register()
which is called at the end, we might detect that the port is configured
as PERIPHERAL and we don't want to enable VBUS in that case .
So I suspect regulator_set_enable() should rather be dropped from
ehci_usb_probe() . What do you think ?
Re: [EXTERNAL] [PATCH v2 25/42] x86: Pass video settings from SPL to U-Boot proper
Hi Simon,
On 19/04/23 09:32, Simon Glass wrote:
When video is set up in SPL, U-Boot proper needs to use the correct
parameters so it can write to the display.
Put these in a bloblist so they are available to U-Boot proper.
Signed-off-by: Simon Glass
---
(no changes since v1)
drivers/pci/pci_rom.c | 78 +++
include/bloblist.h| 1 +
include/video.h | 24 +
3 files changed, 82 insertions(+), 21 deletions(-)
diff --git a/drivers/pci/pci_rom.c b/drivers/pci/pci_rom.c
index 2d9a2a899ef7..ecb6da64c5c9 100644
--- a/drivers/pci/pci_rom.c
+++ b/drivers/pci/pci_rom.c
@@ -26,6 +26,7 @@
#include
#include
+#include
#include
#include
#include
@@ -34,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -420,34 +422,68 @@ int vesa_setup_video(struct udevice *dev, int
(*int15_handler)(void))
printf("Not available (previous bootloader prevents it)\n");
return -EPERM;
}
- bootstage_start(BOOTSTAGE_ID_ACCUM_LCD, "vesa display");
- ret = dm_pci_run_vga_bios(dev, int15_handler, PCI_ROM_USE_NATIVE |
- PCI_ROM_ALLOW_FALLBACK);
- bootstage_accum(BOOTSTAGE_ID_ACCUM_LCD);
- if (ret) {
- debug("failed to run video BIOS: %d\n", ret);
- return ret;
- }
- ret = vesa_setup_video_priv(&mode_info.vesa,
- mode_info.vesa.phys_base_ptr, uc_priv,
- plat);
- if (ret) {
- if (ret == -ENFILE) {
- /*
-* See video-uclass.c for how to set up reserved memory
-* in your video driver
-*/
- log_err("CONFIG_VIDEO_COPY enabled but driver '%s' set up no
reserved memory\n",
- dev->driver->name);
+ /* In U-Boot proper, collect the information added by SPL (see below) */
+ if (IS_ENABLED(CONFIG_SPL_VIDEO) && spl_phase() > PHASE_SPL &&
+ CONFIG_IS_ENABLED(BLOBLIST)) {
+ struct video_handoff *ho;
+
+ ho = bloblist_find(BLOBLISTT_U_BOOT_VIDEO, sizeof(*ho));
+ if (!ho)
+ return log_msg_ret("blf", -ENOENT);
+ plat->base = ho->fb;
+ plat->size = ho->size;
+ uc_priv->xsize = ho->xsize;
+ uc_priv->ysize = ho->ysize;
+ uc_priv->line_length = ho->line_length;
+ uc_priv->bpix = ho->bpix;
+ } else {
+ bootstage_start(BOOTSTAGE_ID_ACCUM_LCD, "vesa display");
+ ret = dm_pci_run_vga_bios(dev, int15_handler,
+ PCI_ROM_USE_NATIVE |
+ PCI_ROM_ALLOW_FALLBACK);
+ bootstage_accum(BOOTSTAGE_ID_ACCUM_LCD);
+ if (ret) {
+ debug("failed to run video BIOS: %d\n", ret);
+ return ret;
}
- debug("No video mode configured\n");
- return ret;
+ ret = vesa_setup_video_priv(&mode_info.vesa,
+ mode_info.vesa.phys_base_ptr,
+ uc_priv, plat);
+ if (ret) {
+ if (ret == -ENFILE) {
+ /*
+* See video-uclass.c for how to set up reserved
+* memory in your video driver
+*/
+ log_err("CONFIG_VIDEO_COPY enabled but driver '%s'
set up no reserved memory\n",
+ dev->driver->name);
+ }
+
+ debug("No video mode configured\n");
+ return ret;
+ }
}
printf("Video: %dx%dx%d\n", uc_priv->xsize, uc_priv->ysize,
mode_info.vesa.bits_per_pixel);
+ /* In SPL, store the information for use by U-Boot proper */
+ if (spl_phase() == PHASE_SPL && CONFIG_IS_ENABLED(BLOBLIST)) {
+ struct video_handoff *ho;
+
+ ho = bloblist_add(BLOBLISTT_U_BOOT_VIDEO, sizeof(*ho), 0);
+ if (!ho)
+ return log_msg_ret("blc", -ENOMEM);
+
+ ho->fb = plat->base;
+ ho->size = plat->size;
+ ho->xsize = uc_priv->xsize;
+ ho->ysize = uc_priv->ysize;
+ ho->line_length = uc_priv->line_length;
+ ho->bpix = uc_priv->bpix;
+ }
+
return 0;
}
diff --git a/include/bloblist.h b/include/bloblist.h
index 2a2f1700eb09..7ea72c6bd46d 100644
--- a/include/bloblist.h
+++ b/include/bloblist.h
@@ -113,6 +113,7 @@ enum bloblist_tag_t {
BLOBLISTT_PROJECT_AREA = 0x8000,
Re: [PATCH v2 2/4] nvme: pci: Enable for SPL
Hi Simon,
On Wed, May 3, 2023 at 6:58 AM Simon Glass wrote:
>
> Hi Mayuresh,
>
> On Tue, 2 May 2023 at 10:19, Mayuresh Chitale
> wrote:
> >
> > Enable NVME and PCI NVMe drivers for SPL builds. Also enable PCI_PNP
> > for SPL which is required to auto configure the PCIe devices.
> >
> > Signed-off-by: Mayuresh Chitale
> > ---
> > drivers/Makefile | 1 +
> > drivers/nvme/Makefile| 2 +-
> > drivers/pci/Kconfig | 7 +++
> > drivers/pci/pci-uclass.c | 3 ++-
> > 4 files changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/Makefile b/drivers/Makefile
> > index 58be410135..dc559ea7f7 100644
> > --- a/drivers/Makefile
> > +++ b/drivers/Makefile
> > @@ -34,6 +34,7 @@ obj-$(CONFIG_$(SPL_)DM_MAILBOX) += mailbox/
> > obj-$(CONFIG_$(SPL_)REMOTEPROC) += remoteproc/
> > obj-$(CONFIG_$(SPL_)SYSINFO) += sysinfo/
> > obj-$(CONFIG_$(SPL_TPL_)TPM) += tpm/
> > +obj-$(CONFIG_$(SPL_)NVME) += nvme/
> > obj-$(CONFIG_XEN) += xen/
> > obj-$(CONFIG_$(SPL_)FPGA) += fpga/
> > obj-y += bus/
> > diff --git a/drivers/nvme/Makefile b/drivers/nvme/Makefile
> > index fa7b619446..fd3e68a91d 100644
> > --- a/drivers/nvme/Makefile
> > +++ b/drivers/nvme/Makefile
> > @@ -4,4 +4,4 @@
> >
> > obj-y += nvme-uclass.o nvme.o nvme_show.o
> > obj-$(CONFIG_NVME_APPLE) += nvme_apple.o
> > -obj-$(CONFIG_NVME_PCI) += nvme_pci.o
> > +obj-$(CONFIG_$(SPL_)NVME_PCI) += nvme_pci.o
> > diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> > index ef328d2652..ecab6ddc7e 100644
> > --- a/drivers/pci/Kconfig
> > +++ b/drivers/pci/Kconfig
> > @@ -40,6 +40,13 @@ config PCI_PNP
> > help
> > Enable PCI memory and I/O space resource allocation and
> > assignment.
> >
> > +config SPL_PCI_PNP
> > + bool "Enable Plug & Play support for PCI"
> > + default n
> > + help
> > + Enable PCI memory and I/O space resource allocation and
> > assignment.
> > + This is required to auto configure the enumerated devices.
> > +
> > config PCI_REGION_MULTI_ENTRY
> > bool "Enable Multiple entries of region type MEMORY in ranges for
> > PCI"
> > help
> > diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
> > index 9343cfc62a..dff63a68ce 100644
> > --- a/drivers/pci/pci-uclass.c
> > +++ b/drivers/pci/pci-uclass.c
> > @@ -1140,7 +1140,8 @@ static int pci_uclass_post_probe(struct udevice *bus)
> > if (ret)
> > return log_msg_ret("bind", ret);
> >
> > - if (CONFIG_IS_ENABLED(PCI_PNP) && ll_boot_init() &&
> > + if ((CONFIG_IS_ENABLED(PCI_PNP) || CONFIG_IS_ENABLED(SPL_PCI_PNP))
> > &&
>
> The CONFIG_IS_ENABLED() macro checks SPL_PCI_PNP when used in an SPL
> build, so you should not need this change.
Ok. Will remove it in the next version.
>
> > + ll_boot_init() &&
> > (!hose->skip_auto_config_until_reloc ||
> > (gd->flags & GD_FLG_RELOC))) {
> > ret = pci_auto_config_devices(bus);
> > --
> > 2.34.1
> >
>
> Regards,
> Simon
Thanks,
Mayuresh.
Re: [PATCH v2 4/4] common: spl: Add spl NVMe boot support
Hi Simon,
On Wed, May 3, 2023 at 6:58 AM Simon Glass wrote:
>
> Hi Mayuresh,
>
> On Tue, 2 May 2023 at 10:19, Mayuresh Chitale
> wrote:
> >
> > Add support to load the next stage image from an NVMe disk which may
> > be formatted as an EXT or FAT filesystem.
> >
> > Signed-off-by: Mayuresh Chitale
> > ---
> > arch/riscv/include/asm/spl.h | 1 +
> > common/spl/Kconfig | 10 +++
> > common/spl/Makefile | 1 +
> > common/spl/spl_nvme.c| 52
> > 4 files changed, 64 insertions(+)
> > create mode 100644 common/spl/spl_nvme.c
> >
> > diff --git a/arch/riscv/include/asm/spl.h b/arch/riscv/include/asm/spl.h
> > index 2898a770ee..9c0bf9755c 100644
> > --- a/arch/riscv/include/asm/spl.h
> > +++ b/arch/riscv/include/asm/spl.h
> > @@ -20,6 +20,7 @@ enum {
> > BOOT_DEVICE_SPI,
> > BOOT_DEVICE_USB,
> > BOOT_DEVICE_SATA,
> > + BOOT_DEVICE_NVME,
> > BOOT_DEVICE_I2C,
> > BOOT_DEVICE_BOARD,
> > BOOT_DEVICE_DFU,
> > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > index a42774c76d..021c4997a7 100644
> > --- a/common/spl/Kconfig
> > +++ b/common/spl/Kconfig
> > @@ -1283,6 +1283,16 @@ config SPL_NVME_BOOT_DEVICE
> > depends on SPL_NVME
> > default 0x0
> >
> > +config SYS_NVME_EXT_BOOT_PARTITION
> > + hex "NVMe ext boot partition number"
> > + depends on SPL_NVME
> > + default 0x2
> > +
> > +config SYS_NVME_FAT_BOOT_PARTITION
> > + hex "NVMe boot partition number"
> > + depends on SPL_NVME
> > + default 0x1
> > +
> > config SPL_SERIAL
> > bool "Support serial"
> > select SPL_PRINTF
> > diff --git a/common/spl/Makefile b/common/spl/Makefile
> > index 13db3df993..4bcc3d7e68 100644
> > --- a/common/spl/Makefile
> > +++ b/common/spl/Makefile
> > @@ -28,6 +28,7 @@ obj-$(CONFIG_$(SPL_TPL_)USB_STORAGE) += spl_usb.o
> > obj-$(CONFIG_$(SPL_TPL_)FS_FAT) += spl_fat.o
> > obj-$(CONFIG_$(SPL_TPL_)FS_EXT4) += spl_ext.o
> > obj-$(CONFIG_$(SPL_TPL_)SATA) += spl_sata.o
> > +obj-$(CONFIG_$(SPL_TPL_)NVME) += spl_nvme.o
> > obj-$(CONFIG_$(SPL_TPL_)SEMIHOSTING) += spl_semihosting.o
> > obj-$(CONFIG_$(SPL_TPL_)DFU) += spl_dfu.o
> > obj-$(CONFIG_$(SPL_TPL_)SPI_LOAD) += spl_spi.o
> > diff --git a/common/spl/spl_nvme.c b/common/spl/spl_nvme.c
> > new file mode 100644
> > index 00..c99e0aefc7
> > --- /dev/null
> > +++ b/common/spl/spl_nvme.c
> > @@ -0,0 +1,52 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2023
> > + * Ventana Micro Systems Inc.
> > + *
> > + * Derived work from spl_sata.c
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +static int spl_nvme_load_image(struct spl_image_info *spl_image,
> > + struct spl_boot_device *bootdev)
> > +{
> > + int ret;
> > + struct blk_desc *blk_desc;
> > +
> > + ret = pci_init();
> > + if (ret < 0)
> > + goto out;
> > +
> > + ret = nvme_scan_namespace();
> > + if (ret < 0)
> > + goto out;
> > +
> > + blk_show_device(UCLASS_NVME, CONFIG_SPL_NVME_BOOT_DEVICE);
> > + blk_desc = blk_get_devnum_by_uclass_id(UCLASS_NVME,
> > + CONFIG_SPL_NVME_BOOT_DEVICE);
> > + if (IS_ENABLED(CONFIG_SPL_FS_EXT4)) {
> > + ret = spl_load_image_ext(spl_image, bootdev, blk_desc,
> > +CONFIG_SYS_NVME_EXT_BOOT_PARTITION,
> > +CONFIG_SPL_PAYLOAD);
> > + if (!ret)
> > + return ret;
> > + }
> > +
> > + if (IS_ENABLED(CONFIG_SPL_FS_FAT))
> > + ret = spl_load_image_fat(spl_image, bootdev, blk_desc,
> > +CONFIG_SYS_NVME_FAT_BOOT_PARTITION,
> > +CONFIG_SPL_PAYLOAD);
> > + else
> > + ret = -ENOSYS;
> > +
> > +out:
> > + return ret;
> > +}
> > +
> > +SPL_LOAD_IMAGE_METHOD("NVME", 0, BOOT_DEVICE_NVME, spl_nvme_load_image);
> > --
> > 2.34.1
> >
>
> All of this code looks generic except:
>
> UCLASS_NVME
> CONFIG_SPL_NVME_BOOT_DEVICE
> CONFIG_SYS_NVME_EXT_BOOT_PARTITION
> so please move the code inside your new function into a generic file
> like spl_blk_fs.c or similar and pass these parameters to it. Then we
> can use the same function for other device types.
>
Ok. WIll do it in the next version.
> Regards,
> SImon
Thanks,
Mayuresh.
Re: [PATCH v3 00/19] Migration to using binman for bootloader
Hi > > This series aims to eliminate the use of additional custom repositories > such as k3-image-gen (K3 Image Generation) repo and core-secdev-k3 (K3 > Security Development Tools) that was plumbed into the U-Boot build flow > to generate boot images for TI K3 platform devices. And instead, we move > towards using binman that aligns better with the community standard build > flow. > > This series uses binman for all K3 platforms supported on U-Boot currently; > both HS (High Security, both SE and FS) and GP (General Purpose) devices. > > Background on using k3-image-gen: > * TI K3 devices require a SYSFW (System Firmware) image consisting > of a signed system firmware image and board configuration binaries, > this is needed to bring up system firmware during U-Boot R5 SPL > startup. > * Board configuration data contain board-specific information > such as resource management, power management and security. > > Background on using core-secdev-k3: > * Contains resources to sign x509 certificates for HS devices > > Series intends to use binman to take over the packaging and signing for > the R5 bootloader images tiboot3.bin (and sysfw.itb, for non-combined > boot flow) instead of k3-image-gen. > > Series also packages the A72/A53 bootloader images (tispl.bin and > u-boot.img) using ATF, OPTEE and DM (Device Manager) This simplifies building U-Boot with sysfw alot - thanks for your work! I have tested this series on an am642 based design. One thing is missing for my HSM use case. I want to build an unsigned Image and need to sign it with binman in the context of the HSM. Therefore we need repacking support. Are you working on that too? -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info/privacypolicy
[PATCH 02/10] board: cssi: Remove stale macro from cmpcpro.c
Three unused macros were left over. Remove them. Signed-off-by: Christophe Leroy --- board/cssi/cmpcpro/cmpcpro.c | 5 - 1 file changed, 5 deletions(-) diff --git a/board/cssi/cmpcpro/cmpcpro.c b/board/cssi/cmpcpro/cmpcpro.c index 3e9ba6a4cc..8a30c48e35 100644 --- a/board/cssi/cmpcpro/cmpcpro.c +++ b/board/cssi/cmpcpro/cmpcpro.c @@ -397,8 +397,3 @@ void ft_board_setup_phy3(void) setbits_be32(&immr->qepio.ioport[2].pdat, 0x0400); } - -#define ADDR_FPGA_R_BASE ((unsigned char __iomem *)CONFIG_FPGA_BASE) -#define ADDR_FPGA_R_ALARMES_IN ((unsigned char __iomem *)CONFIG_FPGA_BASE + 0x31) -#define ADDR_FPGA_R_FAV((unsigned char __iomem *)CONFIG_FPGA_BASE + 0x44) - -- 2.39.2
[PATCH 01/10] board: cssi: Remove duplicated FPGA loading sequence on CMPC885
A duplicated FPGA loading sequence appears after FPGA reset.
Remove it.
Fixes: dac3c6f625 ("board: cssi: Add new board MCR3000_2G")
Signed-off-by: Christophe Leroy
---
board/cssi/cmpc885/cmpc885.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/board/cssi/cmpc885/cmpc885.c b/board/cssi/cmpc885/cmpc885.c
index 540b9d3c78..02da4d9a87 100644
--- a/board/cssi/cmpc885/cmpc885.c
+++ b/board/cssi/cmpc885/cmpc885.c
@@ -896,20 +896,6 @@ int board_early_init_r(void)
}
}
- /* is FPGA firmware loaded ? */
- if (!(in_be32(&cp->cp_pedat) & 0x0001)) {
- printf("Reloading FPGA firmware\n");
-
- /* Load FPGA firmware */
- /* Activate PROG_FPGA_FIRMWARE for 1 usec */
- clrbits_be32(&cp->cp_pedat, 0x0002);
- udelay(1);
- setbits_be32(&cp->cp_pedat, 0x0002);
-
- /* Wait 200ms before checking DONE_FPGA_FIRMWARE */
- mdelay(200);
- }
-
iop_setup_common();
} else {
iop_setup_cmpc885();
--
2.39.2
[PATCH 00/10] Misc fixes + 8xx CPM relocation
This series adds misc fixes for cssi boards and activates CPM relocation in order to enable the use of SCC4 in QMC (QUICC Multi-Channel) mode. Christophe Leroy (10): board: cssi: Remove duplicated FPGA loading sequence on CMPC885 board: cssi: Remove stale macro from cmpcpro.c board: cssi: Load CMPC885's motherboard FPGA earlier powerpc: mpc8xx: CPM parameter RAM can be anywhere powerpc: mpc8xx: Reorganise init RAM powerpc: mpc885: Add CPM USB-SOF microcode for CPM15 ERRATA powerpc: mpc8xx: Add SMC relocation CPM microcode spi, mpc8xx: Take parameter RAM relocation into account serial, mpc8xx: Take parameter RAM relocation into account board: cssi: Activate SMC relocation on CMPC885 board for MIAE device arch/powerpc/cpu/mpc8xx/Kconfig | 45 arch/powerpc/cpu/mpc8xx/Makefile | 2 + arch/powerpc/cpu/mpc8xx/cpu.c| 2 +- arch/powerpc/cpu/mpc8xx/micropatch_smc.c | 105 +++ arch/powerpc/cpu/mpc8xx/micropatch_usb_sof.c | 38 +++ arch/powerpc/cpu/mpc8xx/start.S | 9 +- arch/powerpc/include/asm/cpm_8xx.h | 41 +--- arch/powerpc/include/asm/immap_8xx.h | 8 +- board/cssi/cmpc885/cmpc885.c | 43 ++-- board/cssi/cmpcpro/cmpcpro.c | 5 - configs/CMPC885_defconfig| 3 +- drivers/serial/serial_mpc8xx.c | 24 ++--- drivers/spi/mpc8xx_spi.c | 8 +- include/configs/cmpc885.h| 1 + include/configs/mcr3000.h| 1 + 15 files changed, 251 insertions(+), 84 deletions(-) create mode 100644 arch/powerpc/cpu/mpc8xx/micropatch_smc.c create mode 100644 arch/powerpc/cpu/mpc8xx/micropatch_usb_sof.c -- 2.39.2
[PATCH 10/10] board: cssi: Activate SMC relocation on CMPC885 board for MIAE device
When CMPC885 board is used for MIAE device, SCC2 SCC3 and SMC2 are used for serial lines. Therefore only SCC4 is available for handling the TDM line. In order to use SCC4 in QMC mode without loosing SMC2, SMC2 must be relocated. Activate SMC relocation and relocate SMC2 at offset 0x1fc0 which is unused. Signed-off-by: Christophe Leroy --- board/cssi/cmpc885/cmpc885.c | 4 configs/CMPC885_defconfig| 2 ++ 2 files changed, 6 insertions(+) diff --git a/board/cssi/cmpc885/cmpc885.c b/board/cssi/cmpc885/cmpc885.c index 40128f170a..5e6aa8b8cf 100644 --- a/board/cssi/cmpc885/cmpc885.c +++ b/board/cssi/cmpc885/cmpc885.c @@ -11,6 +11,7 @@ #include #include #include +#include #include #include #include @@ -451,6 +452,9 @@ void iop_setup_miae(void) /* Wait reset on FPGA_F */ udelay(100); + /* Load CPM relocation code */ + cpm_load_patch(cp); + /* Set the front panel LED color to red */ clrbits_8((unsigned char __iomem *)CONFIG_FPGA_BASE + 0x44, 0x02); diff --git a/configs/CMPC885_defconfig b/configs/CMPC885_defconfig index c1031b7e3a..8e64c7b278 100644 --- a/configs/CMPC885_defconfig +++ b/configs/CMPC885_defconfig @@ -9,6 +9,8 @@ CONFIG_ENV_ADDR=0x40004000 CONFIG_MPC8xx=y CONFIG_TARGET_CMPC885=y CONFIG_MPC885=y +CONFIG_SMC_UCODE_PATCH=y +CONFIG_SMC2_RPBASE=0x1fc0 CONFIG_CMD_IMMAP=y CONFIG_SYS_SIUMCR=0x0062 CONFIG_SYS_TBSCR=0x00C3 -- 2.39.2
[PATCH 03/10] board: cssi: Load CMPC885's motherboard FPGA earlier
In order to know the motherboard type earlier, perform I/O ports
initialisation and FPGA loading in board_early_init_f() instead
of board_early_init_r().
This is needed to be able to load mpc8xx CPM microcode base on
motherboard type and before starting to use the CPM.
Console is not available yet so remove the printfs.
Signed-off-by: Christophe Leroy
---
board/cssi/cmpc885/cmpc885.c | 25 +
configs/CMPC885_defconfig| 1 -
2 files changed, 5 insertions(+), 21 deletions(-)
diff --git a/board/cssi/cmpc885/cmpc885.c b/board/cssi/cmpc885/cmpc885.c
index 02da4d9a87..40128f170a 100644
--- a/board/cssi/cmpc885/cmpc885.c
+++ b/board/cssi/cmpc885/cmpc885.c
@@ -586,13 +586,8 @@ void iop_setup_miae(void)
setbits_be32(&cp->cp_peso, 0x00031980);
}
-int board_early_init_f(void)
-{
- return 0;
-}
-
/* Specific board initialization */
-int board_early_init_r(void)
+int board_early_init_f(void)
{
immap_t __iomem *immr = (immap_t __iomem *)CONFIG_SYS_IMMR;
iop8xx_t __iomem *iop = &immr->im_ioport;
@@ -864,8 +859,6 @@ int board_early_init_r(void)
/* Check if fpga firmware is loaded */
if (!(in_be32(&cp->cp_pedat) & 0x0001)) {
- printf("Reloading FPGA firmware.\n");
-
/* Load fpga firmware */
/* Activate PROG_FPGA_FIRMWARE for 1 usec */
clrbits_be32(&cp->cp_pedat, 0x0002);
@@ -874,12 +867,8 @@ int board_early_init_r(void)
/* Wait 200 msec and check DONE_FPGA_FIRMWARE */
mdelay(200);
- if (!(in_be32(&cp->cp_pedat) & 0x0001)) {
- for (;;) {
- printf("error loading firmware.\n");
- mdelay(500);
- }
- }
+ if (!(in_be32(&cp->cp_pedat) & 0x0001))
+ hang();
/* Send a reset signal and wait for 20 msec */
clrbits_be16(ADDR_CPLD_R_RESET, R_RST_STATUS);
@@ -889,12 +878,8 @@ int board_early_init_r(void)
/* Wait 300 msec and check the reset state */
mdelay(300);
- if (!(in_be16(ADDR_CPLD_R_RESET) & R_RESET_STATUS)) {
- for (;;) {
- printf("Could not reset FPGA.\n");
- mdelay(500);
- }
- }
+ if (!(in_be16(ADDR_CPLD_R_RESET) & R_RESET_STATUS))
+ hang();
iop_setup_common();
} else {
diff --git a/configs/CMPC885_defconfig b/configs/CMPC885_defconfig
index b1df954bee..c1031b7e3a 100644
--- a/configs/CMPC885_defconfig
+++ b/configs/CMPC885_defconfig
@@ -30,7 +30,6 @@ CONFIG_AUTOBOOT_STOP_STR_ENABLE=y
CONFIG_AUTOBOOT_STOP_STR_SHA256="4813494d137e1631bba301d5acab6e7bb7aa74ce1185d456565ef51d737677b2"
CONFIG_USE_BOOTCOMMAND=y
CONFIG_BOOTCOMMAND="run flashboot"
-CONFIG_BOARD_EARLY_INIT_R=y
CONFIG_MISC_INIT_R=y
CONFIG_HUSH_PARSER=y
# CONFIG_CMD_BDI is not set
--
2.39.2
[PATCH 06/10] powerpc: mpc885: Add CPM USB-SOF microcode for CPM15 ERRATA
MPC885 CPU has the following ERRATA:
When the USB controller is configured in Host mode, and the
SOF generation (SFTE=1 in USMOD register) is being used,
there may be false CRC error indication in other SCCs.
Although the data is received correctly, the CRC result
will be corrupted.
Add capability to load the related microcode to fix it.
The microcode binary data is copied from Linux kernel.
Other microcode will be added in following patch so make it
a Kconfig choice.
Signed-off-by: Christophe Leroy
---
arch/powerpc/cpu/mpc8xx/Kconfig | 25 +
arch/powerpc/cpu/mpc8xx/Makefile | 1 +
arch/powerpc/cpu/mpc8xx/micropatch_usb_sof.c | 38
arch/powerpc/include/asm/cpm_8xx.h | 7
4 files changed, 71 insertions(+)
create mode 100644 arch/powerpc/cpu/mpc8xx/micropatch_usb_sof.c
diff --git a/arch/powerpc/cpu/mpc8xx/Kconfig b/arch/powerpc/cpu/mpc8xx/Kconfig
index bfd903bc10..52caf06aac 100644
--- a/arch/powerpc/cpu/mpc8xx/Kconfig
+++ b/arch/powerpc/cpu/mpc8xx/Kconfig
@@ -30,6 +30,31 @@ config MPC885
endchoice
+choice
+ prompt "Microcode patch selection"
+ default NO_UCODE_PATCH
+ help
+ This allows loading of CPM microcode.
+
+ Only one microcode can be loaded at a time.
+
+config NO_UCODE_PATCH
+ bool "None"
+
+config USB_SOF_UCODE_PATCH
+ bool "USB SOF patch"
+ depends on MPC885
+ help
+ This microcode fixes CPM15 errata:
+
+ When the USB controller is configured in Host mode, and the
+ SOF generation (SFTE=1 in USMOD register) is being used,
+ there may be false CRC error indication in other SCCs.
+ Although the data is received correctly, the CRC result
+ will be corrupted.
+
+endchoice
+
comment "Specific commands"
config CMD_IMMAP
diff --git a/arch/powerpc/cpu/mpc8xx/Makefile b/arch/powerpc/cpu/mpc8xx/Makefile
index 8918a26288..5a6561e024 100644
--- a/arch/powerpc/cpu/mpc8xx/Makefile
+++ b/arch/powerpc/cpu/mpc8xx/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_CMD_IMMAP) += immap.o
obj-y += interrupts.o
obj-y += speed.o
obj-y += cache.o
+obj-$(CONFIG_USB_SOF_UCODE_PATCH) += micropatch_usb_sof.o
diff --git a/arch/powerpc/cpu/mpc8xx/micropatch_usb_sof.c
b/arch/powerpc/cpu/mpc8xx/micropatch_usb_sof.c
new file mode 100644
index 00..e99cd492ca
--- /dev/null
+++ b/arch/powerpc/cpu/mpc8xx/micropatch_usb_sof.c
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Microcode patches for the CPM as supplied by Motorola.
+ */
+
+#include
+#include
+#include
+#include
+
+/*
+ * USB SOF patch arrays.
+ */
+static uint patch_2000[] = {
+ 0x7fff, 0x7ffd, 0x7ffb, 0x49f7ba5b,
+ 0xba383ffb, 0xf9b8b46d, 0xe5ab4e07, 0xaf77bffe,
+ 0x3f7bbf79, 0xba5bba38, 0xe7676076, 0x6075
+};
+
+static uint patch_2f00[] = {
+ 0x3030304c, 0xcab9e441, 0xa1aaf220
+};
+
+void cpm_load_patch(cpm8xx_t *cp)
+{
+ out_be16(&cp->cp_rccr, 0);
+
+ memcpy_toio(cp->cp_dpmem, patch_2000, sizeof(patch_2000));
+ memcpy_toio(cp->cp_dpmem + 0xf00, patch_2f00, sizeof(patch_2f00));
+
+ out_be16(&cp->cp_cpmcr1, 0);
+ out_be16(&cp->cp_cpmcr2, 0);
+ out_be16(&cp->cp_cpmcr3, 0);
+ out_be16(&cp->cp_cpmcr4, 0);
+
+ out_be16(&cp->cp_rccr, 9);
+}
diff --git a/arch/powerpc/include/asm/cpm_8xx.h
b/arch/powerpc/include/asm/cpm_8xx.h
index 77ffcce5a6..41c79ca7b1 100644
--- a/arch/powerpc/include/asm/cpm_8xx.h
+++ b/arch/powerpc/include/asm/cpm_8xx.h
@@ -684,4 +684,11 @@ void irq_install_handler(int vec, void (*handler)(void *),
void *dev_id);
#define CICR_HP_MASK ((uint)0x1f00) /* Hi-pri int. */
#define CICR_IEN ((uint)0x0080) /* Int. enable */
#define CICR_SPS ((uint)0x0001) /* SCC Spread */
+
+#ifdef CONFIG_NO_UCODE_PATCH
+static inline void cpm_load_patch(cpm8xx_t *cp) { }
+#else
+void cpm_load_patch(cpm8xx_t *cp);
+#endif
+
#endif /* __CPM_8XX__ */
--
2.39.2
[PATCH 04/10] powerpc: mpc8xx: CPM parameter RAM can be anywhere
With relocation, CPM parameter RAM can be anywhere in the
dual port RAM, so don't split dual port RAM.
Remove dparam and dparam16 members of struct comm_proc
PROFF_XXX become offsets from the start of dual port RAM,
then they are now consistant with the offsets in RPBASE
registers.
Signed-off-by: Christophe Leroy
---
arch/powerpc/cpu/mpc8xx/cpu.c| 2 +-
arch/powerpc/include/asm/cpm_8xx.h | 18 +-
arch/powerpc/include/asm/immap_8xx.h | 8 +---
drivers/serial/serial_mpc8xx.c | 2 +-
drivers/spi/mpc8xx_spi.c | 2 +-
5 files changed, 13 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xx/cpu.c b/arch/powerpc/cpu/mpc8xx/cpu.c
index 9b587fbbe8..56383cecde 100644
--- a/arch/powerpc/cpu/mpc8xx/cpu.c
+++ b/arch/powerpc/cpu/mpc8xx/cpu.c
@@ -127,7 +127,7 @@ static int check_CPU(long clock, uint pvr, uint immr)
return -1;
k = (immr << 16) |
- in_be16(&immap->im_cpm.cp_dparam16[PROFF_REVNUM / sizeof(u16)]);
+ in_be16((u16 __iomem *)&immap->im_cpm.cp_dpmem[PROFF_REVNUM]);
/*
* Some boards use sockets so different CPUs can be used.
diff --git a/arch/powerpc/include/asm/cpm_8xx.h
b/arch/powerpc/include/asm/cpm_8xx.h
index 85903d2108..09c24efd91 100644
--- a/arch/powerpc/include/asm/cpm_8xx.h
+++ b/arch/powerpc/include/asm/cpm_8xx.h
@@ -92,15 +92,15 @@ typedef struct cpm_buf_desc {
/* Parameter RAM offsets.
*/
-#define PROFF_SCC1 ((uint)0x)
-#define PROFF_IIC ((uint)0x0080)
-#define PROFF_REVNUM ((uint)0x00b0)
-#define PROFF_SCC2 ((uint)0x0100)
-#define PROFF_SPI ((uint)0x0180)
-#define PROFF_SCC3 ((uint)0x0200)
-#define PROFF_SMC1 ((uint)0x0280)
-#define PROFF_SCC4 ((uint)0x0300)
-#define PROFF_SMC2 ((uint)0x0380)
+#define PROFF_SCC1 ((uint)0x1c00)
+#define PROFF_IIC ((uint)0x1c80)
+#define PROFF_REVNUM ((uint)0x1cb0)
+#define PROFF_SCC2 ((uint)0x1d00)
+#define PROFF_SPI ((uint)0x1d80)
+#define PROFF_SCC3 ((uint)0x1e00)
+#define PROFF_SMC1 ((uint)0x1e80)
+#define PROFF_SCC4 ((uint)0x1f00)
+#define PROFF_SMC2 ((uint)0x1f80)
/* Define enough so I can at least use the serial port as a UART.
*/
diff --git a/arch/powerpc/include/asm/immap_8xx.h
b/arch/powerpc/include/asm/immap_8xx.h
index 3999a02b9c..cf1300f6e2 100644
--- a/arch/powerpc/include/asm/immap_8xx.h
+++ b/arch/powerpc/include/asm/immap_8xx.h
@@ -437,13 +437,7 @@ typedef struct comm_proc {
* depending upon the devices used and options chosen.
* Some processors don't have all of it populated.
*/
- u_char cp_dpmem[0x1C00]; /* BD / Data / ucode */
-
- /* Parameter RAM */
- union {
- u_char cp_dparam[0x400];
- u16 cp_dparam16[0x200];
- };
+ u_char cp_dpmem[0x2000]; /* BD / Data / ucode / Param RAM */
} cpm8xx_t;
/* Internal memory map.
diff --git a/drivers/serial/serial_mpc8xx.c b/drivers/serial/serial_mpc8xx.c
index b8d6a81b65..beffc34d11 100644
--- a/drivers/serial/serial_mpc8xx.c
+++ b/drivers/serial/serial_mpc8xx.c
@@ -89,7 +89,7 @@ static int serial_mpc8xx_probe(struct udevice *dev)
/* initialize pointers to SMC */
sp = cp->cp_smc + SMC_INDEX;
- up = (smc_uart_t __iomem *)&cp->cp_dparam[PROFF_SMC];
+ up = (smc_uart_t __iomem *)&cp->cp_dpmem[PROFF_SMC];
/* Disable relocation */
out_be16(&up->smc_rpbase, 0);
diff --git a/drivers/spi/mpc8xx_spi.c b/drivers/spi/mpc8xx_spi.c
index d84d7aea88..734b0751a9 100644
--- a/drivers/spi/mpc8xx_spi.c
+++ b/drivers/spi/mpc8xx_spi.c
@@ -51,7 +51,7 @@ static int mpc8xx_spi_probe(struct udevice *dev)
{
immap_t __iomem *immr = (immap_t __iomem *)CONFIG_SYS_IMMR;
cpm8xx_t __iomem *cp = &immr->im_cpm;
- spi_t __iomem *spi = (spi_t __iomem *)&cp->cp_dparam[PROFF_SPI];
+ spi_t __iomem *spi = (spi_t __iomem *)&cp->cp_dpmem[PROFF_SPI];
cbd_t __iomem *tbdf, *rbdf;
/* Disable relocation */
--
2.39.2
[PATCH 07/10] powerpc: mpc8xx: Add SMC relocation CPM microcode
In order to use QMC mode in the CPM, a SCC requires more space
in parameter RAM.
After SCC1 there is I2C parameter RAM and after SCC2 there is
SPI parameter RAM. MPC866 and MPC885 can already relocate I2C and.
SPI parameter RAM.
But in order to free space after SCC3 and SCC4, SMC1 and SMC2
need to be relocated. In order to do so, a CPM microcode patch
is required.
Binary data for that patch is copied from Linux kernel.
Signed-off-by: Christophe Leroy
---
arch/powerpc/cpu/mpc8xx/Kconfig | 20 +
arch/powerpc/cpu/mpc8xx/Makefile | 1 +
arch/powerpc/cpu/mpc8xx/micropatch_smc.c | 105 +++
3 files changed, 126 insertions(+)
create mode 100644 arch/powerpc/cpu/mpc8xx/micropatch_smc.c
diff --git a/arch/powerpc/cpu/mpc8xx/Kconfig b/arch/powerpc/cpu/mpc8xx/Kconfig
index 52caf06aac..bd2af8dc10 100644
--- a/arch/powerpc/cpu/mpc8xx/Kconfig
+++ b/arch/powerpc/cpu/mpc8xx/Kconfig
@@ -53,6 +53,26 @@ config USB_SOF_UCODE_PATCH
Although the data is received correctly, the CRC result
will be corrupted.
+config SMC_UCODE_PATCH
+ bool "SMC relocation patch"
+ help
+ This microcode relocates SMC1 and SMC2 parameter RAMs to allow
+ extended parameter RAM for SCC3 and SCC4 (ex: for QMC mode)
+
+config SMC1_RPBASE
+ hex "SMC1 relocation offset"
+ depends on SMC_UCODE_PATCH
+ default 0x1e80
+ help
+ Offset of SMC1 parameter RAM to be written to RPBASE register.
+
+config SMC2_RPBASE
+ hex "SMC2 relocation offset"
+ depends on SMC_UCODE_PATCH
+ default 0x1f80
+ help
+ Offset of SMC2 parameter RAM to be written to RPBASE register.
+
endchoice
comment "Specific commands"
diff --git a/arch/powerpc/cpu/mpc8xx/Makefile b/arch/powerpc/cpu/mpc8xx/Makefile
index 5a6561e024..28a21eeb76 100644
--- a/arch/powerpc/cpu/mpc8xx/Makefile
+++ b/arch/powerpc/cpu/mpc8xx/Makefile
@@ -13,3 +13,4 @@ obj-y += interrupts.o
obj-y += speed.o
obj-y += cache.o
obj-$(CONFIG_USB_SOF_UCODE_PATCH) += micropatch_usb_sof.o
+obj-$(CONFIG_SMC_UCODE_PATCH) += micropatch_smc.o
diff --git a/arch/powerpc/cpu/mpc8xx/micropatch_smc.c
b/arch/powerpc/cpu/mpc8xx/micropatch_smc.c
new file mode 100644
index 00..819211f2db
--- /dev/null
+++ b/arch/powerpc/cpu/mpc8xx/micropatch_smc.c
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Microcode patches for the CPM as supplied by Motorola.
+ */
+
+#include
+#include
+#include
+#include
+
+static uint patch_2000[] = {
+ 0x3fff, 0x3ffd, 0x3ffb, 0x3ff9,
+ 0x5fefeff8, 0x5f91eff8, 0x3ff3, 0x3ff1,
+ 0x3a11e710, 0xedf0ccb9, 0xf318ed66, 0x7f0e5fe2,
+ 0x7fedbb38, 0x3afe7468, 0x7fedf4d8, 0x8ffbb92d,
+ 0xb83b77fd, 0xb0bb5eb9, 0xdfda7fed, 0x90bde74d,
+ 0x6f0dcbd3, 0xe7decfed, 0xcb50cfed, 0xcfeddf6d,
+ 0x914d4f74, 0x5eaedfcb, 0x9ee0e7df, 0xefbb6ffb,
+ 0xe7ef7f0e, 0x9ee57fed, 0xebb7effa, 0xeb30affb,
+ 0x7fea90b3, 0x7e0cf09f, 0xb318, 0x5fffdfff,
+ 0xac35efea, 0x7fce1fc1, 0xe2ff5fbd, 0xaffbe2ff,
+ 0x5fbfaffb, 0xf9a87d0f, 0xaef8770f, 0x7d0fb0a2,
+ 0xeffbbfff, 0xcfef5fba, 0x7d0fbfff, 0x5fba4cf8,
+ 0x7fddd09b, 0x49f847fd, 0x7efdf097, 0x7fedfffd,
+ 0x7dfdf093, 0xef7e7e1e, 0x5fba7f0e, 0x3a11e710,
+ 0xedf0cc87, 0xfb18ad0a, 0x1f85bbb8, 0x74283b7e,
+ 0x7375e4bb, 0x2ab64fb8, 0x5c7de4bb, 0x32fdffbf,
+ 0x5f0843f8, 0x7ce3e1bb, 0xe74f7ded, 0x6f0f4fe8,
+ 0xc7ba32be, 0x73f2efeb, 0x600b4f78, 0xe5bb760b,
+ 0x5388aef8, 0x4ef80b6a, 0xcfef9ee5, 0xabf8751f,
+ 0xefef5b88, 0x741f4fe8, 0x751e760d, 0x7fdb70dd,
+ 0x741cafce, 0xefcc7fce, 0x751e7088, 0x741ce7bb,
+ 0x334ecfed, 0xafdbefeb, 0xe5bb760b, 0x53ceaef8,
+ 0xafe8e7eb, 0x4bf8771e, 0x7e007fed, 0x4fcbe2cc,
+ 0x7fbc3085, 0x7b0f7a0f, 0x34b177fd, 0xb0e75e93,
+ 0xdf313e3b, 0xaf78741f, 0x741f30cc, 0xcfef5f08,
+ 0x741f3e88, 0xafb8771e, 0x5f437fed, 0x0bafe2cc,
+ 0x741ccfec, 0xe5ca53a9, 0x6fcb4f74, 0x5e89df27,
+ 0x2a923d14, 0x4b8fdf0c, 0x751f741c, 0x6c1eeffa,
+ 0xefea7fce, 0x6ffc309a, 0xefec3fca, 0x308fdf0a,
+ 0xadf85e7a, 0xaf7daefd, 0x5e7adf0a, 0x5e7aafdd,
+ 0x761f1088, 0x1e7c7efd, 0x3089fffe, 0x4908fb18,
+ 0x5fffdfff, 0xafbbf0f7, 0x4ef85f43, 0xadf81489,
+ 0x7a0f7089, 0xcfef5089, 0x7a0fdf0c, 0x5e7cafed,
+ 0xbc6e780f, 0xefef780f, 0xefef790f, 0xa7f85eeb,
+ 0xffef790f, 0xefef790f, 0x1489df0a, 0x5e7aadfd,
+ 0x5f09fffb, 0xe79aded9, 0xeff96079, 0x607ae79a,
+ 0xded8eff9, 0x60795edb, 0x607acfef, 0xefefefdf,
+ 0xefbfef7f, 0xeeffedff, 0xebffe7ff, 0xafefafdf,
+ 0xafbfaf7f, 0xaeffadff, 0xabffa7ff, 0x6fef6fdf,
+ 0x6fbf6f7f, 0x6eff6dff, 0x6bff67ff, 0x2fef2fdf,
+ 0x2fbf2f7f, 0x2eff2dff, 0x2bff27ff, 0x4e08fd1f,
+ 0xe5ff6e0f, 0xaff87eef, 0x7e0ffdef, 0xf11f6079,
+ 0xabf8f51e, 0x7e0af11c, 0x37cfae16, 0x7fec909a,
+ 0xadf8efdc, 0xcfeae52f, 0x7d0fe12b, 0xf11c6079,
+
[PATCH 08/10] spi, mpc8xx: Take parameter RAM relocation into account
Instead of inhibiting parameter RAM relocation, take it into account. Signed-off-by: Christophe Leroy --- drivers/spi/mpc8xx_spi.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/spi/mpc8xx_spi.c b/drivers/spi/mpc8xx_spi.c index 734b0751a9..5c8d760935 100644 --- a/drivers/spi/mpc8xx_spi.c +++ b/drivers/spi/mpc8xx_spi.c @@ -52,10 +52,12 @@ static int mpc8xx_spi_probe(struct udevice *dev) immap_t __iomem *immr = (immap_t __iomem *)CONFIG_SYS_IMMR; cpm8xx_t __iomem *cp = &immr->im_cpm; spi_t __iomem *spi = (spi_t __iomem *)&cp->cp_dpmem[PROFF_SPI]; + u16 spi_rpbase; cbd_t __iomem *tbdf, *rbdf; - /* Disable relocation */ - out_be16(&spi->spi_rpbase, 0x1d80); + spi_rpbase = in_be16(&spi->spi_rpbase); + if (spi_rpbase) + spi = (spi_t __iomem *)&cp->cp_dpmem[spi_rpbase]; /* 1 */ /* Initialize the parameter ram. -- 2.39.2
[PATCH 05/10] powerpc: mpc8xx: Reorganise init RAM
Using SMC relocation microcode patch or USB-SOF microcode patch
will disable DPRAM memory from 0x2000 to 0x2400 and from 0x2f00
to 0x3000.
At the time being, init RAM is setup to use 0x2800-0x2e00, but
the stack pointer goes beyond 0x2800 and even beyond 0x2400.
For the time being we are not going to use any microcode patch
that uses memory about 0x3000, so reorganise setup to use:
- 0x2800 - 0x2e00 for init malloc and global data and CPM buffers
- 0x3000 - 0x3c00 for init stack
For more details about CPM dual port ram, see
commit b1d62424cb ("powerpc: mpc8xx: redistribute data in CPM dpram")
Signed-off-by: Christophe Leroy
---
arch/powerpc/cpu/mpc8xx/start.S| 9 +
arch/powerpc/include/asm/cpm_8xx.h | 16
include/configs/cmpc885.h | 1 +
include/configs/mcr3000.h | 1 +
4 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xx/start.S b/arch/powerpc/cpu/mpc8xx/start.S
index 0aa73fca12..41f12021c8 100644
--- a/arch/powerpc/cpu/mpc8xx/start.S
+++ b/arch/powerpc/cpu/mpc8xx/start.S
@@ -141,14 +141,15 @@ in_flash:
mtspr DER, r2
/* set up the stack on top of internal DPRAM */
+ lis r1, CFG_SYS_INIT_SP@h
+ ori r1, r1, CFG_SYS_INIT_SP@l
+ stwur0, -4(r1)
+ stwur0, -4(r1)
+
lis r3, (CFG_SYS_INIT_RAM_ADDR + CFG_SYS_INIT_RAM_SIZE)@h
ori r3, r3, (CFG_SYS_INIT_RAM_ADDR + CFG_SYS_INIT_RAM_SIZE)@l
- stw r0, -4(r3)
- stw r0, -8(r3)
- addir1, r3, -8
bl board_init_f_alloc_reserve
- addir1, r3, -8
/* Zeroise the CPM dpram */
lis r4, CONFIG_SYS_IMMR@h
diff --git a/arch/powerpc/include/asm/cpm_8xx.h
b/arch/powerpc/include/asm/cpm_8xx.h
index 09c24efd91..77ffcce5a6 100644
--- a/arch/powerpc/include/asm/cpm_8xx.h
+++ b/arch/powerpc/include/asm/cpm_8xx.h
@@ -51,14 +51,14 @@
/*
* DPRAM defines and allocation functions
*/
-#define CPM_SERIAL_BASE0x1800
-#define CPM_I2C_BASE 0x1820
-#define CPM_SPI_BASE 0x1840
-#define CPM_FEC_BASE 0x1860
-#define CPM_SERIAL2_BASE 0x18e0
-#define CPM_SCC_BASE 0x1900
-#define CPM_POST_BASE 0x1980
-#define CPM_WLKBD_BASE 0x1a00
+#define CPM_SERIAL_BASE0x0800
+#define CPM_I2C_BASE 0x0820
+#define CPM_SPI_BASE 0x0840
+#define CPM_FEC_BASE 0x0860
+#define CPM_SERIAL2_BASE 0x08E0
+#define CPM_SCC_BASE 0x0900
+#define CPM_POST_BASE 0x0980
+#define CPM_WLKBD_BASE 0x0a00
#define BD_IIC_START ((uint) 0x0400) /* <- please use CPM_I2C_BASE !! */
diff --git a/include/configs/cmpc885.h b/include/configs/cmpc885.h
index b76230e9a4..545365e112 100644
--- a/include/configs/cmpc885.h
+++ b/include/configs/cmpc885.h
@@ -9,6 +9,7 @@
/* Definitions for initial stack pointer and data area (in DPRAM) */
#define CFG_SYS_INIT_RAM_ADDR (CONFIG_SYS_IMMR + 0x2800)
#define CFG_SYS_INIT_RAM_SIZE (0x2e00 - 0x2800)
+#define CFG_SYS_INIT_SP(CONFIG_SYS_IMMR + 0x3c00)
/* RAM configuration (note that CFG_SYS_SDRAM_BASE must be zero) */
#define CFG_SYS_SDRAM_BASE 0x
diff --git a/include/configs/mcr3000.h b/include/configs/mcr3000.h
index 6b16b050ff..a07761fdbb 100644
--- a/include/configs/mcr3000.h
+++ b/include/configs/mcr3000.h
@@ -14,6 +14,7 @@
/* Definitions for initial stack pointer and data area (in DPRAM) */
#define CFG_SYS_INIT_RAM_ADDR (CONFIG_SYS_IMMR + 0x2800)
#defineCFG_SYS_INIT_RAM_SIZE (0x2e00 - 0x2800)
+#define CFG_SYS_INIT_SP(CONFIG_SYS_IMMR + 0x3c00)
/* RAM configuration (note that CFG_SYS_SDRAM_BASE must be zero) */
#defineCFG_SYS_SDRAM_BASE 0x
--
2.39.2
[PATCH 09/10] serial, mpc8xx: Take parameter RAM relocation into account
Instead of inhibiting parameter RAM relacation, take into account the configured one. It means INIT_TRX command cannot be used and must be done manually as explained in the microcode patch application note. Signed-off-by: Christophe Leroy --- drivers/serial/serial_mpc8xx.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/serial/serial_mpc8xx.c b/drivers/serial/serial_mpc8xx.c index beffc34d11..d82760c7f1 100644 --- a/drivers/serial/serial_mpc8xx.c +++ b/drivers/serial/serial_mpc8xx.c @@ -83,6 +83,7 @@ static int serial_mpc8xx_probe(struct udevice *dev) immap_t __iomem *im = (immap_t __iomem *)CONFIG_SYS_IMMR; smc_t __iomem *sp; smc_uart_t __iomem *up; + u16 smc_rpbase; cpm8xx_t __iomem *cp = &(im->im_cpm); struct serialbuffer __iomem *rtx; @@ -90,8 +91,10 @@ static int serial_mpc8xx_probe(struct udevice *dev) sp = cp->cp_smc + SMC_INDEX; up = (smc_uart_t __iomem *)&cp->cp_dpmem[PROFF_SMC]; - /* Disable relocation */ - out_be16(&up->smc_rpbase, 0); + + smc_rpbase = in_be16(&up->smc_rpbase); + if (smc_rpbase) + up = (smc_uart_t __iomem *)&cp->cp_dpmem[smc_rpbase]; /* Disable transmitter/receiver. */ clrbits_be16(&sp->smc_smcmr, SMCMR_REN | SMCMR_TEN); @@ -154,15 +157,12 @@ static int serial_mpc8xx_probe(struct udevice *dev) out_be16(&up->smc_maxidl, CONFIG_SYS_MAXIDLE); out_be32(&rtx->rxindex, 0); - /* Initialize Tx/Rx parameters. */ - while (in_be16(&cp->cp_cpcr) & CPM_CR_FLG) /* wait if cp is busy */ - ; - - out_be16(&cp->cp_cpcr, -mk_cr_cmd(CPM_CR_CH_SMC, CPM_CR_INIT_TRX) | CPM_CR_FLG); - - while (in_be16(&cp->cp_cpcr) & CPM_CR_FLG) /* wait if cp is busy */ - ; + out_be32(&up->smc_rstate, 0); + out_be32(&up->smc_tstate, 0); + out_be16(&up->smc_rbptr, CPM_SERIAL_BASE); + out_be16(&up->smc_tbptr, CPM_SERIAL_BASE + sizeof(cbd_t)); + out_be16(&up->smc_brkcr, 1); + out_be16(&up->smc_brkec, 0); /* Enable transmitter/receiver. */ setbits_be16(&sp->smc_smcmr, SMCMR_REN | SMCMR_TEN); -- 2.39.2
Re: [PATCH] usb: gadget: Compile USB ethernet gadget only if NET is enabled
On Sun, 30 Apr 2023 23:20:35 +0200 Marek Vasut wrote: > In case NET networking is not enabled, it is not possible to compile > the USB ethernet gadget. Protect the symbols in Makefile to avoid > build failure. Such build failure may occur e.g. in case NET and USB > ethernet gadget is enabled in U-Boot proper, but not in SPL. > > Signed-off-by: Marek Vasut > --- > Cc: Lukasz Majewski > --- > drivers/usb/gadget/Makefile | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile > index 6cfe0f3a041..36f65e7eb95 100644 > --- a/drivers/usb/gadget/Makefile > +++ b/drivers/usb/gadget/Makefile > @@ -34,8 +34,10 @@ endif > > obj-$(CONFIG_CI_UDC) += ci_udc.o > > +ifeq ($(CONFIG_$(SPL_TPL_)NET),y) > obj-$(CONFIG_USB_ETHER) += ether.o > obj-$(CONFIG_USB_ETH_RNDIS) += rndis.o > +endif > > # Devices not related to the new gadget layer depend on > CONFIG_USB_DEVICE # This is really only N900 and USBTTY now. Reviewed-by: Lukasz Majewski Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgprhg_u6wz1J.pgp Description: OpenPGP digital signature
Re: [PATCH v3 00/19] Migration to using binman for bootloader
Hi Christian On 04/05/23 14:08, Christian Gmeiner wrote: Hi This series aims to eliminate the use of additional custom repositories such as k3-image-gen (K3 Image Generation) repo and core-secdev-k3 (K3 Security Development Tools) that was plumbed into the U-Boot build flow to generate boot images for TI K3 platform devices. And instead, we move towards using binman that aligns better with the community standard build flow. This series uses binman for all K3 platforms supported on U-Boot currently; both HS (High Security, both SE and FS) and GP (General Purpose) devices. Background on using k3-image-gen: * TI K3 devices require a SYSFW (System Firmware) image consisting of a signed system firmware image and board configuration binaries, this is needed to bring up system firmware during U-Boot R5 SPL startup. * Board configuration data contain board-specific information such as resource management, power management and security. Background on using core-secdev-k3: * Contains resources to sign x509 certificates for HS devices Series intends to use binman to take over the packaging and signing for the R5 bootloader images tiboot3.bin (and sysfw.itb, for non-combined boot flow) instead of k3-image-gen. Series also packages the A72/A53 bootloader images (tispl.bin and u-boot.img) using ATF, OPTEE and DM (Device Manager) This simplifies building U-Boot with sysfw alot - thanks for your work! I have tested this series on an am642 based design. One thing is missing for my HSM use case. I want to build an unsigned Image and need to sign it with binman in the context of the HSM. Therefore we need repacking support. Are you working on that too? So the idea of signing using binman in the HSM flow was discussed earlier [1] and the final call was to leave the boot artifacts that could be re-signed. So repacking support is not part of this series right now, you can use the tools mentioned in the thread [1] to do that for simple enough FIT images. However complex images like tiboot3.bin and tispl.bin might be a future action. I am not completely sure of the HSM flow though, pinging Andrew to comment further on this. [1] https://lore.kernel.org/all/0b2a8709-eb49-b866-5733-21bee021d...@ti.com/ -- Thanking You Neha Malcom Francis
Re: [PATCH] usb: gadget: Compile USB ethernet gadget only if NET is enabled
On 5/4/23 11:04, Lukasz Majewski wrote: On Sun, 30 Apr 2023 23:20:35 +0200 Marek Vasut wrote: In case NET networking is not enabled, it is not possible to compile the USB ethernet gadget. Protect the symbols in Makefile to avoid build failure. Such build failure may occur e.g. in case NET and USB ethernet gadget is enabled in U-Boot proper, but not in SPL. Signed-off-by: Marek Vasut --- Cc: Lukasz Majewski --- drivers/usb/gadget/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile index 6cfe0f3a041..36f65e7eb95 100644 --- a/drivers/usb/gadget/Makefile +++ b/drivers/usb/gadget/Makefile @@ -34,8 +34,10 @@ endif obj-$(CONFIG_CI_UDC) += ci_udc.o +ifeq ($(CONFIG_$(SPL_TPL_)NET),y) obj-$(CONFIG_USB_ETHER) += ether.o obj-$(CONFIG_USB_ETH_RNDIS) += rndis.o +endif # Devices not related to the new gadget layer depend on CONFIG_USB_DEVICE # This is really only N900 and USBTTY now. Reviewed-by: Lukasz Majewski NAK (so this does not get applied by accident, because ongoing discussion about Kconfig symbols)
[PATCH v3 0/5] SPL NVMe support
This patchset adds support to load images of the SPL's next booting stage from a NVMe device. Changes in v3: - Add generic API to fetch payload from Ext or FAT filesystems - Remove reduntant SPL_PCI_PNP config check Changes in v2: - Rebase on v2023.07-rc1 - Use uclass ID for blk APIs - Add support to load FIT images from ext filesystem Mayuresh Chitale (5): spl: Add Kconfig options for NVME spl: blk: Support loading images from fs nvme: pci: Enable for SPL spl: Support loading a FIT from ext FS common: spl: Add spl NVMe boot support arch/riscv/include/asm/spl.h | 1 + common/spl/Kconfig | 31 + common/spl/Makefile | 2 ++ common/spl/spl_blk_fs.c | 54 common/spl/spl_ext.c | 33 ++ common/spl/spl_nvme.c| 34 +++ drivers/Makefile | 1 + drivers/block/Kconfig| 7 + drivers/nvme/Makefile| 2 +- drivers/pci/Kconfig | 7 + include/spl.h| 3 ++ 11 files changed, 174 insertions(+), 1 deletion(-) create mode 100644 common/spl/spl_blk_fs.c create mode 100644 common/spl/spl_nvme.c -- 2.34.1
[PATCH v3 1/5] spl: Add Kconfig options for NVME
Add kconfig options to enable NVME and PCI NVMe support in SPL Signed-off-by: Mayuresh Chitale --- common/spl/Kconfig | 21 + 1 file changed, 21 insertions(+) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index 2c042ad306..515e8f2c66 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -1263,6 +1263,27 @@ config SPL_SATA_RAW_U_BOOT_SECTOR Sector on the SATA disk to load U-Boot from, when the SATA disk is being used in raw mode. Units: SATA disk sectors (1 sector = 512 bytes). +config SPL_NVME + bool "NVM Express device support" + depends on BLK + select HAVE_BLOCK_DEVICE + select SPL_BLK_FS + help + This option enables support for NVM Express devices. + It supports basic functions of NVMe (read/write). + +config SPL_NVME_PCI + bool "NVM Express PCI device support for SPL" + depends on SPL_PCI && SPL_NVME + help + This option enables support for NVM Express PCI devices. + This allows use of NVMe devices for loading u-boot. + +config SPL_NVME_BOOT_DEVICE + hex "NVMe boot device number" + depends on SPL_NVME + default 0x0 + config SPL_SERIAL bool "Support serial" select SPL_PRINTF -- 2.34.1
[PATCH v3 2/5] spl: blk: Support loading images from fs
Add a generic API to support loading of SPL payload from EXT or FAT
filesystem on a given partition of a block device.
Signed-off-by: Mayuresh Chitale
---
common/spl/Makefile | 1 +
common/spl/spl_blk_fs.c | 54 +
drivers/block/Kconfig | 7 ++
include/spl.h | 3 +++
4 files changed, 65 insertions(+)
create mode 100644 common/spl/spl_blk_fs.c
diff --git a/common/spl/Makefile b/common/spl/Makefile
index 13db3df993..5210ad0248 100644
--- a/common/spl/Makefile
+++ b/common/spl/Makefile
@@ -10,6 +10,7 @@ ifdef CONFIG_SPL_BUILD
obj-$(CONFIG_$(SPL_TPL_)FRAMEWORK) += spl.o
obj-$(CONFIG_$(SPL_TPL_)BOOTROM_SUPPORT) += spl_bootrom.o
obj-$(CONFIG_$(SPL_TPL_)LOAD_FIT) += spl_fit.o
+obj-$(CONFIG_$(SPL_TPL_)BLK_FS) += spl_blk_fs.o
obj-$(CONFIG_$(SPL_TPL_)LEGACY_IMAGE_FORMAT) += spl_legacy.o
obj-$(CONFIG_$(SPL_TPL_)NOR_SUPPORT) += spl_nor.o
obj-$(CONFIG_$(SPL_TPL_)XIP_SUPPORT) += spl_xip.o
diff --git a/common/spl/spl_blk_fs.c b/common/spl/spl_blk_fs.c
new file mode 100644
index 00..fb2e8bbea7
--- /dev/null
+++ b/common/spl/spl_blk_fs.c
@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023
+ * Ventana Micro Systems Inc.
+ *
+ * Derived work from spl_sata.c
+ */
+
+#include
+#include
+
+int spl_blk_load_image(struct spl_image_info *spl_image,
+ struct spl_boot_device *bootdev,
+ enum uclass_id uclass_id, int devnum)
+{
+ int ret = -ENOSYS, part;
+ struct blk_desc *blk_desc;
+
+ blk_desc = blk_get_devnum_by_uclass_id(uclass_id, devnum);
+ if (!blk_desc)
+ return ret;
+
+ blk_show_device(uclass_id, devnum);
+
+ if (IS_ENABLED(CONFIG_SPL_FS_EXT4)) {
+ switch (uclass_id) {
+ case UCLASS_NVME:
+ part = CONFIG_SYS_NVME_EXT_BOOT_PARTITION;
+ break;
+ default:
+ return ret;
+ }
+ ret = spl_load_image_ext(spl_image, bootdev, blk_desc, part,
+CONFIG_SPL_PAYLOAD);
+ if (!ret)
+ return ret;
+ }
+
+ if (IS_ENABLED(CONFIG_SPL_FS_FAT)) {
+ switch (uclass_id) {
+ case UCLASS_NVME:
+ part = CONFIG_SYS_NVME_FAT_BOOT_PARTITION;
+ break;
+ default:
+ return ret;
+ }
+ ret = spl_load_image_fat(spl_image, bootdev, blk_desc, part,
+CONFIG_SPL_PAYLOAD);
+ if (!ret)
+ return ret;
+ }
+
+ return ret;
+}
diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index 5a1aeb3d2b..6baaa6f071 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -107,6 +107,13 @@ config EFI_MEDIA
For sandbox there is a test driver.
+config SPL_BLK_FS
+ bool "Load images from filesystems on block devices"
+ depends on SPL_BLK
+ help
+ Use generic support to load images from fat/ext filesystems on
+ different types of block devices such as NVMe.
+
if EFI_MEDIA
config EFI_MEDIA_SANDBOX
diff --git a/include/spl.h b/include/spl.h
index 7e0f5ac63b..4546648394 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -672,6 +672,9 @@ int spl_load_image_ext(struct spl_image_info *spl_image,
int spl_load_image_ext_os(struct spl_image_info *spl_image,
struct spl_boot_device *bootdev,
struct blk_desc *block_dev, int partition);
+int spl_blk_load_image(struct spl_image_info *spl_image,
+ struct spl_boot_device *bootdev,
+ enum uclass_id uclass_id, int devnum);
/**
* spl_early_init() - Set up device tree and driver model in SPL if enabled
--
2.34.1
[PATCH v3 3/5] nvme: pci: Enable for SPL
Enable NVME and PCI NVMe drivers for SPL builds. Also enable PCI_PNP for SPL which is required to auto configure the PCIe devices. Signed-off-by: Mayuresh Chitale --- drivers/Makefile | 1 + drivers/nvme/Makefile | 2 +- drivers/pci/Kconfig | 7 +++ 3 files changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/Makefile b/drivers/Makefile index 58be410135..dc559ea7f7 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -34,6 +34,7 @@ obj-$(CONFIG_$(SPL_)DM_MAILBOX) += mailbox/ obj-$(CONFIG_$(SPL_)REMOTEPROC) += remoteproc/ obj-$(CONFIG_$(SPL_)SYSINFO) += sysinfo/ obj-$(CONFIG_$(SPL_TPL_)TPM) += tpm/ +obj-$(CONFIG_$(SPL_)NVME) += nvme/ obj-$(CONFIG_XEN) += xen/ obj-$(CONFIG_$(SPL_)FPGA) += fpga/ obj-y += bus/ diff --git a/drivers/nvme/Makefile b/drivers/nvme/Makefile index fa7b619446..fd3e68a91d 100644 --- a/drivers/nvme/Makefile +++ b/drivers/nvme/Makefile @@ -4,4 +4,4 @@ obj-y += nvme-uclass.o nvme.o nvme_show.o obj-$(CONFIG_NVME_APPLE) += nvme_apple.o -obj-$(CONFIG_NVME_PCI) += nvme_pci.o +obj-$(CONFIG_$(SPL_)NVME_PCI) += nvme_pci.o diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig index ef328d2652..ecab6ddc7e 100644 --- a/drivers/pci/Kconfig +++ b/drivers/pci/Kconfig @@ -40,6 +40,13 @@ config PCI_PNP help Enable PCI memory and I/O space resource allocation and assignment. +config SPL_PCI_PNP + bool "Enable Plug & Play support for PCI" + default n + help + Enable PCI memory and I/O space resource allocation and assignment. + This is required to auto configure the enumerated devices. + config PCI_REGION_MULTI_ENTRY bool "Enable Multiple entries of region type MEMORY in ranges for PCI" help -- 2.34.1
[PATCH v3 4/5] spl: Support loading a FIT from ext FS
Detect a FIT when loading from an ext File system and handle it using
the FIT SPL support.
Signed-off-by: Mayuresh Chitale
---
common/spl/spl_ext.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/common/spl/spl_ext.c b/common/spl/spl_ext.c
index f117c630bf..7b771c41e9 100644
--- a/common/spl/spl_ext.c
+++ b/common/spl/spl_ext.c
@@ -8,6 +8,26 @@
#include
#include
#include
+#include
+
+static ulong spl_fit_read(struct spl_load_info *load, ulong file_offset,
+ ulong size, void *buf)
+{
+ loff_t filelen = (loff_t)load->priv, actlen;
+ char *filename = (char *)load->filename;
+ int ret;
+
+ ret = ext4fs_read(buf, file_offset, filelen, &actlen);
+ if (ret < 0) {
+ if (IS_ENABLED(CONFIG_SPL_LIBCOMMON_SUPPORT)) {
+ printf("%s: error reading image %s, err - %d\n",
+ __func__, filename, ret);
+ }
+ return ret;
+ }
+
+ return actlen;
+}
int spl_load_image_ext(struct spl_image_info *spl_image,
struct spl_boot_device *bootdev,
@@ -47,6 +67,19 @@ int spl_load_image_ext(struct spl_image_info *spl_image,
goto end;
}
+ if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
+ image_get_magic(header) == FDT_MAGIC) {
+ struct spl_load_info load;
+
+ debug("Found FIT\n");
+ load.read = spl_fit_read;
+ load.bl_len = 1;
+ load.filename = (void *)filename;
+ load.priv = (void *)filelen;
+
+ return spl_load_simple_fit(spl_image, &load, 0, header);
+ }
+
err = spl_parse_image_header(spl_image, bootdev, header);
if (err < 0) {
puts("spl: ext: failed to parse image header\n");
--
2.34.1
[PATCH v3 5/5] common: spl: Add spl NVMe boot support
Add support to load the next stage image from an NVMe disk which may
be formatted as an EXT or FAT filesystem.
Signed-off-by: Mayuresh Chitale
---
arch/riscv/include/asm/spl.h | 1 +
common/spl/Kconfig | 10 ++
common/spl/Makefile | 1 +
common/spl/spl_nvme.c| 34 ++
4 files changed, 46 insertions(+)
create mode 100644 common/spl/spl_nvme.c
diff --git a/arch/riscv/include/asm/spl.h b/arch/riscv/include/asm/spl.h
index 2898a770ee..9c0bf9755c 100644
--- a/arch/riscv/include/asm/spl.h
+++ b/arch/riscv/include/asm/spl.h
@@ -20,6 +20,7 @@ enum {
BOOT_DEVICE_SPI,
BOOT_DEVICE_USB,
BOOT_DEVICE_SATA,
+ BOOT_DEVICE_NVME,
BOOT_DEVICE_I2C,
BOOT_DEVICE_BOARD,
BOOT_DEVICE_DFU,
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 515e8f2c66..6e41ac4e56 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -1284,6 +1284,16 @@ config SPL_NVME_BOOT_DEVICE
depends on SPL_NVME
default 0x0
+config SYS_NVME_EXT_BOOT_PARTITION
+ hex "NVMe ext boot partition number"
+ depends on SPL_NVME
+ default 0x2
+
+config SYS_NVME_FAT_BOOT_PARTITION
+ hex "NVMe boot partition number"
+ depends on SPL_NVME
+ default 0x1
+
config SPL_SERIAL
bool "Support serial"
select SPL_PRINTF
diff --git a/common/spl/Makefile b/common/spl/Makefile
index 5210ad0248..bad2bbf6cf 100644
--- a/common/spl/Makefile
+++ b/common/spl/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_$(SPL_TPL_)USB_STORAGE) += spl_usb.o
obj-$(CONFIG_$(SPL_TPL_)FS_FAT) += spl_fat.o
obj-$(CONFIG_$(SPL_TPL_)FS_EXT4) += spl_ext.o
obj-$(CONFIG_$(SPL_TPL_)SATA) += spl_sata.o
+obj-$(CONFIG_$(SPL_TPL_)NVME) += spl_nvme.o
obj-$(CONFIG_$(SPL_TPL_)SEMIHOSTING) += spl_semihosting.o
obj-$(CONFIG_$(SPL_TPL_)DFU) += spl_dfu.o
obj-$(CONFIG_$(SPL_TPL_)SPI_LOAD) += spl_spi.o
diff --git a/common/spl/spl_nvme.c b/common/spl/spl_nvme.c
new file mode 100644
index 00..82b2bf3493
--- /dev/null
+++ b/common/spl/spl_nvme.c
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023
+ * Ventana Micro Systems Inc.
+ *
+ * Derived work from spl_sata.c
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int spl_nvme_load_image(struct spl_image_info *spl_image,
+ struct spl_boot_device *bootdev)
+{
+ int ret;
+
+ ret = pci_init();
+ if (ret < 0)
+ return ret;
+
+ ret = nvme_scan_namespace();
+ if (ret < 0)
+ return ret;
+
+ ret = spl_blk_load_image(spl_image, bootdev, UCLASS_NVME,
+CONFIG_SPL_NVME_BOOT_DEVICE);
+ return ret;
+}
+
+SPL_LOAD_IMAGE_METHOD("NVME", 0, BOOT_DEVICE_NVME, spl_nvme_load_image);
--
2.34.1
Re: [PATCH 05/10] powerpc: mpc8xx: Reorganise init RAM
On Thu, 2023-05-04 at 10:56 +0200, Christophe Leroy wrote:
> Using SMC relocation microcode patch or USB-SOF microcode patch
> will disable DPRAM memory from 0x2000 to 0x2400 and from 0x2f00
> to 0x3000.
>
> At the time being, init RAM is setup to use 0x2800-0x2e00, but
> the stack pointer goes beyond 0x2800 and even beyond 0x2400.
>
> For the time being we are not going to use any microcode patch
> that uses memory about 0x3000, so reorganise setup to use:
> - 0x2800 - 0x2e00 for init malloc and global data and CPM buffers
> - 0x3000 - 0x3c00 for init stack
>
> For more details about CPM dual port ram, see
> commit b1d62424cb ("powerpc: mpc8xx: redistribute data in CPM dpram")
>
> Signed-off-by: Christophe Leroy
> ---
> arch/powerpc/cpu/mpc8xx/start.S| 9 +
> arch/powerpc/include/asm/cpm_8xx.h | 16
> include/configs/cmpc885.h | 1 +
> include/configs/mcr3000.h | 1 +
> 4 files changed, 15 insertions(+), 12 deletions(-)
>
> diff --git a/arch/powerpc/cpu/mpc8xx/start.S b/arch/powerpc/cpu/mpc8xx/start.S
> index 0aa73fca12..41f12021c8 100644
> --- a/arch/powerpc/cpu/mpc8xx/start.S
> +++ b/arch/powerpc/cpu/mpc8xx/start.S
> @@ -141,14 +141,15 @@ in_flash:
> mtspr DER, r2
>
> /* set up the stack on top of internal DPRAM */
> + lis r1, CFG_SYS_INIT_SP@h
> + ori r1, r1, CFG_SYS_INIT_SP@l
> + stwur0, -4(r1)
> + stwur0, -4(r1)
Changing stack ptr incrementally is likely to confuse gdb which may do stack
accesses if you single step
over this code. It is better to setup the stack in a different reg and the just
assign r1 when done.
Jocke
Re: [PATCH 05/10] powerpc: mpc8xx: Reorganise init RAM
Le 04/05/2023 à 12:07, Joakim Tjernlund a écrit :
> On Thu, 2023-05-04 at 10:56 +0200, Christophe Leroy wrote:
>> Using SMC relocation microcode patch or USB-SOF microcode patch
>> will disable DPRAM memory from 0x2000 to 0x2400 and from 0x2f00
>> to 0x3000.
>>
>> At the time being, init RAM is setup to use 0x2800-0x2e00, but
>> the stack pointer goes beyond 0x2800 and even beyond 0x2400.
>>
>> For the time being we are not going to use any microcode patch
>> that uses memory about 0x3000, so reorganise setup to use:
>> - 0x2800 - 0x2e00 for init malloc and global data and CPM buffers
>> - 0x3000 - 0x3c00 for init stack
>>
>> For more details about CPM dual port ram, see
>> commit b1d62424cb ("powerpc: mpc8xx: redistribute data in CPM dpram")
>>
>> Signed-off-by: Christophe Leroy
>> ---
>> arch/powerpc/cpu/mpc8xx/start.S| 9 +
>> arch/powerpc/include/asm/cpm_8xx.h | 16
>> include/configs/cmpc885.h | 1 +
>> include/configs/mcr3000.h | 1 +
>> 4 files changed, 15 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/powerpc/cpu/mpc8xx/start.S
>> b/arch/powerpc/cpu/mpc8xx/start.S
>> index 0aa73fca12..41f12021c8 100644
>> --- a/arch/powerpc/cpu/mpc8xx/start.S
>> +++ b/arch/powerpc/cpu/mpc8xx/start.S
>> @@ -141,14 +141,15 @@ in_flash:
>> mtspr DER, r2
>>
>> /* set up the stack on top of internal DPRAM */
>> +lis r1, CFG_SYS_INIT_SP@h
>> +ori r1, r1, CFG_SYS_INIT_SP@l
>> +stwur0, -4(r1)
>> +stwur0, -4(r1)
>
> Changing stack ptr incrementally is likely to confuse gdb which may do stack
> accesses if you single step
> over this code. It is better to setup the stack in a different reg and the
> just assign r1 when done.
>
Ok, I can change that. But we are at the very begining and r1 is
undefined until now so it shouldn't matter.
Christophe
[PATCH] imx8qm_dmsse20a1: Improve SPL memory configuration
From: Fabio Estevam
Currently, building imx8qm_dmsse20a1_defconfig leads to the following
warning:
aarch64-linux-ld.bfd: invalid origin for memory region .sdram
Fix it by using the same SPL memory layout as done in the imx8mq_evk.
Reported-by: Tom Rini
Signed-off-by: Fabio Estevam
Tested-by: Oliver Graute
---
configs/imx8qm_dmsse20a1_defconfig | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/configs/imx8qm_dmsse20a1_defconfig
b/configs/imx8qm_dmsse20a1_defconfig
index 3341b5e447fb..57a5007f9e5b 100644
--- a/configs/imx8qm_dmsse20a1_defconfig
+++ b/configs/imx8qm_dmsse20a1_defconfig
@@ -16,6 +16,7 @@ CONFIG_SPL_SERIAL=y
CONFIG_SPL_DRIVERS_MISC=y
CONFIG_ENV_OFFSET=0x8
CONFIG_ENV_SECT_SIZE=0x2
+CONFIG_SPL_STACK=0x13e000
CONFIG_SPL=y
CONFIG_SYS_LOAD_ADDR=0x8028
CONFIG_SYS_MEMTEST_START=0xA000
@@ -38,11 +39,17 @@ CONFIG_USE_BOOTCOMMAND=y
CONFIG_BOOTCOMMAND="mmc dev ${mmcdev}; if mmc rescan; then if run
loadbootscript; then run bootscript; else if run loadimage; then run mmcboot;
else run netboot; fi; fi; else booti ${loadaddr} - ${fdt_addr}; fi"
CONFIG_LOG=y
CONFIG_BOARD_EARLY_INIT_F=y
-CONFIG_SPL_BSS_START_ADDR=0x00128000
CONFIG_SPL_MAX_SIZE=0x1f000
+CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
+CONFIG_SPL_BSS_START_ADDR=0x128000
CONFIG_SPL_BSS_MAX_SIZE=0x1000
CONFIG_SPL_BOARD_INIT=y
-CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
+CONFIG_SYS_SPL_MALLOC=y
+CONFIG_HAS_CUSTOM_SPL_MALLOC_START=y
+CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x12
+CONFIG_SYS_SPL_MALLOC_SIZE=0x3000
CONFIG_SPL_POWER_SUPPORT=y
CONFIG_SPL_POWER_DOMAIN=y
CONFIG_SPL_WATCHDOG_SUPPORT=y
--
2.34.1
Re: [PATCH] dt/bindings: fwu-mdata-mtd: drop changes outside FWU
Hi Rob, On Wed, May 03, 2023 at 12:24:39PM -0500, Rob Herring wrote: > On Wed, May 3, 2023 at 9:37 AM Ilias Apalodimas > wrote: > > > > Hi Krzysztof, > > > > On Tue, Apr 11, 2023 at 07:38:11AM +0200, Krzysztof Kozlowski wrote: > > > On 11/04/2023 01:21, jaswinder.si...@linaro.org wrote: > > > > From: Jassi Brar > > > > > > > > Any requirement of FWU should not require changes to bindings > > > > of other subsystems. For example, for mtd-backed storage we > > > > can do without requiring 'fixed-partitions' children to also > > > > carry 'uuid', a property which is non-standard and not in the > > > > bindings. > > > > > > > > There exists no code yet, so we can change the fwu-mtd bindings > > > > to contain all properties within the fwu-mdata node. > > > > > > > > Signed-off-by: Jassi Brar > > > > --- > > > > > > > > Hi Rob, Hi Krzysztof, > > > > > > > > I was suggested, and I agree, it would be a good idea to get your > > > > blessings > > > > for the location and meta-data (fwu-mdata) bindings for the FWU. > > > > > > > > The FWU images can be located in GPT partitions or MTD backed storage. > > > > The basic bindings for fwu-mdata has already been merged in uboot > > > > (ideally they > > > > too should have had your review). Now I am trying to fully support MTD > > > > backed > > > > storage and hence looking for your review. The proposed bindings are > > > > totally > > > > self-contained and don't require changes to any other subsystem. > > > > > > > > Thanks. > > > > > > I think we do not review U-Boot bindings usually, except these put in > > > the Linux kernel. There were few targeting U-Boot specifically (e.g. > > > Documentation/devicetree/bindings/mtd/partitions/u-boot.yaml and > > > Documentation/devicetree/bindings/nvmem/u-boot,env.yaml) so if you want > > > our blessing, the bindings should be done in Linux kernel repo. > > > > > > I am pretty sure that reviewing other project bindings would be too much > > > of work for me. > > > > Sure that makes sense. But an answer here of whether the bindings make > > sense to the DT maintainers or not would help to move forward. > > I have lots of comments on the bindings, but I'm missing what is the > problem to solve. Yes, it's 'A/B firmware updates', but what > configuration data do you need, why and when do you need it. IOW, give > me enough information to understand why a binding is designed the way > it is and be able to propose alternatives. Thanks for taking the time on this. I do have questions for Jassi as well, but let me describe what I have in mind first. What we are trying to do here is standardize how EFI compliant devices (and in extent SystemReady-IR) can reliably perform firmware updates adding capabilities like rollback, brick protection etc. The high level description of how this is done is described here [0]. The really short version of that document is that you: - Perform a capsule update of the non active partition - Reboot to that partition and launch your OS - If the OS approves the updates (which is implementation defined), then you install an empty capsule indicating the acceptance of the update - If the device for any reason reboots for X amounts of times and the acceptance capsule is not found, it will revert to the primary partition. - If the acceptance capsule is found the device permanently switches over to the new firmware, bumping any rollback counters it might have (that's optional). - All these information along with UUIDs for the storage medium and the image types are stored in the metadata [1], which also has a backup location. What you fundamentally need to perform an A/B booting is a first stage boot loader (or a masked ROM) that can understand the metadata described here [1]. Ideally we would only require the DT to describe where we can find that metadata -- but the reality is a bit different. Currently we only support of 2 types of devices - metadata lives in a GPT partition - They are located in an specific offset on a SPI-NOR GPT based devices are straightforward. As you noticed we only need the phandle of the device. There is a defined UUID for the metadata, so we discover them along with the backup partition. The MTD case is a bit more complicated. The metadata format only defines GUIDs for - UUID identifying the image type (image type GUID) - the UUID of the storage volume where the image is located Since we now don't have a UUID of the storage volume where the image is located, we somehow need to map the image UUID to a device offset. I think this is what Jassi is trying to define here -- it's worth noting that this has to happen for all non-GPT devices. As for when the data is needed, since this is backed up by EFI capsule updates, we only need access from the bootloader (and that's where the update agent currently resides, it's part of the u-boot EFI capsule functionality). > > That's easy enough to deduce for the GPT case. It's just needing to > know which device h
Pull request efi-2023-07-rc2
Dear Tom, The following changes since commit 2440719d258a97824395532cb4a775752b423f63: Merge tag 'u-boot-imx-20230503' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2023-05-03 13:15:12 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-2023-07-rc2 for you to fetch changes up to 8a6414d1e410ab65780a4c5eb99e79e5b9bc21c1: CI: treat documentation warnings as errors (2023-05-04 11:15:12 +0200) Gitlab CI showed no issues: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/16241 Pull request efi-2023-07-rc2 Documentation: * treat documentation warnings as errors in CI * adjust StarFive VisionFive 2 and SiFive Unmatched documentation * man-page for cp * correct description of uclass_get_device_by_of_path * correct proftool usage UEFI * Fix documentation of EFI Python tests * Rename efi_selftest Python test Alexander Shirokov (1): doc: mmc: drop 0x prefixes in read/write examples Heinrich Schuchardt (8): tools: fix TestFdtUtil() dm: core: fix introduce uclass_get_device_by_of_path doc: Indicate required OpenSBI release for VisionFive 2 doc: fix StarFive VisionFive v2 documentation doc: correct HiFive Unmatched boot description test: fix pydoc issues for EFI tests doc: man-page for cp CI: treat documentation warnings as errors Pavel Skripkin (1): docs: fix wrong proftool usage Simon Glass (1): efi: Rename the base efi self-test .azure-pipelines.yml | 2 +- .gitlab-ci.yml | 2 +- doc/board/sifive/unmatched.rst | 6 +- doc/board/starfive/visionfive2.rst | 23 --- doc/develop/trace.rst | 2 +- doc/usage/cmd/cp.rst | 83 ++ doc/usage/cmd/mmc.rst | 4 +- doc/usage/index.rst| 1 + include/dm/uclass.h| 2 +- test/py/tests/test_efi_bootmgr/conftest.py | 6 +- test/py/tests/test_efi_capsule/capsule_defs.py | 2 + test/py/tests/test_efi_capsule/conftest.py | 11 ++-- test/py/tests/test_efi_secboot/conftest.py | 6 +- test/py/tests/test_efi_secboot/defs.py | 2 + test/py/tests/test_efi_selftest.py | 2 +- tools/dtoc/test_fdt.py | 4 +- 16 files changed, 129 insertions(+), 29 deletions(-) create mode 100644 doc/usage/cmd/cp.rst
Re: [PATCH 05/10] powerpc: mpc8xx: Reorganise init RAM
On Thu, 2023-05-04 at 10:17 +, Christophe Leroy wrote:
>
> Le 04/05/2023 à 12:07, Joakim Tjernlund a écrit :
> > On Thu, 2023-05-04 at 10:56 +0200, Christophe Leroy wrote:
> > > Using SMC relocation microcode patch or USB-SOF microcode patch
> > > will disable DPRAM memory from 0x2000 to 0x2400 and from 0x2f00
> > > to 0x3000.
> > >
> > > At the time being, init RAM is setup to use 0x2800-0x2e00, but
> > > the stack pointer goes beyond 0x2800 and even beyond 0x2400.
> > >
> > > For the time being we are not going to use any microcode patch
> > > that uses memory about 0x3000, so reorganise setup to use:
> > > - 0x2800 - 0x2e00 for init malloc and global data and CPM buffers
> > > - 0x3000 - 0x3c00 for init stack
> > >
> > > For more details about CPM dual port ram, see
> > > commit b1d62424cb ("powerpc: mpc8xx: redistribute data in CPM dpram")
> > >
> > > Signed-off-by: Christophe Leroy
> > > ---
> > > arch/powerpc/cpu/mpc8xx/start.S| 9 +
> > > arch/powerpc/include/asm/cpm_8xx.h | 16
> > > include/configs/cmpc885.h | 1 +
> > > include/configs/mcr3000.h | 1 +
> > > 4 files changed, 15 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/arch/powerpc/cpu/mpc8xx/start.S
> > > b/arch/powerpc/cpu/mpc8xx/start.S
> > > index 0aa73fca12..41f12021c8 100644
> > > --- a/arch/powerpc/cpu/mpc8xx/start.S
> > > +++ b/arch/powerpc/cpu/mpc8xx/start.S
> > > @@ -141,14 +141,15 @@ in_flash:
> > > mtspr DER, r2
> > >
> > > /* set up the stack on top of internal DPRAM */
> > > + lis r1, CFG_SYS_INIT_SP@h
> > > + ori r1, r1, CFG_SYS_INIT_SP@l
> > > + stwur0, -4(r1)
> > > + stwur0, -4(r1)
> >
> > Changing stack ptr incrementally is likely to confuse gdb which may do
> > stack accesses if you single step
> > over this code. It is better to setup the stack in a different reg and the
> > just assign r1 when done.
> >
>
> Ok, I can change that. But we are at the very begining and r1 is
> undefined until now so it shouldn't matter.
Yes, but gdb will see r1 change and will try to parse stack when it changes.
This only matters
when single stepping code in question.
I am unlikely to debug 8xx these days, just wanted to mention my past
experience.
Jocke
[PATCH] scripts/Makefile.dts: tweak logic for deciding which dtbs to build
The idea in 3609e1dc5f4d (dts: automatically build necessary .dtb files) was fine, but the implementation was suboptimal due to some misunderstandings on my part (and possibly defects in some defconfig files): - Sometimes DEFAULT_DEVICE_TREE is not included in OF_LIST or SPL_OF_LIST - SPL_OF_LIST is not always a subset of OF_LIST - While SPL_OF_LIST governs the list of dtbs relevant to SPL (i.e., may be built into an SPL-with-bunch-of-dtbs-to-choose-between-at-runtime), those dtbs are not actually _built_ during the SPL build phase, i.e. when $(SPL_) would expand to SPL_. fdtgrep runs on the artifacts produced during the ordinary U-Boot build. Tweak the logic so that we simply add the union of all dtbs mentioned in either DEFAULT_DEVICE_TREE, OF_LIST and SPL_OF_LIST to dtb-y. That should, for real, ensure that we always build all the dtbs that is relevant to the current board, and should in turn enable us to massively simplify arch/*/dts/Makefile. Signed-off-by: Rasmus Villemoes --- Per https://lore.kernel.org/u-boot/20230503145438.GB1134230@bill-the-cat/ I guess one could apply make's built-in sort function since the RHS is very likely to contain some duplicates, but I don't think it really matters. So for now I'm just posting the version of the patch that Tom tested. scripts/Makefile.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Makefile.dts b/scripts/Makefile.dts index 2561025da8..5e2429c617 100644 --- a/scripts/Makefile.dts +++ b/scripts/Makefile.dts @@ -1,3 +1,3 @@ # SPDX-License-Identifier: GPL-2.0+ -dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_$(SPL_)OF_LIST))) +dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST))) -- 2.37.2
Re: [PATCH] usb: ehci-mx6: replace regulator_set_enable with *_if_allowed
On 5/4/23 10:12, Eugen Hristev wrote: On 5/4/23 00:52, Marek Vasut wrote: On 5/2/23 18:13, Tim Harvey wrote: On Mon, May 1, 2023 at 11:51 PM Eugen Hristev wrote: regulator_set_enable_if_allowed already handles cases when the regulator is already enabled, or already disabled, and does not treat these as errors. With this change, the driver can work correctly even if the regulator is already taken or already disabled by another consumer. Signed-off-by: Eugen Hristev --- Hi Tim, I have not tested this as I do not have a mx6 board. can you please try it ? Thanks, Eugen Eugen, This does resolve the issue that occurs after your refcount series [1]. However after thinking about this more and seeing Marek's responses this wasn't an issue of multiple consumers sharing the same regulator. Instead this particular issue was that the vbus regulator is getting enabled twice without being disabled. This kind of issues can be uncovered when we add the refcounter :) Yeah, and that's a good thing. The refcounter is much appreciated (am I repeating myself?) On one hand I am happy to uncover such bugs. However, this leads me to wonder, even without a refcount, even without my series, enabling a regulator that is already enabled should return -EALREADY I don't that so, you can have regulators which supply multiple things and which are claimed by multiple driver instances, at which point they will each enable the regulator (refcount++) and that shouldn't end up returning -EALREADY . Right ? One such example is buck regulator supplying e.g. SD and eMMC Vcc . On the other hand, it appears it will take longer to get the refcount applied though. I think we need to sort out the fallout, but that's probably still fine.
AW: [PATCH v2 2/3] X86: Add support for distro boot
Hello Simon, I've tried out successfully the option (with BOOTSTD_FULL, with BOOTSTD_DEFAULT it's not possible to boot) and will provide a changed patch set soon. Mit freundlichen Grüßen / Best regards Thomas Mittelstaedt Cross-Domain Computing Solutions > -Ursprüngliche Nachricht- > Von: Simon Glass > Gesendet: Dienstag, 2. Mai 2023 19:12 > An: Heinrich Schuchardt > Cc: Mittelstaedt Thomas (XC-CT/EBV3) ; > u-boot@lists.denx.de; Niel Armstrong ; Patrick > Delaunay ; Ramon Fried > ; Marek Vasut ; Manuel Traut > ; Bin Meng > Betreff: Re: [PATCH v2 2/3] X86: Add support for distro boot > > Hi, > > On Tue, 2 May 2023 at 09:41, Heinrich Schuchardt wrote: > > > > > > > > Am 2. Mai 2023 17:21:29 MESZ schrieb thomas.mittelsta...@de.bosch.com: > > >From: Thomas Mittelstaedt > > > > > >Enable distro boot feature for U-Boot at VirtualBox described at > > >https://sou/ > > >rce.denx.de%2Fu-boot%2Fu-boot%2F- > %2Fblob%2Fmaster%2Fdoc%2Fdevelop%2Fd > > > >istro.rst&data=05%7C01%7Cthomas.mittelstaedt%40de.bosch.com%7Ca52180e > > > >e6e8f4087da4d08db4b306953%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0% > 7C0% > > > >7C638186443515155378%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw > MDAiLCJQ > > > >IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata > =4TSv > > >yIZMiz4Tt7Wt36NxQR576tg%2F9cS%2FVyZS83xwN50%3D&reserved=0 > > > > > >Signed-off-by: Thomas Mittelstaedt > > >--- > > > configs/efi-x86_payload64_defconfig | 12 +--- > > > include/configs/efi-x86_payload.h | 11 +++ > > > 2 files changed, 12 insertions(+), 11 deletions(-) > > > > > >diff --git a/configs/efi-x86_payload64_defconfig > > >b/configs/efi-x86_payload64_defconfig > > >index 30a7f31dac..a4cfe95890 100644 > > >--- a/configs/efi-x86_payload64_defconfig > > >+++ b/configs/efi-x86_payload64_defconfig > > >@@ -8,33 +8,23 @@ CONFIG_TARGET_EFI_PAYLOAD=y CONFIG_FIT=y > > >CONFIG_FIT_SIGNATURE=y CONFIG_LEGACY_IMAGE_FORMAT=y > > >+CONFIG_DISTRO_DEFAULTS=y > > > CONFIG_SHOW_BOOT_PROGRESS=y > > > CONFIG_USE_BOOTARGS=y > > > CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro" > > >-CONFIG_USE_BOOTCOMMAND=y > > > CONFIG_PRE_CONSOLE_BUFFER=y > > > CONFIG_SYS_CONSOLE_INFO_QUIET=y > > > CONFIG_DISPLAY_BOARDINFO_LATE=y > > > CONFIG_LAST_STAGE_INIT=y > > >-CONFIG_HUSH_PARSER=y > > > CONFIG_SYS_PBSIZE=532 > > > CONFIG_CMD_IDE=y > > > CONFIG_CMD_MMC=y > > >-CONFIG_CMD_PART=y > > > CONFIG_CMD_USB=y > > >-CONFIG_CMD_DHCP=y > > > CONFIG_BOOTP_BOOTFILESIZE=y > > > # CONFIG_CMD_NFS is not set > > >-CONFIG_CMD_PING=y > > > CONFIG_CMD_TIME=y > > >-CONFIG_CMD_EXT2=y > > >-CONFIG_CMD_EXT4=y > > > CONFIG_CMD_EXT4_WRITE=y > > >-CONFIG_CMD_FAT=y > > >-CONFIG_CMD_FS_GENERIC=y > > > CONFIG_MAC_PARTITION=y > > >-CONFIG_ISO_PARTITION=y > > >-CONFIG_EFI_PARTITION=y > > > CONFIG_ENV_OVERWRITE=y > > > CONFIG_ENV_IS_IN_FAT=y > > > CONFIG_ENV_FAT_INTERFACE="scsi" > > >diff --git a/include/configs/efi-x86_payload.h > > >b/include/configs/efi-x86_payload.h > > >index c72b067c36..e1cd8eb316 100644 > > >--- a/include/configs/efi-x86_payload.h > > >+++ b/include/configs/efi-x86_payload.h > > >@@ -6,6 +6,17 @@ > > > /* > > > * board/config.h - configuration options, board specific > > > */ > > >+#ifndef CONFIG_SPL_BUILD > > >+ > > >+#define BOOT_TARGET_SCSI(func) \ > > > > Shouldn't NVMe be added here too? > > This is automatic if you use bootstd. > > > > > Best regards > > > > Heinrich > > > > >+ func(SCSI, scsi, 0) > > >+ > > >+#define BOOT_TARGET_DEVICES(func) \ > > >+ BOOT_TARGET_SCSI(func) > > >+ > > >+#include > > >+ > > >+#endif > > > > > > #ifndef __CONFIG_H > > > #define __CONFIG_H > > Please can we use bootstd instead? > > You should just need to enable BOOTSTD_DEFAULTS and it will work. If not, > please let me know. > > Please also see the various improvements in[1] available at [2]. There is > also a > new video driver [2]. > > Regards, > Simon > > [1] > https://patchwork.o/ > zlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D351440&data=05%7C01 > %7Cthomas.mittelstaedt%40de.bosch.com%7Ca52180ee6e8f4087da4d08db4b306 > 953%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C6381864435151553 > 78%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yjqyizWXqb > YZmSuzfvqq4EfYvJYqXUf6irbLYhLo4qk%3D&reserved=0 > [2] > https://source.denx/ > .de%2Fu-boot%2Fcustodians%2Fu-boot-dm%2F-%2Ftree%2Fbryc- > working&data=05%7C01%7Cthomas.mittelstaedt%40de.bosch.com%7Ca52180ee > 6e8f4087da4d08db4b306953%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C > 0%7C638186443515155378%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA > wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C > %7C&sdata=5OF%2Bmc%2FVOSFFTzLp3JLrWBxvuZCfqwQDb3GzDZGlvws%3 > D&reserved=0 > [3] > https://patchwork.o/ > zlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D352929&data=05%7C01 > %7Cthomas.mittelstaedt%40de.bosch.com%7Ca52180ee6e8f4087da4d08db4b306 > 953%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C638186443
[PATCH v1 0/2] arm64: Fix building failure for Xen target
This patch series is for building Xen target with Clang. The first patch is to fix building failure for Xen target, the second patch is to add info for a linkage known issue when use Clang as compiler. Leo Yan (2): arm64: Remove duplicated symbols doc: Add info for building Xen target with Clang .../include/asm/boot0-linux-kernel-header.h | 2 -- doc/build/clang.rst | 36 +++ 2 files changed, 36 insertions(+), 2 deletions(-) -- 2.39.2
[PATCH v1 1/2] arm64: Remove duplicated symbols
When build U-boot with clang with using commands: $ make HOSTCC=clang xenguest_arm64_defconfig $ make HOSTCC=clang CROSS_COMPILE=aarch64-linux-gnu- \ CC="clang -target aarch64-linux-gnueabi" -j8 The compiler reports error: /tmp/start-acdf31.s:330:1: error: symbol '_start' is already defined _start: ^ Because the symbol '_start' has been defined twice, one is defined in arch/arm/cpu/armv8/start.S, another is defined in the header boot0-linux-kernel-header.h. To fix building failure, this patch removes the symbol '_start' from boot0-linux-kernel-header.h. Signed-off-by: Leo Yan --- arch/arm/include/asm/boot0-linux-kernel-header.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/include/asm/boot0-linux-kernel-header.h b/arch/arm/include/asm/boot0-linux-kernel-header.h index c6cd76f32a..c930fea5fd 100644 --- a/arch/arm/include/asm/boot0-linux-kernel-header.h +++ b/arch/arm/include/asm/boot0-linux-kernel-header.h @@ -31,8 +31,6 @@ .long \sym\()_hi32 .endm -.globl _start -_start: /* * DO NOT MODIFY. Image header expected by Linux boot-loaders. */ -- 2.39.2
[PATCH v1 2/2] doc: Add info for building Xen target with Clang
When build Xen target with Clang, the linker reports failure. This patch adds the related info in the documentation as a known issue and gives details for how to dismiss the building failure with Clang. Signed-off-by: Leo Yan --- doc/build/clang.rst | 36 1 file changed, 36 insertions(+) diff --git a/doc/build/clang.rst b/doc/build/clang.rst index 1d35616eb5..cc265506c2 100644 --- a/doc/build/clang.rst +++ b/doc/build/clang.rst @@ -74,3 +74,39 @@ simplified with a simple wrapper script - saved as #!/bin/sh exec clang -target arm-freebsd-eabi --sysroot /usr/arm-freebsd "$@" + + +Known Issues + + +When build U-boot for `xenguest_arm64_defconfig` target, it reports linkage +error: + +.. code-block:: bash + +aarch64-linux-gnu-ld.bfd: drivers/xen/hypervisor.o: in function `do_hypervisor_callback': +/home/leoy/Dev2/u-boot/drivers/xen/hypervisor.c:188: undefined reference to `__aarch64_swp8_acq_rel' +aarch64-linux-gnu-ld.bfd: drivers/xen/hypervisor.o: in function `synch_test_and_set_bit': +/home/leoy/Dev2/u-boot/./arch/arm/include/asm/xen/system.h:40: undefined reference to `__aarch64_ldset1_acq_rel' +aarch64-linux-gnu-ld.bfd: drivers/xen/hypervisor.o: in function `synch_test_and_clear_bit': +/home/leoy/Dev2/u-boot/./arch/arm/include/asm/xen/system.h:28: undefined reference to `__aarch64_ldclr1_acq_rel' +aarch64-linux-gnu-ld.bfd: drivers/xen/hypervisor.o: in function `synch_test_and_set_bit': +/home/leoy/Dev2/u-boot/./arch/arm/include/asm/xen/system.h:40: undefined reference to `__aarch64_ldset1_acq_rel' +aarch64-linux-gnu-ld.bfd: drivers/xen/hypervisor.o: in function `synch_test_and_clear_bit': +/home/leoy/Dev2/u-boot/./arch/arm/include/asm/xen/system.h:28: undefined reference to `__aarch64_ldclr1_acq_rel' +aarch64-linux-gnu-ld.bfd: drivers/xen/events.o: in function `synch_test_and_clear_bit': +/home/leoy/Dev2/u-boot/./arch/arm/include/asm/xen/system.h:28: undefined reference to `__aarch64_ldclr1_acq_rel' +aarch64-linux-gnu-ld.bfd: drivers/xen/events.o: in function `synch_test_and_set_bit': +/home/leoy/Dev2/u-boot/./arch/arm/include/asm/xen/system.h:40: undefined reference to `__aarch64_ldset1_acq_rel' +aarch64-linux-gnu-ld.bfd: drivers/xen/gnttab.o: in function `gnttab_end_access': +/home/leoy/Dev2/u-boot/drivers/xen/gnttab.c:109: undefined reference to `__aarch64_cas2_acq_rel' +Segmentation fault + +To fix the failure, we need to append option `-mno-outline-atomics` in Clang +command to not generate local calls to out-of-line atomic operations: + +.. code-block:: bash + +make HOSTCC=clang xenguest_arm64_defconfig +make HOSTCC=clang CROSS_COMPILE=aarch64-linux-gnu- \ + CC="clang -target aarch64-linux-gnueabi -mno-outline-atomics" -j8 -- 2.39.2
Re: [PATCH] usb: ehci-mx6: replace regulator_set_enable with *_if_allowed
On 5/4/23 14:41, Marek Vasut wrote: On 5/4/23 10:12, Eugen Hristev wrote: On 5/4/23 00:52, Marek Vasut wrote: On 5/2/23 18:13, Tim Harvey wrote: On Mon, May 1, 2023 at 11:51 PM Eugen Hristev wrote: regulator_set_enable_if_allowed already handles cases when the regulator is already enabled, or already disabled, and does not treat these as errors. With this change, the driver can work correctly even if the regulator is already taken or already disabled by another consumer. Signed-off-by: Eugen Hristev --- Hi Tim, I have not tested this as I do not have a mx6 board. can you please try it ? Thanks, Eugen Eugen, This does resolve the issue that occurs after your refcount series [1]. However after thinking about this more and seeing Marek's responses this wasn't an issue of multiple consumers sharing the same regulator. Instead this particular issue was that the vbus regulator is getting enabled twice without being disabled. This kind of issues can be uncovered when we add the refcounter :) Yeah, and that's a good thing. The refcounter is much appreciated (am I repeating myself?) On one hand I am happy to uncover such bugs. However, this leads me to wonder, even without a refcount, even without my series, enabling a regulator that is already enabled should return -EALREADY I don't that so, you can have regulators which supply multiple things and which are claimed by multiple driver instances, at which point they will each enable the regulator (refcount++) and that shouldn't end up returning -EALREADY . Right ? That was my thought. And I was returning success if regulator was already enabled. Then Simon asked me to return error codes on each path (review on the v2 of the patches): https://marc.info/?l=u-boot&m=168012024923488&w=2 One such example is buck regulator supplying e.g. SD and eMMC Vcc . On the other hand, it appears it will take longer to get the refcount applied though. I think we need to sort out the fallout, but that's probably still fine.
Re: [PATCH] usb: ehci-mx6: replace regulator_set_enable with *_if_allowed
On 5/4/23 13:51, Eugen Hristev wrote: On 5/4/23 14:41, Marek Vasut wrote: On 5/4/23 10:12, Eugen Hristev wrote: On 5/4/23 00:52, Marek Vasut wrote: On 5/2/23 18:13, Tim Harvey wrote: On Mon, May 1, 2023 at 11:51 PM Eugen Hristev wrote: regulator_set_enable_if_allowed already handles cases when the regulator is already enabled, or already disabled, and does not treat these as errors. With this change, the driver can work correctly even if the regulator is already taken or already disabled by another consumer. Signed-off-by: Eugen Hristev --- Hi Tim, I have not tested this as I do not have a mx6 board. can you please try it ? Thanks, Eugen Eugen, This does resolve the issue that occurs after your refcount series [1]. However after thinking about this more and seeing Marek's responses this wasn't an issue of multiple consumers sharing the same regulator. Instead this particular issue was that the vbus regulator is getting enabled twice without being disabled. This kind of issues can be uncovered when we add the refcounter :) Yeah, and that's a good thing. The refcounter is much appreciated (am I repeating myself?) On one hand I am happy to uncover such bugs. However, this leads me to wonder, even without a refcount, even without my series, enabling a regulator that is already enabled should return -EALREADY I don't that so, you can have regulators which supply multiple things and which are claimed by multiple driver instances, at which point they will each enable the regulator (refcount++) and that shouldn't end up returning -EALREADY . Right ? That was my thought. And I was returning success if regulator was already enabled. Then Simon asked me to return error codes on each path (review on the v2 of the patches): https://marc.info/?l=u-boot&m=168012024923488&w=2 I would argue the regulator API should behave the same way as Linux one, to avoid confusing people developing on both. Simon ?
Re: [PATCH] dt/bindings: fwu-mdata-mtd: drop changes outside FWU
hi Ilias, On Thu, 4 May 2023 at 16:15, Ilias Apalodimas wrote: > > Hi Rob, > > On Wed, May 03, 2023 at 12:24:39PM -0500, Rob Herring wrote: > > On Wed, May 3, 2023 at 9:37 AM Ilias Apalodimas > > wrote: > > > > > > Hi Krzysztof, > > > > > > On Tue, Apr 11, 2023 at 07:38:11AM +0200, Krzysztof Kozlowski wrote: > > > > On 11/04/2023 01:21, jaswinder.si...@linaro.org wrote: > > > > > From: Jassi Brar > > > > > > > > > > Any requirement of FWU should not require changes to bindings > > > > > of other subsystems. For example, for mtd-backed storage we > > > > > can do without requiring 'fixed-partitions' children to also > > > > > carry 'uuid', a property which is non-standard and not in the > > > > > bindings. > > > > > > > > > > There exists no code yet, so we can change the fwu-mtd bindings > > > > > to contain all properties within the fwu-mdata node. > > > > > > > > > > Signed-off-by: Jassi Brar > > > > > --- > > > > > > > > > > Hi Rob, Hi Krzysztof, > > > > > > > > > > I was suggested, and I agree, it would be a good idea to get your > > > > > blessings > > > > > for the location and meta-data (fwu-mdata) bindings for the FWU. > > > > > > > > > > The FWU images can be located in GPT partitions or MTD backed > > > > > storage. > > > > > The basic bindings for fwu-mdata has already been merged in uboot > > > > > (ideally they > > > > > too should have had your review). Now I am trying to fully support > > > > > MTD backed > > > > > storage and hence looking for your review. The proposed bindings are > > > > > totally > > > > > self-contained and don't require changes to any other subsystem. > > > > > > > > > > Thanks. > > > > > > > > I think we do not review U-Boot bindings usually, except these put in > > > > the Linux kernel. There were few targeting U-Boot specifically (e.g. > > > > Documentation/devicetree/bindings/mtd/partitions/u-boot.yaml and > > > > Documentation/devicetree/bindings/nvmem/u-boot,env.yaml) so if you want > > > > our blessing, the bindings should be done in Linux kernel repo. > > > > > > > > I am pretty sure that reviewing other project bindings would be too much > > > > of work for me. > > > > > > Sure that makes sense. But an answer here of whether the bindings make > > > sense to the DT maintainers or not would help to move forward. > > > > I have lots of comments on the bindings, but I'm missing what is the > > problem to solve. Yes, it's 'A/B firmware updates', but what > > configuration data do you need, why and when do you need it. IOW, give > > me enough information to understand why a binding is designed the way > > it is and be able to propose alternatives. > > Thanks for taking the time on this. I do have questions for Jassi as > well, but let me describe what I have in mind first. What we are trying > to do here is standardize how EFI compliant devices (and in extent > SystemReady-IR) > can reliably perform firmware updates adding capabilities like rollback, brick > protection etc. > > The high level description of how this is done is described here [0]. > The really short version of that document is that you: > - Perform a capsule update of the non active partition > - Reboot to that partition and launch your OS > - If the OS approves the updates (which is implementation defined), then > you install an empty capsule indicating the acceptance of the update > - If the device for any reason reboots for X amounts of times and the > acceptance capsule is not found, it will revert to the primary partition. > - If the acceptance capsule is found the device permanently switches over > to the new firmware, bumping any rollback counters it might have (that's > optional). > - All these information along with UUIDs for the storage medium and the > image types are stored in the metadata [1], which also has a backup > location. > > What you fundamentally need to perform an A/B booting is a first stage boot > loader (or a masked ROM) that can understand the metadata described here > [1]. > > Ideally we would only require the DT to describe where we can find that > metadata -- but the reality is a bit different. Currently we only support > of 2 types of devices > - metadata lives in a GPT partition > - They are located in an specific offset on a SPI-NOR > > GPT based devices are straightforward. As you noticed we only need the > phandle > of the device. There is a defined UUID for the metadata, so we discover > them along with the backup partition. > > The MTD case is a bit more complicated. The metadata format only > defines GUIDs for > - UUID identifying the image type (image type GUID) > - the UUID of the storage volume where the image is located > > Since we now don't have a UUID of the storage volume where the image is > located, we somehow need to map the image UUID to a device offset. I think > this is what Jassi is trying to define here -- it's worth noting that this > has to happen for all non-GPT devices. > > As for when the data is needed, sinc
Re: [PATCH] dt/bindings: fwu-mdata-mtd: drop changes outside FWU
[...] > > > I'm assuming it's per partition type rather than storage medium (e.g. > > > SATA, USB, SD, NAND, SPI-NOR)? GPT, 'fixed-partitions', other DT > > > partition bindings, etc. If so, then I'm really wondering why it's a > > > standalone tree rather than integrated into those existing partition > > > bindings. > > > > I think it's per medium, unless I misunderstood something. Sughosh? > > The bindings would be required as per the metadata access mechanism. > So for example, the MTD bindings would suffice for all the storage > mediums which would have MTD based partitioning schemes. Same for all > GPT partitioned devices. Again, as for the need for a separate node > with the compatible property, it is as per the driver model design. > For the other properties, we can indeed have them integrated with the > corresponding partition bindings. Ok, Rob is correct then it really is per partition type. Thanks /Ilias > > -sughosh
[PATCH] dm: core: of_access: fix return value in of_property_match_string
of_property_match_string calls of_find_property to search for the
string property.
If the device node does not exist, of_find_property returns NULL, and
of_property_match_string returns -EINVAL, which is correct.
However, if the device node exists, but the property is not found,
of_find_property still returns NULL, but it will place -FDT_ERR_NOTFOUND
in the *lenp variable.
of_property_match_string does not use the lenp parameter, thus this error
case is being lost, and treated as if the node is NULL, and returns
-EINVAL, which is incorrect.
The callers of of_property_match_string treat the error differently if
the return value is -EINVAL or -ENOENT, e.g. in dwc3 driver:
ret = generic_phy_get_by_name(dev, "usb3-phy", &phy);
if (!ret) {
ret = generic_phy_init(&phy);
if (ret)
return ret;
} else if (ret != -ENOENT && ret != -ENODATA) {
debug("could not get phy (err %d)\n", ret);
return ret;
} else {
phy.dev = NULL;
}
So the caller drivers will just consider the property missing if -ENOENT
is returned, versus the case of -EINVAL, which means something else.
To fix this situation, changed the code to call the of_find_property
with the right third argument to catch this error code and treat it
accordingly.
Signed-off-by: Eugen Hristev
---
drivers/core/of_access.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/core/of_access.c b/drivers/core/of_access.c
index 81a307992c01..57f10445b122 100644
--- a/drivers/core/of_access.c
+++ b/drivers/core/of_access.c
@@ -593,11 +593,14 @@ int of_read_u64(const struct device_node *np, const char
*propname, u64 *outp)
int of_property_match_string(const struct device_node *np, const char
*propname,
const char *string)
{
- const struct property *prop = of_find_property(np, propname, NULL);
+ int len = 0;
+ const struct property *prop = of_find_property(np, propname, &len);
size_t l;
int i;
const char *p, *end;
+ if (!prop && len == -FDT_ERR_NOTFOUND)
+ return -ENOENT;
if (!prop)
return -EINVAL;
if (!prop->value)
--
2.34.1
[PATCH 1/2] kbuild: add dtc as dependency on .dtb files
[Linux commit b8fc5b2157b1]
If dtc is rebuilt, we should rebuild .dtb files with the new dtc.
[Import notes: Back then there was no .dtbo rule in Linux's
Makefile.lib, but the current .dtbo rules in Linux also have the
$(DTC) dependency, so also add it to our .dtbo rule.]
Signed-off-by: Rasmus Villemoes
---
scripts/Makefile.lib | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 7b27224b5d..651d700369 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -331,7 +331,7 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
; \
sed "s:$(pre-tmp):$(<):" $(depfile).pre.tmp $(depfile).dtc.tmp >
$(depfile)
-$(obj)/%.dtb: $(src)/%.dts FORCE
+$(obj)/%.dtb: $(src)/%.dts $(DTC) FORCE
$(call if_changed_dep,dtc)
pre-tmp = $(subst $(comma),_,$(dot-target).pre.tmp)
@@ -351,7 +351,7 @@ cmd_dtco = mkdir -p $(dir ${dtc-tmp}) ; \
-d $(depfile).dtc.tmp $(dtc-tmp) ; \
cat $(depfile).pre.tmp $(depfile).dtc.tmp > $(depfile)
-$(obj)/%.dtbo: $(src)/%.dts FORCE
+$(obj)/%.dtbo: $(src)/%.dts $(DTC) FORCE
$(call if_changed_dep,dtco)
# Fonts
--
2.37.2
[PATCH 2/2] kbuild: Allow DTB overlays to built from .dtso named source files
[Linux commit 363547d2191c]
Currently DTB Overlays (.dtbo) are build from source files with the same
extension (.dts) as the base DTs (.dtb). This may become confusing and
even lead to wrong results. For example, a composite DTB (created from a
base DTB and a set of overlays) might have the same name as one of the
overlays that create it.
Different files should be generated from differently named sources.
.dtb <-> .dts
.dtbo <-> .dtso
We do not remove the ability to compile DTBO files from .dts files here,
only add a new rule allowing the .dtso file name. The current .dts named
overlays can be renamed with time. After all have been renamed we can
remove the other rule.
[Import notes: Adapt to U-Boot by using the cmd_dtco function instead
of cmd_dtc just like the current .dts -> .dtbo rule.]
Signed-off-by: Rasmus Villemoes
---
scripts/Makefile.lib | 3 +++
1 file changed, 3 insertions(+)
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 651d700369..7362a392ad 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -354,6 +354,9 @@ cmd_dtco = mkdir -p $(dir ${dtc-tmp}) ; \
$(obj)/%.dtbo: $(src)/%.dts $(DTC) FORCE
$(call if_changed_dep,dtco)
+$(obj)/%.dtbo: $(src)/%.dtso $(DTC) FORCE
+ $(call if_changed_dep,dtco)
+
# Fonts
# ---
--
2.37.2
Re: [PATCH] scripts/Makefile.lib: also consider $(CONFIG_SYS_BOARD)-u-boot.dtsi
On 03/05/2023 16.54, Tom Rini wrote: > On Wed, May 03, 2023 at 09:51:58AM -0400, Tom Rini wrote: >> On Mon, May 01, 2023 at 10:49:22AM +0200, Rasmus Villemoes wrote: >>> On 27/04/2023 19.31, Tom Rini wrote: > > Well, I'm not sure there's a use case for building all of the extra > device trees. I think what I'll do right now is fire off a CI run (or a > few, in the event of problems) where we just use the logic of > 3609e1dc5f4d and see what falls down. So this gets us a few failures. You can see them on https://source.denx.de/u-boot/u-boot/-/jobs/618127 but one type of failure seems to be the case where CONFIG_DEFAULT_DEVICE_TREE isn't contained in CONFIG_OF_LIST (ls1088aqds_tfa for example) and the other case is where CONFIG_OF_LIST != CONFIG_SPL_OF_LIST and this fails because fdtgrep runs NOT on spl/arch/.../foo.dtb but rather arch/.../foo.dtb and so we don't have the dtb file around. >>> >>> Hm, the former sounds like a bug in the defconfig, the second sounds >>> like a legit use case (or why would we have SPL_OF_LIST). Anyway, both >>> should be fixable by just changing the logic of scripts/Makefile.dts a >>> little; say add the union of DEFAULT_DEVICE_TREE, OF_LIST and >>> SPL_OF_LIST to dtb-y. Something like >>> >>> diff --git a/scripts/Makefile.dts b/scripts/Makefile.dts >>> index 2561025da8..5e2429c617 100644 >>> --- a/scripts/Makefile.dts >>> +++ b/scripts/Makefile.dts >>> @@ -1,3 +1,3 @@ >>> # SPDX-License-Identifier: GPL-2.0+ >>> >>> -dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_$(SPL_)OF_LIST))) >>> +dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) >>> $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST))) >> >> OK, lemme see what happens now. Assuming this is enough, please post as >> a proper patch, thanks! > > The one last problem now is on stm32mp15_dhcor_basic which is a > defconfig missing one from OF_LIST but including it in the its file, so > the above is the patch we need. > Hm, well, for now I think at least all .dtbo targets need to be left in the Makefiles, since nothing in the defconfig tells us to build those. Maybe the CI build will complete because missing those dtbos will just be seen as random missing binary blobs, but it's something that needs to be thought of. There's no CONFIG knob to mention the required dtbos, and adding them to OF_LIST doesn't work because those are without the .dtb suffix (we add that in Makefile.dts). But maybe we can just leave the dtbos in the Makefile (perhaps per SOC or whatever) - they are explicitly _not_ built with the special U-Boot .dtb rule, so doesn't depend on config options and don't have magic .dtsi files included. There's anyway so few of them so far that it'd still be a massive win to trim the Makefiles of the .dtb rules. I just sent two Makefile.lib patches related to the dtb/dtbo logic, but they are not strictly required for sorting this out. But I do think we should do the .dts->.dtso renames sooner rather than later. Rasmus
Re: atmel_sdhci: SDMMC_CD pin still needed for card detection despite EMMC set to non-removable
On 5/1/23 15:21, Zixun Li wrote:
Hi,
Can you find some place to set this bit in the atmel sdhci driver, and not in
the core?
The MC1R register is specific to at91 device.
I've overridden get_cd of the driver, below is the patch:
From e186af71297e9ae6ce241a85bff64683949f0e1b Mon Sep 17 00:00:00 2001
From: Zixun LI
Date: Mon, 1 May 2023 14:02:21 +0200
Subject: [PATCH] atmel_sdhci: Force card-detect if MMC_CAP_NONREMOVABLE.
Signed-off-by: Zixun LI
---
drivers/mmc/atmel_sdhci.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/drivers/mmc/atmel_sdhci.c b/drivers/mmc/atmel_sdhci.c
index 37b0beeed4..fa32055d1f 100644
--- a/drivers/mmc/atmel_sdhci.c
+++ b/drivers/mmc/atmel_sdhci.c
@@ -15,6 +15,9 @@
#define ATMEL_SDHC_MIN_FREQ40
#define ATMEL_SDHC_GCK_RATE24000
+#define ATMEL_SDHC_MC1R 0x204
+#define ATMEL_SDHC_MC1R_FCD0x80
+
#ifndef CONFIG_DM_MMC
int atmel_sdhci_init(void *regbase, u32 id)
{
@@ -59,8 +62,42 @@ static int atmel_sdhci_deferred_probe(struct sdhci_host
*host)
return sdhci_probe(dev);
}
+static int atmel_sdhci_get_cd(struct sdhci_host *host)
+{
+ struct mmc *mmc = host->mmc;
+ int value;
If you use readb to store things into 'value', you should use a single
byte type and not int.
+
+ /* If nonremovable, assume that the card is always present. */
+ if (mmc->cfg->host_caps & MMC_CAP_NONREMOVABLE)
+ {
+ value = sdhci_readb(host, ATMEL_SDHC_MC1R);
+ sdhci_writeb(host, ATMEL_SDHC_MC1R_FCD | value,
ATMEL_SDHC_MC1R);
Can't we do this in a different place?
When we parse the DT for example. If the card is non-removable, this is
described as a property in the DT.
In this way you don't have to recreate all the below code from the
common sdhci_get_cd, and you avoid rewriting the MC1R every time the
get_cd is called.
Eugen
+ return 1;
+ }
+ /* If polling, assume that the card is always present. */
+ if (mmc->cfg->host_caps & MMC_CAP_NEEDS_POLL)
+ return 1;
+
+#if CONFIG_IS_ENABLED(DM_GPIO)
+ value = dm_gpio_get_value(&host->cd_gpio);
+ if (value >= 0) {
+ if (mmc->cfg->host_caps & MMC_CAP_CD_ACTIVE_HIGH)
+ return !value;
+ else
+ return value;
+ }
+#endif
+ value = !!(sdhci_readl(host, SDHCI_PRESENT_STATE) &
+ SDHCI_CARD_PRESENT);
+ if (mmc->cfg->host_caps & MMC_CAP_CD_ACTIVE_HIGH)
+ return !value;
+ else
+ return value;
+}
+
static const struct sdhci_ops atmel_sdhci_ops = {
.deferred_probe = atmel_sdhci_deferred_probe,
+ .get_cd = atmel_sdhci_get_cd,
};
static int atmel_sdhci_probe(struct udevice *dev)
--
2.40.1
Re: [PATCH 2/2] CI: Make use of buildman requirements.txt
On Thu, May 04, 2023 at 09:42:54AM +0530, Neha Malcom Francis wrote: > Hi Tom, > > On 03/05/23 18:34, Tom Rini wrote: > > On Wed, May 03, 2023 at 11:27:20AM +0530, Neha Malcom Francis wrote: > > > Hi Tom > > > > > > Thanks for these patches! > > > > > > On 27/04/23 01:14, Tom Rini wrote: > > > > Now that buildman has a requirements.txt file we need to make use of it. > > > > > > > > Signed-off-by: Tom Rini > > > > --- > > > >.azure-pipelines.yml | 3 +++ > > > >.gitlab-ci.yml | 4 > > > >2 files changed, 7 insertions(+) > > > > > > > > > > However, while trying to ensure CI/CD coverage, I'm running into this " > > > error 'No module named 'jsonschema'" for am62ax [1], any idea why after > > > building successfully for other devices? > > > > > > > > > [1] > > > https://dev.azure.com/u-boot/u-boot/_build/results?buildId=6236&view=logs&jobId=6fe7c803-7a3b-5b46-f057-c1c62fd89ba1&j=22dc4ac5-ae35-5978-08ac-5f386151834e&t=fae48c67-4bb5-5f06-119f-00d23f780e3c > > o > > > > We need to have the requirements.txt file installed in any job that's > > using this part of binman now and I guess my patch above wasn't > > complete? I didn't fully check what happened on Azure due to the other > > problems (ie iot2050 boards not building). > > > > Probably, I'm not sure about how to rectify this. Could you have a look if > possible? Regarding iot2050, I have started working on it. I see it now. The "script" section at the bottom of .azure-pipelines.yml needs the pip install as well, I had missed that. Go ahead and take that up with your reposting of the series :) -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 01/16] mtrr: Don't show an invalid CPU number
On Mon, Mar 27, 2023 at 12:16 PM Simon Glass wrote: > > When U-Boot did not do the MP init, we don't get an actual CPU number > here. Skip printing it in that case. > > Signed-off-by: Simon Glass > --- > > (no changes since v2) > > Changes in v2: > - Don't show an invalid CPU number on error > > cmd/x86/mtrr.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v3 02/16] x86: Adjust search range for sysinfo table
On Mon, Mar 27, 2023 at 12:16 PM Simon Glass wrote: > > Avoid searching starting at 0 since this memory may not be available, > e.g. if protection against NULL-pointer access is enabled. The table > cannot be there anyway, since the first 1KB of memory was originally > used for the interrupt table and coreboot avoids it. > > Start at 0x400 instead. > > Signed-off-by: Simon Glass > --- > > (no changes since v2) > > Changes in v2: > - Update commit message with more detail > - Update code comment to mention that addresses <1KB are ignored > > arch/x86/cpu/cpu.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v3 04/16] acpi: Create a new Kconfig for ACPI
On Mon, Mar 27, 2023 at 12:16 PM Simon Glass wrote: > > We have several Kconfig options for ACPI, but all relate to specific > functions, such as generating tables and AML code. > > Add a new option which controls including basic ACPI library code, > including the lib/acpi directory. This will allow us to add functions > which are available even if table generation is not supported. > > Adjust the command to avoid a build error when ACPIGEN is not enabled. > > Signed-off-by: Simon Glass > --- > > Changes in v3: > - Don't enable ACPI by default except on x86 and sandbox > > Changes in v2: > - Add new patch to create a new Kconfig for ACPI > > arch/Kconfig | 2 ++ > cmd/Kconfig | 2 +- > cmd/acpi.c | 4 > drivers/core/Kconfig | 1 + > lib/Kconfig | 10 +- > lib/Makefile | 2 +- > lib/acpi/Makefile| 4 > 7 files changed, 22 insertions(+), 3 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v3 05/16] acpi: Move the table-finding functions into the libary
On Mon, Mar 27, 2023 at 12:16 PM Simon Glass wrote: > > This is useful for other features. Move the function into library code > so it can be used outside just the 'acpi' command. > > Signed-off-by: Simon Glass > --- > > Changes in v3: > - Avoid a build error with the ASL compiler > > Changes in v2: > - Add new patch to move acpi-table-finding functions into the library > > cmd/acpi.c| 40 +- > include/acpi/acpi_table.h | 8 +++ > lib/acpi/Makefile | 2 ++ > lib/acpi/acpi.c | 45 +++ > 4 files changed, 56 insertions(+), 39 deletions(-) > create mode 100644 lib/acpi/acpi.c > Reviewed-by: Bin Meng
Re: [PATCH v3 03/16] input: Flush the keyboard buffer before resetting it
On Mon, Mar 27, 2023 at 12:16 PM Simon Glass wrote: > > If U-Boot is not the first-stage bootloader the keyboard may already be > set up. Make sure to flush any data before trying to reset it. This > avoids a long timeout / hang. > > Add some comments and a log category while we are here. > > Signed-off-by: Simon Glass > --- > > (no changes since v2) > > Changes in v2: > - Flush the buffer instead of skipping the reset > > drivers/input/i8042.c | 19 +++ > 1 file changed, 19 insertions(+) > Reviewed-by: Bin Meng
Re: [PATCH v3 07/16] x86: Allow locating the UART from ACPI tables
On Mon, Mar 27, 2023 at 12:16 PM Simon Glass wrote: > > When coreboot does not pass a UART in its sysinfo struct, there is no > easy way to find it out. > > Since coreboot does not actually init the serial device when serial is > disabled, it is not possible to make it add this information to the > sysinfo table. > > Add a way to obtain this information from the DBG2 ACPI table, which is > normally set up by coreboot. > > For now this only supports a memory-mapped 16550-style UART. > > Signed-off-by: Simon Glass > --- > > Changes in v3: > - Disable for coreboot64 since ACPI is not available > > Changes in v2: > - Add new patch to allow locating the UART from ACPI tables > > drivers/serial/Kconfig | 10 +++ > drivers/serial/serial_coreboot.c | 114 --- > 2 files changed, 116 insertions(+), 8 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v3 08/16] pci: coreboot: Don't read regions when booting
On Sun, Apr 2, 2023 at 6:52 PM Christian Gmeiner
wrote:
>
> >
> > When U-Boot is the second-stage bootloader, PCI is already set up. We
> > cannot read the regions from the device tree. There is no point anyway,
> > since PCI devices have already been allocated according to the regions
> > and it is not safe for U-Boot to make any changes.
> >
> > Signed-off-by: Simon Glass
> > Reviewed-by: Bin Meng
>
> Tested-by: Christian Gmeiner
>
> This fixes a regression that got introduced with f2ebaaa9f3 ("pci:
> Handle failed calloc in decode_regions()")
>
> For more details see:
> https://lore.kernel.org/all/20220519164830.3934669-1-pt...@google.com/T/#m9f89006c3cd36fd0b4f3856e92328ea39206898c
>
Fixes: f2ebaaa9f38d ("pci: Handle failed calloc in decode_regions()")
Re: [PATCH v3 09/16] x86: coreboot: Use a memory-mapped UART
On Mon, Mar 27, 2023 at 12:16 PM Simon Glass wrote: > > This is much more common on modern hardware, so default to using it. > > This does not affect the normal UART, but does allow the debug UART to > work, since it uses serial_out_shift(), etc. > > Signed-off-by: Simon Glass > --- > > (no changes since v2) > > Changes in v2: > - Expand commit message to explain this is for the debug UART > - Update the defconfig instead > > configs/coreboot64_defconfig | 1 - > configs/coreboot_defconfig | 1 - > 2 files changed, 2 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v3 14/16] x86: nvme: coreboot: Enable NVMe
On Thu, May 4, 2023 at 9:18 PM Bin Meng wrote: > > Hi Simon, > > On Mon, Mar 27, 2023 at 12:17 PM Simon Glass wrote: > > > > Enable support for NVMe storage devices. Update the driver to enable the > > bus master bit, since coreboot does not do that automatically. > > > > Signed-off-by: Simon Glass > > --- > > > > (no changes since v2) > > > > Changes in v2: > > - Drop patch 'usb: Quieten a debug message' since it was fixed elsewhere > > - Drop patch 'x86: coreboot: Use a memory-mapped UART' (not needed) > > > > configs/coreboot_defconfig | 3 +++ > > drivers/nvme/nvme_pci.c| 8 The nvme_pci change should go in a separate patch > > 2 files changed, 11 insertions(+) > > Regards, Bin
Re: [PATCH v3 14/16] x86: nvme: coreboot: Enable NVMe
Hi Simon,
On Mon, Mar 27, 2023 at 12:17 PM Simon Glass wrote:
>
> Enable support for NVMe storage devices. Update the driver to enable the
> bus master bit, since coreboot does not do that automatically.
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v2)
>
> Changes in v2:
> - Drop patch 'usb: Quieten a debug message' since it was fixed elsewhere
> - Drop patch 'x86: coreboot: Use a memory-mapped UART' (not needed)
>
> configs/coreboot_defconfig | 3 +++
> drivers/nvme/nvme_pci.c| 8
> 2 files changed, 11 insertions(+)
>
> diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig
> index 3030e5bf93b4..8bb744e6e84d 100644
> --- a/configs/coreboot_defconfig
> +++ b/configs/coreboot_defconfig
> @@ -59,6 +59,9 @@ CONFIG_SYS_ATA_ALT_OFFSET=0
> CONFIG_ATAPI=y
> CONFIG_LBA48=y
> CONFIG_SYS_64BIT_LBA=y
> +CONFIG_MISC=y
> +CONFIG_NVMEM=y
The above 2 options seem not necessary when enabling NVMe, no?
> +CONFIG_NVME_PCI=y
> # CONFIG_PCI_PNP is not set
> CONFIG_SOUND=y
> CONFIG_SOUND_I8254=y
> diff --git a/drivers/nvme/nvme_pci.c b/drivers/nvme/nvme_pci.c
> index 36bf9c5ffb73..dff19317943c 100644
> --- a/drivers/nvme/nvme_pci.c
> +++ b/drivers/nvme/nvme_pci.c
> @@ -6,6 +6,7 @@
>
> #include
> #include
> +#include
> #include
> #include "nvme.h"
>
> @@ -30,6 +31,13 @@ static int nvme_probe(struct udevice *udev)
> ndev->instance = trailing_strtol(udev->name);
> ndev->bar = dm_pci_map_bar(udev, PCI_BASE_ADDRESS_0, 0, 0,
>PCI_REGION_TYPE, PCI_REGION_MEM);
> +
> + if (!ll_boot_init()) {
I believe we can drop the ll_boot_init() check, and enable
bus-mastering unconditionally as this is done by every PCI device
driver.
> + /* Turn on bus-mastering */
> + dm_pci_clrset_config16(udev, PCI_COMMAND, 0,
> + PCI_COMMAND_MASTER);
> + }
> +
> return nvme_init(udev);
> }
>
Regards,
Bin
Re: [PATCH v3 06/16] x86: coreboot: Collect the address of the ACPI tables
On Mon, Mar 27, 2023 at 12:16 PM Simon Glass wrote: > > At present any ACPI tables created by prior-stage firmware are ignored. > It is useful to be able to view these in U-Boot. > > Pick this up from the sysinfo tables and display it with the cbsysinfo > command. This allows the 'acpi list' command to work when booting from > coreboot. > > Adjust the global_data condition so that acpi_start is available even if > table-generation is disabled. > > Signed-off-by: Simon Glass > > --- > > (no changes since v2) > > Changes in v2: > - Use tab instead of space in header file > - Refactor two patches into one > > arch/x86/include/asm/cb_sysinfo.h | 2 ++ > arch/x86/include/asm/coreboot_tables.h | 2 ++ > arch/x86/lib/coreboot/cb_sysinfo.c | 11 +++ > cmd/x86/cbsysinfo.c| 1 + > include/asm-generic/global_data.h | 4 ++-- > 5 files changed, 18 insertions(+), 2 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v3 15/16] coreboot: Enable ms command
On Mon, Mar 27, 2023 at 12:17 PM Simon Glass wrote: > > This is useful when looking for tables in memory. Enable it for coreboot. > > Signed-off-by: Simon Glass > --- > > (no changes since v2) > > Changes in v2: > - Add new patch to enable ms command > > configs/coreboot_defconfig | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Bin Meng
Re: [PATCH v3 16/16] x86: Allow locating UARTs by device ID
Hi Simon, On Mon, Mar 27, 2023 at 12:17 PM Simon Glass wrote: > > When coreboot does not pass a UART in its sysinfo struct, there is no > easy way to find it out. Add a way to specify known UARTs so we can > find them without needing help from coreboot. > > Since coreboot does not actually init the serial device when serial is > disabled, it is not possible to make it add this information to the > sysinfo table. > > Also, we cannot use the class information, since we don't know which > UART is being used. For example, with Alder Lake there are two: > > 00.16.00 0x8086 0x51e0 Simple comm. controller 0x80 > 00.1e.00 0x8086 0x51a8 Simple comm. controller 0x80 > > In our case the second one is the right one, but thre is no way to > distinguish it from the first one without using the device ID. > > If we have Adler Lake hardware which uses a different UART, we could > perhaps look at the ACPI tables, or the machine information passed in > the SMBIOS tables. > > This was discussed previously before: [1] > > [1] > https://patchwork.ozlabs.org/project/uboot/patch/20210407163159.3.I967ea8c85e009f870c7aa944372d32c990f1b14a@changeid/ > > Signed-off-by: Simon Glass > --- > > (no changes since v2) > > Changes in v2: > - Move this patch to last in the series, so it can be dropped if needed Since now we can parse the DBG2 ACPI table to get the UART info, I'd rather not apply this patch. > > arch/x86/dts/coreboot.dts| 4 > drivers/serial/serial_coreboot.c | 41 > include/pci_ids.h| 3 +++ > 3 files changed, 48 insertions(+) > Regards, Bin
Re: [PATCH] configs: j7200: correct mmc offset
On Thu, May 04, 2023 at 11:47:51AM +0530, Kumar, Udit wrote: > > On 5/3/2023 8:15 PM, Nishanth Menon wrote: > > On 10:58-20230503, Udit Kumar wrote: > > > This patch corrects the MMC raw mode sector offset as > > > per documentation. > > > > > > https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-j7200/08_06_00_11/exports/docs/j7200/linux/Foundational_Components/U-Boot/UG-Memory.html > > > > > > Section: eMMC layout > > Please drop these TI specific documentation. Instead ADD documentation > > into u-boot source explaining these eMMC layout. > > Sure, > > will arch/arm/mach-k3/j7200/ place will be good to hold such documentation ? No, it should be under doc/board/ti/ in rST and follows doc/develop/docstyle.rst -- Tom signature.asc Description: PGP signature
Pull Request / Patch: Enable Usage of ECC with DDR on AM654x
Hello, Recently, when working with the AM65x_GP_EVM development board, I found that the U-boot source code (specifically the SPL), does not properly initialize the DDRSS ram drivers for the AM6548. There are missing register writes that are required from DDR to function with ECC on. I validated this by comparing what U-boot source code does to Texas Instrument DDR test scripts (known as GEL scripts), and these GEL scripts could properly initialize DDR with ECC while U-boot could not, this is due to the missing register writes. The changes are shown here in this pull request: https://github.com/u-boot/u-boot/pull/289 (made just to check CI). Should I submit a patch for this? I have not contributed to U-boot before and would like to know if such a change would be accepted, or even reviewed, as a submission. Thanks, Ben
[PATCH v3 1/3] X86: Add support for SCSI devices
From: Thomas Mittelstaedt U-Boot at VirtualBox must load Linux and boot configuration from disk devices. Here the discs at AHCI (scsi) bus are used to load the need boot data. Signed-off-by: Thomas Mittelstaedt --- configs/efi-x86_payload64_defconfig | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/configs/efi-x86_payload64_defconfig b/configs/efi-x86_payload64_defconfig index 5cde04a5ac..30a7f31dac 100644 --- a/configs/efi-x86_payload64_defconfig +++ b/configs/efi-x86_payload64_defconfig @@ -7,11 +7,11 @@ CONFIG_VENDOR_EFI=y CONFIG_TARGET_EFI_PAYLOAD=y CONFIG_FIT=y CONFIG_FIT_SIGNATURE=y +CONFIG_LEGACY_IMAGE_FORMAT=y CONFIG_SHOW_BOOT_PROGRESS=y CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro" CONFIG_USE_BOOTCOMMAND=y -CONFIG_BOOTCOMMAND="ext2load scsi 0:3 0100 /boot/vmlinuz; zboot 0100" CONFIG_PRE_CONSOLE_BUFFER=y CONFIG_SYS_CONSOLE_INFO_QUIET=y CONFIG_DISPLAY_BOARDINFO_LATE=y @@ -22,7 +22,6 @@ CONFIG_CMD_IDE=y CONFIG_CMD_MMC=y CONFIG_CMD_PART=y CONFIG_CMD_USB=y -# CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y CONFIG_BOOTP_BOOTFILESIZE=y # CONFIG_CMD_NFS is not set @@ -37,6 +36,9 @@ CONFIG_MAC_PARTITION=y CONFIG_ISO_PARTITION=y CONFIG_EFI_PARTITION=y CONFIG_ENV_OVERWRITE=y +CONFIG_ENV_IS_IN_FAT=y +CONFIG_ENV_FAT_INTERFACE="scsi" +CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_USE_BOOTFILE=y CONFIG_BOOTFILE="bzImage" -- 2.30.2
[PATCH v3 0/3] Enable U-Boot at Virtualbox to boot images
From: Thomas Mittelstaedt The changes are needed to get U-Boot to be started at VirtualBox images supporting distro boot capability (scripts and extlinux.conf). Atm the patch "pci: coreboot: Don't read regions when booting" from Simon Glass is not integrated yet. So AHCI and IDE devices are not handled correctly without this patch. (https://patchwork.ozlabs.org/project/uboot/patch/20230220194927.476708-8-...@chromium.org/) Changes since v2: - DISTROBOOT configuration replaced with BOOTSTD to get more flexibility Thomas Mittelstaedt (3): X86: Add support for SCSI devices X86: Add bootstd support X86: pxeboot: bugfix: Set variable for size of initrd boot/pxe_utils.c| 2 +- configs/efi-x86_payload64_defconfig | 7 +-- 2 files changed, 6 insertions(+), 3 deletions(-) -- 2.30.2
[PATCH v3 2/3] X86: Add bootstd support
From: Thomas Mittelstaedt Enable bootstd support for U-Boot at VirtualBox described at https://source.denx.de/u-boot/u-boot/-/blob/master/doc/develop/bootstd.rst This is used to boot system images at Virtualbox via - distroboot (extlinux.conf) - boot script Signed-off-by: Thomas Mittelstaedt --- configs/efi-x86_payload64_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/efi-x86_payload64_defconfig b/configs/efi-x86_payload64_defconfig index 30a7f31dac..9e517e742b 100644 --- a/configs/efi-x86_payload64_defconfig +++ b/configs/efi-x86_payload64_defconfig @@ -7,6 +7,7 @@ CONFIG_VENDOR_EFI=y CONFIG_TARGET_EFI_PAYLOAD=y CONFIG_FIT=y CONFIG_FIT_SIGNATURE=y +CONFIG_BOOTSTD_FULL=y CONFIG_LEGACY_IMAGE_FORMAT=y CONFIG_SHOW_BOOT_PROGRESS=y CONFIG_USE_BOOTARGS=y -- 2.30.2
[PATCH v3 3/3] X86: pxeboot: bugfix: Set variable for size of initrd
From: Thomas Mittelstaedt
The problem was, that zboot() didn't work because of missing
ramdisc size.
Signed-off-by: Thomas Mittelstaedt
---
boot/pxe_utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
index 3a1e50f2b1..87c32b6e62 100644
--- a/boot/pxe_utils.c
+++ b/boot/pxe_utils.c
@@ -554,7 +554,7 @@ static int label_boot(struct pxe_context *ctx, struct
pxe_label *label)
label->name);
goto cleanup;
}
-
+ strcpy(initrd_filesize, simple_xtoa(size));
initrd_addr_str = env_get("ramdisk_addr_r");
size = snprintf(initrd_str, sizeof(initrd_str), "%s:%lx",
initrd_addr_str, size);
--
2.30.2
Re: [PATCH] build_bug.h: Also define static_assert() when __CHECKER__ is defined
On Thu, May 04, 2023 at 06:15:13AM +, Christophe Leroy wrote: > > > Le 03/05/2023 à 22:02, Tom Rini a écrit : > > On Thu, Jan 26, 2023 at 07:17:48PM +0100, Christophe Leroy wrote: > > > >> When doing a build with C=2, the following failure is encountered on > >> several files: > >> > >> CHECK arch/powerpc/cpu/mpc8xxx/fsl_lbc.c > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c: note: in included file (through > >> arch/powerpc/include/asm/global_data.h, include/init.h): > >>include/asm-generic/global_data.h:494:21: error: Expected ) in function > >> declarator > >>include/asm-generic/global_data.h:494:21: error: got ( > >> > >> And because of the error, the interesting part which are the > >> warnings don't appear. This is because static_assert() is defined > >> only when __CHECKER__ is not defined. > >> > >> Add a stub when __CHECKER__ is defined. With that fix, the expected > >> warnings are now seen: > >> > >> CHECK arch/powerpc/cpu/mpc8xxx/fsl_lbc.c > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:32:27: warning: incorrect type in > >> argument 1 (different address spaces) > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:32:27:expected unsigned int > >> const volatile [noderef] *addr > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:32:27:got unsigned int * > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:32:45: warning: incorrect type in > >> argument 1 (different address spaces) > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:32:45:expected unsigned int > >> const volatile [noderef] *addr > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:32:45:got unsigned int * > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:35:24: warning: incorrect type in > >> argument 1 (different address spaces) > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:35:24:expected unsigned int > >> const volatile [noderef] *addr > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:35:24:got unsigned int * > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:35:40: warning: incorrect type in > >> argument 1 (different address spaces) > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:35:40:expected unsigned int > >> const volatile [noderef] *addr > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:35:40:got unsigned int * > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:67:17: warning: incorrect type in > >> argument 1 (different address spaces) > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:67:17:expected unsigned int > >> volatile [noderef] *addr > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:67:17:got unsigned int * > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:68:17: warning: incorrect type in > >> argument 1 (different address spaces) > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:68:17:expected unsigned int > >> volatile [noderef] *addr > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:68:17:got unsigned int * > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:72:17: warning: incorrect type in > >> argument 1 (different address spaces) > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:72:17:expected unsigned int > >> volatile [noderef] *addr > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:72:17:got unsigned int * > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:73:17: warning: incorrect type in > >> argument 1 (different address spaces) > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:73:17:expected unsigned int > >> volatile [noderef] *addr > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:73:17:got unsigned int * > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:78:9: warning: incorrect type in > >> argument 1 (different address spaces) > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:78:9:expected unsigned int > >> volatile [noderef] *addr > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:78:9:got unsigned int * > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:79:9: warning: incorrect type in > >> argument 1 (different address spaces) > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:79:9:expected unsigned int > >> volatile [noderef] *addr > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:79:9:got unsigned int * > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:131:22: warning: incorrect type in > >> argument 1 (different address spaces) > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:131:22:expected unsigned int > >> const volatile [noderef] *addr > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:131:22:got unsigned int * > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:132:49: warning: incorrect type in > >> argument 1 (different address spaces) > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:132:49:expected unsigned int > >> const volatile [noderef] *addr > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:132:49:got unsigned int * > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:144:26: warning: incorrect type in > >> argument 1 (different address spaces) > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:144:26:expected unsigned int > >> volatile [noderef] *addr > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:144:26:got unsigned int > >> [usertype] *mxmr > >>arch/powerpc/cpu/mpc8xxx/fsl_lbc.c:144:4
Re: [PATCH] dt/bindings: fwu-mdata-mtd: drop changes outside FWU
On Thu, 4 May 2023 at 07:08, Ilias Apalodimas wrote: > [...] > > > > > I'm assuming it's per partition type rather than storage medium (e.g. > > > > SATA, USB, SD, NAND, SPI-NOR)? GPT, 'fixed-partitions', other DT > > > > partition bindings, etc. If so, then I'm really wondering why it's a > > > > standalone tree rather than integrated into those existing partition > > > > bindings. > > > > > > I think it's per medium, unless I misunderstood something. Sughosh? > > > > The bindings would be required as per the metadata access mechanism. > > So for example, the MTD bindings would suffice for all the storage > > mediums which would have MTD based partitioning schemes. Same for all > > GPT partitioned devices. Again, as for the need for a separate node > > with the compatible property, it is as per the driver model design. > > For the other properties, we can indeed have them integrated with the > > corresponding partition bindings. > > Ok, Rob is correct then it really is per partition type. > Originally the fwu related properties were embedded into existing nodes. As Sughosh already explained, we need a compatible string, and hence a node, for the u-boot driver core to call probe(). I may be wrong, but I see having fwu properties contained within the fwu node is cleaner than having them embedded into existing bindings (potentially different classes in future). So I moved to the current design. cheers.
Re: [PATCH v2 01/18] dm: Emit the arch_cpu_init_dm() even only before relocation
On Tue, Apr 18, 2023 at 11:31 PM Simon Glass wrote:
>
> The original function was only called once, before relocation. The new
> one is called again after relocation. This was not the intend of the
intend => intent ?
> original call. Fix this by renaming and updating the calling logic.
>
> With this, chromebook_link64 makes it through SPL.
>
> Fixes: 7fe32b3442f ("event: Convert arch_cpu_init_dm() to")
Fixes: 7fe32b3442f0 ("event: Convert arch_cpu_init_dm() to use events")
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> arch/arm/mach-imx/imx8/cpu.c| 2 +-
> arch/arm/mach-imx/imx8m/soc.c | 2 +-
> arch/arm/mach-imx/imx8ulp/soc.c | 2 +-
> arch/arm/mach-imx/imx9/soc.c| 2 +-
> arch/arm/mach-omap2/am33xx/board.c | 2 +-
> arch/arm/mach-omap2/hwinit-common.c | 2 +-
> arch/mips/mach-pic32/cpu.c | 2 +-
> arch/nios2/cpu/cpu.c| 2 +-
> arch/riscv/cpu/cpu.c| 2 +-
> arch/x86/cpu/baytrail/cpu.c | 2 +-
> arch/x86/cpu/broadwell/cpu.c| 2 +-
> arch/x86/cpu/ivybridge/cpu.c| 2 +-
> arch/x86/cpu/quark/quark.c | 2 +-
> arch/x86/lib/fsp2/fsp_init.c| 2 +-
> doc/develop/event.rst | 6 +++---
> drivers/core/root.c | 4 ++--
> drivers/cpu/microblaze_cpu.c| 2 +-
> include/event.h | 2 +-
> 18 files changed, 21 insertions(+), 21 deletions(-)
>
Reviewed-by: Bin Meng
Re: [PATCH v2 02/18] binman: Support writing symbols for ucode etypes
On Tue, Apr 18, 2023 at 11:31 PM Simon Glass wrote: > > Allow symbol writing in these cases so that U-Boot can find the position > and size of U-Boot at runtime. > > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > tools/binman/etype/u_boot_spl_with_ucode_ptr.py | 2 +- > tools/binman/etype/u_boot_tpl_with_ucode_ptr.py | 2 +- > tools/binman/etype/u_boot_with_ucode_ptr.py | 4 ++-- > 3 files changed, 4 insertions(+), 4 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v2 03/18] sf: Guard against zero erasesize
On Tue, Apr 18, 2023 at 11:31 PM Simon Glass wrote: > > With tiny SPI flash the erasesize is 0 which can cause a divide-by-zero > error. Check for this and returns a proper error instead. > > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > drivers/mtd/spi/sf_probe.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > Reviewed-by: Bin Meng
Re: [PATCH v2 04/18] sf: Rename spi-nor-tiny functions
On Tue, Apr 18, 2023 at 11:31 PM Simon Glass wrote: > > The 'tiny' SPI nor functions have the same name as their big brothers, > which can be confusing. Use different names so it is clear which > version is in the image. > > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > drivers/mtd/spi/spi-nor-tiny.c | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v2 05/18] x86: ivybridge: Ensure LPC is available for GPIO base
On Tue, Apr 18, 2023 at 11:31 PM Simon Glass wrote: > > The bd82x6x_get_gpio_base() does not work if the LPC is not set up. > Probe it early to avoid this problem. > > In chromebook_link64 this propblem shows up as an inability to read typo: problem > the GPIO straps for the memory type. > > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > arch/x86/cpu/ivybridge/bd82x6x.c | 17 + > 1 file changed, 9 insertions(+), 8 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v2 06/18] x86: samus: Drop EFI_LOADER
On Tue, Apr 18, 2023 at 11:31 PM Simon Glass wrote: > > This adds a lot of code so that it cannot be build with the binary build => built > blobs. It is not used on this board. Drop it. > > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > configs/chromebook_samus_defconfig | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Bin Meng
Re: [PATCH v2 07/18] x86: Support debug UART in 64-bit mode
On Tue, Apr 18, 2023 at 11:31 PM Simon Glass wrote: > > The debug UART is already set up in SPL, so there is no need to do > anything here. We must provide the (empty) function though. > > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > arch/x86/cpu/x86_64/cpu.c | 7 +++ > 1 file changed, 7 insertions(+) > Reviewed-by: Bin Meng
Re: [PATCH v2 08/18] x86: Tidy up availability of string functions
On Tue, Apr 18, 2023 at 11:31 PM Simon Glass wrote: > > For now, just enable the fast-but-large string functions in 32-boot 32-bit > U-Boot proper only. Avoid using them in SPL. We cannot use then in 64-bit > builds since we only have 32-bit assembly. > > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > arch/x86/include/asm/string.h | 6 +- > arch/x86/lib/Makefile | 4 +++- > 2 files changed, 8 insertions(+), 2 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v2 09/18] x86: mrc: Correct SPL debug message
On Tue, Apr 18, 2023 at 11:31 PM Simon Glass wrote: > > SPL printf() does not normally support %#x so just use %x instead. Hex is > expected in U-Boot anyway. > > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > arch/x86/lib/mrccache.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Bin Meng
Re: [PATCH v2 10/18] x86: spl: Show debugging for BSS
Hi Simon,
On Tue, Apr 18, 2023 at 11:31 PM Simon Glass wrote:
>
> Show the area of memory cleared for BSS, when debugging is enabled.
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> arch/x86/lib/spl.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/lib/spl.c b/arch/x86/lib/spl.c
> index bdf57ef7b5bd..eb0af219ae29 100644
> --- a/arch/x86/lib/spl.c
> +++ b/arch/x86/lib/spl.c
> @@ -117,7 +117,9 @@ static int x86_spl_init(void)
> }
>
> #ifndef CONFIG_SYS_COREBOOT
> - memset(&__bss_start, 0, (ulong)&__bss_end - (ulong)&__bss_start);
> + debug("BSS clear from %lx to %lx len %lx\n", (ulong)&__bss_start,
> + (ulong)&__bss_end, (ulong)&__bss_end - (ulong)&__bss_start);
> + memset(&__bss_start, '\0', (ulong)&__bss_end - (ulong)&__bss_start);
There is no need to change this line.
> # ifndef CONFIG_TPL
>
> /* TODO(s...@chromium.org): Consider calling cpu_init_r() here */
Regards,
Bin
Re: [PATCH v2 13/18] x86: Return mtrr_add_request() to its old purpose
Hi Simon,
On Tue, Apr 18, 2023 at 11:31 PM Simon Glass wrote:
>
> This function used to be for adding a list of requests to be actioned on
> relocation. Revert it back to this purpose, to avoid problems with boards
> which need control of their MTRRs (i.e. those which don't use FSP).
>
> The mtrr_set_next_var() function is available when the next free
> variable-MTRR must be set, so this can be used instead.
>
> Signed-off-by: Simon Glass
> Fixes: 3a5823978ff ("x86: mtrr: Skip MSRs that were already programmed..")
> Fixes: 44aed2f0322 ("x86: mtrr: Do not clear the unused ones..")
The above 2 commit ids are invalid ...
> ---
>
> (no changes since v1)
>
> arch/x86/cpu/mtrr.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
Regards,
Bin
Re: [PATCH v2 14/18] x86: spl: Avoid using init_cache_f_r() from SPL
On Tue, Apr 18, 2023 at 11:31 PM Simon Glass wrote: > > This function is used by U-Boot proper. It does not set up MTRRs when SPL > is enabled, but we do want this done when it is called from SPL. In fact > it is confusing to use the same function from SPL, since there are require > a few conditions there. since there are a few conditions required there ? > > All init_cache_f_r() really does is commit the MTRRs and set up the cache. > Do this in the SPL's version of this function instead. > > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > arch/x86/lib/spl.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > Reviewed-by: Bin Meng
Re: [PATCH v2 15/18] spl: Commit MTRRs only in board_init_f_r()
Hi Simon,
On Tue, Apr 18, 2023 at 11:31 PM Simon Glass wrote:
>
> We don't need to commit the SPI-flash MTRR change immediately, since it is
> now done in the board_init_f_r(). Also this causes chromebook_link64 to
> hang.
Could you add more details as to why this causes chromebook_link64 to hang?
As I see the mtrr_commit() has been there since TPL was introduced on
day 1, there must be some other places changes that caused the
regression on chromebook_link64??
>
> Drop the extra mtrr_commit() in the SPL implementation.
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> arch/x86/lib/spl.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/x86/lib/spl.c b/arch/x86/lib/spl.c
> index 388b51086410..f0b74d04252a 100644
> --- a/arch/x86/lib/spl.c
> +++ b/arch/x86/lib/spl.c
> @@ -147,7 +147,6 @@ static int x86_spl_init(void)
> debug("%s: SPI cache setup failed (err=%d)\n", __func__, ret);
> return ret;
> }
> - mtrr_commit(true);
> # else
> ret = syscon_get_by_driver_data(X86_SYSCON_PUNIT, &punit);
> if (ret)
> --
Regards,
Bin
Re: [PATCH v2 12/18] x86: Tidy up address for loading U-Boot from SPL
On Tue, Apr 18, 2023 at 11:31 PM Simon Glass wrote: > > Use the binman symbols for this, to avoid hard-coding the value. We could > use CONFIG_X86_OFFSET_U_BOOT for the address, but it seems better to > obtain the offset and size through the same mechanism. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Add new patch to tidy up address for loading U-Boot from SPL > > arch/x86/lib/spl.c | 13 +++-- > 1 file changed, 3 insertions(+), 10 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v2 16/18] x86: Simplify cpu_jump_to_64bit_uboot()
On Tue, Apr 18, 2023 at 11:31 PM Simon Glass wrote: > > This copies the cpu_call64() function to memory address and then jumps to > it. This seems to work correctly even when call from SPL, which is call => called > running from SPI flash. > > Drop the copy as it is not needed. > > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > arch/x86/cpu/i386/cpu.c | 32 +--- > 1 file changed, 5 insertions(+), 27 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v2 17/18] x86: samus: Don't include audio and SATA in TPL
On Tue, Apr 18, 2023 at 11:31 PM Simon Glass wrote: > > These are not used in TPL so disable the drivers to save space. > > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > arch/x86/cpu/broadwell/Makefile | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v2 18/18] x86: samus: Adjust TPL start and pre-reloc memory size
On Tue, Apr 18, 2023 at 11:31 PM Simon Glass wrote: > > Move the TPL up a little to make room for the refcode binary blob. Also > increase the pre-relocation memory to make space for recent additions. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Drop patch "x86: Add on to existing MTRRs in SPL" > - Add various patches to resolve problems with chromebook_link64 > > configs/chromebook_samus_tpl_defconfig | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v4 1/3] net: ipv6: Add support for default gateway discovery.
On Sat, 22 Apr 2023 at 03:08, wrote:
>
> From: Ehsan Mohandesi
Hello, Ehsan! Good patch, but one little change is needed.
> +struct icmp6_ra_prefix_info {
> + u8 type; /* Type is 3 for Prefix Information. */
> + u8 len;/* Len is 4 for Prefix Information. */
> + /* The number of leading bits in the Prefix that are valid. */
> + u8 prefix_len;
> + u8 reserved1:6,/* MUST be ignored by the receiver. */
> + aac:1, /* autonomous address-configuration flag */
> + /* Indicates that this prefix can be used for on-link determination.
> */
> + on_link:1;
> + /*
> +* The length of time in seconds that the prefix is valid for the
> +* purpose of on-link determination.
> +*/
> + __be32 valid_lifetime;
> + /* The length of time addresses remain preferred. */
> + __be32 preferred_lifetime;
> + __be32 reserved2; /* MUST be ignored by the receiver. */
> + /*
> +* Prefix is an IP address or a prefix of an IP address. The Prefix
> +* Length field contains the number of valid leading bits in the
> prefix.
> +* The bits in the prefix after the prefix length are reserved and
> MUST
> +* be initialized to zero by the sender and ignored by the receiver.
> +*/
> + struct in6_addr prefix;
> +};
Here it should end with:
} __packed;
Because this structure may be placed at a badly aligned offset within
a packet. For example, at offset 0x46 within Ethernet packet.
Other than that:
Tested-by: Sergei Antonov
Reviewed-by: Sergei Antonov
Re: [PATCH v2 11/18] x86: Set up LPC only after relocation
Hi Simon,
On Tue, Apr 18, 2023 at 11:31 PM Simon Glass wrote:
>
> Probing LPC can cause PCI enumeration to take place, which significantly
> increases pre-relocation memory usage. Also, LPC is somtimes enabled
typo: sometimes
> directly by SPL.
>
> Adjust the logic to probe the LPC only after relocation. This allows
> chromebook_link64 to start up without a much larger
> CONFIG_SYS_MALLOC_F_LEN value.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2:
> - Add new patch to set up LPC only after relocation
>
> drivers/sysreset/sysreset_x86.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
This patch should be squashed to patch #5 ("x86: ivybridge: Ensure LPC
is available for GPIO base ")
Regards,
Bin
Re: [EXTERNAL] [PATCH 00/10] Add AM62x LP SK support
Hi Tom, TI has one SDK release per SoC. If we go this way we will have to release multiple SDK release for each board. It doesn't seem feasible to release different SDK based on same SoC as we have other boards based on AM62x SoC which we planning to add upstream support in future. In past, we followed similar for jacinto platforms. The Xilinx way you have mentioned won't work for TI as Xilinx has only one platform for upstream support. I can evm.c changes to different files under board detection macro "CONFIG_TI_I2C_BOARD_DETECT" in different file to keep board code clean and easy to follow. Regards, Nitin On 4/26/2023 3:08 PM, Nitin Yadav wrote: > This series adds support of AM62x LP SK. The AM62x LP SK > board is similar to AM62x SK but has some significant changes > that requires different set of device tree at each stage > of bootloader. > > First 5 patches add support and sync device tree with linus > master. Next 3 patches perform board detection and select > correct dtb based on board ID. The last 2 patches enable > config to support for building multiple dtb. > > Nitin Yadav (10): > arm: dts: Makefile: Add AM62x LP SK device tree > arm: dts: Add support for AM62x LP SK > arm: dts: Sync DT to add support of AM62x LP SK > arm: dts: Add support for AM62x LP SK at R5 SPL stage > arm: dts: k3-am625-generic: Add generic DT for pre R5 SPL > board: ti: am62x: am62x_env: Update env to select correct dtb > arm: mach-k3: am625_init: Update board specific API name to K3 generic > API's > board: ti: am62x: Add support for detecting multiple device trees > configs: am62x_lpsk_a53_defconfig: Enable support for building > multiple dtbs into FIT > configs: am62x_evm_r5_defconfig: Enable support for building multiple > dtbs at R5 SPL > > arch/arm/dts/Makefile |7 +- > arch/arm/dts/k3-am62-lp-sk-u-boot.dtsi|7 + > arch/arm/dts/k3-am62-lp-sk.dts| 232 ++ > arch/arm/dts/k3-am62-main.dtsi| 368 ++- > arch/arm/dts/k3-am62-r5-lp-sk.dts | 12 + > arch/arm/dts/k3-am625-generic.dts | 70 + > arch/arm/dts/k3-am625-sk-u-boot.dtsi |8 + > arch/arm/dts/k3-am625-sk.dts |5 +- > arch/arm/dts/k3-am62x-ddr-lp4-50-800-800.dtsi | 2190 + > arch/arm/dts/k3-am62x-r5-sk-common.dtsi | 86 + > arch/arm/dts/k3-am62x-sk-common-u-boot.dtsi | 194 ++ > arch/arm/dts/k3-am62x-sk-common.dtsi | 430 > arch/arm/mach-k3/am625_init.c | 34 +- > arch/arm/mach-k3/include/mach/sys_proto.h |1 + > board/ti/am62x/am62x.env |4 + > board/ti/am62x/evm.c | 159 ++ > configs/am62x_evm_a53_defconfig | 10 + > configs/am62x_evm_r5_defconfig|8 +- > 18 files changed, 3783 insertions(+), 42 deletions(-) > create mode 100644 arch/arm/dts/k3-am62-lp-sk-u-boot.dtsi > create mode 100644 arch/arm/dts/k3-am62-lp-sk.dts > create mode 100644 arch/arm/dts/k3-am62-r5-lp-sk.dts > create mode 100644 arch/arm/dts/k3-am625-generic.dts > create mode 100644 arch/arm/dts/k3-am62x-ddr-lp4-50-800-800.dtsi > create mode 100644 arch/arm/dts/k3-am62x-r5-sk-common.dtsi > create mode 100644 arch/arm/dts/k3-am62x-sk-common-u-boot.dtsi > create mode 100644 arch/arm/dts/k3-am62x-sk-common.dtsi >
Re: [PATCH v4 1/3] net: ipv6: Add support for default gateway discovery.
On Sat, 22 Apr 2023 at 03:08, wrote:
> + if (prefix->on_link && ntohl(prefix->valid_lifetime))
> {
> + net_prefix_length = prefix->prefix_len;
> + net_gateway6 = ip6->saddr;
> + return 0;
Is it OK that prefix->prefix_len is used, but prefix->prefix is not?
Just curious.
Re: [PATCH] dt/bindings: fwu-mdata-mtd: drop changes outside FWU
On Thu, May 4, 2023 at 9:01 AM Jassi Brar wrote: > > On Thu, 4 May 2023 at 07:08, Ilias Apalodimas > wrote: > > [...] > > > > > > > I'm assuming it's per partition type rather than storage medium (e.g. > > > > > SATA, USB, SD, NAND, SPI-NOR)? GPT, 'fixed-partitions', other DT > > > > > partition bindings, etc. If so, then I'm really wondering why it's a > > > > > standalone tree rather than integrated into those existing partition > > > > > bindings. > > > > > > > > I think it's per medium, unless I misunderstood something. Sughosh? > > > > > > The bindings would be required as per the metadata access mechanism. > > > So for example, the MTD bindings would suffice for all the storage > > > mediums which would have MTD based partitioning schemes. Same for all > > > GPT partitioned devices. Again, as for the need for a separate node > > > with the compatible property, it is as per the driver model design. > > > For the other properties, we can indeed have them integrated with the > > > corresponding partition bindings. > > > > Ok, Rob is correct then it really is per partition type. > > > Originally the fwu related properties were embedded into existing nodes. > > As Sughosh already explained, we need a compatible string, and hence a > node, for the u-boot driver core to call probe(). DT's purpose is not OS driver instantiation. DT cannot cater to a client's evolving driver structure. > I may be wrong, but I see having fwu properties contained within the > fwu node is cleaner than having them embedded into existing bindings > (potentially different classes in future). So I moved to the current > design. Having all the information related to a device/node in one place is cleaner IMO. As I said, if u-boot wants private interfaces between the DT and itself, then fine, but that should remain private and be stripped by u-boot. A separate node would certainly be easier for doing that. Rob
Re: [PATCH] dt/bindings: fwu-mdata-mtd: drop changes outside FWU
On Thu, 4 May 2023 at 10:19, Rob Herring wrote: > On Thu, May 4, 2023 at 9:01 AM Jassi Brar wrote: > > > I may be wrong, but I see having fwu properties contained within the > > fwu node is cleaner than having them embedded into existing bindings > > (potentially different classes in future). So I moved to the current > > design. > > Having all the information related to a device/node in one place is cleaner > IMO. > > As I said, if u-boot wants private interfaces between the DT and > itself, then fine, but that should remain private and be stripped by > u-boot. A separate node would certainly be easier for doing that. > Seems we are on the same page(?). Current implementation does exactly that -- we have a separate fwu node containing all the properties it needs. thanks.
Re: [PATCH 1/2] arm: dts: k3-j721e: ddr: Update to 0.9.1 version of DDR config tool
Hi Neha! On April 25, 2023 thus sayeth Neha Malcom Francis: > Update the DDR settings to those generated using 0.9.1 version of > Jacinto 7 DDRSS Register Configuration tool. > > Signed-off-by: Neha Malcom Francis > --- > arch/arm/dts/k3-j721e-ddr-evm-lp4-4266.dtsi | 149 ++-- > 1 file changed, 75 insertions(+), 74 deletions(-) > I'm thinking these are stable enough ;) Reviewed-by: Bryan Brattlof ~Bryan
Re: [PATCH 2/2] arm: dts: k3-j7200: ddr: Update to 0.6 version of DDR config tool
Hi Neha! On April 25, 2023 thus sayeth Neha Malcom Francis: > Update the DDR settings to those generated using 0.6 version of > Jacinto 7 DDRSS Register Configuration tool. > > Signed-off-by: Neha Malcom Francis > --- > arch/arm/dts/k3-j7200-ddr-evm-lp4-2666.dtsi | 120 ++-- > 1 file changed, 60 insertions(+), 60 deletions(-) > Reviewed-by: Bryan Brattlof ~Bryan
RE: atmel_sdhci: SDMMC_CD pin still needed for card detection despite EMMC set to non-removable
> Can't we do this in a different place?
> When we parse the DT for example. If the card is non-removable, this is
> described as a property in the DT.
> In this way you don't have to recreate all the below code from the common
> sdhci_get_cd, and you avoid rewriting the MC1R every time the get_cd is
> called.
The problem is inside sdhci_init() there is a sdhci_reset(), FCD bit will lost
if we set it too early.
Then I've looked at the kernel driver, setting this bit is also a workaround of
SAMA5D2 series, who doesn't drive CMD if using CD GPIO line.
https://github.com/linux4sam/linux-at91/blob/068eaa6b4b087b3a86fc4624d0f4083844e93f1c/drivers/mmc/host/sdhci-of-at91.c#L551
I've refactored the code, setting FCD bit after sdhci_probe() with a separate
function to make the purpose more clear.
From 90177e7af8226b88dfbfc08639f768881562a3a2 Mon Sep 17 00:00:00 2001
From: Zixun LI
Date: Thu, 4 May 2023 16:30:41 +0200
Subject: [PATCH] atmel_sdhci: Force card-detect if MMC_CAP_NONREMOVABLE.
---
drivers/mmc/atmel_sdhci.c | 40 +--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/atmel_sdhci.c b/drivers/mmc/atmel_sdhci.c
index 37b0beeed4..ae56266f57 100644
--- a/drivers/mmc/atmel_sdhci.c
+++ b/drivers/mmc/atmel_sdhci.c
@@ -15,6 +15,9 @@
#define ATMEL_SDHC_MIN_FREQ40
#define ATMEL_SDHC_GCK_RATE24000
+#define ATMEL_SDHC_MC1R 0x204
+#define ATMEL_SDHC_MC1R_FCD0x80
+
#ifndef CONFIG_DM_MMC
int atmel_sdhci_init(void *regbase, u32 id)
{
@@ -52,11 +55,38 @@ struct atmel_sdhci_plat {
struct mmc mmc;
};
+static void atmel_sdhci_config_fcd(struct sdhci_host *host)
+{
+ u8 mc1r;
+
+ /* If nonremovable, assume that the card is always present.
+*
+* WA: SAMA5D2 doesn't drive CMD if using CD GPIO line.
+*/
+ if ((host->mmc->cfg->host_caps & MMC_CAP_NONREMOVABLE)
+#if CONFIG_IS_ENABLED(DM_GPIO)
+ || dm_gpio_get_value(&host->cd_gpio) >= 0
+#endif
+ )
+ {
+ sdhci_readb(host, ATMEL_SDHC_MC1R);
+ mc1r |= ATMEL_SDHC_MC1R_FCD;
+ sdhci_writeb(host, mc1r, ATMEL_SDHC_MC1R);
+ }
+}
+
static int atmel_sdhci_deferred_probe(struct sdhci_host *host)
{
struct udevice *dev = host->mmc->dev;
+ int ret;
- return sdhci_probe(dev);
+ ret = sdhci_probe(dev);
+ if (ret)
+ return ret;
+
+ atmel_sdhci_config_fcd(host);
+
+ return 0;
}
static const struct sdhci_ops atmel_sdhci_ops = {
@@ -120,7 +150,13 @@ static int atmel_sdhci_probe(struct udevice *dev)
clk_free(&clk);
- return sdhci_probe(dev);
+ ret = sdhci_probe(dev);
+ if (ret)
+ return ret;
+
+ atmel_sdhci_config_fcd(host);
+
+ return 0;
}
static int atmel_sdhci_bind(struct udevice *dev)
--
2.40.1
Re: Pull request efi-2023-07-rc2
On Thu, May 04, 2023 at 01:16:02PM +0200, Heinrich Schuchardt wrote: > Dear Tom, > > The following changes since commit 2440719d258a97824395532cb4a775752b423f63: > > Merge tag 'u-boot-imx-20230503' of > https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2023-05-03 13:15:12 > -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-efi.git > tags/efi-2023-07-rc2 > > for you to fetch changes up to 8a6414d1e410ab65780a4c5eb99e79e5b9bc21c1: > > CI: treat documentation warnings as errors (2023-05-04 11:15:12 +0200) > > Gitlab CI showed no issues: > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/16241 > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 4/4] test: bdinfo: Add test for command bdinfo
On Sat, Apr 22, 2023 at 03:01:34PM +0200, Marek Vasut wrote: > Add test for command bdinfo . > > Signed-off-by: Marek Vasut > Reviewed-by: Simon Glass > --- > Cc: Jason Liu > Cc: Michal Simek > Cc: Ovidiu Panait > Cc: Simon Glass > --- > include/test/suites.h | 1 + > test/cmd/Makefile | 1 + > test/cmd/bdinfo.c | 179 ++ > test/cmd_ut.c | 6 ++ > 4 files changed, 187 insertions(+) > create mode 100644 test/cmd/bdinfo.c This breaks building on "snow" which does not set CFG_SYS_SDRAM_SIZE seemingly. -- Tom signature.asc Description: PGP signature
Re: [PATCH] scripts/Makefile.dts: tweak logic for deciding which dtbs to build
On Thu, May 04, 2023 at 01:33:08PM +0200, Rasmus Villemoes wrote: > The idea in 3609e1dc5f4d (dts: automatically build necessary .dtb > files) was fine, but the implementation was suboptimal due to some > misunderstandings on my part (and possibly defects in some defconfig > files): > > - Sometimes DEFAULT_DEVICE_TREE is not included in OF_LIST or > SPL_OF_LIST > > - SPL_OF_LIST is not always a subset of OF_LIST > > - While SPL_OF_LIST governs the list of dtbs relevant to SPL (i.e., > may be built into an > SPL-with-bunch-of-dtbs-to-choose-between-at-runtime), those dtbs are > not actually _built_ during the SPL build phase, i.e. when $(SPL_) > would expand to SPL_. fdtgrep runs on the artifacts produced during > the ordinary U-Boot build. > > Tweak the logic so that we simply add the union of all dtbs mentioned > in either DEFAULT_DEVICE_TREE, OF_LIST and SPL_OF_LIST to dtb-y. That > should, for real, ensure that we always build all the dtbs that is > relevant to the current board, and should in turn enable us to > massively simplify arch/*/dts/Makefile. > > Signed-off-by: Rasmus Villemoes Tested-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH] boot/Kconfig: fix comments syntax error
On Mon, Apr 24, 2023 at 04:51:12PM -0400, Hugo Villeneuve wrote: > From: Hugo Villeneuve > > Fix comments syntax error in SPL_LOAD_FIT_APPLY_OVERLAY description. > > Signed-off-by: Hugo Villeneuve > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
