From dc1c02cb598ce1162fd740475580124dd29d9c1d Mon Sep 17 00:00:00 2001 From: Michael Trimarchi Date: Sat, 24 Sep 2022 15:36:24 +0200 Subject: [PATCH 1/7] configs: rockchip: Drop TPL_MAX_SIZE definition The max size is defined at architectural level. On the same commit I have checked mostly all the other architecture and look like they are Fixes: commit ca8a329a1b7f ("Convert CONFIG_SPL_PAD_TO et al to Kconfig") Signed-off-by: Michael Trimarchi Reviewed-by: Tom Rini --- configs/evb-px30_defconfig | 1 - configs/evb-px5_defconfig | 1 - configs/evb-rk3229_defconfig | 1 - configs/evb-rk3328_defconfig | 1 - configs/firefly-px30_defconfig | 1 - configs/lion-rk3368_defconfig | 1 - configs/nanopi-r2s-rk3328_defconfig | 1 - configs/odroid-go2_defconfig | 1 - configs/px30-core-ctouch2-of10-px30_defconfig | 1 - configs/px30-core-ctouch2-px30_defconfig | 1 - configs/px30-core-edimm2.2-px30_defconfig | 1 - configs/roc-cc-rk3328_defconfig | 1 - configs/rock-pi-e-rk3328_defconfig | 1 - configs/rock64-rk3328_defconfig | 1 - 14 files changed, 14 deletions(-) diff --git a/configs/evb-px30_defconfig b/configs/evb-px30_defconfig index 240a044b2ab..4f88879e18a 100644 --- a/configs/evb-px30_defconfig +++ b/configs/evb-px30_defconfig @@ -17,7 +17,6 @@ CONFIG_SPL_STACK_R_ADDR=0x600000 CONFIG_DEBUG_UART_BASE=0xFF160000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SYS_LOAD_ADDR=0x800800 -CONFIG_TPL_MAX_SIZE=0x20000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x400000 diff --git a/configs/evb-px5_defconfig b/configs/evb-px5_defconfig index 8112b42c94d..40df2892e5e 100644 --- a/configs/evb-px5_defconfig +++ b/configs/evb-px5_defconfig @@ -19,7 +19,6 @@ CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_SPL_SPI=y CONFIG_SYS_LOAD_ADDR=0x800800 -CONFIG_TPL_MAX_SIZE=0x40000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x300000 diff --git a/configs/evb-rk3229_defconfig b/configs/evb-rk3229_defconfig index c8833e68ec7..442f504826b 100644 --- a/configs/evb-rk3229_defconfig +++ b/configs/evb-rk3229_defconfig @@ -17,7 +17,6 @@ CONFIG_SPL_STACK_R_ADDR=0x60600000 CONFIG_DEBUG_UART_BASE=0x11030000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SYS_LOAD_ADDR=0x61800800 -CONFIG_TPL_MAX_SIZE=0x100000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x61100000 diff --git a/configs/evb-rk3328_defconfig b/configs/evb-rk3328_defconfig index 251cc3f3cfa..2782a3901df 100644 --- a/configs/evb-rk3328_defconfig +++ b/configs/evb-rk3328_defconfig @@ -16,7 +16,6 @@ CONFIG_SPL_SYS_MALLOC_F_LEN=0x4000 CONFIG_DEBUG_UART_BASE=0xFF130000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SYS_LOAD_ADDR=0x800800 -CONFIG_TPL_MAX_SIZE=0x40000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x300000 diff --git a/configs/firefly-px30_defconfig b/configs/firefly-px30_defconfig index 4bc2031086d..1717eb21106 100644 --- a/configs/firefly-px30_defconfig +++ b/configs/firefly-px30_defconfig @@ -18,7 +18,6 @@ CONFIG_SPL_STACK_R_ADDR=0x600000 CONFIG_DEBUG_UART_BASE=0xFF160000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SYS_LOAD_ADDR=0x800800 -CONFIG_TPL_MAX_SIZE=0x20000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x400000 diff --git a/configs/lion-rk3368_defconfig b/configs/lion-rk3368_defconfig index 5f7c5a00919..33cd0c37c68 100644 --- a/configs/lion-rk3368_defconfig +++ b/configs/lion-rk3368_defconfig @@ -18,7 +18,6 @@ CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_SPL_SPI=y CONFIG_SYS_LOAD_ADDR=0x800800 -CONFIG_TPL_MAX_SIZE=0x40000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x300000 diff --git a/configs/nanopi-r2s-rk3328_defconfig b/configs/nanopi-r2s-rk3328_defconfig index 4dfb7782d98..86f5e111f81 100644 --- a/configs/nanopi-r2s-rk3328_defconfig +++ b/configs/nanopi-r2s-rk3328_defconfig @@ -16,7 +16,6 @@ CONFIG_SPL_STACK_R_ADDR=0x600000 CONFIG_DEBUG_UART_BASE=0xFF130000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SYS_LOAD_ADDR=0x800800 -CONFIG_TPL_MAX_SIZE=0x40000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x300000 diff --git a/configs/odroid-go2_defconfig b/configs/odroid-go2_defconfig index f8e432239b5..c0c0c4daee2 100644 --- a/configs/odroid-go2_defconfig +++ b/configs/odroid-go2_defconfig @@ -20,7 +20,6 @@ CONFIG_SPL_STACK_R_ADDR=0x600000 CONFIG_DEBUG_UART_BASE=0xFF160000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SYS_LOAD_ADDR=0x800800 -CONFIG_TPL_MAX_SIZE=0x20000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x400000 diff --git a/configs/px30-core-ctouch2-of10-px30_defconfig b/configs/px30-core-ctouch2-of10-px30_defconfig index 625460b34e5..2fb8bd8a234 100644 --- a/configs/px30-core-ctouch2-of10-px30_defconfig +++ b/configs/px30-core-ctouch2-of10-px30_defconfig @@ -18,7 +18,6 @@ CONFIG_SPL_STACK_R_ADDR=0x600000 CONFIG_DEBUG_UART_BASE=0xFF160000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SYS_LOAD_ADDR=0x800800 -CONFIG_TPL_MAX_SIZE=0x20000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x400000 diff --git a/configs/px30-core-ctouch2-px30_defconfig b/configs/px30-core-ctouch2-px30_defconfig index bca46982125..76f81ae437e 100644 --- a/configs/px30-core-ctouch2-px30_defconfig +++ b/configs/px30-core-ctouch2-px30_defconfig @@ -18,7 +18,6 @@ CONFIG_SPL_STACK_R_ADDR=0x600000 CONFIG_DEBUG_UART_BASE=0xFF160000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SYS_LOAD_ADDR=0x800800 -CONFIG_TPL_MAX_SIZE=0x20000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x400000 diff --git a/configs/px30-core-edimm2.2-px30_defconfig b/configs/px30-core-edimm2.2-px30_defconfig index c13af9320e9..8493500a064 100644 --- a/configs/px30-core-edimm2.2-px30_defconfig +++ b/configs/px30-core-edimm2.2-px30_defconfig @@ -18,7 +18,6 @@ CONFIG_SPL_STACK_R_ADDR=0x600000 CONFIG_DEBUG_UART_BASE=0xFF160000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SYS_LOAD_ADDR=0x800800 -CONFIG_TPL_MAX_SIZE=0x20000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x400000 diff --git a/configs/roc-cc-rk3328_defconfig b/configs/roc-cc-rk3328_defconfig index 8e2e5302e40..8ba50345da3 100644 --- a/configs/roc-cc-rk3328_defconfig +++ b/configs/roc-cc-rk3328_defconfig @@ -16,7 +16,6 @@ CONFIG_SPL_STACK_R_ADDR=0x600000 CONFIG_DEBUG_UART_BASE=0xFF130000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SYS_LOAD_ADDR=0x800800 -CONFIG_TPL_MAX_SIZE=0x40000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x300000 diff --git a/configs/rock-pi-e-rk3328_defconfig b/configs/rock-pi-e-rk3328_defconfig index 9831670137e..fb5eac3c1f8 100644 --- a/configs/rock-pi-e-rk3328_defconfig +++ b/configs/rock-pi-e-rk3328_defconfig @@ -17,7 +17,6 @@ CONFIG_SPL_SYS_MALLOC_F_LEN=0x4000 CONFIG_DEBUG_UART_BASE=0xFF130000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SYS_LOAD_ADDR=0x800800 -CONFIG_TPL_MAX_SIZE=0x40000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x300000 diff --git a/configs/rock64-rk3328_defconfig b/configs/rock64-rk3328_defconfig index 9ca6f3a3a18..b055dd09794 100644 --- a/configs/rock64-rk3328_defconfig +++ b/configs/rock64-rk3328_defconfig @@ -16,7 +16,6 @@ CONFIG_SPL_STACK_R_ADDR=0x600000 CONFIG_DEBUG_UART_BASE=0xFF130000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_SYS_LOAD_ADDR=0x800800 -CONFIG_TPL_MAX_SIZE=0x40000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x300000 From 34d5feaefe23e6372612fc3afad628082fa3942d Mon Sep 17 00:00:00 2001 From: Pankaj Raghav Date: Wed, 28 Sep 2022 17:23:01 +0200 Subject: [PATCH 2/7] fs: btrfs: remove the usage of undeclared fs_mutex variable This line probably got in by mistake as there is no fs_mutex member in the btrfs_fs_info struct. Signed-off-by: Pankaj Raghav Reviewed-by: Qu Wenruo --- fs/btrfs/disk-io.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index 8043abc1bd6..c80f8e80283 100644 --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -782,8 +782,6 @@ struct btrfs_fs_info *btrfs_new_fs_info(void) fs_info->fs_root_tree = RB_ROOT; cache_tree_init(&fs_info->mapping_tree.cache_tree); - mutex_init(&fs_info->fs_mutex); - return fs_info; free_all: btrfs_free_fs_info(fs_info); From c47bb10a4dd937b35852bbbf082d1deee694c384 Mon Sep 17 00:00:00 2001 From: Andre Przywara Date: Wed, 21 Sep 2022 18:09:46 +0100 Subject: [PATCH 3/7] vexpress64: also consider DTB pointer in x1 Commit c0fce929564f("vexpress64: fvp: enable OF_CONTROL") added code to consider a potential DTB address being passed in the x0 register, or revert to the built-in DTB otherwise. The former case was used when using the boot-wrapper, to which we sell U-Boot as a Linux kernel. The latter was meant for TF-A, for which we couldn't find an easy way to use the DTB it uses itself. We have some quirk to filter for a valid DTB, as TF-A happens to pass a pointer to some special devicetree blob in x0 as well. Now the TF-A case is broken, when enabling proper emulation of secure memory (-C bp.secure_memory=1). TF-A carves out some memory at the top of the first DRAM bank for its own purposes, and configures the TrustZone DRAM controller to make this region secure-only. U-Boot will then hang when it tries to relocate itself exactly to the end of DRAM. TF-A announces this by carving out that region of the /memory node, in the DT it passes on to BL33 in x1, but we miss that so far. Instead of repeating this carveout in our DT copy, let's try to look for a DTB at the address x1 points to as well. This will let U-Boot pick up the DTB provided by TF-A, which has the correct carveout in place, avoiding the hang. While we are at it, make the detection more robust: the length test (is the DT larger than 256 bytes?) is too fragile, in fact the TF-A port for a new FVP model already exceeds this. So we test x1 first, consider 0 an invalid address, and also require a /memory node to detect a valid DTB. And for the records: Some asking around revealed what is really going on with TF-A and that ominous DTB pointer in x0: TF-A expects EDK-2 as its non-secure payload (BL33), and there apparently was some long-standing ad-hoc boot protocol defined just between the two: x0 would carry the MPIDR register value of the boot CPU, and the hardware DTB address would be stored in x1. Now the MPIDR of CPU 0 is typically 0, plus bit 31 set, which is defined as RES1 in the ARMv7 and ARMv8 architectures. This gives 0x80000000, which is the same value as the address of the beginning of DRAM (2GB). And coincidentally TF-A put some DTB structure exactly there, for its own purposes (passing it between stages). So U-Boot was trying to use this DTB, which requires the quirk to check for its validity. Signed-off-by: Andre Przywara Tested-by: Peter Hoyes --- board/armltd/vexpress64/lowlevel_init.S | 2 +- board/armltd/vexpress64/vexpress64.c | 27 +++++++++++++++++++++---- 2 files changed, 24 insertions(+), 5 deletions(-) diff --git a/board/armltd/vexpress64/lowlevel_init.S b/board/armltd/vexpress64/lowlevel_init.S index 3dcfb85d0e9..68ca3f26e96 100644 --- a/board/armltd/vexpress64/lowlevel_init.S +++ b/board/armltd/vexpress64/lowlevel_init.S @@ -7,6 +7,6 @@ save_boot_params: adr x8, prior_stage_fdt_address - str x0, [x8] + stp x0, x1, [x8] b save_boot_params_ret diff --git a/board/armltd/vexpress64/vexpress64.c b/board/armltd/vexpress64/vexpress64.c index 05a7a25c32e..af326dc6f45 100644 --- a/board/armltd/vexpress64/vexpress64.c +++ b/board/armltd/vexpress64/vexpress64.c @@ -100,7 +100,7 @@ int dram_init_banksize(void) * Push the variable into the .data section so that it * does not get cleared later. */ -unsigned long __section(".data") prior_stage_fdt_address; +unsigned long __section(".data") prior_stage_fdt_address[2]; #ifdef CONFIG_OF_BOARD @@ -151,6 +151,23 @@ static phys_addr_t find_dtb_in_nor_flash(const char *partname) } #endif +/* + * Filter for a valid DTB, as TF-A happens to provide a pointer to some + * data structure using the DTB format, which we cannot use. + * The address of the DTB cannot be 0, in fact this is the reserved value + * for x1 in the kernel boot protocol. + * And while the nt_fw_config.dtb used by TF-A is a valid DTB structure, it + * does not contain the typical nodes and properties, which we test for by + * probing for the mandatory /memory node. + */ +static bool is_valid_dtb(uintptr_t dtb_ptr) +{ + if (dtb_ptr == 0 || fdt_magic(dtb_ptr) != FDT_MAGIC) + return false; + + return fdt_subnode_offset((void *)dtb_ptr, 0, "memory") >= 0; +} + void *board_fdt_blob_setup(int *err) { #ifdef CONFIG_TARGET_VEXPRESS64_JUNO @@ -172,10 +189,12 @@ void *board_fdt_blob_setup(int *err) } #endif - if (fdt_magic(prior_stage_fdt_address) == FDT_MAGIC && - fdt_totalsize(prior_stage_fdt_address) > 0x100) { + if (is_valid_dtb(prior_stage_fdt_address[1])) { *err = 0; - return (void *)prior_stage_fdt_address; + return (void *)prior_stage_fdt_address[1]; + } else if (is_valid_dtb(prior_stage_fdt_address[0])) { + *err = 0; + return (void *)prior_stage_fdt_address[0]; } if (fdt_magic(gd->fdt_blob) == FDT_MAGIC) { From d2ab2a2bafd53ace79da900900d5220931c7ef5a Mon Sep 17 00:00:00 2001 From: Nishanth Menon Date: Wed, 21 Sep 2022 08:38:42 -0500 Subject: [PATCH 4/7] board: ti: common: board_detect: Fix EEPROM read quirk for AM6 style data The situation is similar to commit bf6376642fe8 ("board: ti: common: board_detect: Fix EEPROM read quirk"). This is seen on a variant of eeproms seen on some BeagleBone-AI64 which now has a mix of both 1 byte addressing and 2 byte addressing eeproms. Unlike the am335x (ti_i2c_eeprom_am_get) and dra7 (ti_i2c_eeprom_dra7_get) which use constant data structure which allows us to do a complete read of the data, the am6(ti_i2c_eeprom_am6_get) eeprom parse operation is dynamic. This removes the option of being able to read the complete eeprom data in one single shot. Fortunately, on the I2C bus, we do see the following behavior: In 1 byte mode, if we attempt to read the first header data yet again, the misbehaving 2 byte addressing device acts in constant addressing mode which results in the header not matching up and follow on attempt at 2 byte addressing scheme grabs the correct data. This costs us an extra ~3 milliseconds, which is a minor penalty compared to the consistent image support we need to have. Reported-by: Jason Kridner Fixes: a58147c2dbbf ("board: ti: common: board_detect: Do 1byte address checks first.") Signed-off-by: Nishanth Menon --- board/ti/common/board_detect.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c index 9fa7b7beb63..c37629fe8ab 100644 --- a/board/ti/common/board_detect.c +++ b/board/ti/common/board_detect.c @@ -444,6 +444,16 @@ int __maybe_unused ti_i2c_eeprom_am6_get(int bus_addr, int dev_addr, if (rc) return rc; + /* + * Handle case of bad 2 byte eeproms that responds to 1 byte addressing + * but gets stuck in const addressing when read requests are performed + * on offsets. We re-read the board ID to ensure we have sane data back + */ + rc = ti_i2c_eeprom_get(bus_addr, dev_addr, TI_EEPROM_HEADER_MAGIC, + sizeof(board_id), (uint8_t *)&board_id); + if (rc) + return rc; + if (board_id.header.id != TI_AM6_EEPROM_RECORD_BOARD_ID) { pr_err("%s: Invalid board ID record!\n", __func__); return -EINVAL; From 316590db29b484209dbc3c3d60561168d0f7263c Mon Sep 17 00:00:00 2001 From: Miaoqian Lin Date: Mon, 19 Sep 2022 08:28:09 +0400 Subject: [PATCH 5/7] tools: env: Fix missing closedir in ubi_get_volnum_by_name The function calls opendir() but missing the corresponding closedir() before exit the function. Add missing closedir() to fix it. Signed-off-by: Miaoqian Lin --- tools/env/fw_env.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c index 908a162202d..c251e2e6ba7 100644 --- a/tools/env/fw_env.c +++ b/tools/env/fw_env.c @@ -192,10 +192,13 @@ static int ubi_get_volnum_by_name(int devnum, const char *volname) &tmp_devnum, &volnum); if (ret == 2 && devnum == tmp_devnum) { if (ubi_check_volume_sysfs_name(dirent->d_name, - volname) == 0) + volname) == 0) { + closedir(sysfs_ubi); return volnum; + } } } + closedir(sysfs_ubi); return -1; } From d21bbb98cc203dce7c646d2a2a399ed47fa3cc3f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pali=20Roh=C3=A1r?= Date: Thu, 15 Sep 2022 15:54:45 +0200 Subject: [PATCH 6/7] pci: Remove duplicate PCI_REGION_IO / "io" line MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Pali Rohár Reviewed-by: Bin Meng Reviewed-by: Stefan Roese --- cmd/pci.c | 1 - 1 file changed, 1 deletion(-) diff --git a/cmd/pci.c b/cmd/pci.c index 6258699fec8..58a74755c8b 100644 --- a/cmd/pci.c +++ b/cmd/pci.c @@ -452,7 +452,6 @@ static const struct pci_flag_info { { PCI_REGION_PREFETCH, "prefetch" }, { PCI_REGION_SYS_MEMORY, "sysmem" }, { PCI_REGION_RO, "readonly" }, - { PCI_REGION_IO, "io" }, }; static void pci_show_regions(struct udevice *bus) From 76f921eb95d5b814f973a263187db509d6f03903 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pierre-Cl=C3=A9ment=20Tosi?= Date: Fri, 9 Sep 2022 21:16:18 +0100 Subject: [PATCH 7/7] board_r: Relocate OF_EMBED if NEEDS_MANUAL_RELOC only MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When the embedded device tree is pointed to by the __dtb_dt_*begin symbols, it seems to be covered by the early relocation code and doesn't need to be manually patched. Cc: Simon Glass Signed-off-by: Pierre-Clément Tosi --- common/board_r.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/common/board_r.c b/common/board_r.c index 56eb60fa275..00926dcb1e1 100644 --- a/common/board_r.c +++ b/common/board_r.c @@ -150,13 +150,13 @@ static int initr_reloc_global_data(void) */ gd->env_addr += gd->reloc_off; #endif -#ifdef CONFIG_OF_EMBED /* * The fdt_blob needs to be moved to new relocation address * incase of FDT blob is embedded with in image */ - gd->fdt_blob += gd->reloc_off; -#endif + if (CONFIG_IS_ENABLED(OF_EMBED) && CONFIG_IS_ENABLED(NEEDS_MANUAL_RELOC)) + gd->fdt_blob += gd->reloc_off; + #ifdef CONFIG_EFI_LOADER /* * On the ARM architecture gd is mapped to a fixed register (r9 or x18).