sysupgrade fails on evbarm7hf (rasperry pi 2)

[milestone]

Hello everyone

I tried to upgrade NetBSD from 7.0.1 to 7.0.2 but it fails.

sysupgrade kernel
sysupgrade: I: Skipping kernel installation (KERNEL not set)

At first the kernel was not recognized but I set it manual to RPI2

Next try:

sysupgrade auto ftp://ftp.NetBSD.org/pub/NetBSD/NetB...vbarm-earmv7hf

No error message, everything seems to be fine but:

uname -a
NetBSD berlin 7.0.1 NetBSD 7.0.1 (RPI2.201605221355Z) evbarm

Later I tried to upgrade from 7.0.1 to 7.1 but I got the same result. I still stay with 7.0.1 but don't know what I did wrong or where I could try to look.


Update:
Several months later, I tried it again with the same result.

Before I did a complete new installation with NetBSD 8.99.2 (RPI2)

sysupgrade auto ftp://nyftp.netbsd.org/pub/NetBSD-daily/HEAD/201711241510Z/evbarm-earmv7hf

uname -a
NetBSD armv7 8.99.2 NetBSD 8.99.2 (RPI2) #0: Tue Sep 12 07:19:36 UTC 2017  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/evbarm/compile/RPI2 evbarm

Any ideas?

[milestone]

today I tried sysupgrade 8.99.8 -> 8.99.12

same result. No errors and after all I stay with 8.99.8

$ name -r
8.99.8

$ ls -l *bsd
-rw-r--r--  1 root  wheel  8054460 Jan 25 22:21 netbsd
-rw-r--r--  1 root  wheel  7983564 Dec 29 12:22 onetbsd

$ cd /kern ; ls -l
total 31
-r--r--r--  1 root  wheel     11 Jan 26 07:59 boottime
-r--r--r--  1 root  wheel    318 Jan 26 08:11 copyright
-rw-r--r--  1 root  wheel      6 Jan 26 08:11 hostname
-r--r--r--  1 root  wheel      4 Jan 26 08:11 hz
-r--r--r--  1 root  wheel     14 Jan 26 08:11 loadavg
-r--r--r--  1 root  wheel  16368 Jan 26 08:11 msgbuf
-r--r--r--  1 root  wheel      5 Jan 26 08:11 pagesize
-r--r--r--  1 root  wheel      7 Jan 26 08:11 physmem
br--r--r--  1 root  wheel  92, 0 Jan 26 08:11 rootdev
cr--r--r--  1 root  wheel  92, 0 Jan 26 08:11 rrootdev
-r--r--r--  1 root  wheel     18 Jan 26 08:11 time
-r--r--r--  1 root  wheel    122 Jan 26 08:11 version

Maybe just a bug in the version file?

[milestone]

On the netbsd wiki it is mentioned how to upgrade the kernel [1]

Updating the kernel

• Build a new kernel, e.g. using build.sh. It will tell you where the ELF version of the kernel is, e.g.
  ...
  Kernels built from RPI2:
  /Users/feyrer/work/NetBSD/cvs/src-current/obj.evbarm-Darwin-XXX/sys/arch/evbarm/compile/RPI2/netbsd
  ...
• Besides the "netbsd" kernel in ELF format, there is also a "netbsd.bin" kernel that is in a format that the Raspberry can boot.
• Depending on your hardware version, copy this either to /boot/kernel.img (First generation Pi, Pi Zero hardware) or to /boot/kernel7.img (Pi 2, Pi 3 hardware)
• reboot

So I guess, that I have to copy the kernel into the directory /boot

#ls -l *.IMG
-rwxr-xr-x 1 root wheel 7348948 Dec 3 21:03 KERNEL7.IMG

But which file do I need? None of the files are created with sysupgrade?
Or do I have to build the kernel by myself on the RPI and it is not possible with sysupgrade?

[1] http://wiki.netbsd.org/ports/evbarm/..._pi/#index10h2

[milestone]

Still the same problem when I try to upgrade from 8.0 to 8.1

Changed the Kernel manual to RPI2

/usr/pkg/etc/sysupgrade.conf
KERNEL=RPI2

Then I started the upgrade process:

sysupgrade auto ftp://ftp.NetBSD.org/pub/NetBSD/NetB...vbarm-earmv7hf

No problems at all

But ...

uname -a
NetBSD armv7 8.0 NetBSD 8.0 (RPI2) #0: Tue Jul 17 14:59:51 UTC 2018 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/evbarm/compile/RPI2 evbarm

[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?

-bash-5.0$ ls -lT
total 29554
drwxr-xr-x   2 root  wheel      512 May 31 10:43:59 2019 altroot
drwxr-xr-x   2 root  wheel     1024 May 31 10:43:59 2019 bin
drwxr-xr-x   1 root  wheel    16384 Dec 31 23:00:00 1979 boot
drwxr-xr-x   9 root  wheel    28160 May 31 10:43:59 2019 dev
-rw-------   1 root  wheel   671468 Jan  1 19:28:38 2019 dhcpcd.core
drwxr-xr-x  29 root  wheel     2048 Jun  8 14:39:03 2019 etc
drwxr-xr-x   3 root  wheel      512 Oct 27 12:48:52 2018 home
dr-xr-xr-x   2 root  wheel      512 Jun  8 14:41:43 2019 kern
drwxr-xr-x   4 root  wheel     2048 May 31 10:43:59 2019 lib
drwxr-xr-x   3 root  wheel      512 May 31 10:43:59 2019 libdata
drwxr-xr-x   5 root  wheel      512 May 31 10:43:59 2019 libexec
drwxr-xr-x   2 root  wheel      512 May 31 10:43:59 2019 mnt
-rw-r--r--   1 root  wheel  7052052 Jun  8 11:59:38 2019 netbsd
-rw-r--r--   1 root  wheel  7052052 Jun  7 21:40:50 2019 onetbsd
dr-xr-xr-x   1 root  wheel      512 Jun  8 14:41:43 2019 proc
drwxr-xr-x   2 root  wheel     3072 May 31 10:43:59 2019 rescue
drwxr-xr-x   5 root  wheel      512 May 31 10:43:59 2019 root
drwxr-xr-x   2 root  wheel     3072 May 31 10:43:59 2019 sbin
drwxr-xr-x   3 root  wheel      512 May 31 10:43:59 2019 stand
drwxrwxrwt   2 root  wheel      512 Jun  8 14:38:20 2019 tmp
drwxr-xr-x  15 root  wheel      512 May 31 10:43:59 2019 usr
drwxr-xr-x  26 root  wheel      512 May 31 10:43:59 2019 var
-bash-5.0$ uname -a
NetBSD armv7 8.0 NetBSD 8.0 (RPI2) #0: Tue Jul 17 14:59:51 UTC 2018  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/evbarm/compile/RPI2 evbarm

[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

[milestone]

Thanks for you detailed answer!!
I will give it a try :-)

[libertas]

Hi,

Could you give step by step instructions on how to upgrade a NetBSD on the Rpi?

[milestone]

Originally Posted by Sensucht94

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!

Hey,
today I gave it a try but it didn't work for me.
- I downloaded the image by j.McNeill (for RPI2)
- unpacked it
- mounted the IMG
- copied everything to my SD (modified the config.txt before)
- could not boot from SD

-> copied the old files to SD and I am able to boot again.

What's wrong?

[Sehnsucht94]

Originally Posted by milestone

Hey,
today I gave it a try but it didn't work for me.
- I downloaded the image by j.McNeill (for RPI2)
- unpacked it
- mounted the IMG
- copied everything to my SD (modified the config.txt before)
- could not boot from SD

-> copied the old files to SD and I am able to boot again.

What's wrong?

Never tried a RPI2 image, but I really don't see any concrete reason which it shoudn't be working for. Personally I followed this procedure on both RPi3 and Odroid C2. Had you perhaps modified cmdline.txt too so as to point the kernel to a root partition different from the default one (lda0)...and forgot to apply the same modification after upgrading? On the other hand the boot partition should by itself contain everything needed to boot already, so, were that the case, the boot procedure should rather fail at mounting root

[milestone]

Hey. Sorry for the late response.
I switched the usecase for my RPI2, so at the moment there is debian linux running.