Re: Porting to my custom 030 board

> On Oct 1, 2025, at 10:54=E2=80=AFAM, Izumi Tsutsui =
<[email protected]> wrote:
>=20
> 680x0 has so flexible MMU settings that it's a bit hard to see how
> differences are handled among all ports, but we have to check the
> following points:
>=20
> - physical memory mappings (especially whether VA=3D=3DPA for RAMs)
> - how MMU should be set up (especially when VA !=3D PA)
> - how devices (especially serial console device) should be mapped
>  (PTE via 030 MMU, or TT0/TT1 mappings)
>=20
> - mvme68k, news68k, and x68k use PA=3D=3DVA mappings (i.e. RAM starts =
at 0x0)

Add virt68k to that list.  (My homebrew does the same, but it has RAM in =
2 locations -- DRAM at $0000.0000 and a 4MB block of fast SRAM at =
$FE00.0000, and the system controller only maps the boot ROM at =
$0000.0000 for the first 4 bus cycles after a reset.)

> - hp300 has a bit weird PA !=3D VA mappings, so it prepares a special =
page
>  where PA =3D=3D VA to turn MMU on:
>   https://mail-index.netbsd.org/tech-kern/1999/05/26/0015.html

hp300 is very weird in this regard, indeed.  The start of physical RAM =
varies based on the RAM size, and it always ends at the end of the =
physical address space.  I guess it was easiest to just leave the boot =
ROM always mapped at $0000.0000?

> - next68k has RAM from 0x40000000 so it uses temporary TT0/TT1 =
mappings
>  to turn MMU on
> - x68k has optional "extended memory" mapped at PA >0x01000000 so
>  initialization is a bit complicated:
> =
https://github.com/NetBSD/src/blob/netbsd-11/sys/arch/x68k/x68k/machdep.c#=
L1069-L1083
>=20
> - mac68k is a bit difficult to read because it has many hacks
>  for Apple hardware (and MacOS Booter)
>=20
> - cesfic may be a similar port as a simple embeded board, but it has
>  many leftover lines in various sources taken from hp300

Yes, cesfic could use quite a bit of cleanup, and should probably not be =
used as an example.

> - luna68k uses TT0/TT1 to map sparse device space =
(0x40000000-0xFFFFFFFF):
>  =
https://github.com/NetBSD/src/blob/netbsd-11/sys/arch/luna68k/luna68k/loco=
re.s#L255-L261
>  =
https://github.com/NetBSD/src/blob/netbsd-11/sys/arch/luna68k/include/pmap=
.h
>=20
> - amiga and atari have a bit different initialization functions due to
>  historical reasons
>  (though they use a common "4.4BSD/hp300 derived" pmap:
>   =
https://github.com/NetBSD/src/blob/netbsd-11/sys/arch/amiga/amiga/amiga_in=
it.c#L198-L792
>   =
https://github.com/NetBSD/src/blob/netbsd-11/sys/arch/atari/atari/atari_in=
it.c#L197-L691

The Amiga and Atari ports also have their own flavor of some 68040 and =
68060 trap handling.  This is because the Amiga port grew its own 68040 =
code before the hp300 port got it from Hibler via a 4.4BSDLite update.

> - sun68k (sun3 and sun3x) uses completely different MMU settings
> - sun3 uses Sun specific MMU, and sun3x uses full 3-level 030 MMU
>=20
> - other NetBSD/m68k ports use 2-level MMU:
>  =
https://github.com/NetBSD/src/blob/netbsd-11/sys/arch/m68k/include/pmap_mo=
torola.h#L115-L138
> - NetBSD/m68k uses "incomplete (or faked)" 3-level MMU for 040/060
>   (use one page for first and second level tables; see =
pmap_bootstrap.c)

The reason the shared pmap (a.k.a. the "Hibler" pmap) forces the 2-level =
system is to accommodate the HP MMU found on the 9000/320 and 9000/350.  =
It's essentially a crippled 68851 clone and only does 2-level tables and =
doesn't support some of the other 68851 features.

That said, for 68020 / 68030, the Hibler pmap is fine, and the most =
annoying bit is having to craft up a pmap_boostrap() routine.  99.7% of =
it will be more-or-less the same as some other port's, but figuring out =
that last 0.3% tweak was honestly the single most difficult task of the =
virt68k port.

> - you also have to prepare kernel config files under
>  sys/arch/${MACHINE}/conf, but maybe we can copy from the similar port
>=20
> Anyway, we should check "start" function in locore.s to see
> how early bootstrap initialization should be done:
> =
https://github.com/NetBSD/src/blob/netbsd-11/sys/arch/news68k/news68k/loco=
re.s#L118-L434

I've been trying to harmonize a bunch of that early startup code for the =
VA=3D=3DPA platforms, but there's still a little ways to go.

> Next, we have to check pmap_bootstrap.c (called during the above =
"start")
> to set up segment tables and page tables for kernel, RAM, and devices =
etc.
> =
https://github.com/NetBSD/src/blob/netbsd-11/sys/arch/news68k/news68k/pmap=
_bootstrap.c
>=20
> It's a bit annoying to set up serial console before MMU turned on,
> but if your board has debug LEDs mapped somewhere we can use it for =
debug:
> =
https://github.com/NetBSD/src/blob/netbsd-11/sys/arch/news68k/news68k/loco=
re.s#L83-L93
>=20
> Note the most important thing is "how to load your custom kernel =
binary
> into the memory" and "how to jump to the loaded kernel."
> Maybe you can use "objcopy -O binary" to get a raw kernel binary,
> but it depends on your board firmware features.
>=20
> I started porting NetBSD/news68k around 19990506, and got
> a linked kernel on 19990530, then "kernel printf(9)" via
> serial console worked (using NEWS-OS bootloader) on 19990603.
>=20
> Good luck,
> ---
> Izumi Tsutsui

-- thorpej