hard-coded u-boot load addresses fragile and breaking low-memory boards

[Tonymac32]

build/config/bootscripts/boot-meson64.cmd

Line 7 in 0e7fc1c

setenv kernel_addr_r "0x34000000"

Compare values to u-boot config:

#define BOOTM_SIZE		__stringify(0x1700000)
#define KERNEL_ADDR_R		__stringify(0x08080000)
#define KERNEL_COMP_ADDR_R	__stringify(0x0d080000)
#define FDT_ADDR_R		__stringify(0x08008000)
#define SCRIPT_ADDR_R		__stringify(0x08000000)
#define PXEFILE_ADDR_R		__stringify(0x01080000)
#define FDTOVERLAY_ADDR_R	__stringify(0x01000000)
#define RAMDISK_ADDR_R		__stringify(0x13000000)

La Frite will not boot Armbian now that some additional reserved memory regions exist, these do not conflict with the defaults built into U-boot (confirmed on my side). Suggest removing these Armbian-sourced values as default and any board that can't boot normally should put these in armbianEnv.txt or otherwise handle them in a board-specific manner

[github-actions]

Jira ticket: AR-2058

[Tonymac32]

@armbian/boards-amlogic take a look, I'll start changing stuff without feedback otherwise

[rpardini]

@armbian/boards-amlogic take a look, I'll start changing stuff without feedback otherwise

Would using extlinux "just work?" (eg: are the loadaddrs sane in upstream u-boot?). I've no <4gb meson boards to test.

[Tonymac32]

It literally has to be 1 or 2 boards that have a "problem" with the defaults, so not specifying then "just works".

If device tree overlays work with extlinux then sure why not, but its unnecessary work for what is a problem specific to some board, and for all we know isn't even an issue anymore.

[rpardini]

I meant: if it works with extlinux (where we cant' override built-in uboot loaddr's), then it's safe to remove the hacked loadaddrs from bootscript. "One day" we should be able to template/add/remove stuff per-board from the bootscript to make it easier, since this bootscript is used by the whole family...