Hi Pascal,
Thanks for your interest in this issue.
On 28/08/2025 at 12:40 UTC, Pascal Hambourg wrote:
> I discovered the GPT vs U-Boot overlapping issue while using the Debian
> installer because the default disk label (partition table) type defined
> in partman-partitioning is GPT on EFI or arm64 platforms.
Yes exactly; if u-boot-install-sunxi had gained an "--alt-offset" feature I
would have suggested using it to regenerate the sunxi arm64 installer images
with U-Boot positioned at 128K rather than at 8K. As you've described on
#1112448, currently the installer doesn't always produce a bootable system.
> Right, but the partition entry array offset and even the partition entry
> size are defined in the GPT header and may vary. A safe non-overlapping
> requirement check should be:
> [...]
You're right but I think u-boot-install-sunxi is only meant to be a simple
convenience wrapper around dd, with some basic sanity checks. That earlier
comment of mine was just to question the choice of 4 as an upper limit.
> True with H3, A64, H5 and H6 but H616 (and maybe other SOCs) set the
> alternate boot location at 256KiB instead of 128KiB. [...]
Ah I didn't know the H616 was different. So yes, automatically selecting a
suitable offset seems a better way to go; a revised patch is below.
Thanks for your suggestions,
Harold.
diff --git a/debian/bin/u-boot-install-sunxi b/debian/bin/u-boot-install-sunxi
index fca4ddc436..8b2a5cb667 100755
--- a/debian/bin/u-boot-install-sunxi
+++ b/debian/bin/u-boot-install-sunxi
@@ -79,6 +79,31 @@ if [ ! -w "$DEV" ] && [ -z "$FORCE" ]; then
exit 1
fi
+board=$(basename "$TARGET")
+echo >&2 "Selected board: ${board}"
+
+# Select write offset based on board
+case "$board" in
+ # H2+ or H3 SoC
+ "nanopi_neo" | "nanopi_neo_air" | "orangepi_pc_plus" | "orangepi_plus"
| "orangepi_zero" )
+ wroff="128K" ;;
+ # A64, H5 or H6 SoC
+ "a64-olinuxino" | "a64-olinuxino-emmc" | "nanopi_neo2" |
"nanopi_neo_plus2" |\
+ "orangepi_one_plus" | "orangepi_zero_plus2" | "pine64-lts" |
"pine64_plus" |\
+ "pinebook" | "pinephone" | "pinetab" | "sopine_baseboard" | "teres_i" )
+ wroff="128K" ;;
+ # Older SoC
+ *)
+ wroff="8K" ;;
+esac
+echo >&2 "Selected offset: ${wroff}"
+
+# Warn about boot priority
+if [ "$wroff" != "8K" ] && printf 'eGON.BT0' | cmp -s -i 0:8196 -n 8 - "$DEV";
then
+ echo >&2 "WARNING: device/image ($DEV) has boot program"
+ echo >&2 " at offset 8K which might take priority"
+fi
+
if [ -z "$FORCE" ]; then
# A very simple sanity check. GPT mandates a "protective MBR" so this
works
# even with GPT partitioning.
@@ -87,9 +112,9 @@ if [ -z "$FORCE" ]; then
exit 1
fi
- # But, on sunxi64, spl will trample upon GPT.
- if printf 'EFI PART' | cmp -s -i 0:512 -n 8 - "$DEV"; then
- echo >&2 "$0: device/image ($DEV) uses GPT partition table, unusable on
sunxi64"
+ # But writing at offset 8K will trample upon GPT.
+ if [ "$wroff" = "8K" ] && printf 'EFI PART' | cmp -s -i 0:512 -n 8 -
"$DEV"; then
+ echo >&2 "$0: device/image ($DEV) uses GUID partition table, would
overwrite it"
exit 1
fi
fi
@@ -100,5 +125,5 @@ if [ ! -f "$imfile" ]; then
exit 1
fi
-echo "Writing U-Boot image ${imfile} to ${DEV}"
-dd conv=fsync,notrunc if="$imfile" of="$DEV" bs=8K seek=1
+echo "Writing U-Boot image ${imfile} to ${DEV} at offset ${wroff}"
+dd conv=fsync,notrunc if="$imfile" of="$DEV" bs="$wroff" seek=1
diff --git a/debian/manpages/u-boot-install-sunxi.8
b/debian/manpages/u-boot-install-sunxi.8
index 744679ec78..76a11d61a2 100644
--- a/debian/manpages/u-boot-install-sunxi.8
+++ b/debian/manpages/u-boot-install-sunxi.8
@@ -35,6 +35,5 @@ environment variable is set, its contents are used instead.
Skip partition table sanity checks. Usually, a MBR partition table is
required (so u-boot has something to work with), but in rare setups you
may put the data on another disk. Likewise, GPT partition tables are
-incompatible with the layout used on sunxi devices (spl is written at
-offset 16384 while GPT occupies bytes [512..33280) ) but this option lets
+incompatible with the default U-Boot location of 8K, but this option lets
you trample upon them anyway.