This file has changed quite a bit in the last 5 years as the capabilities
of the ECs have grown. Sync it up with the copy in coreboot commit
b9141f2215.
The only change is the addition of EC_VBNV_BLOCK_SIZE_V2. This is needed
because U-Boot uses the new v2 vboot API and this is not currently fully
supported by Chromium OS firmware.
Signed-off-by: Simon Glass <sjg@chromium.org>
The current name conflicts with the Chrome OS verified boot library, which
prevents it being built. That library uses a string whereas U-Boot uses a
64-bit hex value. Rename this in U-Boot.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a string.h header for libraries that expect this to be available, now
that U-Boot's version has moved to include/linux.
Signed-off-by: Simon Glass <sjg@chromium.org>
These are needed for the 2018 version of Chromium OS vboot. Add an
implementation for TPM v1, with v2 to come later.
Signed-off-by: Simon Glass <sjg@chromium.org>
All driver-model operation should return an error code. Adjust this
function to do so also.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
At present we pass around a private pointer to specify the cros_ec device.
With driver model it makes more sense to pass the device. Update the code
to do this.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present ofnode_read_fmap_entry() reads a flash map entry in a format
which is not supported by binman. To allow use to use binman-format
descriptions, update this function.
Also add a simple test.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some devices have children and want to press an existing inactive child
into service when needed. Add a function to help with this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Quite a few functions do not actually modify the device that is passed in.
Update the function signatures to reflect that.
Signed-off-by: Simon Glass <sjg@chromium.org>
There is no reason why this feature should not be supported for uclass-
private data. Update the code accordingly.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present sandbox sets non-blocking I/O as soon as any input is read
from the terminal. However it does not restore the previous state on
exit. Fix this and drop the old os_read_no_block() function.
This means that we always enable blocking I/O in sandbox (if input is a
terminal) whereas previously it would only happen on the first call to
tstc() or getc(). However, the difference is likely not important.
Signed-off-by: Simon Glass <sjg@chromium.org>
This driver was originally written against Chromium OS circa 2012. A few
new features have been added. Enhance the TPM driver to match. This mostly
includes a few new messages and properly modelling whether a particular
'space' is present or not.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use an enum for command values instead of open-coding them. This removes
the need for comments. Also make sure the driver returns proper error
numbers instead of -1.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present there are many situations where sandbox syncs the display to
the SDL frame buffer. This is a very expensive operation but is only
needed every now and then. Update video_sync() so that we can specify
whether this operation is really needed.
At present this flag is not used on other architectures. It could also
be used for reducing writeback-cache flushes but the benefit of that would
need to be investigated.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Add logging to aid debugging features in these drivers. Also drop some
code in sandbox_spi_xfer() which is not used.
Signed-off-by: Simon Glass <sjg@chromium.org>
For debugging it is sometimes useful to write out data for inspection
using an external tool. Add a function which can write this data to a
given file.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present to output a log message you need something like:
log(UCLASS_SPI, LOCL_INFO, "message1");
log(UCLASS_SPI, LOCL_INFO, "message2");
but many files use the same category throughout. Also it is helpful to
shorten the length of log names, providing helpers for common logging
levels. Add some macros so that it is possible to do:
(top of file, before #includes)
#define LOG_CATEGORY UCLASS_SPI
(later in the file)
log_info("message1");
log_debug("message2");
log_err("message3");
Signed-off-by: Simon Glass <sjg@chromium.org>
This macro should have two parameters, not one. Fix it so that it
correctly resolves to _ret when logging is disabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
On my Ubuntu 18.04.1 machine two driver-model bus tests have started
failing recently. The problem appears to be that the DATA region of the
executable is protected. This does not seem correct, but perhaps there
is a reason.
To work around it, unprotect the regions in these tests before accessing
them.
Signed-off-by: Simon Glass <sjg@chromium.org>
Change get_sector_buf() to use map_sysmem() to get a pointer to the
CONFIG_FASTBOOT_BUF_ADDR in memory.
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
With CONFIG_OPTEE_TA_AVB use the trusted application AVB provided by
OP-TEE to manage rollback indexes and device-lock status.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Adds a sandbox tee driver which emulates a generic TEE with the OP-TEE
AVB TA.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
[trini: Fix printf warnings in ta_avb_invoke_func, slots is uint]
Signed-off-by: Tom Rini <trini@konsulko.com>
Adds configuration option OPTEE_TA_AVB and a header file describing the
interface to the Android Verified Boot 2.0 (AVB) trusted application
provided by OP-TEE.
Tested-by: Igor Opaniuk <igor.opaniuk@linaro.org>
Reviewed-by: Igor Opaniuk <igor.opaniuk@linaro.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Adds a uclass to interface with a TEE (Trusted Execution Environment).
A TEE driver is a driver that interfaces with a trusted OS running in
some secure environment, for example, TrustZone on ARM cpus, or a
separate secure co-processor etc.
The TEE subsystem can serve a TEE driver for a Global Platform compliant
TEE, but it's not limited to only Global Platform TEEs.
The over all design is based on the TEE subsystem in the Linux kernel,
tailored for U-Boot.
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Igor Opaniuk <igor.opaniuk@linaro.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Adds mmc_rpmb_route_frames() to route RPMB data frames from/to an
external entity.
Tested-by: Igor Opaniuk <igor.opaniuk@linaro.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
With there now being four device tree files, and 4 separate
defconfig files, the code necessary to determine which board is
being used is no longer necessary as the corresponding pin-muxing
and board names are determined by the device tree.
Signed-off-by: Adam Ford <aford173@gmail.com>
Instead of manually specifying CONFIG_SYS_EXTRA_ENV_RELOC
for every board that needs it, it shouldn't hurt to let
initr_reloc_global_data() always relocate gd->env_addr
unless we know this pointer is outside the initial binary.
To achieve this, the relocation is omitted if
CONFIG_ENV_ADDR is defined (and ENV_IS_EMBEDDED is not).
Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
- fixes to rkimage for SPL boot via USB
- fixes to make_fit_atf.py, incl. entry-point calculation and python3
compatibility
- OP-TEE support for ARMv7-based SoCs
- fixes to RGMII/GMII selection on the RK3328
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJbt0FOAAoJECaAFcEOcohNZmcH/A1mKO0/R4tHCqFP2j0I+OuP
PClkA1HUZuD5phvPMaxdHQBwsq7sAa8AljK1oPCNkslP7mFxToUUBx7xc0vB89P/
D+XsI4uce89hIyTULR2FdhR22MOk41zaLVeNicpQ1keCNbzCwsHsHTA+B4XN/xNe
tdPpu6wN2D+g88DAv+/ebVYgjmxRvFD4qpL9bbZpOqqA8XCcD31ukCR2E4fsESgn
mzwKaKcX6SeYgTVCT8Q15SLTNI1WRUY1Y1laj1WKl4abY+HsTt4Whm9imM2l3K5W
ODj6vnFlwEC9rgdxmtXGcmBfwtyXubSfuZDrMGFAiOlyIUgpPXWZI7i8LYQbZ7s=
=NdBl
-----END PGP SIGNATURE-----
Merge tag 'rockchip-for-v2018.11-rc2' of git://git.denx.de/u-boot-rockchip
Rockchip-focused changes for v2018.11-rc2:
- fixes to rkimage for SPL boot via USB
- fixes to make_fit_atf.py, incl. entry-point calculation and python3
compatibility
- OP-TEE support for ARMv7-based SoCs
- fixes to RGMII/GMII selection on the RK3328
Signed-off-by: Tom Rini <trini@konsulko.com>
Here we do a couple of impovements for all ARC boards
as well as introduce yet another developemnt board.
1. Now for ARC boards we print CPU and board info
which is useful for users and helps with
analysis of logs "post-mortem".
2. Synopsys IoT development kit support is added
This one might bw a bit too late as we're past RC1
but:
1) This doesn't affect any other arches etc
as we change purely ARC code.
2) I've got a chance to talk about U-Boot on
IoT platforms during ELCE (my proposal was on
a wait list and only this week I've got
an update and invitation to talk) so it would
be good to have this board as a primer in upstream
code-base by the time of ELCE 2018.
3) For complete support of IoT devkit I'm yet to
significantly rework regmap subsystem in U-Boot
but that's a different topic and hopefully it will
be done sometime soon... though not this release
cycle for sure.
The DesignWare ARC IoT Development Kit is a versatile platform
that includes the necessary hardware and software to accelerate
software development and debugging of sensor fusion,
voice recognition and face detection designs.
More information is avaialble here [1] and here [2].
The board is based on real silicon with
ARC EM9D-based Data Fusion IP Subsystem.
It sports a rich set of I/O including
* DW USB OTG
* DW MobileStorage (used for micro SD-card)
* GPIO
* multiple serial interface including DW APB UART
* ADC, PWM and eFlash, SRAM and SPI Flash memory
* Real-Time Clock (RTC)
* Bluetooth module with worldwide regulatory compliance
(FCC, IC, CE, ETSI, TELEC)
* On-board 9-axis sensor (gyro, accelerometer and compass)
Extensible with Arduino, Pmod, mikroBUS connectors and a 2x18
extension header.
One of the most interesting features for developers is built-in
Digilent USB JTAG probe so only micro-USB cable is needed!
[1] https://www.synopsys.com/dw/ipdir.php?ds=arc_iot_development_kit
[2] https://www.synopsys.com/dw/doc.php/ds/cc/iot_dev_kit.pdf
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
OP-TEE is an open source trusted OS, in armv7, its loading and
running are like this:
loading:
- SPL load both OP-TEE and U-Boot
running:
- SPL run into OP-TEE in secure mode;
- OP-TEE run into U-Boot in non-secure mode;
To make code simple, it would be fine to use IH_OS_TEE for the
os tyle in TPL(just like IH_OS_LINUX is using both in SPL and U-Boot).
Here is the diagram for SPL loading OP-TEE,
IH_OS_TEE:(make u-boot.itb for SPL)
Non-Secure Secure
BootROM
|
v
SPL
|
v
--------- OP-TEE
|
v
U-Boot
|
V
Linux
For other two king of OP-TEE loading/booting, see commit message:
45b55712d4 image: Add IH_OS_TEE for TEE chain-load boot
More detail:
https://github.com/OP-TEE/optee_os
and search for 'boot arguments' for detail entry parameter in:
core/arch/arm/kernel/generic_entry_a32.S
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Cc: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
This patch adds support for Gigadevices SPI NAND device to the new SPI
NAND infrastructure in U-Boot. Currently only the 128MiB GD5F1GQ4UC
device is supported.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Boris Brezillon <boris.brezillon@bootlin.com>
Cc: Jagan Teki <jagan@openedev.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Jagan Teki <jagan@openedev.com>
The CPfi/4 is derived from XTAL clock and is not fixed. Undo
the previous commit 7984ac8d1635aebd11175c96b07f937a39f0384d.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
This adds QEMU RISC-V 'virt' board target support, with the hope of
helping people easily test U-Boot on RISC-V.
The QEMU virt machine models a generic RISC-V virtual machine with
support for the VirtIO standard networking and block storage devices.
It has CLINT, PLIC, 16550A UART devices in addition to VirtIO and
it also uses device-tree to pass configuration information to guest
software. It implements RISC-V privileged architecture spec v1.10.
Both 32-bit and 64-bit builds are supported. Support is pretty much
preliminary, only booting to U-Boot shell with the UART driver on
a single core. Booting Linux is not supported yet.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
This is the PR for SPI-NAND changes along with few spi changes.
[trini: Re-sync changes for ls1012afrwy_qspi*_defconfig]
Signed-off-by: Tom Rini <trini@konsulko.com>
There should not be a 'nand' command, a 'sf' command and certainly not
a new 'spi-nand' command. Write a 'mtd' command instead to manage all
MTD devices/partitions at once. This should be the preferred way to
access any MTD device.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Jagan Teki <jagan@openedev.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com>
Instead of collecting partitions in a flat list, create a hierarchy
within the mtd_info structure: use a partitions list to keep track of
the partitions of an MTD device (which might be itself a partition of
another MTD device), a pointer to the parent device (NULL when the MTD
device is the root one, not a partition).
By also saving directly in mtd_info the offset of the partition, we
can get rid of the mtd_part structure.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com>
Using an MTD device (resp. partition) name in mtdparts is simple and
straightforward. However, for a long time already, another name was
given in mtdparts to indicate a device (resp. partition) so the
"mtdids" environment variable was created to do the match.
Let's create a function that, from an MTD device (resp. partition)
name, search for the equivalent name in the "mtdparts" environment
variable thanks to the "mtdids" string.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com>
The current parser is very specific to U-Boot mtdparts implementation.
It does not use MTD structures like mtd_info and mtd_partition. Copy
and adapt the current parser in drivers/mtd/mtd-uclass.c (to not break
the current use of mtdparts.c itself) and write some kind of a wrapper
around the current implementation to allow other commands to benefit
from this parsing in a user-friendly way.
This new function will allocate an mtd_partition array for each
successful call. This array must be freed after use by the caller.
The given 'mtdparts' buffer pointer will be moved forward to the next
MTD device (if any, it will point towards a '\0' character otherwise).
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Jagan Teki <jagan@openedev.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com>
The user might want to trigger the probe of any MTD device, export these
functions so they can be called from a command source file.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Jagan Teki <jagan@openedev.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com>
include/mtd.h might be included by files even if CONFIG_DM is not
enabled. In this case, the call to dev_get_uclass_priv() would trigger
a build error. Because this helper has no user, let's drop it off.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
While trying to enable the dw_mmc on rk3188 I managed to confuse
and hang the dw_mmc controller into not delivering further data.
The fifo state never became ready and the driver was iterating in
the while loop reading 0-byte packets forever.
So inspired by how other implementations handle this, check the fifo-
state beforhand and add a timeout to catch any glaring fifo issues
without hanging uboot altogether.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
