config: bootscripts: adjust meson64 U-Boot addresses for 512MB RAM boards

[GalbertPi]

Updated memory addresses for script and kernel in boot configuration, to fix a bug that impeded the OS boot on Radxa Zero models having less than 1 GB RAM (tested). See issue (and attached image below):
#10231

Description

This PR addresses a critical boot loop issue on low-RAM Amlogic meson64 boards (such as the Radxa Zero 512MB variant).

Context

The default hardware configuration template assigned scriptaddr to 0x32000000 (800MB) and kernel_addr_r to 0x34000000 (832MB). While this works flawlessly on 1GB, 2GB, or 4GB models, it causes an immediate out-of-bounds memory allocation crash and silent CPU boot loop on 512MB hardware SKUs.

Solution

Lowered scriptaddr to 0x10000000 (256MB) and kernel_addr_r to 0x08080000 (128.5MB). This establishes a safe, lower common denominator that accommodates 512MB models perfectly without impacting variants with larger RAM capacities. Verified and fully working on physical hardware.

Summary by CodeRabbit

• Bug Fixes
  • Updated the startup/boot configuration to adjust where boot scripts and the kernel are loaded and executed, improving compatibility and reliability during system startup.

[github-actions]

Hey @GalbertPi! 👋

Thanks for submitting your first pull request to the Armbian project — we're excited to have you contributing! 🧡
Your effort doesn’t just improve Armbian — it benefits the entire community of users and developers.

If you'd like to stay informed about project updates or collaborate more closely with the team,
you can optionally share some personal contact preferences at armbian.com/update-data.
This helps us keep in touch without relying solely on GitHub notifications.

Also, don’t forget to ⭐ star the repo if you haven’t already — and welcome aboard! 🚀

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 896cb744-b21b-452e-98b4-5120e9c9718c

📥 Commits

Reviewing files that changed from the base of the PR and between 19a68d0 and e956e5d.

📒 Files selected for processing (1)

• config/bootscripts/boot-meson64.cmd

🚧 Files skipped from review as they are similar to previous changes (1)

• config/bootscripts/boot-meson64.cmd

---

📝 Walkthrough

Walkthrough

The Meson64 U-Boot boot script changes the script load address to 0x08000000 and the kernel load address to 0x08080000.

Changes

Meson64 boot address configuration

Layer / File(s)	Summary
Update U-Boot load addresses config/bootscripts/boot-meson64.cmd	Changes scriptaddr and kernel_addr_r to the revised memory addresses.

Estimated code review effort: 1 (Trivial) | ~2 minutes

Possibly related PRs

• armbian/build#9925 — Updates related U-Boot kernel and script load addresses.

Suggested labels: Patches

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the meson64 U-Boot address adjustment for low-RAM boards.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[iav]

Thanks for the fix — the direction is right, but scriptaddr=0x10000000 introduces a problem on GX boards.

kernel_addr_r=0x08080000 is a good choice: it matches the upstream U-Boot default (include/configs/meson64.h) and sits above the end of the BL32 region (0x07300000) on both GX and G12.

However, boot-meson64.cmd is shared by the whole meson64 family, and on GXBB/GXL/GXM (Odroid C2, Le Potato, La Frite, Khadas VIM1/VIM2, NanoPi K2, …) address 0x10000000 is secure-monitor RAM: meson-gx.dtsi has secmon@10000000 { reg = <0x0 0x10000000 0x0 0x200000>; no-map; }. The script loads armbianEnv.txt, DT overlays and fixup.scr at scriptaddr — writing there on GX can corrupt secure-monitor data (PSCI crashes: reboot/poweroff) or raise an SError.

Suggest scriptaddr=0x08000000 — the upstream U-Boot default: safe on both GX and G12 (between 0x07300000 and kernel_addr_r 0x08080000), and the 512 KB window is plenty for armbianEnv.txt/dtbo/fixup.scr. It helps 512 MB boards exactly the same way.

Radxa Zero (G12A) is unaffected by this issue — its reserved region ends at 0x08000000, which is why the test passed. A smoke boot on any GX board after the change would be great.

[igorpecovnik]

Safest probably making per board override?

[iav]

Agreed — a per-board override is the safest path for this PR: the tested Radxa Zero gets the fix, the rest of the family stays untouched. Mechanics: give the board its own bootscript via BOOTSCRIPT="boot-radxa-zero.cmd:boot.cmd" in the board config (a variant with 0x08000000/0x08080000), or branch on variant in the shared script.

Switching the whole meson64 family to the upstream U-Boot default addresses (scriptaddr=0x08000000, kernel_addr_r=0x08080000 — safe per the DT reserved-memory layout on both GX and G12) could be a follow-up — but only after a smoke boot on GX hardware (C2/Le Potato), not in this PR.

[GalbertPi]

Hi, I just changed the address as per the first comment, with another commit!
I think that custom overrides kill the universality these scripts are supposed to have, isn't it?

[iav]

The update resolves my concern: 0x08000000/0x08080000 are the upstream U-Boot defaults and are safe per the DT reserved-memory layout on every SoC of the family (GX: secmon at 0x10000000 and 0x05000000–0x07300000 untouched; G12: secmon ends at 0x08000000). No objections to the family-wide variant in this form — it effectively syncs the script with the upstream layout. A smoke boot on a GX board (C2/Le Potato) before merging would still be nice; I can't run it myself — no GX hardware here.

[GalbertPi]

Sounds great! Let's keep this PR on standby until someone with GX hardware can run a quick smoke boot test—hopefully next week or as soon as possible—just to be 100% safe before merging.

Thank you so much for double-checking the memory layouts and validating the global approach!

[iav]

Tests that would settle the family-safety question:

GX (separate secmon layout in meson-gx.dtsi — the only uncovered group; a single successful boot on any of these is enough):

• Odroid C2, NanoPi K2 (GXBB)
• Le Potato, Khadas VIM1 (GXL), Khadas VIM2 (GXM)
• La Frite (GXL) — doubly valuable: it has a 512 MB variant, so one boot validates both the fix itself and GX safety

G12/SM1 — already covered by the Radxa Zero test; extra datapoints (Odroid N2/C4/HC4, VIM3/VIM3L, BPi M5) are welcome but not blocking.

The check boils down to: update /boot/boot.scr from this branch → reboot → normal boot plus working reboot/poweroff (PSCI calls would trip over a corrupted secmon).

[pyavitz]

Makes you wonder; why are these set at all in the script? Seeing as they are already preset by the include/configs/meson64.h file.

#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)

Just removing them from the script should resolve the problem, no?

[iav]

Fair question — but the script can't rely on the compiled-in defaults, because it runs on the whole installed base, not just on a freshly built U-Boot:

1. Armbian never reflashes U-Boot on apt upgrade, so deployed systems often run bootloaders years older than the rootfs. The meson64.h values you quote are the current upstream layout, introduced when the 512MB address problem was fixed upstream; previously flashed U-Boots carry the old addresses baked in — exactly the ones that break 512MB boards. Dropping the assignments would fix nothing for the users who need the fix: their old U-Boot would fall back to its old broken defaults.
2. A saved/imported environment survives updates and can shadow compiled-in defaults with stale values — explicit assignments in boot.scr keep boot deterministic regardless of a board's history.
3. Some images historically booted via vendor U-Boot with no distro_bootcmd variables at all.

So syncing the script's values to the upstream layout (what this PR does) is the right move; removing them only works in a world where everyone runs a freshly flashed U-Boot.

[rpardini]

Wouldn't using say EXT=u-boot-menu (enable_extension u-boot-menu in board file) (which causes extlinux.conf, which will just use the compiled-in values) solve it without messing with bootscript?

[iav]

It doesn't, for the same reason I raised with @pyavitz above: "the compiled-in values" are the values of the U-Boot already flashed on the board — and for the affected users that U-Boot is old and carries the old layout.

Mechanically, extlinux.conf doesn't specify load addresses at all. The sysboot/pxe path takes kernel_addr_r, fdt_addr_r, ramdisk_addr_r and pxefile_addr_r from the environment, i.e. from those same compiled-in values of the old bootloader. We'd swap one config-parsing mechanism for another while the addresses stay exactly as broken as before on 512 MB boards.

There's a practical side too. boot.scr ships with the BSP package, so a plain apt upgrade carries the fix to the installed base by itself. Switching to u-boot-menu means changing the boot scheme on already-deployed systems: a different set of files in /boot, a different parsing path, and it only works if the flashed U-Boot was built with that path enabled at all. That's a reasonable conversation for new images; it isn't a fix for boards already in the field.

So u-boot-menu is an orthogonal topic rather than an alternative to this PR. Syncing the script's values with the upstream layout remains the way to fix both new and existing installs.

[GalbertPi]

Good morning!
Just for my information, do you think that somebody will do the pending testing activities before the next stable images for Radxa Zero will be published in the official Armbian repository, so that the fix will be available for everybody?

[igorpecovnik]

somebody will do the pending testing activities

I am 1-2 months away from ability to run fleet wide tests of any PR. Automatically.
https://docs.armbian.com/Contribute/Datacenter/#boards
But we will never have "all" boards.