[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RFC: initramfs-tools support for early firmware loading



As of Linux kernel 3.9, support for supplying early firmware data to the
kernel has been added.  Currently, it is used for early microcode updates
for Intel processors, and ACPI table overrides.

This is a very important feature, that we should support as soon as
practical.  ACPI table overrides can massage less-than-stellar firmware into
something usable, and early CPU microcode update are the only way (other
than a BIOS upgrade) to avoid certain CPU defects.

To supply early firmware data to the kernel, we have to *prepend* an
uncompressed cpio archive to the initramfs image.  The initramfs image
itself can be compressed as usual.

Currently, initramfs-tools has undocumented support for appending data to
the initramfs image.  This is now useless.  We need to enhance
initramfs-tools to support adding arbritary files to a cpio archive that
needs to be prepended to the initramfs image.

The kernel cpio parser is very dumb: it will happly grok unterminated
cpio archives[1], which allows us to prepend any number of such
quasi-cpio archives to the initramfs.  This would be very easy to implement,
in a similar way to the undocumented "catenate_cpiogz" functionality.
However, producing unterminated cpio archives require special tools.

I *think* the kernel will also happly skip any EOF cpio records
("TRAILER!!!" records), which would allow for prepending any number of
regular cpio archives created with a suitably small block size.  But this is
not set in stone, if we want it to be that way, I'd have to request it.  And
I would have to request it *really* *soon*.

Alternatively, we'd have to reserve a filesystem tree somewhere (probably
/boot or /etc) and generate the early firmware cpio archive if it contains
any files.  This is easy enough to do, however it is also a lot less
flexible than allowing dynamic generation of quasi-cpio archives by the hook
scripts.

I am volunteering to write any required tools and patches (including kernel
ones), but I want a second opinion on which way should we take: dynamic
generation, or cpio of an static tree somewhere in /boot or /etc ?

[1] the kernel wants a cpio archive in the 0x070701 format ("newc"), and
doesn't care for the "TRAILER!!!" EOF marker.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


Reply to: