[Sehnsucht94]

Originally Posted by milestone

The date of the files look ok except the /boot directory
So I think the boot process is maybe different than on other systems?

Yes it, and that's where the problem lays : while sysupgrade is doing exactly what it's supposed to do (it's a arch-agnostic shtk script), you are definitely not booting the new kernel. The boot process of most ARM SoCs specifically designed for Linux, involves loading to SDRAM a self-extracting compressed zImage of the kernel, from a FAT{16,32} partition, at 0x82000000, see the arm/booting section of Linux docs. ARM SoCs are not compatible with IBM BIOS and AFAICT cannot make use of boot.cfg(5): that's why your updated kernel at /netbsd is not being loaded.

Referring in particular to Raspberry Pi*, all files needed to boot -as well as all the .dtb firmware- are expected to be found on the first (FAT32) partition of a MBR disk: the third stage bootloader, start.elf, reads config.txt and cmdline.txt and loads to SDRAM a armv7hl PI2 kernel zImage, by default called kernel7.img: any custom name needs to be specified in config.txt, see official docs on Rpi Boot Options.

Now, if you hypothetically renamed a standard netbsd kernel ELF as'kernel7.img' and put it on /boot , that would naturally fail booting as start.elf expects a zImage. While standard kernel build tools (nbmake-evbarm, build.sh) are not capable of creating zImages, gzboot was specifically created as a workaround for the issue: it produces a self-extracting, zImage-like kernel img out of a gzipped kernel raw bin.

The procedure for creating a self-extracting .img should be as easy as:

 $ cd /usr/src/sys/arch/evbarm/stand/gzboot && make
 $ export GZBOOT="/path/to/gzboot-bin" KERNEL=netbsd-RPI2.bin.gz    
 $ ftp ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-8.1/evbarm-earmv7hf/binary/kernel/${KERNEL} 
 $ cat  $GZBOOT $KERNEL > netbsd.img

In this way the gzboot binary code and the gzipped kernel binary image are
concatenated into a single .img file: the gzboot code will look for the gzipped data just after itself and decompress the kernel image at the specified memory address.

Hereby, providing userland sets have been updated to the same version, all you'd have to do left would be uploading the netbsd.img to the Rpi2' /boot partition and edit the config.txt so as to point it to the right image and make it load at 0x200000

kernel=netbsd.img
kernel_address=0x200000
enable_uart=1

Personally, as I can't put up with sources occupying space on my little SD, and I don't plan on keeping track of Rpi official firmware updates, I am used to:

1. upgrading my RPi3's userland to the latest daily arm64 snapshot with sysupgrade
2. fetching the latest ARMv8 GENERIC64 image by j.McNeill from invisible.ca/arm (lots of ARM bootable images here, with UEFI support)
3. burning it somewhere, then rsyncing everything but my custom config.txt (overclocking, VGA monitor) from its /boot partition to my Rpi3's /boot dir
4. reboot: voilà uname will return the expected kernel version

Hope this helps,
Cheers!

EDIT: it seems NetBSD now uses a specific script to tag the kernel bin as a Rpi self-extracting .img, rpi-mkknlimg.sh

Indeed:

$  file /netbsd
/netbsd: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, for NetBSD 8.99.48, with debug_info, not stripped
$ file /boot/netbsd.img
/boot/netbsd.img: Raspberry PI kernel image