u-boot/board/sandbox/sandbox
Mike Frysinger ffdb20bea1 sandbox: spi: Add new SPI flash driver
This adds a SPI flash driver which simulates SPI flash clients.
Currently supports the bare min that U-Boot requires: you can
probe, read, erase, and write.  Should be easy to extend to make
it behave more exactly like a real SPI flash, but this is good
enough to merge now.

sjg@chromium.org added a README and tidied up code a little.
Added a required map_sysmem() for sandbox.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
2013-12-09 12:22:39 -07:00
..
Makefile sandbox: convert makefiles to Kbuild style 2013-10-31 13:26:44 -04:00
README.sandbox sandbox: spi: Add new SPI flash driver 2013-12-09 12:22:39 -07:00
sandbox.c sandbox: convert to common time functions 2013-11-08 15:25:14 -05:00

/*
 * Copyright (c) 2011 The Chromium OS Authors.
 *
 * SPDX-License-Identifier:	GPL-2.0+
 */

Native Execution of U-Boot
==========================

The 'sandbox' architecture is designed to allow U-Boot to run under Linux on
almost any hardware. To achieve this it builds U-Boot (so far as possible)
as a normal C application with a main() and normal C libraries.

All of U-Boot's architecture-specific code therefore cannot be built as part
of the sandbox U-Boot. The purpose of running U-Boot under Linux is to test
all the generic code, not specific to any one architecture. The idea is to
create unit tests which we can run to test this upper level code.

CONFIG_SANDBOX is defined when building a native board.

The chosen vendor and board names are also 'sandbox', so there is a single
board in board/sandbox/sandbox.

CONFIG_SANDBOX_BIG_ENDIAN should be defined when running on big-endian
machines.

Note that standalone/API support is not available at present.

The serial driver is a very simple implementation which reads and writes to
the console. It does not set the terminal into raw mode, so cursor keys and
history will not work yet.


SPI Emulation
-------------

Sandbox supports SPI and SPI flash emulation.

This is controlled by the spi_sf argument, the format of which is:

   bus:cs:device:file

   bus    - SPI bus number
   cs     - SPI chip select number
   device - SPI device emulation name
   file   - File on disk containing the data

For example:

 dd if=/dev/zero of=spi.bin bs=1M count=4
 ./u-boot --spi_sf 0:0:M25P16:spi.bin

With this setup you can issue SPI flash commands as normal:

=>sf probe
SF: Detected M25P16 with page size 64 KiB, total 2 MiB
=>sf read 0 0 10000
SF: 65536 bytes @ 0x0 Read: OK
=>

Since this is a full SPI emulation (rather than just flash), you can
also use low-level SPI commands:

=>sspi 0:0 32 9f
FF202015

This is issuing a READ_ID command and getting back 20 (ST Micro) part
0x2015 (the M25P16).

Drivers are connected to a particular bus/cs using sandbox's state
structure (see the 'spi' member). A set of operations must be provided
for each driver.


Configuration settings for the curious are:

CONFIG_SANDBOX_SPI_MAX_BUS
	The maximum number of SPI buses supported by the driver (default 1).

CONFIG_SANDBOX_SPI_MAX_CS
	The maximum number of chip selects supported by the driver
	(default 10).

CONFIG_SPI_IDLE_VAL
	The idle value on the SPI bus


Tests
-----

So far we have no tests, but when we do these will be documented here.