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

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

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

From: Michael <macallan1888%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: port-macppc/58320: NetBSD/macppc 10.0 INSTALL kernel stalls on
  Power Mac G4
Date: Tue, 29 Apr 2025 19:34:54 -0400

 Hello,
 
 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.
 
 have fun
 Michael