System call wrappers for flash access

[mchack-work]

With an SPI master on some TKey versions (tillitis/tillitis-key1#213) we need some easy way of accessing SPI and the flash chip.

We will probably create a new library, something like libspi.a, and include it in tkey-libs.

[dehanj]

As you say we should have a lib for the SPI API.
How should we handle the API for the flash memory? Should it be part of tkey-libs? Live outside of tkey-libs?

[mchack-work]

I think all the addresses needed to access the SPI should be included in tk1_mem.h, as per usual. I don't think they should be optionally compiled. Instead, I think we want some way to detect during runtime if the SPI master is enabled on the running hardware or not.

I propose low-level functions to use the actual SPI access addresses should be included in libspi.a, as well as higher level functions that are easily used by a developer to access the flash.

[dehanj]

Agree, no optional building. It will be removed during linking if not used.

To summaries:
We want both the low-level functions such as
spi_read(..)
as well as the high level flash access functions, such as
flash_get_manufacturing_id(..)
in libspi.a
Do I interpret you right?

[mchack-work]

You could, I guess, argue that flash_* should live in a separate libflash.a that depends on functions in a libspi.a. I don't have any strong opinion if this is good or bad right now.

[mchack-work]

Since the firmware is getting flash handling (see tillitis/tillitis-key1#275) the tkey-libs functions will basically just become syscall wrappers, a bit of inline assembly that sets up to call the firmware.