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

[Caleb Connolly]

On 21/11/2023 19:24, Tom Rini wrote:
> 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.

To your first point, yeah it looks like I can get away with 128M
uncompressed, it definitely feels a bit safer heh

To be honest, most of my testing has been booting via bootflow/bootefi
-> systemd-boot which I assume will be using the EFI allocator to load
everything. I still have a lot of local patches to push upstream,
otherwise I'd definitely be interested in finding a cleaner / more
generic solution here.
> 
> 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.
> 

-- 
// Caleb (they/them)