Merge tag 'v2021.01-rc5' into next
Prepare v2021.01-rc5 Signed-off-by: Tom Rini <trini@konsulko.com>
This commit is contained in:
Tom Rini
@@ -1,98 +0,0 @@
|
||||
SPDX-License-Identifier: GPL-2.0+
|
||||
/*
|
||||
* (C) Copyright 2011-2012 Pali Rohár <pali@kernel.org>
|
||||
*/
|
||||
|
||||
ANSI terminal bootmenu command
|
||||
|
||||
The "bootmenu" command uses U-Boot menu interfaces and provides
|
||||
a simple mechanism for creating menus with different boot items.
|
||||
The cursor keys "Up" and "Down" are used for navigation through
|
||||
the items. Current active menu item is highlighted and can be
|
||||
selected using the "Enter" key. The selection of the highlighted
|
||||
menu entry invokes an U-Boot command (or a list of commands)
|
||||
associated with this menu entry.
|
||||
|
||||
The "bootmenu" command interprets ANSI escape sequencies, so
|
||||
an ANSI terminal is required for proper menu rendering and item
|
||||
selection.
|
||||
|
||||
The assembling of the menu is done via a set of environment variables
|
||||
"bootmenu_<num>" and "bootmenu_delay", i.e.:
|
||||
|
||||
bootmenu_delay=<delay>
|
||||
bootmenu_<num>="<title>=<commands>"
|
||||
|
||||
<delay> is the autoboot delay in seconds, after which the first
|
||||
menu entry will be selected automatically
|
||||
|
||||
<num> is the boot menu entry number, starting from zero
|
||||
|
||||
<title> is the text of the menu entry shown on the console
|
||||
or on the boot screen
|
||||
|
||||
<commands> are commands which will be executed when a menu
|
||||
entry is selected
|
||||
|
||||
(title and commands are separated by first appearance of '='
|
||||
character in the environment variable)
|
||||
|
||||
First (optional) argument of the "bootmenu" command is a delay specifier
|
||||
and it overrides the delay value defined by "bootmenu_delay" environment
|
||||
variable. If the environment variable "bootmenu_delay" is not set or if
|
||||
the argument of the "bootmenu" command is not specified, the default delay
|
||||
will be CONFIG_BOOTDELAY. If delay is 0, no menu entries will be shown on
|
||||
the console (or on the screen) and the command of the first menu entry will
|
||||
be called immediately. If delay is less then 0, bootmenu will be shown and
|
||||
autoboot will be disabled.
|
||||
|
||||
Bootmenu always adds menu entry "U-Boot console" at the end of all menu
|
||||
entries specified by environment variables. When selecting this entry
|
||||
the bootmenu terminates and the usual U-Boot command prompt is presented
|
||||
to the user.
|
||||
|
||||
Example environment:
|
||||
|
||||
setenv bootmenu_0 Boot 1. kernel=bootm 0x82000000 # Set first menu entry
|
||||
setenv bootmenu_1 Boot 2. kernel=bootm 0x83000000 # Set second menu entry
|
||||
setenv bootmenu_2 Reset board=reset # Set third menu entry
|
||||
setenv bootmenu_3 U-Boot boot order=boot # Set fourth menu entry
|
||||
bootmenu 20 # Run bootmenu with autoboot delay 20s
|
||||
|
||||
|
||||
The above example will be rendered as below
|
||||
(without decorating rectangle):
|
||||
|
||||
┌──────────────────────────────────────────┐
|
||||
│ │
|
||||
│ *** U-Boot Boot Menu *** │
|
||||
│ │
|
||||
│ Boot 1. kernel │
|
||||
│ Boot 2. kernel │
|
||||
│ Reset board │
|
||||
│ U-Boot boot order │
|
||||
│ U-Boot console │
|
||||
│ │
|
||||
│ Hit any key to stop autoboot: 20 │
|
||||
│ Press UP/DOWN to move, ENTER to select │
|
||||
│ │
|
||||
└──────────────────────────────────────────┘
|
||||
|
||||
Selected menu entry will be highlighted - it will have inverted
|
||||
background and text colors.
|
||||
|
||||
To enable the "bootmenu" command add following definitions to the
|
||||
board config file:
|
||||
|
||||
#define CONFIG_CMD_BOOTMENU
|
||||
#define CONFIG_MENU
|
||||
|
||||
To run the bootmenu at startup add these additional definitions:
|
||||
|
||||
#define CONFIG_AUTOBOOT_KEYED
|
||||
#define CONFIG_BOOTDELAY 30
|
||||
#define CONFIG_AUTOBOOT_MENU_SHOW
|
||||
|
||||
When you intend to use the bootmenu on color frame buffer console,
|
||||
make sure to additionally define CONFIG_CFB_CONSOLE_ANSI in the
|
||||
board config file.
|
||||
@@ -1,186 +0,0 @@
|
||||
Command definition
|
||||
------------------
|
||||
|
||||
Commands are added to U-Boot by creating a new command structure.
|
||||
This is done by first including command.h, then using the U_BOOT_CMD() or the
|
||||
U_BOOT_CMD_COMPLETE macro to fill in a struct cmd_tbl struct.
|
||||
|
||||
U_BOOT_CMD(name, maxargs, repeatable, command, "usage", "help")
|
||||
U_BOOT_CMD_COMPLETE(name, maxargs, repeatable, command, "usage, "help", comp)
|
||||
|
||||
name: The name of the command. THIS IS NOT a string.
|
||||
|
||||
maxargs: The maximum number of arguments this function takes including
|
||||
the command itself.
|
||||
|
||||
repeatable: Either 0 or 1 to indicate if autorepeat is allowed.
|
||||
|
||||
command: Pointer to the command function. This is the function that is
|
||||
called when the command is issued.
|
||||
|
||||
usage: Short description. This is a string.
|
||||
|
||||
help: Long description. This is a string. The long description is
|
||||
only available if CONFIG_SYS_LONGHELP is defined.
|
||||
|
||||
comp: Pointer to the completion function. May be NULL.
|
||||
This function is called if the user hits the TAB key while
|
||||
entering the command arguments to complete the entry. Command
|
||||
completion is only available if CONFIG_AUTO_COMPLETE is defined.
|
||||
|
||||
Sub-command definition
|
||||
----------------------
|
||||
|
||||
Likewise an array of struct cmd_tbl holding sub-commands can be created using either
|
||||
of the following macros:
|
||||
|
||||
* U_BOOT_CMD_MKENT(name, maxargs, repeatable, command, "usage", "help")
|
||||
* U_BOOT_CMD_MKENTCOMPLETE(name, maxargs, repeatable, command, "usage, "help",
|
||||
comp)
|
||||
|
||||
This table has to be evaluated in the command function of the main command, e.g.
|
||||
|
||||
static struct cmd_tbl cmd_sub[] = {
|
||||
U_BOOT_CMD_MKENT(foo, CONFIG_SYS_MAXARGS, 1, do_foo, "", ""),
|
||||
U_BOOT_CMD_MKENT(bar, CONFIG_SYS_MAXARGS, 1, do_bar, "", ""),
|
||||
};
|
||||
|
||||
static int do_cmd(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
|
||||
{
|
||||
struct cmd_tbl *cp;
|
||||
|
||||
if (argc < 2)
|
||||
return CMD_RET_USAGE;
|
||||
|
||||
/* drop sub-command argument */
|
||||
argc--;
|
||||
argv++;
|
||||
|
||||
cp = find_cmd_tbl(argv[0], cmd_ut_sub, ARRAY_SIZE(cmd_sub));
|
||||
|
||||
if (cp)
|
||||
return cp->cmd(cmdtp, flag, argc, argv);
|
||||
|
||||
return CMD_RET_USAGE;
|
||||
}
|
||||
|
||||
Command function
|
||||
----------------
|
||||
|
||||
The command function pointer has to be of type
|
||||
int (*cmd)(struct cmd_tbl *cmdtp, int flag, int argc, const char *argv[]);
|
||||
|
||||
cmdtp: Table entry describing the command (see above).
|
||||
|
||||
flag: A bitmap which may contain the following bit:
|
||||
CMD_FLAG_REPEAT - The last command is repeated.
|
||||
CMD_FLAG_BOOTD - The command is called by the bootd command.
|
||||
CMD_FLAG_ENV - The command is called by the run command.
|
||||
|
||||
argc: Number of arguments including the command.
|
||||
|
||||
argv: Arguments.
|
||||
|
||||
Allowable return value are:
|
||||
|
||||
CMD_RET_SUCCESS The command was successfully executed.
|
||||
|
||||
CMD_RET_FAILURE The command failed.
|
||||
|
||||
CMD_RET_USAGE The command was called with invalid parameters. This value
|
||||
leads to the display of the usage string.
|
||||
|
||||
Completion function
|
||||
-------------------
|
||||
|
||||
The completion function pointer has to be of type
|
||||
int (*complete)(int argc, char *const argv[], char last_char,
|
||||
int maxv, char *cmdv[]);
|
||||
|
||||
argc: Number of arguments including the command.
|
||||
|
||||
argv: Arguments.
|
||||
|
||||
last_char: The last character in the command line buffer.
|
||||
|
||||
maxv: Maximum number of possible completions that may be returned by
|
||||
the function.
|
||||
|
||||
cmdv: Used to return possible values for the last argument. The last
|
||||
possible completion must be followed by NULL.
|
||||
|
||||
The function returns the number of possible completions (without the terminating
|
||||
NULL value).
|
||||
|
||||
Behind the scene
|
||||
----------------
|
||||
|
||||
The structure created is named with a special prefix and placed by
|
||||
the linker in a special section using the linker lists mechanism
|
||||
(see include/linker_lists.h)
|
||||
|
||||
This makes it possible for the final link to extract all commands
|
||||
compiled into any object code and construct a static array so the
|
||||
command array can be iterated over using the linker lists macros.
|
||||
|
||||
The linker lists feature ensures that the linker does not discard
|
||||
these symbols when linking full U-Boot even though they are not
|
||||
referenced in the source code as such.
|
||||
|
||||
If a new board is defined do not forget to define the command section
|
||||
by writing in u-boot.lds ($(srctree)/board/boardname/u-boot.lds) these
|
||||
3 lines:
|
||||
|
||||
.u_boot_list : {
|
||||
KEEP(*(SORT(.u_boot_list*)));
|
||||
}
|
||||
|
||||
Writing tests
|
||||
-------------
|
||||
|
||||
All new commands should have tests. Tests for existing commands are very
|
||||
welcome.
|
||||
|
||||
It is fairly easy to write a test for a command. Enable it in sandbox, and
|
||||
then add code that runs the command and checks the output.
|
||||
|
||||
Here is an example:
|
||||
|
||||
/* Test 'acpi items' command */
|
||||
static int dm_test_acpi_cmd_items(struct unit_test_state *uts)
|
||||
{
|
||||
struct acpi_ctx ctx;
|
||||
void *buf;
|
||||
|
||||
buf = malloc(BUF_SIZE);
|
||||
ut_assertnonnull(buf);
|
||||
|
||||
ctx.current = buf;
|
||||
ut_assertok(acpi_fill_ssdt(&ctx));
|
||||
console_record_reset();
|
||||
run_command("acpi items", 0);
|
||||
ut_assert_nextline("dev 'acpi-test', type 1, size 2");
|
||||
ut_assert_nextline("dev 'acpi-test2', type 1, size 2");
|
||||
ut_assert_console_end();
|
||||
|
||||
ctx.current = buf;
|
||||
ut_assertok(acpi_inject_dsdt(&ctx));
|
||||
console_record_reset();
|
||||
run_command("acpi items", 0);
|
||||
ut_assert_nextline("dev 'acpi-test', type 2, size 2");
|
||||
ut_assert_nextline("dev 'acpi-test2', type 2, size 2");
|
||||
ut_assert_console_end();
|
||||
|
||||
console_record_reset();
|
||||
run_command("acpi items -d", 0);
|
||||
ut_assert_nextline("dev 'acpi-test', type 2, size 2");
|
||||
ut_assert_nextlines_are_dump(2);
|
||||
ut_assert_nextline("%s", "");
|
||||
ut_assert_nextline("dev 'acpi-test2', type 2, size 2");
|
||||
ut_assert_nextlines_are_dump(2);
|
||||
ut_assert_nextline("%s", "");
|
||||
ut_assert_console_end();
|
||||
|
||||
return 0;
|
||||
}
|
||||
DM_TEST(dm_test_acpi_cmd_items, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
|
||||
@@ -43,11 +43,8 @@ Build Procedure
|
||||
In order to prevent this, the required device-tree MUST be set during compilation.
|
||||
All device-tree files are located in ./arch/arm/dts/ folder.
|
||||
|
||||
For the EspressoBin board with populated eMMC device use
|
||||
# make DEVICE_TREE=armada-3720-espressobin-emmc
|
||||
|
||||
For other DB boards (MacchiatoBin, EspressoBin without soldered eMMC and 3700 DB board)
|
||||
compile u-boot with just default device-tree from defconfig using:
|
||||
For other DB boards (MacchiatoBin, EspressoBin and 3700 DB board) compile u-boot with
|
||||
just default device-tree from defconfig using:
|
||||
|
||||
# make
|
||||
|
||||
|
||||
@@ -30,9 +30,10 @@ next image headers:
|
||||
|
||||
v2, v1 and v0 formats are backward compatible.
|
||||
|
||||
Android Boot Image format is represented by :c:type:`struct andr_img_hdr` in
|
||||
U-Boot, and can be seen in ``include/android_image.h``. U-Boot supports booting
|
||||
Android Boot Image and also has associated command
|
||||
The Android Boot Image format is represented by
|
||||
:c:type:`struct andr_img_hdr <andr_img_hdr>` in U-Boot, and can be seen in
|
||||
``include/android_image.h``. U-Boot supports booting Android Boot Image and also
|
||||
has associated command
|
||||
|
||||
Booting
|
||||
-------
|
||||
|
||||
75
doc/board/advantech/imx8qm-rom7720-a1.rst
Normal file
75
doc/board/advantech/imx8qm-rom7720-a1.rst
Normal file
@@ -0,0 +1,75 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0+
|
||||
|
||||
U-Boot for the NXP i.MX8QM ROM 7720a1 board
|
||||
===========================================
|
||||
|
||||
Quick Start
|
||||
-----------
|
||||
|
||||
- Build the ARM Trusted firmware binary
|
||||
- Get scfw_tcm.bin and ahab-container.img
|
||||
- Get imx-mkimage
|
||||
- Build U-Boot
|
||||
- Build imx-mkimage
|
||||
- Flash the binary into the SD card
|
||||
- Boot
|
||||
|
||||
Get and Build the ARM Trusted firmware
|
||||
--------------------------------------
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git clone https://source.codeaurora.org/external/imx/imx-atf
|
||||
$ cd imx-atf/
|
||||
$ git checkout origin/imx_4.14.78_1.0.0_ga -b imx_4.14.78_1.0.0_ga
|
||||
$ make PLAT=imx8qm bl31
|
||||
|
||||
Get scfw_tcm.bin and ahab-container.img
|
||||
---------------------------------------
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-sc-firmware-1.1.bin
|
||||
$ chmod +x imx-sc-firmware-1.1.bin
|
||||
$ ./imx-sc-firmware-1.1.bin
|
||||
$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.0.bin
|
||||
$ chmod +x firmware-imx-8.0.bin
|
||||
$ ./firmware-imx-8.0.bin
|
||||
|
||||
Or use this to avoid running random scripts from the internet,
|
||||
but note that you must agree to the license the script displays:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ dd if=imx-sc-firmware-1.1.bin of=imx-sc-firmware-1.1.tar.bz2 bs=37185 skip=1
|
||||
$ tar -xf imx-sc-firmware-1.1.tar.bz2
|
||||
$ cp imx-sc-firmware-1.1/mx8qm-val-scfw-tcm.bin $(builddir)
|
||||
|
||||
$ dd if=firmware-imx-8.0.bin of=firmware-imx-8.0.tar.bz2 bs=37180 skip=1
|
||||
$ tar -xf firmware-imx-8.0.tar.bz2
|
||||
$ cp firmware-imx-8.0/firmware/seco/mx8qm-ahab-container.img $(builddir)
|
||||
|
||||
Build U-Boot
|
||||
------------
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ export ATF_LOAD_ADDR=0x80000000
|
||||
$ export BL33_LOAD_ADDR=0x80020000
|
||||
$ make imx8qm_rom7720_a1_4G_defconfig
|
||||
$ make u-boot.bin
|
||||
$ make flash.bin
|
||||
|
||||
Flash the binary into the SD card
|
||||
---------------------------------
|
||||
|
||||
Burn the flash.bin binary to SD card offset 32KB:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo dd if=flash.bin of=/dev/sd[x] bs=1k seek=32 conv=fsync
|
||||
|
||||
Boot
|
||||
----
|
||||
|
||||
Set Boot switch SW2: 1100.
|
||||
9
doc/board/advantech/index.rst
Normal file
9
doc/board/advantech/index.rst
Normal file
@@ -0,0 +1,9 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0+
|
||||
|
||||
Advantech
|
||||
=========
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
imx8qm-rom7720-a1.rst
|
||||
@@ -23,7 +23,7 @@ branch: imx_5.4.3_2.0.0
|
||||
.. code-block:: bash
|
||||
|
||||
$ make PLAT=imx8mp bl31
|
||||
$ sudo cp build/imx8mp/release/bl31.bin $(srctree)
|
||||
$ cp build/imx8mp/release/bl31.bin $(srctree)
|
||||
|
||||
Get the ddr firmware
|
||||
--------------------
|
||||
@@ -32,11 +32,11 @@ Get the ddr firmware
|
||||
|
||||
$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.7.bin
|
||||
$ chmod +x firmware-imx-8.7.bin
|
||||
$ ./firmware-imx-8.7
|
||||
$ sudo cp firmware-imx-8.7/firmware/ddr/synopsys/lpddr4_pmu_train_1d_dmem_201904.bin $(srctree)/lpddr4_pmu_train_1d_dmem.bin
|
||||
$ sudo cp firmware-imx-8.7/firmware/ddr/synopsys/lpddr4_pmu_train_1d_imem_201904.bin $(srctree)/lpddr4_pmu_train_1d_imem.bin
|
||||
$ sudo cp firmware-imx-8.7/firmware/ddr/synopsys/lpddr4_pmu_train_2d_dmem_201904.bin $(srctree)/lpddr4_pmu_train_2d_dmem.bin
|
||||
$ sudo cp firmware-imx-8.7/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem_201904.bin $(srctree)/lpddr4_pmu_train_2d_imem.bin
|
||||
$ ./firmware-imx-8.7.bin
|
||||
$ cp firmware-imx-8.7/firmware/ddr/synopsys/lpddr4_pmu_train_1d_dmem_201904.bin $(srctree)/lpddr4_pmu_train_1d_dmem.bin
|
||||
$ cp firmware-imx-8.7/firmware/ddr/synopsys/lpddr4_pmu_train_1d_imem_201904.bin $(srctree)/lpddr4_pmu_train_1d_imem.bin
|
||||
$ cp firmware-imx-8.7/firmware/ddr/synopsys/lpddr4_pmu_train_2d_dmem_201904.bin $(srctree)/lpddr4_pmu_train_2d_dmem.bin
|
||||
$ cp firmware-imx-8.7/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem_201904.bin $(srctree)/lpddr4_pmu_train_2d_imem.bin
|
||||
|
||||
Build U-Boot
|
||||
------------
|
||||
|
||||
@@ -7,6 +7,7 @@ Board-specific doc
|
||||
:maxdepth: 2
|
||||
|
||||
actions/index
|
||||
advantech/index
|
||||
AndesTech/index
|
||||
amlogic/index
|
||||
atmel/index
|
||||
|
||||
@@ -23,38 +23,48 @@ use.
|
||||
more step (if and only if you have original U-Boot), i.e. run the
|
||||
following command::
|
||||
|
||||
$ truncate -s %4096 u-boot.bin
|
||||
$ truncate -s %4096 u-boot.bin
|
||||
|
||||
2. Run your board and interrupt booting to U-Boot console. In the console
|
||||
call::
|
||||
|
||||
=> run do_force_flash_os
|
||||
=> run do_force_flash_os
|
||||
|
||||
3. Wait for few seconds, it will prepare environment variable and runs
|
||||
DFU. Run DFU command from the host system::
|
||||
|
||||
$ dfu-util -v -d 8087:0a99 --alt u-boot0 -D u-boot.bin
|
||||
$ dfu-util -v -d 8087:0a99 --alt u-boot0 -D u-boot.bin
|
||||
|
||||
4. Return to U-Boot console and following hint. i.e. push Ctrl+C, and
|
||||
reset the board::
|
||||
|
||||
=> reset
|
||||
|
||||
=> reset
|
||||
|
||||
Updating U-Boot using xFSTK
|
||||
---------------------------
|
||||
|
||||
You can also update U-Boot using the xfstk-dldr-solo tool if you can build it.
|
||||
One way to do that is to follow the `xFSTK`_ instructions. You may need to use
|
||||
a virtual machine running Ubuntu Trusty. Once you have built it and installed
|
||||
libboost-all-dev, you can copy xfstk-dldr-solo to /usr/local/bin and
|
||||
One way to do that is to follow the `xFSTK`_ instructions. In short, after you
|
||||
install all necessary dependencies and clone repository, it will look like this:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
cd xFSTK
|
||||
export DISTRIBUTION_NAME=ubuntu20.04
|
||||
export BUILD_VERSION=1.8.5
|
||||
git checkout v$BUILD_VERSION
|
||||
...
|
||||
|
||||
Once you have built it, you can copy xfstk-dldr-solo to /usr/local/bin and
|
||||
libboost_program_options.so.1.54.0 to /usr/lib/i386-linux-gnu/ and with luck
|
||||
it will work. You might fine this `drive`_ helpful.
|
||||
it will work. You might find this `drive`_ helpful.
|
||||
|
||||
If it does, then you can download and unpack the Edison reocovery image,
|
||||
install dfu-util, reset your board and flash U-Boot like this::
|
||||
If it does, then you can download and unpack the Edison recovery image,
|
||||
install dfu-util, reset your board and flash U-Boot like this:
|
||||
|
||||
$ xfstk-dldr-solo --gpflags 0x80000007 \
|
||||
.. code-block:: sh
|
||||
|
||||
xfstk-dldr-solo --gpflags 0x80000007 \
|
||||
--osimage u-boot-edison.img \
|
||||
--fwdnx recover/edison_dnx_fwr.bin \
|
||||
--fwimage recover/edison_ifwi-dbg-00.bin \
|
||||
@@ -64,7 +74,7 @@ This should show the following
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
XFSTK Downloader Solo 0.0.0
|
||||
XFSTK Downloader Solo 1.8.5
|
||||
Copyright (c) 2015 Intel Corporation
|
||||
Build date and time: Aug 15 2020 15:07:13
|
||||
|
||||
@@ -75,13 +85,12 @@ This should show the following
|
||||
.......(lots of dots)........XFSTK-STATUS--Reconnecting to device - Attempt #1
|
||||
.......(even more dots)......................
|
||||
|
||||
|
||||
You have about 10 seconds after resetting the board to type the above command.
|
||||
If you want to check if the board is ready, type:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
lsusb |egrep "8087|8086"
|
||||
lsusb | egrep "8087|8086"
|
||||
Bus 001 Device 004: ID 8086:e005 Intel Corp.
|
||||
|
||||
If you see a device with the same ID as above, the board is waiting for your
|
||||
@@ -112,9 +121,9 @@ After about 5 seconds you should see some console output from the board:
|
||||
|
||||
*** Ready to receive application ***
|
||||
|
||||
After another 10 seconds the xFSTK tool completes and the board resets. About
|
||||
10 seconds after that should see the above message again and then within a
|
||||
few seconds U-Boot should start on your board:
|
||||
After another 10 seconds the xFSTK tool completes and the board resets. About
|
||||
10 seconds after that should see the above message again and then within a few
|
||||
seconds U-Boot should start on your board:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
@@ -146,7 +155,7 @@ After about 5 seconds you should see some console output from the board:
|
||||
Building boot_params at 0x00090000
|
||||
Loading bzImage at address 100000 (5427456 bytes)
|
||||
Magic signature found
|
||||
Kernel command line: "rootwait root=PARTUUID=ada722ed-6410-764e-8619-abff6f66e10e rootfstype=ext4 console=ttyMFD2 earlyprintk=ttyMFD2,keep loglevel=4 g_multi.ethernet_config=cdc systemd.unit=multi-user.target hardware_id=00 g_multi.iSerialNumber=2249baf774c675598661a63098c0ad41 g_multi.dev_addr=02:00:86:c0:ad:41 platform_mrfld_audio.audio_codec=dummy"
|
||||
Kernel command line: "rootwait ..."
|
||||
Magic signature found
|
||||
|
||||
Starting kernel ...
|
||||
@@ -157,5 +166,5 @@ After about 5 seconds you should see some console output from the board:
|
||||
|
||||
edison login:
|
||||
|
||||
.. _xFSTK: https://community.intel.com/t5/Intel-Makers/Building-xFSTK-on-Ubuntu-14-04-32-bit-for-flashing-Edison/td-p/538081
|
||||
.. _xFSTK: https://github.com/edison-fw/xFSTK
|
||||
.. _drive: https://drive.google.com/drive/u/0/folders/1URPHrOk9-UBsh8hjv-7WwC0W6Fy61uAJ
|
||||
|
||||
74
doc/board/toradex/apalix-imx8x.rst
Normal file
74
doc/board/toradex/apalix-imx8x.rst
Normal file
@@ -0,0 +1,74 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0+
|
||||
|
||||
Apalis iMX8X V1.1A Module
|
||||
==========================
|
||||
|
||||
Quick Start
|
||||
-----------
|
||||
|
||||
- Build the ARM trusted firmware binary
|
||||
- Get scfw_tcm.bin and ahab-container.img
|
||||
- Build U-Boot
|
||||
- Load U-Boot binary using uuu
|
||||
- Flash U-Boot binary into the eMMC
|
||||
- Boot
|
||||
|
||||
Get and Build the ARM Trusted Firmware
|
||||
--------------------------------------
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git clone -b toradex_imx_5.4.24_2.1.0 http://git.toradex.com/cgit/imx-atf.git
|
||||
$ cd imx-atf/
|
||||
$ make PLAT=imx8qx bl31
|
||||
|
||||
Get scfw_tcm.bin and ahab-container.img
|
||||
---------------------------------------
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ wget https://github.com/toradex/i.MX-System-Controller-Firmware/blob/master/src/scfw_export_mx8qx_b0/build_mx8qx_b0/mx8qx-apalis-scfw-tcm.bin
|
||||
$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-seco-3.6.3.bin
|
||||
$ chmod +x imx-seco-3.6.3.bin
|
||||
$ ./imx-seco-3.6.3.bin
|
||||
|
||||
Copy the following binaries to the U-Boot folder:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ cp imx-atf/build/imx8qx/release/bl31.bin .
|
||||
$ cp imx-seco-3.6.3/firmware/seco/mx8qxb0-ahab-container.img mx8qx-ahab-container.imx8_defconfig
|
||||
|
||||
Build U-Boot
|
||||
------------
|
||||
.. code-block:: bash
|
||||
|
||||
$ make apalis-imx8x_defconfig
|
||||
$ make u-boot-dtb.imx
|
||||
|
||||
Load the U-Boot Binary Using UUU
|
||||
--------------------------------
|
||||
|
||||
Get the latest version of the universal update utility (uuu) aka ``mfgtools 3.0``:
|
||||
|
||||
https://community.nxp.com/external-link.jspa?url=https%3A%2F%2Fgithub.com%2FNXPmicro%2Fmfgtools%2Freleases
|
||||
|
||||
Put the module into USB recovery aka serial downloader mode, connect USB device
|
||||
to your host and execute uuu:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo ./uuu u-boot/u-boot-dtb.imx
|
||||
|
||||
Flash the U-Boot Binary into the eMMC
|
||||
-------------------------------------
|
||||
|
||||
Burn the ``u-boot-dtb.imx`` binary to the primary eMMC hardware boot area
|
||||
partition and boot:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
load mmc 1:1 $loadaddr u-boot-dtb.imx
|
||||
setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200
|
||||
mmc dev 0 1
|
||||
mmc write ${loadaddr} 0x0 ${blkcnt}
|
||||
@@ -7,6 +7,7 @@ Toradex
|
||||
:maxdepth: 2
|
||||
|
||||
apalix-imx8
|
||||
apalix-imx8x
|
||||
colibri_imx7
|
||||
colibri-imx8x
|
||||
verdin-imx8mm
|
||||
|
||||
20
doc/build/gcc.rst
vendored
20
doc/build/gcc.rst
vendored
@@ -29,6 +29,26 @@ Depending on the build targets further packages maybe needed
|
||||
lzma-alone openssl python3 python3-coverage python3-pyelftools \
|
||||
python3-pytest python3-sphinxcontrib.apidoc python3-sphinx-rtd-theme swig
|
||||
|
||||
SUSE based
|
||||
~~~~~~~~~~
|
||||
|
||||
On suse based systems the cross compiler packages are named
|
||||
cross-<architecture>-gcc<version>.
|
||||
|
||||
You could install GCC and the GCC 10 cross compiler for the ARMv8 architecture
|
||||
with
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo zypper install gcc cross-aarch64-gcc10
|
||||
|
||||
Depending on the build targets further packages maybe needed.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
zypper install bc bison flex gcc libopenssl-devel libSDL2-devel make \
|
||||
ncurses-devel python3-devel python3-pytest swig
|
||||
|
||||
Prerequisites
|
||||
-------------
|
||||
|
||||
|
||||
29
doc/conf.py
29
doc/conf.py
@@ -36,7 +36,34 @@ latex_engine = 'xelatex'
|
||||
# Add any Sphinx extension module names here, as strings. They can be
|
||||
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
|
||||
# ones.
|
||||
extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain', 'kfigure']
|
||||
extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'kfigure']
|
||||
|
||||
#
|
||||
# cdomain is badly broken in Sphinx 3+. Leaving it out generates *most*
|
||||
# of the docs correctly, but not all.
|
||||
#
|
||||
if major >= 3:
|
||||
if (major > 3) or (minor > 0 or patch >= 2):
|
||||
sys.stderr.write('''The build process with Sphinx 3+ is broken.
|
||||
You will have to remove -W in doc/Makefile.
|
||||
''')
|
||||
# Sphinx c function parser is more pedantic with regards to type
|
||||
# checking. Due to that, having macros at c:function cause problems.
|
||||
# Those needed to be escaped by using c_id_attributes[] array
|
||||
c_id_attributes = [
|
||||
|
||||
# include/linux/compiler.h
|
||||
"__maybe_unused",
|
||||
|
||||
# include/efi.h
|
||||
"EFIAPI",
|
||||
|
||||
# include/efi_loader.h
|
||||
"__efi_runtime",
|
||||
]
|
||||
|
||||
else:
|
||||
extensions.append('cdomain')
|
||||
|
||||
# The name of the math extension changed on Sphinx 1.4
|
||||
if (major == 1 and minor > 3) or (major > 1):
|
||||
|
||||
226
doc/develop/commands.rst
Normal file
226
doc/develop/commands.rst
Normal file
@@ -0,0 +1,226 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0+
|
||||
|
||||
Implementing shell commands
|
||||
===========================
|
||||
|
||||
Command definition
|
||||
------------------
|
||||
|
||||
Commands are added to U-Boot by creating a new command structure.
|
||||
This is done by first including command.h, then using the U_BOOT_CMD() or the
|
||||
U_BOOT_CMD_COMPLETE macro to fill in a struct cmd_tbl structure.
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
U_BOOT_CMD(name, maxargs, repeatable, command, "usage", "help")
|
||||
U_BOOT_CMD_COMPLETE(name, maxargs, repeatable, command, "usage, "help", comp)
|
||||
|
||||
name
|
||||
The name of the command. This is **not** a string.
|
||||
|
||||
maxargs
|
||||
The maximum number of arguments this function takes including
|
||||
the command itself.
|
||||
|
||||
repeatable
|
||||
Either 0 or 1 to indicate if autorepeat is allowed.
|
||||
|
||||
command
|
||||
Pointer to the command function. This is the function that is
|
||||
called when the command is issued.
|
||||
|
||||
usage
|
||||
Short description. This is a string.
|
||||
|
||||
help
|
||||
Long description. This is a string. The long description is
|
||||
only available if CONFIG_SYS_LONGHELP is defined.
|
||||
|
||||
comp
|
||||
Pointer to the completion function. May be NULL.
|
||||
This function is called if the user hits the TAB key while
|
||||
entering the command arguments to complete the entry. Command
|
||||
completion is only available if CONFIG_AUTO_COMPLETE is defined.
|
||||
|
||||
Sub-command definition
|
||||
----------------------
|
||||
|
||||
Likewise an array of struct cmd_tbl holding sub-commands can be created using
|
||||
either of the following macros:
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
U_BOOT_CMD_MKENT(name, maxargs, repeatable, command, "usage", "help")
|
||||
U_BOOT_CMD_MKENTCOMPLETE(name, maxargs, repeatable, command, "usage, "help", comp)
|
||||
|
||||
This table has to be evaluated in the command function of the main command, e.g.
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
static struct cmd_tbl cmd_sub[] = {
|
||||
U_BOOT_CMD_MKENT(foo, CONFIG_SYS_MAXARGS, 1, do_foo, "", ""),
|
||||
U_BOOT_CMD_MKENT(bar, CONFIG_SYS_MAXARGS, 1, do_bar, "", ""),
|
||||
};
|
||||
|
||||
static int do_cmd(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
|
||||
{
|
||||
struct cmd_tbl *cp;
|
||||
|
||||
if (argc < 2)
|
||||
return CMD_RET_USAGE;
|
||||
|
||||
/* drop sub-command argument */
|
||||
argc--;
|
||||
argv++;
|
||||
|
||||
cp = find_cmd_tbl(argv[0], cmd_ut_sub, ARRAY_SIZE(cmd_sub));
|
||||
|
||||
if (cp)
|
||||
return cp->cmd(cmdtp, flag, argc, argv);
|
||||
|
||||
return CMD_RET_USAGE;
|
||||
}
|
||||
|
||||
Command function
|
||||
----------------
|
||||
|
||||
The command function pointer has to be of type
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
int (*cmd)(struct cmd_tbl *cmdtp, int flag, int argc, const char *argv[]);
|
||||
|
||||
cmdtp
|
||||
Table entry describing the command (see above).
|
||||
|
||||
flag
|
||||
A bitmap which may contain the following bits
|
||||
|
||||
* CMD_FLAG_REPEAT - The last command is repeated.
|
||||
* CMD_FLAG_BOOTD - The command is called by the bootd command.
|
||||
* CMD_FLAG_ENV - The command is called by the run command.
|
||||
|
||||
argc
|
||||
Number of arguments including the command.
|
||||
|
||||
argv
|
||||
Arguments.
|
||||
|
||||
Allowable return value are:
|
||||
|
||||
CMD_RET_SUCCESS
|
||||
The command was successfully executed.
|
||||
|
||||
CMD_RET_FAILURE
|
||||
The command failed.
|
||||
|
||||
CMD_RET_USAGE
|
||||
The command was called with invalid parameters. This value
|
||||
leads to the display of the usage string.
|
||||
|
||||
Completion function
|
||||
-------------------
|
||||
|
||||
The completion function pointer has to be of type
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
int (*complete)(int argc, char *const argv[], char last_char,
|
||||
int maxv, char *cmdv[]);
|
||||
|
||||
argc
|
||||
Number of arguments including the command.
|
||||
|
||||
argv
|
||||
Arguments.
|
||||
|
||||
last_char
|
||||
The last character in the command line buffer.
|
||||
|
||||
maxv
|
||||
Maximum number of possible completions that may be returned by
|
||||
the function.
|
||||
|
||||
cmdv
|
||||
Used to return possible values for the last argument. The last
|
||||
possible completion must be followed by NULL.
|
||||
|
||||
The function returns the number of possible completions (without the terminating
|
||||
NULL value).
|
||||
|
||||
Behind the scene
|
||||
----------------
|
||||
|
||||
The structure created is named with a special prefix and placed by
|
||||
the linker in a special section using the linker lists mechanism
|
||||
(see include/linker_lists.h)
|
||||
|
||||
This makes it possible for the final link to extract all commands
|
||||
compiled into any object code and construct a static array so the
|
||||
command array can be iterated over using the linker lists macros.
|
||||
|
||||
The linker lists feature ensures that the linker does not discard
|
||||
these symbols when linking full U-Boot even though they are not
|
||||
referenced in the source code as such.
|
||||
|
||||
If a new board is defined do not forget to define the command section
|
||||
by writing in u-boot.lds ($(srctree)/board/boardname/u-boot.lds) these
|
||||
3 lines:
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
.u_boot_list : {
|
||||
KEEP(*(SORT(.u_boot_list*)));
|
||||
}
|
||||
|
||||
Writing tests
|
||||
-------------
|
||||
|
||||
All new commands should have tests. Tests for existing commands are very
|
||||
welcome.
|
||||
|
||||
It is fairly easy to write a test for a command. Enable it in sandbox, and
|
||||
then add code that runs the command and checks the output.
|
||||
|
||||
Here is an example:
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
/* Test 'acpi items' command */
|
||||
static int dm_test_acpi_cmd_items(struct unit_test_state *uts)
|
||||
{
|
||||
struct acpi_ctx ctx;
|
||||
void *buf;
|
||||
|
||||
buf = malloc(BUF_SIZE);
|
||||
ut_assertnonnull(buf);
|
||||
|
||||
ctx.current = buf;
|
||||
ut_assertok(acpi_fill_ssdt(&ctx));
|
||||
console_record_reset();
|
||||
run_command("acpi items", 0);
|
||||
ut_assert_nextline("dev 'acpi-test', type 1, size 2");
|
||||
ut_assert_nextline("dev 'acpi-test2', type 1, size 2");
|
||||
ut_assert_console_end();
|
||||
|
||||
ctx.current = buf;
|
||||
ut_assertok(acpi_inject_dsdt(&ctx));
|
||||
console_record_reset();
|
||||
run_command("acpi items", 0);
|
||||
ut_assert_nextline("dev 'acpi-test', type 2, size 2");
|
||||
ut_assert_nextline("dev 'acpi-test2', type 2, size 2");
|
||||
ut_assert_console_end();
|
||||
|
||||
console_record_reset();
|
||||
run_command("acpi items -d", 0);
|
||||
ut_assert_nextline("dev 'acpi-test', type 2, size 2");
|
||||
ut_assert_nextlines_are_dump(2);
|
||||
ut_assert_nextline("%s", "");
|
||||
ut_assert_nextline("dev 'acpi-test2', type 2, size 2");
|
||||
ut_assert_nextlines_are_dump(2);
|
||||
ut_assert_nextline("%s", "");
|
||||
ut_assert_console_end();
|
||||
|
||||
return 0;
|
||||
}
|
||||
DM_TEST(dm_test_acpi_cmd_items, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
|
||||
@@ -33,8 +33,10 @@ On most architectures the global data pointer is stored in a register.
|
||||
+------------+----------+
|
||||
| SuperH | r13 |
|
||||
+------------+----------+
|
||||
| x86 32bit | fs |
|
||||
+------------+----------+
|
||||
|
||||
The sandbox, x86, and Xtensa are notable exceptions.
|
||||
The sandbox, x86_64, and Xtensa are notable exceptions.
|
||||
|
||||
Clang for ARM does not support assigning a global register. When using Clang
|
||||
gd is defined as an inline function using assembly code. This adds a few bytes
|
||||
|
||||
@@ -8,6 +8,8 @@ Develop U-Boot
|
||||
:maxdepth: 2
|
||||
|
||||
coccinelle
|
||||
commands
|
||||
crash_dumps
|
||||
global_data
|
||||
logging
|
||||
trace
|
||||
|
||||
@@ -1,6 +1,5 @@
|
||||
# SPDX-License-Identifier: GPL-2.0+
|
||||
#
|
||||
# Copyright (c) 2013 The Chromium OS Authors.
|
||||
.. SPDX-License-Identifier: GPL-2.0+
|
||||
.. Copyright (c) 2013 The Chromium OS Authors.
|
||||
|
||||
Tracing in U-Boot
|
||||
=================
|
||||
@@ -33,73 +32,82 @@ this, follow these steps:
|
||||
|
||||
Add the following to include/configs/sandbox.h (if not already there)
|
||||
|
||||
#define CONFIG_TRACE
|
||||
#define CONFIG_CMD_TRACE
|
||||
#define CONFIG_TRACE_BUFFER_SIZE (16 << 20)
|
||||
#define CONFIG_TRACE_EARLY_SIZE (8 << 20)
|
||||
#define CONFIG_TRACE_EARLY
|
||||
#define CONFIG_TRACE_EARLY_ADDR 0x00100000
|
||||
.. code-block:: c
|
||||
|
||||
#define CONFIG_TRACE
|
||||
#define CONFIG_CMD_TRACE
|
||||
#define CONFIG_TRACE_BUFFER_SIZE (16 << 20)
|
||||
#define CONFIG_TRACE_EARLY_SIZE (8 << 20)
|
||||
#define CONFIG_TRACE_EARLY
|
||||
#define CONFIG_TRACE_EARLY_ADDR 0x00100000
|
||||
|
||||
Build sandbox U-Boot with tracing enabled:
|
||||
|
||||
$ make FTRACE=1 O=sandbox sandbox_config
|
||||
$ make FTRACE=1 O=sandbox
|
||||
.. code-block:: console
|
||||
|
||||
$ make FTRACE=1 O=sandbox sandbox_config
|
||||
$ make FTRACE=1 O=sandbox
|
||||
|
||||
Run sandbox, wait for a bit of trace information to appear, and then capture
|
||||
a trace:
|
||||
|
||||
$ ./sandbox/u-boot
|
||||
.. code-block:: console
|
||||
|
||||
$ ./sandbox/u-boot
|
||||
|
||||
U-Boot 2013.04-rc2-00100-ga72fcef (Apr 17 2013 - 19:25:24)
|
||||
U-Boot 2013.04-rc2-00100-ga72fcef (Apr 17 2013 - 19:25:24)
|
||||
|
||||
DRAM: 128 MiB
|
||||
trace: enabled
|
||||
Using default environment
|
||||
DRAM: 128 MiB
|
||||
trace: enabled
|
||||
Using default environment
|
||||
|
||||
In: serial
|
||||
Out: serial
|
||||
Err: serial
|
||||
=>trace stats
|
||||
671,406 function sites
|
||||
69,712 function calls
|
||||
0 untracked function calls
|
||||
73,373 traced function calls
|
||||
16 maximum observed call depth
|
||||
15 call depth limit
|
||||
66,491 calls not traced due to depth
|
||||
=>trace stats
|
||||
671,406 function sites
|
||||
In: serial
|
||||
Out: serial
|
||||
Err: serial
|
||||
=>trace stats
|
||||
671,406 function sites
|
||||
69,712 function calls
|
||||
0 untracked function calls
|
||||
73,373 traced function calls
|
||||
16 maximum observed call depth
|
||||
15 call depth limit
|
||||
66,491 calls not traced due to depth
|
||||
=>trace stats
|
||||
671,406 function sites
|
||||
1,279,450 function calls
|
||||
0 untracked function calls
|
||||
950,490 traced function calls (333217 dropped due to overflow)
|
||||
16 maximum observed call depth
|
||||
15 call depth limit
|
||||
1,275,767 calls not traced due to depth
|
||||
=>trace calls 0 e00000
|
||||
Call list dumped to 00000000, size 0xae0a40
|
||||
=>print
|
||||
baudrate=115200
|
||||
profbase=0
|
||||
profoffset=ae0a40
|
||||
profsize=e00000
|
||||
stderr=serial
|
||||
stdin=serial
|
||||
stdout=serial
|
||||
0 untracked function calls
|
||||
950,490 traced function calls (333217 dropped due to overflow)
|
||||
16 maximum observed call depth
|
||||
15 call depth limit
|
||||
1,275,767 calls not traced due to depth
|
||||
=>trace calls 0 e00000
|
||||
Call list dumped to 00000000, size 0xae0a40
|
||||
=>print
|
||||
baudrate=115200
|
||||
profbase=0
|
||||
profoffset=ae0a40
|
||||
profsize=e00000
|
||||
stderr=serial
|
||||
stdin=serial
|
||||
stdout=serial
|
||||
|
||||
Environment size: 117/8188 bytes
|
||||
=>host save host 0 trace 0 ${profoffset}
|
||||
11405888 bytes written in 10 ms (1.1 GiB/s)
|
||||
=>reset
|
||||
Environment size: 117/8188 bytes
|
||||
=>host save host 0 trace 0 ${profoffset}
|
||||
11405888 bytes written in 10 ms (1.1 GiB/s)
|
||||
=>reset
|
||||
|
||||
|
||||
Then run proftool to convert the trace information to ftrace format.
|
||||
Then run proftool to convert the trace information to ftrace format
|
||||
|
||||
$ ./sandbox/tools/proftool -m sandbox/System.map -p trace dump-ftrace >trace.txt
|
||||
.. code-block:: console
|
||||
|
||||
Finally run pytimechart to display it:
|
||||
$ ./sandbox/tools/proftool -m sandbox/System.map -p trace dump-ftrace >trace.txt
|
||||
|
||||
$ pytimechart trace.txt
|
||||
Finally run pytimechart to display it
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ pytimechart trace.txt
|
||||
|
||||
Using this tool you can zoom and pan across the trace, with the function
|
||||
calls on the left and little marks representing the start and end of each
|
||||
@@ -109,31 +117,31 @@ function.
|
||||
CONFIG Options
|
||||
--------------
|
||||
|
||||
- CONFIG_TRACE
|
||||
Enables the trace feature in U-Boot.
|
||||
CONFIG_TRACE
|
||||
Enables the trace feature in U-Boot.
|
||||
|
||||
- CONFIG_CMD_TRACE
|
||||
Enables the trace command.
|
||||
CONFIG_CMD_TRACE
|
||||
Enables the trace command.
|
||||
|
||||
- CONFIG_TRACE_BUFFER_SIZE
|
||||
Size of trace buffer to allocate for U-Boot. This buffer is
|
||||
used after relocation, as a place to put function tracing
|
||||
information. The address of the buffer is determined by
|
||||
the relocation code.
|
||||
CONFIG_TRACE_BUFFER_SIZE
|
||||
Size of trace buffer to allocate for U-Boot. This buffer is
|
||||
used after relocation, as a place to put function tracing
|
||||
information. The address of the buffer is determined by
|
||||
the relocation code.
|
||||
|
||||
- CONFIG_TRACE_EARLY
|
||||
Define this to start tracing early, before relocation.
|
||||
CONFIG_TRACE_EARLY
|
||||
Define this to start tracing early, before relocation.
|
||||
|
||||
- CONFIG_TRACE_EARLY_SIZE
|
||||
Size of 'early' trace buffer. Before U-Boot has relocated
|
||||
it doesn't have a proper trace buffer. On many boards
|
||||
you can define an area of memory to use for the trace
|
||||
buffer until the 'real' trace buffer is available after
|
||||
relocation. The contents of this buffer are then copied to
|
||||
the real buffer.
|
||||
CONFIG_TRACE_EARLY_SIZE
|
||||
Size of 'early' trace buffer. Before U-Boot has relocated
|
||||
it doesn't have a proper trace buffer. On many boards
|
||||
you can define an area of memory to use for the trace
|
||||
buffer until the 'real' trace buffer is available after
|
||||
relocation. The contents of this buffer are then copied to
|
||||
the real buffer.
|
||||
|
||||
- CONFIG_TRACE_EARLY_ADDR
|
||||
Address of early trace buffer
|
||||
CONFIG_TRACE_EARLY_ADDR
|
||||
Address of early trace buffer
|
||||
|
||||
|
||||
Building U-Boot with Tracing Enabled
|
||||
@@ -191,20 +199,20 @@ Commands
|
||||
|
||||
The trace command has variable sub-commands:
|
||||
|
||||
- stats
|
||||
Display tracing statistics
|
||||
stats
|
||||
Display tracing statistics
|
||||
|
||||
- pause
|
||||
Pause tracing
|
||||
pause
|
||||
Pause tracing
|
||||
|
||||
- resume
|
||||
Resume tracing
|
||||
resume
|
||||
Resume tracing
|
||||
|
||||
- funclist [<addr> <size>]
|
||||
Dump a list of functions into the buffer
|
||||
funclist [<addr> <size>]
|
||||
Dump a list of functions into the buffer
|
||||
|
||||
- calls [<addr> <size>]
|
||||
Dump function call trace into buffer
|
||||
calls [<addr> <size>]
|
||||
Dump function call trace into buffer
|
||||
|
||||
If the address and size are not given, these are obtained from environment
|
||||
variables (see below). In any case the environment variables are updated
|
||||
@@ -216,14 +224,14 @@ Environment Variables
|
||||
|
||||
The following are used:
|
||||
|
||||
- profbase
|
||||
Base address of trace output buffer
|
||||
profbase
|
||||
Base address of trace output buffer
|
||||
|
||||
- profoffset
|
||||
Offset of first unwritten byte in trace output buffer
|
||||
profoffset
|
||||
Offset of first unwritten byte in trace output buffer
|
||||
|
||||
- profsize
|
||||
Size of trace output buffer
|
||||
profsize
|
||||
Size of trace output buffer
|
||||
|
||||
All of these are set by the 'trace calls' command.
|
||||
|
||||
@@ -231,18 +239,18 @@ These variables keep track of the amount of data written to the trace
|
||||
output buffer by the 'trace' command. The trace commands which write data
|
||||
to the output buffer can use these to specify the buffer to write to, and
|
||||
update profoffset each time. This allows successive commands to append data
|
||||
to the same buffer, for example:
|
||||
to the same buffer, for example::
|
||||
|
||||
trace funclist 10000 e00000
|
||||
trace calls
|
||||
=> trace funclist 10000 e00000
|
||||
=> trace calls
|
||||
|
||||
(the latter command appends more data to the buffer).
|
||||
|
||||
|
||||
- fakegocmd
|
||||
Specifies commands to run just before booting the OS. This
|
||||
is a useful time to write the trace data to the host for
|
||||
processing.
|
||||
fakegocmd
|
||||
Specifies commands to run just before booting the OS. This
|
||||
is a useful time to write the trace data to the host for
|
||||
processing.
|
||||
|
||||
|
||||
Writing Out Trace Data
|
||||
@@ -250,11 +258,11 @@ Writing Out Trace Data
|
||||
|
||||
Once the trace data is in an output buffer in memory there are various ways
|
||||
to transmit it to the host. Notably you can use tftput to send the data
|
||||
over a network link:
|
||||
over a network link::
|
||||
|
||||
fakegocmd=trace pause; usb start; set autoload n; bootp;
|
||||
trace calls 10000000 1000000;
|
||||
tftpput ${profbase} ${profoffset} 192.168.1.4:/tftpboot/calls
|
||||
fakegocmd=trace pause; usb start; set autoload n; bootp;
|
||||
trace calls 10000000 1000000;
|
||||
tftpput ${profbase} ${profoffset} 192.168.1.4:/tftpboot/calls
|
||||
|
||||
This starts up USB (to talk to an attached USB Ethernet dongle), writes
|
||||
a trace log to address 10000000 and sends it to a host machine using
|
||||
@@ -272,16 +280,17 @@ This tool must be given the U-Boot map file and the trace data received
|
||||
from running that U-Boot. It produces a text output file.
|
||||
|
||||
Options
|
||||
-m <map_file>
|
||||
Specify U-Boot map file
|
||||
|
||||
-p <trace_file>
|
||||
Specifiy profile/trace file
|
||||
-m <map_file>
|
||||
Specify U-Boot map file
|
||||
|
||||
-p <trace_file>
|
||||
Specifiy profile/trace file
|
||||
|
||||
Commands:
|
||||
|
||||
- dump-ftrace
|
||||
Write a text dump of the file in Linux ftrace format to stdout
|
||||
dump-ftrace
|
||||
Write a text dump of the file in Linux ftrace format to stdout
|
||||
|
||||
|
||||
Viewing the Trace Data
|
||||
@@ -301,17 +310,17 @@ The following suggestions may be helpful if you are trying to reduce boot
|
||||
time:
|
||||
|
||||
1. Enable CONFIG_BOOTSTAGE and CONFIG_BOOTSTAGE_REPORT. This should get
|
||||
you are helpful overall snapshot of the boot time.
|
||||
you are helpful overall snapshot of the boot time.
|
||||
|
||||
2. Build U-Boot with tracing and run it. Note the difference in boot time
|
||||
(it is common for tracing to add 10% to the time)
|
||||
(it is common for tracing to add 10% to the time)
|
||||
|
||||
3. Collect the trace information as descibed above. Use this to find where
|
||||
all the time is being spent.
|
||||
all the time is being spent.
|
||||
|
||||
4. Take a look at that code and see if you can optimise it. Perhaps it is
|
||||
possible to speed up the initialisation of a device, or remove an unused
|
||||
feature.
|
||||
possible to speed up the initialisation of a device, or remove an unused
|
||||
feature.
|
||||
|
||||
5. Rebuild, run and collect again. Compare your results.
|
||||
|
||||
56
doc/device-tree-bindings/spi/snps,dw-apb-ssi.txt
Normal file
56
doc/device-tree-bindings/spi/snps,dw-apb-ssi.txt
Normal file
@@ -0,0 +1,56 @@
|
||||
Synopsys DesignWare AMBA 2.0 Synchronous Serial Interface
|
||||
and Synopsys DesignWare High Performance Synchronous Serial Interface
|
||||
|
||||
Required properties:
|
||||
- compatible : One of
|
||||
"altr,socfpga-spi",
|
||||
"altr,socfpga-arria10-spi",
|
||||
"canaan,kendryte-k210-spi",
|
||||
"canaan,kendryte-k210-ssi",
|
||||
"intel,stratix10-spi",
|
||||
"intel,agilex-spi",
|
||||
"mscc,ocelot-spi",
|
||||
or "mscc,jaguar2-spi";
|
||||
and one of
|
||||
"snps,dw-apb-ssi-3.20a",
|
||||
"snps,dw-apb-ssi-3.22a",
|
||||
"snps,dw-apb-ssi-3.23",
|
||||
"snps,dw-apb-ssi-4.00a",
|
||||
"snps,dw-apb-ssi-4.01",
|
||||
or "snps,dwc-ssi-1.01a".
|
||||
"snps,dw-apb-ssi" may also be used, but is deprecated in favor of specific
|
||||
version strings.
|
||||
- reg : The register base for the controller. For "mscc,<soc>-spi", a second
|
||||
register set is required (named ICPU_CFG:SPI_MST)
|
||||
- #address-cells : <1>, as required by generic SPI binding.
|
||||
- #size-cells : <0>, also as required by generic SPI binding.
|
||||
- clocks : phandles for the clocks, see the description of clock-names below.
|
||||
The phandle for the "ssi_clk" is required. The phandle for the "pclk" clock
|
||||
is optional. If a single clock is specified but no clock-name, it is the
|
||||
"ssi_clk" clock. If both clocks are listed, the "ssi_clk" must be first.
|
||||
|
||||
Optional properties:
|
||||
- clock-names : Contains the names of the clocks:
|
||||
"ssi_clk", for the core clock used to generate the external SPI clock.
|
||||
"pclk", the interface clock, required for register access.
|
||||
- cs-gpios : Specifies the gpio pins to be used for chipselects.
|
||||
- num-cs : The number of chipselects. If omitted, this will default to 4.
|
||||
- reg-io-width : The I/O register width (in bytes) implemented by this
|
||||
device. Supported values are 2 or 4 (the default).
|
||||
|
||||
Child nodes as per the generic SPI binding.
|
||||
|
||||
Example:
|
||||
|
||||
spi@fff00000 {
|
||||
compatible = "altr,socfpga-arria10-spi",
|
||||
"snps,dw-apb-ssi-4.00a", "snps,dw-apb-ssi";
|
||||
reg = <0xfff00000 0x1000>;
|
||||
interrupts = <0 154 4>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
clocks = <&spi_m_clk>;
|
||||
num-cs = <2>;
|
||||
cs-gpios = <&gpio0 13 0>,
|
||||
<&gpio0 14 0>;
|
||||
};
|
||||
@@ -25,6 +25,7 @@ trying to get it to work optimally on a given system.
|
||||
:maxdepth: 2
|
||||
|
||||
build/index
|
||||
usage/index
|
||||
|
||||
Developer-oriented documentation
|
||||
--------------------------------
|
||||
@@ -109,13 +110,6 @@ Android-specific features available in U-Boot.
|
||||
|
||||
android/index
|
||||
|
||||
Command line
|
||||
------------
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
pstore.rst
|
||||
|
||||
Indices and tables
|
||||
==================
|
||||
|
||||
|
||||
@@ -172,7 +172,7 @@ the '/images' node should have the following layout:
|
||||
- os : OS name, mandatory for types "kernel" and "ramdisk". 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".
|
||||
"u-boot", "rtems", "unity", "integrity".
|
||||
- arch : Architecture name, mandatory for types: "standalone", "kernel",
|
||||
"firmware", "ramdisk" and "fdt". Valid architecture names are: "alpha",
|
||||
"arm", "i386", "ia64", "mips", "mips64", "ppc", "s390", "sh", "sparc",
|
||||
|
||||
@@ -156,11 +156,11 @@ The whitelist database
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_db/ \
|
||||
openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_db/ \
|
||||
-keyout db.key -out db.crt -nodes -days 365
|
||||
$ cert-to-efi-sig-list -g 11111111-2222-3333-4444-123456789abc \
|
||||
cert-to-efi-sig-list -g 11111111-2222-3333-4444-123456789abc \
|
||||
db.crt db.esl
|
||||
$ sign-efi-sig-list -c KEK.crt -k KEK.key db db.esl db.auth
|
||||
sign-efi-sig-list -c KEK.crt -k KEK.key db db.esl db.auth
|
||||
|
||||
Copy the \*.auth files to media, say mmc, that is accessible from U-Boot.
|
||||
|
||||
|
||||
135
doc/usage/bootefi.rst
Normal file
135
doc/usage/bootefi.rst
Normal file
@@ -0,0 +1,135 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0+
|
||||
.. Copyright 2020, Heinrich Schuchardt <xypron.glpk@gmx.de>
|
||||
|
||||
bootefi command
|
||||
===============
|
||||
|
||||
Synopsis
|
||||
--------
|
||||
|
||||
::
|
||||
|
||||
bootefi [image_addr] [fdt_addr]
|
||||
bootefi bootmgr [fdt_addr]
|
||||
bootefi hello [fdt_addr]
|
||||
bootefi selftest [fdt_addr]
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
The *bootefi* command is used to launch a UEFI binary which can be either of
|
||||
|
||||
* UEFI application
|
||||
* UEFI boot services driver
|
||||
* UEFI run-time services driver
|
||||
|
||||
An operating system requires a hardware description which can either be
|
||||
presented as ACPI table (CONFIG\_GENERATE\_ACPI\_TABLE=y) or as device-tree
|
||||
The load address of the device-tree may be provided as parameter *fdt\_addr*. If
|
||||
this address is not specified, the bootefi command will try to fall back in
|
||||
sequence to:
|
||||
|
||||
* the device-tree specified by environment variable *fdt\_addr*
|
||||
* the device-tree specified by environment variable *fdtcontroladdr*
|
||||
|
||||
The load address of the binary is specified by parameter *image_address*. A
|
||||
command sequence to run a UEFI application might look like
|
||||
|
||||
::
|
||||
|
||||
load mmc 0:2 $fdt_addr_r dtb
|
||||
load mmc 0:1 $kernel_addr_r /EFI/grub/grubaa64.efi
|
||||
bootefi $kernel_addr_r $fdt_addr_r
|
||||
|
||||
The last file loaded defines the image file path in the loaded image protocol.
|
||||
Hence the executable should always be loaded last.
|
||||
|
||||
The value of the environment variable *bootargs* is converted from UTF-8 to
|
||||
UTF-16 and passed as load options in the loaded image protocol to the UEFI
|
||||
binary.
|
||||
|
||||
Note
|
||||
UEFI binaries that are contained in FIT images are launched via the
|
||||
*bootm* command.
|
||||
|
||||
UEFI boot manager
|
||||
'''''''''''''''''
|
||||
|
||||
The UEFI boot manager is invoked by the *bootefi bootmgr* sub-command.
|
||||
Here boot options are defined by UEFI variables with a name consisting of the
|
||||
letters *Boot* followed by a four digit hexadecimal number, e.g. *Boot0001* or
|
||||
*BootA03E*. The boot variable defines a label, the device path of the binary to
|
||||
execute as well as the load options passed in the loaded image protocol.
|
||||
|
||||
If the UEFI variable *BootNext* is defined, it specifies the number of the boot
|
||||
option to execute next. If no binary can be loaded via *BootNext* the variable
|
||||
*BootOrder* specifies in which sequence boot options shalled be tried.
|
||||
|
||||
The values of these variables can be managed using the U-Boot command
|
||||
*efidebug*.
|
||||
|
||||
UEFI hello world application
|
||||
''''''''''''''''''''''''''''
|
||||
|
||||
U-Boot can be compiled with a hello world application that can be launched using
|
||||
the *bootefi hello* sub-command. A session might look like
|
||||
|
||||
::
|
||||
|
||||
=> setenv bootargs 'Greetings to the world'
|
||||
=> bootefi hello
|
||||
Booting /MemoryMapped(0x0,0x10001000,0x1000)
|
||||
Hello, world!
|
||||
Running on UEFI 2.8
|
||||
Have SMBIOS table
|
||||
Have device tree
|
||||
Load options: Greetings to the world
|
||||
|
||||
UEFI selftest
|
||||
'''''''''''''
|
||||
|
||||
U-Boot can be compiled with UEFI unit tests. These unit tests are invoked using
|
||||
the *bootefi selftest* sub-command.
|
||||
|
||||
Which unit test is executed is controlled by the environment variable
|
||||
*efi\_selftest*. If this variable is not set, all unit tests that are not marked
|
||||
as 'on request' are executed.
|
||||
|
||||
To show a list of the available unit tests the value *list* can be used
|
||||
|
||||
::
|
||||
|
||||
=> setenv efi_selftest list
|
||||
=> bootefi selftest
|
||||
|
||||
Available tests:
|
||||
'block image transfer' - on request
|
||||
'block device'
|
||||
'configuration tables'
|
||||
...
|
||||
|
||||
A single test is selected for execution by setting the *efi\_selftest*
|
||||
environment variable to match one of the listed identifiers
|
||||
|
||||
::
|
||||
|
||||
=> setenv efi_selftest 'block image transfer'
|
||||
=> bootefi selftest
|
||||
|
||||
Some of the tests execute the ExitBootServices() UEFI boot service and will not
|
||||
return to the command line but require a board reset.
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
To use the *bootefi* command you must specify CONFIG\_CMD\_BOOTEFI=y.
|
||||
The *bootefi hello* sub-command requries CMD\_BOOTEFI\_HELLO=y.
|
||||
The *bootefi selftest* sub-command depends on CMD\_BOOTEFI\_SELFTEST=y.
|
||||
|
||||
See also
|
||||
--------
|
||||
|
||||
* *bootm* for launching UEFI binaries packed in FIT images
|
||||
* *booti*, *bootm*, *bootz* for launching a Linux kernel without using the
|
||||
UEFI sub-system
|
||||
* *efidebug* for setting UEFI boot variables
|
||||
95
doc/usage/bootmenu.rst
Normal file
95
doc/usage/bootmenu.rst
Normal file
@@ -0,0 +1,95 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0+
|
||||
.. (C) Copyright 2011-2012 Pali Rohár <pali@kernel.org>
|
||||
|
||||
bootmenu command
|
||||
================
|
||||
|
||||
The "bootmenu" command uses U-Boot menu interfaces and provides
|
||||
a simple mechanism for creating menus with different boot items.
|
||||
The cursor keys "Up" and "Down" are used for navigation through
|
||||
the items. Current active menu item is highlighted and can be
|
||||
selected using the "Enter" key. The selection of the highlighted
|
||||
menu entry invokes an U-Boot command (or a list of commands)
|
||||
associated with this menu entry.
|
||||
|
||||
The "bootmenu" command interprets ANSI escape sequencies, so
|
||||
an ANSI terminal is required for proper menu rendering and item
|
||||
selection.
|
||||
|
||||
The assembling of the menu is done via a set of environment variables
|
||||
"bootmenu_<num>" and "bootmenu_delay", i.e.::
|
||||
|
||||
bootmenu_delay=<delay>
|
||||
bootmenu_<num>="<title>=<commands>"
|
||||
|
||||
<delay>
|
||||
is the autoboot delay in seconds, after which the first
|
||||
menu entry will be selected automatically
|
||||
|
||||
<num>
|
||||
is the boot menu entry number, starting from zero
|
||||
|
||||
<title>
|
||||
is the text of the menu entry shown on the console
|
||||
or on the boot screen
|
||||
|
||||
<commands>
|
||||
are commands which will be executed when a menu
|
||||
entry is selected
|
||||
|
||||
Title and commands are separated by the first appearance of a '='
|
||||
character in the value of the environment variable.
|
||||
|
||||
The first (optional) argument of the "bootmenu" command is a delay specifier
|
||||
and it overrides the delay value defined by "bootmenu_delay" environment
|
||||
variable. If the environment variable "bootmenu_delay" is not set or if
|
||||
the argument of the "bootmenu" command is not specified, the default delay
|
||||
will be CONFIG_BOOTDELAY. If delay is 0, no menu entries will be shown on
|
||||
the console (or on the screen) and the command of the first menu entry will
|
||||
be called immediately. If delay is less then 0, bootmenu will be shown and
|
||||
autoboot will be disabled.
|
||||
|
||||
Bootmenu always adds menu entry "U-Boot console" at the end of all menu
|
||||
entries specified by environment variables. When selecting this entry
|
||||
the bootmenu terminates and the usual U-Boot command prompt is presented
|
||||
to the user.
|
||||
|
||||
Example environment::
|
||||
|
||||
setenv bootmenu_0 Boot 1. kernel=bootm 0x82000000 # Set first menu entry
|
||||
setenv bootmenu_1 Boot 2. kernel=bootm 0x83000000 # Set second menu entry
|
||||
setenv bootmenu_2 Reset board=reset # Set third menu entry
|
||||
setenv bootmenu_3 U-Boot boot order=boot # Set fourth menu entry
|
||||
bootmenu 20 # Run bootmenu with autoboot delay 20s
|
||||
|
||||
|
||||
The above example will be rendered as below::
|
||||
|
||||
*** U-Boot Boot Menu ***
|
||||
|
||||
Boot 1. kernel
|
||||
Boot 2. kernel
|
||||
Reset board
|
||||
U-Boot boot order
|
||||
U-Boot console
|
||||
|
||||
Hit any key to stop autoboot: 20
|
||||
Press UP/DOWN to move, ENTER to select
|
||||
|
||||
The selected menu entry will be highlighted - it will have inverted
|
||||
background and text colors.
|
||||
|
||||
The "bootmenu" cammand is enabled by::
|
||||
|
||||
CONFIG_CMD_BOOTMENU=y
|
||||
|
||||
To run the bootmenu at startup add these additional settings::
|
||||
|
||||
CONFIG_AUTOBOOT_KEYED=y
|
||||
CONFIG_BOOTDELAY=30
|
||||
CONFIG_AUTOBOOT_MENU_SHOW=y
|
||||
|
||||
When you intend to use the bootmenu on a color frame buffer console,
|
||||
make sure to additionally define::
|
||||
|
||||
CONFIG_CFB_CONSOLE_ANSI=y
|
||||
64
doc/usage/button.rst
Normal file
64
doc/usage/button.rst
Normal file
@@ -0,0 +1,64 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0+
|
||||
|
||||
button command
|
||||
==============
|
||||
|
||||
Synopsis
|
||||
--------
|
||||
|
||||
::
|
||||
|
||||
button list
|
||||
button <name>
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
The button command is used to retrieve the status of a button. To show the
|
||||
status of a button with name 'button1' you would issue the command
|
||||
|
||||
::
|
||||
|
||||
button button1
|
||||
|
||||
The status of the button is both written to the console as *ON* or *OFF* and
|
||||
set in the return value variable *$?* as 0 (true) or 1 (false). To retrieve
|
||||
the status of a button with name *button1* and to write it to environment
|
||||
variable *status1* you would execute the commands
|
||||
|
||||
::
|
||||
|
||||
button button1
|
||||
setenv status1 $?
|
||||
|
||||
A list of all available buttons and their status can be displayed using
|
||||
|
||||
::
|
||||
|
||||
button list
|
||||
|
||||
If a button device has not been probed yet, its status will be shown as
|
||||
*<inactive>* in the list.
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
To use the button command you must specify CONFIG_CMD_BUTTON=y and enable a
|
||||
button driver. The available buttons are defined in the device-tree.
|
||||
|
||||
Return value
|
||||
------------
|
||||
|
||||
The variable *$?* takes the following values
|
||||
|
||||
+---+-----------------------------+
|
||||
| 0 | ON, the button is pressed |
|
||||
+---+-----------------------------+
|
||||
| 1 | OFF, the button is released |
|
||||
+---+-----------------------------+
|
||||
| 0 | button list was shown |
|
||||
+---+-----------------------------+
|
||||
| 1 | button not found |
|
||||
+---+-----------------------------+
|
||||
| 1 | invalid arguments |
|
||||
+---+-----------------------------+
|
||||
17
doc/usage/index.rst
Normal file
17
doc/usage/index.rst
Normal file
@@ -0,0 +1,17 @@
|
||||
Use U-Boot
|
||||
==========
|
||||
|
||||
.. toctree::
|
||||
|
||||
netconsole
|
||||
|
||||
Shell commands
|
||||
--------------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
bootefi
|
||||
bootmenu
|
||||
button
|
||||
pstore
|
||||
@@ -1,3 +1,5 @@
|
||||
Network console
|
||||
===============
|
||||
|
||||
In U-Boot, we implemented the networked console via the standard
|
||||
"devices" mechanism, which means that you can switch between the
|
||||
@@ -6,7 +8,8 @@ serial and network input/output devices by adjusting the 'stdin' and
|
||||
set either of these variables to "nc". Input and output can be
|
||||
switched independently.
|
||||
|
||||
CONFIG_NETCONSOLE_BUFFER_SIZE - Override the default buffer size
|
||||
The default buffer size can be overridden by setting
|
||||
CONFIG_NETCONSOLE_BUFFER_SIZE.
|
||||
|
||||
We use an environment variable 'ncip' to set the IP address and the
|
||||
port of the destination. The format is <ip_addr>:<port>. If <port> is
|
||||
@@ -17,15 +20,16 @@ The source / listening port can be configured separately by setting
|
||||
the 'ncinport' environment variable and the destination port can be
|
||||
configured by setting the 'ncoutport' environment variable.
|
||||
|
||||
For example, if your server IP is 192.168.1.1, you could use:
|
||||
For example, if your server IP is 192.168.1.1, you could use::
|
||||
|
||||
=> setenv nc 'setenv stdout nc;setenv stdin nc'
|
||||
=> setenv ncip 192.168.1.1
|
||||
=> saveenv
|
||||
=> run nc
|
||||
|
||||
On the host side, please use this script to access the console
|
||||
|
||||
On the host side, please use this script to access the console:
|
||||
.. code-block:: bash
|
||||
|
||||
tools/netconsole <ip> [port]
|
||||
|
||||
@@ -54,31 +58,37 @@ file for the original Ingo Molnar's documentation on how to pass
|
||||
parameters to the loadable module.
|
||||
|
||||
The format of the kernel command line parameter (for the static
|
||||
configuration) is as follows:
|
||||
configuration) is as follows
|
||||
|
||||
netconsole=[src-port]@[src-ip]/[<dev>],[tgt-port]@<tgt-ip>/[tgt-macaddr]
|
||||
.. code-block:: bash
|
||||
|
||||
netconsole=[src-port]@[src-ip]/[<dev>],[tgt-port]@<tgt-ip>/[tgt-macaddr]
|
||||
|
||||
where
|
||||
|
||||
src-port source for UDP packets
|
||||
(defaults to 6665)
|
||||
src-ip source IP to use
|
||||
(defaults to the interface's address)
|
||||
dev network interface
|
||||
(defaults to eth0)
|
||||
tgt-port port for logging agent
|
||||
(defaults to 6666)
|
||||
tgt-ip IP address for logging agent
|
||||
(this is the required parameter)
|
||||
tgt-macaddr ethernet MAC address for logging agent
|
||||
(defaults to broadcast)
|
||||
src-port
|
||||
source for UDP packets (defaults to 6665)
|
||||
|
||||
Examples:
|
||||
src-ip
|
||||
source IP to use (defaults to the interface's address)
|
||||
|
||||
dev
|
||||
network interface (defaults to eth0)
|
||||
|
||||
tgt-port
|
||||
port for logging agent (defaults to 6666)
|
||||
|
||||
tgt-ip
|
||||
IP address for logging agent (this is the required parameter)
|
||||
|
||||
tgt-macaddr
|
||||
ethernet MAC address for logging agent (defaults to broadcast)
|
||||
|
||||
Examples
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
netconsole=4444@10.0.0.1/eth1,9353@10.0.0.2/12:34:56:78:9a:bc
|
||||
|
||||
or
|
||||
|
||||
netconsole=@/,@192.168.3.1/
|
||||
|
||||
Please note that for the Linux networked console to work, the
|
||||
@@ -91,6 +101,8 @@ in the ELDK-NFS-based environment.
|
||||
To browse the Linux network console output, use the 'netcat' tool invoked
|
||||
as follows:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
nc -u -l -p 6666
|
||||
|
||||
Note that unlike the U-Boot implementation the Linux netconsole is
|
||||
@@ -57,7 +57,9 @@ Generate kernel crash
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
For test purpose, you can generate a kernel crash by setting reboot timeout to
|
||||
10 seconds and trigger a panic::
|
||||
10 seconds and trigger a panic
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ sudo sh -c "echo 1 > /proc/sys/kernel/sysrq"
|
||||
$ sudo sh -c "echo 10 > /proc/sys/kernel/panic"
|
||||
Reference in New Issue
Block a user