Returns the memory configuration for Renesas R8A7795 (R-Car H3) SoCs,
revision 3.0 and up.
Signed-off-by: Ulrich Hecht
---
See "[RFC] ARM: rmobile: create DT memory nodes for R8A7795 3.0 and newer"
for an explanation of this.
CU
Uli
include/services/arm_arch_svc.h| 1 +
services/
Hi Marek,
On Friday, 15 June 2018 15:00:31 EEST Marek Vasut wrote:
> On 06/15/2018 01:43 PM, Marek Vasut wrote:
> > On 06/15/2018 12:37 PM, Ulrich Hecht wrote:
> >> On Fri, Jun 15, 2018 at 12:09 PM, Marek Vasut
wrote:
> + arm_smccc_smc(ARM_SMCCC_RENESAS_MEMCONF,
> +
Hello,
I am working on a custom board, that is based on the NXP T2080 processor.
We have been experiencing issues with our loading process which utilizes tftp
to retrieve images for loading into NAND.
The vast majority of the attempts result in "Loading: *" or "Loading: #" with
no further output
On Fri, Jun 15, 2018 at 12:09 PM, Marek Vasut wrote:
>> + arm_smccc_smc(ARM_SMCCC_RENESAS_MEMCONF,
>> + 0, 0, 0, 0, 0, 0, 0, &res);
>
> Will this call work on platforms without patched ATF ?
> (I think not, don't you need to handle return value?)
I have not a
Hi Miquel, Simon,
Is there any specific reason why the new tpm2_tis_spi_xfer doesn't support full
duplex? It seems we did some work in parallel but you sent the patches earlier.
Is that codes tested against an existing TPM v2? I have a working
implementation what runs on SLB9670 including full
Uses an SMC call to the ATF to determine the memory configuration, then
creates appropriate DT memory nodes.
Signed-off-by: Ulrich Hecht
---
This is an attempt to avoid having to have a ton of different device trees
for Renesas R8A7795 H3 SoCs from revision 3.0, which come in a number of
differen
Hello,
We have been looking at protecting U-Boot from (malicious) TFTP overwrites.
We want to do this after our ARMv7 U-Boot has relocated.
The memory map looks like this (I hope):
--- Top of DRAM
| U-Boot (Protected)
| -- U_Boot_start
| Heap (Prot
Hi,
After formatting SD card in fat16 format in windows, we are facing issue. I
used git bisect and came to know that this issue is due to
8eafae209c35932d9a6560809c55ee4641534236 commit.
When we use "gparted" utility for formatting SD card in fat16 in linux, it
works fine.
Please give your c
On Fri, Jun 15, 2018 at 01:14:08PM +, Alexey Brodkin wrote:
> Hi Tom,
>
> The following changes since commit 606fddd76c7a045c09d544357806b0b4de4845c7:
>
> Merge branch 'master' of git://git.denx.de/u-boot-net (2018-06-14 07:20:41
> -0400)
>
> are available in the Git repository at:
>
>
On Fri, Jun 15, 2018 at 02:53:58PM +0200, Michal Simek wrote:
> Hi Tom,
>
> please pull these changes to your tree.
> Buildman and travis looks good
> https://travis-ci.org/michalsimek/u-boot/builds/392586380
>
> Thanks,
> Michal
>
> The following changes since commit 606fddd76c7a045c09d5443578
On Thu, Jun 14, 2018 at 07:01:18PM +0200, Alexander Graf wrote:
> Hi Tom,
>
> This is my current patch queue for efi. Please pull.
>
> Alex
>
>
> The following changes since commit acaee30608ce203289a180d664b7f0abb2e64ee7:
>
> ARM: DTS: resync a3517.dtsi with Linux 4.17 (2018-06-13 07:49:1
The V3M Eagle uses flash with 128 kiB or 256 kiB sectors,
disable the 4k sector support.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
---
configs/r8a77970_eagle_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/r8a77970_eagle_defconfig b/configs/r8a77970_eagle_defconfig
Fix the CPGWPR/CPGWPCR register address on V3M Eagle to unlock
access to the CPG clock control registers.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
---
board/renesas/eagle/eagle.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/board/renesas/eagle/eagle.c b/boa
Turning the cache off can help when experimenting with bare metal
applications, enable the cache command on V3M Eagle to make that
easier.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
---
configs/r8a77970_eagle_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/r8a77970_e
Add EtherAVB PHY reset on V3M Eagle to let the AVB driver unreset the PHY.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
---
arch/arm/dts/r8a77970-eagle.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/dts/r8a77970-eagle.dts b/arch/arm/dts/r8a77970-eagle.dts
index 0c555b8dd
Add EtherAVB pinmux node on V3M Eagle to set the pinmux configuration.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
---
arch/arm/dts/r8a77970-eagle.dts | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/dts/r8a77970-eagle.dts b/arch/arm/dts/r8a77970-eagle.dts
index b75f38
On 06/16/2018 01:45 AM, Vasily Khoruzhick wrote:
> On Wed, Jun 13, 2018 at 11:19 PM, Vasily Khoruzhick
> wrote:
>> struct sunxi_ccm_reg doesn't have ahb_reset0_cfg on sun4i and sun5i,
>> thus compilation fails with:
>>
>> drivers/usb/host/ohci-sunxi.c:96:26: error: 'struct sunxi_ccm_reg' has
>> n
The following changes since commit 7868909ed53ed41a945f7ed95ebb88aa252142ce:
Merge git://git.denx.de/u-boot-fsl-qoriq (2018-06-12 13:25:24 -0400)
are available in the Git repository at:
git://git.denx.de/u-boot-usb.git master
for you to fetch changes up to b9f34757db5dcde9ccfa6ce35705b025bc
On Wed, Jun 13, 2018 at 11:19 PM, Vasily Khoruzhick wrote:
> struct sunxi_ccm_reg doesn't have ahb_reset0_cfg on sun4i and sun5i,
> thus compilation fails with:
>
> drivers/usb/host/ohci-sunxi.c:96:26: error: 'struct sunxi_ccm_reg' has
> no member named 'ahb_reset0_cfg'
>
> Access this reg using i
On 06/16/2018 01:21 AM, Laurent Pinchart wrote:
> Hi Marek,
>
> On Friday, 15 June 2018 15:00:31 EEST Marek Vasut wrote:
>> On 06/15/2018 01:43 PM, Marek Vasut wrote:
>>> On 06/15/2018 12:37 PM, Ulrich Hecht wrote:
On Fri, Jun 15, 2018 at 12:09 PM, Marek Vasut
> wrote:
>> +
> From: Heinrich Schuchardt
> Date: Fri, 15 Jun 2018 22:35:58 +0200
>
> On 06/14/2018 10:50 PM, Mark Kettenis wrote:
> >> From: Heinrich Schuchardt
> >> Hello Mark,
> >>
> >> with this patch series running bootefi hello twice in sequence fails on
> >> the BananaPi.
> >>
> >> => bootefi hello
> >
This series makes it possible to run EFI applications in non-secure
mode. It allows me to run OpenBSD on the Technexion PICO-PI-IMX7 and
Banana Pi boards using the PSCI implementation provided by U-Boot.
The second version avoids using r3 to pass the original stack pointer.
For some reason that r
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
ARMV7_LPAE is required in order to enable the MMU in HYP mode.
And we really want to enable the MMU in HYP mode such that we can
enable the the caches. Otherwise U-Boot code (such as the EFI
implementation) that runs in HYP mode will run at a snils pace.
Signed-off-by: Mark Kettenis
---
arch/ar
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
Multiple EFI binaries may be executed in sequence. So if we already
are in non-secure mode after running the first one we should skip
the switching code since it no longer works once we're non-secure.
Signed-off-by: Mark Kettenis
---
cmd/bootefi.c | 6 +-
1 file changed, 5 insertions(+), 1
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 migrating the stack
pointer from SP_svc to SP_hyp while in Monitor mode.
This restores the stack pointer when we drop into
When running at 432 MHz, the Lamobo R1 DRAM tends to get corrupted under
stressing workloads. Reducing the clock rate to 384 MHz results in
significantly-improved stability.
One reliable way to trigger a corruption at 432 MHz is to run
I/O-intensive operations on an attached SATA disk. The same op
On 15.06.18 22:36, Joe Hershberger wrote:
> On Fri, Jun 15, 2018 at 3:33 PM, Alexander Graf wrote:
>>
>>
>> On 15.06.18 22:08, Joe Hershberger wrote:
>>> On Fri, Jun 15, 2018 at 3:24 AM, Alexander Graf wrote:
On 14.06.18 18:58, Joe Hershberger wrote:
> On Thu, Jun 14, 2018 at
On Fri, Jun 15, 2018 at 3:33 PM, Alexander Graf wrote:
>
>
> On 15.06.18 22:08, Joe Hershberger wrote:
>> On Fri, Jun 15, 2018 at 3:24 AM, Alexander Graf wrote:
>>>
>>>
>>> On 14.06.18 18:58, Joe Hershberger wrote:
On Thu, Jun 14, 2018 at 5:04 AM, Alexander Graf wrote:
> The ax25-ae350
On 06/14/2018 10:50 PM, Mark Kettenis wrote:
>> From: Heinrich Schuchardt
>> Hello Mark,
>>
>> with this patch series running bootefi hello twice in sequence fails on
>> the BananaPi.
>>
>> => bootefi hello
>> Scanning disk m...@01c0f000.blk...
>> Found 3 disks
>> WARNING: booting without device t
On 15.06.18 22:08, Joe Hershberger wrote:
> On Fri, Jun 15, 2018 at 3:24 AM, Alexander Graf wrote:
>>
>>
>> On 14.06.18 18:58, Joe Hershberger wrote:
>>> On Thu, Jun 14, 2018 at 5:04 AM, Alexander Graf wrote:
The ax25-ae350 target currently uses CONFIG_BOOTP_SERVERIP which means we
ig
On Fri, Jun 15, 2018 at 3:29 AM, Alexander Graf wrote:
> The ax25-ae350 target currently uses CONFIG_BOOTP_SERVERIP which means we
> ignore the DHCP provided TFTP ip address. This breaks every case where we
> do now provide a serverip environment variable.
>
> Instead, let's use the new CONFIG_BOO
On Fri, Jun 15, 2018 at 3:29 AM, Alexander Graf wrote:
> We can call commands like dhcp and bootp without arguments or with
> explicit command line arguments that really should tell the code where
> to look for files instead.
>
> Unfortunately, the current code simply overwrites command line argum
On Fri, Jun 15, 2018 at 3:29 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
On Fri, Jun 15, 2018 at 3:24 AM, Alexander Graf wrote:
>
>
> On 14.06.18 18:58, Joe Hershberger wrote:
>> On Thu, Jun 14, 2018 at 5:04 AM, Alexander Graf wrote:
>>> The ax25-ae350 target currently uses CONFIG_BOOTP_SERVERIP which means we
>>> ignore the DHCP provided TFTP ip address. This breaks
Provide sandbox.dtb as default device tree for sandbox_defconfig.
We can use the dtb with
./u-boot -d u-boot.dtb
Signed-off-by: Heinrich Schuchardt
---
v2
adjust commit message
---
configs/sandbox_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/sandbox_def
Provide sandbox.dtb as default device tree for sandbox_defconfig.
We can use the dtb with
./u-boot -d u-boot.dtb
Signed-off-by: Heinrich Schuchardt
---
configs/sandbox_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
in
> Am 15.06.2018 um 17:16 schrieb Simon Glass :
>
> Hi Alex,
>
>> On 15 June 2018 at 06:01, Alexander Graf wrote:
>>
>>
>>> On 16.05.18 17:42, Simon Glass wrote:
>>> Add an implementation of setjmp() and longjmp() which rely on the
>>> underlying host C library. Since we cannot know how large
On Fri, Jun 15, 2018 at 12:06 AM, Alex Kiernan wrote:
> When building without FASTBOOT_FLASH we don't include the intermediate
> update callback to keep the client alive, so ensure we don't try setting
> it here.
>
> Signed-off-by: Alex Kiernan
Acked-by: Joe Hershberger
On Fri, Jun 15, 2018 at 10:56 AM, wrote:
> installed bison++
I just "sudo apt-get install flex bison" and it worked great.
>
> Cloned most recent u-boot 2018.06.14
>
> make clean works
> make menuconfig fails:
> make rpi_3_32b_config fails:
>
> YACCscripts/kconfig/zconf.tab.c
> scripts/kcon
Built without a ROM image with FSP (u-boot.rom), the U-Boot loader applies
the microcode update data block encoded in Device Tree to the bootstrap
processor but not passed to the other CPUs when multiprocessing is enabled.
If the bootstrap processor successfully performs a microcode update
from De
Built without a ROM image with FSP (u-boot.rom), the U-Boot loader applies
the microcode update data block encoded in Device Tree to the bootstrap
processor but not passed to the other CPUs when multiprocessing is enabled.
If the bootstrap processor successfully performs a microcode update
from De
Hi Dennis,
On Fri, Jun 15, 2018 at 10:40:20AM -0500, Dennis Gilmore wrote:
> On Thu, 2018-06-14 at 22:23 +0300, Baruch Siach wrote:
> > On Thu, Jun 14, 2018 at 02:10:31PM -0500, Dennis Gilmore wrote:
> > > running sf probe on one of my clearfogs with this set of patches
> > > applied I got
> > >
On Thu, 2018-06-14 at 22:23 +0300, Baruch Siach wrote:
> Hi Dennis,
>
> On Thu, Jun 14, 2018 at 02:10:31PM -0500, Dennis Gilmore wrote:
> > running sf probe on one of my clearfogs with this set of patches
> > applied I got
> >
> > SF: unrecognized JEDEC id bytes: ff, ff, ff
> > Failed to initial
Hi Alex,
On 15 June 2018 at 06:42, Alexander Graf wrote:
>
> This patch set augments Simon's patch set for efi_loader support
> in sandbox[1], but follows a different memory allocation scheme.
>
> Instead of keeping U-Boot addresses in the EFI memory map, this
> patch set makes the EFI memory map
Hi Alex,
On 15 June 2018 at 06:01, Alexander Graf wrote:
>
>
> On 16.05.18 17:42, Simon Glass wrote:
>> Add an implementation of setjmp() and longjmp() which rely on the
>> underlying host C library. Since we cannot know how large the jump buffer
>> needs to be, pick something that should be suit
On 15.06.18 16:24, Simon Glass wrote:
> Hi Alex,
>
> On 15 June 2018 at 06:42, Alexander Graf wrote:
>> The fs_read() and fs_write() functions are internal interfaces that
>> naturally want to get pointers as arguments. Most users so far even
>> have pointers and explicitly cast them into integ
Hi Alex,
On 15 June 2018 at 06:42, Alexander Graf wrote:
> The fs_read() and fs_write() functions are internal interfaces that
> naturally want to get pointers as arguments. Most users so far even
> have pointers and explicitly cast them into integers just to be able
> to pass them into the funct
> From: Alexander Graf
> Date: Fri, 15 Jun 2018 15:12:31 +0200
>
> Am 15.06.2018 um 15:01 schrieb Mark Kettenis :
>
> >> From: Alexander Graf
> >> Date: Fri, 15 Jun 2018 12:49:48 +0200
> >>
> >>> On 15.06.18 05:39, Heinrich Schuchardt wrote:
> >>> On 06/14/2018 10:50 PM, Mark Kettenis wrote:
>
I attempted to integrate SquashFS with U-boot based on the SquashFS support in
Barebox. It works in that loads the Linux kernel and device tree files from a
SquashFS-formatted root filesystem reliably. Unfortunately, it’s slow (much
slower than Linux SquashFS even though they share most of the c
On 15/06/18 13:51, Mark Kettenis wrote:
>> From: Marc Zyngier
>> Date: Fri, 15 Jun 2018 08:59:59 +0100
>>
>> On 14/06/18 21:55, Mark Kettenis wrote:
From: Marc Zyngier
Date: Thu, 14 Jun 2018 12:54:53 +0100
On 13/06/18 23:41, Mark Kettenis wrote:
> If desired (and possible)
On Fri, Jun 15, 2018 at 2:12 PM, Adam Ford wrote:
> Newer kernels have moved from ttyO0 to ttyS0, and when booting
> it drops a notice:
This will break on older kernels or kernels that haven't made the move
from the omap-serial to the 8250_omap kernel.
> WARNING: Your 'console=ttyO0' has been
Hi Tom,
The following changes since commit 606fddd76c7a045c09d544357806b0b4de4845c7:
Merge branch 'master' of git://git.denx.de/u-boot-net (2018-06-14 07:20:41
-0400)
are available in the Git repository at:
git://git.denx.de/u-boot-arc.git tags/arc-updates-for-2018.07-rc2
for you to fetch
Am 15.06.2018 um 15:01 schrieb Mark Kettenis :
>> From: Alexander Graf
>> Date: Fri, 15 Jun 2018 12:49:48 +0200
>>
>>> On 15.06.18 05:39, Heinrich Schuchardt wrote:
>>> On 06/14/2018 10:50 PM, Mark Kettenis wrote:
> From: Heinrich Schuchardt
> Date: Thu, 14 Jun 2018 19:55:51 +0200
>>>
Newer kernels have moved from ttyO0 to ttyS0, and when booting
it drops a notice:
WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0'
This ensures that you still see kernel messages. Please
update your kernel commandline.
This patch updates the console to use ttyS0 and eliminate the
> From: Alexander Graf
> Date: Fri, 15 Jun 2018 12:49:48 +0200
>
> On 15.06.18 05:39, Heinrich Schuchardt wrote:
> > On 06/14/2018 10:50 PM, Mark Kettenis wrote:
> >>> From: Heinrich Schuchardt
> >>> Date: Thu, 14 Jun 2018 19:55:51 +0200
> >>>
> >>> On 06/14/2018 12:41 AM, Mark Kettenis wrote:
>
Hi Tom,
please pull these changes to your tree.
Buildman and travis looks good
https://travis-ci.org/michalsimek/u-boot/builds/392586380
Thanks,
Michal
The following changes since commit 606fddd76c7a045c09d544357806b0b4de4845c7:
Merge branch 'master' of git://git.denx.de/u-boot-net (2018-06-1
> From: Marc Zyngier
> Date: Fri, 15 Jun 2018 08:59:59 +0100
>
> On 14/06/18 21:55, Mark Kettenis wrote:
> >> From: Marc Zyngier
> >> Date: Thu, 14 Jun 2018 12:54:53 +0100
> >>
> >> On 13/06/18 23:41, Mark Kettenis wrote:
> >>> If desired (and possible) switch into HYP mode or non-secure SVC mod
So far we've always had a split address space situation with
"U-Boot addresses" (a number space starting from 0) and "host
virtual addresses" (128MB mapped randomly in address space).
This meant that we had to make sure all code is properly aware that
addresses and pointers are not the same thing,
With efi_loader, we may want to execute payload from RAM. By default,
permissions on the RAM region don't allow us to execute from there though.
So whenever we get into the efi_loader case, let's mark RAM as executable.
That way we still protect normal cases, but allow for efi binaries to
directly
In sandbox, longjmp returns to itself in an endless loop. Cut this through
by calling the real OS function.
Setjmp on the other hand must not return. So here we have to call the OS
setjmp function straight from the code where the setjmp call happens.
Signed-off-by: Alexander Graf
---
arch/sandb
The fs_read() and fs_write() functions are internal interfaces that
naturally want to get pointers as arguments. Most users so far even
have pointers and explicitly cast them into integers just to be able
to pass them into the function.
Convert them over to instead take a pointer argument for the
This patch set augments Simon's patch set for efi_loader support
in sandbox[1], but follows a different memory allocation scheme.
Instead of keeping U-Boot addresses in the EFI memory map, this
patch set makes the EFI memory map contain host virtual addresses.
That way most logic "just works" and
Varargs differ between sysv and ms abi. On x86_64 we have to follow the ms
abi though, so we also need to make sure we use x86_64 varargs helpers.
This patch introduces generic efi vararg helpers that adhere to the
respective EFI ABI. That way we can deal with them properly from efi
loader code an
We try hard to make sure that SMBIOS tables live in the lower 32bit.
However, when we can not find any space at all there, we should not
error out but instead just fall back to map them in the full address
space instead.
Signed-off-by: Alexander Graf
---
lib/efi_loader/efi_smbios.c | 11
From: Simon Glass
This allows this feature to build within sandbox. This is for testing
purposes only since it is not possible for sandbox to load native code.
Signed-off-by: Simon Glass
Signed-off-by: Alexander Graf
---
lib/efi_loader/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletio
Thanks to CONFIG_SANDBOX, we can not rely on config options to tell us
what CPU architecture we're running on.
The compiler however does know that, so let's just move the ifdefs over
to compiler based defines rather than kconfig based options.
Signed-off-by: Alexander Graf
---
lib/efi_loader/ef
Thanks to CONFIG_SANDBOX, we can not rely on config options to tell us
what CPU architecture we're running on.
The compiler however does know that, so let's just move the ifdefs over
to compiler based defines rather than kconfig based options.
Signed-off-by: Alexander Graf
---
include/config_di
From: Simon Glass
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
Signed-off-by: Alexander Graf
---
lib/efi_loader/efi_runtime.c | 12
1 fi
In the sandbox environment we can not easily build efi stub binaries
right now, so let's disable the respective test cases for the efi
selftest suite.
Signed-off-by: Alexander Graf
Reviewed-by: Simon Glass
---
lib/efi_selftest/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
From: Simon Glass
With sandbox these values depend on the host system. Let's assume that it
is x86_64 for now.
Signed-off-by: Simon Glass
Signed-off-by: Alexander Graf
---
include/config_distro_bootcmd.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/config_distro_
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.
This patch changes the c
With efi_loader we do not control payload applications, so we can not
teach them about the difference between virtual and physical addresses.
Instead, let's just always map host virtual addresses in the efi memory
map. That way we can be sure that all memory allocation functions always
return cons
The EFI image loader tries to determine which target architecture we're
working with to only load PE binaries that match.
So far this has worked based on CONFIG defines, because the target CPU
was always indicated by a config define. With sandbox however, this is
not longer true as all sandbox tar
The bootefi command gets a few addresses as values passed in. In sandbox,
these values are in U-Boot address space, so we need to make sure we
explicitly call map_sysmem() on them to be able to access them.
Signed-off-by: Alexander Graf
Reviewed-by: Simon Glass
---
cmd/bootefi.c | 13 --
From: Heinrich Schuchardt
When running on the sandbox the stack is not necessarily at a higher memory
address than the highest free memory.
There is no reason why the checking of the highest memory address should be
more restrictive for EFI_ALLOCATE_ANY_PAGES than for
EFI_ALLOCATE_MAX_ADDRESS.
On 16.05.18 17:42, Simon Glass wrote:
> Add an implementation of setjmp() and longjmp() which rely on the
> underlying host C library. Since we cannot know how large the jump buffer
> needs to be, pick something that should be suitable and check it at
> runtime. At present we need access to the u
On 06/15/2018 01:43 PM, Marek Vasut wrote:
> On 06/15/2018 12:37 PM, Ulrich Hecht wrote:
>> On Fri, Jun 15, 2018 at 12:09 PM, Marek Vasut wrote:
+ arm_smccc_smc(ARM_SMCCC_RENESAS_MEMCONF,
+ 0, 0, 0, 0, 0, 0, 0, &res);
>>>
>>> Will this call work on p
On Fri, Jun 15, 2018 at 06:09:49AM +0200, Marek Vasut wrote:
> On 06/14/2018 11:42 PM, Tom Rini wrote:
> > On Thu, Jun 14, 2018 at 10:58:22PM +0200, Marek Vasut wrote:
> >> On 06/14/2018 03:07 PM, Tom Rini wrote:
> >>> On Thu, Jun 14, 2018 at 01:35:05PM +0200, Marek Vasut wrote:
> On 06/14/201
On 06/15/2018 12:37 PM, Ulrich Hecht wrote:
> On Fri, Jun 15, 2018 at 12:09 PM, Marek Vasut wrote:
>>> + arm_smccc_smc(ARM_SMCCC_RENESAS_MEMCONF,
>>> + 0, 0, 0, 0, 0, 0, 0, &res);
>>
>> Will this call work on platforms without patched ATF ?
>> (I think not, do
On 06/15/2018 12:40 PM, Alex Kiernan wrote:
> We've got this in Kconfig:
>
> config SPL_LOAD_FIT
> bool "Enable SPL loading U-Boot as a FIT"
> select SPL_FIT
> help
> Normally with the SPL framework a legacy image is generated as part
> of the build. Thi
On 15.06.18 05:39, Heinrich Schuchardt wrote:
> On 06/14/2018 10:50 PM, Mark Kettenis wrote:
>>> From: Heinrich Schuchardt
>>> Date: Thu, 14 Jun 2018 19:55:51 +0200
>>>
>>> On 06/14/2018 12:41 AM, Mark Kettenis wrote:
This series makes it possible to run EFI applications in non-secure
We've got this in Kconfig:
config SPL_LOAD_FIT
bool "Enable SPL loading U-Boot as a FIT"
select SPL_FIT
help
Normally with the SPL framework a legacy image is generated as part
of the build. This contains U-Boot along with information as to
whe
On Fri, Jun 15, 2018 at 6:13 PM, Bin Meng wrote:
> On Thu, Jun 14, 2018 at 8:27 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 defaul
On Thu, Jun 14, 2018 at 8:27 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 function in (%
On 06/15/2018 11:40 AM, Ulrich Hecht wrote:
> Uses an SMC call to the ATF to determine the memory configuration, then
> creates appropriate DT memory nodes.
>
> Signed-off-by: Ulrich Hecht
> ---
> This is an attempt to avoid having to have a ton of different device trees
> for Renesas R8A7795 H3
On Thu, Jun 14, 2018 at 11:11 PM, Simon Glass wrote:
> On 12 June 2018 at 21:01, Bin Meng wrote:
>> Fix warning when compiling cherryhill.dts with latest DTC:
>>
>> "Warning (avoid_unnecessary_addr_size): /pci/pch@1f,0: unnecessary
>>#address-cells/#size-cells without "ranges" or child "reg
Hi Simon,
On Thu, Jun 14, 2018 at 8:58 PM, Simon Glass wrote:
> Hi Alex,
>
> On 13 June 2018 at 04:17, Alexander Graf wrote:
>>
>>
>> On 13.06.18 03:29, Simon Glass wrote:
>>> Hi Bin, Alex,
>>>
>>> On 12 June 2018 at 09:36, Bin Meng wrote:
From: Alexander Graf
Currently efi.h de
The ax25-ae350 target currently uses CONFIG_BOOTP_SERVERIP which means we
ignore the DHCP provided TFTP ip address. This breaks every case where we
do now provide a serverip environment variable.
Instead, let's use the new CONFIG_BOOT_PREFER_SERVERIP option to fall back
to the DHCP provided TFTP I
While trying to boot from network on a RISC-V AX25 platform, I saw
that the DHCP IP address did not get populated from the DHCP server
IP address. The reason for that was simple: CONFIG_BOOTP_SERVERIP
was set.
I don't know the history of that option, but it seems to decrease
intuitivity levels of
We can call commands like dhcp and bootp without arguments or with
explicit command line arguments that really should tell the code where
to look for files instead.
Unfortunately, the current code simply overwrites command line arguments
in the dhcp case with dhcp values.
This patch allows the co
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 adds a 3rd option:
3) Use serverip from DHCP if no serverip is gi
On 14.06.18 18:58, Joe Hershberger wrote:
> On Thu, Jun 14, 2018 at 5:04 AM, Alexander Graf wrote:
>> The ax25-ae350 target currently uses CONFIG_BOOTP_SERVERIP which means we
>> ignore the DHCP provided TFTP ip address. This breaks every case where we
>> do now provide a serverip environment va
On 14/06/18 21:55, Mark Kettenis wrote:
>> From: Marc Zyngier
>> Date: Thu, 14 Jun 2018 12:54:53 +0100
>>
>> On 13/06/18 23:41, 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
>>>
Varargs differ between sysv and ms abi. On x86_64 we have to follow the ms
abi though, so we also need to make sure we use x86_64 varargs helpers.
This patch introduces generic efi vararg helpers that adhere to the
respective EFI ABI. That way we can deal with them properly from efi
loader code an
On 14.6.2018 16:16, Simon Glass wrote:
> EXTERNAL EMAIL
>
> Hi Michal,
>
> On 14 June 2018 at 07:05, Michal Simek wrote:
>> On 14.6.2018 14:58, Simon Glass wrote:
>>> Hi,
>>>
>>> On 14 June 2018 at 03:32, Michal Simek wrote:
Make sure that functions are working with proper strcture.
>
Explanation from Simon Glass
"Private data is created when the device is probed and freed when the
device is removed.
Platform data is created when the device is bound, and survives
probe/remove cycles.
Strictly speaking, platform data should be used to hold the decoded
device tree properties. Pr
Hi Janine,
> This patch adds support for enabling or disabling the lane swapping
> (called "port mirroring" in PHY's CFG4 register) feature of the
> DP83867 TI's PHY device.
>
> One use case is when bootstrap configuration enables this feature
> (because of e.g. LED_0 wrong wiring) so then one ne
Hi Janine,
> The DP83867 when not properly bootstrapped - especially with LED_0
> pin - can enter N/A MODE4 for "port mirroring" feature.
>
> To provide normal operation of the PHY, one needs not only to
> explicitly disable the port mirroring feature, but as well stop some
> IC internal testing
100 matches
Mail list logo
