Re: initrd problem

["Alexander Shiyan" <shc_work@mail.ru>]

>Среда, 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