This commit extends the sandbox to implement a dummy
extension_board_scan() function and enables the extension command in
the sandbox configuration. It then adds a test that checks the proper
functionality of the extension command by applying two Device Tree
overlays to the sandbox Device Tree.

Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
[trini: Limit to running on sandbox]
Signed-off-by: Tom Rini <trini@konsulko.com>

Move sandbox_spl over to use OF_PLATDATA_INST. Create a new board to
test the case when this is not enabled, since we will be keeping that
code around for several months and want to avoid regressions.

Skip the dm_test_of_plat_dev() test since driver info is not available
for OF_PLATDATA_INST.

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

Add the FAT environment driver to the priority list.

When testing the UEFI sub-system the EFI system partition is formatted with
FAT so it is reasonable to store the environment there.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.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>

The current macro is a misnomer since it does not declare a device
directly. Instead, it declares driver_info record which U-Boot uses at
runtime to create a device.

The distinction seems somewhat minor most of the time, but is becomes
quite confusing when we actually want to declare a device, with
of-platdata. We are left trying to distinguish between a device which
isn't actually device, and a device that is (perhaps an 'instance'?)

It seems better to rename this macro to describe what it actually is. The
macros is not widely used, since boards should use devicetree to declare
devices.

Rename it to U_BOOT_DRVINFO(), which indicates clearly that this is
declaring a new driver_info record, not a device.

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

Before executing code that we have loaded from a file we need to flush the
data cache and invalidate the instruction flash.

Implement functions flush_cache() and invalidate_icache_all().

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

Since sandbox's SPL is build with of-platadata, we should not use
U_BOOT_DEVICE() declarations as well. Drop them.

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

Activate ENV in EXT4 support in sandbox.

The sandbox behavior don't change; the default environment with
the nowhere backend (CONFIG_ENV_IS_NOWHERE)is still used:
the weak function env_get_location() return ENVL_NOWHERE for priority 0.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.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 using OF_PLATDATA, the bind process between devices and drivers
is performed trying to match compatible string with driver names.
However driver names are not strictly defined, and also there are different
names used when declaring a driver with U_BOOT_DRIVER, the name of the
symbol used in the linker list and the used in the struct driver_info.

In order to make things a bit more clear, rename the drivers names. This
will also help for further OF_PLATDATA improvements, such as checking
for valid driver names.

Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a fix for sandbox of-platdata to avoid using an invalid ANSI colour:
Signed-off-by: Simon Glass <sjg@chromium.org>