On Thu, 30 May 2002, kevin neff wrote:

> hello!
>
> i'm an EE student at the university of wisconsin, platteville campus.  and for
> some time i have been considering a multiple processor system for a final
> project.  sadly, it seems impossible to create hardware without also creating
> a HUGE software problem.  however, if netbsd could be made to run on a
> system with only a reasonable amount of pain and not too much re-inventing, the
> project could be general enough to be useful and i could continue attending
> classes instead of coding :)

Sounds reasonable.

> there are a few questions that arise; here they are.  the first set of questions
> involve the feasibility of the project, the second set pertains to the general
> idea of porting an OS.
>
>   + does the processor need be 32-bit?  is this simply for the convenience
>     of memory addressing?  does the idea of using multiple 8-bit processors
>     instead of their more expensive counterparts make you laugh?  if so, why?

It doesn't make me laugh, but I don't think it's very feasable.

First reason is memory. The 8-bit CPUs I remember working with had at best
a 16-bit address space. While we do try to continue to support
small-memeory systems, "small" is around 4 MB. I doubt you could fit a
kernel and any user programs into 16k.

The second is:

>   + is a mmu absolutely essential?  is virtual memory essential?

Yes.

The kernel uses VM to do a whole lot of things, and it's not really
something NetBSD can do without.

So I'd suggest looking at the "16-bit" CPUs at a minimum. They tended to
all have MMUs available.

>   + how do i get started with a port?  are there some general guidelines?

Not sure.

>   + roughly, how many hours/days/months/years does an average port require?

That would depend on what CPU you choose.

First thing you will need is GCC/binutils support. If you can choose a CPU
already supported, you're much better off. Porting GCC & binutils to a new
CPU could be a (probably booring) project in and of itself.

Second, you'll have to port NetBSD to the CPU, and then to the hardware
you have. Choosing something like an ARM, MIPS, PowerPC, or SH core would
help, in that NetBSD's been ported to those CPUs (see sys/arch/{those
cpus}).

Finally you'll have to get MP running on said CPU/system.

> well, there it is.  thank you for your time.  i'll be looking forward to hearing
> from you!

I think your project is more ambitious than you envisioned. :-)

I would suggest cutting out some of the steps. For instance getting SMP
working on a CPU family it doesn't work on could well be a final project.
Or getting NetBSD working on a CPU it doesn't work on now. :-)

One option for the low-budget side of things would be to look at
www.opencores.org, where there are a number of open-source CPU cores
available. I think some have MMUs. It looks like the OpenRISC 1000
supports MMUs, though I'm not sure if it supports SMP instructions (*).

Take care,

Bill

(*) By "SMP instructions" I mean instructions you'd use to implement
atomic memory access. The 68k family for instance had the TAS instruction,
which used a special read-modify-write memory access. Most RISC CPUs have
instructions that do special loads & stores. The difference is that after
the load happens, if another CPU (or DMA engine) writes that memory
address, the store fails. These instructions use the fact that the cache
controllers have to snoop the bus to make things work right with multiple
bus masters anyway.