March 2023 - U-Boot

[PATCH 1/1] efi_loader: correct shortening of device-paths
by Heinrich Schuchardt 27 Mar '23

27 Mar '23

We use short device-paths in boot options so that a file on a block device can be found independent of the port into which the device is plugged. Usb() device-path nodes only contain port and interface information and therefore cannot identify a block device. UsbWwi() device-path nodes contain the serial number of USB devices. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- include/efi_api.h | 1 + lib/efi_loader/efi_device_path.c | 21 ++++++--------------- 2 files changed, 7 insertions(+), 15 deletions(-) diff --git a/include/efi_api.h b/include/efi_api.h index c4512eeb86..dc6e5ce236 100644 --- a/include/efi_api.h +++ b/include/efi_api.h @@ -604,6 +604,7 @@ struct efi_device_path_acpi_path { # define DEVICE_PATH_SUB_TYPE_MSG_MAC_ADDR 0x0b # define DEVICE_PATH_SUB_TYPE_MSG_UART 0x0e # define DEVICE_PATH_SUB_TYPE_MSG_USB_CLASS 0x0f +# define DEVICE_PATH_SUB_TYPE_MSG_USB_WWI 0x10 # define DEVICE_PATH_SUB_TYPE_MSG_SATA 0x12 # define DEVICE_PATH_SUB_TYPE_MSG_NVME 0x17 # define DEVICE_PATH_SUB_TYPE_MSG_URI 0x18 diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c index 288baa1ca7..9ed5e6273d 100644 --- a/lib/efi_loader/efi_device_path.c +++ b/lib/efi_loader/efi_device_path.c @@ -92,17 +92,13 @@ int efi_dp_match(const struct efi_device_path *a, /** * efi_dp_shorten() - shorten device-path * - * We can have device paths that start with a USB WWID or a USB Class node, - * and a few other cases which don't encode the full device path with bus - * hierarchy: + * When creating a short boot option we want to use a device-path that is + * independent of the location where the block device is plugged in. * - * * MESSAGING:USB_WWID - * * MESSAGING:USB_CLASS - * * MEDIA:FILE_PATH - * * MEDIA:HARD_DRIVE - * * MESSAGING:URI + * UsbWwi() nodes contain a serial number, hard drive paths a partition + * UUID. Both should be unique. * - * See UEFI spec (section 3.1.2, about short-form device-paths) + * See UEFI spec, section 3.1.2 for "short-form device path". * * @dp: original device-path * @Return: shortened device-path or NULL @@ -110,12 +106,7 @@ int efi_dp_match(const struct efi_device_path *a, struct efi_device_path *efi_dp_shorten(struct efi_device_path *dp) { while (dp) { - /* - * TODO: Add MESSAGING:USB_WWID and MESSAGING:URI.. - * in practice fallback.efi just uses MEDIA:HARD_DRIVE - * so not sure when we would see these other cases. - */ - if (EFI_DP_TYPE(dp, MESSAGING_DEVICE, MSG_USB) || + if (EFI_DP_TYPE(dp, MESSAGING_DEVICE, MSG_USB_WWI) || EFI_DP_TYPE(dp, MEDIA_DEVICE, HARD_DRIVE_PATH) || EFI_DP_TYPE(dp, MEDIA_DEVICE, FILE_PATH)) return dp; -- 2.39.2

3 3

[PATCH v2 0/3] Add StarFive JH7110 PCIe drvier support
by Minda Chen 27 Mar '23

27 Mar '23

This patchset needs to apply after patchset in [1]. These PCIe series patches are based on the JH7110 RISC-V SoC and VisionFive V2 board. [1] https://patchwork.ozlabs.org/project/uboot/cover/20230303032432.7837-1-yanh… The PCIe driver depends on gpio, pinctrl, clk and reset driver to do init. The PCIe dts configuation includes all these setting. The PCIe drivers codes has been tested on the VisionFive V2 boards. The test devices includes M.2 NVMe SSD and Realtek 8169 Ethernet adapter. previous patch version v1: https://patchwork.ozlabs.org/project/uboot/cover/20230223105240.15180-1-min… changes v1->v2 1. remove clock commit. The pcie clocks change has been includeded in [1]. 2. Using GENMASK marco1 in patch1. 3. remove the syscon dts node in patch3. The syscon dts dts node has been included in [1]. --- The JH7110 minimal system patchset upstream is in progress. PCIe driver patches is based on this patchset. The JH7110 minimal system patchset details are listed in [1]. For more JH7110 and visionFive v2 information and support, you can visit RVspace wiki[2]. [2] https://wiki.rvspace.org/ Mason Huo (3): starfive: pci: Add StarFive JH7110 pcie driver configs: starfive-jh7110: Add support for PCIe host driver riscv: dts: starfive: Enable PCIe host controller .../dts/jh7110-starfive-visionfive-2.dtsi | 99 ++++ arch/riscv/dts/jh7110.dtsi | 75 +++ configs/starfive_visionfive2_defconfig | 9 + drivers/pci/Kconfig | 11 + drivers/pci/Makefile | 1 + drivers/pci/pcie_starfive_jh7110.c | 478 ++++++++++++++++++ 6 files changed, 673 insertions(+) create mode 100644 drivers/pci/pcie_starfive_jh7110.c base-commit: b0eda49bc9b00503366f2ec431be0178caf9e9b5 prerequisite-patch-id: a84452ba131408ff842b65ae19a3a05f64b3ff60 prerequisite-patch-id: bb320a2102f46d2b2d08b4467cbcdb92050767b8 prerequisite-patch-id: ef5e9d61f7392c7d2e5321aa8a10996ca8eae5fc prerequisite-patch-id: 26dfdb401d680ecd9449acf09131cf4790e987b7 prerequisite-patch-id: a0cfa5d8cdb49bbe9d4739afa90991f882950881 prerequisite-patch-id: a0509f01172e24b3d163f4701496b0349435bdc0 prerequisite-patch-id: d834ece14ffb525b8c3e661e78736692f33fca9b prerequisite-patch-id: aa95c1c047d0b7dae469586873a42932d613411d prerequisite-patch-id: ebc26ed3f97f7babc0fc805152acb578f5eff922 prerequisite-patch-id: 81a83d6fc1e71ce190f9151577deb0c5cd382a20 prerequisite-patch-id: ff5bd799e4cb905fef6cf1cd0ce757980e1d34b7 prerequisite-patch-id: a341d4e8a8e25cb711309123939235fcb3c10c1a prerequisite-patch-id: 749e4eafb431857ee2bec4ac8e78a682f6a57588 prerequisite-patch-id: 04cd7779c7464c7be683cd2718baee8c6554791d prerequisite-patch-id: 25cb7c602018ec89abce43d8835926ac3356f5db prerequisite-patch-id: cf1af96990b01e1025ec50d0b49c79f92f64f352 prerequisite-patch-id: cc5878da5f03e7e1d2c15e88537fd2a93bf47e53 -- 2.17.1

3 15

DM SPI flash improvements
by Tony Dinh 27 Mar '23

27 Mar '23

Hi Simon, I'm investigating a problem with the Thecus N2350 board that has SPI flash on controller 1, but not on controller 0. Booting with SPI SPL is not possible with CONFIG_SF_DEFAULT_BUS=1. Reference: https://lists.denx.de/pipermail/u-boot/2023-March/511517.html That led me to the drivers/mtd/spi/sf-uclass.c and drivers/spi/spi-uclass.c. And I found there are some problems in the spi_flash_probe(), as well as _spi_get_bus_and_cs(). But seeing your comment in the spi_flash_probe function header, I'm thinking perhaps I should not try to fix them. /* * TODO(sjg(a)chromium.org): This is an old-style function. We should remove * it when all SPI flash drivers use dm */ struct spi_flash *spi_flash_probe(unsigned int busnum, unsigned int cs, unsigned int max_hz, unsigned int spi_mode) Could you or Jagan clarify the TODO above meaning? Are we fully in DM SPI yet? If we are, should this be replaced with other means to probe the SPI bus? Or it should have been automatically probed by DM SPI infrastructure, and we just need to tag the SPI 1 DTS node with boot-phase? If that's the case then perhaps this function should be defined out with some configs wrapping. My current SPI configs: CONFIG_SPL_DM_SPI=y CONFIG_SPL_DM_SPI_FLASH=y # CONFIG_DM_HWSPINLOCK is not set CONFIG_DM_SPI_FLASH=y CONFIG_DM_SPI=y CONFIG_SF_DEFAULT_SPEED=50000000 CONFIG_SF_DEFAULT_MODE=0x0 # CONFIG_CMD_SF_TEST is not set CONFIG_SF_DEFAULT_BUS=1 CONFIG_SF_DEFAULT_CS=0 Thanks, Tony

2 2

Default value for bootcmd not defined
by Stefan Nagy 27 Mar '23

27 Mar '23

Hello, I followed the official documentation [1] to build U-Boot for my Rock Pi 4, instead of evb-rk3399_defconfig I used the config file for my board (rock-pi-4-rk3399_defconfig). After I flashed the single boot image to an SD card and put it in I got stuck with the error message: "distro_bootcmd" not defined. Since I have no idea of U-Boot it took me some time to find out that all I needed was to set a different default value for bootcmd. Now I use CONFIG_BOOTCOMMAND="bootflow scan" and it boots my OS as expected. The official documentation looks straightforward for simple users like me, so I thought it might not be intended that the default value for the bootcmd entry is (still) distro_bootcmd. Regards, Stefan. [1] https://u-boot.readthedocs.io/en/latest/board/rockchip/rockchip.html -- E-Mails signieren & verschlüsseln · https://emailselfdefense.fsf.org/de/

2 1

[PATCH 1/1] doc: describe skipping triggering a pipeline in Gitlab
by Heinrich Schuchardt 27 Mar '23

27 Mar '23

'git push -o ci.skip' can be used to push to Gitlab without triggering a pipeline. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- doc/develop/ci_testing.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/doc/develop/ci_testing.rst b/doc/develop/ci_testing.rst index b9a9a516c1..d8690f2cd2 100644 --- a/doc/develop/ci_testing.rst +++ b/doc/develop/ci_testing.rst @@ -50,6 +50,12 @@ runners you are able to provide. While it is intended to be able to run this pipeline on the free public instances provided at https://gitlab.com/ a problem with our squashfs tests currently prevents this. +To push to Gitlab without triggering a pipeline use: + +.. code-block:: bash + + git push -o ci.skip + Docker container ---------------- -- 2.39.2

2 1

[PATCH 1/1] scsi: typo supporedt
by Heinrich Schuchardt 27 Mar '23

27 Mar '23

%s/supporedt/supported/ Fixes: edca8cf72130 ("Convert CONFIG_SCSI_AHCI_PLAT et al to Kconfig") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- drivers/scsi/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index ad484ce8e8..a8014129d3 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -26,7 +26,7 @@ config SCSI_AHCI_PLAT This is deprecated. An AHCI driver should be provided instead. config SYS_SCSI_MAX_SCSI_ID - int "Maximum supporedt SCSI ID" + int "Maximum supported SCSI ID" default 1 help Sets the maximum number of SCSI IDs to scan when looking for devices. -- 2.39.2

2 1

[PATCH v2 00/16] x86: Various minor enhancements for coreboot
by Simon Glass 27 Mar '23

27 Mar '23

This series includes some patches generated while getting U-Boot to boot more nicely on Brya, an Adler Lake Chromebook. This includes: - show the ACPI tables with 'acpi list' - get the UART to work even if coreboot doesn't enable it - show unimplemented sysinfo tags - fix for keyboard not working - fix for trying to set up PCI regions when the info is not available - fix for looking at inaccessible memory to find the sysinfo table Changes in v2: - Don't show an invalid CPU number on error - Update commit message with more detail - Update code comment to mention that addresses <1KB are ignored - Flush the buffer instead of skipping the reset - Add new patch to create a new Kconfig for ACPI - Add new patch to move acpi-table-finding functions into the library - Use tab instead of space in header file - Refactor two patches into one - Add new patch to allow locating the UART from ACPI tables - Expand commit message to explain this is for the debug UART - Update the defconfig instead - Drop patch 'usb: Quieten a debug message' since it was fixed elsewhere - Drop patch 'x86: coreboot: Use a memory-mapped UART' (not needed) - Add new patch to enable ms command - Move this patch to last in the series, so it can be dropped if needed Simon Glass (16): mtrr: Don't show an invalid CPU number x86: Adjust search range for sysinfo table input: Flush the keyboard buffer before resetting it acpi: Create a new Kconfig for ACPI acpi: Move the table-finding functions into the libary x86: coreboot: Collect the address of the ACPI tables x86: Allow locating the UART from ACPI tables pci: coreboot: Don't read regions when booting x86: coreboot: Use a memory-mapped UART x86: coreboot: Document how to enable the debug UART x86: coreboot: Scan PCI after relocation x86: coreboot: Log function names and line numbers x86: coreboot: Show unimplemented sysinfo tags x86: nvme: coreboot: Enable NVMe coreboot: Enable ms command x86: Allow locating UARTs by device ID arch/x86/cpu/cpu.c | 4 +- arch/x86/dts/coreboot.dts | 4 + arch/x86/include/asm/cb_sysinfo.h | 8 ++ arch/x86/include/asm/coreboot_tables.h | 2 + arch/x86/lib/coreboot/cb_sysinfo.c | 13 +++ cmd/Kconfig | 2 +- cmd/acpi.c | 44 +------ cmd/x86/cbsysinfo.c | 9 ++ cmd/x86/mtrr.c | 6 +- configs/coreboot64_defconfig | 1 - configs/coreboot_defconfig | 10 +- doc/board/coreboot/coreboot.rst | 29 +++++ drivers/core/Kconfig | 1 + drivers/input/i8042.c | 19 +++ drivers/nvme/nvme_pci.c | 8 ++ drivers/pci/pci-uclass.c | 4 + drivers/serial/Kconfig | 10 ++ drivers/serial/serial_coreboot.c | 155 +++++++++++++++++++++++-- include/acpi/acpi_table.h | 8 ++ include/asm-generic/global_data.h | 4 +- include/pci_ids.h | 3 + lib/Kconfig | 11 +- lib/Makefile | 2 +- lib/acpi/Makefile | 6 + lib/acpi/acpi.c | 45 +++++++ 25 files changed, 350 insertions(+), 58 deletions(-) create mode 100644 lib/acpi/acpi.c -- 2.40.0.348.gf938b09366-goog

2 18

[PATCH v2 0/2] rockchip: fix efuse/otp misc_read return values
by John Keeping 26 Mar '23

26 Mar '23

Fix the return value for misc_read() in the two Rockchip nvmem drivers so that they return the number of bytes read. In v2 the rockchip-efuse patch is change to correctly handle block_size > 1 and the rockchip-otp patch is new. John Keeping (2): rockchip: efuse: fix misc_read() return values rockchip: otp: fix misc_read() return values drivers/misc/rockchip-efuse.c | 12 ++++++++---- drivers/misc/rockchip-otp.c | 12 ++++++++---- 2 files changed, 16 insertions(+), 8 deletions(-) -- 2.40.0

3 6

NEXT: Pull request for efi-next-20230325
by Heinrich Schuchardt 26 Mar '23

26 Mar '23

Dear Tom, The following changes since commit 884d626d8357853c012d535bf26c143bb7b5e6a5: Merge branch '2023-03-22-assorted-minor-code-cleanups' into next (2023-03-22 20:57:39 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-next-20230325 for you to fetch changes up to 93e3364804ffd4a5d4a0df9c750a1859f9fe298b: cmd: bootefi: allocate device-tree copy from high memory (2023-03-25 12:04:49 +0100) Gitlab CI showed no issues: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/15736 ---------------------------------------------------------------- Pull request for efi-next-20230325 Documenation: * add man-page for efi command UEFI: * Let EFI app call ExitBootServices() before legacy booting kernel * Support zboot and bootm in the EFI app * Let efi command show configuration tables * Support booting a 64-bit kernel from 64-bit EFI app * Allocate device-tree copy from high memory * simplify efi_str_to_u16() ---------------------------------------------------------------- Heinrich Schuchardt (6): efi_loader: support for Ctrl() device path node efi_loader: fix device-path for USB devices efi_loader: move struct efi_device_path to efi.h efi_loader: move dp_alloc() to efi_alloc() efi_loader: simplify efi_str_to_u16() cmd: bootefi: allocate device-tree copy from high memory Simon Glass (12): efi: Set RUN_64BIT correctly for the EFI app x86: Adjust bootparam.h to be more like linux x86: Add return-value comment to cpu_jump_to_64bit() x86: Support booting a 64-bit kernel from 64-bit U-Boot x86: Exit EFI boot services before starting kernel x86: Support zboot and bootm in the EFI app efi: Add another tranch of GUIDs efi: Include GUID names with EFI app and payload doc: Add help for the efi command efi: Split out table-listing code into a new file efi: Support showing tables efI: Allow packaging a kernel in the debugging script arch/x86/Kconfig | 4 +- arch/x86/include/asm/bootm.h | 12 +- arch/x86/include/asm/bootparam.h | 70 ++++++---- arch/x86/include/asm/cpu.h | 1 + arch/x86/lib/bootm.c | 43 ++++-- arch/x86/lib/zimage.c | 17 ++- cmd/Makefile | 4 +- cmd/bootefi.c | 19 +-- cmd/efi.c | 31 ++++- cmd/efi_common.c | 26 ++++ cmd/efidebug.c | 6 +- configs/efi-x86_app32_defconfig | 2 +- configs/efi-x86_app64_defconfig | 3 +- doc/usage/cmd/efi.rst | 219 +++++++++++++++++++++++++++++++ doc/usage/index.rst | 1 + include/efi.h | 22 +++- include/efi_api.h | 31 ++++- include/efi_loader.h | 4 +- lib/efi_loader/efi_device_path.c | 85 ++++++------ lib/efi_loader/efi_device_path_to_text.c | 12 +- lib/efi_loader/efi_memory.c | 46 ++++--- lib/uuid.c | 10 +- scripts/build-efi.sh | 14 +- 23 files changed, 539 insertions(+), 143 deletions(-) create mode 100644 cmd/efi_common.c create mode 100644 doc/usage/cmd/efi.rst

2 1

Re: Bug#1033301: linux: arm64 kernel size increased from 31 to 39 MB, causing u-boot-rpi to fail
by Vagrant Cascadian 26 Mar '23

26 Mar '23

Adding u-boot maintainers for rpi (Matthias Brugger, Peter Robinson) platforms and u-boot list to CC. On 2023-03-22, Salvatore Bonaccorso wrote: > Thanks for tracking this down. I would like to loop in Masahiro and > upstream to see if something can/should be done on upstream side. > > Masahiro, in short, upstream change 994b7ac1697b ("arm64: remove > special treatment for the link order of head.o") (which got backported > as well to 6.1.14) caused the vmlinuz size to icrease significantly, > causing boot failures on Raspberry Pi 3 Model B Plus with u-boot > parameters previously working. Full quoting the Debian report below In general it would be nice to not have the kernel grow nearly 25% in size from a single commit; was that an expected outcome from the above upstream change? Was the "special treament" originally done to keep the kernel size down? As for u-boot, It seems u-boot might need to update the various load addresses for the kernel, device tree and ramdisk at some point regardless of weather this particular issue gets fixed in the kernel, as the kernel will likely continue to grow a bit over time... Aurelien Jarno included a patch referenced below which bumps the tolerances in u-boot from 36MB to 42MB. > On Tue, Mar 21, 2023 at 11:11:13PM +0100, Aurelien Jarno wrote: >> Following the upgrade of the kernel from 6.1.12-1 to 6.1.15-1 on a >> Raspberry Pi 3 Model B Plus, u-boot (from the u-boot-rpi package) failed >> to boot with: >> >> | 40175552 bytes read in 1695 ms (23 MiB/s) >> | 43794863 bytes read in 1817 ms (23 MiB/s) >> | Moving Image from 0x80000 to 0x200000, end=2990000 >> | ERROR: RD image overlaps OS image (OS=0x200000..0x2990000) >> >> I tracked the issue to a significant increase of the kernel size between >> version 6.1.12-1 and 6.15-1: >> >> | 31492 /boot/vmlinuz-6.1.0-5-arm64 >> | 39236 /boot/vmlinuz-6.1.0-6-arm64 >> >> This is more than the 36MB that is allowed by u-boot with the default >> load addresses. A workaround is to shift the load addresses at the >> u-boot level as in the attached patch. >> >> I have tracked issue on the upstream kernel side to the following commit >> on the stable tree: >> >> | commit 3e3e4d234d46e48480a7c7c35399fa811182e8ef >> | Author: Masahiro Yamada <masahiroy(a)kernel.org> >> | Date: Thu Oct 13 08:35:00 2022 +0900 >> | >> | arm64: remove special treatment for the link order of head.o >> | >> | commit 994b7ac1697b4581b7726d2ac64321e3c840229b upstream. >> | >> | In the previous discussion (see the Link tag), Ard pointed out that >> | arm/arm64/kernel/head.o does not need any special treatment - the only >> | piece that must appear right at the start of the binary image is the >> | image header which is emitted into .head.text. >> | >> | The linker script does the right thing to do. The build system does >> | not need to manipulate the link order of head.o. >> | >> | Link: https://lore.kernel.org/lkml/CAMj1kXH77Ja8bSsq2Qj8Ck9iSZKw=1F8Uy-uAWGVDm4-C… >> | Suggested-by: Ard Biesheuvel <ardb(a)kernel.org> >> | Signed-off-by: Masahiro Yamada <masahiroy(a)kernel.org> >> | Reviewed-by: Nicolas Schier <nicolas(a)fjasle.eu> >> | Link: https://lore.kernel.org/r/20221012233500.156764-1-masahiroy@kernel.org >> | Signed-off-by: Will Deacon <will(a)kernel.org> >> | Signed-off-by: Tom Saeger <tom.saeger(a)oracle.com> >> | Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> >> >> The problem is still reproducible on Linus' master. >> >> I am reporting the bug to the linux package as I believed there is no >> real reason for such an increase in the kernel size. In case I missed >> something and this is actually wanted, the bug can be reassigned to the >> u-boot package. >> >> Regards >> Aurelien > >> --- u-boot-2023.01+dfsg.orig/include/configs/rpi.h >> +++ u-boot-2023.01+dfsg/include/configs/rpi.h >> @@ -95,32 +95,32 @@ >> * text_offset bytes (specified in the header of the Image) into a 2MB >> * boundary. The 'booti' command relocates the image if necessary. Linux uses >> * a default text_offset of 0x80000. In summary, loading at 0x80000 >> - * satisfies all these constraints and reserving memory up to 0x02400000 >> - * permits fairly large (roughly 36M) kernels. >> + * satisfies all these constraints and reserving memory up to 0x02a00000 >> + * permits fairly large (roughly 42M) kernels. >> * >> * scriptaddr and pxefile_addr_r can be pretty much anywhere that doesn't >> * conflict with something else. Reserving 1M for each of them at >> - * 0x02400000-0x02500000 and 0x02500000-0x02600000 should be plenty. >> + * 0x02a00000-0x02b00000 and 0x02c00000-0x02d00000 should be plenty. >> * >> * On ARM, both the DTB and any possible initrd must be loaded such that they >> * fit inside the lowmem mapping in Linux. In practice, this usually means not >> * more than ~700M away from the start of the kernel image but this number can >> * be larger OR smaller depending on e.g. the 'vmalloc=xxxM' command line >> * parameter given to the kernel. So reserving memory from low to high >> - * satisfies this constraint again. Reserving 1M at 0x02600000-0x02700000 for >> - * the DTB leaves rest of the free RAM to the initrd starting at 0x02700000. >> + * satisfies this constraint again. Reserving 1M at 0x02c00000-0x02d00000 for >> + * the DTB leaves rest of the free RAM to the initrd starting at 0x02d00000. >> * Even with the smallest possible CPU-GPU memory split of the CPU getting >> - * only 64M, the remaining 25M starting at 0x02700000 should allow quite >> + * only 64M, the remaining 19M starting at 0x02d00000 should allow quite >> * large initrds before they start colliding with U-Boot. >> */ >> #define ENV_MEM_LAYOUT_SETTINGS \ >> "fdt_high=" FDT_HIGH "\0" \ >> "initrd_high=" INITRD_HIGH "\0" \ >> "kernel_addr_r=0x00080000\0" \ >> - "scriptaddr=0x02400000\0" \ >> - "pxefile_addr_r=0x02500000\0" \ >> - "fdt_addr_r=0x02600000\0" \ >> - "ramdisk_addr_r=0x02700000\0" >> + "scriptaddr=0x02a00000\0" \ >> + "pxefile_addr_r=0x02b00000\0" \ >> + "fdt_addr_r=0x02c00000\0" \ >> + "ramdisk_addr_r=0x02d00000\0" >> >> #if CONFIG_IS_ENABLED(CMD_MMC) >> #define BOOT_TARGET_MMC(func) \ Bumping from 36MB to 42MB seems address the issue at hand, although would it make sense to bump even higher... or is that starting to hit other limitations? Thanks everyone! live well, vagrant

2 1