Re: Porting to my custom 030 board

Chris Hanson <[email protected]> Tue, 30 Sep 2025 16:58:50 -0700
Newsgroups gmane.os.netbsd.ports.m68k
Message-ID <[email protected]>
On Feb 25, 2025, at 2:49=E2=80=AFAM, Lawrence Manning =
<[email protected]> wrote:
>=20
> The amount
> of repetition across sys/arch generally is surprising and
> disapointing. Likewise the lack of a clear hierarchy from processor
> architecture down to board or "computer type" is also surprising. I'm
> sure it's all done for logical reasons, but the barrier is
> surprisingly high, for me.

To resurrect this old thread, I think what's making it a little more =
confusing than it needs to be is your expectation that there's a =
hierarchy from processor architecture to machine. While it's unfortunate =
that they're mixed together under sys/arch, in NetBSD the processor =
architecture and machine are really fairly orthogonal: For the most part =
the code that's used for interfacing with a specific peripheral is the =
same across machines, and the code that's used for dealing with specific =
processor architecture is also the same across machines, and in both =
cases they're at least partially if not mostly de-duplicated.

There has also been a lot more work done in the past couple years, =
including a bunch after your post, to further consolidate code including =
for the 68K architecture. If you look now at the NetBSD 11 branch you =
should hopefully see a lot less duplication than in the NetBSD 10 =
branch, and less still in trunk. Also, some of what looks like =
duplication may actually be indirection, where there's a driver with a =
common name that handles the slight differences between machines that =
use the same peripherals, but mostly calls through to that peripheral's =
driver. (No doubt there's more deduplication to be done in that area =
too.)

For your specific board, you should be able to make use of mostly =
generic drivers and mostly generic 68030 processor support; the contents =
of your specific sys/arch/maxi030 machine's directory should be almost =
as thin as they are for (say) sys/arch/virt68k, and should mostly =
involve what's needed to glue the busses together and declare the =
addresses of the peripherals.

  -- Chris