Though nios2-generic board meant to be a template, it is helpful
to be able to test on a real hardware. As the nios2 linux is
developed and tested on a 3c120 FPGA based Golden Hardware Reference
Design, it makes sense to rebase nios2-generic on this FPGA design.
Signed-off-by: NThomas Chou <thomas@wytron.com.tw>

This patch changes the link script to base at CONFIG_SYS_MONITOR_BASE.
Then we can remove the text_base hook in nios2-generic board.
Signed-off-by: NThomas Chou <thomas@wytron.com.tw>

The nios2-yanu.h contains hardware registers and bits of
opencores yanu. As there is no other user of this header
, it should be moved into the driver.
Signed-off-by: NThomas Chou <thomas@wytron.com.tw>
CC: Renato Andreola <renato.andreola@imagos.it>

The nios2.h is nios2 cpu specific, and should go arch asm
directory.
Signed-off-by: NThomas Chou <thomas@wytron.com.tw>

The nios2-io.h defines hardware registers and bits of several FPGA
IP cores. It could be divided in to the specific drivers, including
altera timer, altera sysid, altera uart and altera jtag uart. The
altera pio and altera spi drivers use their own hardware definitions.
The removal of nios2-io.h will help modularity and maintenance.
Signed-off-by: NThomas Chou <thomas@wytron.com.tw>

The epled driver was replaced by altera_pio and gpio_led.
Signed-off-by: NThomas Chou <thomas@wytron.com.tw>

One specific USB 3.0 device behaves strangely when reset by
usb_new_device()'s call to hub_port_reset(). For some reason, the device
appears to briefly drop off the bus when this second bus reset is
executed, yet if we retry this loop, it'll eventually come back after
another two resets.

If USB bus reset is executed over and over within usb_new_device()'s call
to hub_port_reset(), I see the following sequence of results, which
repeats as long as you want:

1) STAT_C_CONNECTION = 1 STAT_CONNECTION = 0  USB_PORT_STAT_ENABLE 0
2) STAT_C_CONNECTION = 1 STAT_CONNECTION = 1  USB_PORT_STAT_ENABLE 0
3) STAT_C_CONNECTION = 1 STAT_CONNECTION = 1  USB_PORT_STAT_ENABLE 1

The device in question is a SanDisk Ultra USB 3.0 16GB memory stick with
USB VID/PID 0x0781/0x5581.

In order to allow this device to work with U-Boot, ignore the
{C_,}CONNECTION bits in the status/change registers, and only use the
ENABLE bit to determine if the reset was successful.

To be honest, extensive investigation has failed to determine why this
problem occurs. I'd love to know! I don't know if it's caused by:
* A HW bug in the device
* A HW bug in the Tegra USB controller
* A SW bug in the U-Boot Tegra USB driver
* A SW bug in the U-Boot USB core

This issue only occurs when the device's USB3 pins are attached to the
host; if only the USB2 pins are connected the issue does not occur. The
USB3 controller on Tegra is in reset, so is not actively communicating
with the device at all - a USB3 analyzer confirms this. Slightly
unplugging the device (so the USB3 pins don't contact) or using a USB2
cable or hub as an intermediary avoids the problem. For some reason,
the Linux kernel (either on the same Tegra board, or on an x86 host)
has no issue with the device, and I observe no disconnections during
reset.

This change won't affect any USB device that already works, since such
devices could not currently be triggering the error return this patch
removes, or they wouldn't be working currently.

However, this patch is quite reliable in practice, hence I hope it's
acceptable to solve the problem.

The only potential fallout I can see from this patch is:

* A broken device that triggers C_CONNECTION/!CONNECTION now causes the
  loop in hub_port_reset() to run multiple times. If it never succeeds,
  this will cause "usb start" to take roughly 1s extra to execute.

* If the user unplugs a device while hub_port_reset() is executing, and
  very quickly swaps in a new device, hub_port_reset() might succeed on
  the new device. This would mean that any information cached about the
  original device (from the descriptor read in usb_new_device(), which
  simply caches the max packet size) might be invalid, which would cause
  problems talking to the new device. However, without this change, the
  new device wouldn't work anyway, so this is probably not much of a
  loss.
Signed-off-by: NStephen Warren <swarren@nvidia.com>

As we support both Host and Device mode operation, an OTG controller
can return -ENODEV on a port which it found to be in Device mode during
Host mode scan for devices. In case -ENODEV is returned, print that the
port is not available and continue instead of screaming a bloody error
message.
Signed-off-by: NMarek Vasut <marex@denx.de>

Commit 3ff291f3
(kconfig: convert Kconfig helper script into a shell script)
restored "<board>_config" target for backward compatibility.
It should be documented.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>

This tool only works on python 2 (python 2.6 or lator).

Change the shebang to make sure the script is run by python 2
and clearly say the supported version in the comment block.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>

We noticed on the DXR2 platform (AM335x with a SMSC LAN9303 switch connected
to the CPSW MAC) that the network performance in U-Boot is quite poor. Only
when the transfer is started without a cable connected, and the cable is
plugged after the first timeout "T" occured, an increased in performance
can be seen. Debugging has revealed, that the cpsw driver has constant
link checking builtin into the rx and tx functions. This results in the
bad performance and seems to be unnecessary. The link has already been
checked in the init function, before the transfer is started. This usually
is sufficient.

BTW: I have seen no other network driver in U-Boot so far, that constantly
checks for link in the rx / tx functions.

The performance numbers on the DXR2 board are:

0.56 MiB/s	cpsw_check_link() in rx and tx path
0.87 MiB/s	cpsw_check_link() only in tx path
1.0  MiB/s	cpsw_check_link() only in rx path
2.7  MiB/s	no cpsw_check_link() in rx and tx path

So with this patch the network performance on DXR2 increases from 0.56
to 2.7 MiB/s (nearly 5 times as fast).
Signed-off-by: NStefan Roese <sr@denx.de>
Tested-by: NSamuel Egli <samuel.egli@siemens.com>
Tested-by: NHeiko Schocher <hs@denx.de>
Cc: Vladimir Koutny <vladimir.koutny@streamunlimited.com>
Cc: Mugunthan V N <mugunthanvnm@ti.com>
Cc: Joe Hershberger <joe.hershberger@gmail.com>
Cc: Tom Rini <trini@ti.com>

I guess some developers are already getting sick of this tool
because it generally takes a few minites to generate the boards.cfg
on a reasonable computer.

The idea popped up on my mind was to skip Makefiles and
to run script/kconfig/conf directly.
This tool should become about 4 times faster.
You might still not be satisfied, but better than doing nothing.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: NSimon Glass <sjg@chromium.org>

It looks silly to regenerate the boards.cfg even when it is
already up to date.

The tool should exit with doing nothing if the boards.cfg is newer
than any of defconfig, Kconfig and MAINTAINERS files.

Specify -f (--force) option to get the boards.cfg regenerated
regardless its time stamp.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: NSimon Glass <sjg@chromium.org>

This tool deletes the incomplete boards.cfg
if it encounters an error or is is terminated by the user.

I notice some problems even though they rarely happen.

[1] The boards.cfg is removed if the program is terminated
during __gen_boards_cfg() function but before boards.cfg
is actually touched.  In this case, the previous boards.cfg
should be kept as it is.

[2] If an error occurs while deleting the incomplete boards.cfg,
the program throws another exception.  This hides the privious
exception and we will not be able to know the real cause.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: NSimon Glass <sjg@chromium.org>

When an error occurs or the program is terminated by the user
on the way, the destructer __del__ of class Slot is invoked and
the work directories are removed.

We have to make sure there are no subprocesses (in this case,
"make O=<work_dir> ...") using the work directories before
removing them.  Otherwise the subprocess spits a bunch of error
messages possibly causing more problems.  Perhaps some users
may get upset to see too many error messages.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: NSimon Glass <sjg@chromium.org>

The tools/genboardscfg.py expects all the Kconfig and defconfig are
written correctly.  Imagine someone accidentally has broken a board.
Error-out just for one broken board is annoying for the other
developers.  Let the tool skip insane boards and continue processing.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: NSimon Glass <sjg@chromium.org>

tools/genboardscfg.py expects all the boards have MAINTAINERS.
If someone adds a new board but misses to add its MAINTAINERS file,
tools/genboardscfg.py fails to generate the boards.cfg file.
It is annoying for the other developers.

This commit allows tools/genboardscfg.py to display warning messages
and continue processing even if some MAINTAINERS files are missing
or have broken formats.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Kconfig in U-Boot creates a temporary file configs/.tmp_defconfig
during processing "make <board>_defconfig".  The temporary file
might be left over for some reasons.

Just in case, tools/genboardscfg.py should make sure to
not read such garbage files.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: NSimon Glass <sjg@chromium.org>

The host filesystem name has changed, so update the tests. The tests now
run again correctly:

$ make O=b/sandbox sandbox_defconfig all
...
$ test/image/test-fit.py -u b/sandbox/u-boot
FIT Tests

=========
Kernel load
Kernel + FDT load
Kernel + FDT + Ramdisk load

Tests passed
Caveat: this is only a sanity check - test coverage is poor
Signed-off-by: NSimon Glass <sjg@chromium.org>

Commit e3a5bbce broke the FIT image tests by not loading a ramdisk even if
a load address is provided in the FIT. The rationale was that a load address
of 0 should be considered to mean 'do not load'.

Add a new load operation which supports this feature, so that the ramdisk
will be loaded if a non-zero load address is provided.
Signed-off-by: NSimon Glass <sjg@chromium.org>

Copy the Kconfig option from "init/Kconfig" of Linux v3.16 tag
and adjust the help document.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>

Now we have CONFIG_LOCALVERSION and CONFIG_LOCALVERSION_AUTO
in Kconfig so we can use scripts/setlocalversion without
any adjustment.  Copy it from Linux 3.16 as is.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>

Copy Kconfig options from "init/Kconfig" of Linux v3.16 tag
and adjust some parts of the help document.

Move CONFIG_SPL, CONFIG_TPL, ... etc. to "Boot images" menu.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>

This commit makes sure boards.cfg is up to date before starting
the build tests.  tools/genboardscfg.py exits immediately printing
"boards.cfg is up to date. Nothing to do." when boards.cfg is
already new.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: NSimon Glass <sjg@chromium.org>

This commit makes sure boards.cfg is up to date before starting
the build tests.  tools/genboardscfg.py exits immediately printing
"boards.cfg is up to date. Nothing to do." when boards.cfg is
already new.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>

This patch fixes a minor problem:
If a block without "F:   configs/*_defconfig" is followed by another
block with "F:   configs/*_defconfig", the maintainers from the
former block are squashed into the latter.
Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>

The commit (SHA1: 8fc17131) reintroduced correct values for vendor and
product IDs required for UMS gadget to work properly either at Windows or
Linux.

This data was missing for GONI target, so this commit corrects this mistake.
Signed-off-by: NLukasz Majewski <l.majewski@samsung.com>
Acked-by: NRobert Baldyga <r.baldyga@samsung.com>
Acked-by: NMinkyu Kang <mk7.kang@samsung.com>

This option is currently not supported, but needs to be, for buildman to
operate as expected.
Reported-by: NYork Sun <yorksun@freescale.com>
Signed-off-by: NSimon Glass <sjg@chromium.org>

snyc with linux v3.15:

commit 1860e379875dfe7271c649058aeddffe5afd9d0d
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Jun 8 11:19:54 2014 -0700

    Linux 3.15
Signed-off-by: NHeiko Schocher <hs@denx.de>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Tom Rini <trini@ti.com>

while playing with the new mtd/ubi/ubifs sync, found some
small updates for it:

- add del_mtd_partition() to include/linux/mtd/mtd
- mtd: add a debug_printf
- remove some not used functions
Signed-off-by: NHeiko Schocher <hs@denx.de>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Tom Rini <trini@ti.com>

resync ubi subsystem with linux:

commit 455c6fdbd219161bd09b1165f11699d6d73de11c
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Mar 30 20:40:15 2014 -0700

    Linux 3.14

A nice side effect of this, is we introduce UBI Fastmap support
to U-Boot.
Signed-off-by: NHeiko Schocher <hs@denx.de>
Signed-off-by: NTom Rini <trini@ti.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Sergey Lapin <slapin@ossfans.org>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Joerg Krause <jkrause@posteo.de>

- move linux specific defines from usb and video code
  into linux/compat.h
- move common linux specific defines from include/ubi_uboot.h
  to linux/compat.h
- add for new mtd/ubi/ubifs sync new needed linux specific
  defines to linux/compat.h
Signed-off-by: NHeiko Schocher <hs@denx.de>
Cc: Marek Vasut <marex@denx.de>
Cc: Anatolij Gustschin <agust@denx.de>
[trini: Add spin_lock_irqsave/spin_unlock_irqrestore dummies from
usb/lin_gadet_compat.h]
Signed-off-by: NTom Rini <trini@ti.com>