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