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@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... 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.