This project is submitted for

Description

The EEEmu SPI emulates any Serial Peripheral Interface Bus EEPROM or Flash memory chipsets up to an interface speed of 25MHz. It also supports any supply and interface voltage between 1.8 to 5 Volts and can be configured to support even the largest of memory sizes.

Details

The world's landfills are littered with old PC motherboards that have failed due to bad flashing, malware or rm /sys/firmware/efi/efivars/*. What if you could recover these boards easily or prevent it from happening all together?

The EEEmu SPI will allow you to do all of this and more. EEEmu SPI can:

Be connected to embedded or IoT platforms to allow them to perform easy datalogging and data storage functions.

Be used as an SPI sniffing and logging device.

Create custom SPI slave hardware.

Anything else you can imagine that requires a versatile high speed serial memory interface.

EEEmu SPI is easy to use as a simple drop in replacement for existing SPI EEPROM. It allows you to quickly and easily configure and load new EEPROM image files using a USB mass storage interface, to onboard storage. Deep configuration options allow you to tweak the operation easily to support any brand or sized EEPROM.

EEEmu SPI also provides additional 3.3V GPIO/I2C pins to allow you to hack the device to your heart's content.

Level conversion supports open drain (pull-up) or active modes. Dual power supplies allow you to power it from the USB or SPI interface (even at the same time).

EEEmu's software is also completely open source. It supports reprogramming via USB, so you can easily tweak the code to suit your application.

After Step 1, collect underpants, and the emulation code in the firmware is finalised, an initial run of these boards will be available for sale on tindie.com for developers and hobbyists. It is hoped that the community adds additional functionality to the open source firmware to create a robust and versatile EEPROM emulation platform.

All EEEmu code, documentation and design on these project pages are licensed under the GNU General Public License (GPL) unless otherwise stated.

I've been recently looking for a cheap supply of USB and SD card mounts/connectors to bring the costs of the board down (some SD card mounts from other manufacturers are a few dollars each even in large quantities). I found what seems to be a decent supplier of all different connector styles from 4UCON, however they took a while to send samples, because they normally do business in larger quantities. They eventually shipped and arrived in the end.

The only downside if that they don't have much in the way of datasheets, only that we can assume the plastic insulator is a Liquid Crystal Polymer (LCP) with a UL94V-0 flammability rating (with the 11071 connector being LCP with glass fiber).

So what sort of characteristics or tolerances do these connectors have under reflow conditions?

One of the main design constraints behind the EEEmu SPI is that it has the ability to emulate some of the faster Flash SPI chipset specifications to allow for BIOS Flash ROM emulation.

Enter the SAM4S. These 120MHz ARM based devices are capable of running with various programmable delays for flexible SPI compatibility and an SPI slave frequency of 25MHz. This speed is a reasonable compromise on price and performance and covers most use cases for embedded design.

These microcontrollers are no slouch when it comes to performing operations either. However this is not the only hurdle when designing such a system. The choice to allow users to store the ROM information on an SD card also brings about significant design considerations. SD cards by nature are a sector addressable device and cannot be read byte by byte like traditional EEPROM. So how do you get low latency performance out of a setup like this?

Firstly you must consider that the speed of the card plays a significant factor. So choosing the right card is crucial to getting decent performance. For testing, a card with a read write speed of 95MB/s has been chosen. This speed of card has been selected to allow the lowest reasonable latency while operating at higher SPI bus speeds. Secondly, we don't want to tie the CPU up with performing SPI and SD transactions. The good thing is these devices have their own SPI and HSMCI peripherals which do most of the work and provide data as registers when available. Once the hardware side of things is sorted, you then move onto software.

Initially through testing a sequential SPI read transaction from a ROM file, the system would take around 320us to read the next sector once the SPI interrupt requests byte information on the sector boundary (every 512 bytes). This was by no means good enough. The EEEmu sources use the Atmel ASF libraries to operate the SD Card, SPI interface and FAT(32) filesystem.

These libraries are "basic" and designed to run the demonstration application. A few tweaks are required to get them running the way you like. The first main issue with these libraries is that they will first do a check to see if the SD card is inserted. This first check has a massive timeout delay of a second to make sure the insertion has "debounced". Subsequent checks don't have this debounce delay however. So to speed things up on startup, this delay is removed on the first check only and if the card is removed while running, the check will be performed again. It turns out they also had several nested redundant checks (4) to see if the SD card was still inserted and operational on every byte read, even if it was reading from the FAT library’s sector buffer.

Once fixed, the performance was much, much better, but still not good enough for 25MHz. To operate a byte addressable ROM format, you must tell these FAT libraries to perform an f_lseek operation to access the byte you are looking for. Unfortunately this seeking is a little slow, even if it’s from the sector buffer. So you have to put statefulness procedures in there to check if the next byte to read is the byte being requested and to ignore the use of f_lseek (note that on each byte read operation, the byte pointer moves to the next byte for the next read).

After all of this, we bring the read latency on a sector boundary down to around 10us or less (with no perceivable latency on a next byte read). While a whole lot faster than 320us, it can still be much better (for example for loading BIOS program data), considering we want operate up to an SPI data rate of 25MHz.

Enter the Buffer

One thing these embedded FAT libraries lack is decent buffering. This is due to the fact they are designed to operate within small memory restrictions and multitasking is difficult on smaller microcontrollers. Well the SAM4S has a fair bit of memory, so why not use it?

Well we don’t want to use it all because we will want a large buffer for optimal write operations and RTOS task stacks, so let’s get smart...

As a first post, I just wanted to give an update on where the EEEmu SPI development currently is.

I started designing this project around the end of February this year after I became frustrated with having to manually re-flash 20 out of warranty server BIOSes. These machines needed updating to work with some specific PCI-e hardware, and unfortunately they would brick after a software based flash. Pulling the ROM, manually flashing, then re-inserting worked, so it wasn't a firmware issue. Since the manufacturer was less than helpful, other than to suggest to RMA them, I wondered how I could provide a quick, easy and software-less update method to prevent this issue from ever occurring.

Development of the first prototype board then started in March. Things have progressed rapidly since then and I hope to have everything on the prototype fully operational by mid May. From there, a new revision of the hardware should be finished and I will start producing the first batches of boards after testing.

This project has been designed to be produced easily on a smaller scale. I now also have the capability to build small batches myself (about 100/day). The plan is to have these boards available on Tindie as soon as they are ready.

So onto the current status. All the code for the USB mass storage, SD card, configuration files and SPI is currently operational. The emulation code is still being worked on as I want it to be as flexible and easy to use as possible. Code will be made available once this and the firmware bootloader is finalised.

The hardware on the prototype is also fully working. The dual power supplies work under all conditions without fault. The level conversion works as expected with different voltages (1.8-5V) and the SPI works well at 25MHz:

Testing SPI reads from a ROM file stored on the SD card with a Teensy 3.2 @ 25MHz

Connecting the Teensy to the EEEmu SPI is easy:

Everything is coming together quite nicely without too many issues. I did have a minor one which "bricks" the ATSAM4S2B MCU. When entering a certain sleep state, the system controller switches off the internal 1.2V regulator, which then powers off the ARM core and prevents it from being programmed afterwards. There is a flash erase pin that you can bring high on startup for 10 seconds to erase the flash, but this is a frustrating design decision made by Atmel/Microchip.

Hihi, I made a version of the Arduino core for the SAM4S4A a while back, ( it snot in Arduino 1.5x format so one can't use it via boards manager yet ) but if you shove the files in arduino/hardware ( windows ) then you should be able to compile for it, or use this as a starting point if you are ever interested in "Arduino IDE and API " for the EEEMu

Did you consider that a lot of current PC motherboards use Quad SPI to connect to their BIOS flash ic? I'm missing the WP and Hold lines usually used for that. Also all 4 data lines are bidirectional for Quad SPI, so you can't use unidirectional level shifters.

For most newer boards I'm considering a "pro" version of this board that would support things like that. The speed that this supports probably wouldn't work with much newer boards as well so the pro version would support higher speeds. But this is a great way to get the emulation code underway and be useful for developers and older hardware.

I hope to have this available for purchase on tindie in the not too distant future (hopefully end of May). I'm still working out a few things with the emulation code (USB/SD/configuration all currently work) as well as the end user flashing to make it reliable for people to make code changes. I will be looking for a few people to test it out first too if you are interested.

There isn't too much from the user side as I tried to design it as a standalone device (once configured). All configuration is done through a config file that is placed on the SD card. The only thing I really need to do is make a generator that creates configs for different EEPROM devices. I plan to support everything that is on the flashrom site first as it's an easy go-to list, then there'll be more to come later. I'll have a way for users to submit working configs too. As for debugging/sniffing, there's two options, the first is to just dump SPI transactions to SD storage, the second will allow you to see these as debug statements over USB. As to how this is visualised, I'll look into this down the track as it can be a massive amount of data for the eyes to ingest.