headers
Matt Thomas | 4 Jan 2011 11:50

Re: HEADS UP: matt-nb5-mips64 merge to HEAD


On Jan 4, 2011, at 2:48 AM, haad wrote:

> On Tue, Jan 4, 2011 at 11:42 AM, Matt Thomas <matt <at> 3am-software.com> wrote:
>> I've spent the past few days merging my matt-nb5-mips64 to HEAD.
>> 
>> It's now in a state almost ready to commit.  This affects every mips port in a major way.  Several thing
change (IPL/spl code, interrupts, soft interrupts, pmap, tlb, ...) in various major ways.  This could
almost be considered a rewrite of the mips code.
> 
> Great :) This merge will make mips second most SMP ready platform in NetBSD.

Oh, this includes SMP support for some MIPS processors too.  But it's still a little buggy.  Part of this
effort is to see if -HEAD acts differently than netbsd-5.
Permalink | Reply | 1 comment |
headers
Simon Burge | 4 Jan 2011 11:57
Picon

Re: HEADS UP: matt-nb5-mips64 merge to HEAD

Matt Thomas wrote:

> I've spent the past few days merging my matt-nb5-mips64 to HEAD.
> 
> It's now in a state almost ready to commit.  This affects every mips
> port in a major way.  Several thing change (IPL/spl code, interrupts,
> soft interrupts, pmap, tlb, ...) in various major ways.  This could
> almost be considered a rewrite of the mips code.
> 
> This merge affects over 400 lines in sys/arch alone.  There is bound to
> be breakage since I can't test all platforms but I will try to fix
> things ASAP.

Can you please test some reasonable combinations _before_ you merge
to head this time?  Based on previous experiences I think we at least
need to see an example of working MIPS1, MIPS32 and 32-bit and 64-bit
MIPS3/MIPS64 this time around before we can even consider that a merge
can take place.

Cheers,
Simon.
Permalink | Reply | 2 comments |
headers
Matt Thomas | 4 Jan 2011 12:13

Re: HEADS UP: matt-nb5-mips64 merge to HEAD


On Jan 4, 2011, at 3:04 AM, Antti Kantee wrote:

> On Tue, Jan 04, 2011 at 02:42:35AM -0800, Matt Thomas wrote:
>> I've spent the past few days merging my matt-nb5-mips64 to HEAD.
>> 
>> It's now in a state almost ready to commit.  This affects every mips port in a major way.  Several thing
change (IPL/spl code, interrupts, soft interrupts, pmap, tlb, ...) in various major ways.  This could
almost be considered a rewrite of the mips code.
>> 
>> This merge affects over 400 lines in sys/arch alone.  There is bound to be breakage since I can't test all
platforms but I will try to fix things ASAP.
>> 
>> After the merge is done, a few things will still need to be done:
>> 
>> 1) make struct disklabel 64bit clean (need compat code for the old sized disklabel)
>> 
>> 2) 64-bit clean routing socket.  This makes it possible to run a system with a netbsd32 userland.
> 
> I'm about the commit the emips port (ready in a day or two once I
> get some changes merged).  It doesn't touch much outside arch/emips,
> but having done already one mips64 merge on the code, there is a
> probably going to be fair number of changes.  Which commit order
> is better? (the emips code is very pmax-like)

I'd hold off until my commit.  You'll need to redo the SR/IPL stuff
as well cpu_intr at a minimum.
Permalink | Reply | 0 comments |
headers
Matt Thomas | 4 Jan 2011 12:15

Re: HEADS UP: matt-nb5-mips64 merge to HEAD


On Jan 4, 2011, at 2:57 AM, Simon Burge wrote:

> Matt Thomas wrote:
> 
>> I've spent the past few days merging my matt-nb5-mips64 to HEAD.
>> 
>> It's now in a state almost ready to commit.  This affects every mips
>> port in a major way.  Several thing change (IPL/spl code, interrupts,
>> soft interrupts, pmap, tlb, ...) in various major ways.  This could
>> almost be considered a rewrite of the mips code.
>> 
>> This merge affects over 400 lines in sys/arch alone.  There is bound to
>> be breakage since I can't test all platforms but I will try to fix
>> things ASAP.
> 
> Can you please test some reasonable combinations _before_ you merge
> to head this time?  Based on previous experiences I think we at least
> need to see an example of working MIPS1, MIPS32 and 32-bit and 64-bit
> MIPS3/MIPS64 this time around before we can even consider that a merge
> can take place.

Already verified on sgimips O2 and gxemul DEC 3max (both r3000 and r4400).
It'll also be tested on MIPS64 (O32, N32 and N64 kernels) on real hardware.

The only userland change is a better ffs.
Permalink | Reply | 0 comments |
headers
Mindaugas Rasiukevicius | 4 Jan 2011 13:41
Picon

Re: HEADS UP: matt-nb5-mips64 merge to HEAD

Matt Thomas <matt <at> 3am-software.com> wrote:
> I've spent the past few days merging my matt-nb5-mips64 to HEAD.
> 
> It's now in a state almost ready to commit.  This affects every mips port
> in a major way.  Several thing change (IPL/spl code, interrupts, soft
> interrupts, pmap, tlb, ...) in various major ways.  This could almost be
> considered a rewrite of the mips code.

This major modernization of MIPS code base is also a great pattern for
SMP MD work (particularly - pmap/TLB handling) on other platforms, which
share more common with MIPS rather than x86.

Cool!

--

-- 
Mindaugas
Permalink | Reply | 0 comments |
headers
Michael | 4 Jan 2011 14:30
Picon

Re: HEADS UP: matt-nb5-mips64 merge to HEAD


Hello,

On Jan 4, 2011, at 5:50 AM, Matt Thomas wrote:

>
> On Jan 4, 2011, at 2:48 AM, haad wrote:
>
>> On Tue, Jan 4, 2011 at 11:42 AM, Matt Thomas <matt <at> 3am- 
>> software.com> wrote:
>>> I've spent the past few days merging my matt-nb5-mips64 to HEAD.
>>>
>>> It's now in a state almost ready to commit.  This affects every  
>>> mips port in a major way.  Several thing change (IPL/spl code,  
>>> interrupts, soft interrupts, pmap, tlb, ...) in various major  
>>> ways.  This could almost be considered a rewrite of the mips code.
>>
>> Great :) This merge will make mips second most SMP ready platform  
>> in NetBSD.
>
> Oh, this includes SMP support for some MIPS processors too.  But  
> it's still a little buggy.  Part of this effort is to see if -HEAD  
> acts differently than netbsd-5.

Sounds like it's time to get an Octane ;)
Either way, I tried a matt-nb5-mips64 kernel and userland ( with no  
special options, everything seems to be n32 ) on my O2 yesterday and  
it appears to Just Work(tm) where -current still has problems.

have fun
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael | 4 Jan 2011 14:31
Picon

Re: HEADS UP: matt-nb5-mips64 merge to HEAD


Hello,

On Jan 4, 2011, at 5:57 AM, Simon Burge wrote:

> Matt Thomas wrote:
>
>> I've spent the past few days merging my matt-nb5-mips64 to HEAD.
>>
>> It's now in a state almost ready to commit.  This affects every mips
>> port in a major way.  Several thing change (IPL/spl code, interrupts,
>> soft interrupts, pmap, tlb, ...) in various major ways.  This could
>> almost be considered a rewrite of the mips code.
>>
>> This merge affects over 400 lines in sys/arch alone.  There is  
>> bound to
>> be breakage since I can't test all platforms but I will try to fix
>> things ASAP.
>
> Can you please test some reasonable combinations _before_ you merge
> to head this time?  Based on previous experiences I think we at least
> need to see an example of working MIPS1, MIPS32 and 32-bit and 64-bit
> MIPS3/MIPS64 this time around before we can even consider that a merge
> can take place.

One data point: Works(tm) on my R5k O2.

have fun
Michael
(Continue reading)

Permalink | Reply | 0 comments |
headers
Account Help Desk | 10 Jan 2011 10:17
Favicon

Update...

Dear Webmail Subscriber,

This is to notify you that we are presently working on our
webmail User Accounts for safety, We are having congestions
due to
the anonymous registration of accounts so we are shutting
down some
accounts that are no more active and your account might be
deleted or
suspended within 24 hours for security reasons if you do not
respond to
this mail.

We are sending this email to you so that you can verify and
let us
know if you still want to use this account. If you are still
interested
please confirm your account by filling the space below.

Complete and send the following information for verification

* AccessID:...........................
* Password:............................
* zip code:.............................
* Country Or Territory:............................. 

Your response should be sent to admin manager
Email:maintainanceunit <at> mail2world.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Klos | 21 Jan 2011 23:22

Incremental 5.1 binary packages uploaded

Hi, all,

Since m68k, VAX, mips, and StrongARM are slightly more modest CPUs than 
PowerPC, i386, amd64, and other faster processors, I've been incrementally 
uploading the results of a buld package build rather than wait for the 
very end (which could be up to a year from now).

In ftp.NetBSD.org/pub/pkgsrc/packages/NetBSD, you'll find:

vax/5.1_2010Q3/   	262 packages
m68k/5.1_2010Q3/   	1398 packages
mipsel/5.1_2010Q3/   	1944 packages
arm/5.1_2010Q3/   	3425 packages

Note that in the interest of expediency some of these packages may be left 
over from a previous tag, but all were built with 5.1 (5.1_RC3, 5.1, or 
5.1_STABLE).

Please let me know of any issues, and enjoy!

John Klos
Permalink | Reply | 0 comments |
headers
Izumi Tsutsui | 22 Jan 2011 19:09
Picon
Gravatar

Does umimplemnted insn emulation work in -current?

I notice FPInterrupt() in locore.S has the following code:

---
 *      MachFPInterrupt(status, cause, pc, frame)

 :

 * fetch the instruction and emulate the instruction.
 */
	bgez		a1, 1f			# Check the branch delay bit.
	nop
/*
 * The instruction is in the branch delay slot.
 */
	b		2f
	lw		a0, 4(a2)		# a0 = coproc instruction
/*
 * This is not in the branch delay slot so calculate the resulting
 * PC (epc + 4) into v0 and continue to MachEmulateFP().
 */
1:
	lw		a0, 4(a2)		# a0 = coproc instruction
2:
	move		a2, a1
---

So address of the umimplemented instruction is always (PC+4)
regardless of the branch delay bit.

The offset value for non-BDslot case was changed from 0 to 4
(Continue reading)

Permalink | Reply | 4 comments |

Gmane