From fd37dac9eb37b543fb1b82a733729514a67bd801 Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Fri, 25 Oct 2013 23:01:31 -0600 Subject: sandbox: Support 'env import' and 'env export' Adjust the code for these commands so that they work on sandbox. Signed-off-by: Simon Glass (Adjusted to fix minor merge comflict, when applied) Change-Id: I987dee6194cd5c83f82604caf894fc85e4eb71a8 --- common/cmd_nvedit.c | 31 ++++++++++++++++++------------- 1 file changed, 18 insertions(+), 13 deletions(-) diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c index c53601cf74..f4e306ceba 100644 --- a/common/cmd_nvedit.c +++ b/common/cmd_nvedit.c @@ -33,6 +33,7 @@ #include #include #include +#include DECLARE_GLOBAL_DATA_PTR; @@ -846,7 +847,8 @@ static int do_env_export(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) { char buf[32]; - char *addr, *cmd, *res; + ulong addr; + char *ptr, *cmd, *res; size_t size = 0; ssize_t len; env_t *envp; @@ -891,10 +893,11 @@ NXTARG: ; if (argc < 1) return CMD_RET_USAGE; - addr = (char *)simple_strtoul(argv[0], NULL, 16); + addr = simple_strtoul(argv[0], NULL, 16); + ptr = map_sysmem(addr, size); if (size) - memset(addr, '\0', size); + memset(ptr, '\0', size); argc--; argv++; @@ -902,7 +905,7 @@ NXTARG: ; if (sep) { /* export as text file */ len = hexport_r(&env_htab, sep, H_MATCH_KEY | H_MATCH_IDENT, - &addr, size, argc, argv); + &ptr, size, argc, argv); if (len < 0) { error("Cannot export environment: errno = %d\n", errno); return 1; @@ -913,12 +916,12 @@ NXTARG: ; return 0; } - envp = (env_t *)addr; + envp = (env_t *)ptr; if (chk) /* export as checksum protected block */ res = (char *)envp->data; else /* export as raw binary data */ - res = addr; + res = ptr; len = hexport_r(&env_htab, '\0', H_MATCH_KEY | H_MATCH_IDENT, @@ -960,7 +963,8 @@ sep_err: static int do_env_import(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) { - char *cmd, *addr; + ulong addr; + char *cmd, *ptr; char sep = '\n'; int chk = 0; int fmt = 0; @@ -1004,7 +1008,8 @@ static int do_env_import(cmd_tbl_t *cmdtp, int flag, if (!fmt) printf("## Warning: defaulting to text format\n"); - addr = (char *)simple_strtoul(argv[0], NULL, 16); + addr = simple_strtoul(argv[0], NULL, 16); + ptr = map_sysmem(addr, 0); if (argc == 2) { size = simple_strtoul(argv[1], NULL, 16); @@ -1012,7 +1017,7 @@ static int do_env_import(cmd_tbl_t *cmdtp, int flag, puts("## Error: external checksum format must pass size\n"); return CMD_RET_FAILURE; } else { - char *s = addr; + char *s = ptr; size = 0; @@ -1032,7 +1037,7 @@ static int do_env_import(cmd_tbl_t *cmdtp, int flag, if (chk) { uint32_t crc; - env_t *ep = (env_t *)addr; + env_t *ep = (env_t *)ptr; size -= offsetof(env_t, data); memcpy(&crc, &ep->crc, sizeof(crc)); @@ -1041,11 +1046,11 @@ static int do_env_import(cmd_tbl_t *cmdtp, int flag, puts("## Error: bad CRC, import failed\n"); return 1; } - addr = (char *)ep->data; + ptr = (char *)ep->data; } - if (himport_r(&env_htab, addr, size, sep, del ? 0 : H_NOCLEAR, - 0, NULL) == 0) { + if (himport_r(&env_htab, ptr, size, sep, del ? 0 : H_NOCLEAR, 0, + NULL) == 0) { error("Environment import failed: errno = %d\n", errno); return 1; } -- cgit v1.2.3 From 1992dbfdb9886c3dfc4a505091895c851f736f3a Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Fri, 25 Oct 2013 23:01:32 -0600 Subject: Make 'run' use run_command_list() instead of run_command() In the case where an environment variable spans multiple lines, we should use run_command_list() so that all lines are executed. This shold be backwards compatible with existing behaviour for existing scripts. Signed-off-by: Simon Glass --- common/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/main.c b/common/main.c index e54f63b956..9bee7bdc6b 100644 --- a/common/main.c +++ b/common/main.c @@ -1550,7 +1550,7 @@ int do_run (cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[]) return 1; } - if (run_command(arg, flag) != 0) + if (run_command_list(arg, -1, flag) != 0) return 1; } return 0; -- cgit v1.2.3 From ad0e4639545b0928a3673114962ee1f3e56402d7 Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Sat, 22 Mar 2014 17:12:58 -0600 Subject: sandbox: Provide a build option to avoid using SDL Some machines do not have SDL libraries installed, and it is still useful to build sandbox without LCD/keyboard support. Add an option for this, used as follows: make sandbox_config all NO_SDL=1 Signed-off-by: Simon Glass --- arch/sandbox/config.mk | 6 ++++++ include/configs/sandbox.h | 16 ++++++++++++++-- 2 files changed, 20 insertions(+), 2 deletions(-) diff --git a/arch/sandbox/config.mk b/arch/sandbox/config.mk index e094ae2d05..c3f889fb1c 100644 --- a/arch/sandbox/config.mk +++ b/arch/sandbox/config.mk @@ -18,3 +18,9 @@ cmd_u-boot__ = $(CC) -o $@ -T u-boot.lds \ $(PLATFORM_LIBS) -Wl,-Map -Wl,u-boot.map CONFIG_ARCH_DEVICE_TREE := sandbox + +# Define this to avoid linking with SDL, which requires SDL libraries +# This can solve 'sdl-config: Command not found' errors +ifneq ($(NO_SDL),) +PLATFORM_CPPFLAGS += -DSANDBOX_NO_SDL +endif diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h index fa62cb6cd5..6bb2546eda 100644 --- a/include/configs/sandbox.h +++ b/include/configs/sandbox.h @@ -140,8 +140,6 @@ #define CONFIG_CROS_EC #define CONFIG_CMD_CROS_EC #define CONFIG_CROS_EC_SANDBOX -#define CONFIG_KEYBOARD -#define CONFIG_CROS_EC_KEYB #define CONFIG_ARCH_EARLY_INIT_R #define CONFIG_BOARD_LATE_INIT @@ -149,7 +147,12 @@ #define CONFIG_SOUND_SANDBOX #define CONFIG_CMD_SOUND +#ifndef SANDBOX_NO_SDL #define CONFIG_SANDBOX_SDL +#endif + +/* LCD and keyboard require SDL support */ +#ifdef CONFIG_SANDBOX_SDL #define CONFIG_LCD #define CONFIG_VIDEO_SANDBOX_SDL #define CONFIG_CMD_BMP @@ -158,9 +161,18 @@ #define CONFIG_SYS_CONSOLE_IS_IN_ENV #define LCD_BPP LCD_COLOR16 +#define CONFIG_CROS_EC_KEYB +#define CONFIG_KEYBOARD + #define CONFIG_EXTRA_ENV_SETTINGS "stdin=serial,cros-ec-keyb\0" \ "stdout=serial,lcd\0" \ "stderr=serial,lcd\0" +#else + +#define CONFIG_EXTRA_ENV_SETTINGS "stdin=serial\0" \ + "stdout=serial,lcd\0" \ + "stderr=serial,lcd\0" +#endif #define CONFIG_GZIP_COMPRESSED #define CONFIG_BZIP2 -- cgit v1.2.3 From 75b3c3aa843911f152098acf8eb551d6bb9d4f13 Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Sat, 22 Mar 2014 17:12:59 -0600 Subject: sandbox: Update and expand the README Now that sandbox has a good base of features, the README is quite out of date. Update it, and document the new features. Signed-off-by: Simon Glass --- README | 11 ++ board/sandbox/sandbox/README.sandbox | 222 +++++++++++++++++++++++++++++++++-- 2 files changed, 226 insertions(+), 7 deletions(-) diff --git a/README b/README index b973344184..4178987e7c 100644 --- a/README +++ b/README @@ -264,6 +264,17 @@ e.g. "make cogent_mpc8xx_config". And also configure the cogent directory according to the instructions in cogent/README. +Sandbox Environment: +-------------------- + +U-Boot can be built natively to run on a Linux host using the 'sandbox' +board. This allows feature development which is not board- or architecture- +specific to be undertaken on a native platform. The sandbox is also used to +run some of U-Boot's tests. + +See board/sandbox/sandbox/README.sandbox for more details. + + Configuration Options: ---------------------- diff --git a/board/sandbox/sandbox/README.sandbox b/board/sandbox/sandbox/README.sandbox index 69895574ff..529c447a5b 100644 --- a/board/sandbox/sandbox/README.sandbox +++ b/board/sandbox/sandbox/README.sandbox @@ -1,5 +1,5 @@ /* - * Copyright (c) 2011 The Chromium OS Authors. + * Copyright (c) 2014 The Chromium OS Authors. * * SPDX-License-Identifier: GPL-2.0+ */ @@ -26,9 +26,168 @@ 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. + +Basic Operation +--------------- + +To run sandbox U-Boot use something like: + + make sandbox_config all + ./u-boot + +Note: + If you get errors about 'sdl-config: Command not found' you may need to + install libsdl1.2-dev or similar to get SDL support. Alternatively you can + build sandbox without SDL (i.e. no display/keyboard support) by removing + the CONFIG_SANDBOX_SDL line in include/configs/sandbox.h or using: + + make sandbox_config all NO_SDL=1 + ./u-boot + + +U-Boot will start on your computer, showing a sandbox emulation of the serial +console: + + +U-Boot 2014.04 (Mar 20 2014 - 19:06:00) + +DRAM: 128 MiB +Using default environment + +In: serial +Out: lcd +Err: lcd +=> + +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. + +To exit, type 'reset' or press Ctrl-C. + + +Console / LCD support +--------------------- + +Assuming that CONFIG_SANDBOX_SDL is defined when building, you can run the +sandbox with LCD and keyboard emulation, using something like: + + ./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 +available options. Some of these are described below. + +The terminal is normally in what is called 'raw-with-sigs' mode. This means +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). + +As mentioned above, -l causes the LCD emulation window to be shown. + +A device tree binary file can be provided with -d. If you edit the source +(it is stored at arch/sandbox/dts/sandbox.dts) you must rebuild U-Boot to +recreate the binary file. + +To execute commands directly, use the -c option. You can specify a single +command, or multiple commands separated by a semicolon, as is normal in +U-Boot. Be careful with quoting as the shall will normally process and +swallow quotes. When -c is used, U-Boot exists after the command is complete, +but you can force it to go to interactive mode instead with -i. + + +Memory Emulation +---------------- + +Memory emulation is supported, with the size set by CONFIG_SYS_SDRAM_SIZE. +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) +- Keyboard (Chrome OS) +- LCD +- Serial (for console only) +- Sound (incomplete - see sandbox_sdl_sound_init() for details) +- SPI +- SPI flash +- TPM (Trusted Platform Module) + +Notable omissions are networking and I2C. + +A wide range of commands is implemented. Filesystems which use a block +device are supported. + +Also sandbox uses generic board (CONFIG_SYS_GENERIC_BOARD) and supports +driver model (CONFIG_DM) and associated commands. SPI Emulation @@ -85,7 +244,56 @@ CONFIG_SPI_IDLE_VAL The idle value on the SPI bus -Tests ------ +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. + + +Testing +------- + +U-Boot sandbox can be used to run various tests, mostly in the test/ +directory. These include: + + command_ut + - Unit tests for command parsing and handling + compression + - Unit tests for U-Boot's compression algorithms, useful for + security checking. It supports gzip, bzip2, lzma and lzo. + driver model + - test/dm/test-dm.sh to run these. + image + - Unit tests for images: + test/image/test-imagetools.sh - multi-file images + test/image/test-fit.py - FIT images + tracing + - test/trace/test-trace.sh tests the tracing system (see README.trace) + verified boot + - See test/vboot/vboot_test.sh for this + +If you change or enhance any of the above subsystems, you shold write or +expand a test and include it with your patch series submission. Test +coverage in U-Boot is limited, as we need to work to improve it. + +Note that many of these tests are implemented as commands which you can +run natively on your board if desired (and enabled). + +It would be useful to have a central script to run all of these. -So far we have no tests, but when we do these will be documented here. +-- +Simon Glass +Updated 22-Mar-14 -- cgit v1.2.3 From 757f64a89ba5bb04661b3f43444ca57fa6db1132 Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Sun, 20 Apr 2014 10:50:13 -0600 Subject: patman: Deal with 'git apply' failures correctly This sort of failure is rare, but the code to deal with it is wrong. Fix it. Signed-off-by: Simon Glass --- tools/patman/gitutil.py | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tools/patman/gitutil.py b/tools/patman/gitutil.py index 5dcbaa3bd7..3ea256de2e 100644 --- a/tools/patman/gitutil.py +++ b/tools/patman/gitutil.py @@ -11,6 +11,7 @@ import subprocess import sys import terminal +import checkpatch import settings @@ -193,6 +194,7 @@ def ApplyPatch(verbose, fname): Args: fname: filename of patch file to apply """ + col = terminal.Color() cmd = ['git', 'am', fname] pipe = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE) @@ -203,8 +205,8 @@ def ApplyPatch(verbose, fname): print line match = re_error.match(line) if match: - print GetWarningMsg('warning', match.group(1), int(match.group(2)), - 'Patch failed') + print checkpatch.GetWarningMsg(col, 'warning', match.group(1), + int(match.group(2)), 'Patch failed') return pipe.returncode == 0, stdout def ApplyPatches(verbose, args, start_point): -- cgit v1.2.3 From 102061bd8b0b174e1cf811dfd35641d8a9e4eba3 Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Sun, 20 Apr 2014 10:50:14 -0600 Subject: patman: Avoid duplicate sign-offs Keep track of all Signed-off-by tags in a commit and silently suppress any duplicates. Signed-off-by: Simon Glass --- tools/patman/README | 1 + tools/patman/commit.py | 14 ++++++++++++++ tools/patman/patchstream.py | 10 ++++++++-- 3 files changed, 23 insertions(+), 2 deletions(-) diff --git a/tools/patman/README b/tools/patman/README index b3aba136b8..5fb508b80d 100644 --- a/tools/patman/README +++ b/tools/patman/README @@ -192,6 +192,7 @@ END A sign-off is added automatically to your patches (this is probably a bug). If you put this tag in your patches, it will override the default signoff that patman automatically adds. + Multiple duplicate signoffs will be removed. Tested-by: Their Name Reviewed-by: Their Name diff --git a/tools/patman/commit.py b/tools/patman/commit.py index 89cce7f88a..3e0adb8f7e 100644 --- a/tools/patman/commit.py +++ b/tools/patman/commit.py @@ -29,6 +29,7 @@ class Commit: self.tags = [] self.changes = {} self.cc_list = [] + self.signoff_set = set() self.notes = [] def AddChange(self, version, info): @@ -72,3 +73,16 @@ class Commit: cc_list: List of aliases or email addresses """ self.cc_list += cc_list + + def CheckDuplicateSignoff(self, signoff): + """Check a list of signoffs we have send for this patch + + Args: + signoff: Signoff line + Returns: + True if this signoff is new, False if we have already seen it. + """ + if signoff in self.signoff_set: + return False + self.signoff_set.add(signoff) + return True diff --git a/tools/patman/patchstream.py b/tools/patman/patchstream.py index c4017e0e6d..9f5682cd0f 100644 --- a/tools/patman/patchstream.py +++ b/tools/patman/patchstream.py @@ -21,7 +21,7 @@ re_remove = re.compile('^BUG=|^TEST=|^BRANCH=|^Change-Id:|^Review URL:' re_allowed_after_test = re.compile('^Signed-off-by:') # Signoffs -re_signoff = re.compile('^Signed-off-by:') +re_signoff = re.compile('^Signed-off-by: *(.*)') # The start of the cover letter re_cover = re.compile('^Cover-letter:') @@ -159,6 +159,7 @@ class PatchStream: commit_tag_match = re_commit_tag.match(line) commit_match = re_commit.match(line) if self.is_log else None cover_cc_match = re_cover_cc.match(line) + signoff_match = re_signoff.match(line) tag_match = None if self.state == STATE_PATCH_HEADER: tag_match = re_tag.match(line) @@ -223,7 +224,7 @@ class PatchStream: if is_blank: # Blank line ends this change list self.in_change = 0 - elif line == '---' or re_signoff.match(line): + elif line == '---': self.in_change = 0 out = self.ProcessLine(line) else: @@ -272,6 +273,11 @@ class PatchStream: else: self.tags.append(line); + # Suppress duplicate signoffs + elif signoff_match: + if self.commit.CheckDuplicateSignoff(signoff_match.group(1)): + out = [line] + # Well that means this is an ordinary line else: pos = 1 -- cgit v1.2.3 From 258060905e04fe2eb509756ef3b37e23e220a2d6 Mon Sep 17 00:00:00 2001 From: Masahiro Yamada Date: Mon, 21 Apr 2014 18:39:35 +0900 Subject: sandbox: move source files from board/ to arch/sandbox/ Prior to commit 33a02da0, all boards must have board/${BOARD}/ or board/${VENDOR}/${BOARD}/ directory. Now this rule is obsolete. It looks weird that sandbox defines "vendor" and "board" just for meeting the old U-Boot directory structure. Signed-off-by: Masahiro Yamada Cc: Simon Glass --- arch/sandbox/lib/Makefile | 2 +- arch/sandbox/lib/sandbox.c | 83 ++++++++++ board/sandbox/sandbox/Makefile | 7 - board/sandbox/sandbox/README.sandbox | 299 ----------------------------------- board/sandbox/sandbox/sandbox.c | 83 ---------- boards.cfg | 2 +- doc/README.sandbox | 299 +++++++++++++++++++++++++++++++++++ 7 files changed, 384 insertions(+), 391 deletions(-) create mode 100644 arch/sandbox/lib/sandbox.c delete mode 100644 board/sandbox/sandbox/Makefile delete mode 100644 board/sandbox/sandbox/README.sandbox delete mode 100644 board/sandbox/sandbox/sandbox.c create mode 100644 doc/README.sandbox diff --git a/arch/sandbox/lib/Makefile b/arch/sandbox/lib/Makefile index 4c1a38d6bc..6480ebfca6 100644 --- a/arch/sandbox/lib/Makefile +++ b/arch/sandbox/lib/Makefile @@ -8,4 +8,4 @@ # -obj-y += interrupts.o +obj-y += interrupts.o sandbox.o diff --git a/arch/sandbox/lib/sandbox.c b/arch/sandbox/lib/sandbox.c new file mode 100644 index 0000000000..e4d4e021bc --- /dev/null +++ b/arch/sandbox/lib/sandbox.c @@ -0,0 +1,83 @@ +/* + * Copyright (c) 2011 The Chromium OS Authors. + * SPDX-License-Identifier: GPL-2.0+ + */ + +#include +#include +#include +#include +#include + +/* + * Pointer to initial global data area + * + * Here we initialize it. + */ +gd_t *gd; + +/* Add a simple GPIO device */ +U_BOOT_DEVICE(gpio_sandbox) = { + .name = "gpio_sandbox", +}; + +void flush_cache(unsigned long start, unsigned long size) +{ +} + +unsigned long timer_read_counter(void) +{ + return os_get_nsec() / 1000; +} + +int dram_init(void) +{ + gd->ram_size = CONFIG_SYS_SDRAM_SIZE; + return 0; +} + +#ifdef CONFIG_BOARD_EARLY_INIT_F +int board_early_init_f(void) +{ +#ifdef CONFIG_VIDEO_SANDBOX_SDL + int ret; + + ret = sandbox_lcd_sdl_early_init(); + if (ret) { + puts("Could not init sandbox LCD emulation\n"); + return ret; + } +#endif + + return 0; +} +#endif + +int arch_early_init_r(void) +{ +#ifdef CONFIG_CROS_EC + if (cros_ec_board_init()) { + printf("%s: Failed to init EC\n", __func__); + return 0; + } +#endif + + return 0; +} + +#ifdef CONFIG_BOARD_LATE_INIT +int board_late_init(void) +{ + if (cros_ec_get_error()) { + /* Force console on */ + gd->flags &= ~GD_FLG_SILENT; + + printf("cros-ec communications failure %d\n", + cros_ec_get_error()); + puts("\nPlease reset with Power+Refresh\n\n"); + panic("Cannot init cros-ec device"); + return -1; + } + return 0; +} +#endif diff --git a/board/sandbox/sandbox/Makefile b/board/sandbox/sandbox/Makefile deleted file mode 100644 index a0b9880d6e..0000000000 --- a/board/sandbox/sandbox/Makefile +++ /dev/null @@ -1,7 +0,0 @@ -# -# Copyright (c) 2011 The Chromium OS Authors. -# -# SPDX-License-Identifier: GPL-2.0+ -# - -obj-y := sandbox.o diff --git a/board/sandbox/sandbox/README.sandbox b/board/sandbox/sandbox/README.sandbox deleted file mode 100644 index 529c447a5b..0000000000 --- a/board/sandbox/sandbox/README.sandbox +++ /dev/null @@ -1,299 +0,0 @@ -/* - * Copyright (c) 2014 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. - - -Basic Operation ---------------- - -To run sandbox U-Boot use something like: - - make sandbox_config all - ./u-boot - -Note: - If you get errors about 'sdl-config: Command not found' you may need to - install libsdl1.2-dev or similar to get SDL support. Alternatively you can - build sandbox without SDL (i.e. no display/keyboard support) by removing - the CONFIG_SANDBOX_SDL line in include/configs/sandbox.h or using: - - make sandbox_config all NO_SDL=1 - ./u-boot - - -U-Boot will start on your computer, showing a sandbox emulation of the serial -console: - - -U-Boot 2014.04 (Mar 20 2014 - 19:06:00) - -DRAM: 128 MiB -Using default environment - -In: serial -Out: lcd -Err: lcd -=> - -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. - -To exit, type 'reset' or press Ctrl-C. - - -Console / LCD support ---------------------- - -Assuming that CONFIG_SANDBOX_SDL is defined when building, you can run the -sandbox with LCD and keyboard emulation, using something like: - - ./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 -available options. Some of these are described below. - -The terminal is normally in what is called 'raw-with-sigs' mode. This means -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). - -As mentioned above, -l causes the LCD emulation window to be shown. - -A device tree binary file can be provided with -d. If you edit the source -(it is stored at arch/sandbox/dts/sandbox.dts) you must rebuild U-Boot to -recreate the binary file. - -To execute commands directly, use the -c option. You can specify a single -command, or multiple commands separated by a semicolon, as is normal in -U-Boot. Be careful with quoting as the shall will normally process and -swallow quotes. When -c is used, U-Boot exists after the command is complete, -but you can force it to go to interactive mode instead with -i. - - -Memory Emulation ----------------- - -Memory emulation is supported, with the size set by CONFIG_SYS_SDRAM_SIZE. -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) -- Keyboard (Chrome OS) -- LCD -- Serial (for console only) -- Sound (incomplete - see sandbox_sdl_sound_init() for details) -- SPI -- SPI flash -- TPM (Trusted Platform Module) - -Notable omissions are networking and I2C. - -A wide range of commands is implemented. Filesystems which use a block -device are supported. - -Also sandbox uses generic board (CONFIG_SYS_GENERIC_BOARD) and supports -driver model (CONFIG_DM) and associated commands. - - -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 - - -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. - - -Testing -------- - -U-Boot sandbox can be used to run various tests, mostly in the test/ -directory. These include: - - command_ut - - Unit tests for command parsing and handling - compression - - Unit tests for U-Boot's compression algorithms, useful for - security checking. It supports gzip, bzip2, lzma and lzo. - driver model - - test/dm/test-dm.sh to run these. - image - - Unit tests for images: - test/image/test-imagetools.sh - multi-file images - test/image/test-fit.py - FIT images - tracing - - test/trace/test-trace.sh tests the tracing system (see README.trace) - verified boot - - See test/vboot/vboot_test.sh for this - -If you change or enhance any of the above subsystems, you shold write or -expand a test and include it with your patch series submission. Test -coverage in U-Boot is limited, as we need to work to improve it. - -Note that many of these tests are implemented as commands which you can -run natively on your board if desired (and enabled). - -It would be useful to have a central script to run all of these. - --- -Simon Glass -Updated 22-Mar-14 diff --git a/board/sandbox/sandbox/sandbox.c b/board/sandbox/sandbox/sandbox.c deleted file mode 100644 index e4d4e021bc..0000000000 --- a/board/sandbox/sandbox/sandbox.c +++ /dev/null @@ -1,83 +0,0 @@ -/* - * Copyright (c) 2011 The Chromium OS Authors. - * SPDX-License-Identifier: GPL-2.0+ - */ - -#include -#include -#include -#include -#include - -/* - * Pointer to initial global data area - * - * Here we initialize it. - */ -gd_t *gd; - -/* Add a simple GPIO device */ -U_BOOT_DEVICE(gpio_sandbox) = { - .name = "gpio_sandbox", -}; - -void flush_cache(unsigned long start, unsigned long size) -{ -} - -unsigned long timer_read_counter(void) -{ - return os_get_nsec() / 1000; -} - -int dram_init(void) -{ - gd->ram_size = CONFIG_SYS_SDRAM_SIZE; - return 0; -} - -#ifdef CONFIG_BOARD_EARLY_INIT_F -int board_early_init_f(void) -{ -#ifdef CONFIG_VIDEO_SANDBOX_SDL - int ret; - - ret = sandbox_lcd_sdl_early_init(); - if (ret) { - puts("Could not init sandbox LCD emulation\n"); - return ret; - } -#endif - - return 0; -} -#endif - -int arch_early_init_r(void) -{ -#ifdef CONFIG_CROS_EC - if (cros_ec_board_init()) { - printf("%s: Failed to init EC\n", __func__); - return 0; - } -#endif - - return 0; -} - -#ifdef CONFIG_BOARD_LATE_INIT -int board_late_init(void) -{ - if (cros_ec_get_error()) { - /* Force console on */ - gd->flags &= ~GD_FLG_SILENT; - - printf("cros-ec communications failure %d\n", - cros_ec_get_error()); - puts("\nPlease reset with Power+Refresh\n\n"); - panic("Cannot init cros-ec device"); - return -1; - } - return 0; -} -#endif diff --git a/boards.cfg b/boards.cfg index 983c657f54..8f5ee64596 100644 --- a/boards.cfg +++ b/boards.cfg @@ -1179,7 +1179,7 @@ Active powerpc ppc4xx - xilinx ppc405-generic Active powerpc ppc4xx - xilinx ppc405-generic xilinx-ppc405-generic_flash xilinx-ppc405-generic:SYS_TEXT_BASE=0xF7F60000,RESET_VECTOR_ADDRESS=0xF7FFFFFC Ricardo Ribalda Active powerpc ppc4xx - xilinx ppc440-generic xilinx-ppc440-generic xilinx-ppc440-generic:SYS_TEXT_BASE=0x04000000,RESET_VECTOR_ADDRESS=0x04100000,BOOT_FROM_XMD=1 Ricardo Ribalda Active powerpc ppc4xx - xilinx ppc440-generic xilinx-ppc440-generic_flash xilinx-ppc440-generic:SYS_TEXT_BASE=0xF7F60000,RESET_VECTOR_ADDRESS=0xF7FFFFFC Ricardo Ribalda -Active sandbox sandbox - sandbox sandbox sandbox - Simon Glass +Active sandbox sandbox - - sandbox - Simon Glass Active sh sh2 - renesas rsk7203 rsk7203 - Nobuhiro Iwamatsu :Nobuhiro Iwamatsu Active sh sh2 - renesas rsk7264 rsk7264 - Phil Edworthy Active sh sh2 - renesas rsk7269 rsk7269 - - diff --git a/doc/README.sandbox b/doc/README.sandbox new file mode 100644 index 0000000000..529c447a5b --- /dev/null +++ b/doc/README.sandbox @@ -0,0 +1,299 @@ +/* + * Copyright (c) 2014 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. + + +Basic Operation +--------------- + +To run sandbox U-Boot use something like: + + make sandbox_config all + ./u-boot + +Note: + If you get errors about 'sdl-config: Command not found' you may need to + install libsdl1.2-dev or similar to get SDL support. Alternatively you can + build sandbox without SDL (i.e. no display/keyboard support) by removing + the CONFIG_SANDBOX_SDL line in include/configs/sandbox.h or using: + + make sandbox_config all NO_SDL=1 + ./u-boot + + +U-Boot will start on your computer, showing a sandbox emulation of the serial +console: + + +U-Boot 2014.04 (Mar 20 2014 - 19:06:00) + +DRAM: 128 MiB +Using default environment + +In: serial +Out: lcd +Err: lcd +=> + +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. + +To exit, type 'reset' or press Ctrl-C. + + +Console / LCD support +--------------------- + +Assuming that CONFIG_SANDBOX_SDL is defined when building, you can run the +sandbox with LCD and keyboard emulation, using something like: + + ./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 +available options. Some of these are described below. + +The terminal is normally in what is called 'raw-with-sigs' mode. This means +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). + +As mentioned above, -l causes the LCD emulation window to be shown. + +A device tree binary file can be provided with -d. If you edit the source +(it is stored at arch/sandbox/dts/sandbox.dts) you must rebuild U-Boot to +recreate the binary file. + +To execute commands directly, use the -c option. You can specify a single +command, or multiple commands separated by a semicolon, as is normal in +U-Boot. Be careful with quoting as the shall will normally process and +swallow quotes. When -c is used, U-Boot exists after the command is complete, +but you can force it to go to interactive mode instead with -i. + + +Memory Emulation +---------------- + +Memory emulation is supported, with the size set by CONFIG_SYS_SDRAM_SIZE. +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) +- Keyboard (Chrome OS) +- LCD +- Serial (for console only) +- Sound (incomplete - see sandbox_sdl_sound_init() for details) +- SPI +- SPI flash +- TPM (Trusted Platform Module) + +Notable omissions are networking and I2C. + +A wide range of commands is implemented. Filesystems which use a block +device are supported. + +Also sandbox uses generic board (CONFIG_SYS_GENERIC_BOARD) and supports +driver model (CONFIG_DM) and associated commands. + + +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 + + +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. + + +Testing +------- + +U-Boot sandbox can be used to run various tests, mostly in the test/ +directory. These include: + + command_ut + - Unit tests for command parsing and handling + compression + - Unit tests for U-Boot's compression algorithms, useful for + security checking. It supports gzip, bzip2, lzma and lzo. + driver model + - test/dm/test-dm.sh to run these. + image + - Unit tests for images: + test/image/test-imagetools.sh - multi-file images + test/image/test-fit.py - FIT images + tracing + - test/trace/test-trace.sh tests the tracing system (see README.trace) + verified boot + - See test/vboot/vboot_test.sh for this + +If you change or enhance any of the above subsystems, you shold write or +expand a test and include it with your patch series submission. Test +coverage in U-Boot is limited, as we need to work to improve it. + +Note that many of these tests are implemented as commands which you can +run natively on your board if desired (and enabled). + +It would be useful to have a central script to run all of these. + +-- +Simon Glass +Updated 22-Mar-14 -- cgit v1.2.3 From 097c5de5f4a64d3b121dc1dbe020f7f2545dabdb Mon Sep 17 00:00:00 2001 From: Masahiro Yamada Date: Mon, 21 Apr 2014 18:50:41 +0900 Subject: sandbox: ignore sandbox.dtb Signed-off-by: Masahiro Yamada Cc: Simon Glass Acked-by: Simon Glass --- arch/sandbox/dts/.gitignore | 1 + 1 file changed, 1 insertion(+) create mode 100644 arch/sandbox/dts/.gitignore diff --git a/arch/sandbox/dts/.gitignore b/arch/sandbox/dts/.gitignore new file mode 100644 index 0000000000..b60ed208c7 --- /dev/null +++ b/arch/sandbox/dts/.gitignore @@ -0,0 +1 @@ +*.dtb -- cgit v1.2.3