>Среда, 30 января 2019, 12:35 +03:00 от Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>: >> >> >> 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@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
