From mboxrd@z Thu Jan 1 00:00:00 1970 From: Catalin Marinas Subject: Re: [PATCH 1/3] arm64: add EFI stub Date: Thu, 5 Dec 2013 15:28:06 +0000 Message-ID: <20131205152806.GC974@darko.cambridge.arm.com> References: <1385762712-17043-1-git-send-email-msalter@redhat.com> <1385762712-17043-2-git-send-email-msalter@redhat.com> <20131205141853.GA974@darko.cambridge.arm.com> <1386254603.1861.120.camel@deneb.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1386254603.1861.120.camel-PDpCo7skNiwAicBL8TP8PQ@public.gmane.org> Sender: linux-efi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Mark Salter Cc: "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "patches-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org" , Ard Biesheuvel , Will Deacon , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org" , "linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Leif Lindholm , "roy.franz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org" List-Id: linux-efi@vger.kernel.org On Thu, Dec 05, 2013 at 02:43:23PM +0000, Mark Salter wrote: > On Thu, 2013-12-05 at 14:18 +0000, Catalin Marinas wrote: > > On Fri, Nov 29, 2013 at 10:05:10PM +0000, Mark Salter wrote: > > > This patch adds PE/COFF header fields to the start of the Image > > > so that it appears as an EFI application to EFI firmware. An EFI > > > stub is included to allow direct booting of the kernel Image. Due > > > to EFI firmware limitations, only little endian kernels with 4K > > > page sizes are supported at this time. > > > > I don't fully understand the EFI firmware limitations but for big endian > > we could have the EFI_STUB wrapper in little endian and get the kernel > > to switch to big endian once booted. The image header should always be > > little endian. > > That would be fun. :) You'd also have to switch back and forth to make > EFI runtime services calls. OK, we'll have to live with this restriction. > > And I have to dig further into the 4K limitation (or you could give a > > quick summary ;)). > > Just that the current UEFI spec mandates 4K pages for UEFI. So if UEFI > maps two 4k pages with different attributes and those two pages are > within the same 64k kernel page, there'd be a problem. I'd be better if > UEFI used 64k pages, then the kernel could easily use 4k or 64k. For server space, we may see some people asking for 64K pages. But I don't know whether there are any UEFI plans here. Thanks. -- Catalin