soc_xilinx_zynqmp driver allows identification of family & revision
of zynqmp SoC. This driver is selected by CONFIG_SOC_XILINX_ZYNQMP.
Add this config to xilinx_zynqmp_virt_defconfig file.
Probe this driver using platdata U_BOOT_DEVICE structure which is
specified in mach-zynqmp/cpu.c.
Signed-off-by: NT Karthik Reddy <t.karthik.reddy@xilinx.com>
Reviewed-by: NAshok Reddy Soma <ashok.reddy.soma@xilinx.com>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

Enable cfi flash on zc770-xm012 configuration.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

Single configuration is working fine and no issue to enable it.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

Replace 'io-standard' property with 'power-source' property in all
zynq dts files to be in sync with Zynq Pinctrl driver.
Signed-off-by: NSai Krishna Potthuri <lakshmi.sai.krishna.potthuri@xilinx.com>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

Add missing "jedec, spi-nor" compatible string for QSPI flash node.
Spi-nor framework uses this compatibility string to probe &
initialize flash. With missing compatibility string we are observing
below error:

Zynq> sf probe 0 0 0
 jedec_spi_nor spi_flash@0:0: unrecognized JEDEC id bytes:
00, 00, 00  Failed to initialize SPI flash at 0:0 (error -2)
Signed-off-by: NRaju Kumar Pothuraju <raju.kumar-pothuraju@xilinx.com>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

Trivial style patch.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

Fix header alignment.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

By dt-binding specs led nodes should have -led suffix that's why add it.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

It is a pain to have to specify the value 10 in each call. Add a new
dectoul() function and update the code to use it.
Signed-off-by: NSimon Glass <sjg@chromium.org>

It is a pain to have to specify the value 16 in each call. Add a new
hextoul() function and update the code to use it.

Add a proper comment to simple_strtoul() while we are here.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Initialize 'igd' and 'sdvo' to NULL so that we just need to test
them against NULL later, to be compatible with that case that IGD
and SDVO devices were already in disabled state.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

For FSP1, there is no such INIT_PHASE_END_FIRMWARE.

Move board_final_cleanup() to fsp2 directory.

Fixes: 7c73cea4 ("x86: Notify the FSP of the 'end firmware' event")
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax
Tested-by: NSimon Glass <sjg@chromium.org>

There are several outstanding issues as to why this does not apply
to FSP1:

* For FSP1, the system memory and reserved memory used by FSP are
  already programmed in the MTRR by FSP.
* The 'mtrr_top' mistakenly includes TSEG memory range that has the
  same RES_MEM_RESERVED resource type. Its address is programmed
  and reported by FSP to be near the top of 4 GiB space, which is
  not what we want for SDRAM.
* The call to mtrr_add_request() is not guaranteed to have its size
  to be exactly the power of 2. This causes reserved bits of the
  IA32_MTRR_PHYSMASK register to be written which generates #GP.

For FSP2, it seems this is necessary as without this, U-Boot boot
process on Chromebook Coral goes very slowly.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax
Tested-by: NSimon Glass <sjg@chromium.org>

The size parameter of mtrr_add_request() and mtrr_set_next_var()
shall be power of 2, otherwise the logic creates a mask that does
not meet the requirement of IA32_MTRR_PHYSMASK register.

Programming such a mask value to IA32_MTRR_PHYSMASK generates #GP.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax
Tested-by: NSimon Glass <sjg@chromium.org>

At present mtrr_commit() programs the MTRR MSRs starting from
index 0, which may overwrite MSRs that were already programmed
by previous boot stage or FSP.

Switch to call mtrr_set_next_var() instead.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax
Tested-by: NSimon Glass <sjg@chromium.org>

Current mtrr_commit() logic assumes that MTRR MSRs are programmed
consecutively from index 0 to its maximum number, and whenever it
detects an unused one, it clears all other MTRRs starting from that
one. However this may not always be the case.

In fact, the clear is not much helpful because these MTRRs come out
of reset as disabled already. Drop the clear codes.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax
Tested-by: NSimon Glass <sjg@chromium.org>

If for some reason, TSC timer frequency cannot be determined from
hardware, nor is it specified in the device tree, U-Boot will panic
resulting in endless reset during boot.

Let's define a default TSC timer frequency using the Kconfig value
CONFIG_X86_TSC_TIMER_FREQ (note: #include must be used instead of
/include/ otherwise the macro is not pre-processed).
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Currently there are two places to specify the x86 TSC timer frequency
with one in Kconfig used for early timer and the other one in device
tree used when the frequency cannot be determined from hardware.

This may potentially create an inconsistent config where the 2 values
do not match. Let's use the one specified in Kconfig in the device
tree as well.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

These 2 options are no longer needed as now binman is used to build
u-boot.rom.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

IRQ polarity in CSRT has the same definition as by ACPI specification
chapter 19.6.64 "Interrupt (Interrupt Resource Descriptor Macro)", i.e.
ActiveHigh is 0, and ActiveLow is 1. On Intel Tangier the DMA controller
IRQ polarity is ActiveHigh.

Note, in DSDT (see southcluster.asl) it's described correctly.

Fixes: 5e99fde3 ("x86: tangier: Populate CSRT for shared DMA controller")
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Except ICH7 SPI, all SPI flashes connected to ICH9 / Fast SPI should
have "m25p,fast-read" property present in their DT nodes.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

At present if we see 'ranges' property (with no value) we assume it is a
boolean, as per the devicetree spec.

But another node may define 'ranges' with a value, forcing us to widen it
to an int array. At present this is not supported and causes an error.

Fix this and add some test cases.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reported-by: NTom Rini <trini@konsulko.com>

The autoboot tests are a recent addition to U-Boot, providing much-needed
coverage in this area.

A side effect of the keyed autoboot test is that this feature is enabled
in sandbox always. This changes the autoboot prompt and confuses the
pytests. Some tests become slower, for example the vboot tests take about
27s now instead of 3s.

We don't actually need this feature enabled to be able to run the tests.
Add a switch to allow sandbox to turn it on and off as needed. Use this
in the one test that needs it.

Add a command-line flag in case this is desired in normal use.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Fixes: 25c8b9f2 ("test: add first autoboot unit tests")
Reviewed-by: NSteffen Jaeckel <jaeckel-floss@eyet-services.de>

There are more Allwinner SoCs that do not have a SCP now.

When there's no SCP_ADDR macro defined, we can assume there's no SCP
available.

Drop the scp part of FIT description when SCP_ADDR does not exist.
Signed-off-by: NIcenowy Zheng <icenowy@sipeed.com>
Reviewed-by: NAndre Przywara <andre.przywara@arm.com>
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>

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: NSamuel Holland <samuel@sholland.org>
Reviewed-by: NAndre Przywara <andre.przywara@arm.com>
[Andre: amend commit message, fix R40 and V3s build]
Signed-off-by: NAndre Przywara <andre.przywara@arm.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: NPali Rohár <pali@kernel.org>
Reviewed-by: NMarek Behún <marek.behun@nic.cz>
Reviewed-by: NStefan 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: NPali Rohár <pali@kernel.org>
Reviewed-by: NMarek Behún <marek.behun@nic.cz>
Reviewed-by: NStefan Roese <sr@denx.de>
Reviewed-by: NChris Packham <judge.packham@gmail.com>
Tested-by: NChris 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: NPali Rohár <pali@kernel.org>
Reviewed-by: NMarek Behún <marek.behun@nic.cz>
Reviewed-by: NStefan Roese <sr@denx.de>
Reviewed-by: NChris Packham <judge.packham@gmail.com>
Tested-by: NChris Packham <judge.packham@gmail.com>

This function does not return, so add the appropriate compiler flag.
Signed-off-by: NPali Rohár <pali@kernel.org>
Reviewed-by: NMarek Behún <marek.behun@nic.cz>
Reviewed-by: NStefan Roese <sr@denx.de>
Reviewed-by: NChris Packham <judge.packham@gmail.com>
Tested-by: NChris 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: NPali Rohár <pali@kernel.org>
Fixes: 944c7a31 ("arm: mvebu: Add option to use UART xmodem protocol via kwboot")
Reviewed-by: NMarek Behún <marek.behun@nic.cz>
Reviewed-by: NStefan Roese <sr@denx.de>
Reviewed-by: NChris Packham <judge.packham@gmail.com>
Tested-by: NChris Packham <judge.packham@gmail.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: NPatrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: NPatrick Delaunay <patrick.delaunay@foss.st.com>
Cc: mark.kettenis@xs4all.nl
Signed-off-by: NPatrick Delaunay <patrick.delaunay@foss.st.com>

Align reset_cpu function with the next prototypes in
sysreset.h or in cpu_func.h to solve compilation issue:

  void reset_cpu(void);

This patch solves the prototype conflict when cpu_func.h is
included.
Signed-off-by: NPatrick Delaunay <patrick.delaunay@foss.st.com>

Rename these options so that CONFIG_IS_ENABLED can be used with them.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NHeiko Schocher <hs@denx.de>

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: NSimon Glass <sjg@chromium.org>
Reviewed-by: NHeiko Schocher <hs@denx.de>

Rename these options so that CONFIG_IS_ENABLED can be used with them.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Rename these options so that CONFIG_IS_ENABLED can be used with them.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Rename this option so that CONFIG_IS_ENABLED can be used with it.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Rename this option so that CONFIG_IS_ENABLED can be used with it.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Rename this option so that CONFIG_IS_ENABLED can be used with it.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Rename this option so that CONFIG_IS_ENABLED can be used with it.
Signed-off-by: NSimon Glass <sjg@chromium.org>