Current assembler codes are inconsistent in the way of register jump
instruction usage; some use jr, some use j. Of course GNU as allows both
usages, but as can be expected from `Jump Register' the mnemonic `jr' is
more intuitive than `j'. For example, Linux doesn't have `j <reg>' usage
at all.

Signed-off-by: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>

Signed-off-by: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>

You can't judge UNCACHED by Config.K0 LSB.

Signed-off-by: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>

Currently we do 1) Index_Store_Tag_I, 2) Fill and 3) Index_Store_Tag_I
again per a loop for I-cache initialization. But according to 'See MIPS
Run', we're encouraged to use three separate loops rather than combining
them *for both I- and D-cache*. This patch tries to fix this.

In accordance with fixing above, mips_init_[id]cache are separated from
mips_cache_reset(), and rewrite cache loops are completely rewritten with
useful macros.

Signed-off-by: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>

This routine fills memory with zero by 64 bytes, and is 64-bit capable.

Signed-off-by: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>

This patch replaces the current function definitions with NESTED, LEAF
and END macro. They specify some more additional information about the
function; an alignment of symbol, type of symbol, stack frame usage, etc.
These information explicitly tells the assembler and the debugger about
the types of code we want to generate.

Signed-off-by: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>

The initial intension of having mips_cache_lock() was to use the cache
as memory for temporary stack use so that a C environment can be set up
as early as possible.

But now mips_cache_lock() follow lowlevel_init(). We've already have the
real memory initilaized at this point, therefore we could/should use it.
No reason to lock at all.

Other problems:

Cache locking is not consistent across MIPS implementaions. Some imple-
mentations don't support locking at all. The style of locking varies -
some support per line locking, others per way, etc. Some parts use bits
in status registers instead of cache ops. Current mips_cache_lock() is
not necessarily general-purpose.

And this is worthy of special mention; once U-Boot/MIPS locks the lines,
they are never get unlocked, so the code relies on whatever gets loaded
after U-Boot to re-initialize the cache and clear the locks. We're sup-
posed to have CFG_INIT_RAM_LOCK and unlock_ram_in_cache() implemented,
but leave the situation as it is for a long time.

For these reasons, I proposed the removal of mips_cache_lock() from the
global start-up code.

This patch adds CFG_INIT_RAM_LOCK_MIPS to make existing users aware that
*things have changed*. If he wants the same behavior as before, he needs
to have CFG_INIT_RAM_LOCK_MIPS in his config file.

If we don't have any regression report through several releases, then
we'll remove codes entirely.

Signed-off-by: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>
Acked-by: Andrew Dyer <amdyer@gmail.com>

No logical changes.

Signed-off-by: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>

  - Add support for Altera FPGA ACEX1K

* Patches by Thomas Lange, 09 Oct 2003:
  - Endian swap ATA identity for all big endian CPUs, not just PPC
  - MIPS only: New option CONFIG_MEMSIZE_IN_BYTES for passing memsize
    args to linux
  - add support for dbau1x00 board (MIPS32)

  - remove trailing white space, trailing empty lines, C++ comments, etc.
  - split cmd_boot.c (separate cmd_bdinfo.c and cmd_load.c)

* Patches by Kenneth Johansson, 25 Jun 2003:
  - major rework of command structure
    (work done mostly by Michal Cendrowski and Joakim Kristiansen)