From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: catalin.marinas@arm.com, labbott@redhat.com,
linux-arm-kernel@lists.infradead.org, ard.biesheuvel@linaro.org
Subject: Re: Memory size and section boundary on armv7
Date: Fri, 12 Apr 2019 14:26:11 +0300 [thread overview]
Message-ID: <20190412112611.GA8295@apalos> (raw)
In-Reply-To: <20190412111614.xbwnffum25ny7ddy@shell.armlinux.org.uk>
> > Can we at least we can print a warning saying "What you are trying to do is not
> > good enough, please re-check the mappings" or something like that,
> > to help people avoid that in the future.
> > The BUG_ON is supposed to do that, but for some reason i can't see it on my
> > console, any ideas why?
>
> That may be a possibility, we would have to ignore the request to setup
> the mapping, which means we could end silently locking up shortly
> there-after.
>
> It may also be possible to slightly rearrange the code to map the
> vectors page before we setup any of the memory mappings (so that
> exceptions can work), but that may need careful handling.
>
Ok, i'll try to have a look at that, since i can easily reproduce the splat
> > Yes. U-Boot wise we could fix that, by placing the dtb on a non section
> > aligned boundary
>
> That's actually misleading.
>
> The problem happens when you have a small no-map section within a 2MB
> region, and it doesn't cross the even-odd 1MB boundary.
>
> To illustrate what I'm saying, if you arranged for it to be (eg) one
> page higher (iow, 0xc7f01000) then you'll hit the same problem.
Yes correct, i actually tried that as well in one of my tests and still had the
same effect
> >
> > The easiest way out of it is to place the fdt on !SECTION_SIZE right?
Yes noted,
Thanks
/Ilias
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-04-12 11:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-11 15:13 Memory size and section boundary on armv7 Ilias Apalodimas
2019-04-11 15:41 ` Russell King - ARM Linux admin
2019-04-11 15:50 ` Ilias Apalodimas
2019-04-11 16:22 ` Russell King - ARM Linux admin
2019-04-12 5:23 ` Ilias Apalodimas
2019-04-12 8:40 ` Russell King - ARM Linux admin
2019-04-12 10:10 ` Ilias Apalodimas
2019-04-12 11:16 ` Russell King - ARM Linux admin
2019-04-12 11:26 ` Ilias Apalodimas [this message]
2019-04-12 11:43 ` Ilias Apalodimas
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=20190412112611.GA8295@apalos \
--to=ilias.apalodimas@linaro.org \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=labbott@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux@armlinux.org.uk \
/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.