DHCP options to identify RPi

[beldzhang]

this is part of #82

1) in DHCP requests:
other than the MAC address, there is no any field to identify a RPi client,
option 93 is set to "0" means IA x86 PC
option 97 UUID just repeat serial no 4 times
the OUI(dc:a6:32) can be use, but it not reliable as my experience
why this needed?
because the PXE options need a special menu item to continue and need to identify x86(bios/uefi) and RPI
suggestion:
option 97, change to magic number + serial no, there is enough length
-or-
option 93, acquire a unique number for RPi (it's complex with IEEE/IANA/RFC...)
-or-
any other option not defined by RFC

2)in DHCP REQUEST packet, there is no PXEClient(60) option
this is not consistency whit DHCP DISCOVER packet.
in my server, I just skip the packets without PXEClient(60), many desktop/laptop/mobile will sent request, and some ones running like flood

@timg236 as you mentioned

I'd suggest an EEPROM config for customizing Option97 e.g.
magic + board-revision + serial + reserved

I think it's a very good idea.
a new video shown netboot to Archlinux and Debian

[timg236]

Ok, I'll add Option97 configuration when I get a spare minute. My vague plan is this format
MAGIC+BOARDREV+MAC LSBs+SERIAL
The current default of repeated serial will be preserved for now although it would be an odd thing to rely upon.
MAGIC can be RPI4 fourCC or hex number specified via EEPROM config file.

The current Option60 can be copied into the DHCP Request as well.

I may also add support for a static ip address (+subnet + gateway).

N.B. We aren't trying to implement a real PXE boot, just enough to make DHCP + TFTP work for the common network configurations. Adding in const data to requests is ok, adding code complexity is not but assuming I've read the protocol correctly the above changes are all fine.

[beldzhang]

this idea is excellent, and no rush...

the current netboot spec is good enough (kernel + initrd + cmdline), because I met some hardware that just has a kernel image support.
there is no need for full PXE stack, for most case with x86 PC, iPXE could do more..

currently debian, archlinuxarm and raspbian is running perfect as client, the server still has some issues that could be done in a week, I think.

BTW, the server side, our code only run on aarch64 because some data struct limiting ...

[beldzhang]

I think I may thought too far...

since I not familiar with dnsmasq/isc-dhcp, so no idea how to check the planed option-97 format in there config files.
if it is not easily parse by dnsmasq/isc-dhcp, then it may not so useful except me, or anyone else write a dhcp server by themself

even for our product, if the stable firmware being released without this format, then we should support current spec to let users running netboot without problem, it make the new format not necessary, we can not force the users re-flash their eeprom on a well running systems without any profit.

the decision is made by you now, it became a “better has” option, not "should have".

BTW: is gzipped kernel image support in current development plan?

[timg236]

Network boot will never be enabled by default in the bootloader EEPROM so and update to the bootloader config will always be required. The rpi-eeprom commands are easily scriptable so it would be easy to have packages / scripts for deploying Pis with custom configurations.

The Option97+60 changes would be in the first stable binary but I'd generally recommend using MAC addresses like piserver because that would work on earlier models.

The bootloader doesn't load the kernel, IIRC start.elf doesn't do the decompression because that would be slow on the VPU. Instead, the built-in decompression code in the kernel is used. I don't think that is likely to change.

[satmandu]

The bootloader doesn't load the kernel, IIRC start.elf doesn't do the decompression because that would be slow on the VPU. Instead, the built-in decompression code in the kernel is used. I don't think that is likely to change.

IIRC only the 32-bit arm Linux kernels support decompression of a zImage in the kernel. Ubuntu currently deals with this by using u-boot to check if a kernel is gzip-compressed, and decompressing the kernel before loading it on either armhf or arm64 with this script. So there is (perhaps) an argument for giving start.elf the ability to load a compressed kernel, as it would provide one more reason for avoiding u-boot.

[beldzhang]

Ok, I'm preparing a preview release recently based on current spec. hopefully can be done in a week.

Raspbian diskless netboot video

[timg236]

The Kernel decompression was previously discussed here. As @pelwell noted decompression on the VPU doesn't make sense, an ARM super stub would be much faster.
In theory start.elf + dtbs + config could be bundled together with super simple compression (due to limited code space in bootloader). That would also reduce round-trips looking for the existence of files. It's fairly low down on the list, the complicated bit is deciding what file to package because ideally the blob would contain the minimal set of files required.
Edit: Add the link again: raspberrypi/firmware#884

[beldzhang]

emmm, I provide some detail info about download speed
the server is running slackware linux x86-64, with a gigabit nic.
the list is only success download, lots of terminated and non-exists not shown.
BTW: 'config.txt' file was transfered 4 times ...

[18:17:13.056] TFTP:....2.0 KB,...60.5 KB/s, 10.10.1.41, config.txt
[18:17:14.655] TFTP:....2.7 MB,....1.7 MB/s, 10.10.1.41, start4.elf
[18:17:14.673] TFTP:....6.1 KB,..333.6 KB/s, 10.10.1.41, fixup4.dat
[18:17:14.852] TFTP:....2.0 KB,....1.5 MB/s, 10.10.1.41, config.txt
[18:17:14.894] TFTP:....2.0 KB,....1.6 MB/s, 10.10.1.41, config.txt
[18:17:15.792] TFTP:....2.0 MB,....4.7 MB/s, 10.10.1.41, rpi4-initrd.gz
[18:17:16.200] TFTP:...39.7 KB,..860.6 KB/s, 10.10.1.41, bcm2711-rpi-4-b.dtb
[18:17:16.703] TFTP:....2.0 KB,....1.1 MB/s, 10.10.1.41, config.txt
[18:17:16.821] TFTP:....1.2 KB,...24.5 KB/s, 10.10.1.41, overlays/vc4-fkms-v3d.dtbo
[18:17:17.159] TFTP:......93 B,..103.2 KB/s, 10.10.1.41, rpi4-cmdline.txt
[18:17:20.363] TFTP:....5.5 MB,....4.9 MB/s, 10.10.1.41, rpi4-vmlinuz

[timg236]

That looks correct, the firmware probes for the existence of files before loading them. The common firmware supports many Linux bootup variants

[lurch]

Also, I believe parts of config.txt are read by bootcode.bin, and parts of config.txt are read by start.elf (or start4.elf).

[beldzhang]

I make a preview version of our netboot diskless software
it can be download from here

[beldzhang]

Finally make a simple netboot server for RPi4, anyone interesting of this can get it [HERE]

• Single program include DHCP and TFTP server
• Easy config file
• Just copy files from SD card boot partition to tftp/ directory
• Support Raspbian (armv7l) and Debian 10 (aarch64)

by my experience, a real PXE service on port 4011 is not needed by 90%+ users.
and it not required by RPi4.

[beldzhang]

@timg236
since we already has a plan for this, I will close this issue.
once you done this part, I can have a try and open new issue if any problem.

is that ok?

[timg236]

Yep that's fine.