Hello Raspberry Pi Team,
I have been testing the network boot feature in your latest bootloader (pieeprom-2020-01-17.bin) with some success, though the experience has been far from smooth. Of course, all of this is expected since it is beta functionality, and accordingly, please find below my feedback.
beldzhang wrote: ↑
Tue Jan 14, 2020 6:46 am1) in DHCP requests:
other than the MAC address, there is no any field to identify a RPi client,
I noticed this as well, and it is not especially convenient. Raspberry Pi devices emit the same DHCP option 60 payload as common x86 PXE PCs, preventing the use of vendor-specific options in the manner which they were intended: to service a particular class of clients. MAC address tagging appears to be the only way at the moment to readily identify Raspberry Pi devices, and it is worth noting that not all DHCP environments make this functionality readily accessible.
There is a related, yet still distinct matter: configuring individual Raspberry Pi devices with unique parameters. The existing TFTP_PREFIX and TFTP_PREFIX_STR bootloader options achieve this in a rudimentary fashion (i.e., at the expense of maintaining a collection of board-specific files on the server), but are still less convenient than network bootloader environments like U-Boot and iPXE where configuration elements such as kernel command lines can be assembled at runtime from various data elements.
I realize that U-Boot or iPXE will likely never find their way into the Raspberry Pi 4 boot EEPROM based on size alone, but hopefully some day soon this will be easier, either because of enhancements in the Raspberry Pi 4 bootloader, or through chain loading of U-Boot and/or iPXE. As of this writing, network functionality for the Raspberry Pi 4 in both U-Boot and iPXE appears to be incomplete.
beldzhang wrote: ↑
Tue Jan 14, 2020 6:46 am4) TFTP download files
blocksize is 1024, could be larger?
is there any future plan to implement windowsize ? since start.elf / kernel / initrd are big, set windowsize > 1 to speed up downloading.
I have also found the TFTP performance of the Raspberry Pi 4 bootloader to be rather slow, at least in comparison to my reference environment (U-Boot 2018.07 on i.MX6) which claims 10.3 MiB/s for both kernel and initramfs downloads. Part of this is definitely related to block size: Raspberry Pi uses blocksize=1024 whereas my reference device uses blocksize=1468.
In addition I have observed two other anomalies related to the Raspberry Pi 4 TFTP download implementation.
First, my TCP Dump captures show numerous unacknowledged TFTP data packets from the server (Synology's clearly patched "TFTP Server SinglePort Version 1.66"). I do not observe any such unacknowledged packets TFTP data packets with the reference device.
Secondly, the Raspberry Pi occasionally fails to boot from the network, hanging either after "Starting start4.elf" or just before mounting the root filesystem. In the latter case a console message similar to the following is displayed:
Code: Select all
[ 7.548926] RAMDISK: gzip image found at block 0
[ 7.674065] RAMDISK: incomplete write (19060 != 32768)
I see no boot issues with the reference device, and no issues with network connectivity under Linux on either. Can you offer any suggestions as to what might be going wrong?