Some clock sources have 3-bit muxes in bits 31:29. Implement core
support for this mux field.

Signed-off-by: Tom Warren <twarren@nvidia.com>
[swarren, extracted from a larger patch by Tom]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>

Since all code that sets or interprets MASK_BITS_* now uses the enums
to define/compare the values, there is no need for MASK_BITS_* to have
a specific integer value. In fact, having a specific integer value may
encourage people to hard-code those values, or interpret the values in
incorrect ways.

As such, remove the logic that assigns a specific value to the enum
values in order to make it completely clear that it's just an enum, not
something that directly represents some integer value.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>

Not all code that set or interpreted "mux_bits" was using the named
macros, but rather some was simply using hard-coded integer constants.
This makes it hard to determine which pieces of code are affected by
changes to those constants.

Replace the integer constants with the equivalent macro definitions so
that everything is nicely tied together.

Note that I'm not convinced all the code was using the correct integer
constants, and hence I'm not convinced that all the code is now using
the desired macros. However, this change is a purely mechanical
replacement and should have no functional change. Fixing any bugs will
come later, separately.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>

OUT_CLK_SOURCE_ are currently named after the number of bits the mask
they represent includes. However, bit count is not the only possible
variable; bit position may also vary. Rename OUT_CLK_SOURCE_ to
OUT_CLK_SOURCE_31_30_ and OUT_CLK_SOURCE4_ to OUT_CLK_SOURCE_31_28 to
more completely describe exactly what they represent, without having to
go look up the definitions.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>

The only place where the MASK_BITS_* values are used is in
adjust_periph_pll(), which interprets the value 4 (old MASK_BITS_29_28,
new MASK_BITS_31_28) as being associated with mask OUT_CLK_SOURCE4_MASK,
i.e. bits 31:28. Rename the MASK_BITS_ macro to reflect how it's actually
implemented.

Note that no Tegra clock register actually uses all of bits 31:28 as
the mux field. Rather, bits 30:28, 29:28, or 28 are used. However, in
those cases, nothing is stored in the bits above the mux field, so it's
safe to pretend that the mux field extends all the way to the end of the
register. As such, the U-Boot clock driver is currently a bit lazy, and
doesn't distinguish between 31:28, 30:28, 29:28 and 28; it just lumps
them all together and pretends they're all 31:28. This patch doesn't
cause this issue; it was pre-existing. Hopefully, future patches will
clean this up.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>

The enum used to define the set of register bits used to represent a
clock's input mux, MUX_BITS_*, is defined separately for each SoC at
present. Move this definition to a common location to ease fixing up
some issues with the definition, and the code that uses it.

Signed-off-by: Tom Warren <twarren@nvidia.com>
[swarren, extracted from a larger patch by Tom]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>

$usb_need_init prevents "usb start" from being run multiple times for
each boot attempt, i.e. once for USB storage, another for PXE, and
another for DHCP. However, the flag that's used to determine when to run
"usb start" is never cleared, so a subsequent "boot" command will never
probe for a freshly plugged in USB device. Fix this so that new USB
devices will be probed once per boot attempt.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>

The U-Boot "cardhu" build supports only revision 4 of the Cardhu board
and later compatible revisions. Hence, set $board_name in the default
environment to "cardhu-a04" rather than just "cardhu".

The Linux kernel has separate DTs for Cardhu A02 and A04, although the
former isn't really supported any more. Consequently, the kernel DT file
that matches the U-Boot cardhu build is "tegra30-cardhu-a04.dtb" rather
than "tegra30-cardhu.dtb". Set the $fdtfile default environment variable
to reflect this.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>

For Tegra20, the SKU ID actually impacts how U-Boot programs the chip,
and hence we need to explicitly know about each and every SKU ID in order
to operate correctly.

However, for Tegra30/114, this isn't the case. Rather than forcing each
new user with a different SKU to manually add their SKU ID into the code,
simply accept any SKU ID.

If U-Boot ever starts e.g. programming maximal CPU clocks etc., we'll
need to undo this, or make the default case map to conservative defaults,
but for now it's likely the path to least support cost.

Reported-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>

Run "tools/reformat.py -i -d '-' -s 8 <boards.cfg >boards0.cfg && mv boards0.cfg boards.cfg"
in order to keep the entries sorted.

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

This is only required for "PIC" relocation and doesn't apply to modern
"PIE" relocation which does data relocation as well as code.

"init_sequence_r" is just an array that consists of compile-time
adresses of init functions. Since this is basically an array of integers
(pointers to "void" to be more precise) it won't be modified during
relocation - it will be just copied to new location as it is.

As a consequence on execution after relocation "initcall_run_list" will
be jumping to pre-relocation addresses. As long as we don't overwrite
pre-relocation memory area init calls are executed correctly. But still
it is dangerous because after relocation we don't expect initially used
memory to stay untouched.

Cc: Tom Rini <trini@ti.com>
Cc: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Doug Anderson <dianders@chromium.org>
Cc: Thomas Langer <thomas.langer@lantiq.com>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>

Add the USB host boot support for the am43xx evm
Add the macros to boot from a usb drive in uBoot

Signed-off-by: Dan Murphy <dmurphy@ti.com>

Add SPL support to be able to detect a USB Mass Storage device
connected to a USB host.  Once a USB Mass storage device is detected
the SPL will load the u-boot.img from a FAT partition to target address.

Signed-off-by: Dan Murphy <dmurphy@ti.com>

Move the FAT functions to a common location for reuse.

Signed-off-by: Dan Murphy <dmurphy@ti.com>

We do not have to define CONFIG_MPC5xxx in board config headers
(and start.S) because it is defined in arch/powerpc/cpu/mpc5xxx/config.mk.

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

Delete some serial.h files, whole code in which is surrounded by
  #if 0 ... #endif

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Stefan Roese <sr@denx.de>

The function os_free() returns nothing.
Its return type should be "void" rather than "void *".

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

Before this commit, all arch/arm/cpu/${CPU}/config.mk except ARMv8
had the same option:
$(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,))

This commit moves it into arch/arm/config.mk.

If the compiler does not support the option,
it is ignored by $(call cc-option,...).
So this commit gives no harm to ARMv8.

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

Define CONFIG_MPC86xx in arch/powerpc/cpu/mpc86xx/config.mk
because all target boards with mpc86xx cpu define it.

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

Define CONFIG_MPC85xx in arch/powerpc/cpu/mpc85xx/config.mk
because all target boards with mpc85xx cpu define it.

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

We do not have to define CONFIG_MPC824X in board config headers
because it is defined in arch/powerpc/cpu/mpc824x/config.mk.

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

We do not have to define CONFIG_5xx in a source file
because it is defined in arch/powerpc/cpu/mpc5xx/config.mk.

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

We do not have to define CONFIG_MPC512X in board config headers
because it is defined in arch/powerpc/cpu/mpc512x/config.mk.

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

We do not have to define CONFIG_8xx in source files
because it is defined in arch/powerpc/cpu/mpc8xx/config.mk

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

We do not have to define CONFIG_MPC83xx in board config headers
because it is defined in arch/powerpc/cpu/mpc83xx/config.mk.

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

We do not have to define CONFIG_4xx in board config headers
because it is defined in arch/powerpc/cpu/ppc4xx/config.mk.

include/configs/JSE.h defines "CONFIG_4x", not "CONFIG_4xx".
I believe it is a typo because "CONFIG_4x" is not used at all
in other files.
So, I also deleted "CONFIG_4x" in include/configs/JSE.h.

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

Commit e5c5301f refactored the build system not to make
directories in board makefiles.
But commit 8f380381 create directories again in
board/avionic-design/tec-ng/Makefile.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Alban Bedel <alban.bedel@avionic-design.de>

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

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

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Stefan Roese <sr@denx.de>
Acked-by: Matthias Fuchs <matthias.fuchs@esd.eu>

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

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

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

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

Like other architectures, CONFIG_AVR32 can be defined
in arch/avr32/config.mk rather than board header files.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Andreas Bießmann <andreas.devel@googlemail.com>
Acked-by: Andreas Bießmann <andreas.devel@googlemail.com>

Commit 643aae14
deleted include/linux/config.h but missed to
delete _LINUX_CONFIG_H macro.
It is no longer used at all.

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

The script files, define2mk.sed and make-asm-offsets
are used to create autoconf.mk and asm-offsets.h
while build.

Whereas README, dot.kermrc, flash_param, send_cmd, send_image
are files useful for kermit.

We should not put files which have the totally different purpose
into the same directory.

This commit creates a new directory, tools/kermit,
and move kermit files into it.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Wolfgang Denk <wd@denx.de>

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