All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: linux-arm-kernel@lists.infradead.org
Cc: catalin.marinas@arm.com, labbott@redhat.com,
	linux@armlinux.org.uk, mrutland@arm.com,
	ard.biesheuvel@linaro.org
Subject: Memory size and section boundary on armv7
Date: Thu, 11 Apr 2019 18:13:20 +0300	[thread overview]
Message-ID: <20190411151320.GA23031@apalos> (raw)

Hello, 

While experimenting with u-boot and booting the kernel as an EFI stub i seem to
hit an issue with memory mapping (map_lowmem).

I can only reproduce the crash when using u-boot's dtb (specified in
fdtcontroladdr) and pass that to the kernel, instead of loading an external one
with 'dtb=' on it's command line.

If CONFIG_ARM_LPAE=y, everything works fine. If the latter is not selected
though the kernel seems to crash only if dtb is placed on a section boundary.
The reason is crashes is the BUG_ON() on arm_pte_alloc() triggers.

fdt size is 0xc00 in both scenarios.
So something like this works fine:
In this case ff000 + c000 + f5000 = 200000
[    0.000000] MAP addr: c7c00000, next c7e00000, phys c7c00000 len 200000
[    0.000000] INI addr: c7e00000, next c7eff000, len ff000
[    0.000000] INI addr: c7f0b000, next c8000000, len f5000
[    0.000000] MAP addr: c8000000, next c8200000, phys c8000000 len 200000

In this working case kernel maps sizes ff000 and f5000 alloc_init_pte() and
skips the 0xc000 of the fdt correctly

The non-working case is: 
[    0.000000] MAP addr: c7e00000, next c7f00000, phys c7e00000 len 100000
[    0.000000] INI addr: c7f0c000, next c8000000, len f4000

Both entries end up using the same pmd

I am not sure what's the best way to fix that. 
Obviously skipping the alloc_init_pte() once this case is detected fixes things,
but  is there a better idea?


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-11 15:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-11 15:13 Ilias Apalodimas [this message]
2019-04-11 15:41 ` Memory size and section boundary on armv7 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
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=20190411151320.GA23031@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 \
    --cc=mrutland@arm.com \
    /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.