Re: mac68k built-in video (PR#58164)

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

(Cc'ed to port-m68k@, and drop tech-toolchain@)

> I also tried a few later kernels (8.0 and 8.3) that seem to crash in the
> same way as the 9.x and 10.0 installation kernels.
> 
> For Nubus video to work, NetBSD would have to act like MacOS; i.e. after
> confirming that the system is a IIci (or IIsi), then check to see if
> there is a monitor attached to RBV. If there is not, then treat the
> system just like any other Mac II (i.e. use Nubus video and all of the
> memory in Banks A and B is available). If there is a monitor attached to
> RBV, then allow for internal video as well as Nubus video, and ignore
> all of the memory in Bank A (or the first 1 MiB if Bank A has more than
> 1 MiB).


# 0) Disclaimer

- I have a certain experience of NetBSD/m68k pmap (i.e. machine
  dependent part of virtual memory system) derived from 4.4BSD/hp300
  implementation, but have quite few knowledge about 68K Mac specific
  hardware design or NetBSD/mac68k specific implementation etc.


# 1) Background of NetBSD/m68k pmap

- Modern(?) RISC CPUs (like MIPS, ARM, SuperH etc.) have address
  spaces that provide 1:1 mapping for physicall address (PA) and
  virtual address (VA). In most cases NetBSD kernel itself is
  allocated at such fixed mapping pages to make things easier.

- On the other hand, m68k MMU is so flexible and there is no fixed
  PA:VA mappings in its address space.
  (Transparent Translation (TT) registers provide such functionality
   but they are not available on all 68k variants, i.e. we still
   tries to support 68020 and 68851)

- To map physical address spaces where the kernel is loaded to
  proper virtual address spaces, a "bootstrap routine" has to
  set up whole MMU settings (like segment table entries and
  page table entries) manually, and on NetBSD/m68k, the machine
  dependent "pmap_bootstrap()" function handles it:
   https://github.com/NetBSD/src/blob/d1f43e70/sys/arch/mac68k/mac68k/pmap_bootstrap.c#L192-L477

- If all physical address spaces (i.e. memory address locations of RAMs)
  are contiguous, it might be easier to setup MMUs.
  (hp300, luna68k, news68 etc.)

- On the other hand, if the physcall address spaces are not contiguous
  and the first region doesn't have enough space to map kernel itself
  and necessary segment/page tables, we need more considerations.
  (amiga, atari, mvme68k, x68k etc.)


# 2) mac68k specific implementation and restrictions

- I'm not sure what the exact panic message was in the PR/58164 case,
  but "panic: Cannot work with the current memory mappings."
  in your message in this early thread is comes from:
   https://github.com/NetBSD/src/blob/d1f43e70/sys/arch/mac68k/mac68k/pmap_bootstrap.c#L189
```
	for (i = 0; i < numranges; i++)
		if (low[i] <= firstpa && firstpa < high[i])
			break;
	if (i >= numranges || nextpa > high[i]) {
		if (mac68k_machine.do_graybars) {
 /* [snip] */
		}
		panic("Cannot work with the current memory mappings.");
	}
```

- "low[]" and "high[]" arrays seem calculated in get_mapping()
  function in src/sys/arch/mac68k/mac68k/machdep.c:
   https://github.com/NetBSD/src/blob/d1f43e70/sys/arch/mac68k/mac68k/machdep.c#L2349-L2435

- The get_mapping() function calls "get_physical()" function.
  The get_physical() seems to check MMU settings, so this implies
  MacOS where Booter is invoked might setup some MMU settings and
  enables MMU before booting NetBSD?

- The get_mapping() also checks PA of internal video etc. but
  it's a bit hard to understand them without knowledge of mac68k
  hardware specification..

- Nevertheless, it looks low[] and high[] arrays represent
  "physical memory address range" i.e. RAM banks. I'm not sure
  actual range values, but maybe the first bank RAM region is
  from low[0] to high[0], and the second bank RAM region is
  from low[1] to high[1].

- The panic "Cannot work with the current memory mappings." is
  triggered in "(i >= numranges || nextpa > high[i])" case
  in pmap_bootstrap(), as mentioned above.

- "i" is a RAM region where the "firstpa" physical address is.
  "firstpa" is a physical address where the kernel is loaded.
  (passed from early asm code in src/sys/arch/mac68k/mac68k/locore.s)
  Then the kernel is loaded in the region between low[i] and high[i]
  here.

- "numranges" is calculated in get_mapping() in machdep.c and
  it looks "how many contiguous physical RAM banks the machine has"
  or so.

- "nextpa" is a physical address that will be occupied by the
  loaded kernel itself and all necessary segment table entries
  and page table entries etc.

Then the panic is triggered in the following cases:
 - "i >= numranges" means "no valid RAM region where the kernel is loaded"
  -> I guess this is unlikely
 - "nextpa > high[i]" means "not enough size to allocate both kernel
    itself and necessary segment tables and page tables etc."
  -> This could happen in other m68k ports


# 3) How to debug / solve the issue

- According to the above assumption, the first RAM region
  (or RAM regions where Booter loads the target kernel)
  should be large enough.

- If RBV (RAM based video) occupies the same RAM region
  (i.e. RAM bank) where kernel is loaded, it could also be
  problematic. If RBV address space (or kernel loading address)
  can be configured in Booter, it could help to solve the problem.

- The other possible solution is move the loaded kernel into
  another RAM region that has enough contiguous space.
 - NetBSD/atari has such code to transfer loaded kernel
   (where 16 bit slow RAM) to faster 32 bit RAM:
     https://github.com/NetBSD/src/blob/da89b8c1/sys/arch/atari/atari/atari_init.c#L607-L620
   but this requires more complicated STE/PTE settings:
    https://mail-index.netbsd.org/port-atari/2008/12/30/msg000179.html

- machdep.c and pmap_bootstrap.c has the following debug printf()s
  that are enabled by "mac68k_machine.do_graybars":
   https://github.com/NetBSD/src/blob/d1f43e70/sys/arch/mac68k/mac68k/machdep.c#L2371-L2372

```
	if (mac68k_machine.do_graybars)
		printf("Loaded at 0x%0lx\n", load_addr);
```

  I'm not sure where "do_graybars" comes from, but maybe
  it can be specified by Booter optoins?

   https://github.com/NetBSD/src/blob/d1f43e70/sys/arch/mac68k/mac68k/machdep.c#L905-L915
```
	/*
	 * More misc stuff from booter.
	 */
	mac68k_machine.machineid = machineid = getenv("MACHINEID");
	mac68k_machine.mach_processor = getenv("PROCESSOR");
#ifndef MAC68K_MEMSIZE
	mac68k_machine.mach_memsize = getenv("MEMSIZE");
#else
	mac68k_machine.mach_memsize = MAC68K_MEMSIZE;
#endif
	mac68k_machine.do_graybars = getenv("GRAYBARS");
```

Any further comments (especially Mac gurus) and debug info
(by the above graybars etc.) are appreciated.

Thanks,
---
Izumi Tsutsui