Added firmware information to web interface header #69
Conversation
- Added firmware information to web interface header - Slightly modified header markup
- Changed home link (gokrazy) to use the native `navbar-brand` class resulting in improved spacing when hitting the xs viewport breakpoint. - Manually defined height of `navbar-brand` element as multiple lines do not seem to be supported by default. This prevents to header from resizing when hitting the xs viewport breakpoint.
status.go
Outdated
| vendor := mustReadFile0("/sys/class/dmi/id/bios_vendor") | ||
| version := mustReadFile0("/sys/class/dmi/id/bios_version") | ||
| date := mustReadFile0("/sys/class/dmi/id/bios_date") | ||
| if vendor == "" || version == "" || date == "" { |
There was a problem hiding this comment.
Instead of not displaying anything when any part is missing, I think it might be nice to display as much as we can. That way, the code works better on platforms we can’t test yet.
There was a problem hiding this comment.
Fair point, fully agreed. I will change this accordingly
If it is available, it’d need to be in the device tree. If it’s not in there, maybe the firmware doesn’t actually expose a version. |
If I remember correctly I already searched the device tree for firmware information. I will have a second look... |
I now had the time to investigate more about the Raspberry Pi firmware version: Coming from the router7 setup, what I intended to describe by the "firmware" was the bootloader and it's version. In case of my router7 running on the apu2e4, this is "coreboot". On the Raspberry Pi, the bootloader seems to be built into the GPU and is non-updateable (see https://wiki.ubuntu.com/ARM/RaspberryPi#Create_a_partition_with_pi_firmware.2Fbootloader_files). If I understand correctly, both bootloader then start loading a boot payload. In case of the apu2e4, the payload is a version of SeaBIOS stored in an on-board flash chip. In case of the Raspberry Pi below Model 4, the payload is stored in the As a consequence, I think my choice of the word "firmware" might have been a bad decision. We might be better of using the word "bootloader" and show this information only on the apu2e4, as the bootloader on the Raspberry Pi will not change. What changes thought is the boot payload, which has already been taken care of with the "EEPROM" information. Please let me know about your thoughts on this. |
The firmware information in the web interface header now shows any details available (vendor, version, date) instead of showing nothing in the case not all details are present.
| {{ if .EEPROM }} | ||
| <tr> | ||
| <th>EEPROM<br>(SHA256)</th> | ||
| <td>{{ shortenSHA256 .EEPROM.PieepromSHA256 }}<br>{{ shortenSHA256 .EEPROM.VL805SHA256 }}</td> |
There was a problem hiding this comment.
Can you add “(EEPROM)” and “(VL805)” respectively, so that it’s more clear what these digests are referring to please?
Sounds good to me! |
|
I think this would be handy, glancing at the UI and finding out the firmware version seems useful and would have helped me also recently figuring out a certain firmware bump was breaking my build. |
This PR implements #68 (Option 3). It also includes some minor styling improvements of the web interface header.
Unfortunately I was not able to find out how to retrieve the firmware version on the raspi3b. Any support on this is more than welcome.
Testing
This PR has been tested on the following devices:
Follow up
While working on this feature I noticed that the apu2c4|raspi3b(+) firmware version and the raspi4b EEPROM version describe the same type of information (at least to my understanding of what a firmware is). As such, we could think about merging the two firmware information retrieval strategies into a single one with conditionals. As of now, on the raspi4b the firmware version is expected to be empty and the EEPROM version to be populated, so the header looks already pretty much the same except for the different wording.