Since S400 will set the memory of SPL image to R/X. We can't write
to any data in SPL image.
1. Set the parameters save/restore only for u-boot, not for SPL. to
avoid write data.
2. Not use MU DM driver but directly call MU API to send release XRDC
to S400 at early phase.
3. Configure the SPL image memory of SRAM2 to writable (R/W/X)
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
According to latest S400 API doc, the the success indicate value is
changed to 0xd6. So update the driver codes.
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The DT bindings of "jedec,spi-nor" [1] defines "m25p,fast-read" property
to indicate that "fast read" opcode can be used to read data from the
chip instead of the usual "read" opcode.
If this property is not present in DT, mask out fast read in
spi_nor_init_params(). This change mirrors the same logic in
spi_nor_info_init_params() in drivers/mtd/spi-nor/core.c in
the Linux kernel v5.14-rc3.
[1] Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml in the kernel tree
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
The smart spi_nor_adjust_hwcaps() does not respect the SPI flash's
hwcaps, and only looks to the controller on what can be supported.
The flash's hwcaps needs to be AND'ed before checking.
Fixes: 71025f013c ("mtd: spi-nor-core: Rework hwcaps selection")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
When slave drivers don't set the max_read_size, the spi-mem should
directly use data.nbytes and not limit to any size. But current
logic will limit to the max_write_size.
This commit mirrors the same changes in the dm version done in
commit 535b1fdb8e ("spi: spi-mem: Fix read data size issue").
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
This chip has been (briefly) tested on the MediaTek MT7688 based GARDENA
smart gateway.
Datasheet: http://xmcwh.com/Uploads/2020-12-17/XM25QH64C_Ver1.1.pdf
Signed-off-by: Reto Schneider <reto.schneider@husqvarnagroup.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
- Fixed broken ICH SPI driver in software sequencer mode
- Added "m25p,fast-read" to SPI flash node for x86 boards
- Drop ROM_NEEDS_BLOBS and BUILD_ROM for x86 ROM builds
- Define a default TSC timer frequency for all x86 boards
- x86 MTRR MSR programming codes bug fixes
- x86 "hob" command bug fixes
- Don't program MTRR for DRAM for FSP1
- Move INIT_PHASE_END_FIRMWARE to FSP2
- Use external graphics card by default on Intel Crown Bay
- tangier: Fix DMA controller IRQ polarity in CSRT
It is a pain to have to specify the value 10 in each call. Add a new
dectoul() function and update the code to use it.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is a pain to have to specify the value 16 in each call. Add a new
hextoul() function and update the code to use it.
Add a proper comment to simple_strtoul() while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Currently there are two places to specify the x86 TSC timer frequency
with one in Kconfig used for early timer and the other one in device
tree used when the frequency cannot be determined from hardware.
This may potentially create an inconsistent config where the 2 values
do not match. Let's use the one specified in Kconfig in the device
tree as well.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Since commit 43c145b8b3 ("spi: ich: Correct max-size bug in ich_spi_adjust_size()")
(in v2020.04-rc1), SPI flash read no longer works with ICH SPI controller
in software sequencer mode.
ICH controller can only transfer a small number of bytes at once.
Before commit 43c145b8b3, the logic happens to make sure data.nbytes
is limited to slave->max_write_size but after commit 43c145b8b3
data.nbytes is no longer limited because slave->max_read_size is not
initialized with a valid number.
Fixes: 43c145b8b3 ("spi: ich: Correct max-size bug in ich_spi_adjust_size()")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
It is fairly easy to handle this case and it makes the emulator more
useful, since PCRs are commonly extended several times.
Add support for this, using U-Boot's sha256 support.
For now sandbox only supports a single PCR, but that is enough for the
tests that currently exist.
Signed-off-by: Simon Glass <sjg@chromium.org>
This is the number of PCRs, so the current check is off by one. Also the
map itself should not be checked, just the resulting pcr_index, to avoid
confusing people who read the code.
Fix these problems.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present the tpm2 emulator does not support storing the device state.
Add this so we can handle the normal vboot flow through the sandbox
executables (VPL->SPL etc.) with the TPM contents staying in place.
Note: sandbox has not yet been converted to use livetree for the state
information, since livetree does not yet support writing to the tree.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add checking as to whether the current TPM state is valid, so we can
implement reading/writing the state.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function current handles the kernel case incorrectly. Fix it, and
use the shorter TPM_HDR_LEN while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add support for this command, moving away from the previous approach of
hard-coding the initial data in the driver, now that the kernel-space data
has to be set up by the higher-level vboot code.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present this code assumes that the TPM data has been read but this may
not be the case. Refactor the code to use a separate pointer so we know
the current state of the data.
Add error checking for the data size.
Signed-off-by: Simon Glass <sjg@chromium.org>
We want to support nvdata in TPM2 as well. To avoid code duplicating the
associated code, move it into a common file.
Drop the special-case logic for the kernel space. This can be handled by
the higher-level code now, i.e. in vboot itself.
Signed-off-by: Simon Glass <sjg@chromium.org>
When scrolling the TrueType console a buffer overrun occurs.
Fixes: a29b012037 ("video: Add a console driver that uses TrueType fonts")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Static inline function _debug_uart_init() should avoid calling external
(non-inline) functions. Therefore do not call get_ref_clk() in
_debug_uart_init() and reimplement its functionality without external
function calls.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
CONFIG_BAUDRATE should be used for setting the baudrate for the early debug
UART. This replaces current hardcoded 115200 value.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behun <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
The PWM pins on North Bridge on Armada 37xx can be configured into PWM
or GPIO functions. When in PWM function, each pin can also be configured
to drive low on 0 and tri-state on 1 (LED mode).
The current definitions handle this by declaring two pin groups for each
pin:
- group "pwmN" with functions "pwm" and "gpio"
- group "ledN_od" ("od" for open drain) with functions "led" and "gpio"
This is semantically incorrect. The correct definition for each pin
should be one group with three functions: "pwm", "led" and "gpio".
Change the "pwmN" groups to support "led" function.
Remove "ledN_od" groups. This cannot break backwards compatibility with
older device trees: no device tree uses it since there is no PWM driver
for this SOC yet. Also "ledN_od" groups are not even documented.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
For the eMMC on ST-Ericsson Ux500v2 we need slightly different
configuration values. Use the existing switch statement to match
the peripheral ID of Ux500v2 (0x10480180) and override the necessary
values to make the eMMC work on devices with ST-Ericsson Ux500.
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com> on stm32f769-disco
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Simplify the code a bit by using the common mmc_of_parse() function
instead of duplicating the device tree parsing code. We can still get
a default value for cfg->f_max by assigning it before calling
mmc_of_parse().
Another advantage of this refactoring is that we parse more properties
now, e.g. "non-removable" can be used to disable CD entirely.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com> on stm32f769-disco
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Simplify the code a bit by using dev_read_addr_ptr() instead of
dev_read_addr(). This avoids having to cast explicitly to void*.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com> on stm32f769-disco
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
The arm,primecell compatible is used for lots of different types
of devices, e.g. I2C, SPI, coresight, ... We really should not bind
the MMC driver to all of them.
Looking through the device trees in U-Boot there seems to be always
a second compatible string for the pl180 device, either arm,pl180
(already listed) or arm,pl18x. Add the "arm,pl18x" compatible to the
list but remove the generic "arm,primecell".
Note that on Linux these compatibles cannot be found in drivers
because AMBA/primecell devices are matched based on their peripheral ID
instead of the compatible.
This fixes the following error messages when booting the ST-Ericsson
U8500 "stemmy" board with the arm_pl180_mmci driver enabled:
MMC: ptm@801ae000 - probe failed: -38
ptm@801af000 - probe failed: -38
funnel@801a6000 - probe failed: -38
tpiu@80190000 - probe failed: -38
etb@801a4000 - probe failed: -38
Cc: Patrice Chotard <patrice.chotard@st.com>
Fixes: 6f41d1a17e ("mmc: arm_pl180_mmci: Sync compatible with kernel")
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com> on stm32f769-disco
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Fix mmc_rpmb_route_frames() implementation to comply with most MMC
drivers that expect some alignment of MMC data frames in memory.
When called from drivers/tee/optee/rpmb.c, the address passed is not
aligned properly. OP-TEE OS inserts a 6-byte header before a raw RPMB
frame which makes RPMB data buffer not 32bit aligned. To prevent breaking
ABI with OPTEE-OS RPC memrefs, allocate a temporary buffer to copy the
data into an aligned memory.
Many RPMB drivers implicitly expect 32bit alignment of the eMMC frame
including arm_pl180_mmci.c, sandbox_mmc.c and stm32_sdmmc2.c
Signed-off-by: Timothée Cercueil <timothee.cercueil@st.com>
Signed-off-by: Timothée Cercueil <litchi.pi@protonmail.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
At present this driver assumes that ulong is 64-bits long. On 32-bit
machines it is not. Use the 64-bit code only on 64-bit machines.
This makes things work correctly on 32-bit machines.
Signed-off-by: Simon Glass <sjg@chromium.org>
This rule should not be in the top-level Makefile. Now that we have a
consistent set of I2C Kconfigs for U-Boot proper, SPL and TPL, we can move
it.
Make use of the existing SPL/TPL rule in drivers/Makefile instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Rename these options so that CONFIG_IS_ENABLED can be used with them.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
At present we have CONFIG_SPL_I2C but not CONFIG_I2C. The reason
CONFIG_I2C is not strictly necessary is that:
a) We have CONFIG_SYS_I2C_LEGACY and CONFIG_DM_I2C for the two possible
i2c stacks
b) In U-Boot proper, we always build drivers/i2c/ regardless of the
options
Still, it is better to have CONFIG_I2C - it makes U-Boot proper similar to
SPL/TPL, so we can (in a future commit) simplify the Makefile rules.
Enable it by default, since as above, we have separate options
(SYS_I2C_LEGACY and DM_I2C) to control whether it is 'really' enabled.
Once we have migrated I2C to driver model, we can drop SYS_I2C_LEGACY and
make DM_I2C become I2C. For now, this lets us simplify the Makefile rules.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
It is quite confusing that CONFIG_SYS_I2C selects the legacy I2C and
CONFIG_DM_I2C selects the current I2C. The deadline to migrate I2C is less
than a year away.
Also we want to have a CONFIG_I2C for U-Boot proper just like we have
CONFIG_SPL_I2C for SPL, so we can simplify the Makefile rules.
Rename this symbol so it is clear it is going away.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
