On Wed, Mar 25, 2020 at 10:58 AM Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> wrote: > > On Tue, Mar 24, 2020 at 05:21:16PM +0100, Yegor Yefremov wrote: > > On Tue, Mar 24, 2020 at 8:35 AM Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> wrote: > > > > > > On Mon, Mar 23, 2020 at 01:22:33PM +0100, Yegor Yefremov wrote: > > > > Hi Sascha, > > > > > > > > On Mon, Mar 23, 2020 at 9:30 AM Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> wrote: > > > > > > > > > > Hi Yegor, > > > > > > > > > > On Fri, Mar 20, 2020 at 09:29:04AM +0100, Yegor Yefremov wrote: > > > > > > I get an "handler failed with: Out of memory" message when trying to > > > > > > load my 22MB large kernel-fit.itb. Below you can see the related log: > > > > > > > > > > > > mounted /dev/nand0.UBI.ubi.kernel on /mnt/nand0.UBI.ubi.kernel > > > > > > YY: bootm_boot > > > > > > YY: read file 0, size 22661672, PAGE_SIZE 4096 > > > > > > YY: fit_open > > > > > > FIT: Opened FIT image: Simple image with single Linux kernel and FDT blob > > > > > > FIT: configuration 'conf221@1': Boot Linux kernel with FDT blob (221) > > > > > > FIT: image 'kernel@1': 'Vanilla Linux kernel' > > > > > > FIT: /images/kernel@1/hash@1: hash OK > > > > > > > > > > > > Loading open firmware Device Tree flattened Binary > > > > > > '/mnt/nand0.UBI.ubi.kernel/kernel-fit.itb' > > > > > > OS image not yet relocated > > > > > > Passing control to FIT image handler > > > > > > YY: do_bootm_linux > > > > > > YY: before bootm_load_os > > > > > > YY: bootm_load_os > > > > > > YY: kernel size 22484352 > > > > > > YY: for each memory bank: size 22484352 > > > > > > __request_region: 0x86b37000:0x880a857f conflicts with 0x87efe860:0x8fdfd0bf > > > > > > > > > > So your kernel has a size of 22484352 bytes. We want to places the > > > > > kernel at a place where we do not risk that it overwrites itself during > > > > > decompression. We assume that the kernel gets five times bigger during > > > > > decompression. So we put it at 0x80000000 + 22484352 * 5. Here the image > > > > > takes 22484352 bytes, so ends at 0x80000000 + 22484352 * (5 + 1) which > > > > > is already inside the malloc area. > > > > > > > > > > Try the attached patch, it should solve that issue. > > > > > > > > No, it doesn't. But reducing the malloc size helped. I have tried the > > > > reduced size with and without the fix. > > > > > > Nevertheless I would still be interested why the patch doesn't work. > > > Care to have a look? Some printfs of the addresses would be enough to > > > give me a clue. > > > > Loading open firmware Device Tree flattened Binary > > '/mnt/nand0.UBI.ubi.kernel/kernel-fit.itb' > > YY: mem_start 80000000, mem_size 133163104 > > YY: image_decomp_size 112422912 > > YY: mem_end 87efe85f > > YY: kaddr initial 86b37000 > > YY: kaddr final 8688d2df > > YY: load_address 8688d000 > > YY: mem_free 87eff000 > > FIT: image 'fdt220@1': 'Flattened Device Tree blob (220)' > > FIT: /images/fdt220@1/hash@1: hash OK > > handler failed with: Out of memory > > > > I hope this helps. > > Yes, that helps, thanks. It seems the kernel now fits into the available > memory, but now there's no space left above the kernel to place the > device tree, at least that's what I assume. So the solution with reduced malloc size still holds. While we are at it, could you add CONFIG_MALLOC_SIZE and other config options in the related Kconfig? Thanks. Yegor _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
