diff options
| -rw-r--r-- | arch/arm/mach-exynos/include/mach/dwmmc.h | 2 | ||||
| -rw-r--r-- | board/samsung/arndale/arndale.c | 13 | ||||
| -rw-r--r-- | common/image-fit-sig.c | 14 | ||||
| -rw-r--r-- | common/image-fit.c | 15 | ||||
| -rw-r--r-- | doc/Makefile | 2 | ||||
| -rw-r--r-- | doc/README.menu | 124 | ||||
| -rw-r--r-- | doc/develop/index.rst | 25 | ||||
| -rw-r--r-- | doc/develop/menus.rst | 131 | ||||
| -rw-r--r-- | doc/develop/py_testing.rst (renamed from test/py/README.md) | 251 | ||||
| -rw-r--r-- | doc/develop/testing.rst (renamed from test/README) | 0 | ||||
| -rw-r--r-- | doc/uImage.FIT/source_file_format.txt | 33 | ||||
| -rw-r--r-- | drivers/mmc/exynos_dw_mmc.c | 56 | ||||
| -rw-r--r-- | tools/Makefile | 2 | ||||
| -rw-r--r-- | tools/env/fw_env.c | 2 | ||||
| -rw-r--r-- | tools/image-host.c | 152 | ||||
| -rw-r--r-- | tools/mkimage.c | 11 |
16 files changed, 424 insertions, 409 deletions
diff --git a/arch/arm/mach-exynos/include/mach/dwmmc.h b/arch/arm/mach-exynos/include/mach/dwmmc.h index 5654a0ea6b..59c28ed54c 100644 --- a/arch/arm/mach-exynos/include/mach/dwmmc.h +++ b/arch/arm/mach-exynos/include/mach/dwmmc.h @@ -25,5 +25,3 @@ /* CLKSEL Register */ #define DWMCI_DIVRATIO_BIT 24 #define DWMCI_DIVRATIO_MASK 0x7 - -int exynos_dwmmc_init(const void *blob); diff --git a/board/samsung/arndale/arndale.c b/board/samsung/arndale/arndale.c index 91813763ce..d283ef6275 100644 --- a/board/samsung/arndale/arndale.c +++ b/board/samsung/arndale/arndale.c @@ -73,19 +73,6 @@ int dram_init_banksize(void) return 0; } -#ifdef CONFIG_MMC -int board_mmc_init(struct bd_info *bis) -{ - int ret; - /* dwmmc initializattion for available channels */ - ret = exynos_dwmmc_init(gd->fdt_blob); - if (ret) - debug("dwmmc init failed\n"); - - return ret; -} -#endif - static int board_uart_init(void) { int err = 0, uart_id; diff --git a/common/image-fit-sig.c b/common/image-fit-sig.c index 5401d9411b..d39741e905 100644 --- a/common/image-fit-sig.c +++ b/common/image-fit-sig.c @@ -19,20 +19,6 @@ DECLARE_GLOBAL_DATA_PTR; #define IMAGE_MAX_HASHED_NODES 100 -#ifdef USE_HOSTCC -void *host_blob; - -void image_set_host_blob(void *blob) -{ - host_blob = blob; -} - -void *image_get_host_blob(void) -{ - return host_blob; -} -#endif - /** * fit_region_make_list() - Make a list of image regions * diff --git a/common/image-fit.c b/common/image-fit.c index 21c44bdf69..8660c3fd81 100644 --- a/common/image-fit.c +++ b/common/image-fit.c @@ -112,6 +112,21 @@ int fit_parse_subimage(const char *spec, ulong addr_curr, } #endif /* !USE_HOSTCC */ +#ifdef USE_HOSTCC +/* Host tools use these implementations for Cipher and Signature support */ +static void *host_blob; + +void image_set_host_blob(void *blob) +{ + host_blob = blob; +} + +void *image_get_host_blob(void) +{ + return host_blob; +} +#endif /* USE_HOSTCC */ + static void fit_get_debug(const void *fit, int noffset, char *prop_name, int err) { diff --git a/doc/Makefile b/doc/Makefile index 0e0da5666f..a686d4728e 100644 --- a/doc/Makefile +++ b/doc/Makefile @@ -106,7 +106,7 @@ cleandocs: $(Q)$(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) $(build)=doc/media clean dochelp: - @echo ' Linux kernel internal documentation in different formats from ReST:' + @echo ' U-Boot documentation in different formats from ReST:' @echo ' htmldocs - HTML' @echo ' latexdocs - LaTeX' @echo ' pdfdocs - PDF' diff --git a/doc/README.menu b/doc/README.menu deleted file mode 100644 index 0f3d741605..0000000000 --- a/doc/README.menu +++ /dev/null @@ -1,124 +0,0 @@ -SPDX-License-Identifier: GPL-2.0+ -/* - * Copyright 2010-2011 Calxeda, Inc. - */ - -U-Boot provides a set of interfaces for creating and using simple, text -based menus. Menus are displayed as lists of labeled entries on the -console, and an entry can be selected by entering its label. - -To use the menu code, enable CONFIG_MENU, and include "menu.h" where -the interfaces should be available. - -Menus are composed of items. Each item has a key used to identify it in -the menu, and an opaque pointer to data controlled by the consumer. - -If you want to show a menu, instead starting the shell, define -CONFIG_AUTOBOOT_MENU_SHOW. You have to code the int menu_show(int bootdelay) -function, which handle your menu. This function returns the remaining -bootdelay. - -Interfaces ----------- -#include "menu.h" - -/* - * Consumers of the menu interfaces will use a struct menu * as the - * handle for a menu. struct menu is only fully defined in menu.c, - * preventing consumers of the menu interfaces from accessing its - * contents directly. - */ -struct menu; - -/* - * NOTE: See comments in common/menu.c for more detailed documentation on - * these interfaces. - */ - -/* - * menu_create() - Creates a menu handle with default settings - */ -struct menu *menu_create(char *title, int timeout, int prompt, - void (*item_data_print)(void *), - char *(*item_choice)(void *), - void *item_choice_data); - -/* - * menu_item_add() - Adds or replaces a menu item - */ -int menu_item_add(struct menu *m, char *item_key, void *item_data); - -/* - * menu_default_set() - Sets the default choice for the menu - */ -int menu_default_set(struct menu *m, char *item_key); - -/* - * menu_default_choice() - Set *choice to point to the default item's data - */ -int menu_default_choice(struct menu *m, void **choice); - -/* - * menu_get_choice() - Returns the user's selected menu entry, or the - * default if the menu is set to not prompt or the timeout expires. - */ -int menu_get_choice(struct menu *m, void **choice); - -/* - * menu_destroy() - frees the memory used by a menu and its items. - */ -int menu_destroy(struct menu *m); - -/* - * menu_display_statusline(struct menu *m); - * shows a statusline for every menu_display call. - */ -void menu_display_statusline(struct menu *m); - -Example Code ------------- -This example creates a menu that always prompts, and allows the user -to pick from a list of tools. The item key and data are the same. - -#include "menu.h" - -char *tools[] = { - "Hammer", - "Screwdriver", - "Nail gun", - NULL -}; - -char *pick_a_tool(void) -{ - struct menu *m; - int i; - char *tool = NULL; - - m = menu_create("Tools", 0, 1, NULL); - - for(i = 0; tools[i]; i++) { - if (menu_item_add(m, tools[i], tools[i]) != 1) { - printf("failed to add item!"); - menu_destroy(m); - return NULL; - } - } - - if (menu_get_choice(m, (void **)&tool) != 1) - printf("Problem picking tool!\n"); - - menu_destroy(m); - - return tool; -} - -void caller(void) -{ - char *tool = pick_a_tool(); - - if (tool) { - printf("picked a tool: %s\n", tool); - use_tool(tool); - } -} diff --git a/doc/develop/index.rst b/doc/develop/index.rst index 0a7e204b34..beaa64d8d9 100644 --- a/doc/develop/index.rst +++ b/doc/develop/index.rst @@ -3,13 +3,32 @@ Develop U-Boot ============== +Implementation +-------------- .. toctree:: - :maxdepth: 2 + :maxdepth: 1 - coccinelle commands - crash_dumps global_data logging + menus + +Debugging +--------- + +.. toctree:: + :maxdepth: 1 + + crash_dumps trace + +Testing +------- + +.. toctree:: + :maxdepth: 1 + + coccinelle + testing + py_testing diff --git a/doc/develop/menus.rst b/doc/develop/menus.rst new file mode 100644 index 0000000000..dda8f963fb --- /dev/null +++ b/doc/develop/menus.rst @@ -0,0 +1,131 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. Copyright 2010-2011 Calxeda, Inc. + +Menus +===== + +U-Boot provides a set of interfaces for creating and using simple, text +based menus. Menus are displayed as lists of labeled entries on the +console, and an entry can be selected by entering its label. + +To use the menu code, enable CONFIG_MENU, and include "menu.h" where +the interfaces should be available. + +Menus are composed of items. Each item has a key used to identify it in +the menu, and an opaque pointer to data controlled by the consumer. + +If you want to show a menu, instead starting the shell, define +CONFIG_AUTOBOOT_MENU_SHOW. You have to code the int menu_show(int bootdelay) +function, which handle your menu. This function returns the remaining +bootdelay. + +Interfaces +---------- + +.. code-block:: c + + #include "menu.h" + + /* + * Consumers of the menu interfaces will use a struct menu * as the + * handle for a menu. struct menu is only fully defined in menu.c, + * preventing consumers of the menu interfaces from accessing its + * contents directly. + */ + struct menu; + + /* + * NOTE: See comments in common/menu.c for more detailed documentation on + * these interfaces. + */ + + /* + * menu_create() - Creates a menu handle with default settings + */ + struct menu *menu_create(char *title, int timeout, int prompt, + void (*item_data_print)(void *), + char *(*item_choice)(void *), + void *item_choice_data); + + /* + * menu_item_add() - Adds or replaces a menu item + */ + int menu_item_add(struct menu *m, char *item_key, void *item_data); + + /* + * menu_default_set() - Sets the default choice for the menu + */ + int menu_default_set(struct menu *m, char *item_key); + + /* + * menu_default_choice() - Set *choice to point to the default item's data + */ + int menu_default_choice(struct menu *m, void **choice); + + /* + * menu_get_choice() - Returns the user's selected menu entry, or the + * default if the menu is set to not prompt or the timeout expires. + */ + int menu_get_choice(struct menu *m, void **choice); + + /* + * menu_destroy() - frees the memory used by a menu and its items. + */ + int menu_destroy(struct menu *m); + + /* + * menu_display_statusline(struct menu *m); + * shows a statusline for every menu_display call. + */ + void menu_display_statusline(struct menu *m); + +Example Code +------------ + +This example creates a menu that always prompts, and allows the user +to pick from a list of tools. The item key and data are the same. + +.. code-block:: c + + #include "menu.h" + + char *tools[] = { + "Hammer", + "Screwdriver", + "Nail gun", + NULL + }; + + char *pick_a_tool(void) + { + struct menu *m; + int i; + char *tool = NULL; + + m = menu_create("Tools", 0, 1, NULL); + + for(i = 0; tools[i]; i++) { + if (menu_item_add(m, tools[i], tools[i]) != 1) { + printf("failed to add item!"); + menu_destroy(m); + return NULL; + } + } + + if (menu_get_choice(m, (void **)&tool) != 1) + printf("Problem picking tool!\n"); + + menu_destroy(m); + + return tool; + } + + void caller(void) + { + char *tool = pick_a_tool(); + + if (tool) { + printf("picked a tool: %s\n", tool); + use_tool(tool); + } + } diff --git a/test/py/README.md b/doc/develop/py_testing.rst index fddc104b26..f71e837aa9 100644 --- a/test/py/README.md +++ b/doc/develop/py_testing.rst @@ -1,6 +1,8 @@ -# U-Boot pytest suite +U-Boot pytest suite +=================== -## Introduction +Introduction +------------ This tool aims to test U-Boot by executing U-Boot shell commands using the console interface. A single top-level script exists to execute or attach to the @@ -14,40 +16,42 @@ results. Advantages of this approach are: flexible than writing it all in C. - It is reasonably simple to interact with U-Boot in this way. -## Requirements +Requirements +------------ The test suite is implemented using pytest. Interaction with the U-Boot console involves executing some binary and interacting with its stdin/stdout. You will need to implement various "hook" scripts that are called by the test suite at the appropriate time. -In order to run the testsuite at a minimum we require that both python3 and -pip for python3 be installed. All of the required python modules are -described in the requirements.txt file in this directory and can be installed -with the command ```pip install -r requirements.txt``` +In order to run the test suite at a minimum we require that both Python 3 and +pip for Python 3 are installed. All of the required python modules are +described in the requirements.txt file in the /test/py/ directory and can be +installed via the command + +.. code-block:: bash + + pip install -r requirements.txt In order to execute certain tests on their supported platforms other tools -will be required. The following is an incomplete list: - -| Package | -| -------------- | -| gdisk | -| dfu-util | -| dtc | -| openssl | -| sudo OR guestmount | -| e2fsprogs | -| util-linux | -| coreutils | -| dosfstools | -| efitools | -| mount | -| mtools | -| sbsigntool | -| udisks2 | - - -Please use the apporirate commands for your distribution to match these tools +will be required. The following is an incomplete list: + +* gdisk +* dfu-util +* dtc +* openssl +* sudo OR guestmount +* e2fsprogs +* util-linux +* coreutils +* dosfstools +* efitools +* mount +* mtools +* sbsigntool +* udisks2 + +Please use the appropriate commands for your distribution to match these tools up with the package that provides them. The test script supports either: @@ -58,28 +62,31 @@ The test script supports either: physical board, attach to the board's console stream, and reset the board. Further details are described later. -### Using `virtualenv` to provide requirements +Using `virtualenv` to provide requirements +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The recommended way to run the test suite, in order to ensure reproducibility is to use `virtualenv` to set up the necessary environment. This can be done via the following commands: -```bash -$ cd /path/to/u-boot -$ sudo apt-get install python3 python3-virtualenv -$ virtualenv -p /usr/bin/python3 venv -$ . ./venv/bin/activate -$ pip install -r test/py/requirements.txt -``` -## Testing sandbox +.. code-block:: console + + $ cd /path/to/u-boot + $ sudo apt-get install python3 python3-virtualenv + $ virtualenv -p /usr/bin/python3 venv + $ . ./venv/bin/activate + $ pip install -r test/py/requirements.txt -To run the testsuite on the sandbox port (U-Boot built as a native user-space +Testing sandbox +--------------- + +To run the test suite on the sandbox port (U-Boot built as a native user-space application), simply execute: -``` -./test/py/test.py --bd sandbox --build -``` +.. code-block:: bash + + ./test/py/test.py --bd sandbox --build The `--bd` option tells the test suite which board type is being tested. This lets the test suite know which features the board has, and hence exactly what @@ -95,7 +102,8 @@ will be written to `${build_dir}/test-log.html`. This is best viewed in a web browser, but may be read directly as plain text, perhaps with the aid of the `html2text` utility. -### Testing under a debugger +Testing under a debugger +~~~~~~~~~~~~~~~~~~~~~~~~ If you need to run sandbox under a debugger, you may pass the command-line option `--gdbserver COMM`. This causes two things to happens: @@ -111,19 +119,21 @@ option `--gdbserver COMM`. This causes two things to happens: A usage example is: Window 1: -```shell -./test/py/test.py --bd sandbox --gdbserver localhost:1234 -``` + +.. code-block:: bash + + ./test/py/test.py --bd sandbox --gdbserver localhost:1234 Window 2: -```shell -gdb ./build-sandbox/u-boot -ex 'target remote localhost:1234' -``` + +.. code-block:: bash + + gdb ./build-sandbox/u-boot -ex 'target remote localhost:1234' Alternatively, you could leave off the `-ex` option and type the command manually into gdb once it starts. -You can use any debugger you wish, so long as it speaks the gdb remote +You can use any debugger you wish, as long as it speaks the gdb remote protocol, or any graphical wrapper around gdb. Some tests deliberately cause the sandbox process to exit, e.g. to test the @@ -132,30 +142,39 @@ to attach the debugger to the new sandbox instance. If these tests are not relevant to your debugging session, you can skip them using pytest's -k command-line option; see the next section. -## Command-line options - -- `--board-type`, `--bd`, `-B` set the type of the board to be tested. For - example, `sandbox` or `seaboard`. -- `--board-identity`, `--id` set the identity of the board to be tested. - This allows differentiation between multiple instances of the same type of - physical board that are attached to the same host machine. This parameter is - not interpreted by the test script in any way, but rather is simply passed - to the hook scripts described below, and may be used in any site-specific - way deemed necessary. -- `--build` indicates that the test script should compile U-Boot itself - before running the tests. If using this option, make sure that any - environment variables required by the build process are already set, such as - `$CROSS_COMPILE`. -- `--buildman` indicates that `--build` should use buildman to build U-Boot. - There is no need to set $CROSS_COMPILE` in this case since buildman handles - it. -- `--build-dir` sets the directory containing the compiled U-Boot binaries. - If omitted, this is `${source_dir}/build-${board_type}`. -- `--result-dir` sets the directory to write results, such as log files, - into. If omitted, the build directory is used. -- `--persistent-data-dir` sets the directory used to store persistent test - data. This is test data that may be re-used across test runs, such as file- - system images. +Command-line options +-------------------- + +--board-type, --bd, -B + set the type of the board to be tested. For example, `sandbox` or `seaboard`. + +--board-identity`, --id + sets the identity of the board to be tested. This allows differentiation + between multiple instances of the same type of physical board that are + attached to the same host machine. This parameter is not interpreted by th + test script in any way, but rather is simply passed to the hook scripts + described below, and may be used in any site-specific way deemed necessary. + +--build + indicates that the test script should compile U-Boot itself before running + the tests. If using this option, make sure that any environment variables + required by the build process are already set, such as `$CROSS_COMPILE`. + +--buildman + indicates that `--build` should use buildman to build U-Boot. There is no need + to set $CROSS_COMPILE` in this case since buildman handles it. + +--build-dir + sets the directory containing the compiled U-Boot binaries. If omitted, this + is `${source_dir}/build-${board_type}`. + +--result-dir + sets the directory to write results, such as log files, into. + If omitted, the build directory is used. + +--persistent-data-dir + sets the directory used to store persistent test data. This is test data that + may be re-used across test runs, such as file-system images. `pytest` also implements a number of its own command-line options. Commonly used options are mentioned below. Please see `pytest` documentation for complete @@ -163,21 +182,26 @@ details. Execute `py.test --version` for a brief summary. Note that U-Boot's test.py script passes all command-line arguments directly to `pytest` for processing. -- `-k` selects which tests to run. The default is to run all known tests. This +-k + selects which tests to run. The default is to run all known tests. This option takes a single argument which is used to filter test names. Simple logical operators are supported. For example: - - `'ums'` runs only tests with "ums" in their name. - - `'ut_dm'` runs only tests with "ut_dm" in their name. Note that in this + + - `'-k ums'` runs only tests with "ums" in their name. + - `'-k ut_dm'` runs only tests with "ut_dm" in their name. Note that in this case, "ut_dm" is a parameter to a test rather than the test name. The full test name is e.g. "test_ut[ut_dm_leak]". - - `'not reset'` runs everything except tests with "reset" in their name. - - `'ut or hush'` runs only tests with "ut" or "hush" in their name. - - `'not (ut or hush)'` runs everything except tests with "ut" or "hush" in + - `'-k not reset'` runs everything except tests with "reset" in their name. + - `'-k ut or hush'` runs only tests with "ut" or "hush" in their name. + - `'-k not (ut or hush)'` runs everything except tests with "ut" or "hush" in their name. -- `-s` prevents pytest from hiding a test's stdout. This allows you to see + +-s + prevents pytest from hiding a test's stdout. This allows you to see U-Boot's console log in real time on pytest's stdout. -## Testing real hardware +Testing real hardware +--------------------- The tools and techniques used to interact with real hardware will vary radically between different host and target systems, and the whims of the user. @@ -187,9 +211,11 @@ via `$PATH`. These scripts implement certain actions on behalf of the test suite. This keeps the test suite simple and isolated from system variances unrelated to U-Boot features. -### Hook scripts +Hook scripts +~~~~~~~~~~~~ -#### Environment variables +Environment variables +''''''''''''''''''''' The following environment variables are set when running hook scripts: @@ -202,16 +228,18 @@ The following environment variables are set when running hook scripts: - `UBOOT_RESULT_DIR` the test result directory. - `UBOOT_PERSISTENT_DATA_DIR` the test persistent data directory. -#### `u-boot-test-console` +u-boot-test-console +''''''''''''''''''' This script provides access to the U-Boot console. The script's stdin/stdout should be connected to the board's console. This process should continue to run indefinitely, until killed. The test suite will run this script in parallel with all other hooks. -This script may be implemented e.g. by exec()ing `cu`, `kermit`, `conmux`, etc. +This script may be implemented e.g. by executing `cu`, `kermit`, `conmux`, etc. +via exec(). -If you are able to run U-Boot under a hardware simulator such as qemu, then +If you are able to run U-Boot under a hardware simulator such as QEMU, then you would likely spawn that simulator from this script. However, note that `u-boot-test-reset` may be called multiple times per test script run, and must cause U-Boot to start execution from scratch each time. Hopefully your @@ -219,10 +247,11 @@ simulator includes a virtual reset button! If not, you can launch the simulator from `u-boot-test-reset` instead, while arranging for this console process to always communicate with the current simulator instance. -#### `u-boot-test-flash` +u-boot-test-flash +''''''''''''''''' Prior to running the test suite against a board, some arrangement must be made -so that the board executes the particular U-Boot binary to be tested. Often, +so that the board executes the particular U-Boot binary to be tested. Often this involves writing the U-Boot binary to the board's flash ROM. The test suite calls this hook script for that purpose. @@ -248,7 +277,8 @@ hook script appropriately. This script will typically be implemented by calling out to some SoC- or board-specific vendor flashing utility. -#### `u-boot-test-reset` +u-boot-test-reset +''''''''''''''''' Whenever the test suite needs to reset the target board, this script is executed. This is guaranteed to happen at least once, prior to executing the @@ -261,20 +291,22 @@ relay or electronic switch attached to the board's reset signal. The semantics of this script require that when it is executed, U-Boot will start running from scratch. If the U-Boot binary to be tested has been written -to flash, pulsing the board's reset signal is likely all this script need do. -However, in some scenarios, this script may perform other actions. For +to flash, pulsing the board's reset signal is likely all this script needs to +do. However, in some scenarios, this script may perform other actions. For example, it may call out to some SoC- or board-specific vendor utility in order to download the U-Boot binary directly into RAM and execute it. This would avoid the need for `u-boot-test-flash` to actually write U-Boot to flash, thus saving wear on the flash chip(s). -#### Examples +Examples +'''''''' https://github.com/swarren/uboot-test-hooks contains some working example hook scripts, and may be useful as a reference when implementing hook scripts for your platform. These scripts are not considered part of U-Boot itself. -### Board-type-specific configuration +Board-type-specific configuration +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Each board has a different configuration and behaviour. Many of these differences can be automatically detected by parsing the `.config` file in the @@ -286,7 +318,8 @@ defined in these modules is available for use by any test function. The data contained in these scripts must be purely derived from U-Boot source code. Hence, these configuration files are part of the U-Boot source tree too. -### Execution environment configuration +Execution environment configuration +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Each user's hardware setup may enable testing different subsets of the features implemented by a particular board's configuration of U-Boot. For example, a @@ -304,14 +337,16 @@ U-Boot source tree, and should be installed outside of the source tree. Users should set `$PYTHONPATH` prior to running the test script to allow these modules to be loaded. -### Board module parameter usage +Board module parameter usage +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The test scripts rely on the following variables being defined by the board module: -- None at present. +- none at present -### U-Boot `.config` feature usage +U-Boot `.config` feature usage +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The test scripts rely on various U-Boot `.config` features, either directly in order to test those features, or indirectly in order to query information from @@ -328,7 +363,8 @@ instances of: - `@pytest.mark.buildconfigspec(...` - `@pytest.mark.notbuildconfigspec(...` -### Complete invocation example +Complete invocation example +~~~~~~~~~~~~~~~~~~~~~~~~~~~ Assuming that you have installed the hook scripts into $HOME/ubtest/bin, and any required environment configuration Python modules into $HOME/ubtest/py, @@ -336,32 +372,33 @@ then you would likely invoke the test script as follows: If U-Boot has already been built: -```bash -PATH=$HOME/ubtest/bin:$PATH \ +.. code-block:: bash + + PATH=$HOME/ubtest/bin:$PATH \ PYTHONPATH=${HOME}/ubtest/py/${HOSTNAME}:${PYTHONPATH} \ ./test/py/test.py --bd seaboard -``` If you want the test script to compile U-Boot for you too, then you likely need to set `$CROSS_COMPILE` to allow this, and invoke the test script as follows: -```bash -CROSS_COMPILE=arm-none-eabi- \ +.. code-block:: bash + + CROSS_COMPILE=arm-none-eabi- \ PATH=$HOME/ubtest/bin:$PATH \ PYTHONPATH=${HOME}/ubtest/py/${HOSTNAME}:${PYTHONPATH} \ ./test/py/test.py --bd seaboard --build -``` or, using buildman to handle it: -```bash +.. code-block:: bash + PATH=$HOME/ubtest/bin:$PATH \ PYTHONPATH=${HOME}/ubtest/py/${HOSTNAME}:${PYTHONPATH} \ ./test/py/test.py --bd seaboard --build --buildman -``` -## Writing tests +Writing tests +------------- Please refer to the pytest documentation for details of writing pytest tests. Details specific to the U-Boot test suite are described below. diff --git a/test/README b/doc/develop/testing.rst index 4bc9ca3a6a..4bc9ca3a6a 100644 --- a/test/README +++ b/doc/develop/testing.rst diff --git a/doc/uImage.FIT/source_file_format.txt b/doc/uImage.FIT/source_file_format.txt index 633f227c59..00ed3ebe93 100644 --- a/doc/uImage.FIT/source_file_format.txt +++ b/doc/uImage.FIT/source_file_format.txt @@ -126,12 +126,10 @@ Root node of the uImage Tree should have the following layout: load addresses supplied within sub-image nodes. May be omitted when no entry or load addresses are used. - Mandatory node: + Mandatory nodes: - images : This node contains a set of sub-nodes, each of them representing single component sub-image (like kernel, ramdisk, etc.). At least one sub-image is required. - - Optional node: - configurations : Contains a set of available configuration nodes and defines a default configuration. @@ -169,8 +167,8 @@ the '/images' node should have the following layout: to "none". Conditionally mandatory property: - - os : OS name, mandatory for types "kernel" and "ramdisk". Valid OS names - are: "openbsd", "netbsd", "freebsd", "4_4bsd", "linux", "svr4", "esix", + - os : OS name, mandatory for types "kernel". Valid OS names are: + "openbsd", "netbsd", "freebsd", "4_4bsd", "linux", "svr4", "esix", "solaris", "irix", "sco", "dell", "ncr", "lynxos", "vxworks", "psos", "qnx", "u-boot", "rtems", "unity", "integrity". - arch : Architecture name, mandatory for types: "standalone", "kernel", @@ -179,10 +177,13 @@ the '/images' node should have the following layout: "sparc64", "m68k", "microblaze", "nios2", "blackfin", "avr32", "st200", "sandbox". - entry : entry point address, address size is determined by - '#address-cells' property of the root node. Mandatory for for types: - "standalone" and "kernel". + '#address-cells' property of the root node. + Mandatory for types: "firmware", and "kernel". - load : load address, address size is determined by '#address-cells' - property of the root node. Mandatory for types: "standalone" and "kernel". + property of the root node. + Mandatory for types: "firmware", and "kernel". + - compatible : compatible method for loading image. + Mandatory for types: "fpga", and images that do not specify a load address. Optional nodes: - hash-1 : Each hash sub-node represents separate hash or checksum @@ -205,9 +206,8 @@ o hash-1 6) '/configurations' node ------------------------- -The 'configurations' node is optional. If present, it allows to create a -convenient, labeled boot configurations, which combine together kernel images -with their ramdisks and fdt blobs. +The 'configurations' node creates convenient, labeled boot configurations, +which combine together kernel images with their ramdisks and fdt blobs. The 'configurations' node has has the following structure: @@ -236,27 +236,22 @@ Each configuration has the following structure: o config-1 |- description = "configuration description" |- kernel = "kernel sub-node unit name" - |- ramdisk = "ramdisk sub-node unit name" |- fdt = "fdt sub-node unit-name" [, "fdt overlay sub-node unit-name", ...] - |- fpga = "fpga sub-node unit-name" |- loadables = "loadables sub-node unit-name" |- compatible = "vendor,board-style device tree compatible string" Mandatory properties: - description : Textual configuration description. - - kernel : Unit name of the corresponding kernel image (image sub-node of a - "kernel" type). + - kernel or firmware: Unit name of the corresponding kernel or firmware + (u-boot, op-tee, etc) image. If both "kernel" and "firmware" are specified, + control is passed to the firmware image. Optional properties: - - ramdisk : Unit name of the corresponding ramdisk image (component image - node of a "ramdisk" type). - fdt : Unit name of the corresponding fdt blob (component image node of a "fdt type"). Additional fdt overlay nodes can be supplied which signify that the resulting device tree blob is generated by the first base fdt blob with all subsequent overlays applied. - - setup : Unit name of the corresponding setup binary (used for booting - an x86 kernel). This contains the setup.bin file built by the kernel. - fpga : Unit name of the corresponding fpga bitstream blob (component image node of a "fpga type"). - loadables : Unit name containing a list of additional binaries to be diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c index 2fc1ef18c7..b4ff1c3fb4 100644 --- a/drivers/mmc/exynos_dw_mmc.c +++ b/drivers/mmc/exynos_dw_mmc.c @@ -135,8 +135,6 @@ static int exynos_dwmci_core_init(struct dwmci_host *host) return 0; } -static struct dwmci_host dwmci_host[DWMMC_MAX_CH_NUM]; - static int do_dwmci_init(struct dwmci_host *host) { int flag, err; @@ -208,60 +206,6 @@ static int exynos_dwmci_get_config(const void *blob, int node, return 0; } -static int exynos_dwmci_process_node(const void *blob, - int node_list[], int count) -{ - struct dwmci_exynos_priv_data *priv; - struct dwmci_host *host; - int i, node, err; - - for (i = 0; i < count; i++) { - node = node_list[i]; - if (node <= 0) - continue; - host = &dwmci_host[i]; - - priv = malloc(sizeof(struct dwmci_exynos_priv_data)); - if (!priv) { - pr_err("dwmci_exynos_priv_data malloc fail!\n"); - return -ENOMEM; - } - - err = exynos_dwmci_get_config(blob, node, host, priv); - if (err) { - printf("%s: failed to decode dev %d\n", __func__, i); - free(priv); - return err; - } - host->priv = priv; - - do_dwmci_init(host); - } - return 0; -} - -int exynos_dwmmc_init(const void *blob) -{ - int node_list[DWMMC_MAX_CH_NUM]; - int boot_dev_node; - int err = 0, count; - - count = fdtdec_find_aliases_for_id(blob, "mmc", - COMPAT_SAMSUNG_EXYNOS_DWMMC, node_list, - DWMMC_MAX_CH_NUM); - - /* For DWMMC always set boot device as mmc 0 */ - if (count >= 3 && get_boot_mode() == BOOT_MODE_SD) { - boot_dev_node = node_list[2]; - node_list[2] = node_list[0]; - node_list[0] = boot_dev_node; - } - - err = exynos_dwmci_process_node(blob, node_list, count); - - return err; -} - #ifdef CONFIG_DM_MMC static int exynos_dwmmc_probe(struct udevice *dev) { diff --git a/tools/Makefile b/tools/Makefile index 9b1aa51b10..2d550432ba 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -155,7 +155,7 @@ HOSTCFLAGS_kwbimage.o += -DCONFIG_KWB_SECURE endif # MXSImage needs LibSSL -ifneq ($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_ARMADA_38X)$(CONFIG_ARMADA_39X)$(CONFIG_FIT_SIGNATURE),) +ifneq ($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_ARMADA_38X)$(CONFIG_ARMADA_39X)$(CONFIG_FIT_SIGNATURE)$(CONFIG_FIT_CIPHER),) HOSTCFLAGS_kwbimage.o += \ $(shell pkg-config --cflags libssl libcrypto 2> /dev/null || echo "") HOSTLDLIBS_mkimage += \ diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c index 66cb9d2a25..2a61a5d6f0 100644 --- a/tools/env/fw_env.c +++ b/tools/env/fw_env.c @@ -1208,7 +1208,7 @@ static int flash_write(int fd_current, int fd_target, int dev_target) if (IS_UBI(dev_target)) { if (ubi_update_start(fd_target, CUR_ENVSIZE) < 0) - return 0; + return -1; return ubi_write(fd_target, environment.image, CUR_ENVSIZE); } diff --git a/tools/image-host.c b/tools/image-host.c index e32cc64257..33a224129a 100644 --- a/tools/image-host.c +++ b/tools/image-host.c @@ -700,13 +700,84 @@ static const char *fit_config_get_image_list(void *fit, int noffset, return default_list; } +static int fit_config_add_hash(void *fit, const char *conf_name, const char *sig_name, + struct strlist *node_inc, const char *iname, int image_noffset) +{ + char name[200], path[200]; + int noffset; + int hash_count; + int ret; + + ret = fdt_get_path(fit, image_noffset, path, sizeof(path)); + if (ret < 0) + goto err_path; + if (strlist_add(node_inc, path)) + goto err_mem; + + snprintf(name, sizeof(name), "%s/%s", FIT_CONFS_PATH, + conf_name); + + /* Add all this image's hashes */ + hash_count = 0; + for (noffset = fdt_first_subnode(fit, image_noffset); + noffset >= 0; + noffset = fdt_next_subnode(fit, noffset)) { + const char *name = fit_get_name(fit, noffset, NULL); + + if (strncmp(name, FIT_HASH_NODENAME, + strlen(FIT_HASH_NODENAME))) + continue; + ret = fdt_get_path(fit, noffset, path, sizeof(path)); + if (ret < 0) + goto err_path; + if (strlist_add(node_inc, path)) + goto err_mem; + hash_count++; + } + + if (!hash_count) { + printf("Failed to find any hash nodes in configuration '%s/%s' image '%s' - without these it is not possible to verify this image\n", + conf_name, sig_name, iname); + return -ENOMSG; + } + + /* Add this image's cipher node if present */ + noffset = fdt_subnode_offset(fit, image_noffset, + FIT_CIPHER_NODENAME); + if (noffset != -FDT_ERR_NOTFOUND) { + if (noffset < 0) { + printf("Failed to get cipher node in configuration '%s/%s' image '%s': %s\n", + conf_name, sig_name, iname, + fdt_strerror(noffset)); + return -EIO; + } + ret = fdt_get_path(fit, noffset, path, sizeof(path)); + if (ret < 0) + goto err_path; + if (strlist_add(node_inc, path)) + goto err_mem; + } + + return 0; + +err_mem: + printf("Out of memory processing configuration '%s/%s'\n", conf_name, + sig_name); + return -ENOMEM; + +err_path: + printf("Failed to get path for image '%s' in configuration '%s/%s': %s\n", + iname, conf_name, sig_name, fdt_strerror(ret)); + return -ENOENT; +} + static int fit_config_get_hash_list(void *fit, int conf_noffset, int sig_offset, struct strlist *node_inc) { int allow_missing; const char *prop, *iname, *end; const char *conf_name, *sig_name; - char name[200], path[200]; + char name[200]; int image_count; int ret, len; @@ -733,72 +804,32 @@ static int fit_config_get_hash_list(void *fit, int conf_noffset, end = prop + len; image_count = 0; for (iname = prop; iname < end; iname += strlen(iname) + 1) { - int noffset; int image_noffset; - int hash_count; + int index, max_index; - image_noffset = fit_conf_get_prop_node(fit, conf_noffset, - iname); - if (image_noffset < 0) { - printf("Failed to find image '%s' in configuration '%s/%s'\n", - iname, conf_name, sig_name); - if (allow_missing) - continue; + max_index = fdt_stringlist_count(fit, conf_noffset, iname); - return -ENOENT; - } - - ret = fdt_get_path(fit, image_noffset, path, sizeof(path)); - if (ret < 0) - goto err_path; - if (strlist_add(node_inc, path)) - goto err_mem; + for (index = 0; index < max_index; index++) { + image_noffset = fit_conf_get_prop_node_index(fit, conf_noffset, + iname, index); - snprintf(name, sizeof(name), "%s/%s", FIT_CONFS_PATH, - conf_name); + if (image_noffset < 0) { + printf("Failed to find image '%s' in configuration '%s/%s'\n", + iname, conf_name, sig_name); + if (allow_missing) + continue; - /* Add all this image's hashes */ - hash_count = 0; - for (noffset = fdt_first_subnode(fit, image_noffset); - noffset >= 0; - noffset = fdt_next_subnode(fit, noffset)) { - const char *name = fit_get_name(fit, noffset, NULL); + return -ENOENT; + } - if (strncmp(name, FIT_HASH_NODENAME, - strlen(FIT_HASH_NODENAME))) - continue; - ret = fdt_get_path(fit, noffset, path, sizeof(path)); + ret = fit_config_add_hash(fit, conf_name, + sig_name, node_inc, + iname, image_noffset); if (ret < 0) - goto err_path; - if (strlist_add(node_inc, path)) - goto err_mem; - hash_count++; - } + return ret; - if (!hash_count) { - printf("Failed to find any hash nodes in configuration '%s/%s' image '%s' - without these it is not possible to verify this image\n", - conf_name, sig_name, iname); - return -ENOMSG; + image_count++; } - - /* Add this image's cipher node if present */ - noffset = fdt_subnode_offset(fit, image_noffset, - FIT_CIPHER_NODENAME); - if (noffset != -FDT_ERR_NOTFOUND) { - if (noffset < 0) { - printf("Failed to get cipher node in configuration '%s/%s' image '%s': %s\n", - conf_name, sig_name, iname, - fdt_strerror(noffset)); - return -EIO; - } - ret = fdt_get_path(fit, noffset, path, sizeof(path)); - if (ret < 0) - goto err_path; - if (strlist_add(node_inc, path)) - goto err_mem; - } - - image_count++; } if (!image_count) { @@ -813,11 +844,6 @@ err_mem: printf("Out of memory processing configuration '%s/%s'\n", conf_name, sig_name); return -ENOMEM; - -err_path: - printf("Failed to get path for image '%s' in configuration '%s/%s': %s\n", - iname, conf_name, sig_name, fdt_strerror(ret)); - return -ENOENT; } static int fit_config_get_data(void *fit, int conf_noffset, int noffset, diff --git a/tools/mkimage.c b/tools/mkimage.c index e78608293e..68d5206cb4 100644 --- a/tools/mkimage.c +++ b/tools/mkimage.c @@ -94,18 +94,18 @@ static void usage(const char *msg) " -x ==> set XIP (execute in place)\n", params.cmdname); fprintf(stderr, - " %s [-D dtc_options] [-f fit-image.its|-f auto|-F] [-b <dtb> [-b <dtb>]] [-i <ramdisk.cpio.gz>] fit-image\n" + " %s [-D dtc_options] [-f fit-image.its|-f auto|-F] [-b <dtb> [-b <dtb>]] [-E] [-B size] [-i <ramdisk.cpio.gz>] fit-image\n" " <dtb> file is used with -f auto, it may occur multiple times.\n", params.cmdname); fprintf(stderr, " -D => set all options for device tree compiler\n" " -f => input filename for FIT source\n" - " -i => input filename for ramdisk file\n"); + " -i => input filename for ramdisk file\n" + " -E => place data outside of the FIT structure\n" + " -B => align size in hex for FIT structure and header\n"); #ifdef CONFIG_FIT_SIGNATURE fprintf(stderr, - "Signing / verified boot options: [-E] [-B size] [-k keydir] [-K dtb] [ -c <comment>] [-p addr] [-r] [-N engine]\n" - " -E => place data outside of the FIT structure\n" - " -B => align size in hex for FIT structure and header\n" + "Signing / verified boot options: [-k keydir] [-K dtb] [ -c <comment>] [-p addr] [-r] [-N engine]\n" " -k => set directory containing private keys\n" " -K => write public keys to this .dtb file\n" " -c => add comment in signature node\n" @@ -142,6 +142,7 @@ static int add_content(int type, const char *fname) return 0; } +#define OPT_STRING "a:A:b:B:c:C:d:D:e:Ef:Fk:i:K:ln:N:p:O:rR:qstT:vVx" static void process_args(int argc, char **argv) { char *ptr; |