From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] arm64: use fixmap region for permanent FDT mapping
Date: Mon, 2 Mar 2015 15:09:28 +0000 [thread overview]
Message-ID: <20150302150928.GH16779@leverpostej> (raw)
In-Reply-To: <CAKv+Gu8TkDRfYmf+V==m7EJyVGC-ZiCSnTtvmHtHgQtbJJo5Sw@mail.gmail.com>
On Mon, Mar 02, 2015 at 02:47:41PM +0000, Ard Biesheuvel wrote:
> On 2 March 2015 at 14:40, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Fri, Feb 27, 2015 at 02:53:43PM +0000, Ard Biesheuvel wrote:
> >> Currently, the FDT blob needs to be in the same naturally aligned
> >> 512 MB region as the kernel, so that it can be mapped into the
> >> kernel virtual memory space very early on using a minimal set of
> >> statically allocated translation tables.
> >>
> >> Now that we have early fixmap support, we can relax this restriction,
> >> by moving the permanent FDT mapping to the fixmap region instead.
> >> This way, the FDT blob may be anywhere in memory.
> >
> > Neat! I was hoping we'd have the chance to do this at some point.
> >
> > [...]
> >
> >> + /*
> >> + * Reserve 2 MB of virtual space for the FDT at the top of the fixmap
> >> + * region. Keep this at the top so it remains 2 MB aligned.
> >> + */
> >> +#define FIX_FDT_SIZE SZ_2M
> >> + FIX_FDT_END,
> >> + FIX_FDT = FIX_FDT_END + FIX_FDT_SIZE / PAGE_SIZE - 1,
> >
> > Doesn't the presence of the FIX_HOLE entry mean that this isn't 2MB
> > aligned?
> >
>
> Well, the fixmap is a bit odd in this respect: FIXADDR_TOP is
> exclusive, so FIX_HOLE is only there as a placeholder.
Ah, I see.
Given that, shouldn't the test in __set_fixmap be something like:
BUG_ON(idx <= FIX_HOLE || idx >= __end_of_fixed_addresses);
[...]
> > Otherwise this looks good!
> >
>
> Actually, there is a bit of a snag:
> early_init_fdt_scan_reserved_mem() reserves the FDT region, but does
> so by using __pa() to retrieve the physical offset, which doesn't work
> now the FDT is not accessed through the linear mapping.
Ouch.
> I will try and figure out what the best way is to work around this.
> Any and all suggestions appreciated.
We can do the reservation in the arm64 code and move the core part
behind a config option, but that's somewhat ugly. Passing the PA into
early_init_fdt_scan_reserved_mem also feels weird.
I'll have a think too.
Mark.
prev parent reply other threads:[~2015-03-02 15:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-27 14:53 [RFC PATCH] arm64: use fixmap region for permanent FDT mapping Ard Biesheuvel
2015-03-02 14:40 ` Mark Rutland
2015-03-02 14:47 ` Ard Biesheuvel
2015-03-02 15:09 ` Mark Rutland [this message]
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=20150302150928.GH16779@leverpostej \
--to=mark.rutland@arm.com \
--cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.