Subject: Re: netbsd/arcalpha possibility?
To: None <email@example.com, firstname.lastname@example.org>
From: R.o.s.s H.a.r.v.e.y <email@example.com>
Date: 12/19/2001 12:27:42
> ... what would be involved? [ to port netbsd/alpha to arc/alphabios boxes ]
It's a lot of low-level work just to run on one or two old machines
where the only product differentiation is lack of SRM. (I.e., we run
on almost identical HW models that have SRM, and which people can
While linux does run on the XL and on a couple of other ARC systems,
on most models linux requires SRM just like we do.
But, to answer your question, there are several different approaches:
1. Write a replacement console containing the old distributable
palcode and boot that via ARC, then NetBSD via the replacement
console. This is what linux did. I tried this once and got
NetBSD limping along with lots of phony SIGBUS events due
apparently to palcode bugs. (The free palcode isn't the
"real" palcode, but a simplified gnu-toolchain-converted
snapshot of an early version of the real thing.) I'm sure
the problems were fixable, tho I never did so because at
that point DEC gave the corp I was working for the real
palcode, solving the problem. Linux didn't seem to work
the palcode as hard, or had workarounds, so it was made to
run successfully on the bogus palcode. Since then, NetBSD/alpha
has a new pmap, so perhaps the old problems are gone. (Or
are worse. :-)
The easy way to approach this is to just add FFS support from
our libsa to MILO.
2. Boot directly off of ARC, and modify NetBSD to run on bare
hardware instead of on top of the OSF/1 palcode.
3. Like 2, but throw the free palcode into locore.s.
ARC documentation and an ARC development kit used to be freely distributed,
so you could probably track a copy down. It is M$-windows-based and requires
buying some M$ tools. You probably don't need that just to hack on MILO.
I'm pretty sure that the current NetBSD developers won't ever decide
to work on this, since the payoff is kind of small for the effort required.