Advanced users • Re: HTTP boot mode boot.img reference design

Hello timg236,

Thanks for again for your quick answer. I was not aware of AON reset registers, but I am not sure it would really suit my use cases.

I followed option A) I mentioned earlier.

I successfully compiled your rpi-system-update project (https://github.com/timg236/rpi-system-update), enabled ssh (after removing some unnecessary packages because the limit of 96MB was already almost reached with default settings), and tried as root to do a simple download image and write it to local disk ($curl -s http://x.y.z.a/image | dd of=/dev/sda bs=1M). Next from the HTTP boot server, I disabled the availability of the boot.sig file, in order for the next reboot to directly use the filesystem on my /dev/sda USB drive that is configured as secondary boot method.

Regarding the eeprom config, I can use a static one (no udpate needed after each re-image process):
[all]
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
BOOT_ORDER=0xf147
HTTP_HOST=x.y.z.a
HTTP_PATH={pi_serial_number}
NET_INSTALL_ENABLED=0
ENABLE_SELF_UPDATE=1

In my original option A) wishes, I wanted to extract the {pi_serial_number} from the HTTP request headers from the HTTP BOOT mode, but it is not present in headers, so I switched to using a dedicated HTTP_PATH per raspberry, using the pi_serial_number as path, in order to control remotely per device if the HTTP boot method will proceed or not (cf disabling availability of boot.img or boot.sig file).

I am fully happy with this method, the only small downside is the longer reboot process introduced with the HTTP BOOT mode that will be evaluated every time, we we are just talking about few seconds wasted.

Thanks again for your answers, it helped a lot !

Statistics: Posted by DarkoM — Tue Nov 12, 2024 2:06 pm

---