Re: mips changes for loongson2

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Thu, Aug 25, 2011 at 08:25:45AM +1000, Simon Burge wrote:
> Manuel Bouyer wrote:
> 
> > Hello,
> > my work on getting the lemote fuloong working is almost ready to
> > be commited (it'll be another evbmips sub-port: evbmips/loongson,
> > which should also work on the lebote yeloong, the gdium and probably 
> > others).
> 
> Good to see it taking shape!
> 
> > This requires a few changes to some mips-specific files as in the attached
> > patches:
> > - bonito.diff:
> >   make the 'struct bonito_config' const, so that it can be in kernel
> >   text instead of data. This needs some __UNCONST() but I guess
> >   it's no big deal.
> >   Add a bc_attach_hook to struct bonito_config, to be used as pc_attach_hook
> >   if not NULL.
> >   Add some LS2-specific register defines (LS2f uses a modified bonito64).
> 
> This looks OK.  The lemote fuloong really uses a Bonito or some
> derivative thereof?

From what I understood, loongson2e based systems uses a real bonito64,
while loongson2f uses a derivative (which, if I understood it right,
is integrated to the CPU). 

> [...]
> > Index: include/cpuregs.h
> > ===================================================================
> > RCS file: /cvsroot/src/sys/arch/mips/include/cpuregs.h,v
> > retrieving revision 1.85
> > diff -u -p -u -r1.85 cpuregs.h
> > --- include/cpuregs.h       2 Aug 2011 05:12:32 -0000       1.85
> > +++ include/cpuregs.h       24 Aug 2011 17:21:23 -0000
> > @@ -1,6 +1,22 @@
> >  /* $NetBSD: cpuregs.h,v 1.85 2011/08/02 05:12:32 matt Exp $        */
> >  
> >  /*
> > + * Copyright (c) 2009 Miodrag Vallat.
> > + *
> > + * Permission to use, copy, modify, and distribute this software for any
> > + * purpose with or without fee is hereby granted, provided that the above
> > + * copyright notice and this permission notice appear in all copies.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> > + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> > + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> > + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> > + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> > + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> > + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> > + */
> > +
> > +/*
> 
> Does a couple of register definitions and macros need a new copyright
> section in this file?  There's been _many_ changes to this since
> the original without adding copyrights for each new CPU type we've
> supported.  I wouldn't include this.

If I did write theses I wouldn't have added or modififed copyrights.
But in this case, it a strait cut-n-paste from OpenBSD code, so I guess
the licence should be copyed too. But I'm not so familiar with these
problems.

> 
> > Index: include/vmparam.h
> > ===================================================================
> > RCS file: /cvsroot/src/sys/arch/mips/include/vmparam.h,v
> > retrieving revision 1.49
> > diff -u -p -u -r1.49 vmparam.h
> > --- include/vmparam.h       21 Jul 2011 23:03:39 -0000      1.49
> > +++ include/vmparam.h       24 Aug 2011 17:21:23 -0000
> > @@ -155,7 +155,11 @@
> >   */
> >  #define VM_MIN_ADDRESS             ((vaddr_t)0x00000000)
> >  #ifdef _LP64
> > +#if 0
> >  #define VM_MAXUSER_ADDRESS ((vaddr_t) 1L << (4*PGSHIFT-8))
> > +#else
> > +#define VM_MAXUSER_ADDRESS ((vaddr_t) 1L << (40))
> > +#endif
> 
> Can the "40" be described in terms of any existing (or new) constants?
> If not, could you please add a comment on how the 40 was derived?  Also,
> I'd not leave the "#if 0" block in - cvs will keep the history.

This has already been fixed by matt@

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--