.. _hack_uefi_not_useless:

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:

.. code-block:: none

	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*