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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox