headers
Manuel Bouyer | 10 Aug 2011 12:33

some mips changes for loongson2

Hello,
I've been working on getting NetBSD running on a loongson2f-based
mini-PC (lemote fuulong). There's already ls2f support for gdium but it's
not complete (for example, it doesn't support 64bits, nor the ISA devices
found on lemote hardware).
Here's a first round of patches, which do 2 things:
- LS2f doens't have separate vector address for tlb_miss and xtlb_miss
  exeptions, the tlb_miss handler address is used for both (and the
  vector can be twice as large as the xtlb_miss space is free for use).
  mips.diff contains a patch for this, where the ls2f tlb_miss
  checks if the fault address is in useg or xuseg and takes appropriate
  action.
- ls2f CPUs have a hardware bug which can make them hang on a jump register
  in kernel mode. A workaround can be implemented in binutils which adds
  2 instructions using the at register before each j(r) ra.
  (right now I'm using a OpenBSD patch which does:
  li at,3
  dmtc0 at, $22
  to clear the branch prediction logic before any jump register. Our binutils
  have something sighly different, I've yet to look at it to see if it's
  useable for us - in any case that's a different topic).
  This workaround requires the use of at register before jump register,
  so I patched the assembly in arch/mips and common/ to allow at use before
  jump so that the assembler can install the workaroud.

Any comment about these 2 patches ?

--

-- 
Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
(Continue reading)

Permalink | Reply | 4 comments |
headers
Simon Burge | 10 Aug 2011 14:28
Picon

Re: some mips changes for loongson2

Hi Manuel,

Manuel Bouyer wrote:

> Hello,
> I've been working on getting NetBSD running on a loongson2f-based
> mini-PC (lemote fuulong). There's already ls2f support for gdium but it's
> not complete (for example, it doesn't support 64bits, nor the ISA devices
> found on lemote hardware).
> Here's a first round of patches, which do 2 things:
> - LS2f doens't have separate vector address for tlb_miss and xtlb_miss
>   exeptions, the tlb_miss handler address is used for both (and the
>   vector can be twice as large as the xtlb_miss space is free for use).
>   mips.diff contains a patch for this, where the ls2f tlb_miss
>   checks if the fault address is in useg or xuseg and takes appropriate
>   action.
> - ls2f CPUs have a hardware bug which can make them hang on a jump register
>   in kernel mode. A workaround can be implemented in binutils which adds
>   2 instructions using the at register before each j(r) ra.
>   (right now I'm using a OpenBSD patch which does:
>   li at,3
>   dmtc0 at, $22
>   to clear the branch prediction logic before any jump register. Our binutils
>   have something sighly different, I've yet to look at it to see if it's
>   useable for us - in any case that's a different topic).
>   This workaround requires the use of at register before jump register,
>   so I patched the assembly in arch/mips and common/ to allow at use before
>   jump so that the assembler can install the workaroud.
> 
> Any comment about these 2 patches ?
(Continue reading)

Permalink | Reply | 3 comments |
headers
David Holland | 10 Aug 2011 19:04
Picon

Re: some mips changes for loongson2

On Wed, Aug 10, 2011 at 10:28:11PM +1000, Simon Burge wrote:
 > >  EXPORT(_lock_ras_start)
 > >  STATIC_LEAF(ras_atomic_cas_noupdate)
 > > -	j	ra
 > > +	RETURN
 > >  	 move	v0, t0
 > >  END(ras_atomic_cas_noupdate)
 > 
 > I _think_ I'd like to see a "j ra" comment on this, but not entirely
 > sure, as we don't use the "RETURN" convention anywhere else.  That said,
 > this hardly looks great either:
 > 
 > 	STATIC_LEAF(ras_atomic_cas_noupdate)
 > 		RETURN			/* j ra   on most CPUs */
 > 		 move   v0, t0
 > 	END(ras_atomic_cas_noupdate)

Call the macro J_RA; that'll make it much clearer.

--

-- 
David A. Holland
dholland <at> netbsd.org
Permalink | Reply | 0 comments |
headers
Manuel Bouyer | 10 Aug 2011 20:56

Re: some mips changes for loongson2

On Wed, Aug 10, 2011 at 10:28:11PM +1000, Simon Burge wrote:
> [...]
> > Index: mips/lock_stubs_ras.S
> > ===================================================================
> 
> > + * to work around the branch prediction engine misbehavior of
> > + * Loongson 2F processors we need to clear the BTB before a j ra.
> > + * This requires extra instructions which don't fit in the RAS blocks,
> > + * so do a PC-relative just to a block of code (this is the same size as
> > + * a j ra) where we can let the assembler install the workaround.
> 
> Perhaps spell out BTB as "branch target buffer"?  I needed google to
> expand that.

Sure, I updated my source tree.

> 
> >  <at>  <at>  -89,7 +103,7  <at>  <at> 
> >  
> >  EXPORT(_lock_ras_start)
> >  STATIC_LEAF(ras_atomic_cas_noupdate)
> > -	j	ra
> > +	RETURN
> >  	 move	v0, t0
> >  END(ras_atomic_cas_noupdate)
> >  
> 
> I _think_ I'd like to see a "j ra" comment on this, but not entirely
> sure, as we don't use the "RETURN" convention anywhere else.  That said,
> this hardly looks great either:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Manuel Bouyer | 10 Aug 2011 21:50

binutil hacks for loongson2

Hello,
the loongson2f CPU has hardware bugs that must be worked around in
software. Fortunably the workaround is only required for kernel mode,
to userland can be shared with other MIPS platforms.

binutils have 2 options for this: -fix-loongson2f-nop and
-mfix-loongson2f-jump.
The first one cause nop instructions to be replaced with a 'or at,at,zero'.
No problem with this (although my CPU doens't seem to need it).
But from what I've read, this could be required for both kernel and
userland :(

The second one is to work around an issue in kernel mode with
jump register instructions and branch prediction logic, as explained here:
https://groups.google.com/group/loongson-dev/msg/e0d2e220958f10a6?dmode=source&hl=zh
Basically, if the branch prediction logic got the wrong choise, the CPU
would end up fetching an instruction with a wrong register value and this
can hang the system if the wrong value happens to be in I/O space.
What -fix-loongson2f-jump does it to insert instructions before the
j reg or jr reg:
	lui at, 0xcfff0000;
	ori at, at, 0xffff
	and reg, reg, at
	j(r) reg
(instead of jump reg we do jump (reg & 0xcfffffff)).

I've issues with this approach. For example, you can't do a jump 0xbfc00000
anymore without special care. Basically, this assumes that all kernel
code is within the low part of kseg0, but with a 64bit kernel and/or modules
we may want to calls outside of this region (for example, calls to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Manuel Bouyer | 10 Aug 2011 23:55

loongson2f: evbmips or new port ?

Hi,
I have a loongson2f-based system (lemote fuulong) booting into sysinst;
ethernet, serial, USB are working, IDE is almost there (I've an
interupt issue that I've worked around with a hugly hack, but I still
hope to have it working properly :)
For now the code is in arch/loongson, based on a few bits from evbmips/gdium,
and from OpenBSD code (OpenBSD supports gdiun, fuulong and others).

The code can easily be turned into evbmips/loongson, but there's
a few things to consider before going one way or another.

First, loongson2 kernels will be 64bits-only. There are some memory and PCI
ressources mapped in physical address above 2Gb and so inaccessible from
32bit kernel unmapped segments. It would probably be possible to
address this using kernel tlb entries, but it would make things much
more complicated, with a posssible run-time cost and no real benefits.
N32 binaries run fine, of course (I've not tested N64 yet).

Next, there may be userland compile-time options issues: earlier loongson2f
processors needs a workaround in software for processor hang, for both
kernel and userland binaries (nop should be remplaced with or at,at,zero,
this is what gas' -fix-loongson2f-nop option does. Only earlier loongson2f
are affected (mine seems not have this problem) so maybe we can just
ignore the issue, or build all evbmips64 binaries with this option
(-fix-loongson2f-nop has ~no runtime performance impact, and should
have no bad effect on any processor but who knows ...)

loongson2 system use pmon as firmware (http://www.opsycon.se/PMON2000/Main).
The pmon version provided by lemote can load ELF files from ext2fs, fat or
iso9660; the partition table is fdisk-style (MSDOS).
(Continue reading)

Permalink | Reply | 10 comments |
headers
matthew green | 11 Aug 2011 01:12
Picon
Favicon

re: loongson2f: evbmips or new port ?


unless you absolutely can't fit it into evbmips, please put it there.

wrt the loongson workarounds, how about we worry about that if there
are systems we end up supporting that have those bugs?

i think you should be able to build a specific installer for this
system in distrib if necessary, but if a generic image can be used
simply by adding a couple of tools that don't break other systems
that seems a better idea.

.mrg.
Permalink | Reply | 1 comment |
headers
Michael | 11 Aug 2011 04:20
Picon
Gravatar

Re: loongson2f: evbmips or new port ?

Hello,

On Wed, 10 Aug 2011 23:55:25 +0200
Manuel Bouyer <bouyer <at> antioche.eu.org> wrote:

> First, loongson2 kernels will be 64bits-only. There are some memory and PCI
> ressources mapped in physical address above 2Gb and so inaccessible from
> 32bit kernel unmapped segments. It would probably be possible to
> address this using kernel tlb entries, but it would make things much
> more complicated, with a posssible run-time cost and no real benefits.
> N32 binaries run fine, of course (I've not tested N64 yet).
> 
> Next, there may be userland compile-time options issues: earlier loongson2f
> processors needs a workaround in software for processor hang, for both
> kernel and userland binaries (nop should be remplaced with or at,at,zero,
> this is what gas' -fix-loongson2f-nop option does. Only earlier loongson2f
> are affected (mine seems not have this problem) so maybe we can just
> ignore the issue, or build all evbmips64 binaries with this option
> (-fix-loongson2f-nop has ~no runtime performance impact, and should
> have no bad effect on any processor but who knows ...)

Mine seems to need it - even with your patches applied init hangs pretty much immediately ( I used o32
binaries from releng ).
I'll check what happens with n32 and -mfix-loongson2f-nop, a kernel built with this option hangs
immediately as well.

> loongson2 system use pmon as firmware (http://www.opsycon.se/PMON2000/Main).
> The pmon version provided by lemote can load ELF files from ext2fs, fat or
> iso9660; the partition table is fdisk-style (MSDOS).
> It looks like there's no way to load from other disk format
(Continue reading)

Permalink | Reply | 5 comments |
headers
Manuel Bouyer | 11 Aug 2011 12:34

Re: loongson2f: evbmips or new port ?

On Thu, Aug 11, 2011 at 09:12:33AM +1000, matthew green wrote:
> 
> unless you absolutely can't fit it into evbmips, please put it there.
> 
> wrt the loongson workarounds, how about we worry about that if there
> are systems we end up supporting that have those bugs?

My system needs -mfix-loongson2f-jump or -mfix-loongson2f-btb for
kernel. It doens't seem to suffer from the -fix-loongson2f-nop problem.

> 
> i think you should be able to build a specific installer for this
> system in distrib if necessary, but if a generic image can be used
> simply by adding a couple of tools that don't break other systems
> that seems a better idea.

Sure. My main problem is the disklabel issue. As it is right now,
all evbmips system have to share the same machine/disklabel.h and
I don't know at this time if it's useable for loongson (if the existing
evbmips disklabel.h is compatible with mbr).

--

-- 
Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--
Permalink | Reply | 0 comments |
headers
Manuel Bouyer | 11 Aug 2011 12:49

Re: loongson2f: evbmips or new port ?

On Wed, Aug 10, 2011 at 10:20:35PM -0400, Michael wrote:
> > [...]
> > Next, there may be userland compile-time options issues: earlier loongson2f
> > processors needs a workaround in software for processor hang, for both
> > kernel and userland binaries (nop should be remplaced with or at,at,zero,
> > this is what gas' -fix-loongson2f-nop option does. Only earlier loongson2f
> > are affected (mine seems not have this problem) so maybe we can just
> > ignore the issue, or build all evbmips64 binaries with this option
> > (-fix-loongson2f-nop has ~no runtime performance impact, and should
> > have no bad effect on any processor but who knows ...)
> 
> Mine seems to need it - even with your patches applied init hangs pretty much immediately ( I used o32
binaries from releng ).
> I'll check what happens with n32 and -mfix-loongson2f-nop, a kernel built with this option hangs
immediately as well.

How does your CPU show up ?
Mine is:
cpu0 at mainbus0: 800.02MHz (hz cycles = 4000100, delay divisor = 400)
cpu0: ICT Loongson 2F CPU (0x6303) Rev. 0.3 with MIPS R4010 FPC Rev. 0.1
cpu0: 64 TLB entries, 1TB (40-bit) VAs, 1TB (40-bit) PAs, 16MB max page size
cpu0: 64KB/32B 4-way set-associative L1 instruction cache
cpu0: 64KB/32B 4-way set-associative write-back L1 data cache
cpu0: 512KB/32B 4-way set-associative write-back L2 unified cache
bonito0 at mainbus0: BONITO Memory and PCI controller, ASIC rev. 0.1

>  
> > loongson2 system use pmon as firmware (http://www.opsycon.se/PMON2000/Main).
> > The pmon version provided by lemote can load ELF files from ext2fs, fat or
> > iso9660; the partition table is fdisk-style (MSDOS).
(Continue reading)

Permalink | Reply | 4 comments |

Gmane