With CONFIG_SYS_GENERIC_BOARD the board hangs after issuing a 'save' command.

Remove CONFIG_SYS_GENERIC_BOARD until this issue can be fixed properly.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>

commit 67a04ab3
fix the build for MX25. The same error
happens for VF610 SOC.

Signed-off-by: Stefano Babic <sbabic@denx.de>

local_irq_save() should be a macro, not a function
because local_irq_save() saves flag to the given argument.

GCC is silent about this issue, but Clang warns:

In file included from lib/asm-offsets.c:15:
In file included from include/common.h:20:
In file included from include/linux/bitops.h:110:
arch/sandbox/include/asm/bitops.h:59:17:
 warning: variable 'flags' is uninitialized when used here
      [-Wuninitialized]
        local_irq_save(flags);
                       ^~~~~

That change causes another warning:

In file included from include/linux/bitops.h:110:0,
                 from include/common.h:20,
                 from lib/asm-offsets.c:15:
arch/sandbox/include/asm/bitops.h: In function ‘test_and_set_bit’:
arch/sandbox/include/asm/bitops.h:56:16: warning: unused variable ‘flags’ [-Wunused-variable]

So, flags should be set to __always_unused.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Jeroen Hofstee <jeroen@myspectrum.nl>
Acked-by: Simon Glass <sjg@chromium.org>
Acked-by: Jeroen Hofstee <jeroen@myspectrum.nl>

Each node in the linked-list that os_dirent_ls() returns has its next
pointer set only when the next node is created. For the last node in the
list, there is no next node, so this never happens, and the next pointer
is never initialized. Explicitly initialize the next pointer so that it
isn't dangling. Without this, "sb ls" might crash.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>

Commit 95fac6ab "sandbox: Use os functions to read host device tree"
removed the ability for get_device_and_partition() to handle the "host"
device type, and redirect accesses to it to the host filesystem. This
broke some unit tests that use this feature. So, revert that change. The
code added back by this patch is slightly different to pacify checkpatch.

However, we're then left with "host" being both:
- A pseudo device that accesses the hosts real filesystem.
- An emulated block device, which accesses "sectors" inside a file stored
  on the host.

In order to resolve this discrepancy, rename the pseudo device from host
to hostfs, and adjust the unit-tests for this change.

The "help sb" output is modified to reflect this rename, and state where
the host and hostfs devices should be used.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Josh Wu <josh.wu@atmel.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>

Until now building the x86 arch boards required 32-bit toolchain. As
many x86_64 toolchains come with 32-bit support (multilib) that's a
good idea to enable build with such toolchains.

The change required was to specify the usage of 32-bit explicitly to
the compiler and the linker (-m32 and -m elf_i386 flags) and locate
the right libgcc path.

Signed-off-by: Vasili Galka <vvv444@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>

- add CONFIG_SYS_GENERIC_BOARD
- remove CONFIG_OF_CONTROL to boot again

Signed-off-by: Heiko Schocher <hs@denx.de>
Acked-by: Kim Phillips <kim.phillips@freescale.com>
Acked-by: Simon Glass <sjg@chromium.org>

move fdtdec_get_int() out of lib/fdtdec.c into lib/fdtdec_common.c
as this function is also used, if CONFIG_OF_CONTROL is not
used. Poped up on the ids8313 board using signed FIT images,
and activating CONFIG_SYS_GENERIC_BOARD. Without this patch
it shows on boot:

No valid FDT found - please append one to U-Boot binary, use u-boot-dtb.bin or define CONFIG_OF_EMBED. For sandbox, use -d <file.dtb>

With this patch, it boots again with CONFIG_SYS_GENERIC_BOARD
enabled.

Signed-off-by: Heiko Schocher <hs@denx.de>
Acked-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@ti.com>

Make both dm enumeration commands support showing whether a driver is active
or not, and use a consistent indicator (an asterisk).

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Marek Vasut <marex@denx.de>

cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
Acked-by: Simon Glass <sjg@chromium.org>

The lifecycle of a device is an important part of driver model. Add to the
existing documentation and clarify it.

Reported-by: Jon Loeliger <jdl@jdl.com>

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

There is a spelling mistake and two functions are missing comments
altogether. Also the flags declaration is correct, but doesn't follow
style. Finally, the uclass_get_device() function has some errors in
its documentation.

Fix these problems.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Marek Vasut <marex@denx.de>

Enable driver model for Tegra boards.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Stephen Warren <swarren@nvidia.com>

These files are taken from Linux 3.14.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Stephen Warren <swarren@nvidia.com>

The values here are int, but the map_to_sysmem() call can return a long.
Add a cast to deal with this.

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

The GPIO tests require the sandbox GPIO driver, so cannot be run on other
platforms. Similarly for the 'dm test' command.

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

In a very few cases we need to adjust the driver model root device, such as
when setting it up at initialisation. Add a macro to make this easier.

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

These files don't compile in some architectures. Fix it by adding the
missing headers.

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

We want 'N0' and 'n0' to mean the same thing, so ensure that case is not
considered when naming GPIO banks.

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

Add a note to encourage people to convert drivers to use driver model.

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

It is best to avoid having any occurence of 'struct device' in driver
model, so rename to achieve this.

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

Linux supports this, and if we are to have compatible device tree files,
U-Boot should also.

Avoid giving the device tree files access to U-Boot's include/ directory.
Only include/dt-bindings is accessible.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>

Support the iotrace feature for sandbox, and enable it, using some dummy
I/O access methods.

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

Support the iotrace feature for ARM, when enabled.

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

When debugging drivers it is useful to see what I/O accesses were done
and in what order.

Even if the individual accesses are of little interest it can be useful to
verify that the access pattern is consistent each time an operation is
performed. In this case a checksum can be used to characterise the operation
of a driver. The checksum can be compared across different runs of the
operation to verify that the driver is working properly.

In particular, when performing major refactoring of the driver, where the
access pattern should not change, the checksum provides assurance that the
refactoring work has not broken the driver.

Add an I/O tracing feature and associated commands to provide this facility.
It works by sneaking into the io.h heder for an architecture and redirecting
I/O accesses through its tracing mechanism.

For now no commands are provided to examine the trace buffer. The format is
fairly simple, so 'md' is a reasonable substitute.

Note: The checksum feature is only useful for I/O regions where the contents
do not change outside of software control. Where this is not suitable you can
fall back to manually comparing the addresses. It might be useful to enhance
tracing to only checksum the accesses and not the data read/written.

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

Import the following trivial commits from Linux v3.16-rc1:

 bb66fc6 kbuild: trivial - use tabs for code indent where possible
 7eb6e34 kbuild: trivial - remove trailing empty lines
 3fbb43d kbuild: trivial - fix comment block indent
 38385f8 kbuild: trivial - remove trailing spaces

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>

The u-boot Overo board actually supports both Overo (OMAP35xx)
and Overo Storm (AM/DM37xx) COMs with a range of different expansion
boards.  This provides a mechanism to select the an appropriate device
tree file based on the processor version and, if available, the
expansion board ID written on the expansion board EEPROM. To match the
3.15+ kernels, fdtfile names have this format:
 "omap3-overo[-storm]-<expansion board name>.dtb"

By default, we use "omap3-overo-storm-tobi.dtb".

Signed-off-by: Ash Charles <ashcharles@gmail.com>

Conflicts:
	include/configs/omap3_overo.h

Fix a trivial copy-paste bug.

Signed-off-by: Axel Lin <axel.lin@ingics.com>

gpmc timeout is disabled and the reset counter
is set to 0. However, if later a driver activates
the timeout setting the reset to a valid value,
the old reset value with zero is still valid
for the first access. In fact, the timeout block
loads the reset counter after a successful access.

Found on a am335x board with a FPGA connected
to the GPMC bus together with the NAND.
When the FPGA driver in kernel activates
the timeout, the system hangs at the first access
by the NAND driver.

Signed-off-by: Stefano Babic <sbabic@denx.de>

Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>