Re: Installing 5.0.2 on a PowerBook G4

[Frank Wille <frank%phoenix.owl.de@localhost>]

Michael wrote:

>> After a short glance over the source it seems that it will only find a
>> disklabel in MBR partitions (quite useless) or without any  
>> partitions, at
>> the beginning of the device.
>
> I don't know where NetBSD stores the disklabel on macppc,

Not at all, I think. Similar to the Amiga's RDB the disklabel is constructed
on the fly while reading the Apple Partition Map. So you can only read a
diskabel, but never write one (you have to use pdisk instead).


> I don't know what you're talking about. Ofwboot seems to at least  
> understand whatever partitioning scheme OSX uses. It may or may not  
> use offsets relative to whatever OF thinks about partitions though, so  
> it's probably not ofwboot itself.

Hm, I guess it splits the OF device part from the file name and can use 
OF_open() on it to determine a partition offset?

It would still be an advantage to be able to use no OF device name at all,
but just let ofwboot find the NetBSD root partition automatically. I will
look into that.


>>> Some *Books can switch CPU or bus speeds and on those OF will start  
>>> up
>>> at low speed. On the iBook G4 there is a gpio to switch it to full
>>> speed ( see sysctl machdep.cpu_speed ) but I have no idea if your
>>> PowerBook uses the same mechanism.
>>
>> No, such a sysctl-entry doesn't exist here. It's a 7447A.
>
> IIRC my iBook G4 has the same CPU.

Sure? Then the CPU should support DFS.

Today I found out that Apple is using the 7447A's DFS (Dynamic Frequency
Switch) feature instead of a second gpio for it. I tried to write a small
patch to support it with machdep.cpu_speed (see my other posting). Works
fine for me.

Another question would be how to use this feature best? Maybe automatically
set machdep.cpu_speed=0 when the system load drops below 0.5?

Or perhaps something can be done with powerd(8)?


>>> [..wrong keyboard layout..]
> I'm thoroughly unfamiliar with the USB code. What I meant is you could  
> make a new map based on de that matches the PowerBook ( de_mac or  
> whatever )

I would have to find out first for how many different models such a keymap
fits. The Apple USB-keyboard on my Powermac G4 is fine, so it is PowerBook
specific.


>>> [..cbb is dead..]
>> cbb0 at pci1 dev 19 function 0: Texas Instruments PCI1510 PCI- 
>> CardBus Bridge
>> (rev. 0x00)
>> [...]
>> cbb0: cacheline 0x8 lattimer 0x10
>> cbb0: bhlc 0x21008
>> cbb0: interrupting at irq 53
>> cardslot0 at cbb0
>> cardbus0 at cardslot0: bus 1
>> pcmcia0 at cardslot0
>
> Hmm, that looks good.
>
>>> And, did you try -current?
>>
>> Yes. Same effect.
>
> Weird. I get this:
> cbb0 at pci1 dev 26 function 0: vendor 0x104c product 0xac1e (rev.
> 0x00) cbb0: cacheline 0x8 lattimer 0x10
> cbb0: bhlc 0x21008
> cbb0: interrupting at irq 58
> cardslot0 at cbb0
> cardbus0 at cardslot0: bus 1
> pcmcia0 at cardslot0
>
> which translates to Texas Instruments PCI1211 PCI-CardBus Bridge

When I plug in a pcmcia card before I boot OF, it is recognized and the LEDs
start blinking, so the port is not electrically dead.

But all kernels crash, when the card is detected (typed manually):

5.0.2
-----
ohci4 at cardbus0 function 0: Opti 82C861 (rev. 0x10)
ohci4: OHCI version 1.0, legacy support
trap: pid 0.5 (system) at  netbsd:cpu_Debugger+0x10:
panic+0x210
trap+0x108
kernel MCHK trap by splraise+0xc
_prop_dictionary_keysym32_pool+0xff8016a8
mutex_vector_exit+0x58
callout_schedule+0x28
pffasttimo+0x9c
callout_softclock+0x1a8
softint_thread+0xf4
emptyidlespin+0x10
_prop_dictionary_keysym32_pool+0xff8016a8

5.99.39
-------
ohci4 at cardbus0 function 0: Opti 82C861 (rev. 0x10)
ohci4: OHCI version 1.0, legacy support
trap: pid 0.5 (system) at  netbsd:cpu_Debugger+0x10:
panic+0x25c
trap+0x120
kernel MCHK trap by splraise+0xc
0xfffffffc
mutex_spin_exit+0x58
callout_schedule+0x44
pffasttimo+0x9c
callout_softclock+0x220
softint_thread+0x10c
emptyidlespin+0x10
0xfffffffc

Ok, I remember I also had some crashes on an i386 laptop some years ago,
which I had to fix first, so it might be just this UMTS card. Not a
priority item at the moment.


> [..display brightness..]
> You're not using radeonfb :p
> That code has been in radeonfb for at least a year. Needs some changes  
> though.

Radeonfb has some problems with the screen dimensions. It looks like the
pixels are shifted each line or even completely mixed. The system boots
multiuser though, and I could log in to get the following from dmesg:

radeonfb0 at pci0 dev 16 function 0: ATI Technologies Radeon Mobility
9600/9700 (M10/11) NP
radeonfb0: Video BIOS not present
radeonfb0: No video BIOS, using default clocks
radeonfb0: refclk = 27.000 MHz, refdiv = 12 minpll = 125000, maxpll = 350000
radeonfb0: using static EDID
max_dotclock according to supported modes: 79810
radeonfb0: using static EDID
max_dotclock according to supported modes: 79810
radeonfb0: 64 MB aperture at 0xb8000000, 64 KB registers at 0xb0000000
radeonfb0: display 0: initial virtual resolution 1280x854 at 8 bpp
radeonfb0: port 0: physical 1280x854 60Hz
radeonfb0: port 1: physical 1280x854 60Hz
wsdisplay0 at radeonfb0 kbdmux 1: console (fb, vt100 emulation)

The resolution seems correct. No idea what's the problem here.


> That's for ADB keyboards and won't work on -current anyway. On older  
> *Books the hotkeys appear as a separate ADB device which these days  
> sends PMF events. I have no idea what they did on USB keyboards.

My USB keyboard just sends the normal function key codes.


>> [..X11..]
>> Fatal server error:
>> can't switch keyboard to raw mode. Enable support for it in the kernel
>
> Well, enable support for it in the kernel :p
> Otherwise, X -configure should do the right thing.

Ok, works with wskbd and wsmouse in xorg.conf. Thanks.

I found a small typo in
xfree/xc/programs/Xserver/hw/xfree86/os-support/bsd/bsd_kbd.c:

                         FatalError("can't switch keyboard to raw mode. "
                                    "Enable support for it in the kernel\n"
                                    "or use for example:\n\n"
                                    "Option \"Protocol\" \"wskbd\"\n"
                                    "Option \"Device\" \"/dev/wskbd0\"\n"
                                    "\nin your XF86Config(5) file\n");

The device wskbd0 didn't work for me, but wskbd does. For wsmouse the error
message is correct. Maybe this should be changed to avoid confusion?

-- 
Frank Wille