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@xxxxxxxxx> || 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 )=-
