All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.