Re: port-macppc/58320: NetBSD/macppc 10.0 INSTALL kernel stalls onPower Mac G4

["Izumi Tsutsui via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR port-macppc/58320; it has been noted by GNATS.

From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: tsutsui%ceres.dti.ne.jp@localhost
Subject: Re: port-macppc/58320: NetBSD/macppc 10.0 INSTALL kernel stalls onPower
	 Mac G4
Date: Sat, 3 May 2025 09:55:58 +0900

 macallan@ wrote:
 
 >  On Mon, 28 Apr 2025 19:50:02 +0000 (UTC)
 >  "Izumi Tsutsui via gnats" <gnats-admin%NetBSD.org@localhost> wrote:
 >  
 >  >  1) disable "have_palette" in macppc/machdep.c:copy_disp_props()
 >  >     in case of PCI framebuffers that don't require genfb(4) in GENERIC
 >  >     (i.e. chipsfb(4), gffb(4), pm3fb(4), tdvfb(4), r128fb(4), voodoofb(4))
 >  >     because at least the ATI Rage 128 on my G4 Mac doesn't show
 >  >     "green" kernel messages on INSTALL kernel (just "white on black")
 >  
 >  Hmm, the INSTALL config doesn't have any of the native drivers, only
 >  genfb. We should probably enable at least the most common ones ( like
 >  machfb, r128fb and radeonfb )
 >  Without them the only way to change palette registers is via OF calls.
 >  
 >  That being said, IIRC macppc bus_space_map() doesn't actually map
 >  anything on 32bit hardware but relies on the entire PCI space being
 >  BAT-mapped 1:1, there's a function in arch/powerpc/oea which tries to
 >  figure out which parts we need and set up BAT registers accordingly, I
 >  had to add stuff to that before to make trm work on a beige G3.
 >  Although, if that was the problem we'd crash in native drivers, not OF
 >  calls. This sounds more like OF's mappings not being properly restored
 >  before calling OF, and 
 >   [   1.0000000] trap: kernel write DSI trap @ 0x900000b0 by 0xff80b578
 >   (DSISR 0x42000000, err=14), lr 0xff93dce8
 >  is something trying to access the r128's palette index register,
 >  apparently expecting 1:1 mapping.
 
 Is it possible to setup "ofw_battable" for such OF's mappings?
 
 The problem was triggered by "per-cpu battable in cpuinfo" changes:
  https://github.com/NetBSD/src/commit/7d632b8ba47400f8dd90e2764265a9747c581aca
  https://github.com/NetBSD/src/commit/b4b0bdf37162bd57950a60dfdf755002dc307dcb
 and it looks the "ofw_battable" is empty:
 
 >> Additionally, in the firmware trampoline, point curcpu at an empty
 >> ofw_battable.  This ensures that the DSI exception handler won't
 >> load a BAT register with a kernel block translation that clobbers
 >> a segment translation owned by the firmware.  Eventually, this ofw_battable
 >> might contain some of the larger translations owned by the firmware.
 
 ---
 Izumi Tsutsui