On Mon, Apr 06, 2020 at 08:24:26PM -0000, Karl Palsson wrote:
Maxime Ripard maxime@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.
There's really no difference with FASTBOOT_BUF_SIZE. It's a limit to prevent getting an image that's too big, the limit is fairly arbitrary, and if it's smaller it's not going to use all of it.
Could it just be removed altogether?
Not really, unfortunately.
You would "allow" users to run a command that might result in a hang/crash
And that's a pretty big deal? Especially since, if you're using a distro, the kernel size might very well go past the tipping point without you noticing at all?
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.
Look, I don't really want to argue about this. I gave you a way forward that would accomodate every one and would allow people with different expectations to change it to their own arbitrary limit easily. If you don't want to do it, fine, but this patch is not a solution either.
Maxime