[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: Tue, 18 Feb 2014 15:37:04 -0600

Hi Colin,

Just wanting to confirm whether or not this patch has been included upstream yet or not?  And if not, what we need to add/change to get it upstream?  



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]