From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Leonard Subject: Re: [PATCH ARM v6 00/14] mini-os: initial ARM support Date: Fri, 18 Jul 2014 09:17:53 +0100 Message-ID: References: <1405508874-3921-1-git-send-email-talex5@gmail.com> <53C6EECF.3020102@linaro.org> <1405612519.4686.1.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1X83Ma-0004fX-F1 for xen-devel@lists.xenproject.org; Fri, 18 Jul 2014 08:17:56 +0000 Received: by mail-oa0-f49.google.com with SMTP id eb12so2542018oac.22 for ; Fri, 18 Jul 2014 01:17:53 -0700 (PDT) In-Reply-To: <1405612519.4686.1.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: David Scott , Anil Madhavapeddy , Julien Grall , Samuel Thibault , xen-devel@lists.xenproject.org, Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 17 July 2014 16:55, Ian Campbell wrote: > On Wed, 2014-07-16 at 22:29 +0100, Julien Grall wrote: > >> > There are two assumptions the code makes that may need changing in the future, but >> > which hopefully don't need to hold up this initial support: >> > >> > - The assumption that the kernel will be loaded at start of RAM + 0x8000. >> > >> > - The assumption that Xen will mark the GIC address range as device memory. >> > This should probably be fixed when the C code gains the ability to control >> > the translation tables, map 4K pages, etc. >> >> I'm fine with the assumptions for an initial support. Did you write-down >> somewhere those restrictions? So if an issue happen in the future, we >> will be able to find quickly the issue. > > Yeah. we can live with them for now, I think. It should be documented > though. I've noted the offset requirement in the linker script and the GIC memory type assumption in a comment in gic.c. > What sort of time line are you foreseeing for fixing them, in terms of > before or after 4.5? If the GIC will always occupy a distinct set of 1MB sections then flagging those is easy enough. Otherwise, we'd have to add support for the second-level page tables, which would complicate things a little. Making the boot code work from arbitrary offsets looks very difficult. I guess we'd need to compile libfdt as PIC, set up a temporary C stack after the kernel (we can assume there's some RAM following it I think), parse the FDT to find the base address, copy the kernel forwards or backwards word by word (first copying the copying code to a safe location somewhere). It all seems very inefficient. From my point of view, it would seem better to have some way to specify the desired load offset. > We should probably consider sticking a "tech preview" or similar label > on mini-os/ARM in 4.5 if these issues remain (the load address one in > particular). -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA