Remove the unnecessary file stm32mp157-pinctrl.dtsi and
solve all issues introduced by the commit 8914831860 ("Merge branch
'next'") after a conflict on the patch applied in the next branch in
commit 1a4f57c895 ("ARM: dts: stm32mp1: DT alignment with Linux 5.6-rc1")
Need to reapplied on stm32mp15-pinctrl.dtsi the the 3 patches
applied previously on file "stm32mp157-pinctrl.dtsi" in v2020.04
- commit 4fdbe6487d ("ARM: dts: stm32: Add alternate pinmux for SDMMC1
direction pins")'
- commit 5fdcba6402 ("ARM: dts: stm32: Add alternate pinmux for SDMMC2
pins 4-7")'
- commit 955de51111 ("ARM: dts: stm32: Add alternate pinmux for ethernet
RGMII")'
Cc: Marek Vasut <marex@denx.de>
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
commit 719cab6d2e ("dm: pinctrl: convert pinctrl-single to livetree")
converted pinctrl driver to livetree. In this conversion, the call to
read pinctrl-single,pins/bits property is provided with pinctrl device
pointer instead of pinctrl config pointer. Because of this none of the
pins gets configured. Fix it by passing the right udevice pointer.
Fixes: 719cab6d2e ("dm: pinctrl: convert pinctrl-single to livetree")
Reported-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
- Adds few DT related fixes required for Linux EFI stub to work on
RISC-V.
- Makes SBI v0.2 the default SBI version to work with OpenSBI v0.7.
- Revert "riscv: qemu: clear kernel-start/-end in device tree as
workaround for BBL"
- Remove unnecessary CONFIG_IS_ENABLED().
Keep all the fdt fixups together for better code management.
Signed-off-by: Atish Patra <atish.patra@wdc.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The DT used by U-Boot may be different from the DT being passed to
the OS if the DT is loaded from external media such as network or
mmc. In that case, the reserved-memory node needs to be copied to
the DT passed to the OS.
Signed-off-by: Atish Patra <atish.patra@wdc.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
FU540 uses OF_SEPARATE instead of OF_PRIOR_STAGE.
Enable OF_BOARD_FIXUP to update the DT with reserved-memory node.
Signed-off-by: Atish Patra <atish.patra@wdc.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
In RISC-V, M-mode software can reserve physical memory regions
by setting appropriate physical memory protection (PMP) csr. As the
PMP csr are accessible only in M-mode, S-mode U-Boot can not read
this configuration directly. However, M-mode software can pass this
information via reserved-memory node in device tree so that S-mode
software can access this information.
This patch provides a framework to copy to the reserved-memory node
from one DT to another. This will be used to update the DT used by
U-Boot and the DT passed to the next stage OS.
Signed-off-by: Atish Patra <atish.patra@wdc.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
In U-Boot, the reserved memory end address is considered as a inclusive
address. This notion is followed while adding a reserved memory node to
the DT.
For example:
end_address = start_address + size - 1
Follow the same notion and fix the end address computation while checking
for existing nodes.
Signed-off-by: Atish Patra <atish.patra@wdc.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Linux booting protocol mandates that register "a0" contains the hartid.
However, U-Boot can not pass the hartid via a0 during standard UEFI
protocol. DT nodes are commonly used to pass such information to the OS.
Add a DT node under chosen node to indicate the boot hartid. EFI stub
in Linux kernel will parse this node and pass it to the real kernel
in "a0" before jumping to it.
Signed-off-by: Atish Patra <atish.patra@wdc.com>
Reviewed-by: Rick Chen <rick@andestech.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
To work with latest OpenSBI release (v0.7 or above) that has the HSM
extension support, select the SBI v0.2 support by default.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Atish Patra <atish.patra@wdc.com>
SBI v0.2 is more scalable and extendable to handle future needs
for RISC-V supervisor interfaces. For example, with SBI v0.2 HSM
extension, only a single hart need to boot and enter operating
system. The booting hart can bring up secondary harts one by one
afterwards.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Atish Patra <atish.patra@wdc.com>
U-Boot proper running in S-mode only need SMP support when using
SBI v0.1. With SBI v0.2 HSM extension, it does not need implement
multicore boot in U-Boot proper.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Atish Patra <atish.patra@wdc.com>
With SBI v0.2 HSM extension, only a single hart need to boot and
enter operating system. The booting hart can bring up secondary
harts one by one afterwards.
For U-Boot running in SPL, SMP can be turned on, while in U-Boot
proper, SMP can be optionally turned off if using SBI v0.2 HSM.
Introduce a new SPL_SMP Kconfig option to support this.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Atish Patra <atish.patra@wdc.com>
Two consecutive SMP ifdefs blocks can be combined into one.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Atish Patra <atish.patra@wdc.com>
Prior to QEMU v3.1.0, QEMU generated the 'virt' SoC node with a
"riscv-virtio-soc" compatible string, and a "simple-bus" driver
was created to accommodate that special case in U-Boot.
Starting from QEMU v3.1.0, the SoC node was set as a "simple-bus",
hence the special simple-bus driver is no longer needed.
Update the doc to mention the latest tested QEMU version 4.2.0.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
The commit was added as a workaround required in QEMU when using BBL as
the supervisor binary interface (SBI) for Linux. We are now using
OpenSBI to provide the SBI, the workaround is therefore not required
anymore and can be removed.
This reverts commit 897206c5cc.
Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
CONFIG_IS_ENABLED(FOO) will check FOO config option for U-Boot,
SPL and TPL, so remove unnecessary CONFIG_IS_ENABLED()
Signed-off-by: Pragnesh Patel <pragnesh.patel@sifive.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
- iproc_sdhci memory leak fix and enable R1B resp quirk
- more mmc cmds and several mmc updates from Heinirich
- Use bounce buffer for tmio sdhci
- Alignment check for tmio sdhci
RPMB support is used by the 'mmc rpmb' command and by the OP-TEE support.
We do not need it in SPL.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
This function is only relevant to the MMC driver so calling it
spl_boot_partition() might be confusing. Rename it to
spl_mmc_boot_partition() to make its purpose more clear (and bring
it in line with spl_mmc_boot_mode()).
Signed-off-by: Harald Seiler <hws@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
The function's name is misleading as one might think it is used
generally to select the boot-mode when in reality it is only used by the
MMC driver to find out in what way it should try reading U-Boot Proper
from a device (either using a filesystem, a raw sector/partition, or an
eMMC boot partition).
Rename it to spl_mmc_boot_mode() to make it more obvious what this
function is about.
Link: https://lists.denx.de/pipermail/u-boot/2020-April/405979.html
Signed-off-by: Harald Seiler <hws@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Implement get_b_max() for the Renesas R-Car SDHI controller driver, limit
the b_max per hardware capabilities such that select Gen2 controllers have
16bit block transfer limit, the rest has 32bit block transfer limit and on
Gen3, the block transfer limit on addresses above the 32bit boundary is set
to 1/4 of the malloc area.
Originally, on Gen3, the block transfers above the 32bit area were limited
to PIO only, which resulted in (R8A7795 Salvator-X , HS200 eMMC):
=> time mmc read 0x0000000700000000 0 0x10000
time: 0.151 seconds
=> time mmc read 0x0000000700000000 0 0x100000
time: 11.090 seconds
with bounce buffer in place and b_max adjustment in place:
=> time mmc read 0x0000000700000000 0 0x10000
time: 0.156 seconds
=> time mmc read 0x0000000700000000 0 0x100000
time: 2.349 seconds
Note that the bounce buffer does mallocate and free the bounce buffer
for every transfer. Experiment which removes this results in further
increase of read speed, from 2.349s to 2.156s per 512 MiB of data,
which is not such a significant improvement anymore. It might however
be interesting to have bounce buffer directly in the MMC core or even
block core.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Add getter function which permits adjusting the maximum number of
blocks that could be read in a single sustained read transfer based
on the location of the source/target buffer and length, before such
transfer starts.
This is mainly useful on systems which have various DMA restrictions
for different memory locations, e.g. DMA limited to 32bit addresses,
and where a bounce buffer is used to work around such restrictions.
Since the U-Boot bounce buffer is mallocated, it's size is limited
by the malloc area size, and the read transfer to such a buffer must
also be limited. However, as not all areas are limited equally, the
b_max should be adjusted accordinly as needed to avoid degrading
performance unnecessarily.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
The R-Car SDHI DMA controller has various restrictions. To work around
those restrictions without falling back to PIO, implement bounce buffer
with custom alignment check function which tests for those limitations.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Increase the malloc area size significantly to cater for bounce buffer
used by the SDHI driver.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Add extended version of the bounce_buffer_start(), which permits passing in
a custom alignment checker function for the buffer. This is useful e.g. on
systems with various DMA restrictions and where the checker function might
be more complex than a simple CPU cache alignment check.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
All sub-commands of the mmc command should be shown in the Kconfig menu
next to the mmc command. This includes:
* mmc bkops
* mmc rpmb
* mmc swrite
The mmc rpmb sub-command is not usable without CONFIG_SUPPORT_EMMC_RPMB.
Add the missing dependency.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
set_ios_post return type changed from void to int, correcting
the same to fix compilation warning.
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
Signed-off-by: Bharat Kumar Reddy Gooty <bharat.gooty@broadcom.com>
Provide command 'mmc wp' to power on write protect boot areas on eMMC
devices.
The B_PWR_WP_EN bit in the extended CSD register BOOT_WP is set. The boot
area are write protected until the next power cycle occurs.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Boot partitions of eMMC devices can be power on or permanently write
protected. Let the 'mmc info' command display the protection state.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
When a mismatch is found trying to write an image for one boot method
to a different boot device, print an error message including the image
header marked target boot device type.
Signed-off-by: Joel Johnson <mrjoel@lixil.net>
Reviewed-by: Stefan Roese <sr@denx.de>
With support added for Armada 38x, include the bubt command in
ClearFog defconfig.
Signed-off-by: Joel Johnson <mrjoel@lixil.net>
Reviewed-by: Stefan Roese <sr@denx.de>
Ensure that the device to which an image is being written includes
header information indicating boot support for the destination
device.
This is derived from the support in the SolidRun master-a38x vendor
fork.
Signed-off-by: Joel Johnson <mrjoel@lixil.net>
Reviewed-by: Stefan Roese <sr@denx.de>
Add support for Armada 38x devices in bubt flashing utility.
This is based on (and streamlined from) the support in the SolidRun
master-a38x vendor fork.
Signed-off-by: Joel Johnson <mrjoel@lixil.net>
Reviewed-by: Stefan Roese <sr@denx.de>
Update mvebu SPL boot selection mechanism for the move to driver model
usage by ensuring that the required driver support for SPI and MMC
booting is available in SPL when the respective boot method is
selected.
Previously, all mvebu boards selected a boot method (implicitly
MVEBU_SPL_BOOT_DEVICE_SPI for many) even if SPL booting wasn't used.
This changes mvebu boot method selection to depend on SPL usage which
resolves the issue with aarch64 boards which don't use SPL getting an
implicit boot device selection resulting in unmet dependencies. The
32-bit arm boards do use SPL, but I'm led to conclude that most aren't
intentionally using the MVEBU_SPL_BOOT_DEVICE selection since none have
SPL_DM_SPI enabled in their defconfig even though they still implicitly
select the SPI boot method.
This also results in the new addition of SPL_GPIO_SUPPORT to helios4.
The mainline dts for helios4 includes the cd-gpios entry for sdhci with
identical addresses as the clearfog dts. I don't have a helios4 board
to confirm, but based on the current source conclude that the board
itself is either wired to pull the signal low for eMMC, or the default
MMC boot isn't fully functional in mainline. In either case, as far as
I can tell, including the GPIO support will at least cause no
regression.
Tested on SolidRun ClearFog devices.
Signed-off-by: Joel Johnson <mrjoel@lixil.net>
Reviewed-by: Stefan Roese <sr@denx.de>
Fix duplication resulting from merging of multiple related series.
Commits cecf38a75, bd02fd29f, and 201a500de added or adjusted SCSI
boot support for ClearFog, but in slightly different locations which
didn't result in a merge conflict.
Signed-off-by: Joel Johnson <mrjoel@lixil.net>
Reviewed-by: Stefan Roese <sr@denx.de>
Register value table for DDR PHY clock divider are wrong. They should be
0 or 1 for divide-by-2 or divide-by-4, respectively. Not 1 or 2. Current
values do not make sense, since 2 cannot be achieved, because the
register is only 1 bit long (mask is set to 1).
This fixes clk dump reporting DDR PHY clock rate differently from Linux.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
The current exit codes of 128 and 129 are useful in that they do not
conflict with those returned by tools, but they are not actually valid.
It seems better to pick some codes which work with 'bit bisect run'.
Update them to 100 (for errors) and 101 (for warnings).
Signed-off-by: Simon Glass <sjg@chromium.org>
These are becoming more common now. They cause boards to show warnings
which can be mistaking for compiler warnings.
Add a buildman option to ignore them. This option works only with the
summary option (-s). It does not affect the build process.
Signed-off-by: Simon Glass <sjg@chromium.org>
Unfortunately the plague of device-tree warnings has not lifted. These
warnings infiltrate almost every build, adding noise and confusion.
Add a buildman option to ignore them. This option works only with the
summary option (-s). It does not affect the build process.
Signed-off-by: Simon Glass <sjg@chromium.org>
