Date: Sat, 2 May 2015 13:49:16 +0000
From: Miod Vallat
To: Michael McConville
Subject: Re: OpenBSD MIPS32 Support

Hello,

> I noticed that your commits on 10 Mar 2014 and 11 Mar 2014 removed
> support for MIPS32 because it was a largely unused ISA. However, the
> Creator CI20 and a bunch of other MIPS32 products are coming out now
> that Imagination Technologies is trying to revive the MIPS ecosystem.
> 
> I'm about to attempt a port to the CI20 as a final project for a
> computer architecture course. Would you consider, if the port succeeds,
> replacing support for MIPS32? I can't guarantee how far I'm going to get
> because I don't have much experience. It seems like an interesting
> project, though, and NetBSD already has the CI20 booting into userland,
> so there's code to work from.

There is absolutely zero interest in getting a MIPS32 port for OpenBSD.

Supporting MIPS in 32-bit mode is just a waste of time - especially if
your hardware is expected to support more than 512MB of physical memory.

Regards,
Miod


Date: Sat, 2 May 2015 20:11:52 +0000
From: Miod Vallat
To: Michael McConville
Subject: Re: OpenBSD MIPS32 Support

> Fair enough. If you have the time, could you clarify a little more why
> you think it's a waste of time?

An important feature of MIPS processors is the ability, in kernel mode,
to have a part of the address space be directly translated; this allows
the kernel to have a direct view of any part of the physical address
space, without the need to create and maintain TLB entries. This is used
a lot by the BSD kernels in order to use faster memory management
routines.

On a 32-bit MIPS processor, that directly translated area will only span
512MB. If you have more than 512MB of physical memory, then the
assumption that the kernel can map any physical address without
involving the TLB no longer stands; this is why the high-end MIPS
designs of the '90s (such as the DECstation 5000/240) did not accept
more than 512MB of physical memory.

On a 64-bit MIPS processor, the virtual address space is several times
larger than the physical address space. The kernel can directly map any
physical memory or device memory address, with different cacheability
attributes, for free. This makes writing kernel code for a 64-bit MIPS
system much easier, and the code runs faster as it reduces kernel
pressure on the TLB.

In the year 2015, it is a complete nonsense to produce new 32-bit system
designs. It's the new ``640KB of memory will be enough for everybody''.

> Also, would it change your mind if Google starting releasing 32-bit
> MIPS Chromebooks?

Of course not. They can release crap hardware if they want to, this
doesn't mean we have to support it.

Miod