On arm64, board info is not applicable and kernel command line patched into
the DT, so the LMB reservation here makes no sense anymore. On legacy arm32,
this might still be necessary on systems which do not use DT or use legacy
ATAGS. Disable this LMB reservation on arm64.
This also permits Linux DT to specify reserved memory node at address close
to the end of DRAM bank, i.e. overlaping with U-Boot location. Since after
boot, U-Boot will be no more, this is OK.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Hai Pham <hai.pham.ud@renesas.com>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Tom Rini <trini@konsulko.com>
Fix following compilation issue when SYS_DCACHE_OFF is enable:
drivers/misc/scmi_agent.c:128: undefined reference to `mmu_set_region_dcache_behaviour'
when SYS_DCACHE_OFF is enable, mmu_set_region_dcache_behaviour() must be
defined.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
If both POSITION_INDEPENDENT and SYS_RELOC_GD_ENV_ADDR are enabled,
wherever original env is placed anywhere, it should be relocated to
the right address.
Relocation offset gd->reloc_off is calculated with SYS_TEXT_BASE in
setup_reloc() and env address gd->env_addr is relocated by the offset in
initr_reloc_global_data().
gd->env_addr
= (orig env) + gd->reloc_off
= (orig env) + (gd->relocaddr - SYS_TEXT_BASE)
However, SYS_TEXT_BASE isn't always runtime base address when
POSITION_INDEPENDENT is enabled. So the relocated env_addr might point to
wrong address. For example, if SYS_TEXT_BASE is zero, gd->env_addr is
out of memory location and memory exception will occur.
There is a difference between linked address such as SYS_TEXT_BASE and
runtime base address. In _main, the difference is calculated as
"run-vs-link" offset. The env_addr should also be added to the offset
to fix the address.
gd->env_addr
= (orig env) + ("run-vs-link" offset) + gd->reloc_off
= (orig env) + (SYS_TEXT_BASE - _start) + (gd->relocaddr - SYS_TEXT_BASE)
= (orig env) + (gd->relocaddr - _start)
Cc: Marek Vasut <marex@denx.de>
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Acked-by: Marek Vasut <marex@denx.de>
Tested-by: Marek Vasut <marex@denx.de>
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>
This commit does the same thing as Linux commit 33def8498fdd.
Use a more generic form for __section that requires quotes to avoid
complications with clang and gcc differences.
Remove the quote operator # from compiler_attributes.h __section macro.
Convert all unquoted __section(foo) uses to quoted __section("foo").
Also convert __attribute__((section("foo"))) uses to __section("foo")
even if the __attribute__ has multiple list entry forms.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When zImage support was added to SPL, the messages were hidden to reduce
code size. However, the wrong config symbol was used. Since this file is
only built when CONFIG_SPL_FRAMEWORK=y, the messages were always hidden.
Use the correct symbol so the messages are printed in U-Boot proper.
Also use IS_ENABLED to drop the #ifdef.
Fixes: 431889d6ad ("spl: zImage support in Falcon mode")
Signed-off-by: Samuel Holland <samuel@sholland.org>
The GICv3 RM requires "The first 1KB of memory for the LPI Pending tables
must contain only zeros on initial allocation, and this must be visible
to the Redistributors, or else the effect is UNPREDICTABLE".
And as the following statement, we here clear the whole Pending tables
instead of the first 1KB.
"An LPI Pending table that contains only zeros, including in the first 1KB,
indicates that there are no pending LPIs.
The first 1KB of the LPI Pending table is IMPLEMENTATION DEFINED. However,
if the first 1KB of the LPI Pending table and the rest of the table contain
only zeros, this must indicate that there are no pending LPIs."
And there isn't any pending LPI under U-Boot, so it's unnecessary to
load the contents of the Pending table during the enablement, then set
the GICR_PENDBASER.PTZ flag.
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> # NXP LS1028A
Reviewed-by: Wasim Khan <wasim.khan@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
On ARMv8 systems
load mmc 0:1 $loadaddr vmlinuz-5.10.0-3-arm64
booti
leads to a hanging system requiring to physically reset the system:
FDT and ATAGS support not compiled in - hanging
### ERROR ### Please RESET the board ###
For systems where physical access is difficult hanging is a poor choice.
It is preferable to reset the system when U-Boot reaches a state that is
not recoverable.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Update the initial value of Domain Access Control Register (DACR)
and set by default the access permission to client (DACR_Dn_CLIENT = 1U)
for each of the 16 domains and no more to all-supervisor
(DACR_Dn_MANAGER = 3U).
This patch allows to activate the domain checking in MMU against the
permission bits in the translation tables and avoids prefetching issue
on ARMv7 [1].
Today it was already done for OMAP2 architecture
./arch/arm/mach-omap2/omap-cache.c::arm_init_domains
introduced by commit de63ac278c ("ARM: mmu: Set domain permissions
to client access") which fixes lot of speculative prefetch aborts seen
on OMAP5 secure devices.
[1] https://developer.arm.com/documentation/ddi0406/b/System-Level-Architecture/Virtual-Memory-System-Architecture--VMSA-/Memory-access-control/The-Execute-Never--XN--attribute-and-instruction-prefetching
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Reported-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Historically, the reset_cpu() function had an `addr` parameter which was
meant to pass in an address of the reset vector location, where the CPU
should reset to. This feature is no longer used anywhere in U-Boot as
all reset_cpu() implementations now ignore the passed value. Generic
code has been added which always calls reset_cpu() with `0` which means
this feature can no longer be used easily anyway.
Over time, many implementations seem to have "misunderstood" the
existence of this parameter as a way to customize/parameterize the reset
(e.g. COLD vs WARM resets). As this is not properly supported, the
code will almost always not do what it is intended to (because all
call-sites just call reset_cpu() with 0).
To avoid confusion and to clean up the codebase from unused left-overs
of the past, remove the `addr` parameter entirely. Code which intends
to support different kinds of resets should be rewritten as a sysreset
driver instead.
This transformation was done with the following coccinelle patch:
@@
expression argvalue;
@@
- reset_cpu(argvalue)
+ reset_cpu()
@@
identifier argname;
type argtype;
@@
- reset_cpu(argtype argname)
+ reset_cpu(void)
{ ... }
Signed-off-by: Harald Seiler <hws@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
There are some calls to bdinfo_print_num_l() with parameters that
could be a 64-bit value on a 32-bit system. Change those calls to
use bdinfo_print_num_ll() instead.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
At present we have bdinfo_print_num() to print unsigned long numbers.
We also have print_phys_addr() which accept numbers that might be
64-bit on a 32-bit platform.
Rename these 2 functions to be clearer:
bdinfo_print_num() => bdinfo_print_num_l()
print_phys_addr() => bdinfo_print_num_ll()
While we are here, make bdinfo_print_num_ll() public so that it can
be used outside cmd/bdinfo.c in the future.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Update announce_and_cleanup() to remove all devices, with the vital ones
being removed last.
This is an extra patch on top of the recent RFC:
http://patchwork.ozlabs.org/project/uboot/list/?series=223280
Signed-off-by: Simon Glass <sjg@chromium.org>
Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Add the Linux magic to the EFI file header to allow running our test
programs with GRUB's linux command. Now we can dump the fixed-up device
tree with our dtbdump.efi tool.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Add a return value to noncached_init and use it directly in the
post-relocation init sequence, rather than using a wrapper stub.
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In the spirit of using the same base name for all of these related macros,
rename this to have the operation at the end. This is not widely used so
the impact is fairly small.
Signed-off-by: Simon Glass <sjg@chromium.org>
There is SPL_ARMV8_SEC_FIRMWARE_SUPPORT and ARMV8_SEC_FIRMWARE_SUPPORT.
Thus use CONFIG_IS_ENABLED() instead of the simple #ifdef.
Signed-off-by: Michael Walle <michael@walle.cc>
Acked-by: Michal Simek <michal.simek@xilinx.com>
Linking a U-Boot larger than 1MB fails with PIE enabled:
u-boot/arch/arm/cpu/armv8/start.S:71:(.text+0x3c): relocation
truncated to fit: R_AARCH64_ADR_PREL_LO21 against symbol `__rel_dyn_end'
defined in .bss_start section in u-boot.
This extends the supported range by using adrp & add to load symbols
early while starting up.
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
SPL_CLEAR_BSS is called regardless of build type if
CONFIG_SPL_EARLY_BSS is defined. Add a guard for CONFIG_SPL_BUILD
to fix.
Signed-off-by: Brian Moyer <bdm310@gmail.com>
Use device tree and UCLASS_SYSCON driver to get
Generic Interrupt Controller (GIC) lpi address and
maximum GIC redistributors count.
Also update Kconfig to select REGMAP and SYSCON when
GIC_V3_ITS is enabled.
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Use device tree and UCLASS_IRQ driver to get following
Generic Interrupt Controller (GIC) details,
-GIC Distributor interface (GICD) base address and
-GIC Redistributors (GICR) base address.
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The Linux coding style guide (Documentation/process/coding-style.rst)
clearly says:
It's a **mistake** to use typedef for structures and pointers.
Besides, using typedef for structures is annoying when you try to make
headers self-contained.
Let's say you have the following function declaration in a header:
void foo(bd_t *bd);
This is not self-contained since bd_t is not defined.
To tell the compiler what 'bd_t' is, you need to include <asm/u-boot.h>
#include <asm/u-boot.h>
void foo(bd_t *bd);
Then, the include direcective pulls in more bloat needlessly.
If you use 'struct bd_info' instead, it is enough to put a forward
declaration as follows:
struct bd_info;
void foo(struct bd_info *bd);
Right, typedef'ing bd_t is a mistake.
I used coccinelle to generate this commit.
The semantic patch that makes this change is as follows:
<smpl>
@@
typedef bd_t;
@@
-bd_t
+struct bd_info
</smpl>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Provide function for setting arbitrary virtual-physical MMU mapping
and cache settings for the given region.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
We don't really want to have ARM-specific code in a generic file. Create
a new arch-specific function to hold it, and move it into that.
Make the function weak so that any arch can implement it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We should not use typedefs in U-Boot. They cannot be used as forward
declarations which means that header files must include the full header to
access them.
Drop the typedef and rename the struct to remove the _s suffix which is
now not useful.
This requires quite a few header-file additions.
Signed-off-by: Simon Glass <sjg@chromium.org>
Move this header out of the common header. Network support is used in
quite a few places but it still does not warrant blanket inclusion.
Note that this net.h header itself has quite a lot in it. It could be
split into the driver-mode support, functions, structures, checksumming,
etc.
Signed-off-by: Simon Glass <sjg@chromium.org>
If dcache is switched OFF to ON state and if non-cached memory is
used, this non-cached memory must be re-declared as uncached to mmu
each time dcache is set ON.
Introduce noncached_set_region() to set this non-cached region's mmu
settings. Let architecture override it by defining it as a weak
function.
For ARM architecture, noncached_set_region() defines all noncached
region as non-cacheable.
Issue found on STM32MP1 platform using dwc_eth_qos ethernet driver,
when going from dcache OFF to dcache ON state, ethernet driver issued
TX timeout errors when performing dhcp or ping.
It can be reproduced with the following sequence:
dhcp
while true ; do
ping 192.168.1.300 ;
dcache off ;
ping 192.168.1.300 ;
dcache on ;
done
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Ramon Fried <rfried.dev@gmail.com>
Cc: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Marek Vasut <marex@denx.de>
initr_enable_interrupts() is an ARM-specific wrapper over
enable_interrupts(), which is run during the common init sequence. It can
be eliminated by moving the enable_interrupts() call to the end of
interrupt_init() function, in arch/arm/lib/interrupts*.c.
Signed-off-by: Ovidiu Panait <ovpanait@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Solved the overflow on phys_addr_t type for start + size in
mmu_set_region_dcache_behaviour() function.
This overflow is avoided by dividing start and end by 2 before addition,
and we only expecting that start and size are even.
This patch doesn't change the current function behavior if the
parameters (start or size) are not aligned on MMU_SECTION_SIZE.
For example, this overflow occurs on ARM32 with:
start = 0xC0000000 and size = 0x40000000
then start + size = 0x100000000 and end = 0x0.
For information the function behavior change with risk of regression,
if we just shift start and size before the addition.
Example with 2MB section size:
MMU_SECTION_SIZE 0x200000 and MMU_SECTION_SHIFT = 21
with start = 0x1000000, size = 0x1000000,
- with the proposed patch, start = 0 and end = 0x1 as previously
- with the more simple patch:
end = (start >> MMU_SECTION_SHIFT) + (size >> MMU_SECTION_SHIFT)
the value of end change:
start >> 21 = 0, size >> 21 = 0 and end = 0x0 !!!
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Add the new flags DCACHE_DEFAULT_OPTION to define the default
option to use according the compilation flags
CONFIG_SYS_ARM_CACHE_*.
This new compilation flag allows to simplify dram_bank_mmu_setup()
and can be used as third parameter (option=dcache option to select)
of mmu_set_region_dcache_behaviour function.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Add protection in dram_bank_mmu_setup() to avoid access to bd->bi_dram
before relocation.
This patch allow to use the generic weak function dram_bank_mmu_setup
to activate the MMU and the data cache in SPL or in U-Boot before
relocation, when bd->bi_dram is not yet initialized.
In this cases, the MMU must be initialized explicitly with
mmu_set_region_dcache_behaviour function.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
In case CONFIG_SYSRESET is set, do_reset from reset.c will not be available
anywere, even if SYSRESET is disabled for SPL/TPL.
'do_reset' is called from SPL for instance from the panic handler and
PANIC_HANG is not set
Signed-off-by: Claudius Heine <ch@denx.de>
Reviewed-by: Marek Vasut <marex@denx.de>
Introduce arch_reserve_mmu to allow for architecture-specific reserve_mmu
routines. Also, define a weak nop stub for it.
Signed-off-by: Ovidiu Panait <ovpanait@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
As a preparation for turning reserve_mmu into an arch-specific variant,
introduce arm_reserve_mmu on ARM. It implements the default routine for
reserving memory for MMU TLB and needs to be weakly defined in order to allow
for machines to override it.
Without this decoupling, after introducing arch_reserve_mmu, there would be two
weak definitions for it, one in common/board_f.c and one in
arch/arm/lib/cache.c.
Signed-off-by: Ovidiu Panait <ovpanait@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Move the ARM-specific reserve_mmu definition from common/board_f.c
to arch/arm/lib/cache.c.
Signed-off-by: Ovidiu Panait <ovpanait@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
If gd->ram_top has been tuned using board_get_usable_ram_top(),
it must be taken into account when reserving arch lmb.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Patrick DELAUNAY <patrick.delaunay@st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Simplify the arm relocation behavior and get gd directly form new_gd,
as it is already done in crt0_64.S:
ldr x18, [x18, #GD_NEW_GD] /* x18 <- gd->new_gd */
This patch avoid assumption on new GD location (new GD is below bd -
with #GD_SIZE offset).
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Macro SZ_64K is undeclared. Include sizes.h to fix the compilation
error.
Signed-off-by: Wasim Khan <wasim.khan@nxp.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
