Re: [U-Boot] [PATCH] block: Add SPL_BLOCK_CACHE and default n

On Sat, Jun 9, 2018 at 11:55 PM Adam Ford wrote: > > When enabling BLOCK_CACHE on devices with limited RAM during SPL, > some devices may not boot. This creates an option to enable > block caching in SPL by defaults off. It is dependent on BLOCK_CACHE > and SPL_BLK > > Fixes: 46960ad6d09b ("bloc

Re: [U-Boot] [PATCH] block: Add SPL_BLOCK_CACHE and default n

On Sat, Jun 09, 2018 at 05:55:11PM -0500, Adam Ford wrote: > When enabling BLOCK_CACHE on devices with limited RAM during SPL, > some devices may not boot. This creates an option to enable > block caching in SPL by defaults off. It is dependent on BLOCK_CACHE > and SPL_BLK > > Fixes: 46960ad6d0

Re: [U-Boot] [PATCH 7/8] spi: sandbox: Fix memory leak in sandbox_sf_bind_emul()

Hi Heinrich, On 9 June 2018 at 11:54, Heinrich Schuchardt wrote: > On 06/09/2018 08:22 PM, Simon Glass wrote: >> Move the strdup() call so that it is only done when we know we will bind >> the device. >> >> Reported-by: Coverity (CID: 131216) >> >> Signed-off-by: Simon Glass >> --- >> >> driver

Re: [U-Boot] [PATCH 3/8] sandbox: Use memcpy() to move overlapping regions

Hi Heinrich, On 9 June 2018 at 10:56, Heinrich Schuchardt wrote: > On 06/09/2018 08:22 PM, Simon Glass wrote: >> The use of strcpy() to remove characters at the start of a string is safe >> in U-Boot, since we know the implementation. But in os.c we are using the >> C library's strcpy() function,

[U-Boot] [PATCH 00/18] x86: efi: Fixes and enhancements to application and payload support

Unfortunately the EFI x86 application and payload support have been broken for quite a while. This series addresses various bug fixes, plus several enhancements like toolchain compatibility (eg: kernel.org i386-linux-gcc), introduction of generic EFI payload which can run on any x86 board, and a EF

[U-Boot] [PATCH 01/18] x86: doc: Fix reference to EFI doc in U-Boot

Since commit f3b5056c4e72 ("efi_loader: split README.efi into two separate documents"), the original README.efi was renamed to README.u-boot_on_efi, but x86 doc still refers to the old one. Signed-off-by: Bin Meng --- doc/README.x86 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --

[U-Boot] [PATCH 02/18] x86: Conditionally build the pinctrl_ich6 driver

The pinctrl_ich6 driver is currently unconditionally built for all x86 boards. Let's use a Kconfig option to control the build. Signed-off-by: Bin Meng --- arch/x86/Kconfig | 6 ++ arch/x86/cpu/baytrail/Kconfig | 1 + arch/x86/cpu/ivybridge/Kconfig | 1 + arch/x86/lib/Makefil

[U-Boot] [PATCH 04/18] x86: efi: payload: Enforce toolchain to generate 64-bit EFI payload stub codes

Attempting to use a toolchain that is preconfigured to generate code for the 32-bit architecture (i386), for example, the i386-linux-gcc toolchain on kernel.org, to compile the 64-bit EFI payload does not build. This updates the makefile fragments to ensure '-m64' is passed to toolchain when buildi

[U-Boot] [PATCH 11/18] x86: Add generic EFI payload support

It is possible to create a generic EFI payload for all x86 boards. The payload is configured to include as many generic drivers as possible. All stuff that touches low-level initialization are not allowed as such is the EFI BIOS's responsibility. Platform specific drivers (like gpio, spi, etc) are

[U-Boot] [PATCH 14/18] efi: stub: Pass EFI GOP information to U-Boot payload

If UEFI BIOS has the graphics output protocol (GOP), let's pass its information to U-Boot payload so that U-Boot can utilize it (eg: an EFI framebuffer driver). Signed-off-by: Bin Meng --- include/efi.h | 35 +++ lib/efi/efi_stub.c | 15 +++ 2 fi

[U-Boot] [PATCH 07/18] dm: pci: Use a 1:1 mapping for bus <-> phy addresses

From: Christian Gmeiner If U-Boot gets used as coreboot payload all pci resources got assigned by coreboot. If a dts without any pci ranges gets used the dm is not able to access pci device memory. To get things working make use of a 1:1 mapping for bus <-> phy addresses. This change makes it po

[U-Boot] [PATCH 05/18] efi: Fix efi_uintn_t for 64-bit EFI payload

Since commit bb0bb91cf0aa ("efi_stub: Use efi_uintn_t"), EFI x86 64-bit payload does not work anymore. The call to GetMemoryMap() in efi_stub.c fails with return code EFI_INVALID_PARAMETER. Since the payload itself is still 32-bit U-Boot, efi_uintn_t gets wrongly interpreted as int, but it should a

[U-Boot] [PATCH 13/18] x86: baytrail: Drop EFI-specific test logics

Now that we have generic EFI payload support, drop EFI-specific test logics in BayTrail Kconfig and codes, and all BayTrail boards too. Signed-off-by: Bin Meng --- arch/x86/cpu/baytrail/Kconfig | 6 +++--- arch/x86/cpu/baytrail/valleyview.c | 3 --- board/advantech/

[U-Boot] [PATCH 03/18] x86: efi: app: Fix broken EFI application

The EFI application does not boot currently. It's due to the call to syscon_get_by_driver_data() in cpu_init_r() maps to nowhere as CONFIG_SYSCON is not included in the configuration. EFI application is built as a shared library, so GCC won't complain during the build process if some symbols are n

[U-Boot] [PATCH 06/18] dm: pci: Make ranges dt property optional

From: Christian Gmeiner If we use U-Boot as coreboot payload with a generic dts without any ranges specified we fail in pci pre_probe and our pci bus is not usable. So convert decode_regions(..) into a void function and do the simple error handling there. Signed-off-by: Christian Gmeiner Revie

[U-Boot] [PATCH 09/18] x86: efi: payload: Add arch_cpu_init()

This adds arch_cpu_init() to the payload codes, in preparation for supporting a generic efi payload. Signed-off-by: Bin Meng --- arch/x86/cpu/efi/payload.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/arch/x86/cpu/efi/payload.c b/arch/x86/cpu/efi/payload.c ind

[U-Boot] [PATCH 15/18] dm: video: Add an EFI framebuffer driver

This adds a DM video driver for U-Boot as the EFI payload. The driver makes use of all necessary information from the passed EFI GOP info to create a linear framebuffer device, as if it were initialized by U-Boot itself. Signed-off-by: Bin Meng --- drivers/video/Kconfig | 9 +++ drivers/vide

[U-Boot] [PATCH 10/18] x86: efi: payload: Minor clean up on error message output

If GetMemoryMap() fails, we really want to know EFI_BITS_PER_LONG instead of BITS_PER_LONG. A space and LF are added in places where error message is output to improve readability. Signed-off-by: Bin Meng --- lib/efi/efi_stub.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff

[U-Boot] [PATCH 12/18] x86: Drop QEMU-specific EFI payload support

Now that we have generic EFI payload support for all x86 boards, drop the QEMU-specific one. Signed-off-by: Bin Meng --- arch/x86/cpu/qemu/Makefile | 2 -- arch/x86/cpu/qemu/qemu.c | 4 --- board/emulation/qemu-x86/Kconfig | 6 ++-- configs/qemu-x86_efi_

[U-Boot] [PATCH 18/18] x86: efi: app: Display correct CPU info during boot

Currently when EFI application boots, it says: CPU: x86_64, vendor , device 0h Fix this by calling x86_cpu_init_f() in arch_cpu_init(). Signed-off-by: Bin Meng --- arch/x86/cpu/efi/app.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/cpu/efi/app.c b/arch/x86/c

[U-Boot] [PATCH 16/18] x86: efi: payload: Add EFI framebuffer driver support

This turns on the EFI framebuffer driver support so that a graphics console can be of additional help. Signed-off-by: Bin Meng --- arch/x86/dts/efi-x86_payload.dts | 4 board/efi/efi-x86_payload/Kconfig | 1 + 2 files changed, 5 insertions(+) diff --git a/arch/x86/dts/efi-x86_payload.dts

[U-Boot] [PATCH 17/18] x86: Rename efi-x86 target to efi-x86_app

To avoid confusion, let's rename the efi-x86 target to efi-x86_app. Signed-off-by: Bin Meng --- arch/x86/cpu/efi/Makefile| 2 +- arch/x86/cpu/efi/{efi.c => app.c}| 0 arch/x86/cpu/intel_common/Makefile | 2 +- arch/x86/dts/Makefi

[U-Boot] [PATCH 08/18] x86: efi: Refactor the directory of EFI app and payload support

At present the EFI application and payload support codes in the x86 directory is distributed in a hybrid way. For example, the Kconfig options for both app and payload are in arch/x86/lib/efi/Kconfig, but the source codes in the same directory get built only for CONFIG_EFI_STUB. This refactors the

Re: [U-Boot] [PATCH 01/18] x86: doc: Fix reference to EFI doc in U-Boot

On 06/10/2018 03:25 PM, Bin Meng wrote: > Since commit f3b5056c4e72 ("efi_loader: split README.efi into two > separate documents"), the original README.efi was renamed to > README.u-boot_on_efi, but x86 doc still refers to the old one. > > Signed-off-by: Bin Meng > --- > > doc/README.x86 | 2 +-

Re: [U-Boot] [PATCH 01/18] x86: doc: Fix reference to EFI doc in U-Boot

Hi Heinrich, On Sun, Jun 10, 2018 at 9:39 PM, Heinrich Schuchardt wrote: > On 06/10/2018 03:25 PM, Bin Meng wrote: >> Since commit f3b5056c4e72 ("efi_loader: split README.efi into two >> separate documents"), the original README.efi was renamed to >> README.u-boot_on_efi, but x86 doc still refers

Re: [U-Boot] [PATCH 05/18] efi: Fix efi_uintn_t for 64-bit EFI payload

On 06/10/2018 03:25 PM, Bin Meng wrote: > Since commit bb0bb91cf0aa ("efi_stub: Use efi_uintn_t"), EFI x86 > 64-bit payload does not work anymore. The call to GetMemoryMap() > in efi_stub.c fails with return code EFI_INVALID_PARAMETER. Since > the payload itself is still 32-bit U-Boot Above you sa

[U-Boot] [RFC] gpio: omap_gpio: Convert to auto-alloc feature when DT is supported

The omap_gpio driver has a TODO that says when every board is converted to DM and DT, the omap_gpio_bind can stop using calloc and switch to auto-alloc. This patch converts this driver to auto-calloc when DT is enabled. Signed-off-by: Adam Ford diff --git a/drivers/gpio/omap_gpio.c b/drivers/gp

Re: [U-Boot] [PATCH 05/18] efi: Fix efi_uintn_t for 64-bit EFI payload

Hi Heinrich, On Sun, Jun 10, 2018 at 10:02 PM, Heinrich Schuchardt wrote: > On 06/10/2018 03:25 PM, Bin Meng wrote: >> Since commit bb0bb91cf0aa ("efi_stub: Use efi_uintn_t"), EFI x86 >> 64-bit payload does not work anymore. The call to GetMemoryMap() >> in efi_stub.c fails with return code EFI_I

[U-Boot] [PATCH 1/2] pinctrl: renesas: Sync Gen2 PFC tables with Linux v4.17

Sync the PFC tables with Linux v4.17. Signed-off-by: Marek Vasut Cc: Nobuhiro Iwamatsu --- drivers/pinctrl/renesas/pfc-r8a7790.c | 8 +- drivers/pinctrl/renesas/pfc-r8a7791.c | 84 +- drivers/pinctrl/renesas/pfc-r8a7794.c | 473 ++ 3 files changed, 559 ins

[U-Boot] [PATCH 2/2] ARM: rmobile: Sync Gen3 DTS with Linux v4.17

Sync the DTs with Linux v4.17. Signed-off-by: Marek Vasut Cc: Nobuhiro Iwamatsu --- arch/arm/dts/r8a7795.dtsi | 602 ++ arch/arm/dts/r8a7796.dtsi | 556 +++ arch/arm/dts/r8a77965.dtsi| 127 +++- arch

[U-Boot] [PATCH] ARM: rmobile: Zap CONFIG_SYS_CLK_FREQ where applicable

The CONFIG_SYS_CLK_FREQ is not used on some of the Gen3 boards, remove it. Moreover, on Ebisu this actually didn't match the comment in the config file at all, but since it was not used, there was no real problem. Signed-off-by: Marek Vasut Cc: Nobuhiro Iwamatsu --- include/configs/draak.h

[U-Boot] [PATCH 2/2] ARM: rmobile: Point load address to more sane area on Gen3

Point the $loadaddr variable and default load address to a more sane area, 384 MiB from the start of RAM. This is to avoid all the reserved memory at the beginning of RAM. The old behavior could still be easily retained by "setenv loadaddr 0x4808" . The new setup allows us to use for example mo

[U-Boot] [PATCH 1/2] ARM: rmobile: Point load address to more sane area on Gen2

Point the $loadaddr variable and default load address to a more sane area, 256 MiB from the start of RAM. While it is convenient to use uImage without copying, which is why the previous load address was set the way it was, uImage is now legacy. This behavior could still be easily retained by "seten

Re: [U-Boot] Uboot as x86_64 EFI payload

On Fri, Jun 8, 2018 at 8:25 PM, Bin Meng wrote: > Hi, > > On Mon, Jan 29, 2018 at 11:18 PM, Juan Alfonso Reyes Ajenjo > wrote: >> Hi, >> I am Juan Alfonso Reyes, a firmware engineer in GMV. Currently we are >> developing new boards based in Apollo Lake CPU. We are trying to load uboot >> from

[U-Boot] [PATCH] ARM: rmobile: Fix environment placement on Draak

The environment on Draak is in the eMMC, card 0, place it so. Signed-off-by: Marek Vasut --- include/configs/draak.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/draak.h b/include/configs/draak.h index 7aabf1178b..e1b9bf1885 100644 --- a/include/configs/dra

Re: [U-Boot] [PATCH 15/18] dm: video: Add an EFI framebuffer driver

Hi Bin, On Sun, 10 Jun 2018 06:25:14 -0700 Bin Meng bmeng...@gmail.com wrote: > This adds a DM video driver for U-Boot as the EFI payload. The driver > makes use of all necessary information from the passed EFI GOP info > to create a linear framebuffer device, as if it were initialized by > U-Boo

Re: [U-Boot] [PATCH 01/18] x86: doc: Fix reference to EFI doc in U-Boot

On 06/10/2018 04:01 PM, Bin Meng wrote: > Hi Heinrich, > > On Sun, Jun 10, 2018 at 9:39 PM, Heinrich Schuchardt > wrote: >> On 06/10/2018 03:25 PM, Bin Meng wrote: >>> Since commit f3b5056c4e72 ("efi_loader: split README.efi into two >>> separate documents"), the original README.efi was renamed

[U-Boot] [PATCH] MAINTAINERS: update ARM Snapdragon

Replace Mateusz as Maintainer for ARM Snapdragon arch. Signed-off-by: Ramon Fried --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 642c448093..b2c9717cb7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -184,7 +184,7 @@ F: arch/arm

Re: [U-Boot] [PATCH 05/18] efi: Fix efi_uintn_t for 64-bit EFI payload

On 06/10/2018 04:30 PM, Bin Meng wrote: > Hi Heinrich, > > On Sun, Jun 10, 2018 at 10:02 PM, Heinrich Schuchardt > wrote: >> On 06/10/2018 03:25 PM, Bin Meng wrote: >>> Since commit bb0bb91cf0aa ("efi_stub: Use efi_uintn_t"), EFI x86 >>> 64-bit payload does not work anymore. The call to GetMemory

Re: [U-Boot] [PATCH 04/18] x86: efi: payload: Enforce toolchain to generate 64-bit EFI payload stub codes

On 10.06.18 15:25, Bin Meng wrote: > Attempting to use a toolchain that is preconfigured to generate code > for the 32-bit architecture (i386), for example, the i386-linux-gcc > toolchain on kernel.org, to compile the 64-bit EFI payload does not > build. This updates the makefile fragments to ens

Re: [U-Boot] [PATCH 14/18] efi: stub: Pass EFI GOP information to U-Boot payload

On 10.06.18 15:25, Bin Meng wrote: > If UEFI BIOS has the graphics output protocol (GOP), let's pass its > information to U-Boot payload so that U-Boot can utilize it (eg: > an EFI framebuffer driver). > > Signed-off-by: Bin Meng Why can't the FB drive determine all of this on its own and just

[U-Boot] [PATCH] efi_loader: Convert runtime reset from switch to if statements

We currently handle the UEFI runtime reset / power off case handling via a switch statement. Compilers (gcc in my case) may opt to handle these via jump tables which they may conveniently put into .rodata which is not part of the runtime section, so it will be unreachable when executed. Fix this b

Re: [U-Boot] [PATCH 14/18] efi: stub: Pass EFI GOP information to U-Boot payload

On Mon, Jun 11, 2018 at 3:16 AM, Alexander Graf wrote: > > > On 10.06.18 15:25, Bin Meng wrote: >> If UEFI BIOS has the graphics output protocol (GOP), let's pass its >> information to U-Boot payload so that U-Boot can utilize it (eg: >> an EFI framebuffer driver). >> >> Signed-off-by: Bin Meng >

Re: [U-Boot] [PATCH 05/18] efi: Fix efi_uintn_t for 64-bit EFI payload

Hi Heinrich, On Mon, Jun 11, 2018 at 2:17 AM, Heinrich Schuchardt wrote: > On 06/10/2018 04:30 PM, Bin Meng wrote: >> Hi Heinrich, >> >> On Sun, Jun 10, 2018 at 10:02 PM, Heinrich Schuchardt >> wrote: >>> On 06/10/2018 03:25 PM, Bin Meng wrote: Since commit bb0bb91cf0aa ("efi_stub: Use efi_

Re: [U-Boot] [PATCH 04/18] x86: efi: payload: Enforce toolchain to generate 64-bit EFI payload stub codes

On Mon, Jun 11, 2018 at 3:11 AM, Alexander Graf wrote: > > > On 10.06.18 15:25, Bin Meng wrote: >> Attempting to use a toolchain that is preconfigured to generate code >> for the 32-bit architecture (i386), for example, the i386-linux-gcc >> toolchain on kernel.org, to compile the 64-bit EFI paylo

[U-Boot] [PATCH V2] dm: gpio: Add DM compatibility to GPIO driver for Davinci

This adds DM_GPIO support for the davinici GPIO driver with DT support. Signed-off-by: Adam Ford diff --git a/arch/arm/mach-davinci/include/mach/gpio.h b/arch/arm/mach-davinci/include/mach/gpio.h index f1d4d9e9e0..d4b25c3d60 100644 --- a/arch/arm/mach-davinci/include/mach/gpio.h +++ b/arch/arm/

Re: [U-Boot] [PATCH v2 3/3] common: Generic loader for file system

On Thu, 2018-06-07 at 12:29 +0200, Marek Vasut wrote: > On 06/07/2018 12:11 PM, Chee, Tien Fong wrote: > > > > On Thu, 2018-06-07 at 11:50 +0200, Marek Vasut wrote: > > > > > > On 06/07/2018 11:45 AM, Chee, Tien Fong wrote: > > > > > > > > > > > > On Thu, 2018-06-07 at 10:41 +0200, Marek Vasut

Re: [U-Boot] [PATCH 4/5] include: dma: Update the function description for dma_memcpy

On Fri, 2018-06-08 at 13:59 -0800, Simon Glass wrote: > Hi, > > On 3 June 2018 at 23:14, Chee, Tien Fong > wrote: > > > > On Fri, 2018-06-01 at 08:25 -0600, Simon Glass wrote: > > > > > > Hi, > > > > > > On 31 May 2018 at 02:08,   wrote: > > > > > > > > > > > > From: Tien Fong Chee > > > >

Re: [U-Boot] ls1021atwr: Convert to use driver model TSEC driver

On Tue, Jun 5, 2018 at 9:28 AM, Bin Meng wrote: > Hi Alison, Prabhakar, > > On Fri, Jun 1, 2018 at 12:06 PM, York Sun wrote: >> On May 31, 2018, at 20:58, Bin Meng wrote: >>> >>> Hi, >>> On Wed, May 30, 2018 at 11:06 AM, York Sun wrote: Alison and Prabhakar, Please take a lo

Re: [U-Boot] [PATCH 14/18] efi: stub: Pass EFI GOP information to U-Boot payload

On 11.06.18 01:29, Bin Meng wrote: > On Mon, Jun 11, 2018 at 3:16 AM, Alexander Graf wrote: >> >> >> On 10.06.18 15:25, Bin Meng wrote: >>> If UEFI BIOS has the graphics output protocol (GOP), let's pass its >>> information to U-Boot payload so that U-Boot can utilize it (eg: >>> an EFI framebuf

Re: [U-Boot] [PATCH 04/18] x86: efi: payload: Enforce toolchain to generate 64-bit EFI payload stub codes

On 11.06.18 04:34, Bin Meng wrote: > On Mon, Jun 11, 2018 at 3:11 AM, Alexander Graf wrote: >> >> >> On 10.06.18 15:25, Bin Meng wrote: >>> Attempting to use a toolchain that is preconfigured to generate code >>> for the 32-bit architecture (i386), for example, the i386-linux-gcc >>> toolchain o

Re: [U-Boot] [PATCH 14/18] efi: stub: Pass EFI GOP information to U-Boot payload

Hi Alex, On Mon, Jun 11, 2018 at 1:52 PM, Alexander Graf wrote: > > > On 11.06.18 01:29, Bin Meng wrote: >> On Mon, Jun 11, 2018 at 3:16 AM, Alexander Graf wrote: >>> >>> >>> On 10.06.18 15:25, Bin Meng wrote: If UEFI BIOS has the graphics output protocol (GOP), let's pass its informat

Re: [U-Boot] [PATCH 04/18] x86: efi: payload: Enforce toolchain to generate 64-bit EFI payload stub codes

Hi Alex, On Mon, Jun 11, 2018 at 1:55 PM, Alexander Graf wrote: > > > On 11.06.18 04:34, Bin Meng wrote: >> On Mon, Jun 11, 2018 at 3:11 AM, Alexander Graf wrote: >>> >>> >>> On 10.06.18 15:25, Bin Meng wrote: Attempting to use a toolchain that is preconfigured to generate code for the

[U-Boot] [PATCH] microblaze: Remove architecture heart beat code

There is no reason to keep this gpio based code in architecture. Use ledtrig-heartbeat.c instead which is much more flexible then this ancient code. Signed-off-by: Michal Simek --- arch/microblaze/Kconfig.debug | 7 arch/microblaze/include/asm/setup.h | 3 -- arch/microblaze/kernel

Re: [U-Boot] [PATCH 1/4] lib: fdtdec: Fill initial ram top with DDR start value from dt

On 8.6.2018 23:59, Simon Glass wrote: > Hi, > > > On 7 June 2018 at 06:18, Michal Simek wrote: >> Hi, >> >> On 5.6.2018 09:20, Siva Durga Prasad Paladugu wrote: >>> Fill initial ram top with DDR base addr value from DT as not filling >>> it here always assumes it as zero while calculating reloca

Re: [U-Boot] [PATCH] cmd: fpga: Remove fit image support passed without fpga device

On 8.6.2018 23:59, Simon Glass wrote: > +Tom > > Hi, > > On 5 June 2018 at 04:47, Michal Simek wrote: >> The patch applied in 2010 >> "cmd_fpga: cleanup help and check parameters" >> (sha1: a790b5b2326be9d7c9ad9e3d9b51a8bfabc62d07" >> was adding this checking >> >> + if (dev == FPGA_INVALI

Re: [U-Boot] [PATCH v2] arm64: zynqmp: accept an absolute path for PMUFW_INIT_FILE

On 8.6.2018 15:02, Emmanuel Vadot wrote: > On Fri, 8 Jun 2018 08:28:02 +0200 > Michal Simek wrote: > >> On 4.6.2018 12:21, Luca Ceresoli wrote: >>> The value of PMUFW_INIT_FILE is prefixed with "$(srctree)/", thus >>> forcing it to be a relative path inside the U-Boot source tree. Since >>> the P