[PATCH 1/2] sunxi: allow bigger images for all

[Karl Palsson]

Maxime Ripard <maxime at cerno.tech> wrote:
> Hi,
> 
> On Mon, Apr 06, 2020 at 03:51:39PM +0000, Karl Palsson wrote:
> > No reason to limit bigger images to 64bit targets, it's quite easy
> > to go over the limit with a kernel+initramfs
> 
> There's a reason: we support some boards with 32 and 64MB of
> RAM.
> 
> It would obviously not fit with 32MB boards, and I'm pretty
> sure it wouldn't with 64MB either.
> 
> It would make more sense to put that in Kconfig so that boards
> that need less have a chance at setting a lower limit, just
> like FASTBOOT_BUF_SIZE

Well, one difference is that the fastboot buffer is memory that's _used_  the CONFIG_SYS_BOOTM_LEN is just an artificial limit to prevent attempting to boot an image that's "too big" and the limit is fairly arbitrary.  Could it just be removed altogether?  You would "allow" users to run a command that might result in a hang/crash, but right now you need to recompile your bootloader based on this arbitrary fixed number.  

The bootm code already mallocs len * 4, then just artificially
limits it (or changes the error message) based on this
CONFIG_SYS_BOOTM_LEN.

```
       /* Allow the image to expand by a factor of 4, should be safe */
        load_buf = malloc((1 << 20) + len * 4);
        ret = image_decomp(imape_comp, 0, data, image_type, load_buf,
                           (void *)data, len, CONFIG_SYS_BOOTM_LEN,
                           &load_end);
```

Sincerely,
Karl Palsson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP-digital-signature.html
Type: application/pgp-signature
Size: 1175 bytes
Desc: OpenPGP Digital Signature
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200406/c8877b32/attachment-0001.sig>