[Top][All Lists]

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

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

From: Tomohiro B Berry
Subject: Re: [PATCH] Adding Bi-Endian 32-bit and 64-bit Support to the Grub ELF Parser
Date: Mon, 13 Jan 2014 15:29:28 -0600

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.  


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]