boards.cfg: keep it sorted filling the board field

The boards.cfg file has allowed to use "-" for the board (= 6th) field
if the board name is the same as the 7th field.

But I notice one problem.
Because tools/reformat.py sorts the lines in the simple alphabetical
order (= the order of character code), some entries for the same board
are not lined up together.

For example, "bf527-ezkit" and "bf527-ezkit-v2" share the same board.
But they are located separately because "bf527-ezkit" fills the board
field with "-" whereas "bf527-ezkit-v2" specifies it explicitely.

The similar things can be seen:
 - between "trizepsive" and "polaris"
 - between "RRvision" and "RRvision_LCD"
 - between "korat" and "korat_perm"
 - between "lwmon5" and "lcd4_lwmon5"

This commit was generated by the following command:

awk '$6 == "-" { $6 = $7 } { print }' boards.cfg \
  | tools/reformat.py -i -d '-' -s 8  > boards0.cfg; \
  mv boards0.cfg boards.cfg

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
boards.cfg: change "<none>" in the board field to "-"

In the previous commit, all the board fields were filled.

Now we can use "-" in the board field for a different meaning.

Going forward, "-" stands for no board directory
as in cpu, soc, vendor fields.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
ARM: DRA7xx: Update the board_name env variable

Update the board_name env variable and accordingly
populate the dtb file.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
socfpga: timer actually counts down

Timer on cyclone5 actually counts down. It took me a while to figure
out, as timer counting in wrong direction actually _can_ be used, it
just appears to tick at extremely high frequency in u-boot.

The bug was introduced in commit
23ab7ee0ffa9d5efd0b4ad830befba306d24a327.

Signed-off-by: Pavel Machek <pavel@denx.de>
Acked-by: Marek Vasut <marex@denx.de>
Prepare v2014.07

Signed-off-by: Tom Rini <trini@ti.com>
Don't send: MAKEALL: Display MD5SUM

 === Do not send to ML, Do not merge into the mailline ===

 What is this ?
 --------------

When you change some makefiles and you want to confirm
your changes are harmless, this patch will be helpful.

With this patch, MAKEALL will display md5sum of
 -  ./u-boot.bin
 -  spl/u-boot-spl.bin (if it exists)
 -  tpl/u-boot-tpl.bin (if it exists)
 -  examples/standalone/hello_world.bin (if it exists)

If the same md5sum is displayed, it means your commits
still generate the same outputs.

Timestamp and version information must be disabled,
otherwise MAKEALL will show the different md5sum at every build.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
microblaze: workaround for build error
bfin: workaround
m68k: work around warnings
Don't send: tools: Add remove_redundant_config
Don't send: tools: add find_unused_source
Don't send: tools: Add find_unused_header
Don't send: tools: run_sed
Don't send: tools: check_config

Check if specified CONFIG is defined or not.
Don't send: tools: insert_config
arm: include config.h in arch/arm/lib/vectors.S

Commit 41623c91 moved exception handling to arch/arm/lib/vectors.S,
but it missed to include <config.h>.

This mistake causes two problems.

[1]
"enbw_cmc", "da850evm_direct_nor", "calimain" boards are broken.

They expect CONFIG_SYS_DV_NOR_BOOT_CFG (= 0x00000011) at the beginning
of the boot image.

But it is missing since commit 41623c91 because
CONFIG_SYS_DV_NOR_BOOT_CFG is never defined in arch/arm/lib/vectors.S.

[2]
Boards with CONFIG_USE_IRQ fail with undefined reference error
of "IRQ_STACK_START" and "FIQ_STACK_START".

This is _potential_ problem because currently there is no board
enabling CONFIG_USE_IRQ.
But we cannot deny the possibility some board may enable it in future.

(If we are not willing to support interrupt feature, all references
to CONFIG_USE_IRQ should be dropped immediately.)

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Series-to: uboot
Series-version: 2
Series-changes: 2
  - Rephrase commit subject and description. (No change in code-diff)

Cover-letter:
ARM: bug fixes of commit 41623c91 (arch/arm/lib/vectors.S)

END
zynq: disable -Wstrict-prototypes option for ps7_init.c

The files ps7_init.c and ps7_init.h are supposed to be generated by
hw projects such as Vivado, PlanAhead and then to be copied into
board/xilinx/zynq directory.

But some prototypes in them cause annoying warning messages:

  CC      spl/board/xilinx/zynq/ps7_init.o
In file included from board/xilinx/zynq/ps7_init.c:50:0:
board/xilinx/zynq/ps7_init.h:137:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
board/xilinx/zynq/ps7_init.h:138:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
board/xilinx/zynq/ps7_init.h:139:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
board/xilinx/zynq/ps7_init.h:145:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
board/xilinx/zynq/ps7_init.c:12602:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
board/xilinx/zynq/ps7_init.c:12723:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
board/xilinx/zynq/ps7_init.c:12742:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
board/xilinx/zynq/ps7_init.c:12761:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
board/xilinx/zynq/ps7_init.c:12854:6: warning: function declaration isn't a prototype [-Wstrict-prototypes]

The prototypes should be

  int ps7_init(void);
  int ps7_post_config(void);
  int ps7_debug(void);

rather than

  int ps7_init();
  int ps7_post_config();
  int ps7_debug();

We do not want to be bothered because of automatically generated files.
But we cannot touch the external projects for now.
What we can do is to disable -Wstrict-prototypes for ps7_init.c

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Tested-by: Michal Simek <michal.simek@xilinx.com>
Series-to: uboot
Series-version: 2
Series-changes: 2
   No change in code. Some changes in git-log
  - Fix a typo:  s/causes/cause/
  - Add Tested-by credit
powerpc: mpc8xx: remove some of tqm8xx board family without maintainers

Remove NSCU, TK885D, TQM823M, TQM850M, TQM855M, TQM860M,
TQM862L, TQM826M, TQM866M, TQM885D boards support.

These boards are old enough and have no maintainers.

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

I built all the other boards and compared MD5SUM.

I confirmed this patch has no impact against them.

END
sparc: merge LEON3 linker scripts

The linker scripts of LEON3

 - board/gaisler/grsim/u-boot.lds
 - board/gaisler/gr_cpci_ax2000/u-boot.lds
 - board/gaisler/gr_ep2s60/u-boot.lds
 - board/gaisler/gr_xc3s_1500/u-boot.lds

are the same (except cosmetic differences such as indentation).

This commit merges them into arch/sparc/cpu/leon3/u-boot.lds.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Daniel Hellstrom <daniel@gaisler.com>
Series-to: uboot
Series-cc: Daniel Hellstrom <daniel@gaisler.com>
Cover-letter:
Merge all SPARC linker scripts into a single file

In the other architecutres, the default linker scripts are placed at
arch/${ARCH}/cpu/u-boot.lds or arch/${ARCH}/cpu/${CPU}/u-boot.lds.

On the other hand, SPARC does not have arch-default linker script
but has almost the same linker scripts under each board directory.

They can be easily merged.

I built all SPARC boards and compared MD5SUM.
The same binaries are produced before/after this series.
So I am sure this clean-up is correct.

END
sparc: merge LEON2 and LEON3 linker scripts

There is only one line diff between LEON2 and LEON3 linker scripts:

  -             arch/sparc/cpu/leon2/start.o (.text)
  +             arch/sparc/cpu/leon3/start.o (.text)

They can be written in the same way:

                */start.o (.text)

So, board/gaisler/grsim_leon2/u-boot.lds
and arch/sparc/cpu/leon3/u-boot.lds
can be merged into arch/sparc/cpu/u-boot.lds.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Daniel Hellstrom <daniel@gaisler.com>