da3752a358a86014cdcce5fc3be5b18d7ec074c4 won't boot 64b kernel

[dickontoo]

Describe the bug

rpi-updated to da3752a358a86014cdcce5fc3be5b18d7ec074c4, and the 64b kernel fails to completely transfer and boot.

To reproduce
Network boot with the attached config.txt. Watch the tftpd logs.

Expected behaviour
For the kernel8.img transfer to complete, and the kernel start booting.

Actual behaviour
The kernel8.img transfer starts, but then appears to crash; the tftpd subsequently gives up. The screen changes from rainbow to black. Nothing appears on serial after the usual 'Starting start4x.elf' line.

System

• Which model of Raspberry Pi? e.g. Pi3B+, PiZeroW

Pi4, 2G and 8G (when I can get that damned thing to boot at all).

• Which OS and version (cat /etc/rpi-issue)?

rpi-updated Buster, 5.4.49-v8+

• Which firmware version (vcgencmd version)?
  da3752a358a86014cdcce5fc3be5b18d7ec074c4

• Which kernel version (uname -a)?

Logs
Doesn't get that far.

Additional context

I was attempting to get my new 8G to boot reliably -- please see this thread -- and thought it would be helpful to at least be on the latest firmware. Both the 8G and the 2G failed to complete the TFTP transfer of the kernel8.img file, although a brief test on the 2G did manage to boot the -v7l. Relevant log entries:

Jun 27 13:38:43 rtr-dickonh atftpd[2413]: Creating new socket: 172.29.23.1:43860
Jun 27 13:38:43 rtr-dickonh atftpd[2413]: Serving b5b897d0/armstub8-gic.bin to 172.29.23.7:49169                                                                Jun 27 13:38:43 rtr-dickonh atftpd[2413]: File /tftpboot/b5b897d0/armstub8-gic.bin not found                                                                    Jun 27 13:38:43 rtr-dickonh atftpd[2413]: Server thread exiting
Jun 27 13:38:43 rtr-dickonh atftpd[2413]: socket may listen on any address, including broadcast                                                                 Jun 27 13:38:43 rtr-dickonh atftpd[2413]: Creating new socket: 172.29.23.1:60395
Jun 27 13:38:43 rtr-dickonh atftpd[2413]: Serving b5b897d0/kernel8.img to 172.29.23.7:49170                                                                     Jun 27 13:38:43 rtr-dickonh atftpd[2413]: tsize option -> 15483392
Jun 27 13:38:43 rtr-dickonh atftpd[2413]: blksize option -> 1024
Jun 27 13:38:48 rtr-dickonh atftpd[2413]: timeout: retrying...
Jun 27 13:38:53 rtr-dickonh atftpd[2413]: timeout: retrying...
Jun 27 13:38:58 rtr-dickonh atftpd[2413]: timeout: retrying...
Jun 27 13:39:03 rtr-dickonh atftpd[2413]: timeout: retrying...
Jun 27 13:39:08 rtr-dickonh atftpd[2413]: timeout: retrying...
Jun 27 13:39:13 rtr-dickonh atftpd[2413]: client (172.29.23.7) not responding
Jun 27 13:39:13 rtr-dickonh atftpd[2413]: End of transfer
Jun 27 13:39:13 rtr-dickonh atftpd[2413]: Server thread exiting

bootloader_config:

[all]
BOOT_UART=1
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=15000
TFTP_IP=
BOOT_ORDER=0xf142
SD_BOOT_MAX_RETRIES=3
NET_BOOT_MAX_RETRIES=2
[none]
FREEZE_VERSION=0

config.txt:

arm_64bit=1
gpu_mem=256

initramfs initrd.gz
hdmi_enable_4k=1

dtoverlay=w1-gpio,gpiopin=11
hdmi_ignore_cec_init=1

# Enable audio (loads snd_bcm2835)
dtparam=audio=on
bootloader_update=1

[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
# dtoverlay=vc4-kms-v3d
max_framebuffers=2
enable_uart=1
dtoverlay=uart5
# dtoverlay=uart0
start_x=1
dtparam=act_led_trigger=heartbeat

[all]
#dtoverlay=vc4-fkms-v3d
hdmi_enable_4kp60=1
disable_overscan=1

[pelwell]

I take it that 634e380a4d041492f859712bd2c81112a535b515 boots?

[dickontoo]

On Sat, Jun 27, 2020 at 06:29:20 -0700, Phil Elwell wrote: : I take it that 634e380a4d041492f859712bd2c81112a535b515 boots? Yes, although there's a version mismatch between what /boot/.firmware_revision contains ('634e380a4d041492f859712bd2c81112a535b515') and what 'vcgencmd version' reports ('version 31eda665dcc45e61650a2ef018ef2cf94091c46f (clean) (release) (start_x)'). Either way, that boots. Dickon Hood -- Due to brexit my .signature is temporarily unavailable. Normal service will be resumed as soon as possible. We apologise for the inconvenience in the meantime. This email was sent from a colocated server, and needs no excuses.

[pelwell]

There is a change in da3752a3 that only affects the loading of 64-bit kernels. You can verify that this is the culprit by adding kernel_address=0x80000 to config.txt, which will bypass the new code, but be aware that that this will probably break a 32-bit kernel.

[pelwell]

/boot/.firmware_revision covers the whole release, whereas vcgencmd version is the hash for the source code repo.

[dickontoo]

Thanks for clarifying that.

Yes, kernel_address=0x80000 fixes it. This machine is running a 64b userland ATM anyway, so I'm not too fussed about 32b breakage.

[satmandu]

This is the same issue as #1420

Is there any chance some automated version of rpi-update with a reboot can be done for some subset of the Raspberry PI OS releases on the most recent boards before the firmware is released here?

For instance, all else being equal, both the 32bit and 64 bit Raspberry Pi OS should at least boot on the combo of new firmware & new kernel on the RPI4.

(I assume an automated V&V setup already exists - and assuming such this is just a request then to add arm64 tests.)

[pelwell]

I don't think it is the same issue - this only affects loading the kernel8.img file over TFTP, whereas this fails loading the DTB file.

There are automated tests on the firmware, but the number of tests is lagging behind the increasing number of configurations.

[dickontoo]

32b kernel boots fine. I'm not sure why you thought it wouldn't, TBH. I've had success booting the thing all over the map, although admittedly not on a Pi or with your kernels.

[dickontoo]

Fixed, thanks.