initrd problem

initrd problem

[Alexander Shiyan]

Hello.

I successfully use the barebox with custom board based on CC-i.MX51 module.
I am using 30MB UBI volume as initrd for root filesystem. This configuration is
works fine for me.

I decided to change the size of the UBI volume for the root file system to 60 MB.
Now I get a weird OOM error. Turning on debug information shows a conflict,
but I do not quite understand where to look for the problem.
Where is the starting point to try to solve this problem?


barebox 2018.12.0-00337-g5ff5b7b05-dirty #11 Thu Jan 24 12:17:32 MSK 2019

Board: Mega-Milas Informer i.MX51
__request_region ok: 0x73fa8000:0x73fabfff
__request_region ok: 0x73fd4000:0x73fd7fff
__request_region ok: 0x73fa0000:0x73fa3fff
__request_region ok: 0x73f84000:0x73f87fff
__request_region ok: 0x73f88000:0x73f8bfff
__request_region ok: 0x73f8c000:0x73f8ffff
__request_region ok: 0x73f90000:0x73f93fff
__request_region ok: 0x90000000:0x97ffffff
detected i.MX51 revision 3.0
i.MX reset reason POR (SRSR: 0x00000001)
__request_region ok: 0x73fd0000:0x73fd3fff
__request_region ok: 0x7000c000:0x7000ffff
__request_region ok: 0x73fbc000:0x73fbffff
__request_region ok: 0x73fc0000:0x73fc3fff
__request_region ok: 0x83fd9000:0x83fd9fff
__request_region ok: 0x97fe4000:0x97fe7fff
__request_region: 0x00000000:0x00000fff outside parent resource 0x90000000:0x97ffffff
__request_region ok: 0x95df8d40:0x97df8d3f
__request_region ok: 0x97e00000:0x97e6e517
__request_region ok: 0x97e6e518:0x97e86707
__request_region ok: 0x97e86708:0x97e897df
__request_region ok: 0x73f80800:0x73f809ff
__request_region ok: 0x70010000:0x70013fff
__request_region ok: 0x83fac000:0x83faffff
__request_region ok: 0x83fc4000:0x83fc7fff
mc13xxx-spi mc13892@00: Found MC13892 ID: 0x0045d0 [Rev: 2.0a]
__request_region ok: 0x73fb4000:0x73fb7fff
__request_region ok: 0x73fb8000:0x73fbbfff
__request_region ok: 0x83f98000:0x83f9bfff
__request_region ok: 0x97fe8000:0x97feffff
Module Variant: i.MX515@600MHz, PHY, Accel (0x0b)
Module HW Rev : 03
Module Serial : W115171467
__request_region ok: 0x98000000:0x9fffffff
MC13892 PMIC initialized.
__request_region ok: 0x83fdb000:0x83fdbfff
__request_region ok: 0xcfff0000:0xcfffffff
nand: ONFI flash detected
nand: NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron MT29F2G08ABAEAWP), 256MiB, page size: 2048, OOB size: 64
Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01
__request_region ok: 0x73f80000:0x73f801ff
imx-usb 73f80000.usb@73f80000: USB EHCI 1.00
__request_region ok: 0x73f80200:0x73f803ff
imx-usb 73f80200.usb@73f80200: USB EHCI 1.00
__request_region ok: 0x70004000:0x70007fff
imx-esdhc 70004000.esdhc@70004000: registered as mmc0
__request_region ok: 0x70008000:0x7000bfff
ERROR: mmc1: Failed to get 'vmmc' regulator.
imx-esdhc 70008000.esdhc@70008000: registered as mmc1
__request_region ok: 0x40000000:0x5fffffff
imx-ipuv3 40000000.ipu@40000000: IPUv3EX probed
__request_region ok: 0x1ffe0000:0x1fffffff
__request_region ok: 0x73f98000:0x73f9bfff
__request_region ok: 0x83fda000:0x83fdafff
imx-weim 83fda000.weim@83fda000: WEIM driver registered.
__request_region ok: 0x97df8d40:0x97dfffde
malloc space: 0x95df8d40 -> 0x97df8d3f (size 32 MiB)
envfs: no envfs (magic mismatch) - envfs never written?
running /env/bin/init...
imx-ipuv3-crtc imx-ipuv3-crtc0: ipu_crtc_mode_set: mode->xres: 320
imx-ipuv3-crtc imx-ipuv3-crtc0: ipu_crtc_mode_set: mode->yres: 240
i2c_write: I/O error
i2c_write: I/O error
NOTICE: ubi0: scanning is finished
NOTICE: ubi0: registering /dev/nand0.system.ubi
NOTICE: ubi0: registering kernel as /dev/nand0.system.ubi.kernel
NOTICE: ubi0: registering root as /dev/nand0.system.ubi.root
NOTICE: ubi0: registering bbox as /dev/nand0.system.ubi.bbox
NOTICE: ubi0: attached mtd0 (name "nand0.system", size 255 MiB) to ubi0
NOTICE: ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
NOTICE: ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
NOTICE: ubi0: VID header offset: 512 (aligned 512), data offset: 2048
NOTICE: ubi0: good PEBs: 2040, bad PEBs: 2, corrupted PEBs: 0
NOTICE: ubi0: user volume: 3, internal volumes: 1, max. volumes count: 128
NOTICE: ubi0: max/mean erase counter: 30/16, WL threshold: 4096, image sequence number: 23290
NOTICE: ubi0: available PEBs: 0, total reserved PEBs: 2040, PEBs reserved for bad PEB handling: 38

Hit any key to stop autoboot:    2   1   0
booting 'nand'

Loading ARM Linux zImage '/dev/nand0.system.ubi.kernel'
__request_region ok: 0x92000000:0x922a244f
1 0xffffffff
2 0x923a3000
__request_region ok: 0x923a3000:0x923c2fff
__request_region ok: 0x923a3000:0x923e2fff
__request_region ok: 0x923a3000:0x92402fff
...
__request_region ok: 0x923a3000:0x95da2fff
__request_region ok: 0x923a3000:0x95dc2fff
__request_region ok: 0x923a3000:0x95de2fff
__request_region: 0x923a3000:0x95e02fff conflicts with 0x95df8d40:0x97df8d3f
__request_region: 0x923a3000:0x95e02fff outside parent resource 0x98000000:0x9fffffff
unable to request SDRAM 0x923a3000-0x95e02fff
ERROR: Booting 'nand' failed: Out of memory
booting 'nand' failed: Out of memory
boot: Out of memory
barebox@Mega-Milas Informer i.MX51:/


---
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: initrd problem

[Sascha Hauer]

Hi Alexander,

Sorry for the delay. Has this been resolved in the meantime?

On Thu, Jan 24, 2019 at 12:37:29PM +0300, Alexander Shiyan wrote:
> I decided to change the size of the UBI volume for the root file system to 60 MB.
> Now I get a weird OOM error. Turning on debug information shows a conflict,
> but I do not quite understand where to look for the problem.
> Where is the starting point to try to solve this problem?
> 
> 
> malloc space: 0x95df8d40 -> 0x97df8d3f (size 32 MiB)
> 
> Loading ARM Linux zImage '/dev/nand0.system.ubi.kernel'
> __request_region ok: 0x92000000:0x922a244f

The Kernel documentation recommends putting the Kernel 32MiB into SDRAM
to avoid relocation. This is what we see here.

> __request_region: 0x923a3000:0x95e02fff conflicts with 0x95df8d40:0x97df8d3f

Now we try allocate space for the initrd above it which is 60MiB. This
conflicts with the malloc space.

So yes, you're out of memory.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: initrd problem

[Alexander Shiyan]

Hello.

>Среда, 30 января 2019, 9:08 +03:00 от Sascha Hauer <s.hauer@pengutronix.de>:
>Sorry for the delay. Has this been resolved in the meantime?

Still no.

>On Thu, Jan 24, 2019 at 12:37:29PM +0300, Alexander Shiyan wrote:
>> I decided to change the size of the UBI volume for the root file system to 60 MB.
>> Now I get a weird OOM error. Turning on debug information shows a conflict,
>> but I do not quite understand where to look for the problem.
>> Where is the starting point to try to solve this problem?
>> 
>> malloc space: 0x95df8d40 -> 0x97df8d3f (size 32 MiB)
>> 
>> Loading ARM Linux zImage '/dev/nand0.system.ubi.kernel'
>> __request_region ok: 0x92000000:0x922a244f
>The Kernel documentation recommends putting the Kernel 32MiB into SDRAM
>to avoid relocation. This is what we see here.
>
>> __request_region: 0x923a3000:0x95e02fff conflicts with 0x95df8d40:0x97df8d3f
>
>Now we try allocate space for the initrd above it which is 60MiB. This
>conflicts with the malloc space.
>
>So yes, you're out of memory.
Memory should be enough (256 Mb). I think the problem is that the memory is
divided into two banks of 128 Mb each.

Just look for a next line:
__request_region: 0x923a3000:0x95e02fff outside parent resource 0x98000000:0x9fffffff

Maybe we need some kind of option to merge nearby banks?

---
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: initrd problem

[Alexander Shiyan]

>>On Thu, Jan 24, 2019 at 12:37:29PM +0300, Alexander Shiyan wrote:
>>> I decided to change the size of the UBI volume for the root file system to 60 MB.
>>> Now I get a weird OOM error. Turning on debug information shows a conflict,
>>> but I do not quite understand where to look for the problem.
>>> Where is the starting point to try to solve this problem?
>>> 
>>> malloc space: 0x95df8d40 -> 0x97df8d3f (size 32 MiB)
>>> 
>>> Loading ARM Linux zImage '/dev/nand0.system.ubi.kernel'
>>> __request_region ok: 0x92000000:0x922a244f
>>The Kernel documentation recommends putting the Kernel 32MiB into SDRAM
>>to avoid relocation. This is what we see here.
>>
>>> __request_region: 0x923a3000:0x95e02fff conflicts with 0x95df8d40:0x97df8d3f
>>
>>Now we try allocate space for the initrd above it which is 60MiB. This
>>conflicts with the malloc space.
>>
>>So yes, you're out of memory.
>Memory should be enough (256 Mb). I think the problem is that the memory is
>divided into two banks of 128 Mb each.
>
>Just look for a next line:
>__request_region: 0x923a3000:0x95e02fff outside parent resource 0x98000000:0x9fffffff
>
>Maybe we need some kind of option to merge nearby banks?

Problem is resolved by adding:
global.bootm.initrd.loadaddr=0x98000000

...But I do not really like this method.

---
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: initrd problem

[Sascha Hauer]

On Wed, Jan 30, 2019 at 11:03:02AM +0300, Alexander Shiyan wrote:
> Hello.
> 
> >Среда, 30 января 2019, 9:08 +03:00 от Sascha Hauer <s.hauer@pengutronix.de>:
> >Sorry for the delay. Has this been resolved in the meantime?
> 
> Still no.
> 
> >On Thu, Jan 24, 2019 at 12:37:29PM +0300, Alexander Shiyan wrote:
> >> I decided to change the size of the UBI volume for the root file system to 60 MB.
> >> Now I get a weird OOM error. Turning on debug information shows a conflict,
> >> but I do not quite understand where to look for the problem.
> >> Where is the starting point to try to solve this problem?
> >> 
> >> malloc space: 0x95df8d40 -> 0x97df8d3f (size 32 MiB)
> >> 
> >> Loading ARM Linux zImage '/dev/nand0.system.ubi.kernel'
> >> __request_region ok: 0x92000000:0x922a244f
> >The Kernel documentation recommends putting the Kernel 32MiB into SDRAM
> >to avoid relocation. This is what we see here.
> >
> >> __request_region: 0x923a3000:0x95e02fff conflicts with 0x95df8d40:0x97df8d3f
> >
> >Now we try allocate space for the initrd above it which is 60MiB. This
> >conflicts with the malloc space.
> >
> >So yes, you're out of memory.
> Memory should be enough (256 Mb). I think the problem is that the memory is
> divided into two banks of 128 Mb each.
> 
> Just look for a next line:
> __request_region: 0x923a3000:0x95e02fff outside parent resource 0x98000000:0x9fffffff
> 
> Maybe we need some kind of option to merge nearby banks?

If I'm not mistaken the banks are not really nearby. You should have two
banks, one from 0x90000000 to 0x97ffffff and one from 0xa0000000 to
0xa7ffffff.
I don't know where the resource 0x98000000:0x9fffffff comes from. Could
you paste the output of the iomem command? Are you using the code from
arch/arm/mach-imx/esdctl.c or are you bypassing it?

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: initrd problem

[Alexander Shiyan]

>> >On Thu, Jan 24, 2019 at 12:37:29PM +0300, Alexander Shiyan wrote:
>> >> I decided to change the size of the UBI volume for the root file system to 60 MB.
>> >> Now I get a weird OOM error. Turning on debug information shows a conflict,
>> >> but I do not quite understand where to look for the problem.
>> >> Where is the starting point to try to solve this problem?
>> >> 
>> >> malloc space: 0x95df8d40 -> 0x97df8d3f (size 32 MiB)
>> >> 
>> >> Loading ARM Linux zImage '/dev/nand0.system.ubi.kernel'
>> >> __request_region ok: 0x92000000:0x922a244f
>> >The Kernel documentation recommends putting the Kernel 32MiB into SDRAM
>> >to avoid relocation. This is what we see here.
>> >
>> >> __request_region: 0x923a3000:0x95e02fff conflicts with 0x95df8d40:0x97df8d3f
>> >
>> >Now we try allocate space for the initrd above it which is 60MiB. This
>> >conflicts with the malloc space.
>> >
>> >So yes, you're out of memory.
>> Memory should be enough (256 Mb). I think the problem is that the memory is
>> divided into two banks of 128 Mb each.
>> 
>> Just look for a next line:
>> __request_region: 0x923a3000:0x95e02fff outside parent resource 0x98000000:0x9fffffff
>> 
>> Maybe we need some kind of option to merge nearby banks?
>
>If I'm not mistaken the banks are not really nearby. You should have two
>banks, one from 0x90000000 to 0x97ffffff and one from 0xa0000000 to
>0xa7ffffff.
>I don't know where the resource 0x98000000:0x9fffffff comes from. Could
>you paste the output of the iomem command? Are you using the code from
>arch/arm/mach-imx/esdctl.c or are you bypassing it?

It is not an error. CCMX51 not using ESDCTL.
The first bank is minimal size 128M. The second is a chain to first, its size
depends on module variant.

barebox@Mega-Milas Informer i.MX51:/ iomem
0x00000000 - 0xffffffff (size 0x00000000) iomem
  0x1ffe0000 - 0x1fffffff (size 0x00020000) 1ffe0000.iram@1ffe0000
  0x40000000 - 0x5fffffff (size 0x20000000) 40000000.ipu@40000000
  0x70004000 - 0x70007fff (size 0x00004000) 70004000.esdhc@70004000
  0x70008000 - 0x7000bfff (size 0x00004000) 70008000.esdhc@70008000
  0x7000c000 - 0x7000ffff (size 0x00004000) 7000c000.serial@7000c000
  0x70010000 - 0x70013fff (size 0x00004000) 70010000.spi@70010000
  0x73f80000 - 0x73f801ff (size 0x00000200) 73f80000.usb@73f80000
  0x73f80200 - 0x73f803ff (size 0x00000200) 73f80200.usb@73f80200
  0x73f80800 - 0x73f809ff (size 0x00000200) 73f80800.usbmisc@73f80800
  0x73f84000 - 0x73f87fff (size 0x00004000) 73f84000.gpio@73f84000
  0x73f88000 - 0x73f8bfff (size 0x00004000) 73f88000.gpio@73f88000
  0x73f8c000 - 0x73f8ffff (size 0x00004000) 73f8c000.gpio@73f8c000
  0x73f90000 - 0x73f93fff (size 0x00004000) 73f90000.gpio@73f90000
  0x73f98000 - 0x73f9bfff (size 0x00004000) 73f98000.wdog@73f98000
  0x73fa0000 - 0x73fa3fff (size 0x00004000) 73fa0000.timer@73fa0000
  0x73fa8000 - 0x73fabfff (size 0x00004000) 73fa8000.iomuxc@73fa8000
  0x73fb4000 - 0x73fb7fff (size 0x00004000) 73fb4000.pwm@73fb4000
  0x73fb8000 - 0x73fbbfff (size 0x00004000) 73fb8000.pwm@73fb8000
  0x73fbc000 - 0x73fbffff (size 0x00004000) 73fbc000.serial@73fbc000
  0x73fc0000 - 0x73fc3fff (size 0x00004000) 73fc0000.serial@73fc0000
  0x73fd0000 - 0x73fd3fff (size 0x00004000) 73fd0000.src@73fd0000
  0x73fd4000 - 0x73fd7fff (size 0x00004000) 73fd4000.ccm@73fd4000
  0x83f98000 - 0x83f9bfff (size 0x00004000) 83f98000.iim@83f98000
  0x83fac000 - 0x83faffff (size 0x00004000) 83fac000.spi@83fac000
  0x83fc4000 - 0x83fc7fff (size 0x00004000) 83fc4000.i2c@83fc4000
  0x83fd9000 - 0x83fd9fff (size 0x00001000) imx51-esdctl0
  0x83fda000 - 0x83fdafff (size 0x00001000) 83fda000.weim@83fda000
  0x83fdb000 - 0x83fdbfff (size 0x00001000) 83fdb000.nand@83fdb000
  0x90000000 - 0x97ffffff (size 0x08000000) ram0
    0x95df8d40 - 0x97df8d3f (size 0x02000000) malloc space
    0x97df8d40 - 0x97dfffde (size 0x0000729f) board data
    0x97e00000 - 0x97e6e537 (size 0x0006e538) barebox
    0x97e6e538 - 0x97e86727 (size 0x000181f0) barebox data
    0x97e86728 - 0x97e897ff (size 0x000030d8) bss
    0x97fe4000 - 0x97fe7fff (size 0x00004000) ttb
    0x97fe8000 - 0x97feffff (size 0x00008000) stack
  0x98000000 - 0x9fffffff (size 0x08000000) ram1
  0xcfff0000 - 0xcfffffff (size 0x00010000) 83fdb000.nand@83fdb000

---
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: initrd problem

[Sascha Hauer]

On Wed, Jan 30, 2019 at 12:20:38PM +0300, Alexander Shiyan wrote:
> >> >On Thu, Jan 24, 2019 at 12:37:29PM +0300, Alexander Shiyan wrote:
> >> >> I decided to change the size of the UBI volume for the root file system to 60 MB.
> >> >> Now I get a weird OOM error. Turning on debug information shows a conflict,
> >> >> but I do not quite understand where to look for the problem.
> >> >> Where is the starting point to try to solve this problem?
> >> >> 
> >> >> malloc space: 0x95df8d40 -> 0x97df8d3f (size 32 MiB)
> >> >> 
> >> >> Loading ARM Linux zImage '/dev/nand0.system.ubi.kernel'
> >> >> __request_region ok: 0x92000000:0x922a244f
> >> >The Kernel documentation recommends putting the Kernel 32MiB into SDRAM
> >> >to avoid relocation. This is what we see here.
> >> >
> >> >> __request_region: 0x923a3000:0x95e02fff conflicts with 0x95df8d40:0x97df8d3f
> >> >
> >> >Now we try allocate space for the initrd above it which is 60MiB. This
> >> >conflicts with the malloc space.
> >> >
> >> >So yes, you're out of memory.
> >> Memory should be enough (256 Mb). I think the problem is that the memory is
> >> divided into two banks of 128 Mb each.
> >> 
> >> Just look for a next line:
> >> __request_region: 0x923a3000:0x95e02fff outside parent resource 0x98000000:0x9fffffff
> >> 
> >> Maybe we need some kind of option to merge nearby banks?
> >
> >If I'm not mistaken the banks are not really nearby. You should have two
> >banks, one from 0x90000000 to 0x97ffffff and one from 0xa0000000 to
> >0xa7ffffff.
> >I don't know where the resource 0x98000000:0x9fffffff comes from. Could
> >you paste the output of the iomem command? Are you using the code from
> >arch/arm/mach-imx/esdctl.c or are you bypassing it?
> 
> It is not an error. CCMX51 not using ESDCTL.
> The first bank is minimal size 128M. The second is a chain to first, its size
> depends on module variant.

I see. Similar to what is done in arch/arm/boards/ccxmx51/ccxmx51.c,
right?

In that case merging the two banks won't give you much since barebox
will already be placed in the middle of the available RAM.

Can't you shuffle the code so that you can detect the board variant and
thus the amount of SDRAM before even calling barebox_arm_entry? You
would need some early variant of imx_iim_read(), but in the end this
goes down to a register read, so shouldn't be hard to implement.
Then you could drop the splitting into separate SDRAM regions entirely.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: initrd problem

[Alexander Shiyan]

>Среда, 30 января 2019, 12:35 +03:00 от Sascha Hauer <s.hauer@pengutronix.de>:
>> >> >> I decided to change the size of the UBI volume for the root file system to 60 MB.
>> >> >> Now I get a weird OOM error. Turning on debug information shows a conflict,
>> >> >> but I do not quite understand where to look for the problem.
>> >> >> Where is the starting point to try to solve this problem?
>> >> >> 
>> >> >> malloc space: 0x95df8d40 -> 0x97df8d3f (size 32 MiB)
>> >> >> 
>> >> >> Loading ARM Linux zImage '/dev/nand0.system.ubi.kernel'
>> >> >> __request_region ok: 0x92000000:0x922a244f
>> >> >The Kernel documentation recommends putting the Kernel 32MiB into SDRAM
>> >> >to avoid relocation. This is what we see here.
>> >> >
>> >> >> __request_region: 0x923a3000:0x95e02fff conflicts with 0x95df8d40:0x97df8d3f
>> >> >
>> >> >Now we try allocate space for the initrd above it which is 60MiB. This
>> >> >conflicts with the malloc space.
>> >> >
>> >> >So yes, you're out of memory.
>> >> Memory should be enough (256 Mb). I think the problem is that the memory is
>> >> divided into two banks of 128 Mb each.
>> >> 
>> >> Just look for a next line:
>> >> __request_region: 0x923a3000:0x95e02fff outside parent resource 0x98000000:0x9fffffff
>> >> 
>> >> Maybe we need some kind of option to merge nearby banks?
>> >
>> >If I'm not mistaken the banks are not really nearby. You should have two
>> >banks, one from 0x90000000 to 0x97ffffff and one from 0xa0000000 to
>> >0xa7ffffff.
>> >I don't know where the resource 0x98000000:0x9fffffff comes from. Could
>> >you paste the output of the iomem command? Are you using the code from
>> >arch/arm/mach-imx/esdctl.c or are you bypassing it?
>> 
>> It is not an error. CCMX51 not using ESDCTL.
>> The first bank is minimal size 128M. The second is a chain to first, its size
>> depends on module variant.
>
>I see. Similar to what is done in arch/arm/boards/ccxmx51/ccxmx51.c,
>right?
>
>In that case merging the two banks won't give you much since barebox
>will already be placed in the middle of the available RAM.
>
>Can't you shuffle the code so that you can detect the board variant and
>thus the amount of SDRAM before even calling barebox_arm_entry? You
>would need some early variant of imx_iim_read(), but in the end this
>goes down to a register read, so shouldn't be hard to implement.
>Then you could drop the splitting into separate SDRAM regions entirely.

At the moment I have used an alternative method to solve this problem.
I have reduced MALLOC_SIZE to 16 Mb and as a result, the 60 Mb initd
loaded fine for boards with 128 MB RAM.

---
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox