Bug#899118: flash-kernel: add missing arm64 boards

[Karsten Merker]

Package: flash-kernel
Version: 3.94
Severity: normal
Tags: patch
Add 60 missing database entries for arm64 boards

[...]

many thanks for the patch. Just to make sure that we don't run
into problems later on: do all these boards really use u-boot's
config_distro_bootcmd.h and thereby work properly with
bootscr.uboot-generic?
When looking at the defconfigs for several of these systems, I
see e.g. CONFIG_BOOTARGS settings that don't really match what I
would expect for systems using config_distro_bootcmd.h.
CONFIG_BOOTARGS="console=ttySC0,115200 rw root=/dev/nfs nfsroot=192.168.0.1:/export/rfs ip=192.168.0.20"
CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 earlycon=uart8250,mmio,0x21c0500 ramdisk_size=0x3000000 default_hugepagesz=2m hugepagesz=2m hugepages=256"
CONFIG_BOOTARGS="console=ttyAMA0,115200n8 root=/dev/mmcblk0p9 rw"

[,,,]

- be capable to load and execute boot.scr
- provide the booti command
- devtype, devnum, partition
- fdtfile
- kernel_addr_r
- fdt_addr_r
- ramdisk_addr_r
In your examples above I could not find any evidence that U-Boot cannot
be configured and built to fulfill these requirements.
For instance build
make r8a77995_draak_defconfig
make menuconfig
CONFIG_DISTRO_DEFAULTS=y
CONFIG_BOOTARGS="console=ttySC0,115200"
CONFIG_ENV_IS_IN_MMC=y (this is a default value)
make -j6
Setup missing environment variables interactively and save them to MMC
and you can rely on flash-kernel for booting.
ls1088ardb_sdcard_qspi_defconfig and hikey_defconfig select
CONFIG_DISTRO_DEFAULTS=y. CONFIG_BOOTARGS has to be reconfigured.
This patch is only about providing flash-kernel for the boards. It is
not about providing U-Boot configured to match flash-kernel's requirements.
I think that even for boards for which we do not provide U-Boot as a
Debian package we should allow the usage of flash-kernel without setting
up a local override for the machine database (/etc/flash-kernel/db).

Hello,

our policy has always been to only add an entry for an
armhf/arm64 system to the flash-kernel database if this entry
works out of the box with the default mainline u-boot
configuration for the respective device. Users usually expect
that a system boots out of the box without having to build a
non-standard u-boot configuration and modify the default
environment if the system is listed in the flash-kernel machine
db.

I'm open to arguments to the contrary, but for now I believe that
is makes sense to keep this policy.

Having to build u-boot with an undocumented non-standard
configuration and having to modify various non-obvious parts of
the default environment (which possibly includes having to find
out the platform-specific kernel_addr_r, fdt_addr_r and
ramdisk_addr_r values for systems where they are not already
defined in the default environment) to make the system boot is an
extremely high and completely unexpected hurdle for a "normal"
user, and I believe that we would do a large part of our userbase
a misservice by including entries that do not work out of the
box.

For somebody who has the knowledge to perform all the
aforementioned steps on the u-boot side, it's usually easy to
also add a corresponding local entry to /etc/flash-kernel/db.

I'm CCing debian-arm for further opinions on the matter.

Regards,
Karsten