Re: [PATCH v3 29/29] acpi: Add an acpi command

On Mon, Mar 30, 2020 at 17:13:05 -0600, Simon Glass wrote: > It is useful to dump ACPI tables in U-Boot to see what has been generated. > Add a command to handle this. > > To allow the command to find the tables, add a position into the global > data. > > Support subcommands to list and dump the

Re: [PATCH 084/108] x86: acpi: Support generation of the DBG2 table

Hi Simon, A portion of this set is very much not x86-specific. (more below) On Sun, Jan 26, 2020 at 22:06:31 -0700, Simon Glass wrote: > Add an implementation of the DBG2 (Debug Port Table 2) ACPI table. > Adjust one of the header includes to be in the correct order, before > adding more. > >

Re: [PATCH 034/108] x86: acpi: Move MADT up a bit

On Sun, Jan 26, 2020 at 22:05:41 -0700, Simon Glass wrote: > Put this table before MCFG so that it matches the order that coreboot uses > when passing tables to Linux. This is a cosmetic change since the order of > the tables does not otherwise matter. The patch looks like it's doing the opposite

Re: [U-Boot] EFI_PXE_BASE_CODE_PROTOCOL

On Tue, Aug 06, 2019 at 08:52:09PM +0200, Heinrich Schuchardt wrote: > > > > EFI_PXE_BASE_CODE_PACKET DhcpAck is a union: > > > > > > > > typedef union { > > > > UINT8 Raw[1472]; > > > > EFI_PXE_BASE_CODE_DHCPV4_PACKET Dhcpv4; > > > >

Re: [U-Boot] EFI_PXE_BASE_CODE_PROTOCOL

+Peter Jones (sorry Peter) On Tue, Aug 06, 2019 at 08:34:58AM +0200, Heinrich Schuchardt wrote: > iPXE uses the EFI simple network protocol to execute DHCP. OK. > Can GRUB already do the same when the EFI_PXE_BASE_CODE_PROTOCOL is not > present? Yes. As of very recently (proper* DHCP support

Re: [U-Boot] [RFC 1/1] efi_loader: usage of cleanup_before_linux()

On Fri, Jul 19, 2019 at 07:26:19AM +0100, Peter Robinson wrote: > > As of GRUB 2.04 release (and cherry-picked into debian Buster before > > that), the 32-bit and 64-bit UEFI ports use the same loader. > > Do you have a reference to this patch set handy? I figured it might be good to write a

Re: [U-Boot] [RFC 1/1] efi_loader: usage of cleanup_before_linux()

On Thu, Jul 18, 2019 at 08:53:01PM +0200, Alexander Graf wrote: > > On 18.07.19 19:46, Heinrich Schuchardt wrote: > > Always call cleanup_before_linux() on ARM 32bit during ExitBootServices(). > > > > This fixes a problem problem for booting BSD on ARM 32bit. > > > > Reported-by: Jonathan Gray

Re: [U-Boot] U-Boot/EBBR plugfest at ELC-EU?

On Mon, Jul 08, 2019 at 12:13:07PM +0200, Daniel Kiper wrote: > > I don't know yet - UEFI Asia plugfest date hasn't been decided yet, > > and is likely to end up around the same time. And actually another > > unrelated event too. > > > > Certainly, Lyon is a quite convenient train journey from

Re: [U-Boot] [BUG] Wandboard fails to boot via U-Boot bootefi, GRUB

On Tue, Jul 02, 2019 at 07:35:31PM +0200, Heinrich Schuchardt wrote: > > This always felt somewhat precarious to me. > > > > Could you possibly: > > - add 'set debug=linux' in your grub.cfg and paste the logs > > - add some printouts to arm32-stub.c > > ? > > That debug output is ever so

Re: [U-Boot] [BUG] Wandboard fails to boot via U-Boot bootefi, GRUB

On Tue, Jul 02, 2019 at 07:12:11PM +0200, Heinrich Schuchardt wrote: > > After LoadImage is called, the EFI stub of the kernel image determines > > where the runtime kernel is going to be decompressed to (and I think > > relocates zImage if necessary), and reserves this area, before > > actually

Re: [U-Boot] [BUG] Wandboard fails to boot via U-Boot bootefi, GRUB

Hello Heinrich, On Sat, Jun 29, 2019 at 07:47:10PM +0200, Heinrich Schuchardt wrote: > Hello Leif, > > the Wandboard Quad rev B1 cannot be booted via U-Boot, GRUB-efi-arm. > GRUB loads the initial ramdisk into an area which the the mainline > 4.19.55 kernel simply does not accept because it

Re: [U-Boot] [BUG] Wandboard fails to boot via U-Boot bootefi, GRUB

On Mon, Jul 01, 2019 at 10:22:46PM +0200, Heinrich Schuchardt wrote: > > Hmm. Well, my main concern is that we *should* be ignoring whatever is > > in the DT when booting through UEFI (see Linux commit 500899c2cc3e3). > > > > Could you try deleting the "memory" and "memory@1000" nodes from >

Re: [U-Boot] [BUG] Wandboard fails to boot via U-Boot bootefi, GRUB

Hi, On Mon, Jul 01, 2019 at 07:19:10PM +0200, Heinrich Schuchardt wrote: > > According to this, we have an allocation of somewhat below 8MB, I > > assume this matches the size of the initrd? > > Thanks a lot for taking a look at this. > > 31516827 bytes actually. > 74715648 bytes after

Re: [U-Boot] [BUG] Wandboard fails to boot via U-Boot bootefi, GRUB

Hi Heinrich, On Sat, Jun 29, 2019 at 07:47:10PM +0200, Heinrich Schuchardt wrote: > Hello Leif, > > the Wandboard Quad rev B1 cannot be booted via U-Boot, GRUB-efi-arm. > GRUB loads the initial ramdisk into an area which the the mainline > 4.19.55 kernel simply does not accept because it thinks

Re: [U-Boot] U-Boot/EBBR plugfest at ELC-EU?

On Fri, Jun 28, 2019 at 12:17:54PM +0200, Alexander Graf wrote: > On 28.06.19 12:03, Heinrich Schuchardt wrote: > > I would be interested in joining. I hope that for the plugfest no ELC > > conference ticket will be needed. > > The easiest option for that would be to submit a talk to ELC-E. IIRC

Re: [U-Boot] [PATCH 0/2] efi_loader: implement deprecated Unicode collation protocol

On Wed, May 29, 2019 at 12:09:43PM +0200, Alexander Graf wrote: > > > > Do you want to change this policy? > > > > (I'm just asking.) > > > I am using SCT a lot to test my patches. I want to be able to run the > > > tests on the final code. > > Wouldn't it be better to patch/fork the upstream SCT

Re: [U-Boot] [PATCH] [U-boot]: Change FDT memory typpe from runtime data to acpi reclaim

On Thu, Apr 11, 2019 at 10:08:10PM +0200, Heinrich Schuchardt wrote: > > > How about systab.tables assigned in efi_initialize_system_table()? Which > > > of the addresses in systab.tables should be updated upon relocation. > > > > > > The EFI Spec is really hazy: "A pointer to the table

Re: [U-Boot] [PULL] efi patch queue 2019-01-28

e to the mail here. First, we have: > commit ae4eb8232d927e4f630408f2533f06a5fb1b32a4 > Author: Leif Lindholm > Date: Mon Jan 21 12:12:57 2019 +0900 > > efi_loader: Initial HII database protocols > > which comes in without his, but with others Signed-off-by lines. This

Re: [U-Boot] [RESEND PATCH v2 2/6] efi_loader: Initial HII database protocols

will put together an email to USWG with you on cc. Regards, Leif > > Thanks > Liming > > -Original Message- > > From: Laszlo Ersek [mailto:ler...@redhat.com] > > Sent: Tuesday, January 8, 2019 7:56 PM > > To: Leif Lindholm > > Cc: AKASHI Takahiro ; Alex

Re: [U-Boot] [RESEND PATCH v2 2/6] efi_loader: Initial HII database protocols

MdePkg/MdeModulePkg maintainers - any comments? On Tue, Jan 08, 2019 at 01:28:00AM +0100, Laszlo Ersek wrote: > On 01/07/19 20:22, Leif Lindholm wrote: > > On Mon, Jan 07, 2019 at 07:29:47PM +0100, Laszlo Ersek wrote: > > >> The UEFI spec (v2.7) explicitly requires EFI_GUID

Re: [U-Boot] [RESEND PATCH v2 2/6] efi_loader: Initial HII database protocols

On Mon, Jan 07, 2019 at 07:29:47PM +0100, Laszlo Ersek wrote: > On 01/07/19 15:09, Leif Lindholm wrote: > > Apologies for late reply, back from holidays today. > > I'm going to snip a whole lot of context below, since I have no idea > what project this is about, and/or what fil

Re: [U-Boot] [RESEND PATCH v2 2/6] efi_loader: Initial HII database protocols

Apologies for late reply, back from holidays today. On Tue, Dec 25, 2018 at 05:30:25PM +0900, AKASHI Takahiro wrote: > > >>> +struct efi_key_descriptor { > > >>> + efi_key key; > > >> > > >> Hello Takahiro, > > >> > > >> with the patch I can start the EFI shell. But I am still trying to

Re: [U-Boot] [PATCH 02/11] efi_loader: Initial HII protocols

On Fri, Oct 05, 2018 at 05:52:09PM +0900, AKASHI, Takahiro wrote: > > > 2. If a platform includes a configuration infrastructure, then the > > > EFI_HII_DATABASE_PROTOCOL, EFI_HII_STRING_PROTOCOL, > > > EFI_HII_CONFIG_ROUTING_PROTOCOL, and EFI_HII_CONFIG_ACCESS_PROTOCOL are > > > required. > > > >

Re: [U-Boot] [PATCH v3 4/5] efi_loader: EFI_UNICODE_COLLATION_PROTOCOL

On Wed, Sep 05, 2018 at 12:04:04AM +0200, Alexander Graf wrote: > > I just removed your patch > > XXX efi_loader collation: Expose v1 GUID as well > > from https://github.com/agraf/u-boot/commits/ebbr-demo > > and I am still able to run Shell.efi. > > I just double checked and Shell.efi

Re: [U-Boot] [RFC] efi_loader: workaround for EDK2's shell.efi

On Thu, Aug 09, 2018 at 03:15:38PM +0900, AKASHI Takahiro wrote: > The commit 21b3edfc964 ("efi_loader: check parameters of CreateEvent") > enforces a strict parameter check at CreateEvent(). Unfortunately, > however, EDK2's Shell.efi calls this function with notify_tpl == 0. I find this done in

Re: [U-Boot] [PATCH v2 2/3] arm: armv7: allow unaligned memory access

On Wed, Apr 04, 2018 at 11:46:45AM +0200, Alexander Graf wrote: > On 03.04.18 21:59, Heinrich Schuchardt wrote: > > The UEFI spec mandates that unaligned memory access should be enabled if > > supported by the CPU architecture. > > > > This patch implements the function unaligned_access() to

Re: [U-Boot] [PATCH v3 2/2] efi_loader: provide new doc/README.uefi

Well, from my point of view: Reviewed-by: Leif Lindholm <leif.lindh...@linaro.org> or Acked-by: Leif Lindholm <leif.lindh...@linaro.org> (whichever makes more sense). Many thanks! / Leif > --- > v3 > rename README.efi to README.uefi > use UEFI instead of EFI w

Re: [U-Boot] Fwd: [PATCH v2 2/2][for v2018.03] efi_loader: provide new doc/README.efi

On Mon, Feb 26, 2018 at 07:37:15PM +0100, Heinrich Schuchardt wrote: > On 02/26/2018 06:38 PM, Leif Lindholm wrote: > > Apologies for formatting. > > > > On Mon, Feb 26, 2018 at 04:01:39PM +0100, Alexander Graf wrote: > > > Forwarded Message ---

Re: [U-Boot] Fwd: [PATCH v2 2/2][for v2018.03] efi_loader: provide new doc/README.efi

Apologies for formatting. On Mon, Feb 26, 2018 at 04:01:39PM +0100, Alexander Graf wrote: > Forwarded Message > Subject: [PATCH v2 2/2][for v2018.03] efi_loader: provide new doc/README.efi > Date: Fri, 16 Feb 2018 12:44:27 +0100 > From: Heinrich Schuchardt >

Re: [U-Boot] [PATCH 00/23] efi_loader implement missing functions

On Wed, Aug 30, 2017 at 08:59:31AM +0100, Leif Lindholm wrote: > On Wed, Aug 30, 2017 at 12:03:16AM +0200, Heinrich Schuchardt wrote: > > I am able to provide a test application that will cover the API > > functions that I have focused on (events, protocols, (dis)connect > > c

Re: [U-Boot] [PATCH 00/23] efi_loader implement missing functions

On Wed, Aug 30, 2017 at 12:03:16AM +0200, Heinrich Schuchardt wrote: > On 08/29/2017 10:38 PM, Alexander Graf wrote: > >> Am 29.08.2017 um 22:16 schrieb Simon Glass : > >> That seems more useful long term than re-inventing comprehensive UEFI > >> test suite. (Also,

Re: [U-Boot] [PATCH 00/23] efi_loader implement missing functions

On Tue, Aug 29, 2017 at 05:59:41PM +0200, Heinrich Schuchardt wrote: > On 08/29/2017 02:57 PM, Leif Lindholm wrote: > > UEFI SCT is not yet open source/free software. Obviously, this is > > something Linaro has been lobbying for since day one of our > > involvement. Th

Re: [U-Boot] [PATCH 00/23] efi_loader implement missing functions

On Tue, Aug 29, 2017 at 02:26:48PM +0200, Alexander Graf wrote: > > > > I would add command > > > > bootefi selftest.efi > > > > to run the tests and provide the python wrapper code to add it to the > > > > test suite. > > > > > > I think that's a great idea, yes. > > I wonder how far we are from

Re: [U-Boot] [PATCH v0 21/20] efi_loader: hack for archs that cannot do unaligned accesses

On Tue, Aug 08, 2017 at 08:01:10AM -0400, Rob Clark wrote: > On Tue, Aug 8, 2017 at 7:32 AM, Leif Lindholm <leif.lindh...@linaro.org> > wrote: > > On Tue, Aug 08, 2017 at 09:11:14AM +0100, Ard Biesheuvel wrote: > >> On 8 August 2017 at 07:52, Alexander Graf <ag

Re: [U-Boot] [PATCH v0 21/20] efi_loader: hack for archs that cannot do unaligned accesses

On Tue, Aug 08, 2017 at 09:11:14AM +0100, Ard Biesheuvel wrote: > On 8 August 2017 at 07:52, Alexander Graf wrote: > > > > > >> Am 07.08.2017 um 23:18 schrieb Rob Clark : > >> > >> On Mon, Aug 7, 2017 at 5:14 PM, Mark Kettenis > >>

Re: [U-Boot] [PATCH 3/6] arm: efi: Add a hello world test program

On 19 October 2016 at 21:22, Leif Lindholm <leif.lindh...@linaro.org> wrote: > On Mon, Oct 17, 2016 at 07:55:02PM -0600, Simon Glass wrote: >> Hi Leif, >> >> On 26 September 2016 at 19:53, Leif Lindholm <leif.lindh...@linaro.org> >> wrote: >> >&g

Re: [U-Boot] [PATCH 3/6] arm: efi: Add a hello world test program

On Mon, Oct 17, 2016 at 07:55:02PM -0600, Simon Glass wrote: > Hi Leif, > > On 26 September 2016 at 19:53, Leif Lindholm <leif.lindh...@linaro.org> wrote: > >> Thanks for the pointer. Unfortunately that patch appears to make no > >> differences for me. Are you a

Re: [U-Boot] [PATCH 3/6] arm: efi: Add a hello world test program

On Mon, Sep 26, 2016 at 08:09:40AM -0600, Simon Glass wrote: > >> >> If so, can we just remove this for arm64? > >> > > >> > Actually I was hoping that Alexander might have a suitable arm64 > >> > HelloWorld.efi lying around. When I tried building UEFI for arm64, for > >> > some reason it did not

Re: [U-Boot] [PATCH 3/6] arm: efi: Add a hello world test program

On Tue, Aug 09, 2016 at 10:55:31PM +0200, Alexander Graf wrote: > > > > Am 09.08.2016 um 20:16 schrieb Simon Glass : > > > > Hi Bin, > > > >> On 9 August 2016 at 00:50, Bin Meng wrote: > >> Hi Simon, > >> > >>> On Sun, Aug 7, 2016 at 7:23 AM, Simon

Re: [U-Boot] [PATCH 3/4] net: Move the VCI and client arch values to Kconfig

On Fri, May 06, 2016 at 10:54:23AM -0400, Tom Rini wrote: > On Wed, May 04, 2016 at 07:10:52PM +0200, Alexander Graf wrote: > > > We have a bunch of boards that define their vendor class identifier and > > client archs in the board files or in the distro config. Move everything > > to the generic

Re: [U-Boot] [PATCH] efi_loader: Reserve 2 additional pages for fdt

On Fri, Mar 04, 2016 at 10:19:10AM +0100, Alexander Graf wrote: > We mark the device tree as reserved today, spanning exactly the amount > of space it needs. If some other piece of code (like grub2) comes in and > wants to modify the device tree to for example add a kernel command line > though,

Re: [U-Boot] [PATCH 14/16] efi_loader: Add distro boot script for removable media

On Tue, Feb 02, 2016 at 03:45:12AM +0100, Alexander Graf wrote: > UEFI defines a simple boot protocol for removable media. There we should look > at the EFI (first GPT FAT) partition and search for /efi/boot/bootXXX.efi with > XXX being different between different platforms (x86, x64, arm, aa64,

Re: [U-Boot] [PATCH 04/16] efi_loader: Add boot time services

On Tue, Feb 02, 2016 at 03:45:02AM +0100, Alexander Graf wrote: > When an EFI application runs, it has access to a few descriptor and callback > tables to instruct the EFI compliant firmware to do things for it. The bulk > of those interfaces are "boot time services". They handle all object >

Re: [U-Boot] [PATCH 09/16] efi_loader: Implement memory allocation and map

On Tue, Feb 02, 2016 at 03:45:07AM +0100, Alexander Graf wrote: > The EFI loader needs to maintain views of memory - general system memory > windows as well as used locations inside those and potential runtime service > MMIO windows. > > To manage all of these, add a few helpers that maintain an

Re: [U-Boot] [PATCH 14/16] efi_loader: Add distro boot script for removable media

On Tue, Feb 02, 2016 at 03:45:12AM +0100, Alexander Graf wrote: > UEFI defines a simple boot protocol for removable media. There we should look > at the EFI (first GPT FAT) partition and search for /efi/boot/bootXXX.efi with > XXX being different between different platforms (x86, x64, arm, aa64,

Re: [U-Boot] [PATCH 03/16] efi_loader: Add PE image loader

On Tue, Feb 02, 2016 at 03:45:01AM +0100, Alexander Graf wrote: > EFI uses the PE binary format for its application images. Add support to EFI > PE > binaries as well as all necessary bits for the "EFI image loader" interfaces. > > Signed-off-by: Alexander Graf > > --- > > v1

Re: [U-Boot] [PATCH 06/14] efi_loader: Add runtime services

On Fri, Jan 15, 2016 at 06:06:12AM +0100, Alexander Graf wrote: > After booting has finished, EFI allows firmware to still interact with the OS > using the "runtime services". These callbacks live in a separate address > space, > since they are available long after U-Boot has been overwritten by

Re: [U-Boot] [PATCH 04/14] efi_loader: Add boot time services

On Fri, Jan 15, 2016 at 06:06:10AM +0100, Alexander Graf wrote: > When an EFI application runs, it has access to a few descriptor and callback > tables to instruct the EFI compliant firmware to do things for it. The bulk > of those interfaces are "boot time services". They handle all object >

Re: [U-Boot] [PATCH 3/9] efi_loader: Add PE image loader

On Fri, Jan 15, 2016 at 12:45:46AM +0100, Alexander Graf wrote: > On 26.12.15 17:26, Leif Lindholm wrote: > >> new file mode 100644 > >> index 000..688e177 > >> --- /dev/null > >> +++ b/lib/efi_loader/efi_image_loader.c > >> @@ -0

Re: [U-Boot] [PATCH 4/9] efi_loader: Add boot time services

On Fri, Jan 15, 2016 at 01:13:15AM +0100, Alexander Graf wrote: > On 26.12.15 19:09, Leif Lindholm wrote: > >> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c > >> new file mode 100644 > >> index 000..ed95962 > >>

Re: [U-Boot] [PATCH 4/9] efi_loader: Add boot time services

On Fri, Jan 15, 2016 at 03:14:54PM +0100, Alexander Graf wrote: > On 15.01.16 14:02, Leif Lindholm wrote: > >>> U-Boot question: is gd->relocaddr always the offset from start of RAM? > >>> How does this work with gaps in memory map? > >> > >> U-Boot

Re: [U-Boot] [PATCH 6/9] efi_loader: Add runtime services

On Fri, Jan 15, 2016 at 03:15:37PM +0100, Alexander Graf wrote: > On 15.01.16 14:52, Leif Lindholm wrote: > >>> "The ResetSystem() function does not return." > >> > >> Hrm, I think returning EFI_UNSUPPORTED is still better than while(1) { > >&

Re: [U-Boot] [PATCH 6/9] efi_loader: Add runtime services

On Fri, Jan 15, 2016 at 01:26:42AM +0100, Alexander Graf wrote: > On 26.12.15 19:33, Leif Lindholm wrote: > >> + .reset_system = (void *)_unimplemented, > > > > "The ResetSystem() function does not return." > > Hrm, I think returning EFI_

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

On Sun, Dec 27, 2015 at 01:10:39PM -0500, Tom Rini wrote: > So, my only "big" concern here is, are we as a community able to view > and implement the relevant parts of the UEFI spec (without having to > agree to a potentially complicated enough license to have to bug a > lawyer)? It's been a

Re: [U-Boot] [PATCH 4/9] efi_loader: Add boot time services

On Tue, Dec 22, 2015 at 02:57:51PM +0100, Alexander Graf wrote: > When an EFI application runs, it has access to a few descriptor and callback > tables to instruct the EFI compliant firmware to do things for it. The bulk > of those interfaces are "boot time services". They handle all object >

Re: [U-Boot] [PATCH 8/9] efi_loader: Add "bootefi" command

On Fri, Dec 25, 2015 at 10:02:44AM +0100, Alexander Graf wrote: > On 24.12.15 12:15, Matwey V. Kornilov wrote: > > Why just not to implement standard EFI behaviour when EFI looks for > > boot-efi partition and proceed? > > Well, what is "standard EFI behavior"? > > There are 2 standard ways I'm

Re: [U-Boot] [PATCH 8/9] efi_loader: Add "bootefi" command

On Fri, Dec 25, 2015 at 10:25:22AM +0100, Andreas Färber wrote: > Am 25.12.2015 um 10:02 schrieb Alexander Graf: > [snip] > > The reason I implemented "bootefi" was really because it's the natural > > fit into how U-Boot handles all other formats today. I don't think this > > is going to be the

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

On Sat, Dec 26, 2015 at 05:27:48PM +0100, Alexander Graf wrote: > >> This patch set is the result of pursuing this endeavor. > > > > Thanks, this is a very cool thing. > > I meant to reply sooner, but Christmas got in the way. > > > >> - I am successfully able to run grub2 and Linux EFI

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

On Tue, Dec 22, 2015 at 02:57:47PM +0100, Alexander Graf wrote: > This is my Christmas present for my openSUSE friends :). > > U-Boot is a great project for embedded devices. However, convincing > everyone involved that only for "a few oddball ARM devices" we need to > support different

Re: [U-Boot] [PATCH 3/9] efi_loader: Add PE image loader

On Tue, Dec 22, 2015 at 02:57:50PM +0100, Alexander Graf wrote: > EFI uses the PE binary format for its application images. Add support to EFI > PE > binaries as well as all necessary bits for the "EFI image loader" interfaces. > > Signed-off-by: Alexander Graf > --- >

Re: [U-Boot] [PATCH 6/9] efi_loader: Add runtime services

On Tue, Dec 22, 2015 at 02:57:53PM +0100, Alexander Graf wrote: > After booting has finished, EFI allows firmware to still interact with the OS > using the "runtime services". These callbacks live in a separate address > space, > since they are available long after U-Boot has been overwritten by

Re: [U-Boot] config: enable CONFIG_API in distro config

On Fri, Apr 18, 2014 at 05:54:51PM -0500, Rob Herring wrote: a) It was excruciatingly slow, to the point of not being useful. b) The binary had hard-coded memory layout, and hence couldn't be generic across multiple boards, since SoCs put their RAM in different places, boards have

Re: [U-Boot] arm: U-Boot API - clang support broke ABI

Hi Jeroen, On Sat, Nov 23, 2013 at 12:20:54PM +0100, Jeroen Hofstee wrote: Commit fe1378a - ARM: use r9 for gd - broke the ABI for users of the U-Boot API on ARM. Users I am aware of are GRUB and the FreeBSD loader. Since I only spotted this on Saturday, this code is well and truly in the

[U-Boot] arm: U-Boot API - clang support broke ABI

Hi, Commit fe1378a - ARM: use r9 for gd - broke the ABI for users of the U-Boot API on ARM. Users I am aware of are GRUB and the FreeBSD loader. Since I only spotted this on Saturday, this code is well and truly in the wild, so any users of the API will need to preserve both r8 and r9 on syscalls

Re: [U-Boot] [PATCH] Save/restore global data pointer on API boundary

On 08/07/12 19:30, Wolfgang Denk wrote: Most architectures keep the global data pointer (gd) in a register. This may, or may not be. You should not make any assumptions on how gd is implemented. The comment did, the code didn't, as long as gd was a pointer (which should be a safe

[U-Boot] [PATCH] Save/restore global data pointer on API boundary

(). This may want to be put behind an ifdef for those architectures that don't use a dedicated register. Signed-off-by: Leif Lindholm leif.lindh...@arm.com --- diff --git a/api/api.c b/api/api.c index a3bf60a..b911270 100644 --- a/api/api.c +++ b/api/api.c @@ -33,6 +33,8 @@ #include api_private.h