November 2022 - U-Boot

[PATCH] Revert "lib: sparse: Make CHUNK_TYPE_RAW buffer aligned"
by Gary Bisson 17 Jun '23

17 Jun '23

This reverts commit 62649165cb02ab95b57360bb362886935f524f26. The patch decreased the write performance quite a bit. Here is an example on an i.MX 8M Quad platform. - Before the revert: Sending sparse 'vendor' 1/2 (516436 KB) OKAY [ 5.113s] Writing 'vendor' OKAY [128.335s] Sending sparse 'vendor' 2/2 (76100 KB) OKAY [ 0.802s] Writing 'vendor' OKAY [ 27.902s] - After the revert: Sending sparse 'vendor' 1/2 (516436 KB) OKAY [ 5.310s] Writing 'vendor' OKAY [ 18.041s] Sending sparse 'vendor' 2/2 (76100 KB) OKAY [ 1.244s] Writing 'vendor' OKAY [ 2.663s] Considering that the patch only moves buffer around to avoid a warning message about misaligned buffers, let's keep the best performances. Signed-off-by: Gary Bisson <gary.bisson(a)boundarydevices.com> Signed-off-by: Troy Kisky <troy.kisky(a)boundarydevices.com> --- lib/image-sparse.c | 69 ++++++---------------------------------------- 1 file changed, 8 insertions(+), 61 deletions(-) diff --git a/lib/image-sparse.c b/lib/image-sparse.c index 5ec0f94ab3e..d80fdbbf58e 100644 --- a/lib/image-sparse.c +++ b/lib/image-sparse.c @@ -46,66 +46,9 @@ #include <asm/cache.h> #include <linux/math64.h> -#include <linux/err.h> static void default_log(const char *ignored, char *response) {} -static lbaint_t write_sparse_chunk_raw(struct sparse_storage *info, - lbaint_t blk, lbaint_t blkcnt, - void *data, - char *response) -{ - lbaint_t n = blkcnt, write_blks, blks = 0, aligned_buf_blks = 100; - uint32_t *aligned_buf = NULL; - - if (CONFIG_IS_ENABLED(SYS_DCACHE_OFF)) { - write_blks = info->write(info, blk, n, data); - if (write_blks < n) - goto write_fail; - - return write_blks; - } - - aligned_buf = memalign(ARCH_DMA_MINALIGN, info->blksz * aligned_buf_blks); - if (!aligned_buf) { - info->mssg("Malloc failed for: CHUNK_TYPE_RAW", response); - return -ENOMEM; - } - - while (blkcnt > 0) { - n = min(aligned_buf_blks, blkcnt); - memcpy(aligned_buf, data, n * info->blksz); - - /* write_blks might be > n due to NAND bad-blocks */ - write_blks = info->write(info, blk + blks, n, aligned_buf); - if (write_blks < n) { - free(aligned_buf); - goto write_fail; - } - - blks += write_blks; - data += n * info->blksz; - blkcnt -= n; - } - - free(aligned_buf); - return blks; - -write_fail: - if (IS_ERR_VALUE(write_blks)) { - printf("%s: Write failed, block #" LBAFU " [" LBAFU "] (%lld)\n", - __func__, blk + blks, n, (long long)write_blks); - info->mssg("flash write failure", response); - return write_blks; - } - - /* write_blks < n */ - printf("%s: Write failed, block #" LBAFU " [" LBAFU "]\n", - __func__, blk + blks, n); - info->mssg("flash write failure(incomplete)", response); - return -1; -} - int write_sparse_image(struct sparse_storage *info, const char *part_name, void *data, char *response) { @@ -209,11 +152,15 @@ int write_sparse_image(struct sparse_storage *info, return -1; } - blks = write_sparse_chunk_raw(info, blk, blkcnt, - data, response); - if (blks < 0) + blks = info->write(info, blk, blkcnt, data); + /* blks might be > blkcnt (eg. NAND bad-blocks) */ + if (blks < blkcnt) { + printf("%s: %s" LBAFU " [" LBAFU "]\n", + __func__, "Write failed, block #", + blk, blks); + info->mssg("flash write failure", response); return -1; - + } blk += blks; bytes_written += ((u64)blkcnt) * info->blksz; total_blocks += chunk_header->chunk_sz; -- 2.35.1

4 6

Setting MAC address from I2C EEPROM - debug / commands? (Xilinx)
by David Antliff 12 Jun '23

12 Jun '23

Hi, I'm looking to extract the board's MAC address from serial I2C EEPROM at boot time, so I'm trying to work out how I can tell if U-Boot is actually able to communicate with this EEPROM, outside of manual i2c commands. I have set CONFIG_ZYNQ_MAC_IN_EEPROM and CONFIG_ZYNQ_MAC_IN_EEPROM however I'm not completely sure that this is working with UltraScale+ Zynq MPSoC boards - I'm using a ZCU208. There's no log message on the U-Boot console to say that there was an attempt to read the MAC address, and with ethaddr unset, this variable is set by U-Boot to the value taken from the device tree rather than EEPROM: ethernet@ff0e0000 { ... local-mac-address = [00 0a 35 00 22 01]; ... I would expect it to be 00 0a 35 07 60 1c based on the contents of the EEPROM. I would like to understand how to debug this. I read that the command "eeprom" has been deprecated for some time (I don't have it enabled), with some I2C serial EEPROM devices now supported by the "Driver Model" - aka DM. Thus I did find: > dm uclass ... uclass 39: i2c_eeprom 0 eeprom@54 @ 7dd21420 ... And I'm able to communicate with the device via commands like: ZynqMP> i2c md 54 0.2 40 200000 0000: 5a 43 55 32 30 38 ff ff ff ff ff ff ff ff ff ff ZCU208.......... 0010: ff 41 30 32 38 33 32 32 30 34 31 34 33 33 32 38 .A02832204143328 0020: 31 2e 33 00 0a 35 07 60 1c 00 0a 35 07 60 1d 00 1.3..5.`...5.`.. 0030: 0a 35 07 60 1e 00 0a 35 07 60 1f 41 08 ff ff ff .5.`...5.`.A.... The MAC address is 6 bytes starting at offset 0x23 (00 0a 35 07 60 1c). My question is - is the 'i2c' command now the accepted and best way to interact with an I2C EEPROM? Or is there another command I can enable (other than "eeprom") that will provide a generic interface for accessing EEPROMs and prove that U-Boot can "see" this device? The EEPROM device in question is an M24128. CONFIG_SYS_I2C_EEPROM_ADDR=0x54 CONFIG_SYS_I2C_EEPROM_BUS=6 CONFIG_SYS_EEPROM_SIZE=16384 CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2 CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET=0x23 CONFIG_ZYNQ_MAC_IN_EEPROM=y U-Boot 2021.01 (Xilinx fork: git://github.com/Xilinx/u-boot-xlnx.git) P.S. if this is better directed to Xilinx or the Xilinx community then I'm happy to do that, but in case it's a more generic U-Boot issue I thought it best to ask here first. Please don't flame me for using Xilinx, I'm trying to do my best with what I'm given. -- David.

4 11

[PATCH] arm: dts: ast2600: Add I2C pinctrl
by Eddie James 01 Jun '23

01 Jun '23

Set the pinctrl groups for each I2C bus. These are essential to I2C operating correctly. Signed-off-by: Eddie James <eajames(a)linux.ibm.com> --- arch/arm/dts/ast2600.dtsi | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/arch/arm/dts/ast2600.dtsi b/arch/arm/dts/ast2600.dtsi index 64074309b7..ef5b131ac0 100644 --- a/arch/arm/dts/ast2600.dtsi +++ b/arch/arm/dts/ast2600.dtsi @@ -833,6 +833,8 @@ bus-frequency = <100000>; interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>; clocks = <&scu ASPEED_CLK_APB2>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_i2c1_default>; status = "disabled"; }; @@ -846,6 +848,8 @@ bus-frequency = <100000>; interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>; clocks = <&scu ASPEED_CLK_APB2>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_i2c2_default>; status = "disabled"; }; @@ -859,6 +863,8 @@ bus-frequency = <100000>; interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>; clocks = <&scu ASPEED_CLK_APB2>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_i2c3_default>; }; i2c3: i2c@200 { @@ -871,6 +877,8 @@ bus-frequency = <100000>; interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>; clocks = <&scu ASPEED_CLK_APB2>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_i2c4_default>; }; i2c4: i2c@280 { @@ -883,6 +891,8 @@ bus-frequency = <100000>; interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>; clocks = <&scu ASPEED_CLK_APB2>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_i2c5_default>; }; i2c5: i2c@300 { @@ -895,6 +905,8 @@ bus-frequency = <100000>; interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>; clocks = <&scu ASPEED_CLK_APB2>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_i2c6_default>; }; i2c6: i2c@380 { @@ -907,6 +919,8 @@ bus-frequency = <100000>; interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>; clocks = <&scu ASPEED_CLK_APB2>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_i2c7_default>; }; i2c7: i2c@400 { @@ -919,6 +933,8 @@ bus-frequency = <100000>; interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>; clocks = <&scu ASPEED_CLK_APB2>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_i2c8_default>; }; i2c8: i2c@480 { @@ -931,6 +947,8 @@ bus-frequency = <100000>; interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>; clocks = <&scu ASPEED_CLK_APB2>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_i2c9_default>; }; i2c9: i2c@500 { @@ -943,6 +961,8 @@ bus-frequency = <100000>; interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>; clocks = <&scu ASPEED_CLK_APB2>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_i2c10_default>; status = "disabled"; }; @@ -956,6 +976,8 @@ bus-frequency = <100000>; interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>; clocks = <&scu ASPEED_CLK_APB2>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_i2c11_default>; status = "disabled"; }; @@ -969,6 +991,8 @@ bus-frequency = <100000>; interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>; clocks = <&scu ASPEED_CLK_APB2>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_i2c12_default>; status = "disabled"; }; @@ -982,6 +1006,8 @@ bus-frequency = <100000>; interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>; clocks = <&scu ASPEED_CLK_APB2>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_i2c13_default>; status = "disabled"; }; @@ -995,6 +1021,8 @@ bus-frequency = <100000>; interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>; clocks = <&scu ASPEED_CLK_APB2>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_i2c14_default>; status = "disabled"; }; @@ -1008,6 +1036,8 @@ bus-frequency = <100000>; interrupts = <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>; clocks = <&scu ASPEED_CLK_APB2>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_i2c15_default>; status = "disabled"; }; @@ -1021,6 +1051,8 @@ bus-frequency = <100000>; interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>; clocks = <&scu ASPEED_CLK_APB2>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_i2c16_default>; status = "disabled"; }; @@ -1246,6 +1278,7 @@ function = "I2C1"; groups = "I2C1"; }; + pinctrl_i2c2_default: i2c2_default { function = "I2C2"; groups = "I2C2"; -- 2.31.1

4 3

[PATCH] ARM: imx: Fix parsing of ROM log event IDs on iMX8M
by fedorross＠gmail.com 21 May '23

21 May '23

From: Fedor Ross <fedor.ross(a)ifm.com> It seems like the ROM log events for the iMX8M are not fully covered by AN12853 i.MX ROMs Log Events, Rev. 0, May 2020. On iMX8M the ROM event ID 0x82 seems to use parameter0 which stops the parsing because the end of list is detected too early. This patch adds ROM event ID 0x82 and skips the next word if ID 0x82 is parsed. Fixes: a5ee05cf71 ("ARM: imx: Pick correct eMMC boot partition from ROM log") Signed-off-by: Fedor Ross <fedor.ross(a)ifm.com> Cc: Fabio Estevam <festevam(a)gmail.com> Cc: Marek Vasut <marex(a)denx.de> Cc: Peng Fan <peng.fan(a)nxp.com> Cc: Stefano Babic <sbabic(a)denx.de> --- arch/arm/mach-imx/imx8m/soc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c index 8171631db1..4df57cb150 100644 --- a/arch/arm/mach-imx/imx8m/soc.c +++ b/arch/arm/mach-imx/imx8m/soc.c @@ -677,6 +677,7 @@ int spl_mmc_emmc_boot_partition(struct mmc *mmc) /* Log entries with 1 parameter, skip 1 */ case 0x80: /* Start to perform the device initialization */ case 0x81: /* The boot device initialization completes */ + case 0x82: /* Starts to execute boot device driver pre-config */ case 0x8f: /* The boot device initialization fails */ case 0x90: /* Start to read data from boot device */ case 0x91: /* Reading data from boot device completes */ -- 2.20.1

4 6

commit 787f04bb6a - imx: add USB2_BOOT type
by Rasmus Villemoes 21 May '23

21 May '23

Hi Peng It seems that commit 787f04bb6a (imx: add USB2_BOOT type) broke our board logic which relies on whether get_boot_device() returns USB_BOOT or not. Instrumenting get_boot_device() shows that on our imx8mp board, boot_instance is 3 when we're booting over USB, so boot_dev becomes 20 instead of 17 aka USB_BOOT. I assume that for the boards/socs you mentioned in the commit message, boot_instance could be 0 or 1. However, I don't see anywhere that uses that USB2_BOOT define. Short-term, I'll probably just revert 787f04bb6a locally. A bit longer term, I'm thinking I should be doing rom_api_query_boot_infor() and "decoding" the return value myself. Is there any chance you could make some information on that ROM API public so it's possible for outsiders to understand what's going on? Rasmus

4 8

[PATCH] gpio: renesas: Simplify .request/.rfree callbacks
by Pali Rohár 16 May '23

16 May '23

Remove identify wrapper functions. Signed-off-by: Pali Rohár <pali(a)kernel.org> --- drivers/gpio/gpio-rcar.c | 15 ++------------- 1 file changed, 2 insertions(+), 13 deletions(-) diff --git a/drivers/gpio/gpio-rcar.c b/drivers/gpio/gpio-rcar.c index 138801850d3e..ba00bb459679 100644 --- a/drivers/gpio/gpio-rcar.c +++ b/drivers/gpio/gpio-rcar.c @@ -130,20 +130,9 @@ static int rcar_gpio_get_function(struct udevice *dev, unsigned offset) return GPIOF_INPUT; } -static int rcar_gpio_request(struct udevice *dev, unsigned offset, - const char *label) -{ - return pinctrl_gpio_request(dev, offset, label); -} - -static int rcar_gpio_free(struct udevice *dev, unsigned offset) -{ - return pinctrl_gpio_free(dev, offset); -} - static const struct dm_gpio_ops rcar_gpio_ops = { - .request = rcar_gpio_request, - .rfree = rcar_gpio_free, + .request = pinctrl_gpio_request, + .rfree = pinctrl_gpio_free, .direction_input = rcar_gpio_direction_input, .direction_output = rcar_gpio_direction_output, .get_value = rcar_gpio_get_value, -- 2.20.1

3 8

[RFC] Proposed location to host the firmware handoff specification.
by Jose Marinho 09 May '23

09 May '23

Hi, Arm worked to draft a firmware handoff [1] specification, evolving it based on community feedback. This activity followed the request of some members of the Arm ecosystem [2]. The spec (still at ALP – feedback/comments welcome!) standardizes how information is propagated between different firmware components during boot. The spec hopes to remove the reliance on bespoke/platform-specific information handoff mechanisms, thus reducing the code maintenance burden. The concept of entry types is present in the spec – these are data structure layouts that carry a specific type of data. New types are meant to be added, following the needs and use-cases of the different communities. Thus, these communities should be empowered to request new types! To enable community contributions, the specification must be hosted in a location that is friendly to change requests. We propose to host the spec in trustedfirmware.org (tf.org). Tf.org hosts several open-source projects and already has an open governance model. TF-A, and the associated community, rely on tf.org, and thus are already well equipped to maintain this specification and keep it up to date. Tf.org is agnostic of any downstream projects that would adopt this specification (e.g. U-boot, EDK2, etc.). We welcome the views of the communities and want to understand if there are any strong objections to what’s being proposed! If anyone has objections, we are happy to consider alternatives and associated trade-offs. Regards [1] https://developer.arm.com/documentation/den0135/latest [2] Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages - TF-A - lists.trustedfirmware.org<https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…>

9 26

[PATCH] fw_env: add fallback to Linux's NVMEM based access
by Rafał Miłecki 09 May '23

09 May '23

From: Rafał Miłecki <rafal(a)milecki.pl> A new DT binding for describing environment data block has been added in Linux's commit 5db1c2dbc04c ("dt-bindings: nvmem: add U-Boot environment variables binding"). Once we get a proper Linux NVMEM driver it'll be possible to use Linux's binary interface for user-space as documented in the: https://www.kernel.org/doc/html/latest/driver-api/nvmem.html This commits makes fw_env fallback to looking for a compatible NVMEM device in case config file isn't present. In a long term this may make config files redundant and avoid code (info) duplication. Signed-off-by: Rafał Miłecki <rafal(a)milecki.pl> --- tools/env/fw_env.c | 70 ++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 67 insertions(+), 3 deletions(-) diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c index 31afef6f3b..be77bbf054 100644 --- a/tools/env/fw_env.c +++ b/tools/env/fw_env.c @@ -1713,6 +1713,67 @@ static int check_device_config(int dev) return rc; } +static int find_nvmem_device(void) +{ + const char *path = "/sys/bus/nvmem/devices"; + struct dirent *dent; + char *nvmem = NULL; + char comp[256]; + char buf[32]; + int bytes; + DIR *dir; + + dir = opendir(path); + if (!dir) { + return -EIO; + } + + while (!nvmem && (dent = readdir(dir))) { + FILE *fp; + + if (!strcmp(dent->d_name, ".") || !strcmp(dent->d_name, "..")) { + continue; + } + + bytes = snprintf(comp, sizeof(comp), "%s/%s/of_node/compatible", path, dent->d_name); + if (bytes < 0 || bytes == sizeof(comp)) { + continue; + } + + fp = fopen(comp, "r"); + if (!fp) { + continue; + } + + fread(buf, sizeof(buf), 1, fp); + + if (!strcmp(buf, "u-boot,env")) { + bytes = asprintf(&nvmem, "%s/%s/nvmem", path, dent->d_name); + if (bytes < 0) { + nvmem = NULL; + } + } + + fclose(fp); + } + + closedir(dir); + + if (nvmem) { + struct stat s; + + stat(nvmem, &s); + + DEVNAME(0) = nvmem; + DEVOFFSET(0) = 0; + ENVSIZE(0) = s.st_size; + + return 0; + } + + return -ENOENT; +} + static int parse_config(struct env_opts *opts) { int rc; @@ -1723,9 +1784,12 @@ static int parse_config(struct env_opts *opts) #if defined(CONFIG_FILE) /* Fills in DEVNAME(), ENVSIZE(), DEVESIZE(). Or don't. */ if (get_config(opts->config_file)) { - fprintf(stderr, "Cannot parse config file '%s': %m\n", - opts->config_file); - return -1; + if (find_nvmem_device()) { + fprintf(stderr, "Cannot parse config file '%s': %m\n", + opts->config_file); + fprintf(stderr, "Failed to find NVMEM device\n"); + return -1; + } } #else DEVNAME(0) = DEVICE1_NAME; -- 2.34.1

3 2

[PATCH v5 0/2] Add MNT Reform 2 board support
by Patrick Wildt 02 May '23

02 May '23

The MNT Reform 2 is a modular DIY laptop. In its initial version it is based on the BoundaryDevices i.MX8MQ SoM. Some parts have been lifted from BoundaryDevices official U-Boot downstream project. This U-Boot patchset supports the serial console, the SD card and eMMC, Gigabit Ethernet and USB. Changes since v4: - Adjusted to Kconfig conversions. - Removed U-Boot-specific device tree changes. - Synced device tree to Linux v5.19-rc3. Changes since v3: - Adjusted to Binman changes in main branch. - Cleaned up environment variables akin to i.MX8MM. - Added vendor-prefix to device tree filename. - Provided ramdisk_addr_r. Changes since v2: - Switched to Binman. Changes since v1: - Synced DTS with files in Linux git repo. - Added support for USB host ports. Patrick Wildt (2): arm: dts: imx8mq: update MNT Reform 2 to Linux v5.19-rc3 board: mntre: imx8mq: Add MNT Reform 2 board support arch/arm/dts/imx8mq-mnt-reform2-u-boot.dtsi | 11 + arch/arm/dts/imx8mq-mnt-reform2.dts | 145 ++- arch/arm/dts/imx8mq-nitrogen-som.dtsi | 15 +- arch/arm/mach-imx/imx8m/Kconfig | 7 + board/mntre/imx8mq_reform2/Kconfig | 15 + board/mntre/imx8mq_reform2/MAINTAINERS | 7 + board/mntre/imx8mq_reform2/Makefile | 12 + board/mntre/imx8mq_reform2/imx8mq_reform2.c | 213 ++++ board/mntre/imx8mq_reform2/lpddr4_timing.c | 1014 +++++++++++++++++ .../mntre/imx8mq_reform2/lpddr4_timing_ch2.h | 95 ++ board/mntre/imx8mq_reform2/spl.c | 260 +++++ configs/imx8mq_reform2_defconfig | 94 ++ include/configs/imx8mq_reform2.h | 86 ++ 13 files changed, 1966 insertions(+), 8 deletions(-) create mode 100644 arch/arm/dts/imx8mq-mnt-reform2-u-boot.dtsi create mode 100644 board/mntre/imx8mq_reform2/Kconfig create mode 100644 board/mntre/imx8mq_reform2/MAINTAINERS create mode 100644 board/mntre/imx8mq_reform2/Makefile create mode 100644 board/mntre/imx8mq_reform2/imx8mq_reform2.c create mode 100644 board/mntre/imx8mq_reform2/lpddr4_timing.c create mode 100644 board/mntre/imx8mq_reform2/lpddr4_timing_ch2.h create mode 100644 board/mntre/imx8mq_reform2/spl.c create mode 100644 configs/imx8mq_reform2_defconfig create mode 100644 include/configs/imx8mq_reform2.h -- 2.36.1

5 16

[PATCH] socfpga_de0_nano_soc: enable CONFIG_USE_BOOTCOMMAND
by Vijai Kumar K 28 Apr '23

28 Apr '23

There is no default boot command set for de0-nano-soc. This results in simply dropping to the u-boot shell. With this, the target now automatically invokes distro_bootcmd to boot the kernel. Signed-off-by: Vijai Kumar K <Vijaikumar_Kanagarajan(a)mentor.com> --- configs/socfpga_de0_nano_soc_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/socfpga_de0_nano_soc_defconfig b/configs/socfpga_de0_nano_soc_defconfig index ec7355d2cc..ddc147e8a0 100644 --- a/configs/socfpga_de0_nano_soc_defconfig +++ b/configs/socfpga_de0_nano_soc_defconfig @@ -12,7 +12,6 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x800000 CONFIG_FIT=y CONFIG_TIMESTAMP=y -# CONFIG_USE_BOOTCOMMAND is not set CONFIG_DEFAULT_FDT_FILE="socfpga_cyclone5_de0_nano_soc.dtb" CONFIG_SYS_CONSOLE_IS_IN_ENV=y CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y -- 2.25.1

3 2