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
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
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
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
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
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
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
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
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
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
> > > >
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
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/
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
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_
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
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 +-
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
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
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
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
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_
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
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
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
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
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
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
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/
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
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
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
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
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
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 --
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
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,
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
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
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
57 matches
Mail list logo