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>
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>
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>
Hardware testing of a board using the Armada 385 has shown that an
impedance threshold setting of 0x7 performs better in an eye-diagram
test than with Marvell's recommended value 0x6.
As other boards may still perform better with Marvell's reccomended value,
a configuration option is added with a default value of 0x6.
Signed-off-by: Joshua Scott <joshua.scott@alliedtelesis.co.nz>
Reviewed-by: Stefan Roese <sr@denx.de>
This converts the following to Kconfig:
CONFIG_ENV_OVERWRITE
Signed-off-by: Adam Ford <aford173@gmail.com>
[trini: Rerun migration, remove some comments]
Signed-off-by: Tom Rini <trini@konsulko.com>
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>
When running USB compliance tests on our Armada-385 hardware platforms
we have seen some eye mask violations. Marvell's internal documentation
says: Based on silicon test results, it is recommended to change the
impedance calibration threshold setting to 0x6 prior to calibration.
Port changes from Marvell's u-boot fork[1] to address this.
[1] - https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/a6221551
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Convert the CRS305-1G-4S board to CRS3xx-98DX3236 to enable easier
implementation of new CRS3xx series boards, based on Marvell Prestera
98DX3236.
Signed-off-by: Luka Kovacic <luka.kovacic@sartura.hr>
Reviewed-by: Stefan Roese <sr@denx.de>
Cc: Luka Perkov <luka.perkov@sartura.hr>
Cc: Jakov Petrina <jakov.petrina@sartura.hr>
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>
Have this symbol follow the pattern of all other such symbols.
This patch also removes a TODO from the code.
Reviewed-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Update mvebu SPL boot selection mechanism for the move to driver model
usage by ensuring that the required driver support for SPI and MMC
booting is available in SPL when the respective boot method is
selected.
Previously, all mvebu boards selected a boot method (implicitly
MVEBU_SPL_BOOT_DEVICE_SPI for many) even if SPL booting wasn't used.
This changes mvebu boot method selection to depend on SPL usage which
resolves the issue with aarch64 boards which don't use SPL getting an
implicit boot device selection resulting in unmet dependencies. The
32-bit arm boards do use SPL, but I'm led to conclude that most aren't
intentionally using the MVEBU_SPL_BOOT_DEVICE selection since none have
SPL_DM_SPI enabled in their defconfig even though they still implicitly
select the SPI boot method.
This also results in the new addition of SPL_GPIO_SUPPORT to helios4.
The mainline dts for helios4 includes the cd-gpios entry for sdhci with
identical addresses as the clearfog dts. I don't have a helios4 board
to confirm, but based on the current source conclude that the board
itself is either wired to pull the signal low for eMMC, or the default
MMC boot isn't fully functional in mainline. In either case, as far as
I can tell, including the GPIO support will at least cause no
regression.
Tested on SolidRun ClearFog devices.
Signed-off-by: Joel Johnson <mrjoel@lixil.net>
Reviewed-by: Stefan Roese <sr@denx.de>
In case when ARM Trusted Firmware changes the default address of PCIe
regions (which can be done for devices with 4 GB RAM to maximize the
amount of RAM the device can use) we add code that looks at how ATF
changed the PCIe windows in the CPU Address Decoder and changes given
device-tree blob accordingly.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
Currently on Armada-37xx the mem_map structure is statically defined to
map first 2 GB of memory as RAM region, and system registers and PCIe
region device region.
This is insufficient for when there is more RAM or when for example the
PCIe windows is mapped to another address by the CPU Address Decoder.
In the case when the board has 4 GB RAM, on some boards the ARM Trusted
Firmware can move the PCIe window to another address, in order to
maximize possible usable RAM.
Also the dram_init and dram_init_banksize looks for information in
device-tree, and therefore different device trees are needed for boards
with different RAM sizes.
Therefore we add code that looks at how the ARM Trusted Firmware has
configured the CPU Address Decoder windows, and then we update the
mem_map structure and compute gd->ram_size and gd->bd->bi_dram bank
base addresses and sizes accordingly.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>
