Image credit: Alpha Omega.
Problem
The „AlphaRS” hardware is a separate entity, it receives power from its own mains adapter, and the connection between the „AlphaRS” and the user’s computer is via Ethernet. Consequentially, the hardware can be switched off or on while the user’s computer is working. Since the firmware for the hardware is not saved in the flash memory of the hardware itself, it has to be copied to the DSP every time the hardware is switched on.
The reason for not saving the code on the hardware is quite simple. In case of bugfixes or new versions of the firmware, we can send the binary to the customer, and on the next boot the firmware will be updated automatically, without the need for the customer to learn cumbersome flashing procedure. And — it greatly eases the debugging.
The copying was achieved using stock network bootloader for the DSP, as provided by Texas Instruments. It transferred the binary file (which was ~12 MB in size) from the predefined location in the computer’s filesystem to the DSP, unpacked it, copied the firmware for each of the cores to the core’s code memory section, set the instruction pointer of every core to the c_int00() address and started the boot image execution, as described in this document.
However, the process could take minutes. And it was expected that the device will be online in seconds after being powered on. And I achieved it.
Solution
At first, I thoroughly learned the Ethernet Boot procedure.
In short, the Ethernet Boot means that the device which asks for firmware initializes the Ethernet interface and starts sending a standard BOOTP request, meaning literally „Please someone boot me, my address is <MAC address of the Ethernet interface>”. The request is broadcasted to the whole subnet, and is repeated every several seconds.
The UI on the user’s computer knows the MAC address of the hardware, therefore, until the connection is established, it performs polling: it listens to the network traffic and filters it with npcap. When the BOOTP request packet with the hardware’s MAC address is detected, the UI starts its own procedure: it sends the TCP/IP configuration to the hardware and adds its own address as the BOOTP server. Then the hardware initializes TCP/IP connection to the user’s computer and politely asks for the precompiled firmware binary.
I made few assumptions:
- The connection between the user’s computer and the „AlphaRS” hardware is direct and wired, using a single Ethernet cable. (Actually, that was a requirement).
- The connection is established via IPv4.
- The user will rarely detach the networking cable that connects his computer with the „AlphaRS” hardware.
Then I studied the npcap filtering setup in the UI.
I found out that upon loading of the UI, the program created a list of all network devices that are defined in Windows, and passed over them one by one, configuring „npcap” filter to search for the BOOTP request with the MAC address of the hardware (which is known in advance) in all data captured from a specific network device. For each of the devices, it listens for one second, and if the BOOTP request was not detected, it moves on to the next device. This loop goes on and on, until BOOTP request is detected at one of the devices.
The list of the network devices can be quite long, even if the number of physical NICs in the system is low. But not every NIC can be connected to the „AlphaRS” hardware. For example, the loopback device will never receive the BOOTP request, so it can be safely omitted. All devices listed as „Wireless” can be omitted as well. Last but not least, all devices listed as „Virtual” or „Bridge” also can be omitted. That can greatly reduce the number of devices to be listened to, — from as much as 27 to as low as 3 or 4.
The last assumption led to the idea that I should save the device that was used to connect to the „AlphaRS” hardware and start with it next time. If the user did connect the hardware to another Ethernet device in the computer, I will lose a few seconds listening to the wrong device, — not a big deal. But if the hardware was not detached from the computer, — which is likely the case, — I can save tens of seconds.
Additionally, I have reviewed the code that sets up the „npcap” filter and found out that it listens to the network traffic only for one second, while BOOTP request is sent every 3 seconds. That led to many cases of „false negative” detection, when the BOOTP packet was omitted just because the UI didn’t listen to the correct device long enough. I increased the listening time to 4 seconds.
That solved the problem. In vast majority of cases, the hardware started booting immediately after being turned on. If it was connected to another NIC, it was picked up after 4 seconds. The possibility of a neurosurgeon having more than 3 physical NICs in his desktop is negligible.
Result
The boot time of „AlphaRS” hardware was reduced from 3-5 minutes in worst case to 3-5 seconds in worst case.