From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-ua1-x943.google.com ([2607:f8b0:4864:20::943]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jH84X-0006My-ET for barebox@lists.infradead.org; Wed, 25 Mar 2020 15:36:03 +0000 Received: by mail-ua1-x943.google.com with SMTP id v24so902032uak.0 for ; Wed, 25 Mar 2020 08:36:00 -0700 (PDT) MIME-Version: 1.0 References: <20200323083012.GP3335@pengutronix.de> <20200324073557.GS3335@pengutronix.de> <20200325095803.GD27288@pengutronix.de> In-Reply-To: <20200325095803.GD27288@pengutronix.de> From: Yegor Yefremov Date: Wed, 25 Mar 2020 16:35:47 +0100 Message-ID: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "barebox" Errors-To: barebox-bounces+u.kleine-koenig=pengutronix.de@lists.infradead.org Subject: Re: am335x: load a kernel with integrated initramfs To: Sascha Hauer Cc: barebox , Lucas Stach On Wed, Mar 25, 2020 at 10:58 AM Sascha Hauer 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 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 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@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox