Re: [v2022.10.0] initcall of of_probe_memory failed (EBUSY)

[Ahmad Fatoum <a.fatoum@pengutronix.de>]

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.

Cheers,
Ahmad

> 
> Thanks again!
> 


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