On Thu, Nov 29, 2018 at 11:36 PM Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
