Up until now, U-boot would only support the User datagram protocol (UDP) allowing for TFTP and NFS boot, but Linaro has now added support for TCP and HTTP in U-boot in order to boot Linux from common web servers.
TFTP boot from U-boot has been supported for years, as around the year 2006 I remember implementing TFTP Linux boot for a Karaoke system in order to lower the BoM cost by selecting a smaller flash device, and I also explained how to boot Linux on a TV box with TFTP back in 2014. This requires installing a TFTP server on your server, which is quite a trivial task, but HTTP servers are omnipresent, so it’s a welcome addition to U-boot.
If you want to use HTTP to boot Linux, it needs to be enabled in the U-boot config:
|
1 2 3 |
CONFIG_PROT_TCP=y CONFIG_PROT_TCP_SACK=y CONFIG_CMD_WGET=y |
The top and bottom options are pretty obvious, and the second config enables Selective Acknowledgment (SACK) for maximum performance of the TCP protocol.
Once you have installed an HTTP server in the server hosting the Linux image, you can boot Linux on the target device running U-boot as follows:
|
1 2 3 |
setenv autoload 0;dhcp setenv serverip 192.168.0.1 wget $loadaddr ~/vmlinuz |
Alternatively, it is also possible to load Linux with a single command line after an IP address is acquired through DHCP:
|
1 |
wget $loadaddr 192.168.0.1:~/vmlinuz |
The advantage of using HTTP over TFTP is limited, but that’s just the start of the work done as part of the Arm SystemReady project, as Linaro plans to implement HTTPS support and eventually integrate it with UEFI HTTP boot in order to allow U-boot to have a standardized and secure way to download boot images from a web server.
Via the Linaro Blog
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
That’s really cool. It will allow u-boot to fetch images remotely, and possibly that some vendors will start to pre-configure rescure *URLs* in their boot loaders.
We’re already seeing some companies like Hardkernel preconfiguring u-boot to support extlinux out of the box, meaning that you can come with an SD having just an extlinux directory, an extlinux.conf file, a kernel, possibly an initrd and a device tree, and this SD will be bootable without having to fiddle with the boot loader’s config at all. So suddenly you’re getting a generic boot mechanism that could be portable across systems. The option described above just pushes the concept of portable boot a bit further. We need to continue to improve standard and portable boot methods on ARM boards.
well this extlinux support is in fact made (and recommended) by U-Boot itself, not Hardkernel.
I know it’s made and provided by u-boot, but it’s only very recently that I saw it enabled (and I think my odroid-m1 was the first board I saw it enabled on).
There is huge benefit for this I think.
TFTP use UDP. So there isn’t any integrity checking for data you downloaded
In fact it’s not related to UDP, as there is no more and no less integrity than with TCP, everything relies on the 16-bit layer4 checkup (UDP checksum or TCP checksum), so that’s exactly the same for both. The real difference is that TFTP like the vast majority of UDP-based services is a crappy protocol that involves a separate channel for data transfer that requires specific connection tracking and NAT in devices that are crossed, and that makes it totally unsuitable to use over the internet. In addition by default it uses tiny windows of a single packet, meaning it’s extremely sensitive to latency. Those who have tried to use it over an ethernet-to-wifi bridge probably remember it, you usually see the sharps slowly progress on your terminal! With HTTP over TCP you can have larger windows and you don’t need any specific tracking for a data channel, so the protocol is more WAN-friendly.
What iIwould really like is the ability to have 1 device fill multiple roles and the ability to choose what is booting over the network each boot. For me this would be ideal and not have to keep track of sd cards.
Another point is that I suspect it will permit to download scripts or config snippets that can be sourced locally, hence that’s the beginning of easier deployments. We can even imagine web application servers producing these configs on the fly based on a few arguments passed in the request, the IP or MAC address, etc.
Ipxe has those scripts i believe. I played with booting over http with ipxe like 10 years ago.
This is a horrible trend. I can see manufacturers making devices that boot remotely and cut your device off if your subscription expires.
“Please register your fridge with us before you can use it.”
At least before the device had to have an image of some sort that one can persuade to cooperate.
With this it can be all remote, nothing for you to hack.
It’s more or less the case with all the IoT crap sold in shops nowadays. The lamp you use with your google home or alexa was registered at ITTT by its ephemeral vendor and if they don’t renew the subscription you suddenly can’t control it anymore.
There is a difference. If the vendor does not renew the ITTT subscription, I wont be able to control the device remotely, but it will still turn on and off. If Im determined, I can modify its firmware.
With this the device won’t even boot once the vendor is gone.
We have had PXE network boot for a long, long time on X86 and did it happen?
Its choice for specialised solutions often for rollout on site where a single update is done once for the whole network.
Its main uses are likely not as you say as battering the bandwidth of there servers is an extra cost.
Great addition for certain use.
Big problem with PXE was it lacked DHCP. You had to configure each PC, and configure a server.
Now so long as you have Ethernet, you have the ability to boot from a URL in Uboot, which can be pre-cached.
This is a game changer, though it will take 2-4 years before mass market devices hook into it.
The initial ramifications will be every Linux-based OS can now have a built-in recovery mode, so if the internal storage isn’t working, and there’s Ethernet, there will be a user-friendly environment.
Not to be too hard on u-boot but feeding it random garbage from untrustable sources is the last thing you want to do IMHO 😀