2019-07-18 07:34:33 +00:00
|
|
|
.. SPDX-License-Identifier: GPL-2.0+ */
|
|
|
|
.. Copyright (c) 2014 The Chromium OS Authors.
|
|
|
|
.. sectionauthor:: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
Sandbox
|
|
|
|
=======
|
2011-10-10 08:22:14 +00:00
|
|
|
|
|
|
|
Native Execution of U-Boot
|
2019-07-18 07:34:33 +00:00
|
|
|
--------------------------
|
2011-10-10 08:22:14 +00:00
|
|
|
|
|
|
|
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.
|
|
|
|
|
2021-03-08 00:35:16 +00:00
|
|
|
Sandbox allows development of many types of new features in a traditional way,
|
|
|
|
rather than needing to test each iteration on real hardware. Many U-Boot
|
|
|
|
features were developed on sandbox, including the core driver model, most
|
|
|
|
uclasses, verified boot, bloblist, logging and dozens of others. Sandbox has
|
|
|
|
enabled many large-scale code refactors as well.
|
|
|
|
|
2011-10-10 08:22:14 +00:00
|
|
|
CONFIG_SANDBOX is defined when building a native board.
|
|
|
|
|
2014-09-23 19:05:59 +00:00
|
|
|
The board name is 'sandbox' but the vendor name is unset, so there is a
|
|
|
|
single board in board/sandbox.
|
2011-10-10 08:22:14 +00:00
|
|
|
|
|
|
|
CONFIG_SANDBOX_BIG_ENDIAN should be defined when running on big-endian
|
|
|
|
machines.
|
|
|
|
|
2018-02-12 07:05:57 +00:00
|
|
|
There are two versions of the sandbox: One using 32-bit-wide integers, and one
|
|
|
|
using 64-bit-wide integers. The 32-bit version can be build and run on either
|
|
|
|
32 or 64-bit hosts by either selecting or deselecting CONFIG_SANDBOX_32BIT; by
|
|
|
|
default, the sandbox it built for a 32-bit host. The sandbox using 64-bit-wide
|
|
|
|
integers can only be built on 64-bit hosts.
|
2017-08-01 23:33:34 +00:00
|
|
|
|
2011-10-10 08:22:14 +00:00
|
|
|
Note that standalone/API support is not available at present.
|
|
|
|
|
2014-03-22 23:12:59 +00:00
|
|
|
|
2020-03-18 15:42:39 +00:00
|
|
|
Prerequisites
|
|
|
|
-------------
|
|
|
|
|
2021-07-18 20:14:24 +00:00
|
|
|
Install the dependencies noted in :doc:`../build/gcc`.
|
2020-03-18 15:42:39 +00:00
|
|
|
|
|
|
|
|
2014-03-22 23:12:59 +00:00
|
|
|
Basic Operation
|
|
|
|
---------------
|
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
To run sandbox U-Boot use something like::
|
2014-03-22 23:12:59 +00:00
|
|
|
|
2014-08-31 15:49:43 +00:00
|
|
|
make sandbox_defconfig all
|
2014-03-22 23:12:59 +00:00
|
|
|
./u-boot
|
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
Note: If you get errors about 'sdl-config: Command not found' you may need to
|
2020-02-03 14:36:12 +00:00
|
|
|
install libsdl2.0-dev or similar to get SDL support. Alternatively you can
|
2019-07-18 07:34:33 +00:00
|
|
|
build sandbox without SDL (i.e. no display/keyboard support) by removing
|
|
|
|
the CONFIG_SANDBOX_SDL line in include/configs/sandbox.h or using::
|
2014-03-22 23:12:59 +00:00
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
make sandbox_defconfig all NO_SDL=1
|
|
|
|
./u-boot
|
2014-03-22 23:12:59 +00:00
|
|
|
|
|
|
|
U-Boot will start on your computer, showing a sandbox emulation of the serial
|
2019-07-18 07:34:33 +00:00
|
|
|
console::
|
2014-03-22 23:12:59 +00:00
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
U-Boot 2014.04 (Mar 20 2014 - 19:06:00)
|
2014-03-22 23:12:59 +00:00
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
DRAM: 128 MiB
|
|
|
|
Using default environment
|
2014-03-22 23:12:59 +00:00
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
In: serial
|
|
|
|
Out: lcd
|
|
|
|
Err: lcd
|
|
|
|
=>
|
2014-03-22 23:12:59 +00:00
|
|
|
|
|
|
|
You can issue commands as your would normally. If the command you want is
|
|
|
|
not supported you can add it to include/configs/sandbox.h.
|
|
|
|
|
2021-02-07 21:27:07 +00:00
|
|
|
To exit, type 'poweroff' or press Ctrl-C.
|
2014-03-22 23:12:59 +00:00
|
|
|
|
|
|
|
|
|
|
|
Console / LCD support
|
|
|
|
---------------------
|
|
|
|
|
|
|
|
Assuming that CONFIG_SANDBOX_SDL is defined when building, you can run the
|
2019-07-18 07:34:33 +00:00
|
|
|
sandbox with LCD and keyboard emulation, using something like::
|
2014-03-22 23:12:59 +00:00
|
|
|
|
|
|
|
./u-boot -d u-boot.dtb -l
|
|
|
|
|
|
|
|
This will start U-Boot with a window showing the contents of the LCD. If
|
|
|
|
that window has the focus then you will be able to type commands as you
|
|
|
|
would on the console. You can adjust the display settings in the device
|
|
|
|
tree file - see arch/sandbox/dts/sandbox.dts.
|
|
|
|
|
|
|
|
|
|
|
|
Command-line Options
|
|
|
|
--------------------
|
|
|
|
|
|
|
|
Various options are available, mostly for test purposes. Use -h to see
|
2020-09-19 18:05:47 +00:00
|
|
|
available options. Some of these are described below:
|
|
|
|
|
2020-12-30 17:10:24 +00:00
|
|
|
-t, --terminal <arg>
|
|
|
|
The terminal is normally in what is called 'raw-with-sigs' mode. This means
|
2020-09-19 18:05:47 +00:00
|
|
|
that you can use arrow keys for command editing and history, but if you
|
|
|
|
press Ctrl-C, U-Boot will exit instead of handling this as a keypress.
|
|
|
|
Other options are 'raw' (so Ctrl-C is handled within U-Boot) and 'cooked'
|
|
|
|
(where the terminal is in cooked mode and cursor keys will not work, Ctrl-C
|
|
|
|
will exit).
|
|
|
|
|
2020-12-30 17:10:24 +00:00
|
|
|
-l
|
|
|
|
Show the LCD emulation window.
|
2020-09-19 18:05:47 +00:00
|
|
|
|
2020-12-30 17:10:24 +00:00
|
|
|
-d <device_tree>
|
|
|
|
A device tree binary file can be provided with -d. If you edit the source
|
2020-09-19 18:05:47 +00:00
|
|
|
(it is stored at arch/sandbox/dts/sandbox.dts) you must rebuild U-Boot to
|
|
|
|
recreate the binary file.
|
|
|
|
|
2020-12-30 17:10:24 +00:00
|
|
|
-D
|
|
|
|
To use the default device tree, use -D.
|
2020-09-19 18:05:47 +00:00
|
|
|
|
2020-12-30 17:10:24 +00:00
|
|
|
-T
|
|
|
|
To use the test device tree, use -T.
|
2020-09-19 18:05:47 +00:00
|
|
|
|
2020-12-30 17:10:24 +00:00
|
|
|
-c [<cmd>;]<cmd>
|
|
|
|
To execute commands directly, use the -c option. You can specify a single
|
2020-09-19 18:05:47 +00:00
|
|
|
command, or multiple commands separated by a semicolon, as is normal in
|
|
|
|
U-Boot. Be careful with quoting as the shell will normally process and
|
|
|
|
swallow quotes. When -c is used, U-Boot exits after the command is complete,
|
|
|
|
but you can force it to go to interactive mode instead with -i.
|
|
|
|
|
2020-12-30 17:10:24 +00:00
|
|
|
-i
|
|
|
|
Go to interactive mode after executing the commands specified by -c.
|
2014-03-22 23:12:59 +00:00
|
|
|
|
2020-12-30 17:07:48 +00:00
|
|
|
Environment Variables
|
|
|
|
---------------------
|
|
|
|
|
|
|
|
UBOOT_SB_TIME_OFFSET
|
|
|
|
This environment variable stores the offset of the emulated real time clock
|
|
|
|
to the host's real time clock in seconds. The offset defaults to zero.
|
|
|
|
|
2014-03-22 23:12:59 +00:00
|
|
|
Memory Emulation
|
|
|
|
----------------
|
|
|
|
|
2022-05-17 16:09:17 +00:00
|
|
|
Memory emulation is supported, with the size set by CONFIG_SANDBOX_RAM_SIZE_MB.
|
2014-03-22 23:12:59 +00:00
|
|
|
The -m option can be used to read memory from a file on start-up and write
|
|
|
|
it when shutting down. This allows preserving of memory contents across
|
|
|
|
test runs. You can tell U-Boot to remove the memory file after it is read
|
|
|
|
(on start-up) with the --rm_memory option.
|
|
|
|
|
|
|
|
To access U-Boot's emulated memory within the code, use map_sysmem(). This
|
|
|
|
function is used throughout U-Boot to ensure that emulated memory is used
|
|
|
|
rather than the U-Boot application memory. This provides memory starting
|
|
|
|
at 0 and extending to the size of the emulation.
|
|
|
|
|
|
|
|
|
|
|
|
Storing State
|
|
|
|
-------------
|
|
|
|
|
|
|
|
With sandbox you can write drivers which emulate the operation of drivers on
|
|
|
|
real devices. Some of these drivers may want to record state which is
|
|
|
|
preserved across U-Boot runs. This is particularly useful for testing. For
|
|
|
|
example, the contents of a SPI flash chip should not disappear just because
|
|
|
|
U-Boot exits.
|
|
|
|
|
|
|
|
State is stored in a device tree file in a simple format which is driver-
|
|
|
|
specific. You then use the -s option to specify the state file. Use -r to
|
|
|
|
make U-Boot read the state on start-up (otherwise it starts empty) and -w
|
|
|
|
to write it on exit (otherwise the stored state is left unchanged and any
|
|
|
|
changes U-Boot made will be lost). You can also use -n to tell U-Boot to
|
|
|
|
ignore any problems with missing state. This is useful when first running
|
|
|
|
since the state file will be empty.
|
|
|
|
|
|
|
|
The device tree file has one node for each driver - the driver can store
|
|
|
|
whatever properties it likes in there. See 'Writing Sandbox Drivers' below
|
|
|
|
for more details on how to get drivers to read and write their state.
|
|
|
|
|
|
|
|
|
|
|
|
Running and Booting
|
|
|
|
-------------------
|
|
|
|
|
|
|
|
Since there is no machine architecture, sandbox U-Boot cannot actually boot
|
|
|
|
a kernel, but it does support the bootm command. Filesystems, memory
|
|
|
|
commands, hashing, FIT images, verified boot and many other features are
|
|
|
|
supported.
|
|
|
|
|
|
|
|
When 'bootm' runs a kernel, sandbox will exit, as U-Boot does on a real
|
|
|
|
machine. Of course in this case, no kernel is run.
|
|
|
|
|
|
|
|
It is also possible to tell U-Boot that it has jumped from a temporary
|
|
|
|
previous U-Boot binary, with the -j option. That binary is automatically
|
|
|
|
removed by the U-Boot that gets the -j option. This allows you to write
|
|
|
|
tests which emulate the action of chain-loading U-Boot, typically used in
|
|
|
|
a situation where a second 'updatable' U-Boot is stored on your board. It
|
|
|
|
is very risky to overwrite or upgrade the only U-Boot on a board, since a
|
|
|
|
power or other failure will brick the board and require return to the
|
|
|
|
manufacturer in the case of a consumer device.
|
|
|
|
|
|
|
|
|
|
|
|
Supported Drivers
|
|
|
|
-----------------
|
|
|
|
|
|
|
|
U-Boot sandbox supports these emulations:
|
|
|
|
|
|
|
|
- Block devices
|
|
|
|
- Chrome OS EC
|
|
|
|
- GPIO
|
|
|
|
- Host filesystem (access files on the host from within U-Boot)
|
2015-03-22 22:09:13 +00:00
|
|
|
- I2C
|
2014-03-22 23:12:59 +00:00
|
|
|
- Keyboard (Chrome OS)
|
|
|
|
- LCD
|
2015-03-22 22:09:13 +00:00
|
|
|
- Network
|
2014-03-22 23:12:59 +00:00
|
|
|
- Serial (for console only)
|
|
|
|
- Sound (incomplete - see sandbox_sdl_sound_init() for details)
|
|
|
|
- SPI
|
|
|
|
- SPI flash
|
|
|
|
- TPM (Trusted Platform Module)
|
|
|
|
|
2018-04-30 23:13:05 +00:00
|
|
|
A wide range of commands are implemented. Filesystems which use a block
|
2014-03-22 23:12:59 +00:00
|
|
|
device are supported.
|
|
|
|
|
2016-05-15 00:49:27 +00:00
|
|
|
Also sandbox supports driver model (CONFIG_DM) and associated commands.
|
2011-10-10 08:22:14 +00:00
|
|
|
|
|
|
|
|
2018-09-19 00:43:28 +00:00
|
|
|
Sandbox Variants
|
|
|
|
----------------
|
|
|
|
|
|
|
|
There are unfortunately quite a few variants at present:
|
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
sandbox:
|
|
|
|
should be used for most tests
|
|
|
|
sandbox64:
|
|
|
|
special build that forces a 64-bit host
|
|
|
|
sandbox_flattree:
|
|
|
|
builds with dev_read\_...() functions defined as inline.
|
|
|
|
We need this build so that we can test those inline functions, and we
|
|
|
|
cannot build with both the inline functions and the non-inline functions
|
|
|
|
since they are named the same.
|
|
|
|
sandbox_spl:
|
|
|
|
builds sandbox with SPL support, so you can run spl/u-boot-spl
|
|
|
|
and it will start up and then load ./u-boot. It is also possible to
|
|
|
|
run ./u-boot directly.
|
2018-09-19 00:43:28 +00:00
|
|
|
|
2019-10-11 20:28:47 +00:00
|
|
|
Of these sandbox_spl can probably be removed since it is a superset of sandbox.
|
2018-09-19 00:43:28 +00:00
|
|
|
|
|
|
|
Most of the config options should be identical between these variants.
|
|
|
|
|
|
|
|
|
2015-03-22 22:09:21 +00:00
|
|
|
Linux RAW Networking Bridge
|
|
|
|
---------------------------
|
|
|
|
|
|
|
|
The sandbox_eth_raw driver bridges traffic between the bottom of the network
|
|
|
|
stack and the RAW sockets API in Linux. This allows much of the U-Boot network
|
|
|
|
functionality to be tested in sandbox against real network traffic.
|
|
|
|
|
|
|
|
For Ethernet network adapters, the bridge utilizes the RAW AF_PACKET API. This
|
|
|
|
is needed to get access to the lowest level of the network stack in Linux. This
|
|
|
|
means that all of the Ethernet frame is included. This allows the U-Boot network
|
|
|
|
stack to be fully used. In other words, nothing about the Linux network stack is
|
|
|
|
involved in forming the packets that end up on the wire. To receive the
|
|
|
|
responses to packets sent from U-Boot the network interface has to be set to
|
|
|
|
promiscuous mode so that the network card won't filter out packets not destined
|
|
|
|
for its configured (on Linux) MAC address.
|
|
|
|
|
|
|
|
The RAW sockets Ethernet API requires elevated privileges in Linux. You can
|
2019-07-18 07:34:33 +00:00
|
|
|
either run as root, or you can add the capability needed like so::
|
2015-03-22 22:09:21 +00:00
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
sudo /sbin/setcap "CAP_NET_RAW+ep" /path/to/u-boot
|
2015-03-22 22:09:21 +00:00
|
|
|
|
|
|
|
The default device tree for sandbox includes an entry for eth0 on the sandbox
|
|
|
|
host machine whose alias is "eth1". The following are a few examples of network
|
|
|
|
operations being tested on the eth0 interface.
|
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
.. code-block:: none
|
|
|
|
|
|
|
|
sudo /path/to/u-boot -D
|
2015-03-22 22:09:21 +00:00
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
DHCP
|
|
|
|
....
|
2015-03-22 22:09:21 +00:00
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
setenv autoload no
|
|
|
|
setenv ethrotate no
|
|
|
|
setenv ethact eth1
|
|
|
|
dhcp
|
2015-03-22 22:09:21 +00:00
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
PING
|
|
|
|
....
|
2015-03-22 22:09:21 +00:00
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
setenv autoload no
|
|
|
|
setenv ethrotate no
|
|
|
|
setenv ethact eth1
|
|
|
|
dhcp
|
|
|
|
ping $gatewayip
|
2015-03-22 22:09:21 +00:00
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
TFTP
|
|
|
|
....
|
2015-03-22 22:09:21 +00:00
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
setenv autoload no
|
|
|
|
setenv ethrotate no
|
|
|
|
setenv ethact eth1
|
|
|
|
dhcp
|
|
|
|
setenv serverip WWW.XXX.YYY.ZZZ
|
|
|
|
tftpboot u-boot.bin
|
2015-03-22 22:09:21 +00:00
|
|
|
|
2018-04-30 23:13:05 +00:00
|
|
|
The bridge also supports (to a lesser extent) the localhost interface, 'lo'.
|
2015-03-22 22:09:23 +00:00
|
|
|
|
|
|
|
The 'lo' interface cannot use the RAW AF_PACKET API because the lo interface
|
|
|
|
doesn't support Ethernet-level traffic. It is a higher-level interface that is
|
|
|
|
expected only to be used at the AF_INET level of the API. As such, the most raw
|
|
|
|
we can get on that interface is the RAW AF_INET API on UDP. This allows us to
|
|
|
|
set the IP_HDRINCL option to include everything except the Ethernet header in
|
|
|
|
the packets we send and receive.
|
|
|
|
|
|
|
|
Because only UDP is supported, ICMP traffic will not work, so expect that ping
|
|
|
|
commands will time out.
|
|
|
|
|
|
|
|
The default device tree for sandbox includes an entry for lo on the sandbox
|
|
|
|
host machine whose alias is "eth5". The following is an example of a network
|
|
|
|
operation being tested on the lo interface.
|
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
.. code-block:: none
|
2015-03-22 22:09:23 +00:00
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
TFTP
|
|
|
|
....
|
|
|
|
|
|
|
|
setenv ethrotate no
|
|
|
|
setenv ethact eth5
|
|
|
|
tftpboot u-boot.bin
|
2015-03-22 22:09:23 +00:00
|
|
|
|
2015-03-22 22:09:21 +00:00
|
|
|
|
2013-12-03 23:43:27 +00:00
|
|
|
SPI Emulation
|
|
|
|
-------------
|
|
|
|
|
|
|
|
Sandbox supports SPI and SPI flash emulation.
|
|
|
|
|
2020-04-27 06:46:45 +00:00
|
|
|
The device can be enabled via a device tree, for example::
|
|
|
|
|
|
|
|
spi@0 {
|
|
|
|
#address-cells = <1>;
|
|
|
|
#size-cells = <0>;
|
|
|
|
reg = <0 1>;
|
|
|
|
compatible = "sandbox,spi";
|
|
|
|
cs-gpios = <0>, <&gpio_a 0>;
|
|
|
|
spi.bin@0 {
|
|
|
|
reg = <0>;
|
|
|
|
compatible = "spansion,m25p16", "jedec,spi-nor";
|
|
|
|
spi-max-frequency = <40000000>;
|
|
|
|
sandbox,filename = "spi.bin";
|
|
|
|
};
|
|
|
|
};
|
|
|
|
|
|
|
|
The file must be created in advance::
|
|
|
|
|
|
|
|
$ dd if=/dev/zero of=spi.bin bs=1M count=2
|
|
|
|
$ u-boot -T
|
|
|
|
|
|
|
|
Here, you can use "-T" or "-D" option to specify test.dtb or u-boot.dtb,
|
|
|
|
respectively, or "-d <file>" for your own dtb.
|
2013-12-03 23:43:27 +00:00
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
With this setup you can issue SPI flash commands as normal::
|
2013-12-03 23:43:27 +00:00
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
=>sf probe
|
|
|
|
SF: Detected M25P16 with page size 64 KiB, total 2 MiB
|
|
|
|
=>sf read 0 0 10000
|
|
|
|
SF: 65536 bytes @ 0x0 Read: OK
|
2013-12-03 23:43:27 +00:00
|
|
|
|
|
|
|
Since this is a full SPI emulation (rather than just flash), you can
|
2019-07-18 07:34:33 +00:00
|
|
|
also use low-level SPI commands::
|
2013-12-03 23:43:27 +00:00
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
=>sspi 0:0 32 9f
|
|
|
|
FF202015
|
2013-12-03 23:43:27 +00:00
|
|
|
|
|
|
|
This is issuing a READ_ID command and getting back 20 (ST Micro) part
|
|
|
|
0x2015 (the M25P16).
|
|
|
|
|
|
|
|
|
2016-08-11 20:52:03 +00:00
|
|
|
Block Device Emulation
|
|
|
|
----------------------
|
|
|
|
|
|
|
|
U-Boot can use raw disk images for block device emulation. To e.g. list
|
|
|
|
the contents of the root directory on the second partion of the image
|
2019-07-18 07:34:33 +00:00
|
|
|
"disk.raw", you can use the following commands::
|
2016-08-11 20:52:03 +00:00
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
=>host bind 0 ./disk.raw
|
|
|
|
=>ls host 0:2
|
2016-08-11 20:52:03 +00:00
|
|
|
|
2021-03-15 05:11:11 +00:00
|
|
|
The device can be marked removeable with 'host bind -r'.
|
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
A disk image can be created using the following commands::
|
2016-08-11 20:52:03 +00:00
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
$> truncate -s 1200M ./disk.raw
|
|
|
|
$> echo -e "label: gpt\n,64M,U\n,,L" | /usr/sbin/sgdisk ./disk.raw
|
|
|
|
$> lodev=`sudo losetup -P -f --show ./disk.raw`
|
|
|
|
$> sudo mkfs.vfat -n EFI -v ${lodev}p1
|
|
|
|
$> sudo mkfs.ext4 -L ROOT -v ${lodev}p2
|
2016-08-11 20:52:03 +00:00
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
or utilize the device described in test/py/make_test_disk.py::
|
2017-09-10 06:47:12 +00:00
|
|
|
|
|
|
|
#!/usr/bin/python
|
|
|
|
import make_test_disk
|
|
|
|
make_test_disk.makeDisk()
|
2016-08-11 20:52:03 +00:00
|
|
|
|
2014-03-22 23:12:59 +00:00
|
|
|
Writing Sandbox Drivers
|
|
|
|
-----------------------
|
|
|
|
|
|
|
|
Generally you should put your driver in a file containing the word 'sandbox'
|
|
|
|
and put it in the same directory as other drivers of its type. You can then
|
|
|
|
implement the same hooks as the other drivers.
|
|
|
|
|
|
|
|
To access U-Boot's emulated memory, use map_sysmem() as mentioned above.
|
|
|
|
|
|
|
|
If your driver needs to store configuration or state (such as SPI flash
|
|
|
|
contents or emulated chip registers), you can use the device tree as
|
|
|
|
described above. Define handlers for this with the SANDBOX_STATE_IO macro.
|
|
|
|
See arch/sandbox/include/asm/state.h for documentation. In short you provide
|
|
|
|
a node name, compatible string and functions to read and write the state.
|
|
|
|
Since writing the state can expand the device tree, you may need to use
|
|
|
|
state_setprop() which does this automatically and avoids running out of
|
|
|
|
space. See existing code for examples.
|
|
|
|
|
|
|
|
|
2022-04-30 06:56:54 +00:00
|
|
|
VPL (Verifying Program Loader)
|
|
|
|
------------------------------
|
|
|
|
|
|
|
|
Sandbox provides an example build of vpl called `sandbox_vpl`. This can be run
|
|
|
|
using::
|
|
|
|
|
|
|
|
/path/to/sandbox_vpl/tpl/u-boot-tpl -D
|
|
|
|
|
|
|
|
It starts up TPL (first-stage init), then VPL, then runs SPL and finally U-Boot
|
|
|
|
proper, following the normal flow for a verified boot. At present, no
|
|
|
|
verification is actually implemented.
|
|
|
|
|
|
|
|
|
2019-04-08 19:20:41 +00:00
|
|
|
Debugging the init sequence
|
|
|
|
---------------------------
|
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
If you get a failure in the initcall sequence, like this::
|
2019-04-08 19:20:41 +00:00
|
|
|
|
|
|
|
initcall sequence 0000560775957c80 failed at call 0000000000048134 (err=-96)
|
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
Then you use can use grep to see which init call failed, e.g.::
|
2019-04-08 19:20:41 +00:00
|
|
|
|
|
|
|
$ grep 0000000000048134 u-boot.map
|
|
|
|
stdio_add_devices
|
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
Of course another option is to run it with a debugger such as gdb::
|
2019-04-08 19:20:41 +00:00
|
|
|
|
|
|
|
$ gdb u-boot
|
|
|
|
...
|
|
|
|
(gdb) br initcall.h:41
|
|
|
|
Breakpoint 1 at 0x4db9d: initcall.h:41. (2 locations)
|
|
|
|
|
|
|
|
Note that two locations are reported, since this function is used in both
|
|
|
|
board_init_f() and board_init_r().
|
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
.. code-block:: none
|
|
|
|
|
2019-04-08 19:20:41 +00:00
|
|
|
(gdb) r
|
|
|
|
Starting program: /tmp/b/sandbox/u-boot
|
|
|
|
[Thread debugging using libthread_db enabled]
|
|
|
|
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
|
|
|
|
|
|
|
|
U-Boot 2018.09-00264-ge0c2ba9814-dirty (Sep 22 2018 - 12:21:46 -0600)
|
|
|
|
|
|
|
|
DRAM: 128 MiB
|
|
|
|
MMC:
|
|
|
|
|
|
|
|
Breakpoint 1, initcall_run_list (init_sequence=0x5555559619e0 <init_sequence_f>)
|
|
|
|
at /scratch/sglass/cosarm/src/third_party/u-boot/files/include/initcall.h:41
|
|
|
|
41 printf("initcall sequence %p failed at call %p (err=%d)\n",
|
|
|
|
(gdb) print *init_fnc_ptr
|
|
|
|
$1 = (const init_fnc_t) 0x55555559c114 <stdio_add_devices>
|
|
|
|
(gdb)
|
|
|
|
|
|
|
|
|
|
|
|
This approach can be used on normal boards as well as sandbox.
|
|
|
|
|
2022-05-17 16:21:29 +00:00
|
|
|
For debugging with GDB or LLDB, it is preferable to reduce the compiler
|
|
|
|
optimization level (CONFIG_CC_OPTIMIZE_FOR_DEBUG=y) and to disable Link Time
|
|
|
|
Optimization (CONFIG_LTO=n).
|
2019-04-08 19:20:41 +00:00
|
|
|
|
2019-05-18 17:59:47 +00:00
|
|
|
SDL_CONFIG
|
|
|
|
----------
|
|
|
|
|
|
|
|
If sdl-config is on a different path from the default, set the SDL_CONFIG
|
|
|
|
environment variable to the correct pathname before building U-Boot.
|
|
|
|
|
|
|
|
|
2019-05-18 17:59:50 +00:00
|
|
|
Using valgrind / memcheck
|
|
|
|
-------------------------
|
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
It is possible to run U-Boot under valgrind to check memory allocations::
|
2019-05-18 17:59:50 +00:00
|
|
|
|
2022-03-23 18:04:50 +00:00
|
|
|
valgrind ./u-boot
|
|
|
|
|
|
|
|
For more detailed results, enable `CONFIG_VALGRIND`. There are many false
|
|
|
|
positives due to `malloc` itself. Suppress these with::
|
|
|
|
|
|
|
|
valgrind --suppressions=scripts/u-boot.supp ./u-boot
|
2019-05-18 17:59:50 +00:00
|
|
|
|
|
|
|
If you are running sandbox SPL or TPL, then valgrind will not by default
|
|
|
|
notice when U-Boot jumps from TPL to SPL, or from SPL to U-Boot proper. To
|
2022-03-23 18:04:50 +00:00
|
|
|
fix this, use `--trace-children=yes`. To show who alloc'd some troublesome
|
|
|
|
memory, use `--track-origins=yes`. To uncover possible errors, try running all
|
|
|
|
unit tests with::
|
2019-05-18 17:59:50 +00:00
|
|
|
|
2022-03-23 18:04:50 +00:00
|
|
|
valgrind --track-origins=yes --suppressions=scripts/u-boot.supp ./u-boot -Tc 'ut all'
|
2019-05-18 17:59:50 +00:00
|
|
|
|
2014-03-22 23:12:59 +00:00
|
|
|
Testing
|
|
|
|
-------
|
|
|
|
|
|
|
|
U-Boot sandbox can be used to run various tests, mostly in the test/
|
2021-03-08 00:35:16 +00:00
|
|
|
directory.
|
2019-09-25 14:56:07 +00:00
|
|
|
|
2021-03-08 00:35:16 +00:00
|
|
|
See :doc:`../develop/tests_sandbox` for more information and
|
|
|
|
:doc:`../develop/testing` for information about testing generally.
|
2019-09-25 14:56:07 +00:00
|
|
|
|
2018-11-16 01:43:59 +00:00
|
|
|
|
|
|
|
Memory Map
|
|
|
|
----------
|
|
|
|
|
|
|
|
Sandbox has its own emulated memory starting at 0. Here are some of the things
|
|
|
|
that are mapped into that memory:
|
|
|
|
|
2019-07-18 07:34:33 +00:00
|
|
|
======= ======================== ===============================
|
|
|
|
Addr Config Usage
|
|
|
|
======= ======================== ===============================
|
2018-11-16 01:43:59 +00:00
|
|
|
0 CONFIG_SYS_FDT_LOAD_ADDR Device tree
|
2021-07-05 22:32:48 +00:00
|
|
|
c000 CONFIG_BLOBLIST_ADDR Blob list
|
2018-11-16 01:43:59 +00:00
|
|
|
10000 CONFIG_MALLOC_F_ADDR Early memory allocation
|
2019-04-08 19:20:44 +00:00
|
|
|
f0000 CONFIG_PRE_CON_BUF_ADDR Pre-console buffer
|
2021-03-08 00:35:15 +00:00
|
|
|
100000 CONFIG_TRACE_EARLY_ADDR Early trace buffer (if enabled). Also used
|
|
|
|
as the SPL load buffer in spl_test_load().
|
|
|
|
200000 CONFIG_SYS_TEXT_BASE Load buffer for U-Boot (sandbox_spl only)
|
2019-07-18 07:34:33 +00:00
|
|
|
======= ======================== ===============================
|