Re: [PATCH 2/3] ARM: i.MX: Add max_load_size option to boards that will need it

[Andrey Smirnov <andrew.smirnov@gmail.com>]

On Thu, Nov 29, 2018 at 11:36 PM Sascha Hauer <s.hauer@pengutronix.de> wrote:
>
> Hi Andrey,
>
> On Thu, Nov 29, 2018 at 10:11:47PM -0800, Andrey Smirnov wrote:
> >
> > The change above bricks Barebox on RDU2 because load size of 0x11000
> > isn't enough. Tracing what hdr->boot_data.size was set to prior to
> > this series ends up with 0x1d000 as a number, using which appears to
> > fix the problem on the real board, so we probably should max_load_size
> > to at least that much. I am hoping you can fix it on your end, but let
> > me know if you need me to generate a fixup patch.
>
> I adjusted it to 0x31000 which is the maximum of free space in the SRAM.
>

Just checked the latest upstream/next and there's a still a bit of a
twist to this saga, I am afraid :-). The limit of 0x31000 works just
fine, but there a silly typo here:

https://git.pengutronix.de/cgit/barebox/tree/arch/arm/boards/zii-imx6q-rdu2/flash-header-rdu2.imxcfg?h=next#n3

specifically "00x31000" instead of "0x31000", which is interpreted by
do_max_load_size() as "0". Changing the code to the following:

data->max_load_size = strtoul(argv[1], &end, 0);
if (*end != '\0') {
    fprintf(stderr, "illegal max_load_size \"%s\"\n", argv[1]);
    return -EINVAL;
}

fixed the problem, however we might want to do that for all of the
other places that do similar parsing and don't check the result
(do_dcd_offset(), do_loadaddr()) . I'll put together a patch for that
shortly.

> BTW I am not really happy that we can't detect when we run out of space
> in the SRAM. I am aware of that and hopefully we can find a solution,
> but currently we have nothing more than just a few ideas.
>

Agreed and good to know.

Thanks,
Andrey Smirnov

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox