There is xrdc inside i.MX8ULP, we need to configure permission to make
sure AP non-secure world could access the resources.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Since S400 will set the memory of SPL image to R/X. We can't write
to any data in SPL image.
1. Set the parameters save/restore only for u-boot, not for SPL. to
avoid write data.
2. Not use MU DM driver but directly call MU API to send release XRDC
to S400 at early phase.
3. Configure the SPL image memory of SRAM2 to writable (R/W/X)
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
i.MX8ULP support using ROM API to load container image,
it use same ROM API as i.MX8MN/MP, and use same container format
as i.MX8QM/QXP.
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Since the container is shared among i.MX platforms, move its header file
to mach-imx
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Add basic i.MX8ULP support
For the MMU part, Using a simple way the calculate the MMU size to avoid
default heavy calcaulation. And align address and size in the table
settings to 2MB or 4GB as much as possible. So we can reduce the 4K page
allocations in MMU table which will spends much time in create the
page table
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
- Move the PSCI runtime code for H3/A23/A33 into SRAM
- Pick the environment from the actual MMC boot device (SD card vs.
eMMC)
- Plus a small improvement from Icenowy, just for good measure.
So far for the H3, A23, and A33 SoCs, we use DRAM to hold the secure
monitor code (providing PSCI runtime services). And while those SoCs do
not have the secure SRAM B like older SoCs, there is enough (secure)
SRAM A2 to put the monitor code and data in there instead.
Follow the design of 64-bit SoCs and use the first part for the monitor,
and the last 16 KiB for the SCP firmware. With this change, the monitor
no longer needs to reserve a region in DRAM.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
[Andre: amend commit message, fix R40 and V3s build]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
At early U-Boot stage, before relocation, MMU is not yet configured
and disabled. DDR may not be configured with the correct memory
attributes (can be configured in MT_DEVICE instead of MT_MEMORY).
In this case, usage of memcpy_{from, to}io() may leads to synchronous
abort in AARCH64 in case the normal memory address is not 64Bits aligned.
To avoid such situation, forbid usage of normal memory cast to (u64 *) in
case MMU is not enabled.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Cc: mark.kettenis@xs4all.nl
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
It is quite confusing that CONFIG_SYS_I2C selects the legacy I2C and
CONFIG_DM_I2C selects the current I2C. The deadline to migrate I2C is less
than a year away.
Also we want to have a CONFIG_I2C for U-Boot proper just like we have
CONFIG_SPL_I2C for SPL, so we can simplify the Makefile rules.
Rename this symbol so it is clear it is going away.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
CNTFRQ_EL0 is only writable from the highest supported exception
level on the platform. For Armv8-A, this is typically EL3, but
technically EL2 and EL3 are optional so it may need to be
initialized at EL2 or EL1. For Armv8-R, the highest exception
level is always EL2.
This patch moves the initialization outside of the switch_el
block and uses a new macro branch_if_not_highest_el which
dynamically detects whether it is at the highest supported
exception level.
Linux's docs state that CNTFRQ_EL0 should be initialized by the
bootloader. If not set, the the U-Boot prompt countdown hangs.
Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com>
- Enabled distro boot for all TI platforms.
- Cleanup for AM335x Guardian Board
- PRUSS rproc on AM65 platform.
- Add PMIC support for J7200
- Misc fixes for Nokia RX-51
# Conflicts:
# arch/arm/mach-omap2/am33xx/Kconfig
Add clock function to setup relevant clocks for USB3.0 controllers and
PHYs on i.MX8MQ
Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Patrick Wildt <patrick@blueri.se>
Tested-by: Patrick Wildt <patrick@blueri.se>
secureworld_exit() is only used in one file, so make it static
to that file and remove it from sys_proto.h. This
may help with some further optimization in the future.
Signed-off-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210625192308.277136-3-aford173@gmail.com
try_unlock_memory() is only used in one file, so make it static
in that file,remove it from the sys_proto header file, and relocate
it into the #ifdef section that call it. This will make it only built
under the conditions when it is called, and it may help with some
further optimization in the future.
Signed-off-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210625192308.277136-2-aford173@gmail.com
If reset-gpio is defined by device-tree use that if
CONFIG_PCIE_IMX_PERST_GPIO is not defined.
Note that after this the following boards which define
CONFIG_PCIE_IMX_PERST_GPIO in their board header file as well as their
device-tree should be able to remove CONFIG_PCIE_IMX_PERST_GPIO without
consequence:
- mx6sabresd
- mx6sxsabresd
- novena
- tbs2910
- vining_2000
Note that the ge_bx50v3 board uses CONFIG_PCIE_IMX_PERST_GPIO and does
not have reset-gpios defined it it's pcie node in the dt thus removing
CONFIG_PCIE_IMX_PERST_GPIO globally can't be done until that board adds
reset-gpios.
Cc: Ian Ray <ian.ray@ge.com> (maintainer:GE BX50V3 BOARD)
Cc: Sebastian Reichel <sebastian.reichel@collabora.com> (maintainer:GE BX50V3 BOARD)
Cc: Fabio Estevam <festevam@gmail.com> (maintainer:MX6SABRESD BOARD)
Cc: Marek Vasut <marex@denx.de> (maintainer:NOVENA BOARD)
Cc: Soeren Moch <smoch@web.de> (maintainer:TBS2910 BOARD)
Cc: Silvio Fricke <open-source@softing.de> (maintainer:VINING_2000 BOARD)
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
To avoid the complexity of DMA operations (with chained descriptors), we
use repeated MMIO reads and writes to the SD_FIFO_REG, which allows us
to drain or fill the MMC data buffer FIFO very easily.
However those MMIO accesses are somewhat costly, so this limits our MMC
performance, to between 17 and 22 MB/s, but down to 9.5 MB/s on the H6
(partly due to the lower AHB1 frequency).
As it turns out we read the FIFO status register after *every* word we
read or write, which effectively doubles the number of MMIO accesses,
thus effectively more than halving our performance.
To avoid this overhead, we can make use of the FIFO level bits, which are
in the very same FIFO status registers.
So for a read request, we now can collect as many words as the FIFO
level originally indicated, and only then need to update the status
register.
We don't know for sure the size of the FIFO (and it seems to differ
across SoCs anyway), so writing is more fragile, which is why we still
use the old method for that. If we find a minimum FIFO size available on
all SoCs, we could use that, in a later optimisation.
This patch increases the eMMC read speed on a Pine64-LTS from about
22MB/s to 44 MB/s. SD card reads don't gain that much, but with 23 MB/s
we now reach the practical limit for 3.3V SD cards.
On the H6 we double our transfer speed, from 9.5 MB/s to 19.7 MB/s.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Most Allwinner SoCs which use the so called "new timing mode" in their
MMC controllers actually use the double-rate PLL6/PERIPH0 clock as their
parent input clock. This is interestingly enough compensated by a hidden
"by 2" post-divider in the mod clock, so the divider and actual output
rate stay the same.
Even though for the H6 and H616 (but only for them!) we use the doubled
input clock for the divider computation, we never accounted for the
implicit post-divider, so the clock was only half the speed on those SoCs.
This didn't really matter so far, as our slow MMIO routine limits the
transfer speed anyway, but we will fix this soon.
Clean up the code around that selection, to always use the normal PLL6
(PERIPH0(1x)) clock as an input. As the rate and divider are the same,
that makes no difference.
Explain the hardware differences in a comment.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Most clock factors and dividers in the H6 PLLs use a "+1 encoding",
which we were missing on two occasions.
This fixes the MMC clock setup on the H6, which could be slightly off due
to the wrong parent frequency:
mmc 2 set mod-clk req 52000000 parent 1176000000 n 2 m 12 rate 49000000
Also the CPU frequency (PLL1) was a tad too high before.
For PLL5 (DRAM) we already accounted for this +1, but in the DRAM code
itself, not in the bit field macro. Move this there to be aligned with
what the other SoCs and other PLLs do.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
These boards have not been converted to CONFIG_DM_USB by the deadline
and is also missing conversion to CONFIG_DM. Remove them. As this is
the last of the SPEAr platforms, so remove the rest of the remaining
support as well.
Cc: Vipin Kumar <vipin.kumar@st.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
These boards have not been converted to CONFIG_DM_USB by the deadline
and is also missing conversion to CONFIG_DM. Remove them. As this is
also the last SPEAR3XX platform, remove that symbol as well.
Cc: Vipin Kumar <vipin.kumar@st.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
These boards have not been converted to CONFIG_DM_USB by the deadline
and is also missing conversion to CONFIG_DM. Remove them.
Cc: Vipin Kumar <vipin.kumar@st.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
These boards have not been converted to CONFIG_DM_USB by the deadline
and is also missing conversion to CONFIG_DM. Remove them.
Cc: Vipin Kumar <vipin.kumar@st.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
There's nothing special or unique to the lpc32xx that requires its own config
parameter for specifying the console uart index. Therefore instead of using
the lpc32xx-specific CONFIG_SYS_LPC32XX_UART include parameter, use the
already-available CONFIG_CONS_INDEX from Kconfig.
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Since some SoCs and boards do not hae extra asm/arch/gpio.h,
introduce CONFIG_GPIO_EXTRA_HEADER instead of adding
!define(CONFIG_ARCH_XXXX) in asm/gpio.h.
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
All symbols that are defined in Kconfig will always be defined (or not)
prior to preprocessing due to the -include directive while building.
However, symbols which are not yet migrated will only be defined (or
not) once the board config.h is included, via <config.h>. While the end
goal must be to migrate all symbols, today we have cases where the size
of gd will get mismatched within the build, based on include order.
Mitigate this by making sure that any <asm/global_data.h> that uses
symbols not in Kconfig does start with <config.h>. Remove this when not
needed.
Cc: Alexey Brodkin <alexey.brodkin@synopsys.com>
Cc: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Cc: Huan Wang <alison.wang@nxp.com>
Cc: Angelo Dureghello <angelo@sysam.it>
Cc: Rick Chen <rick@andestech.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
RK3568 is a high-performance and low power quad-core application
processor designed for personal mobile internet device and AIoT
equipments.
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
We need those macros to instruct drivers on how to behave for SoC specific
quirks, so let's add it as done for other i.MX SoCs.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
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>
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>
Previously we have known that R40 has a configuration register for its
rank 1, which allows different configuration than rank 0. Reverse
engineering of newest libdram of A64 from Allwinner shows that A64 has
this register too. It's bit 0 (which enables dual rank in rank 0
configuration register) means a dedicated rank size setup is used for
rank 1.
Now, Pine64 scheduled to use a 3GiB LPDDR3 DRAM chip (which has 2GiB
rank 0 and 1GiB rank 1) on PinePhone, that makes asymmetric dual rank
DRAM support necessary.
Add this support. The code could support both A64 and R40, but because
dual rank detection is broken on R40 now, we cannot really use it on R40
currently.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
