[PATCH v3 2/5] arm64: use fixmap region for permanent FDT mapping

[mark.rutland@arm.com (Mark Rutland)]

On Thu, Apr 09, 2015 at 02:16:23PM +0100, Ard Biesheuvel wrote:
> On 9 April 2015 at 15:12, Mark Rutland <mark.rutland@arm.com> wrote:
> >> >> +NOTE: versions prior to v4.1 require, in addition to the requirements
> >> >> +listed above, that the dtb be placed above the kernel Image inside the
> >> >> +same naturally aligned 512 MB region.
> >> >
> >> > Minor nit: This would read a little better if we just said "versions
> >> > prior to v4.1 also require that ...", dropping "in addition to the
> >> > requirements listed above".
> >> >
> >>
> >> OK
> >>
> >> Actually, I realized that this is incorrect anyway: it is not the same
> >> naturally aligned 512 MB region, it is actually 'within 512 MB of the
> >> start of the kernel Image' since that itself is naturally aligned to
> >> 512 MB in the virtual address space.
> >
> > Surely starting at TEXT_OFFSET bytes below the kernel image? ;)
> >
> 
> Only if you find it acceptable that people start putting their FDT in
> the TEXT_OFFSET region ... :-)

Unfortunately people are already doing such things (which is one reason
I moved the page tables out of the region).

It also means that the region of TEXT_OFFSET bytes below 512M from the
start of the image is unusable...

[...]

> >> I was going to suggest to use SZ_2M for the masking, but map a 4 MB
> >> window. That way, we can relax the requirement from "should not cross
> >> a 2 MB boundary' to 'should not exceed 2 MB in size', which is
> >> arguable easier to adhere to, since the latter is a property of the
> >> DTB itself, whereas the former is a property of whatever your malloc()
> >> gives you. That means the mask would remain SZ_2M, and the size would
> >> become SZ_4M
> >
> > That sounds good so long as it doesn't get in the way of increasing
> > FIX_FDT_SIZE in future.
> >
> 
> No, it shouldn't. And it actually makes it more obvious when we do
> increase it later which values should be left alone (SZ_2M) and which
> values should be increased (the higher ones)

Sounds good to me then.

> Yes. I am currently looking into a way to make early_fixmap_init() not
> rely on __va(), and if that is easily doable, I will propose something
> for the FDT which is quite close to the latest submitted version. But
> otherwise, it may be a bit more complicated, and the FDT mapping needs
> more work.

Ok. I'll keep an eye out then.

Mark.