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

[Ian Abbott <abbotti@mev.co.uk>]

On 17/10/2022 14:41, Ahmad Fatoum wrote:
> Hello Ian,
> 
> On 17.10.22 15:10, Ian Abbott wrote:
>> On 17/10/2022 13:24, Ahmad Fatoum wrote:
>>> On 17.10.22 14:03, Ian Abbott wrote:
>>>> Barebox v2022.10.0 seems to work for me, but I now get this (harmless?) error during initialization:
>>>>
>>>> initcall of_probe_memory+0x1/0x34 failed: Device or resource busy
>>>>
>>>> (This is on a 32-bit ARM SoCFPGA/CycloneV based system.)
>>>>
>>>> git bisect is blaming commit d0b5f6bde15b ("of: reserved-mem: reserve regions prior to mmu_initcall()").
>>>
>>> Can you define #define DEBUG at the top of common/resource.c and paste
>>> the output?
>>
>> Here is what I get for a Terasic DE0-Nano-SoC.  (I was using a custom board for the original report, but the symptoms are the same.)
> 
> Thanks for the debug output.
> 
>> Board: Terasic DE-0(Atlas)
>> __request_region ok: 0x00000000:0x3fffffff flags=0x0
> 
> Here socfpga_detect_sdram() will register ram0 after reading it
> from hardware.
> 
>> __request_region ok: 0xffd04000:0xffd04fff flags=0x0
>> __request_region ok: 0xffd05000:0xffd05fff flags=0x0
>> __request_region ok: 0xffc02000:0xffc02fff flags=0x0
>> __request_region ok: 0xffc03000:0xffc03fff flags=0x0
>> __request_region: 0x00000000:0x3fffffff (ram0) conflicts with 0x00000000:0x3fffffff (ram0)
> 
> And then when device-tree is parsed, of_probe_memory()
> will register the same memory bank again. The error reports this unexpected
> situation, but as you noted should not break the boot.
> 
> 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.

> 
> 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!

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".)

Thanks again!

-- 
-=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company  )=-
-=( registered in England & Wales.  Regd. number: 02862268.  )=-
-=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=-
-=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-