u-boot/board/sandbox/sandbox
Darwin Rambo de351d6be6 lib: time: add weak timer_init() function
If timer_init() is made a weak stub function, then it allows us to
remove several empty timer_init functions for those boards that
already have a timer initialized when u-boot starts. Architectures
that use the timer framework may also remove the need for timer.c.

Signed-off-by: Darwin Rambo <drambo@broadcom.com>
Reviewed-by: Tim Kryger <tim.kryger@linaro.org>
2014-01-24 16:59:06 -05: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 lib: time: add weak timer_init() function 2014-01-24 16:59:06 -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.