Now device_type = "memory" is mandatory to allow u-boot to read memory
node, so let's add it to memory node.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Now device_type = "memory" is mandatory to allow u-boot to read memory
node, so let's add it to memory node.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
This mpu handling works for every i.MXRT SoC that we have, so let's
generalize imxrt1050_region_config to imxrt_region_config.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
os_find_text_base() assumes that first line of /proc/self/maps holds
information about the text. Hence we must call the function before calling
os_malloc() which calls mmap(0x10000000,).
Failure to do so has led to incorrect values for pc_reloc when an
exception was reported
=> exception undefined
Illegal instruction
pc = 0x5628d82e9d3c, pc_reloc = 0x5628c82e9d3c
as well as incorrect output of the bdinfo command
=> bdinfo
relocaddr = 0x0000000007858000
reloc off = 0x0000000010000000
Fixes: b308d9fd18 ("sandbox: Avoid using malloc() for system state")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
For some configurations with more PCIe cards and PCIe bridges, 16 MiB of
PCIe MEM space may not be enough. Since TF-A already allocates a 128 MiB
CPU window for PCIe, and since IO port space is only 64 KiB in total,
use all the remaining space (64 + 32 + 16 + 8 + 4 + 2 + 1 = 127 MiB) for
PCIe MEM.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Current version of this function uses a lot of incorrect assumptions about
the `ranges` DT property:
* parent(#address-cells) == 2
* #size-cells == 2
* number of entries == 2
* address size of first entry == 0x1000000
* second child address entry == base + 0x1000000
Trying to increase PCIe MEM space to more than 16 MiB leads to an overlap
with PCIe IO space, and trying to define additional MEM space (as a third
entry in the `ranges` DT property) causes U-Boot to crash when booting the
kernel.
## Flattened Device Tree blob at 04f00000
Booting using the fdt blob at 0x4f00000
Loading Device Tree to 000000001fb01000, end 000000001fb08f12 ... OK
ERROR: board-specific fdt fixup failed: <unknown error>
- must RESET the board to recover.
Fix a3700_fdt_fix_pcie_regions() to properly parse and update all addresses
in the `ranges` property according to
https://elinux.org/Device_Tree_Usage#PCI_Address_Translation
Now it is possible to increase PCIe MEM space from 16 MiB to maximal value
of 127 MiB.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Fixes: cb2ddb291e ("arm64: mvebu: a37xx: add device-tree fixer for PCIe regions")
Reviewed-by: Stefan Roese <sr@denx.de>
Find PCIe DT node by compatible string instead of retrieving it by using
hardcoded DT path.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Change DT compatible string for A3700 PCIe from 'marvell,armada-37xx-pcie'
to 'marvell,armada-3700-pcie' to make U-Boot A3700 PCIe DT node compatible
with Linux' DT node.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Add defconfig and board support for HiFive Unmatched.
Signed-off-by: Green Wan <green.wan@sifive.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Rick Chen <rick@andestech.com>
Add dts support for fu740. The HiFive Unmatched support is based on
fu740 cpu and drivers in following patch set.
Signed-off-by: Green Wan <green.wan@sifive.com>
[greentime.hu: set fu740 speed to 1.2GHz]
Signed-off-by: Greentime Hu <greentime.hu@sifive.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Rick Chen <rick@andestech.com>
Commit 2243d19e56 ("mmc: mmc-uclass: Use dev_seq() to read aliases
node's index") now actually enforces U-Boot's device enumeration policy,
where explicitly named devices come first, then any other non-named
devices follow, without filling gaps.
For quite a while we have had an "mmc1 = &mmc2;" alias in our
sunxi-u-boot.dtsi, which now leads to the problem that the SD card
(which was always mmc device 0) now gets to be number 2.
This breaks quite some boot scripts, including our own distro boot
commands, and some other features looking at $mmc_bootdev, also
fastboot.
Just add an explicit mmc0 alias in the very same file to fix this and
restore the old behaviour.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reported-by: Samuel Holland <samuel@sholland.org>
Tested-by: Simon Baatz <gmbnomis@gmail.com>
Enable the true random number generator. It can be used, for example, to
generate partition UUIDs when partitioning with the gpt command. The
generator is already enabled in the device trees of several other
STM32MP1‐based boards, like DKx or DHCOM.
Signed-off-by: Grzegorz Szymaszek <gszymaszek@short.pl>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
The AM64x SoC uses a central Device Management and Security Controller
(DMSC) processor that manages all the low-level device controls
including the system-wide SoC reset. The system-wide reset is managed
through the system reset driver.
Add a sysreset controller node as a child of the dmsc node to enable
the "reset" command from U-Boot prompt for the K3 AM642 SK.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
The AM64x SoC uses a central Device Management and Security Controller
(DMSC) processor that manages all the low-level device controls
including the system-wide SoC reset. The system-wide reset is managed
through the system reset driver.
Add a sysreset controller node as a child of the dmsc node to enable
the "reset" command from U-Boot prompt for the K3 AM642 EVM.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
The default U-Boot environment variables and design are all set up for
both the MAIN R5FSS clusters to be in Split-mode. This is the setting
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 both the clusters got switched back to LockStep mode by
mistake in commit 70e167495a ("arm: dts: k3-j721e: Sync Linux v5.11-rc6
dts into U-Boot") also in v2021.04-rc2. This throws the following warning
messages when early-booting the cores using default env variables,
k3_r5f_rproc r5f at 5d00000: Invalid op: Trying to start secondary core 7 in lockstep mode
Load Remote Processor 3 with data at addr=0x82000000 98484 bytes: Failed!
k3_r5f_rproc r5f at 5f00000: Invalid op: Trying to start secondary core 9 in lockstep mode
Load Remote Processor 5 with data at addr=0x82000000 98484 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: 70e167495a ("arm: dts: k3-j721e: Sync Linux v5.11-rc6 dts into U-Boot")
Reported-by: Minas Hambardzumyan <minas@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
The assembly output of the arch_initr_trap() function differed by a
single byte after common.h was removed from traps.c:
fff49a18 <arch_initr_trap>:
fff49a18: 94 21 ff f0 stwu r1,-16(r1)
fff49a1c: 7c 08 02 a6 mflr r0
fff49a20: 90 01 00 14 stw r0,20(r1)
-fff49a24: 80 62 00 44 lwz r3,68(r2)
+fff49a24: 80 62 00 38 lwz r3,56(r2)
fff49a28: 4b ff 76 19 bl fff41040 <trap_init>
fff49a2c: 80 01 00 14 lwz r0,20(r1)
fff49a30: 38 60 00 00 li r3,0
fff49a34: 38 21 00 10 addi r1,r1,16
fff49a38: 7c 08 03 a6 mtlr r0
This was causing a consistent hard lockup during the MMC read / loading
of the QoriQ FMan firmware on a P2041RDB board.
Re-adding the header causes identical assembly to be emitted and allows
the firmware loading and subsequent boot to succeed.
Fixes: 401d1c4f5d ("common: Drop asm/global_data.h from common header")
Signed-off-by: Matt Merhar <mattmerhar@protonmail.com>
Remove qemu_mips boards because DM migration doesn't make sense.
The board support for qemu_mips is already marked as deprecated
in Qemu in favour of the Malta board. Also qemu_mips support
has been removed from Linux a long time ago.
The official replacement is the Malta board. The same Malta U-Boot
image can be used with Qemu and on physical hardware.
All combinations of Big Endian and Little Endian as well as 32 bit
and 64 bit are supported.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
When using LTO, we can throw away the --gc-sections flag, but only if
using private libgcc.
When using system's libgcc, --gc-sections is still needed, otherwise
linking will fail due to undefined references to libc's symbols.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
When building with LTO, using -ffunction-sections/-fdata-sections is not
useful anymore.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
For some reason when building SPL for ARMv8 with LTO, the relocation
information is not discarded.
Discard it explicitly in the linker script.
This fixes LTO build for imx8mm_venice_defconfig.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
Adam Ford says that DM3730 needs board.c compiled without LTO flags.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Adam Ford <aford173@gmail.com>
When building with LTO, the compiler complains about type mismatch of
function usb_gadget_handle_interrupts(). This function is defined
without parameters in files
arch/arm/mach-rockchip/board.c
board/samsung/common/exynos5-dt.c
but it should have one parameter, int index.
Fix this.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
When seaboard_defconfig is compiled with LTO, the compiler complains
about some instructions not being supported in ARM mode.
This is caused by arch/arm/mach-tegra/tegra20/warmboot_avp.c having
different CFLAGS declared in Makefile. This file needs to be compiled
without LTO.
Fix this by removing -flto for this file.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
When building imx8mp_evk_defconfig with LTO, the compiler complains
about type mismatch of function imx_eqos_txclk_set_rate() in file
drivers/net/dwc_eth_qos.c:845:12
which contains a weak definition of this function, vs file
arch/arm/mach-imx/imx8m/clock_imx8mm.c
which contains an implementation.
Change the type of this function in the implementation to fix this.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When building with LTO, the compiler complains about type mismatch of
function clk_bsc_enable() in file:
arch/arm/cpu/armv7/kona-common/clk-stubs.c
vs other files that define or use this function:
warning: type of ‘clk_bsc_enable’ does not match original declaration.
Change the type of this function to that of the other usages.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When building keystone with LTO the compiler complains:
Error: selected processor does not support `smc #0' in Thumb mode
Fix this by removing -flto for the file implementing these SMC calls.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
When imx28_xea_defconfig is built with LTO, the compiler complains about
the two different declarations of _start:
include/asm-generic/sections.h as extern void _start(void);
arch/arm/cpu/arm926ejs/mxs/mxs.c as extern uint32_t _start;
Fix this.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Fix LTO build for some thumb-interwork usecases (such as for
da850evm_defconfig), where inline assmebly such as
mrc p15,0,r2,c1,c0,0
causes the compiler to fail during LTO linking with
Error: selected processor does not support `mrc p15,0,r2,c1,c0,0'
in Thumb mode
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
On ARM, the gd pointer is stored in registers r9 / x18. For this the
-ffixed-r9 / -ffixed-x18 flag is used when compiling, but using global
register variables causes errors when building with LTO, and these
errors are very difficult to overcome.
Richard Biener says [1]:
Note that global register vars shouldn't be used with LTO and if they
are restricted to just a few compilation units the recommended fix is
to build those CUs without -flto.
We cannot do this for U-Boot since all CUs use -ffixed-reg flag.
It seems that with LTO we could in fact store the gd pointer differently
and gain performance or size benefit by allowing the compiler to use
r9 / x18. But this would need more work.
So for now, when building with LTO, go the clang way, and instead of
declaring gd a global register variable, we make it a function call via
macro.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68384
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
The Thumb instruction `ldr` is able to move high registers only from
armv7. For armv5 and armv6 we have to use `mov`.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
In style of linked lists, instead of declaring symbols for boundaries
of getopt options array in the linker script, declare corresponding
sections and retrieve the boundaries via static inline functions.
Without this clang's LTO produces binary without any getopt options,
because for some reason it thinks that array is empty (start and end
symbols are at the same address).
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
