UEFI is not (entirely) useless

The ultimate summary of Intels engineering philosophy seems to be overengineering: ACPI adds a quarter of a million lines of code to the FreeBSD kernel, that is ten times more lines of code than all of Lua 5.3.

They could have created ACPI on top of Lua, and it would probably have worked better sooner, but nope, not Intel.

Another complicated mess from Intel is UEFI.

Again, pretty much the same story: They could have taken an existing codebase and worked from there, but no-o-oh! We’re Intel, that would not be nearly complex enough.

Imagine therefore my delight when I found an actual case where UEFI allowed me to solve an actual real-world problem.

Avoiding Ultima Thule

So there is this FreeBSD box, which is at a very distant, and most of the year almost inaccessible remote location, where it keeps an eye on something which really bears watching. It would be utterly silly for somebody to have to go out there, just to push a button or power-cycle something, and the FreeBSD box is there to prevent that, if at all possible.

Which brings us to “Qui custodiet ipsos custodes?”: Who looks after the FreeBSD box ?

Amongst other things, the hardware watchdog does.

Normally the watchdog is not armed until the FreeBSD kernel has loaded, from one of several possible and different storage media.

I would like to arm it before we try to load FreeBSD, so that if the loader or the kernel hangs, another attempt will be made.

On the current hardware, I did a binary patch to th BIOS.

The next campaign will upgrade the station and we are busy prototyping.

UEFI Shell

The embedded computer I am testing, has an option to boot UEFI Shell instead of any particular disk.

The UEFI shell is a small CLI built into the BIOS, so it will supposedly come up, even if all the storage media do not.

More importantly, it will look for a startup.nsh script to run at boot.

The ‘MM’ command of the UEFI shell allows you to read and write pretty much any address-space of the system, which is precisely what I need:

MM 4e ;IO :87 -n
MM 4e ;IO :87 -n

MM 4e ;IO :20 -n
MM 4f ;IO -n
MM 4e ;IO :21 -n
MM 4f ;IO -n

MM 4e ;IO :23 -n
MM 4f ;IO -n
MM 4e ;IO :24 -n
MM 4f ;IO -n

MM 4e ;IO :07 -n
MM 4f ;IO :07 -n

[...]

BOOTx64.efi

The full sequence of pokery gives FreeBSD 10 minutes to get its shit together and WDIOCPATPAT() the watchdog, otherwise the box resets and tries again.

That is actually not entirely useless…

phk