Start by elaborating on what some of our constraints tend to be with
image location values, and document where these external constraints
can come from. Provide a new subsection, an example based on the TI
ARMv7 OMAP2PLUS families of chips, that gives sample values and explains
why we use these particular values. This is based on what is in
include/configs/ti_armv7_common.h as of fb3ad9bd92 ("TI: Add, use a
DEFAULT_LINUX_BOOT_ENV environment string") as this contains just the
values referenced in this document now and not some of the further
additions that are less generic.
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
- Explain why fdt_addr and initrd_addr should not be set to disable
relocation normally.
- Provide some advice on the typical loadaddr default value.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This variable is never set nor explained why it would be set, drop it.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
cp.b is used a lot as a way to load binaries to memory and execute
them, however we may need to integrate this with the efi subsystem to
set it up as a bootdev.
So, introduce a loadm command that will be consistent with the other
loadX commands and will call the efi API's.
ex: loadm $kernel_addr $kernel_addr_r $kernel_size
with this a kernel with CONFIG_EFI_STUB enabled will be loaded and
then subsequently booted with bootefi command.
Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
"valu" should be "value".
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
For indicating the address and size of a memory region other commands use a
<addr>[:<size>] syntax. Do the same for bootefi.
Fixes: 2058983689 ("cmd: bootefi: restore ability to boot arbitrary blob")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
%s/cammand/command/
%s/sequencies/sequences/
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
To quote the author:
The bootflow feature provide a built-in way for U-Boot to automatically
boot an Operating System without custom scripting and other customisation.
This is called 'standard boot' since it provides a standard way for
U-Boot to boot a distro, without scripting.
It introduces the following concepts:
- bootdev - a device which can hold a distro
- bootmeth - a method to scan a bootdev to find bootflows (owned by
U-Boot)
- bootflow - a description of how to boot (owned by the distro)
This series provides an implementation of these, enabled to scan for
bootflows from MMC, USB and Ethernet. It supports the existing distro
boot as well as the EFI loader flow (bootefi/bootmgr). It works
similiarly to the existing script-based approach, but is native to
U-Boot.
With this we can boot on a Raspberry Pi 3 with just one command:
bootflow scan -lb
which means to scan, listing (-l) each bootflow and trying to boot each
one (-b). The final patch shows this.
With a standard way to identify boot devices, booting become easier. It
also should be possible to support U-Boot scripts, for backwards
compatibility only.
...
The design is described in these two documents:
https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2dav4ZkNC12/view?usp=sharinghttps://drive.google.com/file/d/1kTrflO9vvGlKp-ZH_jlgb9TY3WYG6FF9/view?usp=sharing
A image_size parameter has been added to the bootefi parameter.
Describe all parameters.
Correct how the description of how the device-path in the loaded
image protocol is determined.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
* add link to booti man-page
* correct link description for efidebug command
* correct punctuation
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Drop this text at the end since it already mentions bootp and dhcp.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
This doesn't really make much sense in the documentation. Add a code
comment instead.
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>
This adds support for booting entirely from JTAG while using a
hard-coded RCW. With these steps, it is not necessary to program a
"good" RCW using CodeWarrior. The method here can be performed with any
JTAG adapter supported by OpenOCD, including the on-board CMSIS-DAP
(albeit very slowly).
These steps require LS1046A support in OpenOCD, which was added in [1].
[1] 5b70c1f679/
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
[trini: Add reference to doc/board/nxp/ls1046ardb.rst]
This documents how to use semihosting, the new semihosting features, and
how to migrate from smhload.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
This converts the semihosting readme to rST. I have tried to make only
cosmetic changes, but I did fix up the first link (which was broken).
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
This converts the existing README.plan9 to reST, and puts it under
the doc/usage/os directory.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
At present the doc only mentions Arm, PowerPC and x86. RISC-V support
has been added since VxWorks SR0650 support for a while, and U-Boot
supports loading a RISC-V VxWorks kernel too. Let's document it.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This converts the existing README.vxworks to reST, and puts it under
the doc/usage/os directory.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Update the extension command title for consistency with other commands.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Currently all shell command docs are put in the doc/usage root.
Let's group them into cmd/ sub-directory.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Provide human readable descriptions of the speed nodes instead of the name
of constants from the code as it is already done for 'mmc rescan'
command in commit 212f078496 ("doc: mmc rescan speed mode").
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The non-driver model video support was removed two years ago. Drop this
driver, which is only used by nokia_rx51.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fix some typo and wrong information about dfu_alt_info.
- Add the parameter format, decimal only or hexadecimal.
- Use same parameter name for the same kind of parameters.
(e.g. dev -> dev_id)
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
doc/usage/index.rst in branch origin/next includes usage/environment twice.
Remove the duplicate entry.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Literally adhering to the docs gave this wrong output:
U-Boot> setenv fdtaddr 0x87f00000
U-Boot> fdtaddr $fdtaddr
Unknown command 'fdtaddr' - try 'help'
Fixes: d80162cfc5 ("doc: Document how to apply fdt overlays")
Signed-off-by: Alexander Dahl <ada@thorsis.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
This command is fairly complicated so documentation is useful.
Unfortunately I an not sure how the MTD side of things works and cannot
find information about that.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
This has different semantics in different places. Go with the bootm method
and put it in a common function so that the behaviour is consistent in
U-Boot. Update the docs.
To be clear, this changes the way that 'bootelf' and standalone boot
work. Before, if autostart was set to "fred" or "YES", for example, they
would consider that a "yes". This may change behaviour for some boards,
but the only in-tree boards which mention autostart use "no" to disable
it, which will still work.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Wolfgang Denk <wd@denx.de>
Make various other updates suggested during review of the rST conversion.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Make various updates suggested during review of the rST conversion.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Suggested-by: Wolfgang Denk <wd@denx.de>
Add mention of this option since it does a similar thing to the text
environment.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
At present U-Boot environment variables, and thus scripts, are defined
by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
to this file and dealing with quoting and newlines is harder than it
should be. It would be better if we could just type the script into a
text file and have it included by U-Boot.
Add a feature that brings in a .env file associated with the board
config, if present. To use it, create a file in a board/<vendor>
directory, typically called <board>.env and controlled by the
CONFIG_ENV_SOURCE_FILE option.
The environment variables should be of the form "var=value". Values can
extend to multiple lines. See the README under 'Environment Variables:'
for more information and an example.
In many cases environment variables need access to the U-Boot CONFIG
variables to select different options. Enable this so that the environment
scripts can be as useful as the ones currently in the board config files.
This uses the C preprocessor, means that comments can be included in the
environment using /* ... */
Also support += to allow variables to be appended to. This is needed when
using the preprocessor.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Marek Behún <marek.behun@nic.cz>
Move this from the README to rST format.
Drop i2cfast since it is obviously obsolete and breaks the formatting.
Other changes and improvements are in a following patch.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Marek Behún <marek.behun@nic.cz>
Provide human readable descriptions of the speed nodes instead of the name
of constants from the code.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
