From: Thomas Leonard <talex5@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: David Scott <Dave.Scott@eu.citrix.com>,
Anil Madhavapeddy <anil@recoil.org>,
Julien Grall <julien.grall@linaro.org>,
Samuel Thibault <samuel.thibault@ens-lyon.org>,
xen-devel@lists.xenproject.org,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [PATCH ARM v6 00/14] mini-os: initial ARM support
Date: Fri, 18 Jul 2014 09:17:53 +0100 [thread overview]
Message-ID: <CAG4opy_mLj08peBmZ37COWqu=uk2kE81d38tEoBSfRyHStVcQw@mail.gmail.com> (raw)
In-Reply-To: <1405612519.4686.1.camel@kazak.uk.xensource.com>
On 17 July 2014 16:55, Ian Campbell <Ian.Campbell@citrix.com> 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
next prev parent reply other threads:[~2014-07-18 8:17 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-16 11:07 [PATCH ARM v6 00/14] mini-os: initial ARM support Thomas Leonard
2014-07-16 11:07 ` [PATCH ARM v6 01/14] mini-os: x86_64: make thread stacks 16-byte aligned Thomas Leonard
2014-07-17 15:50 ` Ian Campbell
2014-07-17 18:15 ` Samuel Thibault
2014-07-18 10:00 ` Ian Campbell
2014-07-18 13:22 ` Samuel Thibault
2014-07-17 18:15 ` Samuel Thibault
2014-07-16 11:07 ` [PATCH ARM v6 02/14] mini-os: don't include lib.h from mm.h Thomas Leonard
2014-07-16 13:30 ` Thomas Leonard
2014-07-17 15:51 ` Ian Campbell
2014-07-17 18:17 ` Samuel Thibault
2014-07-16 11:07 ` [PATCH ARM v6 03/14] mini-os: added HYPERVISOR_xsm_op Thomas Leonard
2014-07-16 11:07 ` [PATCH ARM v6 04/14] mini-os: headers for ARM Thomas Leonard
2014-07-16 21:25 ` Julien Grall
2014-07-17 8:14 ` Thomas Leonard
2014-07-17 9:04 ` Ian Campbell
2014-07-17 11:41 ` Julien Grall
2014-07-17 15:59 ` Ian Campbell
2014-07-18 1:29 ` Chen Baozi
2014-07-18 7:58 ` Thomas Leonard
2014-07-17 18:27 ` Samuel Thibault
2014-07-18 7:54 ` Thomas Leonard
2014-07-16 11:07 ` [PATCH ARM v6 05/14] mini-os: import libfdt Thomas Leonard
2014-07-16 11:44 ` Andrew Cooper
2014-07-16 12:29 ` Ian Campbell
2014-07-16 13:02 ` Andrew Cooper
2014-07-16 13:34 ` Ian Campbell
2014-07-16 14:13 ` Anil Madhavapeddy
2014-07-16 14:35 ` Ian Campbell
2014-07-17 18:30 ` Samuel Thibault
2014-07-16 11:07 ` [PATCH ARM v6 06/14] mini-os: use generic local_irq_enable function Thomas Leonard
2014-07-17 16:00 ` Ian Campbell
2014-07-17 18:32 ` Samuel Thibault
2014-07-16 11:07 ` [PATCH ARM v6 07/14] mini-os: arm: boot code Thomas Leonard
2014-07-16 21:49 ` Julien Grall
2014-07-17 9:37 ` Thomas Leonard
2014-07-17 9:46 ` Ian Campbell
2014-07-17 9:48 ` Thomas Leonard
2014-07-17 16:28 ` Ian Campbell
2014-07-30 10:47 ` Thomas Leonard
2014-07-30 11:26 ` Ian Campbell
2014-07-30 12:20 ` Thomas Leonard
2014-07-30 12:54 ` Ian Campbell
2014-07-30 13:37 ` Thomas Leonard
2014-07-30 13:43 ` Ian Campbell
2014-07-16 11:07 ` [PATCH ARM v6 08/14] mini-os: arm: memory management Thomas Leonard
2014-07-21 17:36 ` Julien Grall
2014-08-03 10:23 ` Thomas Leonard
2014-07-16 11:07 ` [PATCH ARM v6 09/14] mini-os: arm: scheduling Thomas Leonard
2014-07-28 10:53 ` Ian Campbell
2014-07-28 11:20 ` Thomas Leonard
2014-07-28 11:26 ` Ian Campbell
2014-07-16 11:07 ` [PATCH ARM v6 10/14] mini-os: arm: events Thomas Leonard
2014-07-28 10:55 ` Ian Campbell
2014-07-16 11:07 ` [PATCH ARM v6 11/14] mini-os: arm: time Thomas Leonard
2014-07-21 17:45 ` Julien Grall
2014-07-28 10:41 ` Ian Campbell
2014-07-16 11:07 ` [PATCH ARM v6 12/14] mini-os: arm: interrupt controller Thomas Leonard
2014-07-21 17:56 ` Julien Grall
2014-07-16 11:07 ` [PATCH ARM v6 13/14] mini-os: arm: build system Thomas Leonard
2014-07-16 22:03 ` Julien Grall
2014-07-17 10:16 ` Thomas Leonard
2014-07-28 10:58 ` Ian Campbell
2014-07-16 11:07 ` [PATCH ARM v6 14/14] mini-os: arm: show registers, stack and exception vector on fault Thomas Leonard
2014-07-28 11:13 ` Ian Campbell
2014-07-28 11:49 ` Thomas Leonard
2014-07-28 12:01 ` Ian Campbell
2014-07-16 21:29 ` [PATCH ARM v6 00/14] mini-os: initial ARM support Julien Grall
2014-07-17 15:55 ` Ian Campbell
2014-07-17 16:17 ` Ian Campbell
2014-07-18 8:07 ` Thomas Leonard
2014-07-18 8:17 ` Thomas Leonard [this message]
2014-07-18 10:07 ` Ian Campbell
2014-07-18 12:45 ` Ian Campbell
2014-08-05 10:56 ` Thomas Leonard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAG4opy_mLj08peBmZ37COWqu=uk2kE81d38tEoBSfRyHStVcQw@mail.gmail.com' \
--to=talex5@gmail.com \
--cc=Dave.Scott@eu.citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=anil@recoil.org \
--cc=julien.grall@linaro.org \
--cc=samuel.thibault@ens-lyon.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).