From: Yegor Yefremov <yegorslists@googlemail.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: barebox <barebox@lists.infradead.org>, Lucas Stach <lst@pengutronix.de>
Subject: Re: am335x: load a kernel with integrated initramfs
Date: Mon, 23 Mar 2020 13:22:33 +0100 [thread overview]
Message-ID: <CAGm1_kvEGeMhGMr32AMZapL52L7Ks0-zdRs4=p4Rj=JgOS6Y=Q@mail.gmail.com> (raw)
In-Reply-To: <20200323083012.GP3335@pengutronix.de>
Hi Sascha,
On Mon, Mar 23, 2020 at 9:30 AM Sascha Hauer <s.hauer@pengutronix.de> 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.
Yegor
> Besides this obvious bug you can also adjust the sime of the malloc
> area. By default roughly half of the available RAM is used for malloc,
> but in Kconfig you can adjust it to a smaller size which gives you more
> place for the kernel.
>
> Sascha
>
> --------------------------------------8<-------------------------------
>
> From ca440da09c3cdb83e17a6f0a99f24f69300c0ba3 Mon Sep 17 00:00:00 2001
> From: Sascha Hauer <s.hauer@pengutronix.de>
> Date: Mon, 23 Mar 2020 09:17:36 +0100
> Subject: [PATCH] ARM: bootm: make sure we place the kernel in free memory
>
> When placing the kernel image in memory make sure we do not
> place it too high, outside of the available memory, outside of the
> available memory.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> arch/arm/lib32/bootm.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/lib32/bootm.c b/arch/arm/lib32/bootm.c
> index d64e705c40..971ebee8ac 100644
> --- a/arch/arm/lib32/bootm.c
> +++ b/arch/arm/lib32/bootm.c
> @@ -104,11 +104,24 @@ static int get_kernel_addresses(size_t image_size,
> spacing = SZ_1M;
>
> if (*load_address == UIMAGE_INVALID_ADDRESS) {
> + unsigned long mem_end = mem_start + mem_size - 1;
> + unsigned long kaddr;
> +
> /*
> * Place the kernel at an address where it does not need to
> * relocate itself before decompression.
> */
> - *load_address = mem_start + image_decomp_size;
> + kaddr = mem_start + image_decomp_size;
> +
> + /*
> + * Make sure we do not place the image past the end of the
> + * available memory.
> + */
> + if (kaddr + image_size + spacing >= mem_end)
> + kaddr = mem_end - image_size - spacing;
> +
> + *load_address = PAGE_ALIGN_DOWN(kaddr);
> +
> if (verbose)
> printf("no OS load address, defaulting to 0x%08lx\n",
> *load_address);
> --
> 2.25.1
>
>
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 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
next prev parent reply other threads:[~2020-03-23 12:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-20 8:29 Yegor Yefremov
2020-03-23 8:30 ` Sascha Hauer
2020-03-23 12:22 ` Yegor Yefremov [this message]
2020-03-24 7:35 ` Sascha Hauer
2020-03-24 16:21 ` Yegor Yefremov
2020-03-25 9:58 ` Sascha Hauer
2020-03-25 15:35 ` Yegor Yefremov
2020-03-25 15:36 ` Yegor Yefremov
2020-04-08 17:17 ` Yegor Yefremov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGm1_kvEGeMhGMr32AMZapL52L7Ks0-zdRs4=p4Rj=JgOS6Y=Q@mail.gmail.com' \
--to=yegorslists@googlemail.com \
--cc=barebox@lists.infradead.org \
--cc=lst@pengutronix.de \
--cc=s.hauer@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox