mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Ahmad Fatoum <>
To: Ian Abbott <>,
	Barebox List <>
Subject: Re: [v2022.10.0] initcall of of_probe_memory failed (EBUSY)
Date: Mon, 17 Oct 2022 16:45:48 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hello Ian,

On 17.10.22 16:32, Ian Abbott wrote:
> On 17/10/2022 14:41, Ahmad Fatoum wrote:
>> The correct solution would be removing the memory@0 node from the
>> device tree. After all, if barebox has read it from hardware,
>> why hardcode it in the device tree?
> Most of those device trees are copied from Linux where it makes sense to have the memory node.

With many other SoCs, the memory node is omitted and the bootloader is
expected to fix it up. For the barebox DT in arch/arm/dts/ I'd suggest
it be deleted if the platform queries the memory controller.
If the DT is in dts/src/arm, it can be overridden in barebox DT
with /delete-property/ &{/memory@0};

>> Still, barebox was supposed to have logic to fuse identical and
>> overlapping memory banks. Can you try the patch I just sent out?
> The patch seems to work, thanks!

You can reply to that patch with a Tested-by: yourname <mail> and Sascha's
scripts will automatically pick it up.

> The only conflict in the debug output is between the "fdt-memreserve-0" and "zero page" regions, but I think that is normal:
> initcall-> of_reserved_mem_walk+0x1/0xfc
> __request_region ok: 0x00000000:0x00000fff flags=0x80000200
> initcall-> mmu_init+0x1/0x60
> __request_region ok: 0x3ffe4000:0x3ffe7fff flags=0x200
> mmu: ttb: 0x3ffe4000
> mmu: Vectors are at 0x3fe00020
> __request_region: 0x00000000:0x00000fff (zero page) conflicts with 0x00000000:0x00000fff (fdt-memreserve-0)
> mmu: Created zero page
> (I defined DEBUG in "arch/arm/cpu/mmu.c" to get the "mmu: Created zero page" log.  Note: the "fdt-memreserve-0" region comes from the "/memreserve/" line in "dts/src/arm/socfpga_cyclone5.dtsi".)

This is good and was one of the motivations behind the series: If the CPUs
are "parked" in the spin table at start of RAM, it should not be possible
to have barebox place a kernel there as it would crash the other CPUs.

Yours is a bit of a special case though, zero page mapping is ok for
a reserved region as barebox turns off the MMU before boot.

But if you look in arch/arm/cpu/mmu.c, you'll see that if the call
to request_sdram_region in create_zero_page() had succeeded, it
would just have been a no-op:

  pr_debug("zero page is in SDRAM area, currently not supported\n");

So no functional change really.


> Thanks again!

Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       |  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

      reply	other threads:[~2022-10-17 14:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-17 12:03 Ian Abbott
2022-10-17 12:24 ` Ahmad Fatoum
2022-10-17 13:10   ` Ian Abbott
2022-10-17 13:31     ` Ian Abbott
2022-10-17 13:41     ` Ahmad Fatoum
2022-10-17 14:32       ` Ian Abbott
2022-10-17 14:45         ` Ahmad Fatoum [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* 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