MB85RSxx FRAM bringup

[hawkw]

This branch adds an initial implementation of a driver for the Fujitsu
MB85xx series of ferroelectric RAM (FRAM) devices, as seen in Power
Shelf Controller rev C boards. The FRAM chip is a SPI device with a
fairly simple protocol, detailed in the Fujitsu datasheet. It also
has additional pins for toggling the write protection feature (which can
also be controlled over SPI) and a "hold" pin to maintain a read/write
transaction when CS is deasserted, but my driver doesn't currently use
those pins because we don't really need them.

I've also included a simple demo task which writes some data to a FRAM
device and checks whether it can be read back. Eventually, I'd like to
replace this with a more general-purpose "read the contents of the FRAM"
task that can be used for debugging purposes, but I've left it as is for
now in the interests of getting the driver implementation ready to
merge. I'll revisit this later.

[aapoalas]

I'm not sure if outside reviews are welcome here: My apologies if I'm just being a nuisance.

I just wanted to say that this was really nice and easy to read, and all the code looked good to me.

[hawkw]

ah, thanks --- good catch!

[hawkw]

I just wanted to say that this was really nice and easy to read, and all the code looked good to me.

Thanks! I try :)

[cbiffle]

Huuuuuh. So, this can work, but it's an unexpected use for locking the SPI controller (unexpected to me, anyway). You're basically using it to fake scatter/gather.

I can't really recommend a better approach right now, but this suggests to me that the SPI API wants to be extended to do scatter-gather like the I2C API has.

[hawkw]

This comment in the SPI API implied to me that the lock operation was intended to be used this way:

hubris/drv/spi-api/src/lib.rs

Lines 217 to 222 in acd41c7

	/// `assert_cs` can be used to force CS into the asserted (low) state, or
	/// keep it deasserted. If you choose to assert it, then SPI transactions
	/// via `read`/`write`/`exchange` will leave it asserted rather than
	/// toggling it. You can call `lock` while the SPI controller is locked (by
	/// you) to alter CS state, either to toggle it on its own, or to enable
	/// per-transaction CS control again.

But, you're right that support for a scatter-gather type API would be nice --- in particular, it would let us avoid an IPC roundtrip in between writing the command and the data, etc.

[hawkw]

Okay, @cbiffle, I think that I've addressed all your feedback --- let me know what you think!