On Wed, Aug 07, 2013 at 07:05:54PM +0100, Dave Martin wrote:

Is it possible for this allocation to fail -- i.e., because UEFI has
put us in an unsuitable location which is within the first 128MB of
RAM, such that we can't pick a suitable location without overlap?

For the time being though, I think this is impossible because the
decompressed Image can't exceed ~32MB (so the zImage should not
exceed that either, and both can fit inside 128MB.  It doesn't
matter if UEFI's initial load location overlaps the decompressed
Image).

If UEFI put reserved regions with the first 128MB we're likely to
be dead anyway, so we shouldn't assume we'll have to cope with that
for now...

There is no reason we would be dead unless we end up not being able
to allocate regions for FDT and initrd within range.

There could be some boot services region lying around, that will
be reusable before we even jump to the decompressor. Or there could
be some badly placed runtime code lying where it can safely remain.

Are there additional kernel regions to worry about?

quoted

+		@ Save return values of efi_entry
+		stmfd	sp!, {r0, r3}
+		bl	cache_clean_flush
+		bl	cache_off

Why turn the cache off?  Does that mean that EFI may launch images with
the cache enabled?

 
Yup.

If so, are we guaranteed that VA=PA?  Otherwise simply turning the MMU
off is not safe.

Yes, VA=PA is guaranteed.
 

(Hmm, the UEFI spec seems to suggest "yes" for these questions)

 
:)

/
    Leif