If there is more than one loaded image, refuse to automatically select
the image to execute.  There are at least two possible cases, with
different "correct" answers:

1. User loads image A by mistake, then loads image B and types "boot".
   User wants to execute image B.

2. User loads image A, then loads image B (which patches image A), then
   types "boot".  User wants to execute image A.

If a user actually wants to load multiple images, they must explicitly
specify which image is to be executed.

Some shuffling around of the image management code; this needs tidying up.

allows us to avoid execution loops without having to hack around the
image registration order.

download

other protocol won't work at the moment.

reflect the fact that they allocate and deallocate user memory (i.e.
things reached through a userptr_t).

took out the contract to eventually call efree() when it called fetch().

Maintain the most recently loaded image at the start of the list, so that
imgautoselect() will pick it.

returns the allocated buffer.

"kernel".

reference holders that their reference is about to become invalid.

typical build will now include 880 bytes of PCI support code, compared to
2327 bytes in Etherboot 5.4.

(There is a slight cost of around 5 extra bytes per access to a
non-constant config space address; this should be an overall win.
Driver-specific accesses will usually be to constant addresses, for
which there is no additional cost.)

Yes, you really can do it in 65 bytes.