We can only select SPL_SKIP_LOWLEVEL_INIT if SPL is enabled, otherwise
we get a warning about unmet dependencies on platforms that don't use
SPL.
Fixes: cf47a8cf8f ("arm: mvebu: Select SPL_SKIP_LOWLEVEL_INIT on ARMADA_32BIT")
Cc: Stefan Roese <sr@denx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Instead of declaring CONFIG_SPL_DRIVERS_MISC in board config header,
select it in Kconfig.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Instead of declaring CONFIG_SYS_MALLOC_SIMPLE dependant on
CONFIG_SPL_BUILD in board config header, select
CONFIG_SPL_SYS_MALLOC_SIMPLE in Kconfig.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Select SPL_SKIP_LOWLEVEL_INIT on 32bit Armada platforms via Kconfig,
as this was removed from mach/config.h in a2ac2b96 ("Convert
CONFIG_SKIP_LOWLEVEL_INIT et al to Kconfig").
Signed-off-by: Stefan Roese <sr@denx.de>
Fixes: a2ac2b96 ("Convert CONFIG_SKIP_LOWLEVEL_INIT et al to Kconfig")
Cc: Tom Rini <trini@konsulko.com>
Cc: Marek Behún <kabel@kernel.org>
Cc: Pali Rohár <pali@kernel.org>
Tested-by: Pali Rohár <pali@kernel.org>
These are part of SOC_CONTROL_REG1 register, not PEX_CAPABILITIES_REG.
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>
Remove unused PCIe functions from SerDes code. They are unused and are
duplicated either from generic PCIe code or from pci_mvebu.c.
Remove also unused PCIe macros from SerDes code. They are just obfuscated
variants of standards macros in include/pci.h or in pci_mvebu.c.
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>
This code is trying to parse PCIe config space of PCIe card connected on
the other end of link and then is trying to force 5.0 GT/s speed via Target
Link Speed bits in PCIe Root Port Link Control 2 Register on the local part
of link if it sees that card supports 5.0 GT/s via Max Link Speed bits in
Link Capabilities Register.
The code is incorrect for more reasons:
- Accessing config space of an endpoint card cannot be done immediately.
If the PCIe link is not up, reading vendor/device ID registers will
return all ones.
- Parsing is incomplete, so it can cause issues even for working cards.
Moreover there is no need to force speed to 5.0 GT/s via Target Link Speed
bits on PCIe Root Port Link Control 2 Register. Hardware changes speed from
2.5 GT/s to 5.0 GT/s autonomously when it is supported.
Most importantly, this code does not change link speed at all, since
because after updating Target Link Speed bits on PCIe Root Port Link
Control 2 Register, it is required to retrain the link, and the code for
that is completely missing.
The code was probably needed for making buggy endpoint cards work. Such a
workaround, though, should be implemented via PCIe subsystem (via quirks,
for example), as buggy cards could also affect other PCIe controllers.
Note that this code is fully unrelated to a38x SerDes code and really
should not have been included in SerDes initialization. Usage of magic
constants without names and comments made this SerDes code hard to read and
understand.
Remove this PCIe application code from low level SerDes code. As this code
is configuring only 5.0 GT/s part, in the worst case, it could leave buggy
cards at the initial speed of 2.5 GT/s (if somehow before this change they
could have been "upgraded" to 5.0 GT/s speed even with missing link
retraining). Compliant cards which just need longer initialization should
work better after this change.
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>
PCI device ID is part of the PCIe controller SoC / revision. For Root
Complex mode (which is the default and the only mode supported currently
by U-Boot and Linux kernel), it is PCI device ID of PCIe Root Port device.
If there is some issue with this device ID, it should be set / updated by
PCIe controller driver (pci_mvebu.c), as this register resides in address
space of the controller. It shouldn't be done in SerDes initialization
code.
In the worst case (a specific board for example) it could be done via
U-Boot's weak function board_pex_config().
But it should not be overwritten globally for all A38x devices.
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>
Enabling Common Clock Configuration bit in PCIe Root Port Link Control
Register should not be done unconditionally. It is enabled by operating
system as part of ASPM. Also after enabling Common Clock Configuration it
is required to do more work, like retraining link. Some cards may be broken
due to this incomplete Common Clock Configuration and some cards are broken
and do not support ASPM at all.
Remove this incomplete code for Common Clock Configuration. It really
should not be done in SerDes code as it is not related to SerDes, but to
PCIe subsystem.
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>
Device/Port Type bits of PCIe Root Port PCI Express Capabilities Register
are read-only SAR registers and are initialized according to current mode
configured by PCIe controller. Changing PCIe controller mode (from Root
Complex mode to Endpoint mode or the other way) is possible via PCI
Express Control Register (offset 0x41A00), bit 1 (ConfRoot Complex). This
has to be done in PCIe controller driver (in our case pci_mvebu.c). Note
that default mode is Root Complex.
Maximum Link Speed bits of PCIe Root Port Link Capabilities Register are
platform specific and overwriting them does not make sense. They are set by
PCIe controller according to current SerDes configuration. For A38x it is
5.0 GT/s if SerDes supports appropriate speed.
Maximum Link Width bits of PCIe Root Port Link Capabilities Register are
read-only SAR registers, but unfortunately if this is not set correctly
here, then access PCI config space of the endpoint card behind this Root
Port does not work.
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 comments to understand what this magic code is doing.
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>
SoC Control 1 Register (offset 0x18204) is already defined by macro
SOC_CONTROL_REG1.
Use macro SOC_CONTROL_REG1 instead of macro SOC_CTRL_REG in ctrl_pex.c
code and remove the other definition.
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>
Replace magic register offsets by macros to make code more readable.
Add comments about what this code is doing.
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>
Rename these options so that CONFIG_IS_ENABLED can be used with them.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
[trini: Fixup some incorrect renames]
Signed-off-by: Tom Rini <trini@konsulko.com>
Move the function get_boot_device() from spl.c to cpu.c.
Make it visible, so that it may be used from other files.
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>
File mach/soc.h is included also in 64-bit mvebu processors, so define
Armada XP related macros only when compiling for Armada XP.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
default n/no doesn't need to be specified. It is default option anyway.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
[trini: Rework FSP_USE_UPD portion]
Signed-off-by: Tom Rini <trini@konsulko.com>
This converts the following to Kconfig:
CONFIG_SKIP_LOWLEVEL_INIT
CONFIG_SKIP_LOWLEVEL_INIT_ONLY
In order to do this, we need to introduce SPL and TPL variants of these
options so that we can clearly disable these options only in SPL in some
cases, and both instances in other cases.
Signed-off-by: Tom Rini <trini@konsulko.com>
Move CONFIG_DDR_32BIT/64BIT to Kconfig as a choice for Armada XP
platforms. Make 64bit the default as this mirrors the current code.
Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
If ddr3_init() fails then DDR was not initialized and we cannot load and
execute U-Boot. We cannot continue, we cannot do anything in this case, so
hang.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
This mvebu axp platform always uses fixed 250 MHz TCLK. So specify this
CONFIG_SYS_TCLK option in msys section of global file soc.h file instead of
manual configuration in every board file.
Now every #if-#else case of soc.h file defines CONFIG_SYS_TCLK, so remove
useless default CONFIG_SYS_TCLK value from the end of soc.h file.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
This mvebu msys platform always uses fixed 200 MHz TCLK. So specify this
CONFIG_SYS_TCLK option in msys section of global file soc.h file instead of
manual configuration in every board file.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Bit 20 in SAR register specifies if TCLK is running at 200 MHz or 166 MHz.
Use this information instead of manual configuration in every board file.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Bit 15 in SAR register specifies if TCLK is running at 200 MHz or 250 MHz.
Use this information instead of manual configuration in every board file.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
We don't need this check anymore since when PCI is enabled, driver model
is always used.
Use CONFIG_PCI instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Correct macro usage)
Signed-off-by: Tom Rini <trini@konsulko.com>
Now that proper load and execution addresses are set in v1 kwbimage we
can use it for loading and booting U-Boot proper.
Use the new spl_parse_board_header() function to implement parsing the
kwbimage v1 header. Use information from this header to locate offset and
size of the U-Boot proper binary, instead of using the legacy U-Boot
header which is prepended to the U-Boot proper binary stored at fixed
offset. This has the advantage that we do not need to relay on legacy
U-Boot header anymore and therefore U-Boot proper binary can be stored at
any offset, as is the case when loading & booting U-Boot proper by
BootROM. The CONFIG_SYS_U_BOOT_OFFS option is therefore not used by SPL
code anymore.
Also allow to compile U-Boot SPL without CONFIG_SPL_SPI_FLASH_SUPPORT,
CONFIG_SPL_MMC_SUPPORT or CONFIG_SPL_SATA_SUPPORT set. In this case
BootROM is used for loading and executing U-Boot proper. This reduces the
size of U-Boot's SPL image. By default these config options are enabled
and so BootROM loading is not used. In some cases BootROM reads from SPI
NOR at lower speed than U-Boot SPL. So people can decide whether they
want to have smaller SPL binary at the cost of slower boot.
Therefore dependency on CONFIG_SPL_DM_SPI, CONFIG_SPL_SPI_FLASH_SUPPORT,
CONFIG_SPL_SPI_LOAD, CONFIG_SPL_SPI_SUPPORT, CONFIG_SPL_DM_GPIO,
CONFIG_SPL_DM_MMC, CONFIG_SPL_GPIO_SUPPORT, CONFIG_SPL_LIBDISK_SUPPORT,
CONFIG_SPL_MMC_SUPPORT, CONFIG_SPL_SATA_SUPPORT and
CONFIG_SPL_LIBDISK_SUPPORT is changed from strict to related "imply"
(which can be selectivelly turned off and causes booting via BootROM).
Options CONFIG_SYS_SPI_U_BOOT_OFFS,
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR and
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET have to to be set to
zero as they define the location where kwbimage header starts. It is the
location where BootROM expects start of the kwbimage from which it reads,
parses and executes SPL part. The same applies to option
CONFIG_SPL_SATA_RAW_U_BOOT_SECTOR, which has to be set to one.
Update all config files to set correct values of these options and set
CONFIG_SYS_U_BOOT_OFFS to the correct value - the offset where U-Boot
proper starts.
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 code uses hack in board_init_f() which calls return_to_bootrom()
to skip U-Boot SPL code and return back to BootROM to load U-Boot via
UART or from NAND.
This change migrates that hack from the board_init_f() function and
changes it to return BOOT_DEVICE_BOOTROM instead of returning to BootROM
directly, so that U-Boot's SPL framework is used for returning to
BootROM.
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>
Reviewed-by: Chris Packham <judge.packham@gmail.com>
Tested-by: Chris Packham <judge.packham@gmail.com>
U-Boot's SPL framework already has an API for loading U-Boot via
BootROM.
Implement the function board_return_to_bootrom() for mvebu SPL code.
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>
Reviewed-by: Chris Packham <judge.packham@gmail.com>
Tested-by: Chris Packham <judge.packham@gmail.com>
This function does not return, so add the appropriate compiler flag.
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>
Reviewed-by: Chris Packham <judge.packham@gmail.com>
Tested-by: Chris Packham <judge.packham@gmail.com>
Register r0 should be set to return value 0x0 - NO_ERR.
Set r0 with return value after all registers are restored from the
stack, so that the return value is always correct.
Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: 944c7a3176 ("arm: mvebu: Add option to use UART xmodem protocol via kwboot")
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Chris Packham <judge.packham@gmail.com>
Tested-by: Chris Packham <judge.packham@gmail.com>
If fixup offset is zero then there is nothing to fix. All calculation in
this case just increase addresses by value zero which results in identity.
So in this case skip whole fixup re-calculation as it is not needed.
This is just an optimization for special case when fix_offset is zero which
skips code path which does only identity operations (meaning nothing). No
functional changes.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Konstantin Porotchkin <kostap@marvell.com>
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>
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>
Some of the setups including cn9130 opens mmio window starting from
0xc0000000, reflect it in the u-boot code.
Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com>
Signed-off-by: Kostya Porotchkin <kostap@marvell.com>
Signed-off-by: Stefan Roese <sr@denx.de>
There is region left by ATF, which needs to remain in memory to provide RT
services. To prevent overwriting it by u-boot, do not provide any mapping
for this memory region, so any attempt to access it will trigger
synchronous exception.
Update sr 2021-04-12:
Don't update armada3700/cpu.c mmu table, as this has specific changes
included in mainline.
Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com>
Signed-off-by: Stefan Roese <sr@denx.de>
This patch adds the base support for the Marvell Octeon TX2 CN9130 CRB.
Not all interfaces are supported fully yet.
Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Config option ARMADA_39X is never set so remove all dead code hidden under
ifdef CONFIG_ARMADA_39X blocks.
Also remove useless checks for CONFIG_ARMADA_38X define as this macro is
always defined for a38x code path.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
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>
