On Fri, Aug 13, 2021 at 14:14:27 +0200, Alexander Graf wrote:
> > > There are a few reasons you may want to use eBPF:
> > >
> > > 1) Security
> > > 2) Cross-arch compatibility
> > >
> > > I don't think you can get either in UEFI's current module model, because
> > > you
> > > exchange direct fla
On Fri, Aug 13, 2021 at 12:58:26 +0200, Alexander Graf wrote:
> On 13.08.21 11:54, Leif Lindholm wrote:
> > On Fri, Aug 13, 2021 at 08:18:14 +0200, François Ozog wrote:
> > > This:
> > >
> > > https://linuxfoundation.org/press-release/facebook-google-isovale
On Fri, Aug 13, 2021 at 08:18:14 +0200, François Ozog wrote:
> This:
>
> https://linuxfoundation.org/press-release/facebook-google-isovalent-microsoft-and-netflix-launch-ebpf-foundation-as-part-of-the-linux-foundation
>
> Following earlier addition of eBPF in Windows kernel:
> https://github.com/
On Thu, Apr 15, 2021 at 10:41:28 -0700, ron minnich wrote:
> HOBS are "bad'.
>
> several reasons.
> 1. They depend on the nature of the C compiler and require use of a keyword
> ("packed") known to be an issue.
> (i.e. there are alignment and padding requirements that not all
> compilers handl
Francois already replied more elegantly, but I'll respond regardless.
On Thu, Oct 22, 2020 at 14:15:47 -0600, Simon Glass wrote:
> > If you are looking for a Linux-centric way of getting a
> > fully-vertically-integrated OS up and running with a minimum of code,
> > then that is arguably closer to
On Fri, Oct 09, 2020 at 11:12:35 -0600, Simon Glass wrote:
> > From an EBBR point of view I would expect it to be an implementation
> > decision. For some use cases key enrolment makes sense, for others not
> > so much.
> >
> > In the PC space, Microsoft required that vendors include a means for
>
On Tue, Sep 15, 2020 at 15:04:44 +0100, Grant Likely wrote:
> On 15/09/2020 14:46, Leif Lindholm wrote:
> > On Tue, Sep 15, 2020 at 14:14:30 +0100, Grant Likely wrote:
> > > > The EFI stub in Linux removes /memreserve/ entries from the DT before
> > > >
On Tue, Sep 15, 2020 at 14:14:30 +0100, Grant Likely wrote:
> > > > > > > +``/memory`` node and UEFI
> > > > > > > +~~
> > > > > > > +
> > > > > > > +When booting via [UEFI]_, the system memory map is obtained via
> > > > > > > the
> > > > > > > +GetMemoryMap() UEFI boot ti
On Thu, Mar 19, 2020 at 12:31:37 +0100, François Ozog wrote:
> On Thu, 19 Mar 2020 at 12:05, Leif Lindholm wrote:
> > I'm pretty sure Heinrich's concerns with this description are similar
> > to my own, and boil down to one thing: this sounds like inventing new
>
Hi Ilias,
On Thu, Mar 19, 2020 at 12:33:30 +0200, Ilias Apalodimas wrote:
> On Thu, Mar 19, 2020 at 10:45:31AM +0100, Heinrich Schuchardt wrote:
> > > > As some of you may know, I'm going to submit a RFC patch series for UEFI
> > > > capsule support on U-Boot in a week or so (maybe). With this pat
Minor comment:
On Tue, Mar 10, 2020 at 17:02:27 +0100, Francois Ozog wrote:
> 0.2 - normative text
> The normative section shall be stated clearly: is " 1.2. Guiding
> Principles" normative?
>
> IETF and ETSI have different language conventions to express
> absolutely mandated and various levels
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 here
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
FYI: EDK2 development mailing list changing to de...@edk2.groups.io
This will give us some better flexibility with regards to whitelisting
non-subscribers and suchlike currently not possible through 01.org.
On Wed, Apr 03, 2019 at 10:59:31AM -0500, stephano wrote:
> tl;dr
> If you're sending emai
On 4 August 2018 at 05:51, Simon Glass wrote:
> >> On Fri, Aug 03, 2018 at 05:34:05PM +0100, Grant Likely wrote:
> >>
> >>> Anyone familiar with Open Source Firmware Conference coming up in
> >>> September? Is this just a PC firmware thing, or do we have some U-Boot
> >>> involvement?
> >>>
> >>>
On Tue, May 08, 2018 at 11:57:38AM +0100, Daniel Thompson wrote:
> > > > No sure how other OSes like Windows or ubuntu make this happen. But
> > > > they do call SetVariable during runtime such as to set OsIndications
> > > > or BootNext to reboot to BIOS system utility.
> > >
> > > Sorry, just no
(Whoops, boot-architecture wasn't on cc on this thread, forwarding
message there for public archiving. Please add arm.ebbr-discuss to cc
on any replies.)
On Wed, May 02, 2018 at 06:09:15PM -0400, Tom Rini wrote:
> On Wed, May 02, 2018 at 10:48:11PM +0100, Grant Likely wrote:
> > On 02/05/2018 22:2
On Mon, Apr 30, 2018 at 02:26:22PM +, Chang, Abner (HPS SW/FW Technologist)
wrote:
> > > I guess it would be possible to implement this in code. The problem is
> > > that the UEFI spec does not cover any of this, and so there is no way
> > > for the OS to find out whether it can call SetVariab
On Thu, Apr 26, 2018 at 12:52:04PM -0400, William Mills wrote:
> Driver and Boot### global variable entries. If present, these
> entries will be processed in the order specified by corresponding
> statically defined SysPrepOrder, DriverOrder and BootOrder global
> variables.
I took an action last week to provide a block of text for how
platforms without persistent variable storage should behave. Here's my
opening play:
Boot manager behaviour without persistent variable store
===
Platforms that do not implement pers
Adding linaro-u...@lists.linaro.org, which is the more appropriate
mailing list for this topic.
On Mon, May 22, 2017 at 04:44:00PM +0530, Mohan Rao .vanimina wrote:
> When trying to boot-up BeagleBoneBlack Platform using UEFI with below
> procedure (instead of U-boot), ran into following issue.
>
On Wed, Jul 08, 2015 at 09:22:32AM -0700, Blibbet wrote:
> On 07/08/2015 07:24 AM, Leif Lindholm wrote:
> > On Wed, Jul 01, 2015 at 12:59:12PM +, Meenakshi Aggarwal wrote:
> >> This is my first query on this list. I apologize for any mistake.
>
> This is also my
Hi Meenakshi,
On Wed, Jul 01, 2015 at 12:59:12PM +, Meenakshi Aggarwal wrote:
> This is my first query on this list. I apologize for any mistake.
None spotted.
> I have some queries on following patch :
> https://lists.linaro.org/pipermail/boot-architecture/2013-June/000325.html
>
> I am no
Hi Ryan,
On Tue, Nov 19, 2013 at 08:30:25AM +, Ryan Harkin wrote:
> Hi Olivier/Steve/Leif/whoever is interested,
>
> I have a problem I'm trying to solve and I don't think there is a proper
> solution using the current ARM BDS.
>
> Basically, some of Linaro's releases are failing to boot "ou
On Mon, Sep 30, 2013 at 10:28:49PM +0100, Grant Likely wrote:
> > > load image protocol. In that case the sub should override the setting in
> the
> > > FDT if the initrd argument is present.
> >
> > Hmm, well, it's slightly worse than that - it will have one; only it
> > will be GRUB's command lin
On Mon, Sep 30, 2013 at 09:05:04PM +0100, Grant Likely wrote:
> > Handling the 2 cases is not a problem. I just don't want to handle
> > 'mixed' cases where
> > a command line and an FDT are passed to the stub, and information from
> > both is used.
> >
> > As I understand it, the two cases are:
>
On Mon, Sep 30, 2013 at 12:16:08PM -0700, Roy Franz wrote:
> >> So ... I guess that would modify the stub behaviour to:
> >> - Look for an FDT_GUID configuration table.
> >> - If there, use it.
> >> - If not there, require one to be loaded based on command line.
> >
> > Create a mostly empty one fo
On Mon, Sep 30, 2013 at 07:27:58PM +0100, Grant Likely wrote:
> > So ... I guess that would modify the stub behaviour to:
> > - Look for an FDT_GUID configuration table.
> > - If there, use it.
> > - If not there, require one to be loaded based on command line.
>
> Create a mostly empty one for pa
On Mon, Sep 30, 2013 at 08:05:59AM -0700, Roy Franz wrote:
> > I was thinking that the stub would want to use the FDT passed by grub
> > if one is passed, but I hadn't thought about the case where grub wants
> > to pass information to the stub, but the stub still loads the FDT. The
> > easiest thin
Hi guys,
I've been looking at the patches Matthew Garrett wrote for loading a
UEFI stub kernel through GRUB, and noticed one thing that may require
updates to the stub code: it uses GRUB to load the initrd.
Doing this of course means the initrd does not need to go into the EFI
System Partition, wh
good idea for us to mention that in the documentation.
I do not recognise the other error message.
/
Leif
On Mon, Sep 02, 2013 at 05:01:23PM +0530, Vijay Kilari wrote:
> Hi Leif Lindholm,
>
>
>I am changing to UEFI from u-boot on my TC2 board.
> I have followed the st
When testing Roy Franz's ARM UEFI stub kernel loader patches on a TC2
platform, the loader (correctly) highlighted an issue that has been
lurking unnoticed for a while: the very UEFI image actually makes
following the Linux boot protocol impossible.
Roy's stub takes the paranoid (and correct) appr
efi_lookup_mapped_addr is a handy helper function for translating
a physical address to the corresponding virtual one by scanning
through memmap.map.
This patch breaks it out into a new file for use elsewhere.
Signed-off-by: Leif Lindholm
---
arch/x86/platform/efi/efi.c | 28
Since the efi_set_virtual_address_map call has strict init ordering
requirements, add an explicit hook in the required place.
Signed-off-by: Leif Lindholm
---
init/main.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/init/main.c b/init/main.c
index 9484f4b..c61706e 100644
--- a
This patch implements basic support for UEFI runtime services in the
ARM architecture - a requirement for using efibootmgr to read and update
the system boot configuration.
It also locates any presented SMBIOS configuration table and stores it
for potential later use by DMI.
Signed-off-by: Leif
services on ARM
platforms, as well as the basic underlying EFI support. It also defines a
mechanism by which the required information is passed from the bootloader
to the kernel via FDT entries.
This patchset depends on the previously submitted early_ioremap() patchset.
Leif Lindholm (4
This patch provides documentation of the [U]EFI runtime services and
configuration features.
Signed-off-by: Leif Lindholm
---
Documentation/arm/00-INDEX |3 +++
Documentation/arm/uefi.txt | 39 +++
2 files changed, 42 insertions(+)
create mode 100644
This patch adds support for early_ioremap, based on the existing
mechanism in x86. Up to 7 regions of up to 128KB each can be
temporarily mapped in before paging_init, regardless of later highmem
status.
Signed-off-by: Leif Lindholm
---
arch/arm/Kconfig | 20 +++
arch/arm/include
This patch provides documentation of the early_ioremap() functionality,
including its implementation and usage instructions.
Signed-off-by: Leif Lindholm
---
Documentation/arm/00-INDEX |2 ++
Documentation/arm/early_ioremap.txt | 12
2 files changed, 14 insertions
of early_ioremap(), available
before paging_init() only. Like the x86 code on which it is based, it
(p)re-uses the fixmap regions for its virtual mapping range. Up to 7
simultaneous mappings of up to 128KB can be accommodated in the available
fixmap space.
Leif Lindholm (2):
Documentation: arm
On 24 June 2013 10:08, Ryan Harkin wrote:
> On 24 June 2013 08:44, Dong, Eric wrote:
>> This change is not correct, the "Buffer" variable is not defined.
>
> Hmmm, isn't that curious! I've not really looked that this change
> before, which is my mistake for accepting it, but you're right, Buffer
fixed tomorrow.
Again, early reviewing would be appreciated.
/
Leif
>From 4e410d8e615701ab5320c1a85087457553609088 Mon Sep 17 00:00:00 2001
From: Leif Lindholm
Date: Thu, 25 Apr 2013 22:21:52 +
Subject: [PATCH 2/2] Initial ARMv7-A (U)EFI runtime services support.
Includes some nasty ha
, and then send it upstream later this week.
Early reviewing would be much appreciated.
/
Leif
>From ef2136643ce687f6980ed8d7bb1f67a6da6e7931 Mon Sep 17 00:00:00 2001
From: Leif Lindholm
Date: Mon, 10 Jun 2013 13:50:57 +0100
Subject: [PATCH 1/2] Add early_ioremap() support for ARMv7.
Rest
On 26 Apr 2013 22:14, "Jean-Christophe PLAGNIOL-VILLARD" <
plagn...@jcrosoft.com> wrote:
> > Contains a few known bugs, and will need some fundamental
> > discussions/reengineering, but lets us start experimenting.
>
> impossible to test on omap4 as it's impossible to run the UEFI on qemu or
> real
Terse information, more engineering notes than documentation, and
links to sources can be found at:
https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/RuntimeServices
Contains a few known bugs, and will need some fundamental
discussions/reengineering, but lets us start experimenting.
/
Leif
45 matches
Mail list logo
