Hi Magnus,
On Tuesday, 19 June 2018 08:43:31 EEST Magnus Damm wrote:
> On Tue, Jun 19, 2018 at 11:15 AM, Laurent Pinchart wrote:
> > On Sunday, 17 June 2018 03:08:02 EEST Marek Vasut wrote:
> >> On 06/16/2018 05:44 PM, Laurent Pinchart wrote:
> >>> On Saturday, 16 June 2018 02:42:30 EEST Marek
On Mon, 2018-06-18 at 12:59 -0400, Tom Rini wrote:
> On Wed, Jun 13, 2018 at 03:32:43PM +0800, tien.fong.c...@intel.com
> wrote:
>
> >
> > From: Tien Fong Chee
> >
> > In ARM 64-bits, memory size can be supported is more than 4GB,
> > hence increasing save array is needed to cope with testing
> -Original Message-
> From: Marek Vasut [mailto:marek.va...@gmail.com]
> Sent: 2018年6月19日 12:23
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Bin Meng
> ; Jaehoon Chung ;
> Jean-Jacques Hiblot ; Kishon Vijay Abraham I ;
> Peng Fan ; Simon Glass
> Subject: [PATCH] mmc: Parse HS400 DT
2018-06-16 4:12 GMT+08:00 Joe Hershberger :
> 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
Add HS400 properties parsing support to mmc_of_parse().
Signed-off-by: Marek Vasut
Cc: Bin Meng
Cc: Jaehoon Chung
Cc: Jean-Jacques Hiblot
Cc: Kishon Vijay Abraham I
Cc: Peng Fan
Cc: Simon Glass
---
drivers/mmc/mmc-uclass.c | 4
1 file changed, 4 insertions(+)
diff --git
The sh_pfc_{read,write}() must operate on the register address directly
rather than on an offset, fix this to prevent illegal access.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
---
drivers/pinctrl/renesas/pfc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Hi Heinrich,
On Tue, Jun 12, 2018 at 11:50 PM, Heinrich Schuchardt
wrote:
> 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
On Sunday, 17 June 2018 03:08:02 EEST Marek Vasut wrote:
> On 06/16/2018 05:44 PM, Laurent Pinchart wrote:
> > Hi Marek,
> >
> > On Saturday, 16 June 2018 02:42:30 EEST Marek Vasut wrote:
> >> On 06/16/2018 01:21 AM, Laurent Pinchart wrote:
> >>> On Friday, 15 June 2018 15:00:31 EEST Marek Vasut
2018-06-18 13:59 GMT+09:00 Baruch Siach :
> Commit e19b0fb4851f (kbuild: generate u-boot.cfg as a byproduct of
> include/autoconf.mk) removed the use of the cpp_cfg macro in Makefile,
> but forgot to remove its definition.
>
> Cc: Masahiro Yamada
> Signed-off-by: Baruch Siach
> ---
Reviewed-by:
Previous rename of efi-x86 target missed the MAINTAINERS update,
which caused the buildman warnings:
WARNING: no status info for 'efi-x86_app'
WARNING: no maintainers for 'efi-x86_app'
This updates the board MAINTAINERS to reflect the up-to-date info.
Signed-off-by: Bin Meng
---
On 06/18/2018 06:59 PM, Tom Rini wrote:
> On Sun, Jun 17, 2018 at 02:02:22AM +0200, Marek Vasut wrote:
>
>> The following changes since commit acaee30608ce203289a180d664b7f0abb2e64ee7:
>>
>> ARM: DTS: resync a3517.dtsi with Linux 4.17 (2018-06-13 07:49:14 -0400)
>>
>> are available in the Git
> Actually the DRAM is not only seperated in one
> bank. The DRAM bank information is stored in
> gd->bd->bi_dram, so reserve lmb according to
> gd->bd->bi_dram.
>
> Signed-off-by: Jason Zhu
> ---
> common/bootm.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff
On Mon, Jun 18, 2018 at 8:58 PM, Bin Meng wrote:
> On Sat, Jun 16, 2018 at 2:01 AM, Ivan Gorinov wrote:
>> 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
On Wed, 13 Jun 2018 11:51:13 +0800, kever.yang at rock-chips.com wrote:
>(snip)
>I just not understand why remove the dependency on python is so important,
>there already many modules depend on python.
On Wed, 13 Jun 2018 11:57:48 +0800, kever.yang at rock-chips.com wrote:
>(snip)
> Could you
On Mon, Jun 18, 2018 at 03:37:36PM -0400, Tom Rini wrote:
> On Sun, Jun 17, 2018 at 09:21:55PM +0800, Bin Meng wrote:
>
> > Hi Tom,
> >
> > The following changes since commit a715415bb5948c84cc44c601b193188990f7238b:
> >
> > Merge branch 'master' of git://git.denx.de/u-boot-usb (2018-06-16
>
From: Karsten Merker
To: Duncan Hare
Cc: U-Boot Mailing List
Sent: Monday, June 18, 2018 11:43 AM
Subject: Re: [U-Boot] Fw: make config Error
>
> In this repository. It might exist elsewhere.
>
> I generally use raspbian to compile u-boot for the raspberry
> pi, and Debian as a
On Sun, Jun 17, 2018 at 6:55 AM, Baruch Siach wrote:
> From: Rabeeh Khoury
>
> This fixes sporadic timeout on initial packet Tx (usually ARP), with an
> error message like:
>
> timeout: packet not sent
>
> Signed-off-by: Rabeeh Khoury
> Signed-off-by: Baruch Siach
Acked-by: Joe Hershberger
On Sun, Jun 17, 2018 at 6:55 AM, Baruch Siach wrote:
> From: Rabeeh Khoury
>
> Make the initialization sequence consistent with the Linux kernel
> driver.
>
> Signed-off-by: Rabeeh Khoury
> Signed-off-by: Baruch Siach
Acked-by: Joe Hershberger
___
On Mon, Jun 18, 2018 at 3:07 AM, Marek Vasut wrote:
> Do not stop the clock in the start callback in case of failure, keep
> them running to also keep the PHY running. The failure could be ie.
> PHY failing to negotiate link and if the clock get shut down, another
> attempt at bringing the link
On Sun, Jun 17, 2018 at 10:48 PM, Marek Vasut wrote:
> The RAVB only supports 100Full and 1000Full operation, it does not support
> 10Full or any Half-duplex modes. The PHY could still advertise those features
> though, so filter out the PHY features accordingly.
>
> Signed-off-by: Marek Vasut
>
On Sun, Jun 17, 2018 at 9:30 PM, Marek Vasut wrote:
> The recent DTs have the PHY reset GPIO in the PHY node rather than
> the ethernet MAC node, support extracting the PHY reset GPIO info
> from both the PHY node and ethernet MAC node.
>
> Signed-off-by: Marek Vasut
> Cc: Nobuhiro Iwamatsu
>
On Sun, Jun 17, 2018 at 9:30 PM, Marek Vasut wrote:
> The recent DTs have the PHY reset GPIO in the PHY node rather than
> the ethernet MAC node, support extracting the PHY reset GPIO info
> from both the PHY node and ethernet MAC node.
>
> Signed-off-by: Marek Vasut
> Cc: Nobuhiro Iwamatsu
>
I'm trying to get a build going without the legacy image format, but I
need boot scripts (and I'm using distro boot). I'm coming unstuck when
trying to boot one as there's no way to pass in the FIT unit name to
source with distro boot.
Would adding a default property inside /images (like we have
Vicente,
> On 18 Jun 2018, at 22:07, Vicente Bergas wrote:
>
> On Wed, 13 Jun 2018 11:51:13 +0800, kever.yang at rock-chips.com wrote:
>> (snip)
>> I just not understand why remove the dependency on python is so important,
>> there already many modules depend on python.
>
> On Wed, 13 Jun 2018
On Sun, Jun 17, 2018 at 09:21:55PM +0800, Bin Meng wrote:
> Hi Tom,
>
> The following changes since commit a715415bb5948c84cc44c601b193188990f7238b:
>
> Merge branch 'master' of git://git.denx.de/u-boot-usb (2018-06-16
> 00:07:37 -0400)
>
> are available in the git repository at:
>
>
On Thu, Jun 14, 2018 at 10:44:53AM +0200, Mario Six wrote:
> The Linux kernel moved to sphinx-based documentation and got rid of the
> DocBook based documentation quite a while ago. Hence, the DocBook
> documentation for U-Boot should be converted as well.
>
> To achieve this, import the
On Thu, Jun 14, 2018 at 03:07:25PM +0800, Jason Zhu wrote:
> Actually the DRAM is not only seperated in one
> bank. The DRAM bank information is stored in
> gd->bd->bi_dram, so reserve lmb according to
> gd->bd->bi_dram.
>
> Signed-off-by: Jason Zhu
> ---
> common/bootm.c | 13 ++---
>
The kwboot utility can use the generated image to boot mvebu SoCs from
UART.
Signed-off-by: Baruch Siach
---
arch/arm/mach-mvebu/Kconfig | 3 +++
arch/arm/mach-mvebu/Makefile | 3 +++
2 files changed, 6 insertions(+)
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index
Move the gdsys Controlcenter DC specific build time kwbimage.cfg
generation code into the mach-mvebu/ directory to be shared by all 32bit
mvebu platforms.
Remove board specific kwbimage.cfg files, and use the generated one
instead. These files are all identical, with two exceptions. Clearfog
and
This allows selection of the boot device at build time without source
code modification.
Signed-off-by: Baruch Siach
---
include/configs/clearfog.h | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/include/configs/clearfog.h b/include/configs/clearfog.h
index
Use MVEBU_SPL_BOOT_DEVICE_* to select between SPI and MMC, instead of
board specific symbols. This commit enables the boot device selection
menu to all mvebu platforms, but it is only effective on Turris Omnia
and gdsys Controlcenter DC platforms. A following commit will enable
boot selection for
Use generic mvebu Kconfig symbols like all other mvebu boards.
Signed-off-by: Baruch Siach
---
arch/arm/mach-mvebu/Kconfig | 3 +++
board/gdsys/a38x/Kconfig| 12
2 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-mvebu/Kconfig
u-boot-spl.bin and u-boot-spl-dtb.bin are identical when building the
turris_omnia_defconfig. This commit makes Turris Omnia consistent with
all other mvebu boards.
Signed-off-by: Baruch Siach
---
board/CZ.NIC/turris_omnia/kwbimage.cfg | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Currently the boot device that the generated .kwb image supports is
statically set in two places. The BOOT_FROM directive in the per board
kwbimage.cfg file, and the CONFIG_SPL_BOOT_DEVICE macro in the board
config header file.
The gdsys Controlcenter DC supports build time generation of the
This bug is the combination of dwc2 USB controller and lan78xx
USB ethernet controller, which is the combination in use on
the Raspberry Pi Model 3 B+.
When the host attempts to receive a packet, but a packet has not
arrived, the lan78xx controller responds by setting BIR
(Bulk-In Empty Response)
In testing networking with EFI/u-boot, there is an issue where the dwc2
USB controller will hang -- requiring an USB reset. The issue appears to
be the programming of the "Bulk-In Empty Response" in the lan78xx
controller. The patch is a suggested fix.
However, I am not familiar enough with
On Tue, Jun 12, 2018 at 03:24:07PM -0500, Nishanth Menon wrote:
> Hi,
>
> This is a follow on from https://marc.info/?l=u-boot=151691688828176=2
> (RFC)
>
> NOTE:
> * As per ARM recommendations[2], and discussions in list[1] ARM
> Cortex-A9/12/17 do not need additional steps in u-boot to
On Wed, Jun 06, 2018 at 05:03:57PM +0100, Ben Whitten wrote:
> Move to calling the abstraction which allows for hardware acceleration.
> We also remove unneeded defines and only include objects if required.
>
> Signed-off-by: Ben Whitten
[snip]
> diff --git a/common/image-fit.c
On Wed, Jun 13, 2018 at 03:32:43PM +0800, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee
>
> In ARM 64-bits, memory size can be supported is more than 4GB,
> hence increasing save array is needed to cope with testing larger memory.
>
> Signed-off-by: Tien Fong Chee
> ---
>
On Sun, Jun 17, 2018 at 11:13:23PM -0700, Vasily Khoruzhick wrote:
> On Sun, Jun 17, 2018 at 11:04 PM, Jagan Teki wrote:
> >> Do git pull and make sure you are at least at
> >> a715415bb5948c84cc44c601b193188990f7238b.
> >
> > Yes, I even tried on this, can't see any issue? Let me know If I still
On Sun, Jun 17, 2018 at 02:02:22AM +0200, Marek Vasut wrote:
> The following changes since commit acaee30608ce203289a180d664b7f0abb2e64ee7:
>
> ARM: DTS: resync a3517.dtsi with Linux 4.17 (2018-06-13 07:49:14 -0400)
>
> are available in the Git repository at:
>
>
On Mon, Jun 18, 2018 at 11:45:23AM +0530, Jagan Teki wrote:
> On Mon, Jun 18, 2018 at 6:44 AM, Marek Vasut wrote:
> > On 06/17/2018 06:13 PM, Vasily Khoruzhick wrote:
> >> ohci-hcd casts priv_data pointer to (ohci_t *), thus it must be
> >> the first member in private data struct.
> >>
> >> Fixes
On Tue, Jun 12, 2018 at 11:34 AM, Vipul Kumar wrote:
> From: Michal Simek
>
> This patch added support to read register base address
> from DTS file.
This patch also adding fifo_depth apart from reg.
>
> Signed-off-by: Michal Simek
> Signed-off-by: Vipul Kumar
> ---
>
From: Fabio Estevam
Since commit 1da1938d57b3 ("spl: Add default values for ARCH_MX7")
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR is selected by default on
i.MX7 platforms, so remove it from the board defconfig.
Signed-off-by: Fabio Estevam
---
configs/cl-som-imx7_defconfig | 1 -
1 file
On 06/18/2018 05:22 PM, Alexander Graf wrote:
This patch set augments Simon's patch set for efi_loader support
in sandbox[1], but cuts off the memory allocation scheme at a different
point.
According to the UEFI spec, efi_allocate_pages() takes a uint64_t *
argument. Via this argument, we get a
On Mon, Jun 18, 2018 at 12:39 AM, Jagan Teki wrote:
>> >From what I see in the other thread, the USB never worked with the
>> series. If the controller returns 0s as EHCI version, something is
>> obviously broken and I don't even understand how that could be an
>> acceptable positive test result.
This patch set augments Simon's patch set for efi_loader support
in sandbox[1], but cuts off the memory allocation scheme at a different
point.
According to the UEFI spec, efi_allocate_pages() takes a uint64_t *
argument. Via this argument, we get a physical address as input, but
emit a pointer
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
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
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(-)
From: Simon Glass
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.
Signed-off-by: Simon Glass
[agraf: Remove map_sysmem() call]
Signed-off-by: Alexander
We currently expose host addresses in the EFI memory map. That can be
bad if we ever want to use sandbox to boot strap a real kernel, because
then the kernel would fetch its memory table from our host virtual address
map. But to make that use case work, we would need to have full control
over the
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
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
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
---
v3 -> v4:
-
Now that elf.h contains relocation defines for all architectures
we care about, let's just include it unconditionally and refer to
the defines.
Signed-off-by: Alexander Graf
---
lib/efi_loader/efi_runtime.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git
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
---
In some code paths we check whether host virtual addresses are sane.
That only works if at least alignments between host and U-Boot address
spaces match.
So let's always map U-Boot addresses with 64kb alignment. That should
be enough to ensure that the actual RAM ends up in a different page
from
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
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.
With efi_loader, we may want to execute payloads 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
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
---
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
We need to know about x86 relocation definitions even in cases where
we don't officially build against the x86 target, such as with sandbox.
So let's move the x86 definitions into the common elf header, where all
other architectures already have them.
Signed-off-by: Alexander Graf
---
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
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
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
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
On 06/18/2018 04:08 PM, Simon Glass wrote:
From: Alexander Graf
The fs_read() function wants to get an address rather than the
pointer to a buffer.
So let's convert the passed buffer from pointer back a the address
to make efi_loader on sandbox happier.
Signed-off-by: Alexander Graf
On 06/18/2018 04:08 PM, Simon Glass wrote:
Add some more verbose debugging when doing memory allocations. This might
help to find bugs later.
Signed-off-by: Simon Glass
Very useful indeed.
Reviewed-by: Alexander Graf
Alex
___
U-Boot mailing
On 06/18/2018 04:08 PM, Simon Glass wrote:
Sandbox does not support direct casts between addresses and pointers,
since it uses an emulated RAM buffer rather than directly using host
RAM.
The current EFI code uses an integer type for addresses, but treats them
like pointers.
Update the code to
On 06/18/2018 04:08 PM, Simon Glass wrote:
This function currently returns an error code, but never uses it. There is
no function comment so it is not obvious why. Presuambly the error is not
important.
Update the function to explain its purpose and why it ignores the error.
Drop the useful
On 06/18/2018 04:08 PM, Simon Glass wrote:
At present this function takes a pointer as its argument, then passes this
to efi_allocate_pages(), which actually takes an address. It uses casts,
which are not supported on sandbox.
I think this is the big API misunderstanding that caused our
On 06/18/2018 04:08 PM, Simon Glass wrote:
Sandbox only has 128MB of memory so we cannot relocate the device tree up
to start at 128MB. Use 127MB instead, which should be safe.
Signed-off-by: Simon Glass
We should just drop into the fallback case if allocation fails, no?
Alex
---
On 06/18/2018 04:08 PM, Simon Glass wrote:
The test should exit like any other EFI application, by calling exit()
in the boot services API. But this crashes at present on sandbox. For now,
add in the placeholder code.
Signed-off-by: Simon Glass
It crashes because setjmp/longjmp are broken.
On 06/18/2018 04:08 PM, Simon Glass wrote:
At present map_sysmem() maps an address into the sandbox RAM buffer,
return a pointer, while map_to_sysmem() goes the other way.
The mapping is currently just 1:1 since a case was not found where a more
flexible mapping was needed. PCI does have a
On 02/06/2018 13:55, Jagan Teki wrote:
> Match imx6q-icore-mipi and imx6dl-icore-mipi dtb in
> board_fit_config_name_match.
>
> Signed-off-by: Jagan Teki
> ---
> board/engicam/common/spl.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/board/engicam/common/spl.c
Hi Mans,
On 27/04/2018 11:45, Mans Rullgard wrote:
> If many values differ from the defaults, overriding the full table
> is simpler and more space efficient than tweaking it through
> mxs_adjust_memory_params().
>
> Signed-off-by: Mans Rullgard
> ---
Applied to u-boot-imx, thanks !
Best
On 06/18/2018 04:08 PM, Simon Glass wrote:
At present a NULL pointer passed to printf for a %pU argument will cause
U-Boot to access memory at 0. Fix this by adding a check, and print
"(null)" instead.
Signed-off-by: Simon Glass
Reviewed-by: Alexander Graf
Alex
On 06/18/2018 04:08 PM, Simon Glass wrote:
There appears to be a bug [1] in gcc when using varargs with this
attribute. Disable it for sandbox so that functions which use that can
work correctly, such as install_multiple_protocol_interfaces().
[1]
On 06/18/2018 04:08 PM, Simon Glass wrote:
Use a starting address of 256MB which should be available. This helps to
make sandbox RAM buffers pointers more recognisable.
Signed-off-by: Simon Glass
Nak, this has a non-0 chance of failing, in case something else is
already mapped at that
On 11/06/2018 20:08, Otavio Salvador wrote:
> We should use the baudrate variable available inside U-Boot
> environment to allow it to be changed dynamically.
>
> Signed-off-by: Otavio Salvador
> ---
>
> include/configs/wandboard.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
On Fri, Jun 15, 2018 at 5:42 AM, 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/2018 01:19 PM, Tom Rini wrote:
>> >>> On Wed, Jun 13, 2018 at
From: Alexander Graf
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
Signed-off-by: Simon Glass
---
Changes in v8: None
Changes in
Add some more verbose debugging when doing memory allocations. This might
help to find bugs later.
Signed-off-by: Simon Glass
---
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
From: Joe Hershberger
To: Duncan Hare
Cc: Simon Glass ; Joe Hershberger ;
u-boot
Sent: Friday, June 15, 2018 12:54 PM
Subject: Re: [U-Boot] make config Error
On Fri, Jun 15, 2018 at 10:56 AM, wrote:
> installed bison++
I just "sudo apt-get install flex bison" and it worked
This function can be used from do_bootefi_exec() so that we use mostly the
same code for a normal EFI application and an EFI test.
Rename the function and use it in both places.
Signed-off-by: Simon Glass
---
Changes in v8: None
Changes in v7:
- Drop patch "efi: Init the 'rows' and 'cols'
On 14/05/2018 14:44, Fabio Estevam wrote:
> From: Ye Li
>
> According to the Cortex-A7 TRM, for ACTLR.SMP bit "You must ensure this bit
> is set to 1 before the caches and MMU are enabled, or any cache and TLB
> maintenance operations are performed".
> ROM sets this bit in normal boot flow, but
Sandbox does not support direct casts between addresses and pointers,
since it uses an emulated RAM buffer rather than directly using host
RAM.
The current EFI code uses an integer type for addresses, but treats them
like pointers.
Update the code to maintain a (reasonably) clear separation
From: Alexander Graf
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
This function is useful to signal that the application needs to exit
immediate. It can be caught with a debugger (e.g. gdb). Add a stub for it
so that it can be called from within sandbox when an internal error
occurs.
Signed-off-by: Simon Glass
---
Changes in v8: None
Changes in v7: None
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.
Use a starting address of 256MB which should be available. This helps to
make sandbox RAM buffers pointers more recognisable.
Signed-off-by: Simon Glass
---
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
This function currently returns an error code, but never uses it. There is
no function comment so it is not obvious why. Presuambly the error is not
important.
Update the function to explain its purpose and why it ignores the error.
Drop the useful error return value.
Signed-off-by: Simon Glass
From: Alexander Graf
The fs_read() function wants to get an address rather than the
pointer to a buffer.
So let's convert the passed buffer from pointer back a the address
to make efi_loader on sandbox happier.
Signed-off-by: Alexander Graf
Reviewed-by: Simon Glass
Signed-off-by: Simon Glass
This is a bit confusing at present since it adds 4KB to the pointer, then
rounds it up. It looks like a bug, but is not.
Move the 4KB addition into a separate statement and expand the comment.
Signed-off-by: Simon Glass
---
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in
The test should exit like any other EFI application, by calling exit()
in the boot services API. But this crashes at present on sandbox. For now,
add in the placeholder code.
Signed-off-by: Simon Glass
---
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes
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 to reboot afterwards).
For now the test just
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
---
Changes in v8: None
Changes in v7:
- Update patch subject s/builder/build/
Changes in v6: None
Changes in v5: None
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 v8: None
Changes in v7:
- Drop an unnecessary comment
Changes in v6:
- Warn about building
1 - 100 of 166 matches
Mail list logo
