Re: Porting to my custom 030 board

[Jason Thorpe <thorpej%me.com@localhost>]

> On Oct 1, 2025, at 10:54 AM, Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost> wrote:
> 
> 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:
> 
> - physical memory mappings (especially whether VA==PA for RAMs)
> - how MMU should be set up (especially when VA != PA)
> - how devices (especially serial console device) should be mapped
>  (PTE via 030 MMU, or TT0/TT1 mappings)
> 
> - mvme68k, news68k, and x68k use PA==VA 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 != VA mappings, so it prepares a special page
>  where PA == 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
> 
> - mac68k is a bit difficult to read because it has many hacks
>  for Apple hardware (and MacOS Booter)
> 
> - 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/locore.s#L255-L261
>  https://github.com/NetBSD/src/blob/netbsd-11/sys/arch/luna68k/include/pmap.h
> 
> - 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_init.c#L198-L792
>   https://github.com/NetBSD/src/blob/netbsd-11/sys/arch/atari/atari/atari_init.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
> 
> - other NetBSD/m68k ports use 2-level MMU:
>  https://github.com/NetBSD/src/blob/netbsd-11/sys/arch/m68k/include/pmap_motorola.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
> 
> 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/locore.s#L118-L434

I've been trying to harmonize a bunch of that early startup code for the VA==PA 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
> 
> 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/locore.s#L83-L93
> 
> 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.
> 
> 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.
> 
> Good luck,
> ---
> Izumi Tsutsui

-- thorpej