Am 2018-06-07 11:07, schrieb Bastian Germann:
Hello Michael,
I tried to use the MTD layer but that did not work even though I set
the
flash in the Linux device tree read-write. I cannot remember the output
exactly as it is some time ago that I tried (with Debian).
Cheers,
Bastian
+ flashro
> 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.
>
> The PE standard allows for HI20/LOW12 relocations. Within the efi_loader
> target we always know that our relocation target is 4k aligned, so we
> don't need to worry about the LOW12 part.
>
> This patch adds support for the respective relocations. With this and a
> few grub patches I have cooki
On 12.06.18 07:26, Simon Glass wrote:
> With sandbox the U-Boot code is not mapped into the sandbox memory range
> so does not need to be excluded when allocating EFI memory. Update the EFI
> memory init code to take account of that.
>
> Also use mapmem instead of a cast to convert a memory addr
On 12.06.18 07:26, Simon Glass wrote:
> At present this code casts addresses to pointers so cannot be used with
> sandbox. Update it to use mapmem instead.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> - Drop incorrect map_sysmem() in wri
On 12.06.18 07:26, Simon Glass wrote:
> With sandbox these values depend on the host system. Let's assume that it
> is x86_64 for now.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
> include/config_distro_boot
On 12.06.18 07:26, Simon Glass wrote:
> Add these so that we can build the EFI loader for sandbox. The values are
> for x86_64 so potentially bogus. But we don't support relocation within
> sandbox anyway.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v5: None
> Changes in v4: None
> Cha
When we boot using memdp (bootefi on an address without previous
load that populates the device path) then the memory device path
we pass in is not backed by any handle.
That can result in weird effects. For example grub gets very grumpy
about this inside the efi_net module and just loops endlessl
This adds some enhancements to the Intel Cougar Canyon 2 board.
This series is available at u-boot-x86/cc2-working for testing.
Changes in v2:
- drop patches that were applied to u-boot-x86
- drop v1 patches using Kconfig option CONFIG_DISCRETE_PIRQ_ROUT
- new patch to "parse number of PIRQ links
The "intel,pirq-link" property in Intel IRQ router's dt bindings
has two cells, where the second one represents the number of PIRQ
links on the platform. However current driver does not parse this
information from device tree. This adds the codes to do the parse
and save it for future use.
Signed-
Currently both pirq_reg_to_linkno() and pirq_linkno_to_reg() assume
consecutive PIRQ routing control registers. But this is not always
the case on some platforms. Introduce a new device tree property
intel,pirq-regmap to describe how the PIRQ routing register offset
is mapped to the link number and
Add Panther Point chipset interrupt pin/PIRQ information, and
enable the generation of PIRQ routing table and MP table.
Signed-off-by: Bin Meng
---
Changes in v2:
- add the PIRQ register mapping via "intel,pirq-regmap" property
arch/x86/dts/cougarcanyon2.dts | 46
Hi York Sun
please help review, if no issue, would you help me merge it to upstream.
Thanks.
Regards
Yinbo
-Original Message-
From: Yinbo Zhu
Sent: 2018年5月21日 12:05
To: yinbo@nxp.com; u-boot@lists.denx.de; York Sun
Cc: Xiaobo Xie ; Jerry Huang ; Ran
Wang
Subject: RE: [PATCH v1] EH
On 12.06.18 07:26, Simon Glass wrote:
> This jumps to test code which can call directly into the EFI support. It
> does not need a separate image so it is easy to write tests with it.
>
> This test can be executed without causing problems to the run-time
> environemnt (e.g. U-Boot does not need
On June 11, 2018 10:38:45 PM GMT+03:00, Simon Glass wrote:
>Hi Ramon,
>
>On 11 June 2018 at 13:14, Ramon Fried wrote:
>>
>>
>> On Mon, Jun 11, 2018 at 5:53 PM, Simon Glass
>wrote:
>>>
>>> Hi Ramon,
>>>
>>> On 9 June 2018 at 03:06, Ramon Fried wrote:
>>> > The Shared Memory Manager driver implem
On 12.6.2018 07:31, Masahiro Yamada wrote:
> 2018-06-12 14:26 GMT+09:00 Masahiro Yamada :
>> Hi Siva, Michal.
>>
>>
>> I noticed drivers/mmc/sdhci-cadence.c
>> not working for my boards.
>>
>>
>> git-bisect points the following commit:
>>
>>
>>
>> commit 434f9d454eb1a17bb7f5cdb21167ccbe7e41da39
>>
On Tue, Jun 12, 2018 at 1:54 PM, Alexander Graf wrote:
> Currently efi.h determines a few bits of its environment according to
> config options. This falls apart with the efi stub support which may
> result in efi.h getting pulled into the stub as well as real U-Boot
> code. In that case, one may
Hi,
On 08/06/2018 23:59, Simon Glass wrote:
Hi,
On 7 June 2018 at 01:39, Lukasz Majewski wrote:
Hi Jean-Jacques,
Most of the time the UDC is bound to a driver when a dedicated
command is executed, like 'dfu'. But the ethernet gadget driver must
be bound by calling usb_ether_init() in the c
Hi Marek,
Do you plan to take this series or does it need some rework?
I'm hoping to build on it to support DM_USB on the TI platforms.
JJ
On 29/05/2018 14:36, Jean-Jacques Hiblot wrote:
This series aims at bringing improvements to the dwc3_generic driver so
that it can be used by most of th
On 11.6.2018 13:40, Siva Durga Prasad Paladugu wrote:
> This patch basically adds two new commands for loadig secure
> images/bitstreams.
> 1. zynq rsa adds support to load secure image which can be both
>authenticated or encrypted or both authenticated and encrypted
>image in xilinx bootim
Hi Stefano, Fabio,
Sorry for the bother in patch 1, that patch is big. So ask here.
Do you have any comments on the patchset?
Thanks,
Peng
> -Original Message-
> From: Peng Fan
> Sent: 2018年5月28日 20:25
> To: sba...@denx.de; Fabio Estevam
> Cc: u-boot@lists.denx.de; Peng Fan
> Subject:
Hi Masahiro,
Can you please try with this below change and let me know if it works.
In our case, we don’t want to read tuning pattern, instead it waits for
TUNED_CLK bit to be set in host ctrl2 register. But, in your case, you want to
read back the pattern data and compare it.
--- a/drivers/m
Hi Siva,
2018-06-12 18:44 GMT+09:00 Siva Durga Prasad Paladugu :
> Hi Masahiro,
>
> Can you please try with this below change and let me know if it works.
> In our case, we don’t want to read tuning pattern, instead it waits for
> TUNED_CLK bit to be set in host ctrl2 register. But, in your case,
Since commit 508d8567046f ("efi_selftest: allow building relocation code
on x86_64") we can build the miniapp test cases without error on x86_64.
But they are incompatible to the upcoming patches for the Sandbox.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_selftest/Makefile | 4 +---
1 file
Hi Seung-Woo,
> After the commit 265edc03d5a1 ("fs/fat: Clean up open-coded sector
> <-> cluster conversions"), it is hung up writing new file to FAT16
> disk with more than 19 files in armv7. It is because result value
> of sect_to_cluster() is not proper by casting from signed value to
> unsigne
On 12.06.2018 02:39, dgilm...@redhat.com wrote:
From: Dennis Gilmore
The helios4 is built on the SolidRun Armada 38x SOM.
The port os based on the ClearFog board, using information from
https://github.com/helios-4/u-boot-marvell as well as dtb input
from https://github.com/helios-4/linux-marvel
Hi Tom,
please pull the Helios4 Armada 38x support from Dennis, which was
posted in v3 a few days ago.
Thanks,
Stefan
The following changes since commit 813d1fb56dc0af9567feb86cd71c49f14662044b:
Merge branch 'master' of git://git.denx.de/u-boot-ubi (2018-06-08 10:08:20
-0400)
are available
Hi Seung-Woo,
> After the commit 6aae84769a0b ("gadget: f_thor: Fix memory leaks of
> usb request and its buffer"), there is hang-up with ctrl-c in some
> udc. It is because req of out_ep is freed before out_ep is disabled.
> Fix hang-up with ctrl-c by disabling ep before free req of the ep.
>
>
This patch fixes the mmc tuning command failures
when tuning pattern data needs to read back for
comparision against the excpected bit pattern.
Signed-off-by: Siva Durga Prasad Paladugu
---
drivers/mmc/sdhci.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mm
Hi Ivan,
On Fri, Jun 1, 2018 at 2:46 AM, Ivan Gorinov wrote:
> UEFI specifies the calling convention used in Microsoft compilers;
> first arguments of a function are passed in (%rcx, %rdx, %r8, %r9).
>
> All other compilers use System V ABI by default, passing first integer
> arguments of a funct
2018-06-12 21:00 GMT+09:00 Siva Durga Prasad Paladugu
:
> This patch fixes the mmc tuning command failures
> when tuning pattern data needs to read back for
> comparision against the excpected bit pattern.
>
Typo:
excpected -> expected
Reported-by: Masahiro Yamada
> Signed-off-by: Siva Durg
On Mon, Jun 11, 2018 at 10:53 PM, Simon Glass wrote:
> On 10 June 2018 at 05:25, Bin Meng wrote:
>> 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
On Mon, Jun 11, 2018 at 10:53 PM, Simon Glass wrote:
> On 10 June 2018 at 05:25, Bin Meng wrote:
>> 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.
>>
>> E
On Mon, Jun 11, 2018 at 10:53 PM, Simon Glass wrote:
> On 10 June 2018 at 05:25, Bin Meng wrote:
>> 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 de
On Mon, Jun 11, 2018 at 10:54 PM, Simon Glass wrote:
> On 10 June 2018 at 05:25, Bin Meng wrote:
>> 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 d
On Mon, Jun 11, 2018 at 10:54 PM, Simon Glass wrote:
> On 10 June 2018 at 05:25, Bin Meng wrote:
>> 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.
>>
>> Sign
On Mon, Jun 11, 2018 at 10:53 PM, Simon Glass wrote:
> On 10 June 2018 at 05: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 pay
Hi Alex,
On 12 June 2018 at 02:05, Alexander Graf wrote:
>
>
> On 12.06.18 07:26, Simon Glass wrote:
>> With sandbox the U-Boot code is not mapped into the sandbox memory range
>> so does not need to be excluded when allocating EFI memory. Update the EFI
>> memory init code to take account of tha
Hi Alex,
On 12 June 2018 at 02:12, Alexander Graf wrote:
>
>
> On 12.06.18 07:26, Simon Glass wrote:
>> At present this code casts addresses to pointers so cannot be used with
>> sandbox. Update it to use mapmem instead.
>>
>> Signed-off-by: Simon Glass
>> ---
>>
>> Changes in v5: None
>> Change
Hi Alex,
On 12 June 2018 at 02:13, Alexander Graf wrote:
>
>
> On 12.06.18 07:26, Simon Glass wrote:
>> With sandbox these values depend on the host system. Let's assume that it
>> is x86_64 for now.
>>
>> Signed-off-by: Simon Glass
>> ---
>>
>> Changes in v5: None
>> Changes in v4: None
>> Chan
Hi Alex,
On 12 June 2018 at 02:28, Alexander Graf wrote:
>
>
> On 12.06.18 07:26, Simon Glass wrote:
>> This jumps to test code which can call directly into the EFI support. It
>> does not need a separate image so it is easy to write tests with it.
>>
>> This test can be executed without causing
On 12.06.18 15:48, Simon Glass wrote:
> Hi Alex,
>
> On 12 June 2018 at 02:05, Alexander Graf wrote:
>>
>>
>> On 12.06.18 07:26, Simon Glass wrote:
>>> With sandbox the U-Boot code is not mapped into the sandbox memory range
>>> so does not need to be excluded when allocating EFI memory. Update
On 12.06.18 15:48, Simon Glass wrote:
> Hi Alex,
>
> On 12 June 2018 at 02:12, Alexander Graf wrote:
>>
>>
>> On 12.06.18 07:26, Simon Glass wrote:
>>> At present this code casts addresses to pointers so cannot be used with
>>> sandbox. Update it to use mapmem instead.
>>>
>>> Signed-off-by: Si
On 12.06.18 15:48, Simon Glass wrote:
> Hi Alex,
>
> On 12 June 2018 at 02:13, Alexander Graf wrote:
>>
>>
>> On 12.06.18 07:26, Simon Glass wrote:
>>> With sandbox these values depend on the host system. Let's assume that it
>>> is x86_64 for now.
>>>
>>> Signed-off-by: Simon Glass
>>> ---
>>
Hi Peng,
On Tue, Jun 12, 2018 at 6:43 AM, Peng Fan wrote:
> Hi Stefano, Fabio,
>
> Sorry for the bother in patch 1, that patch is big. So ask here.
> Do you have any comments on the patchset?
It would be better if you could split this 41 patch series into smaller pieces.
For example: you could
> These constants are defined in arch-specific code but redefined here. Add
> a TODO to clean this up.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Heinrich Schuchardt
Thanks, applied to efi-next
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
ht
On 12.06.18 15:48, Simon Glass wrote:
> Hi Alex,
>
> On 12 June 2018 at 02:28, Alexander Graf wrote:
>>
>>
>> On 12.06.18 07:26, Simon Glass wrote:
>>> This jumps to test code which can call directly into the EFI support. It
>>> does not need a separate image so it is easy to write tests with i
Hi Miquèl,
On 06.06.2018 17:30, Miquel Raynal wrote:
During the last months, Boris Brezillon shared his work to support
serial flashes within Linux. First, he delivered (and merged) a new
layer called spi-mem. He also initiated in Linux MTD subsystem the move
of all 'raw' NAND related code to a
On Sat, Jun 9, 2018 at 6:43 PM, Bin Meng wrote:
> Hi Heinrich,
>
> On Sat, Jun 9, 2018 at 6:02 PM, Heinrich Schuchardt
> wrote:
>> Hello Bin,
>>
>> tools/buildman/buildman fails with
>>
>> arch/x86/dts/cherryhill.dtb: Warning (avoid_unnecessary_addr_size):
>> /pci/pch@1f,0: unnecessary #address-
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
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.
This updates the x86 doc to reference both README.u-boot_on_efi and
README.uefi.
Signed-off-by: Bin Meng
-
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
From: Alexander Graf
Currently efi.h determines a few bits of its environment according to
config options. This falls apart with the efi stub support which may
result in efi.h getting pulled into the stub as well as real U-Boot
code. In that case, one may be 32bit while the other one is 64bit.
T
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
This turns on the EFI framebuffer driver support so that a graphics
console can be of additional help.
Signed-off-by: Bin Meng
Reviewed-by: Simon Glass
---
Changes in v2: None
arch/x86/dts/efi-x86_payload.dts | 4
board/efi/efi-x86_payload/Kconfig | 1 +
2 files changed, 5 insertions(+)
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
Now that we have generic EFI payload support for all x86 boards,
drop the QEMU-specific one.
Signed-off-by: Bin Meng
Reviewed-by: Simon Glass
---
Changes in v2:
- update QEMU MAINTAINERS file to remove defconfig files
arch/x86/cpu/qemu/Makefile | 2 --
arch/x86/cpu/qemu/qemu.c
This adds arch_cpu_init() to the payload codes, in preparation for
supporting a generic efi payload.
Signed-off-by: Bin Meng
Reviewed-by: Simon Glass
---
Changes in v2: None
arch/x86/cpu/efi/payload.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86/cpu
To avoid confusion, let's rename the efi-x86 target to efi-x86_app.
Signed-off-by: Bin Meng
Reviewed-by: Simon Glass
---
Changes in v2:
- update README.u-boot_on_efi to use efi-x86_app
arch/x86/cpu/efi/Makefile| 2 +-
arch/x86/cpu/efi/{efi.c => app.c}
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
Reviewed-by: Simon Glass
---
Changes in v2: None
include/efi.h | 35 +++
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
Reviewed-by: Simon Glass
---
Changes in v2: None
arch/x86/cpu/baytrail/Kconfig | 6 +++---
arch/x86/cpu/baytrail/val
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
Reviewed-by: Simon Glass
---
Changes in v2:
- drop patches that were already applied to u-boot-x86
arch/x86/cpu/efi/app.c | 2 +-
Hi Alex,
On Tue, Jun 12, 2018 at 5:21 PM, Bin Meng wrote:
> On Tue, Jun 12, 2018 at 1:54 PM, Alexander Graf wrote:
>> Currently efi.h determines a few bits of its environment according to
>> config options. This falls apart with the efi stub support which may
>> result in efi.h getting pulled in
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
Reviewed-by: Anatolij Gustschin
---
Changes in v2:
On Tue, Jun 12, 2018 at 01:21:59PM +0200, Stefan Roese wrote:
> Hi Tom,
>
> please pull the Helios4 Armada 38x support from Dennis, which was
> posted in v3 a few days ago.
>
> Thanks,
> Stefan
>
>
> The following changes since commit 813d1fb56dc0af9567feb86cd71c49f14662044b:
>
> Merge bran
car.o can only be used with start.o, not with start64.o.
So on qemu 64bit it should only be built for 32bit SPL but not for u-boot.
Without this patch but with an unrelated pending patch
("x86: Add 64-bit setjmp/longjmp implementation") the
following error occurred for qemu-x86_64_defconfig:
arc
On 06/06/2018 08:28 PM, Ivan Gorinov wrote:
> Add setjmp/longjmp functions for x86_64.
> The FPU control word and MXCSR control bits are preserved across calls.
With this patch
make mrproper && make qemu-x86_64_defconfig && make -j6
produces
arch/x86/cpu/built-in.o: In function `car_init':
arch
On 06/12/2018 05:36 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.
>
> This updates the x86 doc to reference both README.u-boot_o
Tom,
I have fixed the issues you caught earlier, and pass compiling
https://travis-ci.org/yorksun/u-boot/builds/390939575
The following changes since commit 71002b508a1bc0986023764f155f0db26f548db2:
cmd: add missing line breaks for pr_err() (2018-06-07 20:06:29 -0400)
are available in the git
The current code that switches into HYP mode doesn't bother to set
up a stack for HYP mode. This doesn't work for EFI applications
as they expect a usable stack. Fix this by saving the stack
pointer before switching and use it to set SP_hyp from monitor.
This restores the stack pointer when we dr
This reverts commit c524997acb3d322e1bbd36c06ad02ef589705e7c.
Booting ARMv7 in non-secure mode using bootefi works now.
Signed-off-by: Mark Kettenis
---
doc/README.uefi| 2 --
lib/efi_loader/Kconfig | 2 --
2 files changed, 4 deletions(-)
diff --git a/doc/README.uefi b/doc/README.uefi
If desired (and possible) switch into HYP mode or non-secure SVC mode
before calling the entry point of an EFI application. This allows
U-Boot to provide a usable PSCI implementation and makes it possible
to boot kernels into hypervisor mode using an EFI bootloader.
Based on diffs from Heinrich S
This series makes it possible to run EFI applications in non-secure
mode. It allows me to run OpenBSD on the imx7d-pico-pi board while
using the PSCI implementation provided by U-Boot.
Mark Kettenis (3):
ARM: HYP/non-sec: save and restore stack
efi_loader: ARM: run EFI payloads non-secure
R
> From: Alexander Graf
> Date: Fri, 6 Apr 2018 09:48:06 +0200
>
> On 06.04.18 07:43, Heinrich Schuchardt wrote:
> > Booting with SMP fails on the Allwinner A20 CPU.
> > https://gist.github.com/xypron/2524ba898d6905d959c744c2b05da196
> >
> > When executing bootefi we need to
> > * copy the Power
UEFI specifies the calling convention used in Microsoft compilers;
first arguments of a function are passed in (%rcx, %rdx, %r8, %r9).
All other compilers use System V ABI by default, passing first integer
arguments of a function in (%rdi, %rsi, %rdx, %rcx, %r8, %r9).
These ABI also specify diffe
UEFI specifies the calling convention used in Microsoft compilers;
first arguments of a function are passed in (%rcx, %rdx, %r8, %r9).
All other compilers use System V ABI by default, passing first integer
arguments of a function in (%rdi, %rsi, %rdx, %rcx, %r8, %r9).
These ABI also specify diffe
EFI image handle and system table are not used in _relocate().
Signed-off-by: Ivan Gorinov
---
arch/arm/lib/crt0_aarch64_efi.S | 2 --
arch/arm/lib/crt0_arm_efi.S | 2 --
arch/arm/lib/reloc_aarch64_efi.c | 3 +--
arch/arm/lib/reloc_arm_efi.c | 3 +--
4 files changed, 2 insertions(+), 8
EFI image handle and system table are not used in _relocate().
Signed-off-by: Ivan Gorinov
---
arch/x86/lib/reloc_ia32_efi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/x86/lib/reloc_ia32_efi.c b/arch/x86/lib/reloc_ia32_efi.c
index e838af3..49a0b94 100644
--- a/arc
EFI image handle and system table are not used in _relocate().
Signed-off-by: Ivan Gorinov
---
arch/riscv/lib/reloc_riscv_efi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/riscv/lib/reloc_riscv_efi.c b/arch/riscv/lib/reloc_riscv_efi.c
index 8b4b2b1..51b7520 100644
On 06/12/2018 07:27 PM, Mark Kettenis wrote:
> This series makes it possible to run EFI applications in non-secure
> mode. It allows me to run OpenBSD on the imx7d-pico-pi board while
> using the PSCI implementation provided by U-Boot.
>
> Mark Kettenis (3):
> ARM: HYP/non-sec: save and restore
On Mon, May 28, 2018 at 7:25 AM, Peng Fan wrote:
> The MIB RAM and FIFO receive start register does not exist on
> i.MX8. Accessing these register will cause SERROR.
>
> Signed-off-by: Peng Fan
> Cc: Joe Hershberger
Acked-by: Joe Hershberger
___
U-Bo
Hi Peng,
On Mon, May 28, 2018 at 7:25 AM, Peng Fan wrote:
> From: Ye Li
>
> When the power domain driver is enabled, we need to enable clocks after power
> domain on. So the clock settings can't set in board_init, needs to set them
> when the device is probed. Add this weak function in driver, t
On Mon, Jun 4, 2018 at 5:31 AM, Jean-Jacques Hiblot wrote:
> When a USB ethernet device is halted, the device driver is removed. When
> this happens the uclass private memory is freed and uclass_priv is set to
> NULL. This causes a data abort when uclass_priv->state is then set to
> ETH_STATE_PASS
On Mon, Jun 4, 2018 at 5:17 AM, Quentin Schulz
wrote:
> On the SPEAr600 SoC, which has the dwmac1000 variant of the IP block,
> the DMA reset never succeeds when a MII PHY is used (no problem with a
> GMII PHY). The designware_eth_init() function sets the
> DMAMAC_SRST bit in the DMA_BUS_MODE regi
On 12.06.18 19:27, Mark Kettenis wrote:
> The current code that switches into HYP mode doesn't bother to set
> up a stack for HYP mode. This doesn't work for EFI applications
> as they expect a usable stack. Fix this by saving the stack
> pointer before switching and use it to set SP_hyp from m
On 12.06.18 19:27, Mark Kettenis wrote:
> If desired (and possible) switch into HYP mode or non-secure SVC mode
> before calling the entry point of an EFI application. This allows
> U-Boot to provide a usable PSCI implementation and makes it possible
> to boot kernels into hypervisor mode using
On 12.06.18 19:51, Ivan Gorinov wrote:
> UEFI specifies the calling convention used in Microsoft compilers;
> first arguments of a function are passed in (%rcx, %rdx, %r8, %r9).
>
> All other compilers use System V ABI by default, passing first integer
> arguments of a function in (%rdi, %rsi, %
Hi,
I see a strange problem with `saveenv` on Raspberry Pi 3 platform.
Other Raspberry Pi (0/w/2) device work well with `saveenv`.
After I call the `saveenv` command, the device going into `fsm 1, hsts
0001` loop. I try it with env file on ext/fat and on mmc.
Here is the bug report:
https://
On 12.06.18 17:36, 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, efi_uintn_t get
menting in u-boot,
I am starting to wonder if we should also be doing this in kernel. ->
following is an example:
for OMAP5uEVM (dual A15) with next-20180612 -> Uboot does setup the
IBE bit, so the
CPU0 ICIALLU does get activated however, that is not true for CPU1.
Further if we enter
On 12.06.18 17:33, Bin Meng wrote:
> Hi Alex,
>
> On Tue, Jun 12, 2018 at 5:21 PM, Bin Meng wrote:
>> On Tue, Jun 12, 2018 at 1:54 PM, Alexander Graf wrote:
>>> Currently efi.h determines a few bits of its environment according to
>>> config options. This falls apart with the efi stub support
On Wed, Jun 6, 2018 at 7:32 AM, Alexander Graf wrote:
> Currently we can choose between 2 different types of behavior for the
> serverip variable:
>
> 1) Always overwrite it with the DHCP server IP address (default)
> 2) Ignore what the DHCP server says (CONFIG_BOOTP_SERVERIP)
>
> This patch a
On Wed, Jun 6, 2018 at 8:54 PM, Rick Chen wrote:
>> From: Alexander Graf [mailto:ag...@suse.de]
>> Sent: Wednesday, June 06, 2018 8:32 PM
>> To: u-boot@lists.denx.de
>> Cc: Rick Jian-Zhi Chen(陳建志); Joe Hershberger; Simon Glass
>> Subject: [PATCH 1/2] net: Add option to prefer bootp/dhcp serverip
>
On Fri, Jun 1, 2018 at 3:45 AM, Ley Foon Tan wrote:
> Add code to reset all reset signals as in Ethernet DT node. A reset property
> is an optional feature,
> so only print out a warning and do not fail if a reset property is not
> present.
>
> If a reset property is discovered, then use it to d
> From: Alexander Graf
> Date: Tue, 12 Jun 2018 20:46:02 +0200
>
> On 12.06.18 19:27, Mark Kettenis wrote:
> > The current code that switches into HYP mode doesn't bother to set
> > up a stack for HYP mode. This doesn't work for EFI applications
> > as they expect a usable stack. Fix this by sa
Enable CVE_2017_5715 and since we have our own v7_arch_cp15_set_acr
function to setup the bits, we are able to override the settings.
Without this enabled, Linux kernel reports:
CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit,
system vulnerable
With this enabled, Linux
Enable CVE-2017-5715 option to set the IBE bit. This enables kernel
workarounds necessary for the said CVE.
With this enabled, Linux reports:
CPU0: Spectre v2: using BPIALL workaround
This workaround may need to be re-applied in OS environment around low
power transition resume states where conte
As recommended by Arm in [1], ACTLR[0] (Enable invalidates of BTB)
needs to be set[2] for BTB to be invalidated on ICIALLU. This needs to
be done unconditionally for Cortex-A15 processors. Provide a config
option for platforms to enable this option based on impact analysis
for products.
NOTE: This
lution and is based on recommendation
This from Arm[2] for variant 2 CVE-2017-5715 -> Kernel changes can be seen on
linux next (next-20180612) or on linux master (upcoming v4.18-rc1 tag).
* I think it is necessary on older SoCs without firmware support
(such as older OMAPs and AM*) to hav
As recommended by Arm in [1], IBE[2] has to be enabled unconditionally
for BPIALL to be functional on Cortex-A8 processors. Provide a config
option for platforms to enable this option based on impact analysis
for products.
NOTE: This patch in itself is NOT the final solution, this requires:
a) Imp
1 - 100 of 197 matches
Mail list logo
