Discussion of issues relevant to all MIPS-based NetBSD ports

Manuel Bouyer | 24 Aug 2011 19:42

mips changes for loongson2

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).

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).

- mips.diff:
  add some LS2F specific defines to cpuregs.h
  Fix a bug with VM_MAXUSER_ADDRESS and 16k pages (VM_MAXUSER_ADDRESS
  doens't change with page size ...)
  Hack some assembly files for LS2 branch prediction bug workaround on
  j(r) reg, as already discussed here (basically, the assembler needs to
  be able to use at register when it runs into a j register instruction).
  LS2-specific tlbmiss handler (ls2 doesn't have a separate handler for
  64bit addresses)
  Fixes for some #ifdef MIPS3_LOONGSON2 assembly code (using the wrong
  register).
  mips_fixup.c: add code to handle the instructions added by
  -fix-loongson2-btb
- common.diff:
  Hack some assembly files for LS2 branch prediction bug workaround on

(Continue reading)

headers

Simon Burge | 25 Aug 2011 00:25

Re: mips changes for loongson2

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?

> - mips.diff:
>   add some LS2F specific defines to cpuregs.h
>   Fix a bug with VM_MAXUSER_ADDRESS and 16k pages (VM_MAXUSER_ADDRESS
>   doens't change with page size ...)
>   Hack some assembly files for LS2 branch prediction bug workaround on
>   j(r) reg, as already discussed here (basically, the assembler needs to
>   be able to use at register when it runs into a j register instruction).
>   LS2-specific tlbmiss handler (ls2 doesn't have a separate handler for

(Continue reading)

headers

Matt Thomas | 25 Aug 2011 06:05

Re: mips changes for loongson2


On Aug 24, 2011, at 3:25 PM, 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?

Yes it does.

>> Index: include/vmparam.h
>> ===================================================================
>> RCS file: /cvsroot/src/sys/arch/mips/include/vmparam.h,v

(Continue reading)

headers

Manuel Bouyer | 25 Aug 2011 12:05

Re: mips changes for loongson2

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
> > ===================================================================

(Continue reading)

headers

Matt Thomas | 25 Aug 2011 06:03

Re: mips changes for loongson2


On Aug 24, 2011, at 10:42 AM, 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).
> 
> 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).
> 
> - mips.diff:
>  add some LS2F specific defines to cpuregs.h
>  Fix a bug with VM_MAXUSER_ADDRESS and 16k pages (VM_MAXUSER_ADDRESS
>  doens't change with page size …)

Done differently.