Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

1 view
Skip to first unread message

Matt Thomas

unread,
Jan 4, 2011, 5:50:20 AM1/4/11
to

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

> On Tue, Jan 4, 2011 at 11:42 AM, Matt Thomas <ma...@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.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de

Simon Burge

unread,
Jan 4, 2011, 5:57:56 AM1/4/11
to
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.

Matt Thomas

unread,
Jan 4, 2011, 6:13:26 AM1/4/11
to

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.

Matt Thomas

unread,
Jan 4, 2011, 6:15:48 AM1/4/11
to

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.

Mindaugas Rasiukevicius

unread,
Jan 4, 2011, 7:41:27 AM1/4/11
to
Matt Thomas <ma...@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

Michael

unread,
Jan 4, 2011, 8:30:47 AM1/4/11
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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@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
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBTSMhB8pnzkX8Yg2nAQJJVwgAkKtb6ptHhyIBUtwbvzCtQYSpTLLaB0rs
nDBfe9t0KlX6j92MxPOII2M5gQ/KZYK5ocSbVy/3lbz/SOfRxaydzQZJQ8GpMB6y
P2GWhBvW10H3Zz0fo27zOVN0xL9mBk/W7T7GyA3AuuQQo5WjKVyZba82z3I6hL6+
Yj727baUVr71ibb/wjgDKbSq4FmUX1jJJN5r+vsnPjYm82zKUqLZ3P7P6s7ux8dZ
SnTE6yd8hVYiEGiLlHMhr9r80zHYdJtOG4yugDN58LwEqmAM547Ad4Tz/exSLrZX
NFoZqpcpxlLMA4ahNrCQBKBX00HlKPr9IJyJC8R2NeXSpAS/dqCORQ==
=Ftgt
-----END PGP SIGNATURE-----

Michael

unread,
Jan 4, 2011, 8:31:48 AM1/4/11
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBTSMhRcpnzkX8Yg2nAQJ1MQf8DfmHxOR2i6N1QELYoPpk+M/D5BK/c78z
+JtCNU+27T3lfHq0sKerfPrmqLWxq1MKTyvs4ku9RqTTtXFDlCK8zy8VzswESTnQ
0PQmMZ2G7Yq9SV11l/Eu4ofm/AR1V9s6cdIqcgZaegGNsNCCEJXvUGlgkgCNJnyZ
hqWXGf8x8Exr7CZKiWNDTluneFMCsUNbNfUMmG0wyKNBKyRqRVemojuGPZY+oFdR
gJi5mFP+H00io4z4lc+z0l4L+z0usbKyyGp5qH3Klk47rh9SE2P/1twxemEKjD9D
kFQFk/So/bBzmN0v7p0lVFDs3FNhoZPnruA+RQcNHb4dTegWbm+nbA==
=kMAX
-----END PGP SIGNATURE-----

0 new messages