This converts the following to Kconfig:
   CONFIG_SYS_IMMR

We do this by consolidating the SYS_IMMR options we have and providing
defaults.

We also, in the few places where M68K was also sharing code with these
platforms, define it within the file to CONFIG_SYS_MBAR to match usage.
This should be cleaned up longer term.

Signed-off-by: Tom Rini <trini@konsulko.com>

This converts the following to Kconfig:
   CONFIG_SYS_MEMTEST_START
   CONFIG_SYS_MEMTEST_END

This is removing unused defines and correcting the default value to be
0x0 as we are a hex symbol.

Signed-off-by: Tom Rini <trini@konsulko.com>

This converts the following to Kconfig:
   CONFIG_WATCHDOG_TIMEOUT_MSECS

Signed-off-by: Tom Rini <trini@konsulko.com>

Because of how these symbols work, and the remaining board config.h file
uses, we need to do these at the same time.  In some cases we just get
to move rather directly to the defconfigs.  A few cases require manual
intervention.

For the case of the eb_cpu5282 we need to select HW_WATCHDOG for the
target, given how it's implemented.

For the cases of m53menlo, dh_imx6, display5, and display5_factory we
disable SPL watchdog support as the particular combination of options
they want would require either more symbols or enabling SPL_DM.

Signed-off-by: Tom Rini <trini@konsulko.com>

The symbol CONFIG_FSL_PCI_INIT is no longer enabled anywhere, removed
now unused code.

Signed-off-by: Tom Rini <trini@konsulko.com>

This converts the following to Kconfig:
   CONFIG_SYS_NAND_DRIVER_ECC_LAYOUT

In order to do this conversion, expose this option to the user and
use "save" not "safe" in the text.

Signed-off-by: Tom Rini <trini@konsulko.com>

This converts the following to Kconfig:
   CONFIG_SUPPORT_EMMC_RPMB

This fixes a few platforms where the option was not taking effect as
intended.

Signed-off-by: Tom Rini <trini@konsulko.com>

This option is used as part of configuring the default environment for a
number of platforms.  However, it is always set to 1 and the only time
it is part of Kconfig, it is used in a hard-coded manner.  Hard-code the
value in the environment instead.

Signed-off-by: Tom Rini <trini@konsulko.com>

This converts the following to Kconfig:
   CONFIG_CONS_INDEX
   CONFIG_DEBUG_UART_CLOCK
   CONFIG_FSL_TZPC_BP147
   CONFIG_GENERIC_ATMEL_MCI
   CONFIG_IDENT_STRING
   CONFIG_LIBATA
   CONFIG_LNX_KRNL_IMG_TEXT_OFFSET_BASE
   CONFIG_LPC32XX_GPIO
   CONFIG_MP
   CONFIG_MPC8XXX_GPIO
   CONFIG_MTD_PARTITIONS
   CONFIG_MVGBE
   CONFIG_MXC_GPIO
   CONFIG_NR_DRAM_BANKS
   CONFIG_OF_BOARD_SETUP
   CONFIG_OF_STDOUT_VIA_ALIAS
   CONFIG_OF_SYSTEM_SETUP
   CONFIG_PREBOOT
   CONFIG_ROCKCHIP_SERIAL
   CONFIG_RTC_ENABLE_32KHZ_OUTPUT
   CONFIG_RTC_MV
   CONFIG_SCSI_AHCI
   CONFIG_SF_DEFAULT_BUS
   CONFIG_SF_DEFAULT_CS
   CONFIG_SF_DEFAULT_SPEED
   CONFIG_SOFT_SPI
   CONFIG_SPI_FLASH_EON
   CONFIG_SPI_FLASH_MACRONIX
   CONFIG_SPI_FLASH_MTD
   CONFIG_SPI_FLASH_SPANSION
   CONFIG_SPI_FLASH_SST
   CONFIG_SPI_FLASH_STMICRO
   CONFIG_SUPPORT_RAW_INITRD
   CONFIG_SYS_ARCH_TIMER
   CONFIG_SYS_BOARD
   CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE
   CONFIG_SYS_DCACHE_OFF
   CONFIG_SYS_FDT_SAVE_ADDRESS
   CONFIG_SYS_FLASH_CFI
   CONFIG_SYS_FSL_ERRATUM_ESDHC135
   CONFIG_SYS_HAS_SERDES
   CONFIG_SYS_L2CACHE_OFF
   CONFIG_SYS_LITTLE_ENDIAN
   CONFIG_SYS_LOAD_ADDR
   CONFIG_SYS_MMCSD_FS_BOOT_PARTITION
   CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION
   CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
   CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
   CONFIG_SYS_NS16550
   CONFIG_SYS_PLLFIN
   CONFIG_SYS_SPI_U_BOOT_OFFS
   CONFIG_TIMER_SYS_TICK_CH
   CONFIG_USB_EHCI_FSL
   CONFIG_U_QE
   CONFIG_VERSION_VARIABLE

Signed-off-by: Tom Rini <trini@konsulko.com>

This converts the following to Kconfig:
   CONFIG_SD_BOOT
   CONFIG_SD_BOOT_QSPI

Signed-off-by: Tom Rini <trini@konsulko.com>

This converts the following to Kconfig:
   CONFIG_FSL_IFC

This is done via select statements to match previous logic.

Signed-off-by: Tom Rini <trini@konsulko.com>

This converts the following to Kconfig:
   CONFIG_ENV_SPI_BUS
   CONFIG_ENV_SPI_CS
   CONFIG_ENV_SPI_MAX_HZ
   CONFIG_ENV_SPI_MODE

As part of this, we use Kconfig to provide the defaults now that were
done in include/spi_flash.h.  We also in some cases change from using
CONFIG_ENV_SPI_FOO to CONFIG_SF_DEFAULT_FOO as those were the values in
use anyhow as ENV was not enabled.

Signed-off-by: Tom Rini <trini@konsulko.com>

This is a "hex" prompt but the default value was given as an int.
Switch the default to hex (0x0) and remove the defconfigs that were
using the default, but as hex before.

Signed-off-by: Tom Rini <trini@konsulko.com>

With the relevant platforms removed, drop this file.

Signed-off-by: Tom Rini <trini@konsulko.com>

Merge v8 of Simon's series to make CONFIG_OF_BOARD a boolean option.
Quoting him:

With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
there are only three ways to obtain a devicetree:

   - OF_SEPARATE - the normal way, where the devicetree is built and
      appended to U-Boot
   - OF_EMBED - for development purposes, the devicetree is embedded in
      the ELF file (also used for EFI)
   - OF_BOARD - the board figures it out on its own

The last one is currently set up so that no devicetree is needed at all
in the U-Boot tree. Most boards do provide one, but some don't. Some
don't even provide instructions on how to boot on the board.

The problems with this approach were covered in another patch[1], since
removed from this series.

In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
can obtain its devicetree at runtime, even it is has a devicetree built
in U-Boot. This is because U-Boot may be a second-stage bootloader and its
caller may have a better idea about the hardware available in the machine.
This is the case with a few QEMU boards, for example.

So it makes no sense to have OF_BOARD as a 'choice'. It should be an
option, available with either OF_SEPARATE or OF_EMBED. This would allow
rpi3, for example, to run with the devicetree provided by the prior
bootloader.

This series makes this change, adding various missing devicetree files
(and placeholders) to make the build work.

To make the 'prior stage' side of things more deterministic, a new
OF_HAS_PRIOR_STAGE is added, which cannot be disabled by updated a board's
defconfig. This should help to prevent mistakes.

It also adds a run-time message showing where the devicetree came from,
as well as warnings if the board's expected flow is not being used. This
comes originally from the 'standard passage' series, which depends on
this series.

It also provides a few qemu clean-ups discovered along the way. The
qemu-riscv64_spl problem is fixed.

Please see [2] for discussion on the v6 series.

I put Heinrich's Tested-by tag[3] for the series onto the three devicetree
patches (ARM and RISC-V) that I think it most affects. It isn't possible
to apply a tag to a whole series at present and in any case there are
changes in v7.

This series is available at u-boot-dm/ofb-working

[1] https://patchwork.ozlabs.org/project/uboot/patch/20211207001209.3467163-2-sjg@chromium.org/
[2] https://lore.kernel.org/u-boot/20211205133207.GW1220664@bill-the-cat/T/#mcd8c0258827fbc1bb3000b7ff9ba0929df1ddcb2
[3] https://lore.kernel.org/u-boot/93913911-4d20-d28f-ee04-739985184c5e@canonical.com/raw

When running, if the devicetree failed to come from the expected source,
show a warning, e.g:

   U-Boot ...

   DRAM:  128 MiB
   Core:  42 devices, 11 uclasses, devicetree: separate
   Warning: Unexpected devicetree source (not from a prior stage)
   Warning: U-Boot may not function properly
   Flash: 64 MiB
   ...

These warnings should only appear if the board config has been changed, or
the prior stage is broken.

Signed-off-by: Simon Glass <sjg@chromium.org>

U-Boot always needs some sort of a device tree in the build. Some boards
never actually use this, at least in production systems, since a prior
firmware stage sets one up and passes it to U-Boot. At present the only
mechanism to do that is with custom function (OF_BOARD), but future work
will include a standard way of doing this ('standard passage').

It can be confusing to see a device tree emitted from the U-Boot build in
this situation. Add an option to drop it.

Signed-off-by: Simon Glass <sjg@chromium.org>

Boards which define OF_HAS_PRIOR_STAGE must define OF_BOARD at present,
since a custom function is the only way to obtain the devicetree at
runtime.

Add a build error when this requirement is not met, to avoid accepting
any patches which break this requirement.

Add an allowlist for boards which use it, currently none. This allowlist
can be updated for local development, if needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: change of_whitelist to of_allowlist]
Signed-off-by: Tom Rini <trini@konsulko.com>

Use this new Kconfig instead of OF_BOARD, so we know for sure which boards
obtain their devicetree from a prior stage. Leave sandbox alone since it
does not. Also don't touch xilinx_versal_virt since it does not have a
specific TARGET Kconfig.

This option implies OF_BOARD for now, but with future work standard
passage may be used instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Add rpi_4_32b and rpi_arm64 to the list of boards converted]
Signed-off-by: Tom Rini <trini@konsulko.com>

When U-Boot is started from another firmware program, not just a prior
phase of U-Boot, special behaviour is typically used. In particular, the
device tree may come from that prior stage.

At present this is sort-of indicated by OF_BOARD, although the
correlation is not 1:1, since that option simply means that the board has
a custom mechanism for obtaining the device tree. For example, sandbox
defines OF_BOARD. Also the board_fdt_blob_setup() function can in fact
make use of the devicetree in U-Boot if it wishes, as used by
dragonboard410c until very recently.

Add an explicit Kconfig for this situation. Update the OF_BOARD option to
more-accurately reflect what it is doing, e.g. for sandbox.

Drop the docs in the README as it is out of date.

Signed-off-by: Simon Glass <sjg@chromium.org>

It can be confusing to figure out where the devicetree came from. It seems
important enough to warrant a message during boot. Add information about
the number of devices and uclasses too since it is helpful to have some
idea what is going on with driver model.

Report the devicetree source in bdinfo too.

This looks something like this, with > marking the new line.

   U-Boot 2021.10-00190 (Oct 30 2021 - 09:01:29 -0600)

   DRAM:  128 MiB
>  Core:  42 devices, 11 uclasses, devicetree: passage
   Flash: 64 MiB

Signed-off-by: Simon Glass <sjg@chromium.org>

Keep track of where the devicetree came from, so we can report this later.

Signed-off-by: Simon Glass <sjg@chromium.org>

Add a function that returns some basic stats about driver model. For now
we only have two.

Signed-off-by: Simon Glass <sjg@chromium.org>

At present this override function is called even when OF_BOARD is not
enabled. This makes it impossible to disable this feature and in fact
makes the OF_BOARD option useless.

Reinstate its intended purpose, so that it is possible to switch between
the appended devicetree and one provided by the board's custom function.

A follower patch adds warnings for this scenario, but for now we don't
have a Kconfig that definitively tells us that OF_BOARD should be used.

Signed-off-by: Simon Glass <sjg@chromium.org>

We only have two choices for obtaining the devicetree. Simplify the code
to make that clear.

Signed-off-by: Simon Glass <sjg@chromium.org>

This function should only be called when OF_CONTROL is enabled. It
fails in fdtdec_prepare_fdt() anyway, since gd->fdt_blob stays as NULL
if OF_CONTROL is not enabled.

Drop this useless check.

Signed-off-by: Simon Glass <sjg@chromium.org>

Change this to use if() instead of #if

Signed-off-by: Simon Glass <sjg@chromium.org>

This serves no purpose. Drop it.

Signed-off-by: Simon Glass <sjg@chromium.org>

Move this to the header file to clean up the C code.

Signed-off-by: Simon Glass <sjg@chromium.org>

Refactor the code to drop the #ifdefs for this feature.

Signed-off-by: Simon Glass <sjg@chromium.org>

This logic is a bit convoluted for one function. Move the mulit-FIT part
into its own function.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

At present one must hack the Makefile to see what is going on with these
files. Also it doesn't quite work correctly.

Fix this by using an environment variable for debugging. Update the docs
also.

Signed-off-by: Simon Glass <sjg@chromium.org>

This was added as a hack to work around not having an in-tree devicetree.
Now that this is fixed it is not needed.

Drop it.

Signed-off-by: Simon Glass <sjg@chromium.org>

This should not be a separate option from OF_SEPARATE. It is a run-time
option to override the devicetree, even if present.

Move the option out of the choice.

Disable BINMAN_FDT for a few boards which don't actually use it.

Signed-off-by: Simon Glass <sjg@chromium.org>

Add an empty version of this file, so that we can at least build this
board when devicetrees are required.

Signed-off-by: Simon Glass <sjg@chromium.org>

This uses QEMU virt which creates its own devicetree.

Add an empty version of this file, so that we can at least build this
board when devicetrees are required.

Signed-off-by: Simon Glass <sjg@chromium.org>

Add an empty devicetree file for these boards. It seems to be possible to
obtain a real one from another bootloader called 'bolt' but I will leave
this to the maintainer.

Signed-off-by: Simon Glass <sjg@chromium.org>

Add an empty file to prevent build errors when building with
CONFIG_OF_SEPARATE enabled.

Signed-off-by: Simon Glass <sjg@chromium.org>

Add an empty file to prevent build errors when building with
CONFIG_OF_SEPARATE enabled.

Unfortunately there are no build instructions in the U-Boot tree to enable
a real file to be created.

Signed-off-by: Simon Glass <sjg@chromium.org>

Add an empty version of this file, so that we can at least build this
board when devicetrees are required.

The real devicetree is created by the Xen project on-the-fly.

Signed-off-by: Simon Glass <sjg@chromium.org>