Now that we have a 'positive' Kconfig option, use this instead of the
negative one, which is harder to understand.
Signed-off-by: Simon Glass <sjg@chromium.org>
The condition to indicate whether there is a runtime devicetree available
is OF_CONTROL && !OF_PLATDATA. This is a bit unweidly and is repeated in
a lot of places.
Add a new OF_REAL Kconfig which provides this information directly.
Note: This is similar in effect to LIBFDT. We might consider dropping
LIBFDT and using this instead, but this is left for now as we also have
OF_LIBFDT_OVERLAY which it would not make sense to change.
Signed-off-by: Simon Glass <sjg@chromium.org>
The current API is outdated as it requires a devicetree pointer.
Move these functions to use the ofnode API and update this globally. Add
some tests while we are here.
Correct the call in exynos_dsim_config_parse_dt() which is obviously
wrong.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use the more generic reset-gpios property name.
Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Acked-by: Michal Simek <michal.simek@xilinx.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
When printing full help output from a tool, we should be able to handle
a PAGER variable which includes arguments, e.g. PAGER='less -F'.
Signed-off-by: Paul Barker <paul.barker@sancloud.com>
Collect the code for printing the full help message of patman, buildman
and binman into a single function in patman.tools.
Signed-off-by: Paul Barker <paul.barker@sancloud.com>
vexpress_ca9x4 is seemingly the only board except for qemu_arm which
is able to run U-Boot correctly, using the `-M vexpress-a9` option to
QEMU. Building for qemu_arm and running qemu-system-arm with the `-M
virt` argument has a number of downsides, most importantly that it
only supports virtio storage drivers. This significantly reduces its
usefulness in testing memory card and Flash solutions, especially when
the tested images are from a third party source.
So therefore we reintroduce the vexpress_ca9x4 board in this commit,
with the explicit goal of using it with QEMU.
A number of differences to note from the original:
* Since the board was apparently unmaintained, I have now set myself
as the maintainer.
* The board has been converted to use the driver model, which was the
reason it was removed in the first place.
* The vexpress_ca15_tc2 and vexpress_ca5x2 boards, which were removed
in the same commit, are not necessary for the QEMU use case, and
have been omitted.
* An `mmc0` alias was introduced in the dts file. The mmc is not
detected correctly without this, now that it's based on the device
tree instead of the board's init function.
* A couple of other nodes were removed because they were problematic
when trying to run the UEFI bootmgr. Once again, the primary use
case here is QEMU, and these nodes are not needed for that to work.
* Unnecessary board init code has been removed, thanks to driver model
and device tree.
* `CONFIG_OF_EMBED` has been enabled. I know this goes against
recommended practice, but there doesn't seem to be any other way to
pass the dtb to U-Boot in the QEMU scenario. Using the -dtb argument
does not work, I suppose because U-Boot doesn't use the same
mechanics as the kernel when it's booting.
* Load addresses have been changed to fit QEMU use case.
People wanting to get a more detailed, yet somewhat isolated, diff
between this and the original, can run this command:
git diff c6c26a05b89f25a06e7562f8c2071b60fd0c9eac~1 -- \
$( git diff-tree --diff-filter=A -r --name-only HEAD~1 HEAD)
(Make sure to either check out this commit first, or replace HEAD with
the commit ID of this commit)
Signed-off-by: Kristian Amlie <kristian.amlie@northern.tech>
Simplify the bootm and the spl code by using the new config
CONFIG_SUPPORT_PASSING_ATAGS.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
This patch enables the use of the optimized memset(), memmove() &
memcpy() versions recently added on ARM64.
Please note that these optimized functions are now only enabled for
recent GCC versions (>= 9.4), as earlier GCC versions throw these
errors:
aarch64-linux-ar: warning: arch/arm/lib/memset-arm64.o: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000000
...
Signed-off-by: Stefan Roese <sr@denx.de>
[trini: Make this default to off as it causes problems on some platforms still]
Signed-off-by: Tom Rini <trini@konsulko.com>
The optimized memset uses the dc opcode, which causes problems when the
cache is disabled. This patch adds a check if the cache is disabled and
uses a very simple memset implementation in this case. Otherwise the
optimized version is used.
Signed-off-by: Stefan Roese <sr@denx.de>
Ported from https://github.com/ARM-software/optimized-routines
These files are included from this repository, including the latest
git commit ID:
string/aarch64/memcpy.S: afd6244a1f8d
string/aarch64/memset.S: e823e3abf5f8
string/asmdefs.h: e823e3abf5f8
Note that memmove is also handled by the memcpy function.
Please note that when adding these optimized functions as default memset
memcpy functions in U-Boot, U-Boot fails to boot on the LX2160ARDB.
After the initial ATF output, no U-Boot output is shown on the serial
console. Some exception is triggered here in the very early boot process
as some of the assembler opcodes need the caches to be enabled.
Because of this, a follow-up patch will add a check to use a simple
non-optimized memset for the "cache disabled" case.
Note:
I also integrated and tested with the Linux versions of these optimized
functions. They are similar to the ones now integrated but these ARM
versions are still a small bit faster.
Signed-off-by: Stefan Roese <sr@denx.de>
- Rework lmb reservation so we have common code for all arches to use
- armv8 cache.S cleanups, crc32 speedup
- ENV_IS_NOWHWERE, pci io/memory base configuration fixes
Lower 4 bits of PCI_MEMORY_BASE and PCI_MEMORY_LIMIT registers are reserved
and should be zero. So do not set them to non-zero value.
Lower 4 bits of PCI_PREF_MEMORY_BASE and PCI_PREF_MEMORY_LIMIT registers
contain information if 64-bit memory addressing is supported. So preserve
this information when overwriting these registers.
Lower 4 bits of PCI_IO_BASE and PCI_IO_LIMIT register contain information
if 32-bit io addressing is supported. So preserve this information and do
not try to configure 32-bit io addressing (via PCI_IO_BASE_UPPER16 and
PCI_IO_LIMIT_UPPER16 registers) when it is unsupported.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
On MediaTek boards we cannot override the SYS_BOARD / SYS_CONFIG_NAME
variables from defconfig.
This is because in board/mediatek/mtXXXX/Kconfig this value was override
by default due to the if CONFIG_TARGET_MTXXXX condition.
Merge all the Kconfigs to the mach-medatek/Kconfig.
This way:
- we only define SYS_{SOC,VENDOR} once
- all board definitions are in a single place, simplifying the build logic.
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
Add arch_lmb_reserve() implemented using arch_lmb_reserve_generic().
It is rather likely this architecture also needs to cover U-Boot with
LMB before booting Linux.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
Add arch_lmb_reserve() implemented using arch_lmb_reserve_generic().
It is rather likely this architecture also needs to cover U-Boot with
LMB before booting Linux.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Chris Zankel <chris@zankel.net>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
Add arch_lmb_reserve() implemented using arch_lmb_reserve_generic().
This architecture also needs to cover U-Boot with LMB before booting
Linux.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
Add arch_lmb_reserve() implemented using arch_lmb_reserve_generic().
It is rather likely this architecture also needs to cover U-Boot with
LMB before booting Linux.
Reviewed-by: Rick Chen <rick@andestech.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Atish Patra <atish.patra@wdc.com>
Cc: Leo <ycliang@andestech.com>
Cc: Rick Chen <rick@andestech.com>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
Add arch_lmb_reserve() implemented using arch_lmb_reserve_generic().
It is rather likely this architecture also needs to cover U-Boot with
LMB before booting Linux.
Reviewed-by: Rick Chen <rick@andestech.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Rick Chen <rick@andestech.com>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
Add arch_lmb_reserve() implemented using arch_lmb_reserve_generic().
It is rather likely this architecture also needs to cover U-Boot with
LMB before booting Linux.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Thomas Chou <thomas@wytron.com.tw>
Cc: Tom Rini <trini@konsulko.com>
This function is clearly architecture specific code, not board specific
code. The only difference from the previous arm arch_lmb_reserve() is the
extra reservation of 16k of memory below the stack bottom, rather than
the 4k. The common code now also uses 16k alignment. Remove this custom
implementation, as it now behaves exactly as the common code.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Alexey Brodkin <alexey.brodkin@synopsys.com>
Cc: Angelo Dureghello <angelo@sysam.it>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Cc: Hai Pham <hai.pham.ud@renesas.com>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Ye Li <ye.li@nxp.com>
According to input NXP, the 4k alignment is not always sufficient.
Currently iMX works around this problem by implementing board specific
LMB reservation, however it is likely this could also occur on other
systems. Increase the LMB reservation alignment to 16k by default.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Alexey Brodkin <alexey.brodkin@synopsys.com>
Cc: Angelo Dureghello <angelo@sysam.it>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Cc: Hai Pham <hai.pham.ud@renesas.com>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Ye Li <ye.li@nxp.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Switch arc/arm/m68k/microblaze/mips/ppc arch_lmb_reserve() to
arch_lmb_reserve_generic().
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Alexey Brodkin <alexey.brodkin@synopsys.com>
Cc: Angelo Dureghello <angelo@sysam.it>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Cc: Hai Pham <hai.pham.ud@renesas.com>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Wolfgang Denk <wd@denx.de>
The arc/arm/m68k/microblaze/mips/ppc arch_lmb_reserve() implementations
are all mostly the same, except for a couple of details. Implement a
generic arch_lmb_reserve_generic() function which can be parametrized
enough to cater for those differences between architectures. This can
also be parametrized enough so it can handle cases where U-Boot is not
relocated to the end of DRAM e.g. because there is some other reserved
memory past U-Boot (e.g. unmovable firmware for coprocessor), it is not
relocated at all, and other such use cases.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Alexey Brodkin <alexey.brodkin@synopsys.com>
Cc: Angelo Dureghello <angelo@sysam.it>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Cc: Hai Pham <hai.pham.ud@renesas.com>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Wolfgang Denk <wd@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
The arch_lmb_reserve() is called by lib/lmb.c lmb_reserve_common() even
if CMD_BOOTM is not enabled. However, the arc variant of arch_lmb_reserve()
is only compiled in if CMD_BOOTM is enabled.
This currently does not trigger build error, because there is an empty
weak implementation of arch_lmb_reserve(), however that is not the
function that should be used on arc.
Fix this by moving the arch_lmb_reserve() implementation into common
code and always compile it in.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
The arch_lmb_reserve() is called by lib/lmb.c lmb_reserve_common() even
if CMD_BOOT{I,M,Z} is not enabled. However, the arm32/arm64 variant of
arch_lmb_reserve() is only compiled in if CMD_BOOT{I,M,Z} is enabled.
This currently does not trigger build error, because there is an empty
weak implementation of arch_lmb_reserve(), however that is not the
function that should be used on arm32/arm64.
Fix this by moving the arch_lmb_reserve() implementation into common
code and always compile it in.
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
ARMv8.0 has optional crc32 instruction for crc32 calculation. The
instruction is mandatory since ARMv8.1. The crc32 calculation is
faster using the dedicated instruction, e.g. 1.4 GHz iMX8MN gives:
=> time crc32 0x50000000 0x2000000
time: 0.126 seconds # crc32 instruction
time: 0.213 seconds # software crc32
Add implementation using the compiler builtin wrapper for the crc32
instruction and enable it by default, since we don't support any
platforms which do not implement this instruction.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
[trini: Make crc32_table guarded by CONFIG_ARM64_CRC32]
Signed-off-by: Tom Rini <trini@konsulko.com>
Replace the current 2-instruction 2-step tripling code by a
corresponding single instruction leveraging ARMv8-A's "flexible second
operand as a register with optional shift". This has the added benefit
(albeit arguably negligible) of reducing the final code size.
Fix the comment as the tripled cache level is placed in x12, not x0.
Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
Improve the file's readability and conciseness by using the appropriate
Aarch64 instruction: ubfx (unsigned bitfield extract). This makes the
code easier to follow as it directly manipulates the offsets and widths
of the fields read from system registers, as they are expressed in the
Standard (ARM ARM). This has the added benefit (albeit arguably
negligible) of reducing the final code size.
Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
Avoid applying the "fix" introduced by commit 5557eec01c ("env: Fix
invalid env handling in env_init()") to the environment "nowhere".
This is necessary as that commit, by setting the return value of
env_init() to -ENOENT if gd->env_valid is ENV_INVALID, forces that
function to reset gd->env_valid to ENV_VALID. By doing so, it breaks the
assumption (required by ENV_IS_NOWHERE) that gd->env_valid must be
ENV_INVALID.
This, in turn, results in env_relocate() calling env_load() (it should
not), which itself, calls U_BOOT_ENV_LOCATION(nowhere).load() i.e.
env_nowhere_load(). That function, being implemented under the
assumption mentioned above, calls env_set_default(), which in turn,
seeing that gd->env_valid is ENV_VALID (it should not), tries to
dereference whatever lies in gd->env_addr (most likely garbage), leading
to a faulty memory access.
Note that other env_locations might be concerned by this bug but that
this commit only intends to fix it for when ENV_IS_NOWHERE.
Fixes: 5557eec01c ("env: Fix invalid env handling in env_init()")
Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
-----BEGIN PGP SIGNATURE-----
iQFQBAABCgA6FiEEqxhEmNJ6d7ZdeFLIHrMeAg6sL8gFAmFKxpEcHGV1Z2VuLmhy
aXN0ZXZAbWljcm9jaGlwLmNvbQAKCRAesx4CDqwvyBLaB/0XsIdkGAvcHLWW8yUg
27GiRznikNKwn9/qIj2ByraoUd4BvxdQV4gKHR1R9n0sgYh/8VMyLbmhRoCRKFwP
3mQ0MUyjaeU5sEWzasovJVpXhuUapEiV0jEg6t3Lgwd3mp2QK2Pk87zoleQfZNkb
VAVCnt1T+kb3y0W9oa3XZbuH2wam9T5pNWRGW70JbgzdwJNKLO1Qo7MfcUNiDxJu
Jf7uXtYwwILlN38G1KSk1ymMjfaotCqj7RzNaV3Ero57MVj3VzerKGb7H+XPOYf2
nYXyietYLJJkzvHzSDwIdCSVlOSQL8QqVB8GCmLiNQD4tG830RcvSJnYpRLylWQK
6F+Y
=Q/aS
-----END PGP SIGNATURE-----
Merge tag 'u-boot-at91-2022.01-a' of https://source.denx.de/u-boot/custodians/u-boot-at91 into next
First set of u-boot-at91 features for the 2022.01 cycle:
This feature set includes : the support for CPU driver for arm926
(sam9x60 device); changes required for OP-TEE boot for sama5d2_xplained
and sama5d27_som1_ek boards; QSPI boot configuration for sama5d2_icp;
starting to remove old Kconfig unused symbols from config_whitelist.txt
(work will take more time); also small fixes and updates in mach, DT,
configs, etc.
Replace the number in the flexcom-mode property with the define from the
include file.
This corresponds to the approach in Linux kernel.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Add dt-bindings include file for Atmel Flexcom hardware block.
This file is copied from Linux kernel.
It is used in devicetrees from Linux.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
The AT91 RM9200DK board was removed long time ago.
Remove existing references that were not cleaned up.
Fixes: 1c85752258 ("ARM: remove broken "at91rm9200dk" board")
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
CONFIG_SYS_AT91_CPU_NAME looks to be unused.
Remove it and remove it from config_whitelist.txt
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Rewrite the CONFIG_BOOTCOMMAND only if it's not previously configured from
defconfig file.
This allows the user to select from defconfig/menuconfig the desired
boot command.
Adjust the current board defconfigs to reflect the default booting command
for the specific ENV configuration.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Add new config for storing environment from QSPI1.
Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
[eugen.hristev@microchip.com: cleanup and add MAINTAINERS entry]
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Fixed the following DTC build warning (reproducible with W=1)
arch/arm/dts/at91-sama5d2_icp.dtb: Warning (unit_address_format): /ahb/ohci@00400000: unit name should not have leading 0s
arch/arm/dts/at91-sama5d2_icp.dtb: Warning (unit_address_format): /ahb/ehci@00500000: unit name should not have leading 0s
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Reviewed-by: Alexander Dahl <ada@thorsis.com>
Reorder the nodes following the kernel rules: nodes in a range are sorted
by ascending bus address, and when referenced by phandle, are ordered
alphabetically.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Add support for sst26vf064b 64Mbit qspi-flash that is
present on sama5d2_icp board.
Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
[eugen.hristev@microchip.com: move u-boot properties to sama5d2_icp-u-boot.dtsi]
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
When using OP-TEE, address range [0x20000000 - 0x22000000] is reserved.
This modification allows to have a system which always work even when
OP-TEE is present.
Signed-off-by: Clément Léger <clement.leger@bootlin.com>
