Some old GNU assemblers, such as v2.14 (ELDK 3.1.1), v2.16 (ELDK 4.1.0),
warns illegal global symbol references by bal (and jal also) instruction.
This does not happen with the latest binutils v2.18.

Here's an example on gth2_config:

mips_4KC-gcc  -D__ASSEMBLY__ -g  -Os   -D__KERNEL__ -DTEXT_BASE=0x90000000 -I/home/skuribay/devel/u-boot.git/include -fno-builtin -ffreestanding -nostdinc -isy
stem /opt/eldk311/usr/bin/../lib/gcc-lib/mips-linux/3.3.3/include -pipe  -DCONFIG_MIPS -D__MIPS__ -G 0 -mabicalls -fpic -pipe -msoft-float -march=4kc -mtune=4k
c -EB -c -o cache.o cache.S
cache.S: Assembler messages:
cache.S:243: Warning: Pretending global symbol used as branch target is local.
cache.S:250: Warning: Pretending global symbol used as branch target is local.

In principle, gas might be sensitive to global symbol references in PIC
code because they should be processed through GOT (global offset table).
But if `bal' instruction is used, it results in PC-based offset jump.
This is the cause of this warning.

In practice, we know it doesn't matter whether PC-based reference or GOT-
based. As for this case, both will work before/after relocation. But let's
fix the code.

This patch explicitly sets up a target address, then jump there.
Here's an example of disassembled code with/without this patch.

 90000668:       1485ffef        bne     a0,a1,90000628 <mips_cache_reset+0x20>
 9000066c:       ac80fffc        sw      zero,-4(a0)
 90000670:       01402821        move    a1,t2
-90000674:       0411ffba        bal     90000560 <mips_init_icache>
-90000678:       01803021        move    a2,t4
-9000067c:       01602821        move    a1,t3
-90000680:       0411ffcc        bal     900005b4 <mips_init_dcache>
-90000684:       01a03021        move    a2,t5
-90000688:       03000008        jr      t8
-9000068c:       00000000        nop
+90000674:       01803021        move    a2,t4
+90000678:       8f8f83ec        lw      t7,-31764(gp)
+9000067c:       01e0f809        jalr    t7
+90000680:       00000000        nop
+90000684:       01602821        move    a1,t3
+90000688:       01a03021        move    a2,t5
+9000068c:       8f8f81e0        lw      t7,-32288(gp)
+90000690:       01e0f809        jalr    t7
+90000694:       00000000        nop
+90000698:       03000008        jr      t8
+9000069c:       00000000        nop

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

Recent bootelf command fixes (017e9b7925f74878d0e9475388cca9bda5ef9482,
"allow ports to override bootelf behavior") requires ports to have this
function.

Signed-off-by: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>

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>