Re: [PATCH] Adding Bi-Endian 32-bit and 64-bit Support to the Grub ELF Parser

[Tomohiro B Berry]

Hi Colin,  

After some testing, it seems that Grub
is able to boot the kernel just fine with an initrd with only these changes.
 The initrd is loaded into memory while still in BE mode and it looks
like the jump is handled in the firmware, so the address and size still
have to be in big endian mode (and in fact byte swapping them on the grub
side breaks the boot process).  So it looks like the initrd will not
be a problem in this case.  

Regards,
Tomo Berry



From:      
 Colin Watson <address@hidden>
To:      
 The development of
GNU GRUB <address@hidden>, 
Cc:      
 Tomohiro B Berry/Austin/address@hidden
Date:      
 01/13/2014 06:52 AM
Subject:    
   Re: [PATCH]
Adding Bi-Endian 32-bit and 64-bit Support to the Grub ELF Parser

---

On Fri, Jan 10, 2014 at 11:52:52PM +0400, Andrey Borzenkov
wrote:
> В Fri, 10 Jan 2014 11:58:58 -0600
> Tomohiro B Berry <address@hidden> пишет:
> > This patch adds bi-endian support for both 32-bit and 64-bit
elf files. 
> > 
> > It compares the native endianness to the endianness of the elf
file, and 
> > swaps the header bytes if necessary.  This will allow, for
example, 32-bit 
> > Big Endian grub to load a 64-bit Little Endian kernel. 
> 
> I wonder - when big endian grub will pass boot parameters to little
> endian kernel - won't there be endianness mismatch?

I think this is probably not a problem for the case at hand (powerpc),
because command-line arguments are passed by way of an IEEE1275 property
rather than using a pointer in a structure as we do on x86.  And the
kernel expects to enter the PROM in 32-bit BE mode, so passing its
address that way round should be fine.

However, Tomohiro, I wonder if you have tested this with an initrd?  I
don't see code in the kernel to cope with a byteswapped initrd address
and size (though I certainly could be missing something).

If that side of things is confirmed to work, then this looks mostly fine
to me.

I wonder if perhaps we ought to only do this on architectures where we
know that the kernel can cope with being entered in the wrong
endianness?  I don't know - maybe we don't need to worry as on other
architectures the chances of running across a wrong-endian kernel are
pretty infinitesimal anyway.

-- 
Colin Watson                  
                    address@hidden