On Mon, Nov 13, 2023 at 05:07:43PM -0600, Jon Humphreys wrote:
> Daniel Thompson <daniel.thomp...@linaro.org> writes:
> > On Mon, Nov 13, 2023 at 11:18:04AM -0600, Jon Humphreys wrote:
> >> - why is EBBR dictating the location of firmwares? The firmware
> >> locations are a contract with the boot ROM and subsequent stages,
> >> leading up to the OSloader. The OSloader hand-off interface is the
> >> real EBBR contract with an OS provider, I would think.
> >
> Mostly it recommends rather that dictates...
>
> ok, thanks for the reminder on should vs shall. Re-looking at the spec,
> there are no SHALLS regarding firmware locations.
I'm not sure whether it is imminent but I think it possible that at
some point the current EBBR will become "EBBR level N" and the
recommendations will become requirements for level N+1.
> >> Firmware locations:
> >> -------------------
> >> - the EBBR states that a dedicated partition is preferred for storing
> >> firmware. This seems to imply that all firmwares will be in a single
> >> location. This isn't true in many cases (eg, some partitions aren't
> >> large enough and subsequent stages are loaded from a different
> >> partition). Is there guidance (or should be guidance) in EBBR on how
> >> to handle these scenarios?
> >
> > Not sure what you mean here. In general if a partition containing a
> > filesystem isn't big enough then we can just make it bigger...
>
> Not always. Consider a eMMC hardware partition that is limited in size.
> For example, BeaglePlay will put the first stage SPL in the eMMC hardware
> partition
> and other stages (eg, u-boot) in the UDA partition, so that all stages
> will fit.
There is lots of scope for confusion here since the plural form of
firmware is firmware ;-) .
IMHO the size of a hardware partition (or SPINOR) isn't in scope for
this particular EBBR recommendation! The recommendation you mention is
that when firmware is located in shared storage that it be placed in a
single partition.
Interestingly it sounds like BeaglePlay is an example where the EBBR
recommendations w.r.t. shared storage can be applied without requiring
changes to the boot ROM (e.g. if GPT/FAT support can be fitted into the
SPL then adopting this EBBR recommendation is "just software" ;-) ).
> From what you have said, the main point is to reduce the possibility of
> the OS messing with the firmware, so the spec recommends that the
> firmware be in dedicated partitions. This is clear at the beginning of
> chapter 4:
>
> In general, EBBR compliant platforms should use dedicated
> storage for boot firmware images and data ...
>
> What confused me is that 4.2 goes a bit further is specifying firmware
> to be stored in "a dedicated firmware partition". (But no SHALLs here!)
> Maybe replace "a dedicated firmware partition" with "dedicated firmware
> partitions".
I've worked on platforms where the firmware mandates multiple partitions
in the shared storage. The problem is these partitions proliferate
because "let's have one partition for every microcontroller/co-processor
on the SoC". On such systems even *before* we try to author media that
can boot on multiple devices we already have 16+ partitions for firmware.
AFAIR remember the logic behind recommending a single FAT-formatted
firmware partition is that read-only FAT drivers are fairly trivial
and much preferable to using the GPT as a pseudo-filesystem. Thus
I believe recommending a single firmware partition in shared storage
is intentional.
> >> Device Tree:
> >> ------------
> >> - The EBBR requires a device tree file (or ACPI table). It makes
> >> complete theoretical sense that the board firmware should supply the
> >> DTB, since it is (in theory) a description of the hardware, which
> >> obviously doesn't change. But the unfortunate reality is that the
> >> device tree is always changing to stay in sync with the kernel. My
> >> experience is that OS images ship with a corresponding device
> >> tree. But the device tree location is one example where the EBBR does
> >> not specify a convention. How can the EBBR handle this reality so
> >> that we can standardize where an OS vendor can place its version of
> >> the DTB?
> >
> > Does EBBR need to specify that? OS will normally provide an
> > OS bootloader (grub, systemd-boot, etc) and since the OS "owns"
> > the configuration for that bootloader is already has full
> > control over where alternative DTs are loaded from.
> >
> > Note also the discusison w.r.t. the EFI_DT_FIXUP_PROTOCOL which
> > is a potentially useful EBBR feature to help support OS provided
> > device trees.
> >
>
> Your point is that if the OS cares enough about using a particular DTB,
> then it should specify it in the OS loader (eg, "devicetree" grub2
> command), right? True, but I wouldn't say it is normal. I don't see
> Debian or Fedora using it. Instead I see them relying on conventions
> that don't work for all vendors. So there needs to be some influence to
> have these guys start using OS loader commands to explicitly specify the DTB.
Through initiatives like UKI the distros are going to increase
convergence but why do generic distros need to provide identical
ways to hack at the devicetree? They already have a common way to
obtain the devicetree using UEFI *and* a common way to update obsolete
firmware (e.g. old devicetrees) with fwupd and capsule update.
Once a distro has to "just know"[1] what devicetree is has to offer the
firmware on order to boot then on it's way to not being a generic distro
any more! That's fine and is entirely legitimate from an EBBR perspective.
However expecting generic distros to standardize infrastructure that is
only useful for custom distros is unrealistic.
[1] There is a difference between the distro "just knowing" and the
administrator knowing. For example distros already offer
infrastructure that gives the admin the freedom to customize the
devicetree. For example, in Debian:
https://gist.github.com/daniel-thompson/dbc23bd3f4560b0d363187de212e7510
> And yes, DTB fix-up would be an issue.
>
> Alternately, we could add some standard to the EBBR that specifies where
> an OS should put a DTB if it wants the firmware to pick it up. Then,
> that DTB goes through the normal firmware handling, including fix-ups.
> (We would need to factor in security, though, but this is true
> regardless of the approaches taken.)
When alternative devicetrees are required I think UKI is a pretty
good standard to adopt. This is noteworthy here because UKI is
mostly implemented by the OS...
Daniel.
_______________________________________________
boot-architecture mailing list -- boot-architecture@lists.linaro.org
To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
