Align the documentation with the v0.9 spec.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
If one defines HUSH_MODERN_PARSER, it is then possible to use modern parser with:
=> cli get
old
=> cli set modern
=> cli get
modern
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Francis Laniel <francis.laniel@amarulasolutions.com>
This command can be used to print the current parser with 'cli get'.
It can also be used to set the current parser with 'cli set'.
For the moment, only one value is valid for set: old.
Signed-off-by: Francis Laniel <francis.laniel@amarulasolutions.com>
Currently the wget command is hard wired to HTTP port 80. This is
inconvenient, as it is extremely easy to start trivial HTTP server
as an unprivileged user using e.g. python http module to serve the
files, but such a server has to run on one of the higher ports:
"
$ python3 -m http.server -d $(pwd) 8080
"
Make it possible to configure HTTP server port the same way it is
possible to configure TFTP server port, using environment variable
'httpdstp' (similar to 'tftpdstp'). Retain port 80 as the default
fallback port. This way, users can start their own trivial server
and conveniently download whatever files they need into U-Boot.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
The contents of README.sha1 only refer to process around verification
of the pcs440ep board firmware in flash. The device was removed in
commit 242836a893 ("powerpc: ppc4xx: remove pcs440ep support") in
2015 so this readme isn't really relevant anymore so can be removed.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Both SHA1 and (especially) MD5 are no longer as safe as they once were for
cryptographic use. Replaces examples which use them with examples using
SHA256 instead. This will provide more-secure defaults for users who use
documentation examples as a base for their own use. This is not too
necessary for non-verified-boot scenarios (since someone could just replace
the checksum), but I wanted to be complete.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Mention TI_DM argument can be used to fetch a custom DM binary in the
A72 build instructions for K3 devices.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Reviewed-by: Manorit Chawdhry <m-chawdhry@ti.com>
Allow showing a menu and automatically booting, with 'bootflow scan'.
This is more convenient than using a script.
Signed-off-by: Simon Glass <sjg@chromium.org>
To quote the author:
I wanted to add support for ti,lp5562, and found an old submission
from Doug. While trying to modify that to work in current U-Boot, I
found a problem with the "move label handling to core" patches.
Patch 1 is a prerequisite for the ti,lp5562 driver, which turned out
to be needed by Christian as well.
Patch 2 is an attempt at (quick-)fixing the mentioned "move label
handling to core" problem. The real fix consists of changing remaining
drivers to not bind the same driver to the top node as to the child
nodes, but I can't test those other drivers.
Patch 3 introduces a helper which should allow removing some
boilerplate in most individual drivers, and 4,5 apply that in the gpio
and pwm drivers. Converting remaining drivers is trivial, but left out
for now.
Finally patch 6 is the reworked lp5562 driver. While I've changed it
to match existing DT bindings (with the goal of making it work with
our .dts that is known to work with the linux driver), most of the
logic is unchanged from Doug's original patch, so he is still listed
as author.
Changes in v2: Interchange order of patches 1 and 2, add a few R-bs,
and try to trim down the commit message in patch 2.
Driver for the TI LP5562 4 channel LED controller. Supports
independent on/off control of all 4 channels. Supports LED_BLINK on 3
independent channels: blue/green/red. The white channel can blink, but
shares the blue channel blink rate.
Heavily based on patch originally from Doug Zobel [1].
I have modified it so it matches the DT bindings in the linux tree,
and also follows the linux driver implementation more closely. This
should address Tom's concerns, and also matches my goal of making the
U-Boot driver work with our existing .dts which is known to work in
linux.
As our boards only have the R,G,B outputs connected, I have not
actually tested how the white channel behaves, but the R,G,B work
exactly as expected.
[1] https://lore.kernel.org/u-boot/1547150757-1561-1-git-send-email-douglas.zobel@climate.com/
Cc: Doug Zobel <douglas.zobel@climate.com>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
The first four patches are actual fixes. The last three patches add
support for the apparently popular OrangePi Zero 3 board: multiple
people seem to be champing at the bit, so I'd rather give them
something real instead of people using random trees they found on the
Internet. It's actually mostly the new defconfig file anyway, so the
chances for regressions are very slim.
The mtd_debug write does not work in this context. The flashcp command does
work, provides both the erase and write functions and with the verbose
option gives good feedback.
Signed-off-by: Stephen Graf <stephen.graf@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
This is a common typo listed in scripts/spelling.txt. Fix it to match the
patchwork status, which is superseded.
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
At this point, clang can be used on both 32bit and 64bit targets without
issue. Make note of logic we have that will inform clang of the
architecture to build for.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Fix the devicetree used with sandbox. This is needed because the
default (full) devicetree must be used by all phases of boot, with
sandbox.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
To quote the author:
"Scmi" command will be re-introduced per Michal's request.
The functionality is the same as I put it in my patch set of adding
SCMI base protocol support, but made some tweak to make UT, "ut dm
scmi_cmd," more flexible and tolerable when enabling/disabling a specific
SCMI protocol for test purpose.
Each commit may have some change history inherited from the preceding
patch series.
Test
====
The patch series was tested on the following platforms:
* sandbox
This is a help text for scmi command.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>
This enables UFS support for QEMU RISC-V 'virt' machine.
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add generic boot-flow diagrams, and SoC-specific info around build
steps.
Signed-off-by: Jai Luthra <j-luthra@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Move esm-k3.txt to ti,j721e-esm.yaml in line with the devicetree
documentation in kernel.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add am62x_beagleplay_* defconfig customized for the configuration of
BeaglePlay and drop the config fragments.
This is in preparation for dropping the dependency on ti vendor folder
entirely.
Signed-off-by: Nishanth Menon <nm@ti.com>
When using include directives within a section that is included by non
TI board rst file, k3.rst and other include paths need to be relative to
doc/board/ base.
Signed-off-by: Nishanth Menon <nm@ti.com>
Sphinx 6.0 removed the execfile_() function, which we use as part of the
configuration process. They *did* warn us... Just open-code the
functionality as is done in Sphinx itself.
Tested (using SPHINX_CONF, since this code is only executed with an
alternative config file) on various Sphinx versions from 2.5 through 6.0.
Reported-by: Martin Liška <mliska@suse.cz>
Cc: stable@vger.kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Rebased for U-Boot
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Add the README files for the HiSilicon boards to the HTML documentation.
This required a bit of reformatting.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
- squashfs improvements, remove common.h in some places, assorted code
fixes, fix a few CONFIG symbol names in Kconfig files, bring in
linux's <linux/time.h> conversion functions, poplar updates, bcb
improvements.
Currently BCB command-line, C APIs and implementation only
support MMC interface. Extend it to allow various block
device interfaces.
Signed-off-by: Dmitrii Merkurev <dimorinny@google.com>
Cc: Eugeniu Rosca <erosca@de.adit-jv.com>
Cc: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Cc: Sean Anderson <sean.anderson@seco.com>
Cc: Cody Schuffelen <schuffelen@google.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> # on vim3
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
To quote the author:
This series tests raw nand flash in sandbox and fixes various bugs discovered in
the process. I've tried to do things in a contemporary manner, avoiding the
(numerous) variations present on only a few boards. The test is pretty minimal.
Future work could test the rest of the nand API as well as the MTD API.
Bloat (for v1) at [1] (for boards with SPL_NAND_SUPPORT enabled). Almost
everything grows by a few bytes due to nand_page_size. A few boards grow more,
mostly those using nand_spl_loaders.c. CI at [2].
[1] https://gist.github.com/Forty-Bot/9694f3401893c9e706ccc374922de6c2
[2] https://source.denx.de/u-boot/custodians/u-boot-clk/-/pipelines/18443
Add a sandbox NAND flash driver to facilitate testing. This driver supports
any number of devices, each using a single chip-select. The OOB data is
stored in-band, with the separation enforced through the API.
For now, create two devices to test with. The first is a very small device
with basic ECC. The second is an 8G device (chosen to be larger than 32
bits). It uses ONFI, with the values copied from the datasheet. It also
doesn't need too strong ECC, which speeds things up.
Although the nand subsystem determines the parameters of a chip based on
the ID, the driver itself requires devicetree properties for each
parameter. We do not derive parameters from the ID because parsing the ID
is non-trivial. We do not just use the parameters that the nand subsystem
has calculated since that is something we should be testing. An exception
is made for the ECC layout, since that is difficult to encode in the device
tree and is not a property of the device itself.
Despite using file I/O to access the backing data, we do not support using
external files. In my experience, these are unnecessary for testing since
tests can generally be written to write their expected data beforehand.
Additionally, we would need to store the "programmed" information somewhere
(complicating the format and the programming process) or try to detect
whether block are erased at runtime (degrading probe speeds).
Information about whether each page has been programmed is stored in an
in-memory buffer. To simplify the implementation, we only support a single
program per erase. While this is accurate for many larger flashes, some
smaller flashes (512 byte) support multiple programs and/or subpage
programs. Support for this could be added later as I believe some
filesystems expect this.
To test ECC, we support error-injection. Surprisingly, only ECC bytes in
the OOB area are protected, even though all bytes are equally susceptible
to error. Because of this, we take care to only corrupt ECC bytes.
Similarly, because ECC covers "steps" and not the whole page, we must take
care to corrupt data in the same way.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Return an error when the user does not select an OS, so we know whether
to boot or not.
Move calling of bootflow_menu_run() into a separate function so we can
call it from other places.
Expand the test to cover these cases.
Add some documentation also, while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
The sphinx-prompt documentation[0] provides examples on how we can use
prompt as a parameter to simplify the description. Use the same.
While at it, ensure to make all relevant prompts clarified such as gdb
prompts.
[0] http://sbrunner.github.io/sphinx-prompt/
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Signed-off-by: Milan P. Stanić <mps@arvanta.net>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Title underlines should match the length of the title. Unfortunately
docutils only catches underlines that are too short.
Add some missing empty lines after titles.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
