Thoughts about hardware

NOTE: This section is in early draft phase.

These may end-up being broken down into their own sub-pages, and this page will be edited without a public history (for now).

This page collects some often repeated opinions and thoughts about hardware. These may change over time, these are not absolutes.

About SBCs

Platform firmware storage

All general-purpose computing systems should come with dedicated storage for the platform firmware.

The exact storage type is left unspecified, but generally that means SPI flash.

The SPI Flash size should be big enough to allow load of rooms to grow features, as needed. A good ballpark figure these days is 128Mbit (16MiB). Since this is for general-purpose, the user should have an affordance to be able to experiment with schemes, ideas and shenanigans.

Why is this important? So boot becomes boring.

With a dedicated area for the platform firmware, one can erase the operating system drive, and still have the system start to a useful interface, that is likely more featured than what the Boot ROM provides.

The main idea here is that you can stash a platform firmware that boots using standards-based boot methods (e.g. UEFI) and then treat it mostly like you would another boring old computer. Shove a USB drive with the generic UEFI iso of your favourite distro, and just install it to any other storage medium.

Add an "EC" in control of the system

Yes, it's expensive, and another moving part you don't outright need.

BUT, it is extremely useful for end-users, depending on what it does.

For example, having an EC mediating the platform firmware may allow storing A/B images of the platform firmware in the SPI flash, since the EC could, for example, read one of two "packages" saved in SPI when the AP (SoC) is reading, instead of passing reads through.

Another example use-case, more useful for phones, tablets or laptops made from SBC-class parts, is to mediate special "NMI" key combos. Let's take the example of a laptop, you can make it so a give three-finger salute (e.g. ESC+F3+Power) forces resets everythin on the board.

Another thing it would be able to do is provide software control for some hardware features, like enabling/disabling internal storage (eMMC), which may or may not be tied to key presses.

A good example to follow through from is the GSC in ChromeOS devices. Another notable example is the MCU in VIM 3, 3L and 4 from Khadas.

Signs of life

All SBCs and SBC-like hardware should:

Why? So when you apply power you can see one LED light-up ASAP. This way you know that the hardware is being powered-on, and the next stage of startup is hopefully happening. This is important when there is no proper "platform firmware" read, and it might be hanging in some mode (e.g. "maskrom mode") waiting for tethered upload of something.

The next stage of startup should ASAP turn on another LED/change colour to show it is running.

Assuming we're now at the OS boot stage, the OS should itself handle turning off/on LEDs to correctly expose that it is now in charge.

So, assuming an RGB LED, a good flow could be:

Ideally, though, it would have a discrete LED for power being applied, but some designs (e.g. phones) can't really have that. Why? Because in this example it means we can't exactly rely on the blue LED for other statuses, as it gets overloaded into being the "powered-on" state.

I suppose an alternative is to have the three colours reversed (hardware default on)

It removes some of the overloaded semantics, as it can be assumed that "all LEDs on" during early startup means no driver was able to take over and handle them.

About RISC-V

RISC-V will solve the user-facing problems of ARM

No, RISC-V SBCs will almost assuredly definitely not solve them.

The main one I have in mind is the boot issues that "ARM" is well-known for. For that, see Non-Wintel Boot