linux-kernel - Re: [PATCH v2 1/3] Documentation: arm: add UEFI support documentation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 3 Oct 2013 19:18:02 +0200
From:	Leif Lindholm <leif.lindholm@...aro.org>
To:	Rob Herring <robherring2@...il.com>
Cc:	linux-arm-kernel@...ts.infradead.org, roy.franz@...aro.org,
	linux-efi@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, grant.likely@...retlab.ca,
	matt.fleming@...el.com, msalter@...hat.com,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	arnd@...db.de
Subject: Re: [PATCH v2 1/3] Documentation: arm: add UEFI support documentation

On Thu, Oct 03, 2013 at 11:11:18AM -0500, Rob Herring wrote:
> Adding devicetree list since you are defining bindings...
> 
> > +with CONFIG_OF.
> > +
> > +It parses the FDT /chosen node for the following parameters:
> 
> DT bindings should be documented in Documentation/devicetree/bindings.
> 
> I also wonder if this would be more appropriately placed in a /firmware
> node.

This is information passed to the kernel by the bootloader - not
system descriptiont - so I don't quite see why it needs different
treatment from initrd and bootargs.

Feedback on v1 was:
https://lkml.org/lkml/2013/6/26/378
and
https://lkml.org/lkml/2013/6/27/420

I don't really mind either way, but the current layout is now used
across 3 sets of kernel patches, so we need to reach some sort of
consensus. Interested parties so far: me, you, Grant, Arnd, Mark.

> > +- 'linux,efi-mmap':
> > +  The EFI memory map as an embedded property. (required)
> > +  An array of type EFI_MEMORY_DESCRIPTOR as described by the UEFI
> > +  specification, current version described in Linux by efi_memory_desc_t.
> 
> Is that too complex to describe here?

No, just felt a bit redundant, and also not architecture-specific.

> > +  The memory map is represented in little-endian, not DT, byte order.
> > +  This map needs to contain at least the regions to be preserved for runtime
> > +  services, but would normally just be the map retreieved by calling UEFI
> > +  GetMemoryMap() immediately before ExitBootServices().
> > +- 'linux,efi-mmap-desc-size':
> > +  Size of each descriptor in the memory map. (override default)
> 
> 32-bit value?

Value as returned by the above mentioned GetMemoryMap().
Defined in UEFI specification (and <linux/efi.h>) as 32-bit (native
int). But yes, I can be explicit.

> > +- 'linux,efi-mmap-desc-ver':
> > +  Memory descriptor format version. (override default)
> 
> String? Number?

Value as returned by the above mentioned GetMemoryMap().
Defined in the UEFI specification as 32-bit (uint32), not
architecture specific. And I can add that too.

> Are these all generated by UEFI at runtime or could they be statically
> set in a platform's DTB?

Generated at runtime.
This is not the platform memory map, this is the UEFI memory map,
which tells us which regions we need to preserve for runtime
services, ACPI and such.

> How would other OS's get this information? Is this really linux specific?

The way it is passed through DT is. Other operating systems might keep
boot services running for longer, and make calls into UEFI later, so
not needing to cache the data. Since boot services means the timer
interrupt is active, the ARM Linux boot protocol effectively prohibits
this.

Many of these questions are about generic UEFI mechanisms.
If they need to be documented outside the UEFI specification,
Documentation/arm is not the right place for it.

If you want, I could give a basic Documentation/uefi.txt a shot.

/
    Leif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/