This patch configures U-Boot SPL for DHCOM SoM to permit DFU upload of
SPL and subsequent u-boot.itb for recovery or commissioning purposes.
The DFU usage procedure is identical to STM32MP1 DHCOR SoM, see commit
3919aa1722 ("ARM: dts: stm32: Add DFU support for DHCOR recovery") ,
except for switching the SoM into DFU mode. By default, the DHCOM SoM
has no dedicated mechanism for setting BOOTn straps into UART/USB mode,
therefore to enter DFU mode, the SoC must fail to boot from boot media
which can be selected by the BOOTn strap override mechanism first and
then fall back to DFU mode.
In case of a SoM with pre-populated BOOTn strap override button, power
the system off, remove microSD card (if applicable), hold down the BOOTn
strap override button located between eMMC and SoM edge connector, power
on the SoM. The SoC will fail to boot from SD card and fall back into
DFU mode.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Fix the following warning in SPL and make sure that even DTs which
enforce Vbus detection using u-boot,force-vbus-detection;, the DFU
in SPL will work.
dwc2-udc-otg usb-otg@49000000: prop pinctrl-0 index 0 invalid phandle
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Device tree alignment with Linux kernel v5.17-rc1
- ARM: dts: stm32: add pull-up to USART3 and UART7 RX pins
on STM32MP15 DKx boards
- ARM: dts: stm32: clean uart4_idle_pins_a node for stm32mp15
- ARM: dts: stm32: tune the HS USB PHYs on stm32mp15xx-dkx
- ARM: dts: stm32: tune the HS USB PHYs on stm32mp157c-ev1
- ARM: dts: stm32: fix stusb1600 pinctrl used on stm32mp157c-dk
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Add support of the permanent lock support in U-Boot proper
when BSEC is not managed by secure monitor (TF-A SP_MIN or OP-TEE).
This patch avoid issue with stm32key command and fuse command
on basic boot for this missing feature of U-Boot BSEC driver.
Reported-by: Johann Neuhauser <jneuhauser@dh-electronics.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Tested-by: Johann Neuhauser <jneuhauser@dh-electronics.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Remap PCI I/O space to the bus address 0x0 in the Armada 37xx device-tree
in order to support legacy I/O port based cards which have hardcoded I/O
ports in low address space.
Some legacy PCI I/O based cards do not support 32-bit I/O addressing.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
This enum is currently anonymous. Add a name so it can be used in the
code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Commit 7945caf22c ("arm: sunxi: Enable SPI/SPI-FLASH support for A64")
selected CONFIG_SPI by default on all Allwinner A64 boards, even though
only 4 out of the 14 A64 boards have a SPI flash chip. All other SoCs
had to manually select DM_SPI and friends, even though they are a
platform property (the sunxi SPI driver is DM_SPI only).
Clean this up to allow easy selection of SPI flash support in U-Boot
proper, by selecting DM_SPI and DM_SPI_FLASH *if* CONFIG_SPI is
selected, for *all* Allwinner SoCs. This simplifies the defconfig for
two Libretech boards already.
Also remove the forced CONFIG_SPI from the A64 Kconfig, instead let the
four boards which allow SPI booting select this explicitly.
Any board wishing to support SPI flash in U-Boot proper now just defines
CONFIG_SPI and CONFIG_SPI_FLASH_<vendor> in its defconfig, Kconfig takes
care of the rest.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Recent unrelated fixes (9876ae7db6) revealed that we were missing bits
from 2af181b53e in the IOT2050 dt. Add them, but only for main U-Boot.
SPL loads from QSPI only, thus cannot use DMA.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
We only want to call do_board_detect() if CONFIG_TI_I2C_BOARD_DETECT
is set. Same as done for am64.
This makes it possible to add a custom am65 based board design to
U-Boot that does not use this board detection mechanism.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
The a3700_fdt_fix_pcie_regions() function still computes nonsense.
It computes the fixup offset from the PCI address taken from the first
row of the "ranges" array, which means that:
- PCI address must equal CPU address (otherwise the computed fix offset
will be wrong),
- the first row must contain the lowest address.
This is the case for the default device-tree, which is why we didn't
notice it.
It also adds the fixup offset to all PCI and CPU addresses, which is
wrong.
Instead:
1) The fixup offset must be computed from the CPU address, not PCI
address.
2) The fixup offset must be computed from the row containing the lowest
CPU address, which is not necessarily contained in the first row.
3) The PCI address - the address to which the PCIe controller remaps the
address space as seen from the point of view of the PCIe device -
must be fixed by the fix offset in the same way as the CPU address
only in the special case when the CPU adn PCI addresses are the same.
Same addresses means that remapping is disabled, and thus if we
change the CPU address, we need also to change the PCI address so
that the remapping is still disabled afterwards.
Consider an example:
The ranges entries contain:
PCI address CPU address
70000000 EA000000
E9000000 E9000000
EB000000 EB000000
By default CPU PCIe window is at: E8000000 - F0000000
Consider the case when TF-A moves it to: F2000000 - FA000000
Until now the function would take the PCI address of the first entry:
70000000, and the new base, F2000000, to compute the fix offset:
F2000000 - 70000000 = 82000000, and then add 8200000 to all addresses,
resulting in
PCI address CPU address
F2000000 6C000000
6B000000 6B000000
6D000000 6D000000
which is complete nonsense - none of the CPU addresses is in the
requested window.
Now it will take the lowest CPU address, which is in second row,
E9000000, and compute the fix offset F2000000 - E9000000 = 09000000,
and then add it to all CPU addresses and those PCI addresses which
equal to their corresponding CPU addresses, resulting in
PCI address CPU address
70000000 F3000000
F2000000 F2000000
F4000000 F4000000
where all of the CPU addresses are in the needed window.
Fixes: 4a82fca8e3 ("arm: a37xx: pci: Fix a3700_fdt_fix_pcie_regions() function")
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
First set of u-boot-atmel fixes for the 2022.04 cycle:
This fixes set includes only a single fix for the Ethernet on sama7g5ek
board which is broken at the moment.
Commit 88998f7775 ("arm: arm926ej-s: Add sunxi code") introduced
the ARM926 version of the code to save and restore some FEL state, to
be able to return to the BROM FEL code after the SPL has run.
However during review a change was made, that happened to mess up the
register restore part, so SCTLR and CPSR ended up with the wrong values,
breaking return to FEL.
Use the same offset that we actually save those registers to, to make
FEL booting actually work on the Lichee Pi Nano.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The SUNIV SoCs come with a sun6i-style SPI controller at the base address
of sun4i SPI controller. The module clock of the SPI controller is
missing which leaves us running directly from the AHB clock, which is
set to 200MHz.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
[Icenowy: Original implementation]
Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>
[Jesse: adaptation to Upstream U-Boot]
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
In contrast to other Allwinner SoCs the F1C100s BROM does not store a
boot source indicator in the eGON header in SRAM. This leaves the SPL
guessing where we were exactly booted from, and for instance trying
the SD card first, even though we booted from SPI flash.
By inspecting the BROM code and by experimentation, Samuel found that the
top of the BROM stack contains unique pointers for each of the boot
sources, which we can use as a boot source indicator.
This patch removes the existing board_boot_order bodge and replace it
with a proper boot source indication function.
The only caveat is that this only works in the SPL, as the SPL header
gets overwritten with the exception vectors, once U-Boot proper takes
over. Always return MMC0 as the boot source, when called from U-Boot
proper, as a placeholder for now, until we find another way.
Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>
Suggested-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Support for Apple M1 Pro and Max will allow using a single binary for
all M1 SoCs. The M1 Pro/Max have a different memory layout. The RAM
start address is 0x100_0000_0000 instead of 0x8_0000_0000.
Replace the hardcoded memory layout with dynamic initialized
environment variables in board_late_init().
Tested on Mac Mini (2020) and Macbook Pro 14-inch (2021).
Signed-off-by: Janne Grunau <j@jannau.net>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Simplify the binman config and fdt nodes by using the "@..-SEQ"
substitutions and CONFIG_OF_LIST.
Signed-off-by: Michael Walle <michael@walle.cc>
[Rebased]
Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
omap_ehci_hcd_stop appears to be dead code, and omap_ehci_hcd_init
is only called by the probe function, so it can be static to that
function. Remove both from the header along with some additional
checking for DM_USB.
Signed-off-by: Adam Ford <aford173@gmail.com>
These symbols are incorrect, meaning that binman cannot find the
associated entry. This leads to errors like:
binman: Section '/binman/simple-bin': Symbol '_binman_spl_prop_size'
in entry '/binman/simple-bin/u-boot-spl/u-boot-spl-nodtb':
Entry 'spl' not found in list (mkimage,u-boot-spl-nodtb,
u-boot-spl-bss-pad,u-boot-spl-dtb,u-boot-spl,u-boot-img,main-section)
Fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
The default U-Boot environment variables and design are all set up for
the MAIN R5FSS cluster to be in Split-mode. This is the setting used
when the dts nodes were originally added in v2021.01 U-Boot and the
dt nodes are synched with the kernel binding property names in
commit 468ec2f3ef ("remoteproc: k3_r5: Sync to upstreamed kernel DT
property names") merged in v2021.04-rc2.
The modes for the MAIN R5FSS cluster got switched back to LockStep mode
by mistake in commit fa09b12dc5 ("arm: ti: k3: Resync dts files and
bindings with Linux Kernel v5.14") in v2022.01-rc1. This throws the
following warning messages when early-booting the cores using default
env variables,
k3_r5f_rproc r5f@5d00000: Invalid op: Trying to start secondary core 7 in lockstep mode
Load Remote Processor 3 with data@addr=0x82000000 83148 bytes: Failed!
Fix this by switching back both the clusters to the expected Split-mode.
Make this mode change in the u-boot specific dtsi file to avoid such
sync overrides in the future until the kernel dts is also switched to
Split-mode by default.
Fixes: fa09b12dc5 ("arm: ti: k3: Resync dts files and bindings with Linux Kernel v5.14")
Signed-off-by: Suman Anna <s-anna@ti.com>
There are a few memory functions for both the emif4 (AM3517)
and sdrc (OMAP35/DM37) code that can be defined as static,
because those functions are not used externally. Make them
static and clean up some of the corresponding headers.
Signed-off-by: Adam Ford <aford173@gmail.com>
With LTO enabled, some functions appear to be optimized in a
way that causes hanging on some OMAP3 boards after some
unrelated patches were applied. The solution appears to make
several functions __used. There also appears be to be some
dead code, so remove it while cleaning this up.
This has been tested on a general purpose OMAP3530, DM3730,
and AM3517.
Signed-off-by: Adam Ford <aford173@gmail.com>
Correct the min/max voltages of VDD_CPU. As per data sheet the VDD_CPU
minimum voltage is .6V & maximum voltage is .9V.
Correct the same. While at it fix the comment to reflect VDD_CPU
instead of VDD_MPU.
Data Sheet Link: https://www.ti.com/lit/gpn/dra829v
Signed-off-by: Keerthy <j-keerthy@ti.com>
Choose the memory map based on the compatible property from the
device tree passed to us by m1n1. Since DRAM on the M1 Pro/Max
starts at a different address avoid hardcoding the top of usable
memory. Also make sure that the addresses entered into the memory
map are page aligned such that we don't crash in dcache_enable().
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Tested on: Macbook M1 Max
Tested-by: Janne Grunau <j@jannau.net>
The GW7902 is based on the i.MX 8M Mini / Nano SoC featuring:
- LPDDR4 DRAM
- eMMC FLASH
- Gateworks System Controller
- LTE CAT M1 modem
- USB 2.0 HUB
- M.2 Socket with USB2.0, PCIe, and dual-SIM
- IMX8M FEC
- PCIe based GbE
- RS232/RS485/RS422 serial transceiver
- GPS
- CAN bus
- WiFi / Bluetooth
- MIPI header (DSI/CSI/GPIO/PWM/I2S)
- PMIC
To add support for the i.MX8M Nano GW7902:
- Add imx8mn-venice dts/defconfig/include
- Add imx8mn-gw7902 dts
- Add imx8mn-2gb lpddr4 dram configs
- Add misc support for IMX8M Nano SoC
- rename imx8mm-venice.c to venice.c as it is no longer imx8mm specific
- update README with differences for IMX8MN vs IMX8MM
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
The interface for NOR/OneNAND is called "EIM" not "EMI". Fix this.
Signed-off-by: Harald Seiler <hws@denx.de>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
- a37xx: pci: Cleanup and minor fix for root port check (Pali)
- pci: mvebu: Ensure that root port is always on root zero bus (Pali)
- kwbimage: Fix dumping DATA registers for v0 images (Pali)
- kwbimage: Support for parsing extended v0 format (Pali)
- a37xx: Fix code and update DTS files to upstream version (Pali)
- a37xx: Fix and extend building memory map (Pali)
- ddr: marvell: a38x: fix BYTE_HOMOGENEOUS_SPLIT_OUT decision (Marek)
- mvebu: Optionally reset board on DDR training failure (Marek)
Some boards may occacionally fail DDR training. Currently we hang() in
this case. Add an option that makes the board do an immediate reset in
such a case, so that a new training is tried as soon as possible,
instead of hanging and possibly waiting for watchdog to reset the board.
(If the DDR training fails while booting the image via UART, we will
still hang - it doesn't make sense to reset in such a case, because
after reset the board will try booting from another medium, and the
UART booting utility does not expect that.)
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Function is named build_mem_map, not a3700_build_mem_map.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
In function build_mem_map() prepare also mapping for CCI-400 and
BootROM windows.
BootROM window is 1 MB long and by default starts at address 0xfff00000.
A53 AP BootROM is 16 kB long and repeats in this BootROM window 64 times.
RVBAR_EL3 register is set to value 0xffff0000, so by default A53 AP BootROM
is accessed via range 0xffff0000-0xffff3fff.
CCI-400 window when new TF-A version is used, starts at address 0xfe000000
and when old TF-A version is used, starts at address 0xd8000000.
Physical addresses are read directly from mvebu registers, so if TF-A
remaps it in future (again) then it would not cause any issue for U-Boot.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Function build_mem_map() modifies global variable mem_map. This variable is
used by the get_page_table_size() function which is called by function
arm_reserve_mmu() (as aliased macro PGTABLE_SIZE). Function
arm_reserve_mmu() is called earlier than enable_caches() which calls
build_mem_map(). So arm_reserve_mmu() does not calculate reserved memory
correctly.
Fix this issue by calling build_mem_map() from a3700_dram_init() which is
called before arm_reserve_mmu().
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
