Changes in std.loongson

Changes in std.loongson http://nxr.netbsd.org/rss/src/sys/arch/evbmips/conf/std.loongson en Copyright 2005 Java 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." /src/sys/arch/evbmips/conf/std.loongson - 1.2 Tue Aug 08 00:22:21 UTC 2017 maya branches: 1.1.12; 1.1.30; 1.1.46; 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. /src/sys/arch/evbmips/conf/std.loongson - 1.1 Sat Aug 27 13:42:44 UTC 2011 bouyer Pull up following revision(s) (requested by maya in ticket #246): sys/arch/evbmips/conf/std.loongson: revision 1.2 usr.sbin/sysinst/arch/evbmips/md.h: revision 1.2 sys/arch/mips/mips/mipsX_subr.S: revision 1.101 sys/arch/mips/mips/mipsX_subr.S: revision 1.102 sys/arch/mips/mips/mipsX_subr.S: revision 1.103 sys/arch/mips/mips/mipsX_subr.S: revision 1.104 In working around loongson errata clear BTB and RAS, same as other operating systems. 15 Errata: Issue of Out-of-order in loongson (translated) In loongson 2F, because of the branch prediction, sometimes the CPU may fetch the instructions from some unexpected area (for example I/O space). It is an invalid operation. There are two ways for the CPU to choose the branch target. The first one is predicting the branch target according to the branch target history. The second one is calculating the branch target by the ALU. There are most 8 instructions in the instruction window at the same time in loongson2f (Remember the loongson 2f is superscalar, right?). Hence, the branch target of an indirect branch(such as jr) could be got(may be predicted by the branch target history) earlier and the instrctions of the branch target could be prefetched even if there are branch instructions before it. As a result, it is possible to fetch the instructions from I/O region( say out-of the physical address range of [0- 0x100000]) in kernel model because of the instruction prefetch of the branch target. There are some suggestions to prevent prefetching instructions from the I/O region in kernel mode. (1) When switching from user model to kernel model, you should flush the branch target history such as BTB and RAS. (2) Doing some tricks to the indirect branch target to make sure that the indirect branch target can not be in the I/O region. Remove whitespace I just introduced Build the loongson kernels with all the binutils loongson2f errata workarounds From Zhang Fuxin via <a rel="nofollow" href="https://sourceware.org/ml/binutils/2009-11/msg00387.html">https://sourceware.org/ml/binutils/2009-11/msg00387.html</a> - 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." evbmips can "boot root FFSv2" It typically uses a non-NetBSD bootloader (PMON, u-boot...) and those don't differentiate from v1 from v2 - both are unsupported and it requires a separate boot partition. Don't need the errata workaround on user return It's reported that the MMU will block such invalid reads in userland, and it's only needed on entry. use meaningful name for errata hack, dedup /src/sys/arch/evbmips/conf/std.loongson - 1.1.46.1 Tue Aug 29 00:47:29 UTC 2017 martin Sync with HEAD /src/sys/arch/evbmips/conf/std.loongson - 1.1.30.1 Mon Aug 28 17:51:36 UTC 2017 skrll update from HEAD /src/sys/arch/evbmips/conf/std.loongson - 1.1.12.1 Sun Dec 03 11:36:09 UTC 2017 jdolecek