Build the loongson kernels with all the binutils loongson2f errata workarounds

From Zhang Fuxin via https://sourceware.org/ml/binutils/2009-11/msg00387.html

- The NOP issue

"The nature of the erratum is deeply related to the microarchitecture of
Loongson-2. It uses roughly a 4-way superscalar dynamically scheduled core,
instructions are excuted as much as possible in parallel with technics like
branch prediction etc. We use a 8-entry internal branch prediction queue to
keep track of each predicted branches, if some branches are proved to be
wrongly predicted, all the instructions following it will be cancelled,together
with the resources used by them, including the registers used for renaming, and
the queue entry will be freeed. There is a bug that might cause a hang when the
queue is full(some resources might been leaked due to conflict branch entries),
the workaround is to reduce the possiblity of branch queue full by using
renaming registers(they are also limited, can prevent too many simutaneos
branches). In theory this is still not enough to fully eliminate possible
hangs, but the possiblity is extremely low now and hard to be hit in real
code."

- The JUMP instructions issue

"The Loongson-2 series processors have quite complex micro-architecture, it will
try to execute instructions from the predicated branch of coming instruction
stream before they are confirmed to be run, if the predication of branch
direction is proved wrong later, the instructions will be cancelled, but if the
instructions is a read from memory, the read action might not be cancelled(but
the changes to register will) to enable some prefetch. This will lead to some
problems when compining with some chipsets. E.g. the AMD CS5536 used in
Yeeloong/Fuloong will hang if it gets an address in the physical address range
of 0x100000-0x200000(might be more other ranges). Speculative reads can perform
read at any address in theory(due to wrong prediction of branch directions and
the use of branch target buffer), thus in very few occasions they might cause a
hard lock of the machine.

To prevent this, we need to prevent some addresses from entering branch
target buffers. A way to do this is that to modify all jump targets, e.g.,
calulations of t9
...
jalr t9 =>
calculations of t9
or t9, t9, 0x80000000; // to make sure t9 is in kseg0
jalr t9
Of course, we have to consider 64/32bit, and modules addresses etc.

This only need to be performed on kernel code, because only there we can have
accesses not translated/limited by TLB. For user code, it is impossible to
generate accesses to unwanted physical address. So it is safe.

Also, to prevent addresses generated by user mode code to be used by the
kernel, we add a few empty jumps to flush the BTB upon entrance to kernel."

Add loongson support to evbmips, based on the OpenBSD loongson port
and the existing evbmips/gdium support.
This has been tested on a lemote fuloong device (boots multiuser),
should also support other lemote devices (maybe with minor adjustments,
or adding missing drivers). There is some gdium support here too, but it
may not be yet complete (someone with a gdium would need to have a look,
hi macallan@ :)
loongson kernels are 64bits only: the loongson2f has ressources located
above the 2Gb physical address, and it's much easier to access it
using XKPHYS than trying to make it fit in the limited 32bit kernel
virtual space.