u-boot names for hisi 3519dv500 3516cv6xx

[sansarus]

https://github.com/OpenIPC/u-boot-hi3519dv500/blob/2eae7bc48dfda1b9d190fc54d05028703069d357/.github/workflows/build.yml#L158
https://github.com/OpenIPC/u-boot-hi3516cv6xx/blob/d8a22b0cec0ed9f748e64050a2eb70bfff9037bc/.github/workflows/build.yml#L192

creates not standart name for u-boot image
and not suitable with

firmware/.github/workflows/image.yml

Line 83 in 3e98d91

uboot=u-boot-$1-nor.bin

so tgz packets at releases makes wrong

[widgetii]

Resolved for cv6xx in #2210: the firmware release pipeline now assembles full NOR images per DDR topology rather than expecting a single u-boot-<soc>-nor.bin.

Root cause: hi3516cv610 has no single universal image — its u-boot is published per DDR binning because the boot-ROM DDR init table is baked into each boot image (and CMD_DDR_TRAINING only tunes PHY timing, not type/size). So image.yml now emits:

• openipc-hi3516cv610-ddr2-64m-nor-ultimate.bin
• openipc-hi3516cv610-ddr3-128m-nor-ultimate.bin
• openipc-hi3516cv610-ddr3-512m-nor-ultimate.bin
• openipc-hi3516cv608-nor-ultimate.bin

(u-boot @0, firmware.bin.<soc> @0x50000). These appear from the next nightly image-assembly run.

Hi3519DV500 is not yet covered: its NOR boot path isn't wired in u-boot (# CONFIG_USE_BOOTCOMMAND is not set, CONFIG_MTDPARTS_DEFAULT="", bootcmd bootm 0x42000000 with no sf read), so a full NOR image can't boot. Leaving this issue open to track the dv500 side once that lands.

[widgetii]

dv500 NOR boot — verified end-to-end in QEMU

The Hi3519DV500 full NOR image (self-extracting U-Boot + firmware.bin = gzip FIT kernel + squashfs) now boots all the way to the login prompt on the emulated dual Cortex-A55, deterministically (3/3 runs, no Oops/panic):

Starting kernel ...
VFS: Mounted root (squashfs filesystem) readonly on device 31:3.
Run /init as init process
Welcome to OpenIPC
openipc-hi3519dv500 login:

Two PRs make this work:

• U-Boot — hi3519dv500: SPI-NOR boot (automatic flash-layout detection) u-boot-hi3519dv500#3: SPI-NOR auto flash-layout detection + the bootargs default-env mechanism (mirrors cv6xx hi-common.h: bootargs in EXTRA_ENV, escaped ${osmem}/${mtdids}/${mtdparts}, CONFIG_BOOTARGS_SUBST), ft_board_setup() stripping the FIT dtb's stale linux,initrd-* reservation, and CONFIG_SYS_BOOTM_LEN=32M.
• QEMU machine — hisilicon: boot the published Hi3519DV500/Hi3516DV500 NOR image to userspace widgetii/qemu-hisilicon#126: FMC 8-byte JEDEC read, reset-to-EL1 (+ EL3 off) with PSCI-over-SMC conduit on the flash path, and a GPIO0_0 pull-up so U-Boot doesn't drop into the USB/SD download loop.

Notable gotcha for anyone building dv500/cv6xx NOR images: the published FIT kernel dtb ships linux,initrd-start=0x60000040 / linux,initrd-end=0x61000000. With no ramdisk and ≤512 MB RAM the kernel unpacks a bogus 16 MiB initramfs from non-existent memory → intermittent slab corruption and panics. The U-Boot PR strips it; the proper long-term fix is for the kernel dtb to not carry that stale reservation.

cv6xx NOR images (per-DDR-binning) were added earlier in #2210. Once #3 merges, the dv500 NOR image can be wired into image.yml the same way.

[widgetii]

Resolved

The root of this report: the HiSilicon per-SoC u-boot repos publish boot-<soc>-<binning>-nor.bin artifacts that don't fit image.yml's generic create() (which expects one u-boot-<board>-nor.bin plus separate uImage.<soc> + rootfs.squashfs.<soc>), so the released tgz packing was wrong for these SoCs.

Rather than force the HiSilicon images into the generic naming, we taught image.yml how the V4/V5 parts actually ship. On these SoCs the u-boot is published per DDR binning (the boot-ROM DDR init table is baked into each signed boot image) while the kernel+rootfs is a single pre-packed firmware.bin.<soc> blob flashed at the firmware-partition offset. A dedicated create_hisi() assembles one full 16 MiB NOR image per binning (u-boot @0, firmware.bin at the partition offset).

What landed

• cv6xx — image: assemble per-DDR-binning full NOR images for hi3516cv610/cv608 (#2208) #2210: create_hisi() + the cv610 (DDR2-64M / DDR3-128M / DDR3-512M) and cv608 images, firmware @0x50000.
• Hi3519DV500 — full NOR boot brought up from scratch:
  • U-Boot SPI-NOR boot path + bootargs/initrd fixes — hi3519dv500: SPI-NOR boot (automatic flash-layout detection) u-boot-hi3519dv500#3
  • Emulator support (FMC, EL1+PSCI, GPIO pull-up) — hisilicon: boot the published Hi3519DV500/Hi3516DV500 NOR image to userspace widgetii/qemu-hisilicon#126
  • Image assembly (dmeb / dmebpro, firmware @0xc0000) — image: assemble Hi3519DV500 full NOR images (#2208) #2211
• The published image was verified booting end-to-end to openipc-hi3519dv500 login: in QEMU (dual Cortex-A55, deterministic, zero Oops).

Naming

Release artifacts are now consistent and traceable to their per-binning u-boot:

• openipc-hi3516cv610-{ddr2-64m,ddr3-128m,ddr3-512m}-nor-ultimate.bin, openipc-hi3516cv608-nor-ultimate.bin
• openipc-hi3519dv500-{dmeb,dmebpro}-nor-ultimate.bin

All three PRs are merged. Closing — please reopen if any specific artifact name still looks off.