public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] [U-boot]: Change FDT memory typpe from runtime data to acpi reclaim
Date: Fri, 12 Apr 2019 20:36:08 +0300	[thread overview]
Message-ID: <20190412173608.GA16789@apalos> (raw)
In-Reply-To: <210d135d-0b9b-62b6-14b3-af4d79800d9d@gmx.de>

Hi Heinrich,

> 
> Hello Ilias, hello Ard,
> 
> please, have a look at this patch:
> 
> efi_loader: update virtual address in efi_mem_carve_out
> https://lists.denx.de/pipermail/u-boot/2019-April/364937.html
> 
> Possibly the bug reported here could have contributed the Linux crash
> you experienced.
> 
Thanks for the heads up.
Unfortunately i've already tried that. I was talking to Patrick before he posted
the patch upstream. This seems unrelated anyway (all my tests were with the
patch applied regardless)
https://lore.kernel.org/linux-arm-kernel/20190411151320.GA23031 at apalos/
This has an explanation on the problem. 

The tl;dr version (quoting Russell)

"It is also designed to allow hardware-section sized mappings (making
it possible to map sections on 1MB granularity) but as a single Linux
page table always occupies 2MB, it is not permitted for the unused
half of an aligned 2MB slot to be used for a page table mapping -
hence this BUG_ON().
The ARM early mapping routines are intentionally designed such that
areas of memory that they are asked to map are non-overlapping - it
is the caller's responsibility to ensure this."

In order to make sure this won't trigger we got to make sure that the fdt is
placed on the first 1mb boundary of the memory (of any 2mb aligned area)
thus forcing the kernel to init the pte's correctly, 
instead of trying to do section mappings for the memory in that area.

The problem happens when you have a small no-map section within a 2MB
region, and it does cross the even-odd 1MB boundary.
So fdt at 0x7f00000 (or any other are after that like 0xc7f01000) will crash 
the kernel with a BUG_ON().
Placing it in 0x7e01000-7eFF000 would be fine (on armv7's with LPAE off in the
kernel)

Thanks
/Ilias

  parent reply	other threads:[~2019-04-12 17:36 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-11 18:39 [U-Boot] [PATCH] [U-boot]: Change FDT memory typpe from runtime data to acpi reclaim Ilias Apalodimas
2019-04-11 18:43 ` Ard Biesheuvel
2019-04-11 18:46   ` Ilias Apalodimas
2019-04-11 19:34 ` Heinrich Schuchardt
2019-04-11 19:41   ` Ilias Apalodimas
2019-04-11 19:59     ` Heinrich Schuchardt
2019-04-11 20:50       ` Ard Biesheuvel
2019-04-12 17:16         ` Heinrich Schuchardt
2019-04-12 17:24           ` Ard Biesheuvel
2019-04-12 17:44             ` Heinrich Schuchardt
2019-04-12 17:47               ` Ard Biesheuvel
2019-04-12 17:36           ` Ilias Apalodimas [this message]
2019-04-12 17:49             ` Heinrich Schuchardt
2019-04-11 19:50   ` Ard Biesheuvel
2019-04-11 20:08     ` Heinrich Schuchardt
2019-04-11 20:44       ` Ard Biesheuvel
2019-04-12 19:24       ` Leif Lindholm

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=20190412173608.GA16789@apalos \
    --to=ilias.apalodimas@linaro.org \
    --cc=u-boot@lists.denx.de \
    /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