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

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

[Ian Abbott]

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

-- 
-=( 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 )=-

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

[Ahmad Fatoum]

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?

Thanks,
Ahmad

> 


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

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

[Ian Abbott]

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

lowlevel init done
SDRAM setup...
SDRAM calibration...
done


barebox 2022.10.0-dirty #31 Mon Oct 17 13:58:34 BST 2022


Board: Terasic DE-0(Atlas)
__request_region ok: 0x00000000:0x3fffffff flags=0x0
__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)
initcall of_probe_memory+0x1/0x34 failed: Device or resource busy
__request_region ok: 0x00000000:0x00000fff flags=0x80000200
__request_region ok: 0x3ffe4000:0x3ffe7fff flags=0x200
__request_region: 0x00000000:0x00000fff (zero page) conflicts with 
0x00000000:0x00000fff (fdt-memreserve-0)
__request_region ok: 0x1fefd960:0x3fdfb2bf flags=0x200
__request_region ok: 0x3fe00000:0x3fe71e0b flags=0x200
__request_region ok: 0x3fe71e0c:0x3fe8272f flags=0x200
__request_region ok: 0x3fe82730:0x3fe85d1f flags=0x200
__request_region ok: 0xffc04000:0xffc04fff flags=0x0
__request_region ok: 0xfffec600:0xfffec6ff flags=0x0
__request_region ok: 0x3ffe8000:0x3ffeffff flags=0x200
__request_region ok: 0xff702000:0xff703fff flags=0x0
socfpga_designware_eth ff702000.ethernet@ff702000.of: user ID: 0x10, 
Synopsys ID: 0x37
mdio_bus: miibus0: probed
__request_region ok: 0xff704000:0xff704fff flags=0x0
dw_mmc ff704000.dwmmc0@ff704000.of: registered as mmc0
__request_region ok: 0xffd02000:0xffd02fff flags=0x0
__request_region ok: 0xff706000:0xff706fff flags=0x0
__request_region ok: 0xffb90000:0xffb90003 flags=0x0
__request_region ok: 0x3fdfb2c0:0x3fdfffc9 flags=0x200
malloc space: 0x1fefd960 -> 0x3fdfb2bf (size 511 MiB)
mmc0: detected SD card version 2.0
mmc0: registered mmc0

Hit any to stop autoboot:    3


-- 
-=( 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 )=-

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

[Ian Abbott]

On 17/10/2022 14: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.)
> 
> [snip]

Here is the same thing with "Trace initcalls" and "Trace driver 
probes/removes" turned on:

lowlevel init done
SDRAM setup...
SDRAM calibration...
done


barebox 2022.10.0-dirty #33 Mon Oct 17 14:26:52 BST 2022


Board: Terasic DE-0(Atlas)
rm_init+0x1/0xc
initcall-> mdio_bus_init+0x1/0xc
initcall-> spi_bus_init+0x1/0xc
initcall-> i2c_bus_init+0x1/0xc
initcall-> gpio_desc_alloc+0x1/0x18
initcall-> fs_bus_init+0x1/0xc
initcall-> socfpga_ccm_driver_register+0x1/0xc
initcall-> syscon_driver_register+0x1/0xc
initcall-> socfpga_init+0x1/0x58
__request_region ok: 0x00000000:0x3fffffff flags=0x0
initcall-> socfpga_boot_save_loc+0x1/0x34
initcall-> of_arm_init+0x1/0x38
     probe-> ffd04000.clkmgr@ffd04000.of
__request_region ok: 0xffd04000:0xffd04fff flags=0x0
initcall-> unwind_init+0x1/0x30
initcall-> register_autoboot_vars+0x1/0x60
initcall-> arm_arch_timer_driver_register+0x1/0xc
initcall-> of_timer_init+0x1/0x14
initcall-> socfpga_reset_driver_register+0x1/0xc
     probe-> ffd05000.rstmgr@ffd05000.of
__request_region ok: 0xffd05000:0xffd05fff flags=0x0
initcall-> net_init+0x1/0x74
initcall-> init_fs+0x1/0x30
initcall-> ns16550_serial_driver_register+0x1/0xc
     probe-> ffc02000.serial0@ffc02000.of
__request_region ok: 0xffc02000:0xffc02fff flags=0x0
     probe-> ffc03000.serial1@ffc03000.of
__request_region ok: 0xffc03000:0xffc03fff flags=0x0
initcall-> socfpga_init+0x1/0x2c
initcall-> dos_partition_init+0x1/0xc
initcall-> of_stdoutpath_init+0x1/0x14
initcall-> of_probe_memory+0x1/0x34
__request_region: 0x00000000:0x3fffffff (ram0) conflicts with 
0x00000000:0x3fffffff (ram0)
initcall of_probe_memory+0x1/0x34 failed: Device or resource busy
initcall-> __exceptions_stop+0x1/0x44
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
__request_region: 0x00000000:0x00000fff (zero page) conflicts with 
0x00000000:0x00000fff (fdt-memreserve-0)
initcall-> mem_malloc_resource+0x1/0x94
__request_region ok: 0x1fefd960:0x3fdfb2bf flags=0x200
__request_region ok: 0x3fe00000:0x3fe71f2b flags=0x200
__request_region ok: 0x3fe71f2c:0x3fe8284f flags=0x200
__request_region ok: 0x3fe82850:0x3fe85e3f flags=0x200
initcall-> bootsource_init+0x1/0x38
initcall-> reset_source_init+0x1/0x40
initcall-> register_mtdoob+0x1/0x14
initcall-> i2c_dw_driver_register+0x1/0xc
     probe-> ffc04000.i2c@ffc04000.of
__request_region ok: 0xffc04000:0xffc04fff flags=0x0
initcall-> clk_gpio_init+0x1/0x10
initcall-> smp_twd_driver_register+0x1/0xc
     probe-> fffec600.timer@fffec600.of
__request_region ok: 0xfffec600:0xfffec6ff flags=0x0
initcall-> mc13xxx_spi_driver_register+0x1/0x20
initcall-> mc13xxx_i2c_driver_register+0x1/0x20
initcall-> ext_init+0x1/0xc
initcall-> ramfs_init+0x1/0xc
initcall-> devfs_init+0x1/0xc
initcall-> ubifs_init+0x1/0x70
initcall-> tftp_init+0x1/0x30
initcall-> nfs_init+0x1/0x34
initcall-> fat_init+0x1/0xc
initcall-> restart_register_feature+0x1/0x1c
initcall-> arm_request_stack+0x1/0x50
__request_region ok: 0x3ffe8000:0x3ffeffff flags=0x200
initcall-> mount_root+0x1/0x58
     probe-> ramfs0
     probe-> devfs0
initcall-> binfmt_sh_init+0x1/0xc
initcall-> binfmt_uimage_init+0x1/0xc
initcall-> console_common_init+0x1/0x54
initcall-> of_kernel_init+0x1/0x1c
initcall-> blspec_init+0x1/0xc
initcall-> console_ctrlc_init+0x1/0x20
initcall-> firmware_init+0x1/0x28
initcall-> genphy_driver_register+0x1/0xc
initcall-> ksphy_driver_register+0x1/0x10
initcall-> socfpga_dwc_ether_driver_register+0x1/0xc
     probe-> ff702000.ethernet@ff702000.of
__request_region ok: 0xff702000:0xff703fff flags=0x0
socfpga_designware_eth ff702000.ethernet@ff702000.of: user ID: 0x10, 
Synopsys ID: 0x37
mdio_bus: miibus0: probed
initcall-> cqspi_driver_register+0x1/0xc
initcall-> dw_mmc_driver_register+0x1/0x10
     probe-> ff704000.dwmmc0@ff704000.of
__request_region ok: 0xff704000:0xff704fff flags=0x0
dw_mmc ff704000.dwmmc0@ff704000.of: registered as mmc0
initcall-> mem_init+0x1/0x60
     probe-> mem0
     probe-> mem1
initcall-> dw_wdt_driver_register+0x1/0xc
     probe-> ffd02000.watchdog@ffd02000.of
__request_region ok: 0xffd02000:0xffd02fff flags=0x0
initcall-> of_partition_init+0x1/0x4c
initcall-> socfpga_fpgamgr_driver_register+0x1/0x10
     probe-> ff706000.fpgamgr@ff706000.of
__request_region ok: 0xff706000:0xff706fff flags=0x0
__request_region ok: 0xffb90000:0xffb90003 flags=0x0
initcall-> prng_init+0x1/0x28
initcall-> null_init+0x1/0x28
initcall-> full_init+0x1/0x28
initcall-> zero_init+0x1/0x28
initcall-> md5_digest_register+0x1/0xc
initcall-> init_net_poll+0x1/0x14
initcall-> barebox_memory_areas_init+0x1/0x2c
__request_region ok: 0x3fdfb2c0:0x3fdfffc9 flags=0x200
initcall-> barebox_of_populate+0x1/0x14
initcall-> of_register_memory_fixup+0x1/0x10
initcall-> dummy_csrc_warn+0x1/0x2c
initcall-> bootm_init+0x1/0x128
initcall-> init_command_list+0x1/0x2c
initcall-> display_meminfo+0x1/0x34
malloc space: 0x1fefd960 -> 0x3fdfb2bf (size 511 MiB)
initcall-> of_register_bootargs_fixup+0x1/0x2c
initcall-> init_boot+0x1/0x74
initcall-> device_probe_deferred+0x1/0xc0
initcall-> of_init_hostname+0x1/0x18
initcall-> barebox_of_driver_init+0x1/0x44
     probe-> chosen:environment.of
mmc0: detected SD card version 2.0
mmc0: registered mmc0
         probe-> fat0
initcall-> eth_register_of_fixup+0x1/0x10
initcall-> dhcp_global_init+0x1/0xf8
initcall-> ifup_all_init+0x1/0x20
initcall-> ubifs_init+0x1/0x48
initcall-> armlinux_register_image_handler+0x1/0x74
initcall-> load_environment+0x1/0x2c
initcall-> of_populate_ethaddr+0x1/0x90
initcalls done
^[[?25hExecuting '/env/init/automount'...
Executing '/env/init/automount-ratp'...
Executing '/env/init/ps1'...

Hit any to stop autoboot:    3


-- 
-=( 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 )=-

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

[Ahmad Fatoum]

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?

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

Thanks!
Ahmad

> initcall of_probe_memory+0x1/0x34 failed: Device or resource busy
> __request_region ok: 0x00000000:0x00000fff flags=0x80000200
> __request_region ok: 0x3ffe4000:0x3ffe7fff flags=0x200
> __request_region: 0x00000000:0x00000fff (zero page) conflicts with 0x00000000:0x00000fff (fdt-memreserve-0)
> __request_region ok: 0x1fefd960:0x3fdfb2bf flags=0x200
> __request_region ok: 0x3fe00000:0x3fe71e0b flags=0x200
> __request_region ok: 0x3fe71e0c:0x3fe8272f flags=0x200
> __request_region ok: 0x3fe82730:0x3fe85d1f flags=0x200
> __request_region ok: 0xffc04000:0xffc04fff flags=0x0
> __request_region ok: 0xfffec600:0xfffec6ff flags=0x0
> __request_region ok: 0x3ffe8000:0x3ffeffff flags=0x200
> __request_region ok: 0xff702000:0xff703fff flags=0x0
> socfpga_designware_eth ff702000.ethernet@ff702000.of: user ID: 0x10, Synopsys ID: 0x37
> mdio_bus: miibus0: probed
> __request_region ok: 0xff704000:0xff704fff flags=0x0
> dw_mmc ff704000.dwmmc0@ff704000.of: registered as mmc0
> __request_region ok: 0xffd02000:0xffd02fff flags=0x0
> __request_region ok: 0xff706000:0xff706fff flags=0x0
> __request_region ok: 0xffb90000:0xffb90003 flags=0x0
> __request_region ok: 0x3fdfb2c0:0x3fdfffc9 flags=0x200
> malloc space: 0x1fefd960 -> 0x3fdfb2bf (size 511 MiB)
> mmc0: detected SD card version 2.0
> mmc0: registered mmc0
> 
> Hit any to stop autoboot:    3
> 
> 


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

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

[Ian Abbott]

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

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

[Ahmad Fatoum]

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 |