[PATCH 14/21] mach-snapdragon: dynamic load addresses

[Tom Rini]

On Tue, Nov 21, 2023 at 05:09:37PM +0000, Caleb Connolly wrote:

> Heavily inspired by Apple board code. Use the LMB allocator to configure
> load addresses at runtime, and implement a lookup table for selecting a
> devicetree.
> 
> As some Qualcomm RBx boards have different RAM capacities and base
> addresses, it isn't possible to hardcode these regions.
> 
> Signed-off-by: Caleb Connolly <caleb.connolly at linaro.org>
[snip]
> +#define KERNEL_COMP_SIZE	SZ_32M
> +#define SZ_96M			(SZ_64M + SZ_32M)
> +
> +#define addr_alloc(lmb, size) lmb_alloc(lmb, size, SZ_2M)
> +
> +/* Stolen from arch/arm/mach-apple/board.c */
> +int board_late_init(void)
> +{
> +	struct lmb lmb;
> +	u32 status = 0;
> +
> +	lmb_init_and_reserve(&lmb, gd->bd, (void *)gd->fdt_blob);
> +
> +	/* We need to be fairly conservative here as we support boards with just 1G of TOTAL RAM */
> +	status |= env_set_hex("kernel_addr_r", addr_alloc(&lmb, SZ_96M));
> +	status |= env_set_hex("loadaddr", addr_alloc(&lmb, SZ_64M));
> +	status |= env_set_hex("fdt_addr_r", addr_alloc(&lmb, SZ_2M));
> +	status |= env_set_hex("ramdisk_addr_r", addr_alloc(&lmb, SZ_96M));
> +	status |= env_set_hex("kernel_comp_addr_r", addr_alloc(&lmb, KERNEL_COMP_SIZE));
> +	status |= env_set_hex("kernel_comp_size", KERNEL_COMP_SIZE);
> +	status |= env_set_hex("scriptaddr", addr_alloc(&lmb, SZ_4M));
> +	status |= env_set_hex("pxefile_addr_r", addr_alloc(&lmb, SZ_4M));

First, with 1G total, we should I think be fine using SZ_128M and not
needing to add SZ_96M. Second, having worked on
https://patchwork.ozlabs.org/project/uboot/patch/20231119144338.630138-2-sjg@chromium.org/
a bit I think your sizes are a bit funny. We're looking at where to
decompress the provided Image file to and so 32M is too small. My
generic v6.6 Image is 40MB. One of those "would be nice" things to see
now that I've kicked things around a little was if all of our boot$foo
decompression logic just asked the lmb to give us a new region of
max-feasible-size for a Linux kernel (or we make it a choice between 64
or 128MB max supported kernel image). And further looking at the code
and matching it up with the function docs, it's even funkier than I had
thought, sigh.

And to try and be clear, the second is an ask, but the first is a change
request, those sizes are too small and inconsistent with supporting a
large uncompressed kernel.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20231121/095cccc7/attachment.sig>