CONFIG_PPC != Mac

CONFIG_PPC != Mac

[Dan Malek]

Or vice versa....

So, the 2.4.0 PowerPC tree is now Mac workstation only?  Please,
we can't make the assumption that CONFIG_PPC is a Macintosh.  It
breaks all PowerPC embedded systems (or anything that isn't a recent
Mac with USB).  There is a CONFIG_MAC, isn't that enough to do the same
thing?

Can we quickly resolve this?  The BK tree doesn't build for many
systems right now.

Thanks.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Tom Rini]

On Fri, Jul 28, 2000 at 07:57:11PM -0400, Dan Malek wrote:

> So, the 2.4.0 PowerPC tree is now Mac workstation only?  Please,
> we can't make the assumption that CONFIG_PPC is a Macintosh.  It
> breaks all PowerPC embedded systems (or anything that isn't a recent
> Mac with USB).  There is a CONFIG_MAC, isn't that enough to do the same
> thing?

Well, where are the specific breakages?  (CONFIG_MAC is used for 68k only
right now, IIRC.)

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Tony Mantler]

At 11:38 AM -0500 7/29/2000, Tom Rini wrote:
>On Fri, Jul 28, 2000 at 07:57:11PM -0400, Dan Malek wrote:
>
>> So, the 2.4.0 PowerPC tree is now Mac workstation only?  Please,
>> we can't make the assumption that CONFIG_PPC is a Macintosh.  It
>> breaks all PowerPC embedded systems (or anything that isn't a recent
>> Mac with USB).  There is a CONFIG_MAC, isn't that enough to do the same
>> thing?
>
>Well, where are the specific breakages?  (CONFIG_MAC is used for 68k only
>right now, IIRC.)

Add a CONFIG_PMAC maybe? I don't really object to sharing CONFIG_MAC with
PPC, except that it would be easy to assume that CONFIG_MAC == CONFIG_MAC
&& __powerpc__, and vice versa CONFIG_MAC == CONFIG_MAC && __m68k__.

On the other hand, using a CONFIG option all over the place is probably the
wrong answer for this. I'd rather see something along the lines of:

#ifdef CONFIG_PMAC
#define MACH_IS_PMAC (machtype == MACH_PMAC)
#else
#define MACH_IS_PMAC 0
#endif

...

if (MACH_IS_PMAC) {
	/* do powermac stuff here */
}

which may already exist, I haven't ever bothered to look. Anyways, it would
let you either strip out powermac code, or build a kernel that works both
on powermacs and non-powermacs alike, depending on which you want.


Or whatever.

Cheers - Tony :)


--
Tony Mantler       Renaissance Nerd Extraordinaire     nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada                     http://nicoya.feline.pp.se/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Dan Malek]

Tony Mantler wrote:

> Add a CONFIG_PMAC maybe? I don't really object to sharing CONFIG_MAC with
> PPC, except that it would be easy to assume that CONFIG_MAC == CONFIG_MAC
> && __powerpc__, and vice versa CONFIG_MAC == CONFIG_MAC && __m68k__.

Ahhhhh....I get it.  Apologies to the m68k folks....
OK....let me think about this and work on some alternatives.  So, it
is OK to assume CONFIG_MAC implies m68k?

Thanks.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Tony Mantler]

At 12:40 PM -0500 7/29/2000, Dan Malek wrote:
>Tony Mantler wrote:
>
>> Add a CONFIG_PMAC maybe? I don't really object to sharing CONFIG_MAC with
>> PPC, except that it would be easy to assume that CONFIG_MAC == CONFIG_MAC
>> && __powerpc__, and vice versa CONFIG_MAC == CONFIG_MAC && __m68k__.
>
>Ahhhhh....I get it.  Apologies to the m68k folks....
>OK....let me think about this and work on some alternatives.  So, it
>is OK to assume CONFIG_MAC implies m68k?

At the moment, it appears yes. via-cuda.c is a good example of this. On the
other hand, valkyriefb.c uses __mc68000 instead, so go fig.


Cheers - Tony :)


--
Tony Mantler       Renaissance Nerd Extraordinaire     nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada                     http://nicoya.feline.pp.se/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Martin Costabel]

Tony Mantler wrote:
>
> At 12:40 PM -0500 7/29/2000, Dan Malek wrote:
> >Tony Mantler wrote:
> >
> >> Add a CONFIG_PMAC maybe? I don't really object to sharing CONFIG_MAC with
> >> PPC, except that it would be easy to assume that CONFIG_MAC == CONFIG_MAC
> >> && __powerpc__, and vice versa CONFIG_MAC == CONFIG_MAC && __m68k__.
> >
> >Ahhhhh....I get it.  Apologies to the m68k folks....
> >OK....let me think about this and work on some alternatives.  So, it
> >is OK to assume CONFIG_MAC implies m68k?
>
> At the moment, it appears yes. via-cuda.c is a good example of this. On the
> other hand, valkyriefb.c uses __mc68000 instead, so go fig.

??? Care to explain? What kernel are you talking about? I don't find any
CONFIG_MAC in the kernel sources, nor any 68000 in valkyriefb.c.

IMHO, there seems to be a lot of confusion right now with config options
in the latest bk kernel, like you can still choose CONFIG_ADBMOUSE, but
no longer CONFIG_ADB_KEYBOARD which is needed at several places,
however.

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Tony Mantler]

At 9:24 PM -0500 7/29/2000, Martin Costabel wrote:
>Tony Mantler wrote:
>>
>> At 12:40 PM -0500 7/29/2000, Dan Malek wrote:
>> >Tony Mantler wrote:
>> >
>> >> Add a CONFIG_PMAC maybe? I don't really object to sharing CONFIG_MAC with
>> >> PPC, except that it would be easy to assume that CONFIG_MAC == CONFIG_MAC
>> >> && __powerpc__, and vice versa CONFIG_MAC == CONFIG_MAC && __m68k__.
>> >
>> >Ahhhhh....I get it.  Apologies to the m68k folks....
>> >OK....let me think about this and work on some alternatives.  So, it
>> >is OK to assume CONFIG_MAC implies m68k?
>>
>> At the moment, it appears yes. via-cuda.c is a good example of this. On the
>> other hand, valkyriefb.c uses __mc68000 instead, so go fig.
>
>??? Care to explain? What kernel are you talking about? I don't find any
>CONFIG_MAC in the kernel sources, nor any 68000 in valkyriefb.c.

2.3.99-pre5, Linus edition. just happens to be what I have handy atm.

I should certainly hope there would be some CONFIG_MAC in the kernel source
somewhere, it should have been there since 2.0.something atleast... unless
maybe Linus decided he doesn't like 68k macs and stripped it all out! :o ;)


Cheers - Tony :)


--
Tony Mantler       Renaissance Nerd Extraordinaire     nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada                     http://nicoya.feline.pp.se/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Dan Malek]

Martin Costabel wrote:

> ??? Care to explain? What kernel are you talking about? I don't find any
> CONFIG_MAC in the kernel sources, nor any 68000 in valkyriefb.c.

I originally stated I was using the 2.4.0-test5 from BitKeeper......
The CONFIG_MAC is in some Makefiles, which causes drivers/macintosh
to be used.


> IMHO, there seems to be a lot of confusion right now with config options
> in the latest bk kernel,

So, I'm not alone here :-)?


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Franz Sirl]

At 04:24 30.07.00, Martin Costabel wrote:

>Tony Mantler wrote:
> >
> > At 12:40 PM -0500 7/29/2000, Dan Malek wrote:
> > >Tony Mantler wrote:
> > >
> > >> Add a CONFIG_PMAC maybe? I don't really object to sharing CONFIG_MAC
> with
> > >> PPC, except that it would be easy to assume that CONFIG_MAC ==
> CONFIG_MAC
> > >> && __powerpc__, and vice versa CONFIG_MAC == CONFIG_MAC && __m68k__.
> > >
> > >Ahhhhh....I get it.  Apologies to the m68k folks....
> > >OK....let me think about this and work on some alternatives.  So, it
> > >is OK to assume CONFIG_MAC implies m68k?
> >
> > At the moment, it appears yes. via-cuda.c is a good example of this. On the
> > other hand, valkyriefb.c uses __mc68000 instead, so go fig.
>
>??? Care to explain? What kernel are you talking about? I don't find any
>CONFIG_MAC in the kernel sources, nor any 68000 in valkyriefb.c.
>
>IMHO, there seems to be a lot of confusion right now with config options
>in the latest bk kernel, like you can still choose CONFIG_ADBMOUSE, but
>no longer CONFIG_ADB_KEYBOARD which is needed at several places,
>however.

What still uses CONFIG_ADB_KEYBOARD in bitkeeper? I thought I catched all
PPC uses of it? mac_keyb.c and adbmouse.c are obsolete now for PPC. The
input layer Makefile setup in drivers/macintosh needs some refinement vs.
m68k though (hopefully m68k people will use my new stuff too). The possible
selection of the obsolete CONFIG_ADBMOUSE is already fixed in my local
tree, I conditionalized it on CONFIG_MAC.

BTW, how about CONFIG_PPC_DESKTOP and CONFIG_PPC_EMBEDDED in addition to
CONFIG_PPC?

Franz.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Martin Costabel]

Franz Sirl wrote:
[]
> What still uses CONFIG_ADB_KEYBOARD in bitkeeper? I thought I catched all
> PPC uses of it? mac_keyb.c and adbmouse.c are obsolete now for PPC. The
> input layer Makefile setup in drivers/macintosh needs some refinement vs.
> m68k though (hopefully m68k people will use my new stuff too). The possible
> selection of the obsolete CONFIG_ADBMOUSE is already fixed in my local
> tree, I conditionalized it on CONFIG_MAC.

Yes, I had CONFIG_ADBMOUSE=y, and this needed mac_keyb.c which was not
included unless CONFIG_ADB_KEYBOARD was chosen.

I am fighting with the "new input layer" right now, although I don't
quite understand why this thing is being inflicted upon innocent ADB
users.

I am trying to use it in compatibility mode, so that I can still boot
into other kernels (if I see this right, for ADB it doesn't exist
outside of BenH's 2.2.17 tree and the linuxppc_2_3 tree. How sure is it
that this will be accepted into the mainstream kernel?). There are still
some problems:

After booting, some keys don't work: The "a" key that was mentioned
before (it is the "q" here on my French keyboard), but also all the
function keys and most keypad keys. Some of them don't produce keycodes,
some of them weird ones.

After starting X, the situation remained the same, although xev didn't
show the same keycodes or lack of them as showkey. I then switched
/proc/sys/dev/mac_hid/keyboard_sends_linux_keycodes on and off (had to
learn to type "j" for <return> first to go back) and left and reentered
X a couple of times. After a while, all keys started to work correctly.
I'll do some more testing what makes them work.

The main problem so far is that I cannot get mouse button emulation to
work. Has anyone tested this on an ADB keyboard/mouse? Or does it only
work if one goes over completely to the "linux" keycodes? I don't want
to do this yet, because it will make my system unusable with any other
kernel (or maybe unusable at all). Last time I tried, it took me several
hours to get a usable system back.

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Franz Sirl]

At 15:11 31.07.00, Martin Costabel wrote:
>Franz Sirl wrote:
>[]
> > What still uses CONFIG_ADB_KEYBOARD in bitkeeper? I thought I catched all
> > PPC uses of it? mac_keyb.c and adbmouse.c are obsolete now for PPC. The
> > input layer Makefile setup in drivers/macintosh needs some refinement vs.
> > m68k though (hopefully m68k people will use my new stuff too). The possible
> > selection of the obsolete CONFIG_ADBMOUSE is already fixed in my local
> > tree, I conditionalized it on CONFIG_MAC.
>
>Yes, I had CONFIG_ADBMOUSE=y, and this needed mac_keyb.c which was not
>included unless CONFIG_ADB_KEYBOARD was chosen.
>
>I am fighting with the "new input layer" right now, although I don't
>quite understand why this thing is being inflicted upon innocent ADB
>users.

2.4 users are not innocent :-). As I said, just don't turn on
CONFIG_ADBMOUSE. I'm doing that right now, cause the kernel uses linux
keycodes already internally now, and they will show up externally somewhere
during 2.5, so doing it for 2.4 with backwards compatibility on by default
is the best thing to do.

>I am trying to use it in compatibility mode, so that I can still boot
>into other kernels (if I see this right, for ADB it doesn't exist
>outside of BenH's 2.2.17 tree and the linuxppc_2_3 tree. How sure is it
>that this will be accepted into the mainstream kernel?). There are still
>some problems:
>
>After booting, some keys don't work: The "a" key that was mentioned
>before (it is the "q" here on my French keyboard), but also all the
>function keys and most keypad keys. Some of them don't produce keycodes,
>some of them weird ones.

I fixed that in my tree too, just got the condition in pmac_setup.c wrong,
it should be if (!keyboard_sends_linux_keycodes) ..., just a typo, will be
fixed later today.

>After starting X, the situation remained the same, although xev didn't
>show the same keycodes or lack of them as showkey. I then switched
>/proc/sys/dev/mac_hid/keyboard_sends_linux_keycodes on and off (had to
>learn to type "j" for <return> first to go back) and left and reentered
>X a couple of times. After a while, all keys started to work correctly.
>I'll do some more testing what makes them work.

See above, switching /proc/sys/dev/mac_hid/keyboard_sends_linux_keycodes to
1 and then back to 0 probably fixes it.

>The main problem so far is that I cannot get mouse button emulation to
>work. Has anyone tested this on an ADB keyboard/mouse? Or does it only
>work if one goes over completely to the "linux" keycodes? I don't want
>to do this yet, because it will make my system unusable with any other
>kernel (or maybe unusable at all). Last time I tried, it took me several
>hours to get a usable system back.

Mouse button emulation works for me and it works in both keycode modes, in
2.4 the adb_buttons kernel arg is gone though.

Franz.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Andreas Tobler]

Franz Sirl wrote:

> 2.4 users are not innocent :-). As I said, just don't turn on
> CONFIG_ADBMOUSE. I'm doing that right now, cause the kernel uses linux
> keycodes already internally now, and they will show up externally somewhere
> during 2.5, so doing it for 2.4 with backwards compatibility on by default
> is the best thing to do.

Turning CONFIG_ADBMOUSE off results in a nice kernel panic with two additional
keyboards connected to the adb-port of my wallstreet :-) (No additional mouse
connected)

With only the internal kbd it works so far even with the new LAYER maps.

Andreas

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

New input layer and ADB (Was Re: CONFIG_PPC != Mac)

[Martin Costabel]

Franz,

Franz Sirl wrote:
>
> At 15:11 31.07.00, Martin Costabel wrote:
[]
> >After booting, some keys don't work: The "a" key that was mentioned
> >before (it is the "q" here on my French keyboard), but also all the
> >function keys and most keypad keys. Some of them don't produce keycodes,
> >some of them weird ones.
>
> I fixed that in my tree too, just got the condition in pmac_setup.c wrong,
> it should be if (!keyboard_sends_linux_keycodes) ..., just a typo, will be
> fixed later today.

Yes, this works, the keys are now working correctly from the beginning.
Thanks!

Sometimes after a console switch, I end up in capslock mode. Switching
capslock on then gives lowercase letters (except the letter "L"). After
a further console switch, things return to normal.

> >The main problem so far is that I cannot get mouse button emulation to
> >work. Has anyone tested this on an ADB keyboard/mouse? Or does it only
> >work if one goes over completely to the "linux" keycodes? I don't want
> >to do this yet, because it will make my system unusable with any other
> >kernel (or maybe unusable at all). Last time I tried, it took me several
> >hours to get a usable system back.
>
> Mouse button emulation works for me and it works in both keycode modes, in
> 2.4 the adb_buttons kernel arg is gone though.

After another hour of trying, I still have no mouse button emulation.
Neither in the console with gpm nor in X (Free86-4.0.1 from your
devel.linuxppc.org RPMs, with OPTION "XkbModel" "macintosh_old"). What's
the trick?

Here are my relevant kernel config options. Is there something missing?

CONFIG_INPUT_ADBHID=y
CONFIG_MAC_ADBKEYCODES=y
CONFIG_INPUT=y
# CONFIG_INPUT_IFORCE_USB is not set
CONFIG_INPUT_ADBHID=y
CONFIG_INPUT_KEYBDEV=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y

Remark: Since I am using devfs, I had to put a line
LOOKUP    mouse    CFUNCTION GLOBAL symlink input/mice mouse
into /etc/devfsd. Otherwise no /dev/mouse got created.

Final question: What is /proc/sys/dev/mac_hid/keyboard_lock_keycodes
for?

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New input layer and ADB (Was Re: CONFIG_PPC != Mac)

[Geert Uytterhoeven]

On Mon, 31 Jul 2000, Martin Costabel wrote:
> Sometimes after a console switch, I end up in capslock mode. Switching
> capslock on then gives lowercase letters (except the letter "L"). After
> a further console switch, things return to normal.

That's normal. With PC keyboards, the LED state of the Caps Lock key is
controlled by Linux, while Mac (and Amiga) keyboards remember the Caps Lock
state in the keyboard. Hence if you do a VC switch to a VC where Caps Lock is
in a different state, Linux and the keyboard will disagree.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New input layer and ADB (Was Re: CONFIG_PPC != Mac)

[Michael Schmitz]

> > Sometimes after a console switch, I end up in capslock mode. Switching
> > capslock on then gives lowercase letters (except the letter "L"). After
> > a further console switch, things return to normal.
>
> That's normal. With PC keyboards, the LED state of the Caps Lock key is
> controlled by Linux, while Mac (and Amiga) keyboards remember the Caps Lock
> state in the keyboard. Hence if you do a VC switch to a VC where Caps Lock is

Wrong for Mac. We explicitly set LED state from the keyboard bottom half
if necessary (though it stopped working consistently sometime in 2.1
IIRC).

The CapsLock on ADB keyboards is worth a million laughs actually. It
is sticky by hardware, and never sends a key up event, only key down. See
mac_keyb.c.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New input layer and ADB (Was Re: CONFIG_PPC != Mac)

[Martin Costabel]

Michael Schmitz wrote:
>
> > > Sometimes after a console switch, I end up in capslock mode. Switching
> > > capslock on then gives lowercase letters (except the letter "L"). After
> > > a further console switch, things return to normal.
> >
> > That's normal. With PC keyboards, the LED state of the Caps Lock key is
> > controlled by Linux, while Mac (and Amiga) keyboards remember the Caps Lock
> > state in the keyboard. Hence if you do a VC switch to a VC where Caps Lock is
>
> Wrong for Mac. We explicitly set LED state from the keyboard bottom half
> if necessary (though it stopped working consistently sometime in 2.1
> IIRC).
>
> The CapsLock on ADB keyboards is worth a million laughs actually. It
> is sticky by hardware, and never sends a key up event, only key down. See
> mac_keyb.c.

In any case, Franz's typo fix (lost "!") makes the problem disappear\x13and
everything works as it should: VCs remember their capslock state
independently of what the capslock key itself remembers.\x13

--
Martin
\x11 \x13

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: New input layer and ADB (Was Re: CONFIG_PPC != Mac)

[Geert Uytterhoeven]

On Thu, 3 Aug 2000, Michael Schmitz wrote:
> > > Sometimes after a console switch, I end up in capslock mode. Switching
> > > capslock on then gives lowercase letters (except the letter "L"). After
> > > a further console switch, things return to normal.
> >
> > That's normal. With PC keyboards, the LED state of the Caps Lock key is
> > controlled by Linux, while Mac (and Amiga) keyboards remember the Caps Lock
> > state in the keyboard. Hence if you do a VC switch to a VC where Caps Lock is
>
> Wrong for Mac. We explicitly set LED state from the keyboard bottom half
> if necessary (though it stopped working consistently sometime in 2.1
> IIRC).

IIRC, the only (borrowed) ADB keyboard I ever connected to my CHRP box (when I
used Xpmac) had no Caps Lock LED, but a mechanical Caps Lock indicator (key
stays up or down). I'm afraid you can control those mechanics by software :-)

> The CapsLock on ADB keyboards is worth a million laughs actually. It
> is sticky by hardware, and never sends a key up event, only key down. See
> mac_keyb.c.

I know, cfr. amikeyb.c :-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Andreas Tobler]

Franz Sirl wrote:
> >Turning CONFIG_ADBMOUSE off results in a nice kernel panic with two additional
> >keyboards connected to the adb-port of my wallstreet :-) (No additional mouse
> >connected)
>
> Now that is interesting. Did it work with Ben's 2.2? Were the keyboards
> plugged in at boot time? Modules or compiled in? Can you give a bit more
> details please?

Sure I can ;-)
Situation: Wallstreet I internal ISO-kbd , ISO-kbd, ANSI-kbd, (with and
without MouseMan)
Built-in!

- 2.2.17pre13-ben2 works flawless, no problem so far except the KP_equal.....

- 2.4.0test5 synced today no additional kbd on boot works
- 2.4.0test5 with additional kbd & MouseMan plugged in AFTER boot works
- 2.4.0test5 with additional kbd & MouseMan plugged on boot (means
before) panics.
- 2.4.0test5 with additional kbd & MouseMan plugged on boot, passing
console=ttyS0 as kernel args works
- 2.4.0test5 with additional kbd & MouseMan plugged on boot, passing
console=tty0 and console=ttyS0 as kernel args panics, see below.

The console stuff was added to collect an eventual panic :-)

The config I have to grab from the linux side

Andreas

---------

log with only console=ttyS0:

ADB keyboard at 2, handler 1
Detected ADB keyboard, type ISO, swapping keys.
input1: ADB HID on ID 2:2.c4
ADB keyboard at 12, handler set to 3
Detected ADB keyboard, type ANSI.
input2: ADB HID on ID 12:2.03
ADB keyboard at 13, handler 1
Detected ADB keyboard, type ANSI.
input3: ADB HID on ID 13:2.01
ADB keyboard at 15, handler 1
Detected ADB keyboard, type ISO, swapping keys.
input4: ADB HID on ID 15:2.05
input5: ADB HID on ID 7:7.1f
ADB mouse at 3, handler set to 4 (trackman/mouseman)
input6: ADB HID on ID 3:3.04
ADB mouse at 14, handler set to 4 (trackpad)
input7: ADB HID on ID 14:3.04
Macintosh non-volatile memory driver v1.0
event0: Event device for input7
event1: Event device for input6
event2: Event device for input5
event3: Event device for input4
event4: Event device for input3
event5: Event device for input2
event6: Event device for input1
event7: Event device for input0
usb.c: registered new driver hid
keybdev.c: Adding keyboard: input4
keybdev.c: Adding keyboard: input3
keybdev.c: Adding keyboard: input2
keybdev.c: Adding keyboard: input1
mouse0: PS/2 mouse device for input7
mouse1: PS/2 mouse device for input6
mouse2: PS/2 mouse device for input0
mice: PS/2 mouse device common for all mice

log with console=tty0 & console=ttyS0:

ADB keyboard at 2, handler 1
Detected ADB keyboard, type ISO, swapping keys.
input1: ADB HID on ID 2:2.c4
NIP: C0154254 XER: 00000000 LR: C01541A0 REGS: c055f9e0 TRAP: 0300
MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c055e000[1] 'swapper' Last syscall: 120
last math 00000000 last altivec 00000000
GPR00: C01541A0 C055FA90 C055E000 00000000 00000001 0000003A 00000001 081A7300
GPR08: C0270000 C0270000 00000000 000000DC 22828042 002CB0A8 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000 00001032 0055FBC0 00000000 C0004BE4
GPR24: C0005A00 00000001 C055FBD0 00000001 00000034 0000003A 00000001 00000000

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Michael Schmitz]

> I am fighting with the "new input layer" right now, although I don't
> quite understand why this thing is being inflicted upon innocent ADB
> users.

My question exactly.

> The main problem so far is that I cannot get mouse button emulation to
> work. Has anyone tested this on an ADB keyboard/mouse? Or does it only
> work if one goes over completely to the "linux" keycodes? I don't want
> to do this yet, because it will make my system unusable with any other
> kernel (or maybe unusable at all). Last time I tried, it took me several
> hours to get a usable system back.

ADB keyboard and mouse work (and button emulation works as well) with
CONFIG_NEW_INPUT_LAYER not set. What doesn't work for me anymore is the
USB mouse. The 2.2.17 kernel (rsynced last Thursday) only compiled after I
added a #ifdef CONFIG_MOUSEDEV somewhere in mac_keyb.c as a consequence of
not having CONFIG_NEW_INPUT_LAYER defined. I'd look it up on the Lombard
but the box just crashed on me the second time in a row today. 2.2.17 sure
is exciting.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Geert Uytterhoeven]

On Mon, 31 Jul 2000, Franz Sirl wrote:
> BTW, how about CONFIG_PPC_DESKTOP and CONFIG_PPC_EMBEDDED in addition to
> CONFIG_PPC?

And what makes the difference between a `desktop' and an `embedded' PPC here?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Dan Malek]

Geert Uytterhoeven wrote:
>
> On Mon, 31 Jul 2000, Franz Sirl wrote:
> > BTW, how about CONFIG_PPC_DESKTOP and CONFIG_PPC_EMBEDDED in addition to
> > CONFIG_PPC?
>
> And what makes the difference between a `desktop' and an `embedded' PPC here?


I hope we don't do this, as I don't think that is a very good
distinction either.  I prefer some of the other suggestions, where
we simply have mix-n-match configuration options.  Select a board
and processor type and go from there.

I have had the opportunity lately to use some of the other Linux
processor architecture configurations.  The Linux PowerPC configuration
really isn't too bad, and I would prefer just a small evolution.  If
you want to see some bad configuration and hard to use environments,
go visit some of the other emerging architectures.......

I think even some of the "source restructuring" that has been discussed
could also be mitigated with a more logical set of configuration options.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Geert Uytterhoeven]

On Sat, 29 Jul 2000, Tony Mantler wrote:
> At 11:38 AM -0500 7/29/2000, Tom Rini wrote:
> >On Fri, Jul 28, 2000 at 07:57:11PM -0400, Dan Malek wrote:
> >
> >> So, the 2.4.0 PowerPC tree is now Mac workstation only?  Please,
> >> we can't make the assumption that CONFIG_PPC is a Macintosh.  It
> >> breaks all PowerPC embedded systems (or anything that isn't a recent
> >> Mac with USB).  There is a CONFIG_MAC, isn't that enough to do the same
> >> thing?
> >
> >Well, where are the specific breakages?  (CONFIG_MAC is used for 68k only
> >right now, IIRC.)
>
> Add a CONFIG_PMAC maybe? I don't really object to sharing CONFIG_MAC with
> PPC, except that it would be easy to assume that CONFIG_MAC == CONFIG_MAC
> && __powerpc__, and vice versa CONFIG_MAC == CONFIG_MAC && __m68k__.
>
> On the other hand, using a CONFIG option all over the place is probably the
> wrong answer for this. I'd rather see something along the lines of:
>
> #ifdef CONFIG_PMAC
> #define MACH_IS_PMAC (machtype == MACH_PMAC)
> #else
> #define MACH_IS_PMAC 0
> #endif
>
> ...
>
> if (MACH_IS_PMAC) {
> 	/* do powermac stuff here */
> }
>
> which may already exist, I haven't ever bothered to look. Anyways, it would

Ah, the 1996 m68k scheme :-) [cfr. include/asm-m68k/setup.h]

> let you either strip out powermac code, or build a kernel that works both
> on powermacs and non-powermacs alike, depending on which you want.

The Master PPC Penguin decided to no longer allow to build machine specific
kernels, but treat PowerMac/PReP/MTX/CHRP as one big machine type
(`CONFIG_ALL_PPC').

Given the flexibility I was used to on m68k[*], I find this a pity as well...

Gr{oetje,eeting}s,

						Geert

[*] Mix-'n-match any of:

    bool 'Amiga support' CONFIG_AMIGA
    bool 'Atari support' CONFIG_ATARI
    bool 'Macintosh support' CONFIG_MAC
    bool 'Apollo support' CONFIG_APOLLO
    bool 'VME (Motorola and BVM) support' CONFIG_VME
    bool 'HP9000/300 support' CONFIG_HP300
    bool 'Sun3x support' CONFIG_SUN3X
    bool 'Q40/Q60 support' CONFIG_Q40

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Michel Dänzer]

Geert Uytterhoeven wrote:

> The Master PPC Penguin decided to no longer allow to build machine specific
> kernels, but treat PowerMac/PReP/MTX/CHRP as one big machine type
> (`CONFIG_ALL_PPC').

Where does APUS fit in there?


Michel


--
There's no place like ~
______________________________________________________________________________
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86, Team *AMIGA*, AUGS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Geert Uytterhoeven]

On Sun, 30 Jul 2000, Michel [iso-8859-1] Dänzer wrote:
> Geert Uytterhoeven wrote:
> > The Master PPC Penguin decided to no longer allow to build machine specific
> > kernels, but treat PowerMac/PReP/MTX/CHRP as one big machine type
> > (`CONFIG_ALL_PPC').
>
> Where does APUS fit in there?

APUS is something different (CONFIG_APUS, cfr. arch/ppc/config.in). Currently
it's not possible to build one kernel that supports both APUS and any other
machine type anyway.

So currently you have to compile a kernel for _either_

    PowerMac/PReP/MTX/CHRP (CONFIG_ALL_PPC)
 or Gemini (CONFIG_GEMINI)
 or EST8260 (CONFIG_EST8260)
 or APUS (CONFIG_APUS)

Personally I'd more like a configuration where you can select whatever you
want of

  - PowerMac (CONFIG_PMAC)
  - PReP (CONFIG_PREP)
  - MTX (CONFIG_MTX)
  - CHRP (CONFIG_CHRP)
  - Gemini (CONFIG_GEMINI)
  - EST8260 (CONFIG_EST8260)
  - APUS (CONFIG_APUS)

with of course some extra logic to prevent illegal combinations.

The main reason why the Master PPC Penguin chose for the CONFIG_ALL_PPC option
was to be able to compile one kernel that would run on all his machines,
instead of having to compile multiple kernels, one for each machine.
I don't understand why he didn't want the flexibele scheme above, since it
would support anything you want, including his favorite configuration.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Platform configuration (was: Re: CONFIG_PPC != Mac)

[Geert Uytterhoeven]

On Sun, 30 Jul 2000, Geert Uytterhoeven wrote:
> On Sun, 30 Jul 2000, Michel [iso-8859-1] Dänzer wrote:
> > Where does APUS fit in there?
>
> APUS is something different (CONFIG_APUS, cfr. arch/ppc/config.in). Currently
> it's not possible to build one kernel that supports both APUS and any other
> machine type anyway.
>
> So currently you have to compile a kernel for _either_
>
>     PowerMac/PReP/MTX/CHRP (CONFIG_ALL_PPC)
>  or Gemini (CONFIG_GEMINI)
>  or EST8260 (CONFIG_EST8260)
>  or APUS (CONFIG_APUS)
>
> Personally I'd more like a configuration where you can select whatever you
> want of
>
>   - PowerMac (CONFIG_PMAC)
>   - PReP (CONFIG_PREP)
>   - MTX (CONFIG_MTX)
>   - CHRP (CONFIG_CHRP)
>   - Gemini (CONFIG_GEMINI)
>   - EST8260 (CONFIG_EST8260)
>   - APUS (CONFIG_APUS)
>
> with of course some extra logic to prevent illegal combinations.

So what about this?

--- linux-2.4.0-test8-pre1/arch/ppc/config.in.orig	Wed Aug 23 18:52:20 2000
+++ linux-2.4.0-test8-pre1/arch/ppc/config.in	Wed Aug 30 14:23:38 2000
@@ -82,6 +82,10 @@
 fi

 if [ "$CONFIG_ALL_PPC" != "y" ];then
+  bool 'PowerMac support' CONFIG_PMAC
+  bool 'PReP support' CONFIG_PREP
+  bool 'MTX support' CONFIG_MTX
+  bool 'CHRP support' CONFIG_CHRP
   define_bool CONFIG_MACH_SPECIFIC y
 fi

and replace all tests for CONFIG_ALL_PPC by a suitable combination of tests
for CONFIG_PMAC/CONFIG_PREP/CONFIG_MTX/CONFIG_CHRP? (BTW, there are still some
relics of CONFIG_PREP around in config.in)

This clearly indicates that you can
 1. still compile one kernel that can run on all of PowerMac/PReP/MTX/CHRP,
    while
 2. it allows to fine tune the kernel to your specific machine and
 3. protect against illegal combinations with other machine types.
And if it ever will be possible to compile a generic kernel that runs on e.g.
APUS as well, CONFIG_APUS can be included in CONFIG_ALL_PPC (or better, rename
it to CONFIG_GENERIC_PPC) as well.

I'm willing to work on a first patch, but I don't have a PPC cross-compiler at
hand and am unable to use bitkeeper, so I have to base it on plain
2.4.0-test8-pre1 and leave it untested. Whoever owns whatever machine can
smooth the rough edges for his/her platform afterwards.

What do you think?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Platform configuration (was: Re: CONFIG_PPC != Mac)

[Gabriel Paubert]

On Wed, 30 Aug 2000, Geert Uytterhoeven wrote:

>
> On Sun, 30 Jul 2000, Geert Uytterhoeven wrote:
> >
> > Personally I'd more like a configuration where you can select whatever you
> > want of
> >
> >   - PowerMac (CONFIG_PMAC)
> >   - PReP (CONFIG_PREP)
> >   - MTX (CONFIG_MTX)
> >   - CHRP (CONFIG_CHRP)
> >   - Gemini (CONFIG_GEMINI)
> >   - EST8260 (CONFIG_EST8260)
> >   - APUS (CONFIG_APUS)
> >
> > with of course some extra logic to prevent illegal combinations.
>
> So what about this?
>
> --- linux-2.4.0-test8-pre1/arch/ppc/config.in.orig	Wed Aug 23 18:52:20 2000
> +++ linux-2.4.0-test8-pre1/arch/ppc/config.in	Wed Aug 30 14:23:38 2000
> @@ -82,6 +82,10 @@
>  fi
>
>  if [ "$CONFIG_ALL_PPC" != "y" ];then
> +  bool 'PowerMac support' CONFIG_PMAC
> +  bool 'PReP support' CONFIG_PREP
> +  bool 'MTX support' CONFIG_MTX
> +  bool 'CHRP support' CONFIG_CHRP
>    define_bool CONFIG_MACH_SPECIFIC y
>  fi
>
> and replace all tests for CONFIG_ALL_PPC by a suitable combination of tests
> for CONFIG_PMAC/CONFIG_PREP/CONFIG_MTX/CONFIG_CHRP? (BTW, there are still some
> relics of CONFIG_PREP around in config.in)
>
> This clearly indicates that you can
>  1. still compile one kernel that can run on all of PowerMac/PReP/MTX/CHRP,
>     while
>  2. it allows to fine tune the kernel to your specific machine and
>  3. protect against illegal combinations with other machine types.
> And if it ever will be possible to compile a generic kernel that runs on e.g.
> APUS as well, CONFIG_APUS can be included in CONFIG_ALL_PPC (or better, rename
> it to CONFIG_GENERIC_PPC) as well.
>
> I'm willing to work on a first patch, but I don't have a PPC cross-compiler at
> hand and am unable to use bitkeeper, so I have to base it on plain
> 2.4.0-test8-pre1 and leave it untested. Whoever owns whatever machine can
> smooth the rough edges for his/her platform afterwards.
>
> What do you think?

I strongly disagree. What I would like to see is the same kernel running
on all machines, without exception (well all 6xx/7xx/74xx and Power[34]
in 32 bit mode, obvioulsy 8xx and company are too different).

The only reasonable way to do this that I see is to have a self linking
kernel, the initial boot code would simply uncompress a partially linked
kernel and perform the final link step before passing control to it.

Yes this involves putting several versions of processor specific code
in the same kernel, but once compressed it's not that big. The _init
sections are ok, but adding apus/prep/openfirmware is pushing the method
past the breaking point.

Yes, this will make the bot iamge bigger, I just  don't care (embedded
systems are different) since it will make the running kernel smaller:

- only one PCI config method will be linked in for example,
- only the code for the specific interrupt controller(s) will be in (the
current code is a complete mess and so outstandingly inefficient that the
only sane solution is a complete rewrite)
- the various additional section are always rounded up to a page boundary,
another source of wasted space,
- a lot of conditional/machine dependant code will disappear as well as
ppc_md since it will be linked in,

And yes there are problems, like the fact that System.map will not be
constant, perhaps not even across reboots (imagine that you add modules
in the same image and the module becomes automagically linked in the
kernel image if the appropriate hardware happens to be plugged-in).

However this is solvable, and perhaps even better: keep a System.map
around inside the kernel and write it to /boot/System.map early in the
boot scripts and free the kernel memory at this time (a read-once self
destructing /proc entry for example). This even guarantees that System.map
is consistent with your kernel, which I see as a big plus.

Ok, I have a lot of other ideas (espcially about memory management, which
is currently braindead for desktops PPC) but that will be for other posts.

There actually are times where I think that the only viable solution is:
	rm -rf arch/ppc/*
	restart on a sane basis

	Regards,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Platform configuration (was: Re: CONFIG_PPC != Mac)

[Benjamin Herrenschmidt]

>I strongly disagree. What I would like to see is the same kernel running
>on all machines, without exception (well all 6xx/7xx/74xx and Power[34]
>in 32 bit mode, obvioulsy 8xx and company are too different).
>
>The only reasonable way to do this that I see is to have a self linking
>kernel, the initial boot code would simply uncompress a partially linked
>kernel and perform the final link step before passing control to it.

Heh, that's interesting since that's close to an idea I had of having the
bootloader pre-load some modules and have the kernel automatically link
them, so all the platform dependent stuffs could be in modules.

The only problem is that some HW probe code must be present in the
bootloader itself to decide which modules to load (well, this could be in
the bootloader config file, but then, we need a way to load all of them
for boot CDs).

>And yes there are problems, like the fact that System.map will not be
>constant, perhaps not even across reboots (imagine that you add modules
>in the same image and the module becomes automagically linked in the
>kernel image if the appropriate hardware happens to be plugged-in).
>
>However this is solvable, and perhaps even better: keep a System.map
>around inside the kernel and write it to /boot/System.map early in the
>boot scripts and free the kernel memory at this time (a read-once self
>destructing /proc entry for example). This even guarantees that System.map
>is consistent with your kernel, which I see as a big plus.

There's already some code for the kernel to get passed a System.map by
the bootloader. It's currently only used by xmon (AFAIK). With the
dynamic linking stuff, the bootloader could pass the "base" kernel
system.map, and would extend it with modules that gets linked in.

>Ok, I have a lot of other ideas (espcially about memory management, which
>is currently braindead for desktops PPC) but that will be for other posts.
>
>There actually are times where I think that the only viable solution is:
>	rm -rf arch/ppc/*
>	restart on a sane basis

heh..

Something else Cort and I have in mind for 2.5 is to also remove a huge
part of what we currently have in prom.c and head.S and move all that to
bootloaders. The idea is that the kernel would always be entered with MMU
cleaned and off, and all the firmware dependant things like the OF
device-tree would be passed by the bootloader instead of beeing retreived
from OF by the kernel.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Platform configuration (was: Re: CONFIG_PPC != Mac)

[Gabriel Paubert]

On Thu, 31 Aug 2000, Benjamin Herrenschmidt wrote:

> Heh, that's interesting since that's close to an idea I had of having the
> bootloader pre-load some modules and have the kernel automatically link
> them, so all the platform dependent stuffs could be in modules.

Ok, I see that we agree...

> The only problem is that some HW probe code must be present in the
> bootloader itself to decide which modules to load (well, this could be in
> the bootloader config file, but then, we need a way to load all of them
> for boot CDs).

For PCI devices it's not that complex (if you have a list of device
identifiers supported by the module in a header of the module, you can
decide whether you have to link the corresponding module or not).

For desktops and large embedded system (16Mb RAM or more), I just don't
care about the size of the initial image (bootloader+kernel). Anything
which is potentially useful during boot can be included, as long as it is
thrown away before the kernel (whose memory footprint has to be minimized
on the other hand) gets control.

> There's already some code for the kernel to get passed a System.map by
> the bootloader. It's currently only used by xmon (AFAIK). With the
> dynamic linking stuff, the bootloader could pass the "base" kernel
> system.map, and would extend it with modules that gets linked in.

Ok...

> Something else Cort and I have in mind for 2.5 is to also remove a huge
> part of what we currently have in prom.c and head.S and move all that to
> bootloaders. The idea is that the kernel would always be entered with MMU
> cleaned and off, and all the firmware dependant things like the OF
> device-tree would be passed by the bootloader instead of beeing retreived
> from OF by the kernel.

Well, I had a preliminary version of prepboot which read the device tree
instead of residual data, but I gave up and never finished when I realized
that my OF was buggy to the point that the device @1f was actually @0 and
a few others of the same category (real-mode? could not be reliably read
for example when booting from a prepboot partition).

I think the code is still on my ftp directory; the only differences
between a zImage.elf and a zImage.ppcboot were the name of the linker
script and of the output file in the final link command. The rest was
identical, byte per byte, with exactly the same files linked together.

	Gabriel


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Platform configuration (was: Re: CONFIG_PPC != Mac)

[Geert Uytterhoeven]

On Thu, 31 Aug 2000, Gabriel Paubert wrote:
> On Wed, 30 Aug 2000, Geert Uytterhoeven wrote:
> > On Sun, 30 Jul 2000, Geert Uytterhoeven wrote:
> > > Personally I'd more like a configuration where you can select whatever you
> > > want of
> > >
> > >   - PowerMac (CONFIG_PMAC)
> > >   - PReP (CONFIG_PREP)
> > >   - MTX (CONFIG_MTX)
> > >   - CHRP (CONFIG_CHRP)
> > >   - Gemini (CONFIG_GEMINI)
> > >   - EST8260 (CONFIG_EST8260)
> > >   - APUS (CONFIG_APUS)
> > >
> > > with of course some extra logic to prevent illegal combinations.
> >
> > So what about this?
> >
> > --- linux-2.4.0-test8-pre1/arch/ppc/config.in.orig	Wed Aug 23 18:52:20 2000
> > +++ linux-2.4.0-test8-pre1/arch/ppc/config.in	Wed Aug 30 14:23:38 2000
> > @@ -82,6 +82,10 @@
> >  fi
> >
> >  if [ "$CONFIG_ALL_PPC" != "y" ];then
> > +  bool 'PowerMac support' CONFIG_PMAC
> > +  bool 'PReP support' CONFIG_PREP
> > +  bool 'MTX support' CONFIG_MTX
> > +  bool 'CHRP support' CONFIG_CHRP
> >    define_bool CONFIG_MACH_SPECIFIC y
> >  fi
> >
> > and replace all tests for CONFIG_ALL_PPC by a suitable combination of tests
> > for CONFIG_PMAC/CONFIG_PREP/CONFIG_MTX/CONFIG_CHRP? (BTW, there are still some
> > relics of CONFIG_PREP around in config.in)
> >
> > This clearly indicates that you can
> >  1. still compile one kernel that can run on all of PowerMac/PReP/MTX/CHRP,
> >     while
> >  2. it allows to fine tune the kernel to your specific machine and
> >  3. protect against illegal combinations with other machine types.
> > And if it ever will be possible to compile a generic kernel that runs on e.g.
> > APUS as well, CONFIG_APUS can be included in CONFIG_ALL_PPC (or better, rename
> > it to CONFIG_GENERIC_PPC) as well.
> >
> > I'm willing to work on a first patch, but I don't have a PPC cross-compiler at
> > hand and am unable to use bitkeeper, so I have to base it on plain
> > 2.4.0-test8-pre1 and leave it untested. Whoever owns whatever machine can
> > smooth the rough edges for his/her platform afterwards.
> >
> > What do you think?
>
> I strongly disagree. What I would like to see is the same kernel running
> on all machines, without exception (well all 6xx/7xx/74xx and Power[34]
> in 32 bit mode, obvioulsy 8xx and company are too different).

You can still compile a generic kernel by enabling all of
CONFIG_PMAC/CONFIG_PREP/CONFIG_MTX/CONFIG_CHRP.

> The only reasonable way to do this that I see is to have a self linking
> kernel, the initial boot code would simply uncompress a partially linked
> kernel and perform the final link step before passing control to it.
>
> Yes this involves putting several versions of processor specific code
> in the same kernel, but once compressed it's not that big. The _init
> sections are ok, but adding apus/prep/openfirmware is pushing the method
> past the breaking point.

Cool!

> Yes, this will make the bot iamge bigger, I just  don't care (embedded
> systems are different) since it will make the running kernel smaller:

My interest is in smaller kernel images. I don't want to compile every single
piece of PPC code that's useless for my hardware, I want to compile only what
I need. I think I'm already wasting too much of my time waiting for kernel
compiles.

And since there are people who care about embedded PPC systems, it would be
great to at least have _the choice_ to compile a small specific kernel or a
large generic one.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Platform configuration (was: Re: CONFIG_PPC != Mac)

[Dan Malek]

Geert Uytterhoeven wrote:

> And since there are people who care about embedded PPC systems, it would be
> great to at least have _the choice_ to compile a small specific kernel or a
> large generic one.

Yeah, well, I am used to continually losing this battle.  Although
embedded PowerPC is likely to have _lots_ more installations than
the desktop, we'll just survive on the pieces left behind.  A pretty
running desktop gets lots of press coverage while code that acutally
runs the infrastructure of the world is unknown (I guess we are doing
a great job, then :-).

I am just happy that I can finally build a kernel for the MPC8xx that
doesn't require I configure an ADB keyboard.  I also like building the
same sources for all of my Mac workstations and servers as well.

I would also like to see us spend a little more time trying to
stabilize 2.4 instead of trying to solve elaborate configuration and
boot schemes.  That is what 2.5 is for.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Platform configuration (was: Re: CONFIG_PPC != Mac)

[Gabriel Paubert]

On Thu, 31 Aug 2000, Dan Malek wrote:

> I would also like to see us spend a little more time trying to
> stabilize 2.4 instead of trying to solve elaborate configuration and
> boot schemes.  That is what 2.5 is for.

What are your problems with 2.4 ? I'm at 2.4.0-test7 and I've not had any
problem so far, although I still need to upgrade my modutils.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Platform configuration (was: Re: CONFIG_PPC != Mac)

[Michel Dänzer]

Gabriel Paubert wrote:
>
> On Thu, 31 Aug 2000, Dan Malek wrote:
>
> > I would also like to see us spend a little more time trying to
> > stabilize 2.4 instead of trying to solve elaborate configuration and
> > boot schemes.  That is what 2.5 is for.
>
> What are your problems with 2.4 ? I'm at 2.4.0-test7 and I've not had any
> problem so far, although I still need to upgrade my modutils.

A few days ago, I rsynced linux-pmac-devel and tried 2.4.0-test7(-pre?) . I
had problems with the network, no TCP connection could be established. Anyone
seen this?


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and the DRI project

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Platform configuration (was: Re: CONFIG_PPC != Mac)

[Joseph Garcia]

Michel D舅zer wrote:
> A few days ago, I rsynced linux-pmac-devel and tried 2.4.0-test7(-pre?) . I
> had problems with the network, no TCP connection could be established. Anyone
> seen this?

When I tried 2.4, it takes forever for a name to resolve.  connections seem ok
once they are made.

My system also seems to have a fork problem in 2.4.  su hangs for 2-3 minutes.
strace tracks it to a wait that seems to have stalled.  Often, logins and a
handful of other situations do the same.  I mentioned this to Takashi Oe, as I
first noticed it when trying his NuBus 2.4 kernel, but he told me it's a 2.4
thing, possibly relating to VM.  I don't think this is related to the network
problem, or could it be a wakeup problem?

--
Joseph P. Garcia      jpgarcia@execpc.com      jpgarcia@lidar.ssec.wisc.edu
CS Undergraduate                      Student Employee - Systems Programmer
University of Wisconsin - Madison                            UW Lidar Group

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

2.4 problems

[Michel Dänzer]

Joseph Garcia wrote:

> > A few days ago, I rsynced linux-pmac-devel and tried 2.4.0-test7(-pre?) .
> > I had problems with the network, no TCP connection could be established.
> > Anyone seen this?
>
> When I tried 2.4, it takes forever for a name to resolve.  connections seem
> ok once they are made.

For me, the names got resolved, but no HTTP, IMAP, ... connection could be
established. As ICQ also worked, I conclude that TCP didn't work but UDP did.


> My system also seems to have a fork problem in 2.4.  su hangs for 2-3
> minutes.

Haven't seen that.


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and the DRI project

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.4 problems

[Dan Malek]

Michel Dänzer wrote:

> Haven't seen that.

My 7200 won't even boot.....


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.4 problems

[Martin Costabel]

Dan Malek wrote:
>
> Michel Dänzer wrote:
>
> > Haven't seen that.
>
> My 7200 won't even boot.....

On my 6400, both bk-test8 and pmac-devel-test7 are running nicely. The
one major problem is random sudden freezes that can happen after some
minutes or after 3 days and which have been reported a couple of times
by others, too. It is like the ADB interrupt dies. There are no
messages, the computer is still alive, it goes on compiling or
downloading, and today I even could ssh in over the net, but locally,
keyboard and mouse are dead, even MagicSysRq, the only working key combo
is ctrl-cmd-power :-(

I never saw this with 2.2.X kernels (not recently, in any case).

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.4 problems

[Benjamin Herrenschmidt]

>On my 6400, both bk-test8 and pmac-devel-test7 are running nicely. The
>one major problem is random sudden freezes that can happen after some
>minutes or after 3 days and which have been reported a couple of times
>by others, too. It is like the ADB interrupt dies. There are no
>messages, the computer is still alive, it goes on compiling or
>downloading, and today I even could ssh in over the net, but locally,
>keyboard and mouse are dead, even MagicSysRq, the only working key combo
>is ctrl-cmd-power :-(
>
>I never saw this with 2.2.X kernels (not recently, in any case).

Interesting. Do you have the new input layer enabled or are you still
running the old keyboard and mouse drivers ? If you telnet to the box, do
you still see ADB interrupts increasing when typing keys or not ?


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

which kernel...?

[johnathan spectre]

hello all,

i am new to linuxppc (finally got it working on my pismo) but not linux in
general. i'm noticing quite a few differences between the worlds (but am
very happy with linux on my powerbook). i have one big question though...

which kernel should i be using?

i rsync'ed down pmac-benh because someone on linuxppc-user told me that was
what i needed to support audio on my pismo. it works great (thanks ben) as
far as i can tell.. but there are also 4 other kernels (not to mention
xfree86 which i haven't tried yet...) to be had.

can someone explain the differences between them to me? will any of the
others run on my pismo? is any of the others "better" or "worse" (no offense
to all the coders involved)? should i just be quiet and happy with ben's
latest and do all of them plan on merging at some point and then folding
their code into what's available at www.kernel.org?

i'm sorry if this is a FAQ, but i didn't see it anywhere on the faqomatic..

thanks for any/all responses!


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: which kernel...?

[Matt Brubeck]

On Thu, 31 Aug 2000, johnathan spectre wrote:

> i rsync'ed down pmac-benh because someone on linuxppc-user told me that was
> what i needed to support audio on my pismo. it works great (thanks ben) as
> far as i can tell.. but there are also 4 other kernels (not to mention
> xfree86 which i haven't tried yet...) to be had.
>
> can someone explain the differences between them to me? will any of the
> others run on my pismo? is any of the others "better" or "worse" (no offense
> to all the coders involved)? should i just be quiet and happy with ben's
> latest and do all of them plan on merging at some point and then folding
> their code into what's available at www.kernel.org?

Ben H's rsync tree and precompiled kernels contain very recent work on new
PowerMac hardware support (AirPort, Pismo audio, Rage 128 video). If you
have a recent Apple machine (iBook or later), Ben's kernels may give you
hardware support that's not yet in the other development trees.

Once they are tested, Ben's changes are regularly merged into Paul's tree,
which is the main development tree for the PowerMac platform. If you don't
need the very latest changes from Ben's kernels, then Paul's rsync tree is
a good place to go.

Cort's Bitkeeper repository is a development tree for the PowerPC platform
(not just Macs and Mac clones). Patches are regularly shared back and
forth between the bk and rsync trees. They are also merged with the
mainstream (kernel.org) sources, but with less regularity.

For your hardware (Pismo), I'd recommend sticking with the rsync kernels.
Use the benh trees if you want to use (and test) the latest experimental
features, or Paul's tree if you'd rather wait for those changes to be
tested and merged.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.4 problems

[Martin Costabel]

Benjamin Herrenschmidt wrote:
>
> >On my 6400, both bk-test8 and pmac-devel-test7 are running nicely. The
> >one major problem is random sudden freezes that can happen after some
> >minutes or after 3 days and which have been reported a couple of times
> >by others, too. It is like the ADB interrupt dies. There are no
> >messages, the computer is still alive, it goes on compiling or
> >downloading, and today I even could ssh in over the net, but locally,
> >keyboard and mouse are dead, even MagicSysRq, the only working key combo
> >is ctrl-cmd-power :-(
> >
> >I never saw this with 2.2.X kernels (not recently, in any case).
>
> Interesting. Do you have the new input layer enabled or are you still
> running the old keyboard and mouse drivers ?

I am now running the new input layer (with old keycodes). But I saw
(rather, suffered from) these freezes already before the arrival of the
new input layer. For a while I blamed it on Xpmac, where I seem to
remember having had these even with 2.2.x kernels, but I am using now
XFree-4.0.1-fbdev.

>                                              If you telnet to the box, do
> you still see ADB interrupts increasing when typing keys or not ?

You mean when I type on the local "dead" keyboard? I couldn't test this
yet, because the machine from which I sshed in was 15 km away at work.
And after a while I had the bad idea to type "hwclock -r", upon which
the 6400 was really dead, so I could not test it any further. While I
observed it, the ADB interrupt did not increase.

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.4 problems

[Benjamin Herrenschmidt]

>You mean when I type on the local "dead" keyboard? I couldn't test this
>yet, because the machine from which I sshed in was 15 km away at work.
>And after a while I had the bad idea to type "hwclock -r", upon which
>the 6400 was really dead, so I could not test it any further. While I
>observed it, the ADB interrupt did not increase.

Ok, so it looks like Cuda gets dead.

Iain Sandoe recently did work to improve the robustness of the Cuda state
machine. I didn't yet have time to look at his code, but it may be
interesting for you to test his patch.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Discrepancy in BAT mapping?

[Takashi Oe]

Hi,

In arch/ppc/kernel/prom.c, frame buffer is mapped via BAT with
_PAGE_GUARDED for 603, 604, 750, etc.  The same value is loaded to both
IBAT and DBAT in arch/ppc/kernel/head.S.

However, in arch/ppc/mm/init.c's setbat(), G bit is stripped off for IBAT.

I suppose it doesn't matter too much since it's frame buffer, but which is
correct technically?


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Discrepancy in BAT mapping?

[Michel Lanners]

On  10 Sep, this message from Takashi Oe echoed through cyberspace:
> In arch/ppc/kernel/prom.c, frame buffer is mapped via BAT with
> _PAGE_GUARDED for 603, 604, 750, etc.  The same value is loaded to both
> IBAT and DBAT in arch/ppc/kernel/head.S.
>
> However, in arch/ppc/mm/init.c's setbat(), G bit is stripped off for IBAT.
>
> I suppose it doesn't matter too much since it's frame buffer, but which is
> correct technically?

Hmmm, setting the G bit for instruction pages should never be necessary.
I may be totally wrong, but as I see the logic, your instructions are
not supposed to modify themselves when read. So there is no reason to
protect them from speculative access. Hence, clear the G bit on all
instruction-only mappings, so speculative access may be used to a
performance advantage.

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Discrepancy in BAT mapping?

[Benjamin Herrenschmidt]

>
>Hmmm, setting the G bit for instruction pages should never be necessary.
>I may be totally wrong, but as I see the logic, your instructions are
>not supposed to modify themselves when read. So there is no reason to
>protect them from speculative access. Hence, clear the G bit on all
>instruction-only mappings, so speculative access may be used to a
>performance advantage.

Well, who will ever execute code out of the framebuffer anyway ? Also, I
beleive we can remove the G bit completely, there's no need to prevent
speculative access to the fb. I'll look into this.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.4 problems

[Michel Lanners]

On  31 Aug, this message from Dan Malek echoed through cyberspace:
>
> Michel Dänzer wrote:
>
>> Haven't seen that.
>
> My 7200 won't even boot.....

And my G3-graded 7600 will only boot one out of 10-20 tries. The other
times, it dies at random places somewhere in init/main.c. When it does
boot up, it dies awfully while processing the rc scripts, with the oops
not showing any apparent problem. That crash is evil, since all
partitions except root will appear to be clean when in fact they are
not.

Which means major havoc will start to appear on my disks if I don't
force an immediate clean fsck....

I'd help debug the 2.4 kernels further, if I could get past these two
problems.... I've just now re-rsync'ed Paul's tree, lets see if there's
any difference....

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Platform configuration (was: Re: CONFIG_PPC != Mac)

[Takashi Oe]

On Thu, 31 Aug 2000, Joseph Garcia wrote:

> Michel D舅zer wrote:
> > A few days ago, I rsynced linux-pmac-devel and tried 2.4.0-test7(-pre?) . I
> > had problems with the network, no TCP connection could be established. Anyone
> > seen this?
>
> When I tried 2.4, it takes forever for a name to resolve.  connections seem ok
> once they are made.
>
> My system also seems to have a fork problem in 2.4.  su hangs for 2-3 minutes.
> strace tracks it to a wait that seems to have stalled.  Often, logins and a
> handful of other situations do the same.  I mentioned this to Takashi Oe, as I
> first noticed it when trying his NuBus 2.4 kernel, but he told me it's a 2.4
> thing, possibly relating to VM.  I don't think this is related to the network
> problem, or could it be a wakeup problem?

At least for NuBus kernel, the main cause was very slow disk I/O.  The
latest NuBus 53c(f)9{4,6} driver is much improved in this regard.  I don't
know if you'd still see the mometarily (however long) freezes.


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Platform configuration (was: Re: CONFIG_PPC != Mac)

[Tom Rini]

On Thu, Aug 31, 2000 at 06:10:55PM +0200, Gabriel Paubert wrote:
>
>
> On Thu, 31 Aug 2000, Dan Malek wrote:
>
> > I would also like to see us spend a little more time trying to
> > stabilize 2.4 instead of trying to solve elaborate configuration and
> > boot schemes.  That is what 2.5 is for.
>
> What are your problems with 2.4 ? I'm at 2.4.0-test7 and I've not had any
> problem so far, although I still need to upgrade my modutils.

Here's a few: The PCI resource allocation/conflict stuff has "issues" with
some Pmacs (7600, Yikes! G4, I don't know about others).  And my powerstack
series e doesn't get beyond loading linux right now (I haven't played too much
tho.)  But regardless, this is a 2.5 issues.  I'd be very supprised if this
gets into 2.4.0 or even an early 2.4.x.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Platform configuration (was: Re: CONFIG_PPC != Mac)

[Dan Malek]

Tom Rini wrote:

> Here's a few: The PCI resource allocation/conflict stuff has "issues" with
> some Pmacs (7600, Yikes! G4, I don't know about others).

Geeze, don't even go there.  I have some really cool multimedia boards
I have been trying to use for months in my G4.....after lots of
resource conflict messages I discover my USB has been "reallocated"
to the bit bucket.....I would like to do some FireWire, but those are
PCI devices, too.  I haven't tried my 2940 SCSI lately, although I
suspect it is more of a driver problem than PCI related.  Works great
in 2.2, crashes downloading microcode in 2.4.  I am trying to collect
useful information and make sense of this, but I am having trouble
grasping all of the changes in the software and the configuration of
some of the G4 hardware.

It seems all of the standard stuff works OK, so I will just put these
projects aside for a while.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Platform configuration (was: Re: CONFIG_PPC != Mac)

[Timothy A. Seufert]

At 6:44 PM -0700 8/31/00, Tom Rini wrote:
>On Thu, Aug 31, 2000 at 06:10:55PM +0200, Gabriel Paubert wrote:
>>
>>
>>  On Thu, 31 Aug 2000, Dan Malek wrote:
>>
>>  > I would also like to see us spend a little more time trying to
>>  > stabilize 2.4 instead of trying to solve elaborate configuration and
>>  > boot schemes.  That is what 2.5 is for.
>>
>>  What are your problems with 2.4 ? I'm at 2.4.0-test7 and I've not had any
>>  problem so far, although I still need to upgrade my modutils.
>
>Here's a few: The PCI resource allocation/conflict stuff has "issues" with
>some Pmacs (7600, Yikes! G4, I don't know about others).

B&W G3 as well (same thing as the Yikes! G4 really).  I have the
following problems on one (latest BK 2.4.0-test8 kernel, as of a
couple minutes ago):

1. Resource conflicts are reported for the CMD646 IDE controller and
an Adaptec 2940UW card

2. During the fb probe of the Rage 128 PCI card, a pattern of colored
characters is written to the screen.  This might be somebody's
deliberate debug output, as it almost looks too regular to be an
error.

3. When attempting to do the partition scan, the kernel has massive
problems with lost IDE interrupts and failed DMA stuff.  Eventually
it gives up and moves on without successfully scanning my IDE drive.

4. Probably due to the resource conflict problem, the aic7xxx driver
doesn't recognize the 2940.  This is a showstopper for me because my
root partition's on a drive connected to the 2940.

   Tim Seufert

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Platform configuration (was: Re: CONFIG_PPC != Mac)

[Benjamin Herrenschmidt]

>
>1. Resource conflicts are reported for the CMD646 IDE controller and
>an Adaptec 2940UW card

Please, send me logs of dmesg, /proc/device-tree (with lsprop), and /
proc/pci.

>2. During the fb probe of the Rage 128 PCI card, a pattern of colored
>characters is written to the screen.  This might be somebody's
>deliberate debug output, as it almost looks too regular to be an
>error.

I noticed that too. It happens only occasionally. Sometimes, it's so bad
that I never get a single correct char displayed, sometimes it just
doesn't happen. Note that I didn't have the problem for a week or two
now, I thought it was fixed. Sounds a bit like someone is corrupting memory...

>3. When attempting to do the partition scan, the kernel has massive
>problems with lost IDE interrupts and failed DMA stuff.  Eventually
>it gives up and moves on without successfully scanning my IDE drive.

With the CMD controller ? The mac-io should work fine with the current
bk, the CMD still have problems.

>4. Probably due to the resource conflict problem, the aic7xxx driver
>doesn't recognize the 2940.  This is a showstopper for me because my
>
>root partition's on a drive connected to the 2940.

I'll see what I can do.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Platform configuration (was: Re: CONFIG_PPC != Mac)

[Andreas Tobler]

Benjamin Herrenschmidt wrote:
>
> >
> >1. Resource conflicts are reported for the CMD646 IDE controller and
> >an Adaptec 2940UW card
[snip]
> >4. Probably due to the resource conflict problem, the aic7xxx driver
> >doesn't recognize the 2940.  This is a showstopper for me because my
> >
> >root partition's on a drive connected to the 2940.
>
> I'll see what I can do.

For me the same happens, the root is sitting on the drive connected to
the 2940UW.
The patch from Geert which you posted to ppclinux.sourceforge.net would
solve this conflict. At least I could boot with it on my 7200.

Andreas

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Platform configuration (was: Re: CONFIG_PPC != Mac)

[Timothy A. Seufert]

At 1:02 PM +0200 9/1/00, Benjamin Herrenschmidt wrote:

>>3. When attempting to do the partition scan, the kernel has massive
>>problems with lost IDE interrupts and failed DMA stuff.  Eventually
>>it gives up and moves on without successfully scanning my IDE drive.
>
>With the CMD controller ? The mac-io should work fine with the current
>bk, the CMD still have problems.

Yep, with the CMD.  I only have a DVD-ROM attached to the mac-io
controller, when I play with it tomorrow I'll watch carefully and see
if it's being recognized.

   Tim Seufert

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Platform configuration (was: Re: CONFIG_PPC != Mac)

[Timothy A. Seufert]

[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]

At 1:02 PM +0200 9/1/00, Benjamin Herrenschmidt wrote:
>>
>>1. Resource conflicts are reported for the CMD646 IDE controller and
>>an Adaptec 2940UW card
>
>Please, send me logs of dmesg, /proc/device-tree (with lsprop), and /
>proc/pci.

OK, finally got a chance to play with 2.4 again.  Here they are.

>>4. Probably due to the resource conflict problem, the aic7xxx driver
>>doesn't recognize the 2940.  This is a showstopper for me because my
>>
>>root partition's on a drive connected to the 2940.
>
>I'll see what I can do.

I managed to boot 2.4 from the SCSI drive and get the above logs by
using the hack Tom Rini suggested (comment out a test in aic7xxx
which rejects improperly configured PCI devices).  Thanks, Tom!

Booting takes a long time thanks to the cmd646 driver taking a very
long time to figure out that it's screwed, but once it's up 2.4 seems
OK on this box.

I did have one further problem.  Since the installation on this box
is LPPC 2K, it uses labels rather than device numbers to mount
partitions.  Label based mounting appears to be quite broken in 2.4,
it couldn't find the root partition at all.  I think I've seen this
mentioned before on the main linux-kernel mailing list, but I'm not
sure.  In any case, I just rebooted the box with 2.2 and changed
fstab to mount by device instead of label, and then 2.4 was happy.

I also tried Geert's PCI patch (the one on sourceforge), but it
caused a kernel panic during boot.

[-- Attachment #2: frankenmac-logs.tar.bz2 --]
[-- Type: application/octet-stream, Size: 13591 bytes --]

begin 644 frankenm.bz2
M0EIH.3%!62936=7)/#4`.63_@O_Y,#!Z;________O____I$```(8"V>]#WK
M=VON7QWNO=[WMU[/9<`'H!][QP?$\/>W!V^^^?/3'OF^][SWS6ULVM/EOIW?
M=CCUG;=N?;TJ$+UA??;WWS1WU<^V[6HV;=;O=Q5[SKUO5I5ZYQZ@Y9Z][=F=
MZ=Z\'-N[NJB/3>@]%VI;.J.W7UR]I/C:^[G3SVCA)$($TR9-`!#0`FFDP-!-
M3:F32?I3VJ>IIZ@]3U,Q0:>IZ@)00`0@C0$U3>02>B-&3U-J:;4::`T&FF@`
M`T`!IB(1"GZIY$GIY)J'J:`&1H`&@``-`:````DU((@$C)/*GFC0D\U,4:;4
M`&0:!H`!H&@``$22`@9$`AE/331"F]4_2;0"3:A^HT0>34P@``TT`)$0@$&@
MFC4PB8F0D]E3PHV4>4/4/U3U#U`:````_T#]?]/]?_WGU\#WYD%KQ29@B7"]
MA*"!ZO5\-D#8A\*:"3T%T+,72_HJ]O3CJM"2%]R(^D:(DV,"BY8%`M`A2D8*
M00($6Z(%UD1J5`6D5BC4*"0"(L,8(E(L44C`%D@P)!5"($,I0JR`AO$4\HBE
MK*B8SW_$']GKL.IMER>6@B2$NMTOJ>YCFL+BJ"1#5<G(V==ZSGA=WQA@YJ84
M'S)F33EIN^6,C?_'+`D%$E%AF%YN]RJ;*Z333>:<SFV'@I[Y4=2^QCL`#7$`
M;P1J+0<.5Z;6$-W-U77S_7C6G`P(AYD4-R@7P;4W)2I:Y/C)TO)D5M04,D)W
M4""4FBZYSOTCLJS1O!A&5`TP[66`BKU[=BY(M=Z#<,@OWTM3HOPL719D-#E0
M%#:(<HJVJ+JX27GFZ#_O+HP8WM014JK"[.4KB5-8RAVO",PL62<&"F.V)0\L
M=MP[K8A<YF&I85IN2"4)AUJIW$#8@<PPBY7G==,VDVIY_VX/8Q7#CH'2[U4;
MJQ5&**Q=$FB,ED\]JN@7CPW[:=L72X@;@,*C]=-]5K(:,ML"!C4X[],=8$@9
M"20L;($56,7MK;Y6/A_@Y33^5]*T?RX?+D'9F(/JJ_NHS7V'"R>&[XY_ZPYZ
M;ZL]-7\,O7Q4?5TS_\+7'$4TR/VT@X^1AYP:G\V-*@GON>++'83+Y8OKINI[
MB5,(YU_TW\WEDD0C$A67S3_KMRCB@S0W<W[*?'FD6LYXIRL3OY4`/$(""/`B
MH<8"BNR(\:ZM_(Y_E#R/TM9W<<,<?R3EQ)!(1ZF0DY/;'H+[.H@N:2;\8PF\
MJ4E,J-48;5'9@?'NI7."3-$I2?":P*)NW4?<M1HEY$5#1B5<LE)3/GZWD]&D
M[?)N1UJJV4V^R[GIEH_N1SV=_"4Q4^F*V:6^9OF0->3E,L67JQ8Z4D@R^;)E
MXL*<P(/ZM^N!?D8VO;E]\O#PMP5`!AX`OB43%[**5!HT!'5%0'")P+5R%5(=
MX$?2#$+C'+,?3D<(?QY!MFXSB09K&SP`[LBQ>X<T\[HS%?3&R1YSD]OBD_JV
M]TO)&DRL!NA*\(*3UD3V1BA)"))FOH[*6].GF]/Z?DAXX]%1K"_%/"GQ^[)T
M2G]7?S`8J^B$W)T=[K_'2O)T@4&'ZJ='E#5T>KV._VH70L^_)QJ#7IJM46/;
MC&N)Z;K#42(J)4I8<`H*A@\M:_"PE52<)HFP>PWZJDI;>:B=5.W&@(IGWV<W
MX"?G[[.&AQK44\Y,D3(6S/)-;AH;%YVOF<9[I*FL1NYQ?EC.%T":N=6)$6A2
MXB=#HY<XK8RFSC%!=$GAQ4VC0F@,7:)<8^^Z9:=C-E-&832N71QH#!NSEL-B
M()G&'+.%(,G4LV6P^[?E0UNX7TPB@9T]/!))(HXQZ`4"`84JV3-5-QQ<#5A7
M/'Q7(*VI81<W4/L+50)_#"G3$_?5&GJR0+8_,WZX\U_>+$4AV..^$]T\C(/W
M/.1:CC7%75[]/=J*K2:'S=+A7^?16=G/^?J8RV&H@^@9QGHXSH?"5K:=KS[Y
MY,AVUY97$M??4!335#A5APFJQ5VRMQ'%4=ZOJKO?PRQMC/9B(]S=TY//%HV9
M-?$))(S\=<./<;*]>(G)Z78LT8MDJKNN=LP\,KM?%QH]O'=MVD&8B:&53-,Z
M"G"$;F1V,G9,3-L6R%VNB7N>Z>&RO@=QKWBU&-FZW4XP!C=^UB0P<.#\:#JM
MYYZ43(\]WP(<B4@O:!!$>+GB=M4P9HD/AW^*(KRS]@RQV;ASTLL7S.=HUR+<
MIZE'#B'7-KS]D>5%CC;!3[E"<D11#]%##RAJ2\$<B*29F#^B:?F'\V@=3,M@
M-4ABZAMN7+EHXNZ=9Z.:QPZY6SK&E>E-M#ZB.<3PGTS>95_Q*:3EX;^J[10:
M&UDP1P/KYIA\#4&;9)9&TZ7O!LFM[>`J@@9<03UQ#][(.SK+8&9MN=RH,G%#
M=QT&]Q>3RN,/[(>5>P<[;=%G*743W&YC<_(L6;)K%^/O/F&#$VX![.?)Z1EW
MX\.79\*C?WU=]8#1HS<>(ZIINR?SV]_/&G=*DL8LY&+<T^Z-5NT-[HP[I[4*
M/\(PWUG5!&[.ZUXL+J%70Q:!&S?[$+17VH;.S$$39CP8R\ANAWW?I$[FT6$:
MWJR:J+-VU\YE!D>PTY/'HFGT)';0S,S?!N_AM"SCZ?0^GRRZK4=B^&%^+WE(
M:1D[C]B81[+)KDQJG>9/-"89=3#1IR,XL%%H)@!H6!IFTK*F'*J1<U;%$6,W
MFJ4$0V1E!AS34;!BU&FF!+E::,2AIR6D+!#+9;^@>P#CZ_FW\4>"$6;:)/[/
MEN6ZG16%<#68,/KO/DN5&,;?'V[DEL\RL'U%V&67J$)(MXM.D_Z1SW=/9>@)
M#;6(]C`W1#KXT^C7W[N2G/]FTHR+^E$]5K(8Y.6S@SX]T)-&.4+,M6N=VQH7
MK-08_RI/88QL:M'F70/D70/MLH;;A7&K$W%*5'AR94+"03._IT<X;8FMAP:(
M,JYV;66<IE^T]$+?.^02]->)HV#ADN,@9(YJ-ZA^W(E3X32WL'U!QVW!GV3$
M;W!9C5PV>\E$F;N[7S2XM092>J7L99`D%+G1]G/=1RV:2BBK.;U5<"AO;L4G
MQ(2\CWZ>9ST7?W6=(Y'U<USLOF;/RZ:2\6/<?UIFYGQ.[^/%L<$;X.KOO99P
MY!G3A*S7;.S**J/Z.690#C-)\M=:G3-/;A1-<[/[\.R\?[[\JN(L^N+R%M*)
MICCPNQ70E%_AY*[&UVWW]TN$9]&7+:,T^3)DB-7&46^[$]F[/[>:S'MNTK)?
M75/FG@S3:BX[\^%<B:9;O,WT1E[_HW/)Q?&'^KU$GM=O[3UT^VX.,[U5KV,F
MG?#(():#.%@Y%'.\N_<K!,J]R")0%TX%3"1A0%$$I(%$21"))(Q5*)8JL$.;
M2$F98,$DP;%?6T&:-R[D**2<MD@7*!%DT00&R"8HHZ[+6<H4TM&&M:NB]_GV
M<)`^L@JPG-T75))L`1R:#NS\HM'N^?AV/MH>^^(8W#L>=33"UI,@B65E>:DY
MNTEE<6$+=?7JSQ6M.QJ=4\XXCW!54:_=^_KEX=^?W7*QD/=?D^'-/.33/#(U
M<(??X8\_75AFK.S?B;13/Z(E'P^O)H@_A$Y\B(A@S`Q<P^/->9R01:3QA@&6
MKBR+*4KR:#^\/KR$`Q1/DF854Q,WE%(;-"75Y<[7Y;'F8V]?@BES1X6&:<XY
M#"G9*RB+F8/EL)\L@]AT?'H,GTH]R-QQ@S"Z-?MG03(M1C1V%KT[.7$0C/7B
MK.XA#N:>;VMONMLX$55<%X30`W0JY5I.H*PMSN!RP(QCPPI!]15@G<&*U#LY
M<=96ZM^.@FY'C>?EMAL6KIHO1B1-H67&N*X,@\*#3-#<H@XW&XV#(EIH6-A=
MYJ*RWD2#-D)+XS4WT3C=M+D7JN)0@HD8CTMB5(U2U=!R87WR,U80^SM(6-`S
M[R`V5SK3DVUK9+2[`U?-6*!RP1@)(&G'@4!B\FN67Y+X]&]P\;>44.3OX<4I
MIV4\.R",\>,S]EF5=$\YXXMJNV\CF=)BYC%P3,J2R"_BR)]_\^W\S;;H[!O'
M!5`*T4!,<$[E.U*RF\$.HB71XQ*B\92X^5??U.";KYBS/BM*NST(R631.V,>
M(;&A'&O:>GR(.6I%IH.(Z>^#,N/7M8:Y*@]?$.IURL,Q1L94TEKE^@O0D$G[
M)VXD--S<KQILAG(V94.</L#$\K[>6!X1LX;"U@$/AI=0>4[<KI0CZ[@.H"($
MB4DV(5*_<A(.4XVLVEPTQWF*94+Z\=D*<9$X!D-MS>`.MU`*H3E;9"Y]!Z[)
M71QWY9,40>:I9=M25Y2BAKV:9P<&GQ7F''A'9QQ+)LDU.5;@N!Q+5=PX2&$D
MA1+)0U9)%,1Z+;MVVH6+H%>I(80G",LXD&W4I%0%0BJ+UN9"A6U\53NT3#^Y
MLURXFNX,Q8T6(<[1OM=]7HT?RE<Z<=L>%,(PS+^T&L7Z37Q"(BF-NA\I.F''
M&;CM;I;/#(.A@:LA11Q8JFV"BH9$FB@^#?O;W8H]RJ.$HH,,T9>'8)4#")!7
M6M"R<M#IV[0W!T:B,B(J)-W[3ND@F!>YK\-#!DPT`D(@Q82XAZ8A12.AL;UW
MV3$7J@T44TU17!:,4+$US6U5D!:Y.;SYK"P(&$D#UL+OC50N[G32VJZ%PA5I
M)D@\<3S#(?9BHB"V3X&6&..WM`MH.+WHLP@&M6)B](:IV)1I?3;6<KHD3*%K
M7=4="Q<BQ&*2-NFGPH3,9VSS>2IS@DH^%*4*6E<;T'<^/4@%8F]#@R%,M;O?
M=JKRUC!;X$W<$XH;Q((SK@P6;ESBB#-$$`9,1:S:B7+'$9S+D$$B-J8<98",
M&(B2C+L0S*4%H@[G"M6!+4E(DFQ"60@7=62;$I(60(;6$U2<V]T[;@;]2J*E
M`Q!!6,X5*;<9B1;MO9:>$1EGRP,.N=CS(5#B.`Y)@B@TR3FQ#'NEF1*`WR@-
M_8FW+>[5PTX81#W,!@R)TGXW*#=!6<7+&;]^EU3"T^KR?HIZ.=[Y.(O@08.M
MY`>O^KI>&?Q\:9!#0$)?LJT01"BD-E)@^J;I'E8IHQ))'J=JP5G!D^?QIN95
M)U&Q#";Z%R["/FZ7W(I&3,%14OT<1*4+K"0V''@\8JTQ2*AU\NR%Z%Z;1I$(
M"*+-+.*%FHYHI2U&=%TGM!)K+@U),8*S=("+TB+A.<2`X7Q23`/5&%2LP%LJ
M3E2J<HU2=FK,*@,8J7D%@8OE,?*&8!"]Y0])J!KS>KNVE"$\8)VZXZ?'XA_>
M>31,WD!W5.J;IN";,V?-E66+R?C8;.?`:8T0J]>*KKHGC7_-*JE50WKY@>2K
MJJJJJAC-NO?VR$WH&]E[^"_EV\7/?.]W\]PV9.*K?"$,,!K)XHITR9,F[B^R
MP[0%3WB]Y>W.%NNX6</2_S3\F:7K73Z)6+76<YIFEW<^SYT'%F]\&4@;A&@P
MQOX[/V_$&47S$!V:X;SX4-2+?"H5623>4U"R*=!>B83@RW/7E=%%5S@HY_%O
M*&/4N.^E"9?N*,/@8TG1PK.-CAU2'OF!E2#<;+=G/'G[*K??"-XPY;-3!:^4
MPM/4\#8L5D#;#VOR$#V+'K#(1$A\\47KJ8G1USS!;);KBM`8*K&&(.QM9R`)
M7K)!9$6JJN*E*[5Y_X0PE;#]AJAQ#=C<^+4T5@]<1?9MG(DCHT,)0'($W.@K
M@S.LJWYG&GVP'#AOTCNE*%JZXE(6ZQFOD&5@<N-/!FU4E#"22-IEH6+DO>!7
MT-LIN6:J!A1S:.JAH[1A&5)PTPYWMQ(P0GFN4A?PLAV%^5`*7/3G1!Q1/?@L
M#>JQKC[>L5[XT<L,;SN?WDQR&8-M>?9S\$7(.K3"8%$':,\<]N.PMM\J<H92
M.V),0X:1L#>U,H[*T)ZGCZKY6]4JJJJ*,R9*K,X,\5QN@]ZOW'B3A_B.(2<0
M*>7OY[R:2HI(X9J6YU)7Q=%MK,3RPZ6]("$,ME%&NYZ^GEMV%#(^W469@YTK
M6)VC?B@$#':)$`+S.&@E$MUK@/>MMVB-[=Q#4Z9HX]VZ-EH<)0'!O3[SZ%"O
M/8?I\P34DQ9LX&4+%0$1%+'F&WQ_/U.NCS.SA?.RWF+T=NOX,F/)MIX=6+0F
MQO*WY.T7:T9#2I$I,U9`0XIF0%`\YQ<S5*QZ#CP-\AWX9.;)\DSDJ`'.>#KV
M*4M*DF98@ILEF%>[,ST&(3\_A?2"J'G.*Q-=.7?[M3?:RO=,71R16@4HH8\"
M14])YN5"$;]BO/ROW0$&T-D92-@TL-&Q8Y5A4D)P2E&XH5K98I9*`H`J+"&4
M;,XXMW/K>4U7%3L'[3>N\%?;L.+QZ:F=HYZ'*^]'9WG8W0&PH,<1SLUE>O9S
M8M/J4,$%F&KVYR,E3R]$G1:,:\A-K'L$W"18E9(X2,=]8VVH"ATI`L(Z5];)
ME"5M=3&IE@\KQ)E9,^SM5^J5M2]<VV5.'B9,L5!T+H>^:733AX;&5I8QU9B7
M5Q=DDDB[?C;!]8!+P+J^%HSO@B:K,F3C/;7D(5M-<2.+P%T#C+X&QFPX'0B'
M7.94#B&Q076MEDB"HW9U;%9WH`-Z^J12,BTP04U(7@")`'@F>:\YH@$M=YMC
M)(DV$6&%?C&P""$>HW0"W1I*L70H*+#<^(1ZB>7GN<02Y='L2F^YV:D(*DT5
M6E:"(\X]T".P21]!M`<449#R<%>F,W(R=F(/"MLS7"<UV9&VADN[2JK15.04
M6C26`3:&N]Q,KJAT9QN0LQ7KXK&<5MK3EN5E#?CLR3T)+86=;Y,NHS<UG=QO
M)8-X+!KLQ77;6QJ':QT%2TF+QM%:=A:?K3*<(G:@5[3AC)QZYOJ/LQ&/%@F9
MD(QMI0&7AL\2#K2#%)K&#<EN0%F4TZ0@E>0"D1)W%72YT!`X5+[Z&LNUN=>&
MXYI3U//T`ZZ-(CXQ]'X4K51.>>UR=!6D[((FF)0D[.',0G-UU+ZG8:TZ-Z9G
MS$X>?"Z3DB,UPJ]GCR+7X>19/+3DX54J2!(^%-:/XX]ZB6[(M]PX#$448BBB
M>/65R,G";\&)+EDY=3XL;KE8=8"Z2OVM(BE\A/25W7-8.YBVT"WRX;OY>S<K
MJ`_[43ADLD'I.49KA!DUS9YPCO(Y(1@B[0Y%,AVG30W"(!Y`Y(AQ.F$!KVGJ
MWZ>*2J.G-,-O4%HKB([BP8A[JH7BK&+-!/#+6-3NKI1=$TFMQ/)#4'4B0:8>
M:O@Z9G:R=1B3V&)\S3UFECSHWKT#?!*@V1V-0Z.J0%#$>W3#ZSJ]ONCE8]U`
M\FG3>F#J+,JWF[\5&\_;]'3;T3/#%3&_?+FM')2*\^VO;BG8TI<>*7!4!/B^
M(Y!]@U6^IZ@TB-ONW+QMXHWFU6PR0=BJ[YMK3X$$CQFW%9#J@941J+.,N,)'
MPS,;X"74A++V5$_L0%6")IE*S8:/N:P[R$M7NOIO0.AL9H];K:X!IMQ.>U(.
M1'API7HE@A]L:5CG^+F+&-%URYU19FX*8[L@J8-(V/M:WYY</)PVAOC[!)5A
M53U%5>"D@*N!;JZ*+YTVTT_ZU_/]GD"PQ@:"`<0GWL#^YPC+Q-BZMCPVS_/R
MTX3;.=,)BRBNJ*P2E]"H>=C0TK"#/6..+0WKDFV(C"%8Y<D)#U/"0AR]O,5A
M&0C%$4F`W^@G\WVD^*>23T_XX%NVOR>X,>^W!A<;;[WYXGXO']3^R8/[O^?W
M']FU^U,=:*&=6%HYV+]222),4FWIS"9@*F,_X0_#\E65'VC7>6,Y6FT^$H&:
M:YGV!D#/J55<B3P&)!2%^KTN5V*L![K5]?0%(Z3-[GD-&OZ2%FW#W'"48&"S
M=S^YH[!F%X&[*E](`/(D7<B=I2!!M+R%8+^S@1+?]P'5S!F:?"_/+TO,4*9R
MPH?*PO5'`/Q*$^)SD-'ND[RT,/-`0IB&Q#*G\"4Y!"(%0-X['XQ@PG=&C*](
MBO8<\3)]]H0;9NM-F2>.6@$6LV3XLT3Q23,?#GO1NTA(`XF0MV\1H-\V+A`@
MR(C#YDB#T(Z&-B"#^CS:N&$\W+%SI":E[EZPH3L_.?GLO!@')YJLDR7['T(=
M7CRP.]$UP53O].ZNL^%K.8NZS%[KR"A@59_Z_1M@0FC50T/(9]&/QDK0#FH"
M=T#6"Y2+43L7/AW4S:Q>W#&?/4Z==JF%*=;P\`<^X^[3`)-C^BX\9!'/XQO9
M7#T`$SQ(#M@5KKX!!=V)Y)CT1[8/O?&BL*@ISH&AGR<Y-J<0.O=O9LC:/%(=
M5PFD@_F/M)Z/V]3SX=$Z8K]@1#F);GULENOPC;7ZN<]G</US6"&`#^.WM7D,
M53CM]O+]C-VPO9,PWU_30@^GN\4@HDD6#R\W[[^%^XGHM?H,>9?HV+W$(<)+
MJA,D_(OJHOFHV_)K\<Y0-4*E8,")=$R,(V>8*>U[O253Z8]?W2ND_0QW?>?:
M!24O;7K]P5^CZ'D`JQW$J@2X;`*1D*0?4(DD&PG/]'*%]R.'TM@O@:SS"\7@
M8^23(;_,`<"H%4BOD7GMUXH"^RM,(&W3[UFS`VV+?S=%F\V.2BF6C1+;JF\S
MSF8#,@Q"2!AB1Z"&9EQT,Y>H@]Z]IRLMW<T4-C,T5[`.R0=*"`8&(8V)V$4,
M#T&E(F`V..#=ZTI=$S]O,8#]7/H$1YQ\XGNMV).I<#`5]U)@^\'L]BCU5V06
M1;`56O/@Z]_/3UPL3;)0]<]`LF(6$U;?H?D_T8P9F#1O_>U%SU93>B=G(&!M
MH9'AP1Z3;\7N_%7U5(@;.TD;HY:HVS`@)T$$3?-YV8O]$Q-3X_4>!FE-0Y88
MQ11S026&OM$O?;Y9*H-==*X0!O(R0*]`-@V`=R),R3YR@&$C)*4;K1:>#BD8
M6@T8CLRX)$(DA0$9`0+"8H!="/.3[V$8JZ"I[SSP88'D'Y7W608<E-NOU>AU
M2+`Z$FSSND)(@#+A-22@/MVS%(;:0'!(N8T=@J'#S$.WC1BU#Y_#SG;IKZD5
M8,B%^>U0,0]FQ%C;&!;\7[:")%%=/9(2Y#Z5-MX3XQ9F+I'6"TC%#LBHGM+Y
M=8`;]YAL`"U]D53Z]8\W9QB,F<CTIC4R58&T-#8\]%2UU_R_=9-R[MVH767X
ME5^0@"'#3>&<2R5$*2HH4]5&A;6G5:-F^RU9?;O\PS0YD(51F/KF3!`G`P/&
M9)8V-.-"V4O-?FUGO=RY15[[U]G.%`7DX@6H;.\VD4O5L-)K7*PJ<8@:Y$2$
MI,0IF'W]*T1[((]!%FW857R2M@8H!=["A`T'KY]QLU,,T7UM3E3RF`63.@KS
ME\5"K,45&`AC`U8HQ/G?F\5'/TF=..X=<^B2[:X6Q&K;#+6]N2.:9S;H@X#D
M4S`)Q=0LRS;3<<:<HD@DST89G<[9:33+1C)"&1B#X`=$DA$(M\A*@&FFEO#G
M,G8+VCFCRJX#H"ZY/AVI*-J0%,4-UZ*%*I9JEW(I&[K/>ZS=M*<W88CLHBEB
MV@&@#TL`6=BJ"(,B)KG`CZ[%0I;C'^WM%^E>]2`4(41%ON\$'19@6"UAMZ/"
M5PJ_#E@JA8FH.HN:V6%)`ZDFA2\;0I("&8"%:Q1U\3!9<#,B!6-H(R$$,H,:
M.@RV:3F7:&<!5U(O9=(4+LELL\V$@I!=4S>8RC2P@EW)X;09S1`H9.F$BDV*
M#3`<;!41$"$8(BZH49@$"@>)U%7Q4!Y+ZC41G7O[IVY2W"<*%[-E6?1]FCE@
M6`1>%:.E]@+TDB:K[`:P)+IQU6SAB59?D+`&?G2K>6LB2H&$W+\"Q;*(N7FU
M2F7C5XUG)D)Q"L$9!MI060AM%BL^BIT@5Y*(B!T:@;2VH0=@)`/LB(<$@O1$
MWISZ\VB9H<0/)+UJA`M&$!`D0$RJ>]WX:(!DX[S>]@P1DJ2?-3;.L\IR#<CT
M7.G`["($6NP'\@>)[Q/K4`<W9O,7>IW40CNWAQP0&Q))(G-&:J"".Q&=M0L$
MO4ACUVCE7`>>(:Q".&P)5]KF0[0*-JM<UD,-A@-S8TF\"P&B:-Y9S^F`JG<.
M_LO5'0L)FFEW$I*ZA0[IBPPZ7FT;QRRU[PO$8!ZR6O@+Y3?'Q#Q`YGEI!@F"
M"&!F'V00\L^0TAH;>@VHWH*!H'<'7:;5LQ1S&8K?HL6)BWAW].YN%5+P;REQ
M0XW/I3'+FW!V1'F7Z)\7MM"QZ6OWDI&UWP6+=A-8&4/5&+ZZH?==[?8';OLL
M5C"*/6,"4S"(MG[%-0!F0W%C%MR]U?-1K8?V6CI7Z4,#V6*%L`,B=%I>#C0"
M=_9V@D-?Q>A'/VJ($/Q&E-X-B99T,E^,JM52GKW6[B^YYIWO%US>ISD#2D3Z
M]8VMI!$02+Y^IJ)ID3,,#"22,OV_+U?_43H+CZ?J&8]1>;V[2X%N5>5T/@A`
M]6@;$:,K[XGI+-%&_2'+V[A@]S2(R)"'#-R7DAP/3.$+\01$#2!J91TE7I75
MJ10+SZ0:K>4%NZ\I&<94I"$(I14H`]T30#`TT;+_+`\_A2?P^GPLCL5,F&_9
MO&[LPZ5A)B!]$0IN908,`N"P8!!O&YR?F:I^&JDA,J4'8,/I(@W`$2)%$^>_
MO%[0[$M&5WGY;".4+$ODO[<0$"1$</IP-CZ.=5Y0(T)[?PKEA?/\79SQ,@F0
MD4<A>M40Q_^<P3%LNAK_GP$&*<Z5UNL[('06GOBD&<#7]"*-B#]WFFK%1K8L
M:YQ#HK8U4L(;Y\>/*A4:Z!X(_;T4I"A0>D\(5N@!M#\!KD/H.01BH;N3$)W!
M42D@I4HD612*AX??P'.>!A?R]<^WV'9*W<\]P0YQC55MBR$R%GB(6K5J(9DJ
M.G;O0,PT;T2''$^0=MMEM[*-L`LI`"GU[[]R*E661]Y<?<3ZKSW0R=LI*I"B
M+5UDM`*P\0N4,U`$S-"20Q^!QY\V#8Z,I4E3C+9-Z%NW042H4D[Z"T;+-FS"
M7*JEP^C:?,^;+M^;>#E2EPOQP^(W:0/=VF.SN0)ML`H#1#;L>RU3"Z]:+7Y7
M<VZ1(K1FA@%[R#5F)NAKDF:-7GYIENJ`M`!=TYY@5;--BQ-,,-322;+#!N#E
M12MR4>&_1%X1EP6`Y<H0"!=`_(97`.BXG!&!4ZIX#E,("&CQ9(Y8HID11A3T
M!<DDD<>?`ZFDP0`BH1#T<8;-/:5P/@,S!BM=$9):;T'P6/=O22#5C!@_F^3K
MEDHAL+OX\=$+`F47"'W:;BZL7<3F)UCP)U1IQ(UD#[I67$`J5H&26TF2%58"
M%B-&(P@W8U#"[2ERJ[M`);E(P!B1*&DOO8A0U0*6@"^7MU#:I#])>;Q4."</
MO7,(.674"7`209;6E*&%K)`K;+$Z">H@(<@D$5(&#1QCY91PWH>&P-@2U(NX
M")N[G=8*8ER@#W&*;U`'A0W(9;=FOD6L`R=B-/1$S(XW$2BPWH%B`?K39@`M
MH$#``E$3!,AON78:]4HJ='0)EZ,365S_JL^V'I+DZIX#B7T=E`X&=*,\3Y()
MYD#`OO<0(CG/0X!4V.7.!;L=V2<1Z`9R(.:`[`#K;R%!F)J0^_)H2\]1;Y>#
M0!FCO6!S,++]$`ZN-R+[$-.M0D`+BC=O+KIRO:%BMJ`\JS?!\KL3;B%#N"_(
MB6W$"(9)FX]F4+@HN<2<;`&$:@V;"=W]>*NP]>]"WM$Z@MDDR#72??^?X_<%
MNR59$Y[R%@!S1U`-3X"\+Z?OQ5H.D&D@!]>"4G+QH-[YY`;FXCQ"=$VD#Y>T
M%@>_UJR[:+Z<M4H`P^VI\AV[A52)#C7K.;!<$\##>(WW6(AS"^'@(3!U^`7)
MY"/E^3HQSS"`0@"9%761*2*(:R_,`)A$P2&NB#W[5C4L?@&<7=`VC86%&;09
M\\X23-?>7O2>E%"+H`3E?-"@206@U1.UT2UDDV*VBI>AT&9M;D#:=([.HA""
M8!NUR.*'S[5/EB;POJ19`8D(R$40X(U2C!GG&'!);%+)01%(B'20*BD82744
MU/D(!H'J]F1C\8'I6]HXG?)>0`FN)*OY$=,=!S6VBQ121!'IJU!U;9'79TWF
M&L@[54/P8C@OCFB&Q0GFCN4ONU0VMK^Y%*J^8M1)2P-[OS;YE83R<D4T#SFW
M3CCV/-J'B$4H"XT@(#,N:*",&J9`'"YT\<JLD\5'L#D6URK2J];`ST0;$$E1
M$2'-;O+J;ND.#5+J&(Q6<@+\9$*I$TP@DRF`E)HN>-KI5R1PAQ]*%.2`&-:4
M>(="QEA8J7R`8S*89-SE,8E@<:::8Q`HJ!0C:)`G@9C/-YQ;+RQ+J!!;C25`
MP:Y7AMO;A6Q\*:NP*9(8,DYA*,3";+E2D6=&*)@&FDV%,\INPF4;,<!SL,47
M,OKNIR*B2GF7@J$-\X(VBE<R-X,&#4*E)D:O,A59.(Q4&+2*3EH9#,OAKQR;
M>X;[FX*,W'@.9;0?*FQLF9W[7$";./2*[9`#(>9P05EI"K/.R2RV/JA9A>(7
M#H&Y$A:BFN7/)6R(WTM80U$SB,"($`@'&@"CTU90F=U#?<V:F7(*+.U@0W*X
MH;$+ZY7BPOE@4.(%N%Q0*O?H7A(%WD%AA@DIQAG?B*(Z;K5K$,VH$RT<MT%!
MUM&ZK"*"5X.B(Y`!JS@"A$(3.J"LP3Y(1K[ZN0((77*6,6=!QE%P,00+VP\P
MA-!D05'K(<=AVB#6B4+!$FZ-=W3#-%)1!G!R!@511L94FV]5U7+;>E2QR.DP
M+PIOI^:'W!_<'$#NHJL/EHC9CH$`/.Q1%`[BHPDY"DH!Q"[(.:P59,E8C%YW
M'*K$PL67&VSC94=KF,E0QNUK"0XQS5XX%O6R'6@KE`0H&1ZAJ@V^8((#]*2X
M+NI8./@/(#8:*C*[)%S!*KWNA:#ZEFRV+&9EH6T,$<"BP#<&==^@D@O!%V/,
M:)W6-[(`)(V#A'?J$NYP7;%F4+]R:,'`G$MMX<RJ0KPETX?AT`T@,4[^L--%
M?PT5`_R2,%<>QB4Z!@5MH+WE3H5%^HLD77]T#2Z@NJ1YN5T]W0=Z*)(5%2PU
MO>H$%`:[&9"2A!P%3ENZ^QX-7+0E[0K9(%Q)W*TN?^#$#;`$$'+WA#,L3K`-
M"(7F)S,/"(>H"L.)3HDD2GD%"(R4]A8(E$0DB@:0Q*[(1"7%H*XJ2[-AZ.3?
M/IA>@,RI*:+KY#X*@G($>CW5\&!@P=_>Z45>C]Q2R`=#!]#(11'(B";1H@&J
M.IORKY4M8F2<S/#7#B$V@*I`:VHA%Z".J]R,V^E,$7:=)IAUZK!!0C:;D>\3
A,`?2$-Y+TOBD-XA[_8@'?Y?*I^^"__B[DBG"A(:N2>&H
`
end

[-- Attachment #3: Type: text/plain, Size: 15 bytes --]


   Tim Seufert

Re: Platform configuration (was: Re: CONFIG_PPC != Mac)

[Timothy A. Seufert]

At 2:32 AM -0700 9/5/00, Timothy A. Seufert wrote:

>OK, finally got a chance to play with 2.4 again.  Here they are.

Looks like my stupid mailer truncated the filename a bit; it's really
frankenmac-logs.tar.bz2.

   Tim Seufert

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Platform configuration (was: Re: CONFIG_PPC != Mac)

[Tom Rini]

On Fri, Sep 01, 2000 at 01:42:14AM -0700, Timothy A. Seufert wrote:
> At 6:44 PM -0700 8/31/00, Tom Rini wrote:
> >On Thu, Aug 31, 2000 at 06:10:55PM +0200, Gabriel Paubert wrote:
> >>
> >>
> >>  On Thu, 31 Aug 2000, Dan Malek wrote:
> >>
> >>  > I would also like to see us spend a little more time trying to
> >>  > stabilize 2.4 instead of trying to solve elaborate configuration and
> >>  > boot schemes.  That is what 2.5 is for.
> >>
> >>  What are your problems with 2.4 ? I'm at 2.4.0-test7 and I've not had any
> >>  problem so far, although I still need to upgrade my modutils.
> >
> >Here's a few: The PCI resource allocation/conflict stuff has "issues" with
> >some Pmacs (7600, Yikes! G4, I don't know about others).
>
> B&W G3 as well (same thing as the Yikes! G4 really).  I have the
> following problems on one (latest BK 2.4.0-test8 kernel, as of a
> couple minutes ago):
>
> 1. Resource conflicts are reported for the CMD646 IDE controller and
> an Adaptec 2940UW card

There should be more conflicts reported than that.  But not all drivers check
for conflicts yet.

> 2. During the fb probe of the Rage 128 PCI card, a pattern of colored
> characters is written to the screen.  This might be somebody's
> deliberate debug output, as it almost looks too regular to be an
> error.

That does seem odd, I didn't get that one.

> 3. When attempting to do the partition scan, the kernel has massive
> problems with lost IDE interrupts and failed DMA stuff.  Eventually
> it gives up and moves on without successfully scanning my IDE drive.

On the cmd646?  Did/does this happen w/ older kernels as well?  I know
test7/test8-preX are more broken.

> 4. Probably due to the resource conflict problem, the aic7xxx driver
> doesn't recognize the 2940.  This is a showstopper for me because my
> root partition's on a drive connected to the 2940.

This can be kludged around.  search for pci_enable_device (should be 2 lines
something like:
if(pci_enable_device())
	break; or return;
and comment it out.  Then you can see what else is broken.  (I currently have
USB kbd problems as well, w/ the standard apple kbd)

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Platform configuration (was: Re: CONFIG_PPC != Mac)

[Benjamin Herrenschmidt]

>Yeah, well, I am used to continually losing this battle.  Although
>embedded PowerPC is likely to have _lots_ more installations than
>the desktop, we'll just survive on the pieces left behind.  A pretty
>running desktop gets lots of press coverage while code that acutally
>runs the infrastructure of the world is unknown (I guess we are doing
>a great job, then :-).
>
>I am just happy that I can finally build a kernel for the MPC8xx that
>doesn't require I configure an ADB keyboard.  I also like building the
>same sources for all of my Mac workstations and servers as well.

In the current bk, I made sure you can compile without ADB (even for
pmac), without the backlight stuffs, etc...

>I would also like to see us spend a little more time trying to
>stabilize 2.4 instead of trying to solve elaborate configuration and
>boot schemes.  That is what 2.5 is for.

Agreed.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Platform configuration (was: Re: CONFIG_PPC != Mac)

[Gabriel Paubert]

On Thu, 31 Aug 2000, Geert Uytterhoeven wrote:

> > The only reasonable way to do this that I see is to have a self linking
> > kernel, the initial boot code would simply uncompress a partially linked
> > kernel and perform the final link step before passing control to it.
> >
> > Yes this involves putting several versions of processor specific code
> > in the same kernel, but once compressed it's not that big. The _init
> > sections are ok, but adding apus/prep/openfirmware is pushing the method
> > past the breaking point.
>
> Cool!
>
> > Yes, this will make the bot iamge bigger, I just  don't care (embedded
> > systems are different) since it will make the running kernel smaller:
>
> My interest is in smaller kernel images. I don't want to compile every single
> piece of PPC code that's useless for my hardware, I want to compile only what
> I need. I think I'm already wasting too much of my time waiting for kernel
> compiles.

And you `make {x,menu,old,}config' to take longer than `make zimage' ?

First, kernel compile times are only fairly large after a big update, when
I do `make dep clean zImage'. Second, the proportion of time spend in the
specific PPC code (mostly arch/ppc and drivers/macintosh) is rather small.
Third, building a minimal kernel image for each machine would involve a
ton (and that's an undrestatement) of kernel options: CONFIG_INTC_8259,
CONFIG_INTC_POWERMAC, CONFIG_INTC_OPENPIC and others for the interrupt
controllers, half a dozen or so CONFIG_RTC types, same for CONFIG_NVRAM
and a few other things I surely forget. The only reasonable solution is to
aim for the smallest runtime kernel image.

> And since there are people who care about embedded PPC systems, it would be
> great to at least have _the choice_ to compile a small specific kernel or a
> large generic one.

Then build an utility which trims the kernel the same way as the smart
bootloader would do. People with embedded systems know what their target
systems is and could use it, but please don't add another couple of
hundred entries in the basic Linux kernel configuration.

	Regards,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Platform configuration (was: Re: CONFIG_PPC != Mac)

[Benjamin Herrenschmidt]

>First, kernel compile times are only fairly large after a big update, when
>I do `make dep clean zImage'. Second, the proportion of time spend in the
>specific PPC code (mostly arch/ppc and drivers/macintosh) is rather small.
>Third, building a minimal kernel image for each machine would involve a
>ton (and that's an undrestatement) of kernel options: CONFIG_INTC_8259,
>CONFIG_INTC_POWERMAC, CONFIG_INTC_OPENPIC and others for the interrupt
>controllers, half a dozen or so CONFIG_RTC types, same for CONFIG_NVRAM
>and a few other things I surely forget. The only reasonable solution is to
>aim for the smallest runtime kernel image.

Well, an easy first step is to have those per-machine cumulative compile
options so you can choose pmac only, pmac+chrp, etc...

That's only a few more config stuffs (CONFIG_PPC_PMAC, CONFIG_PPC_PREP,
etc...), the core code wouldn't need to change. We can even optimize the
various if (_machine == xxxx) using maros that get resolved to a constant
when only one machine type is compiled in.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Platform configuration (was: Re: CONFIG_PPC != Mac)

[Geert Uytterhoeven]

On Thu, 31 Aug 2000, Benjamin Herrenschmidt wrote:
> >First, kernel compile times are only fairly large after a big update, when
> >I do `make dep clean zImage'. Second, the proportion of time spend in the
> >specific PPC code (mostly arch/ppc and drivers/macintosh) is rather small.
> >Third, building a minimal kernel image for each machine would involve a
> >ton (and that's an undrestatement) of kernel options: CONFIG_INTC_8259,
> >CONFIG_INTC_POWERMAC, CONFIG_INTC_OPENPIC and others for the interrupt
> >controllers, half a dozen or so CONFIG_RTC types, same for CONFIG_NVRAM
> >and a few other things I surely forget. The only reasonable solution is to
> >aim for the smallest runtime kernel image.
>
> Well, an easy first step is to have those per-machine cumulative compile
> options so you can choose pmac only, pmac+chrp, etc...

Right, just like we had 2 years ago.

> That's only a few more config stuffs (CONFIG_PPC_PMAC, CONFIG_PPC_PREP,
> etc...), the core code wouldn't need to change. We can even optimize the
> various if (_machine == xxxx) using maros that get resolved to a constant
> when only one machine type is compiled in.

Yes indeed.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Platform configuration (was: Re: CONFIG_PPC != Mac)

[Geert Uytterhoeven]

On Thu, 31 Aug 2000, Gabriel Paubert wrote:
> On Thu, 31 Aug 2000, Geert Uytterhoeven wrote:
> > My interest is in smaller kernel images. I don't want to compile every single
> > piece of PPC code that's useless for my hardware, I want to compile only what
> > I need. I think I'm already wasting too much of my time waiting for kernel
> > compiles.
>
> And you `make {x,menu,old,}config' to take longer than `make zimage' ?

Real men use `vi .config', delete some lines and type `make oldconfig' :-)

> First, kernel compile times are only fairly large after a big update, when
> I do `make dep clean zImage'. Second, the proportion of time spend in the
> specific PPC code (mostly arch/ppc and drivers/macintosh) is rather small.
> Third, building a minimal kernel image for each machine would involve a
> ton (and that's an undrestatement) of kernel options: CONFIG_INTC_8259,
> CONFIG_INTC_POWERMAC, CONFIG_INTC_OPENPIC and others for the interrupt
> controllers, half a dozen or so CONFIG_RTC types, same for CONFIG_NVRAM
> and a few other things I surely forget. The only reasonable solution is to
> aim for the smallest runtime kernel image.

Hmm... Now you make me think of something :-) What about drivers/intctrl/ to
share all code for interrupt controllers? Almost all archs have their own
i8259 code...

> > And since there are people who care about embedded PPC systems, it would be
> > great to at least have _the choice_ to compile a small specific kernel or a
> > large generic one.
>
> Then build an utility which trims the kernel the same way as the smart
> bootloader would do. People with embedded systems know what their target
> systems is and could use it, but please don't add another couple of
> hundred entries in the basic Linux kernel configuration.
  ^^^^^^^
Please don't exaggerate! I'd be happy with the 4 extra questions for
PReP, CHRP, PowerMac and MTX only (for now).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Platform configuration (was: Re: CONFIG_PPC != Mac)

[Dan Malek]

Geert Uytterhoeven wrote:

> Real men use `vi .config', delete some lines and type `make oldconfig' :-)

No, you actually further edit autoconf.h and just type 'make vmlinux'
(after removing the .o files not properly covered by dependencies :-).



	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Dan Malek]

Geert Uytterhoeven wrote:

> Given the flexibility I was used to on m68k[*], I find this a pity as well...


Well, it looks like I opened up a big can of worms...........

I guess this is something that will get discussed as part of
"restructuring" the PowerPC source tree when we jump into 2.5.xx.
However, I need some kind of a simple solution that will help me with
the embedded processors that will no longer build in the 2.4.xx
kernel.  I know there must be some embedded Linux m68k boards that
have a similar challenge that I may be able to use for insight.

What I would like to do in the short term, is create a CONFIG_PPCMAC
that has the sole purpose of including the drivers/macintosh software,
or perhaps overload the CONFIG_ALL_PPC to do this.  Perhaps I will
look at what CONFIG_PPC really means, and not define this for embedded
boards (although this sounds wrong).

Thanks for the comments.  We'll be back :-).


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Geert Uytterhoeven]

On Mon, 31 Jul 2000, Dan Malek wrote:
> Geert Uytterhoeven wrote:
> > Given the flexibility I was used to on m68k[*], I find this a pity as well...
> Well, it looks like I opened up a big can of worms...........
>
> I guess this is something that will get discussed as part of
> "restructuring" the PowerPC source tree when we jump into 2.5.xx.

Note that there was a time when we did have separate CONFIG_PMAC, CONFIG_PREP
and CONFIG_CHRP switches. I liked it, since it allowed to customize your kernel
more precisely.

> However, I need some kind of a simple solution that will help me with
> the embedded processors that will no longer build in the 2.4.xx
> kernel.  I know there must be some embedded Linux m68k boards that
> have a similar challenge that I may be able to use for insight.

AFAIK there are no embedded m68k boards. There are embedded uClinux boards,
though, but these are still at the 2.0.38 level.

> What I would like to do in the short term, is create a CONFIG_PPCMAC
> that has the sole purpose of including the drivers/macintosh software,

Please call it CONFIG_PMAC, like it used to be.

BTW, ADB code should be in driverd/adb/, cfr. all other bus types. It should be
protected using CONFIG_ADB, which should be configurable depending on either of
CONFIG_MAC, CONFIG_PMAC, CONFIG_CHRP or CONFIG_NEXT in
arch/{m68k,ppc}/config.in. That way you can leave out ADB support if you don't
need it (e.g. for server PowerMac boxes, and for CHRP boxes that use the PS/2
port only).

> or perhaps overload the CONFIG_ALL_PPC to do this.  Perhaps I will
> look at what CONFIG_PPC really means, and not define this for embedded
> boards (although this sounds wrong).

CONFIG_PPC is always set to `y' on the PPC platform. It's a substitute for
checking the arch type. I don't really see why it was invented, since the same
thing can easily be done using `#ifdef __powerpc__' in sources and `ifeq
($(ARCH),PPC)' in makefiles. Besides, CONFIG_PPC has the unwanted side effect
of making more sources depend on config.h.

So far my opinion...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Dan Malek]

Geert Uytterhoeven wrote:

> Please call it CONFIG_PMAC, like it used to be.

BenH beat all of us to this :-).  He made the modifications for
the new "unified" CONFIG_ALL_PPC........


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Ani Joshi]

On Wed, 2 Aug 2000, Geert Uytterhoeven wrote:

> Note that there was a time when we did have separate CONFIG_PMAC, CONFIG_PREP
> and CONFIG_CHRP switches. I liked it, since it allowed to customize your kernel
> more precisely.

Also note that one can use the __pmac __prep attributes which were added
to the kernel a long time ago, and __chrp which I recently added.  Granted
these wont 'weed out' code like cpp does but you can still get rid of
excess kernel data upon boot.


ani


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Benjamin Herrenschmidt]

>BTW, ADB code should be in driverd/adb/, cfr. all other bus types. It
>should be
>protected using CONFIG_ADB, which should be configurable depending on
>either of
>CONFIG_MAC, CONFIG_PMAC, CONFIG_CHRP or CONFIG_NEXT in
>arch/{m68k,ppc}/config.in. That way you can leave out ADB support if you
don't
>need it (e.g. for server PowerMac boxes, and for CHRP boxes that use the PS/2
>port only).

I don't think there's real need anymore for an adb directory. The only
file in it would be adb.c. The mouse and kbd drivers are moving to input,
the controller drivers (Cuda,PMU) do not only ADB but all sort of other
machine admin tasks (like power control, I2C, ...) and so are needed even
whithout ADB support as part of "PowerMac" support. Cuda can be shared
with m68k, maybe PMU too, so drivers/macintosh is not a so bad place for it.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: future of drivers/macintosh (was Re: CONFIG_PPC != Mac)

[Joseph Garcia]

Benjamin Herrenschmidt wrote:
> I don't think there's real need anymore for an adb directory. The only
> file in it would be adb.c. The mouse and kbd drivers are moving to input,
> the controller drivers (Cuda,PMU) do not only ADB but all sort of other
> machine admin tasks (like power control, I2C, ...) and so are needed even
> whithout ADB support as part of "PowerMac" support. Cuda can be shared
> with m68k, maybe PMU too, so drivers/macintosh is not a so bad place for it.

would it be a prudent move to relocate most of drivers/macintosh to
drivers/char, with the exception of mediabay.c to drivers/block/mac-mediabay.c?

Something that fits the current layout scheme in a bi-partisan way.

--
Joseph P. Garcia      jpgarcia@execpc.com      jpgarcia@lidar.ssec.wisc.edu
CS Undergraduate                      Student Employee - Systems Programmer
University of Wisconsin - Madison                            UW Lidar Group

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: future of drivers/macintosh (was Re: CONFIG_PPC != Mac)

[Benjamin Herrenschmidt]

>> I don't think there's real need anymore for an adb directory. The only
>> file in it would be adb.c. The mouse and kbd drivers are moving to input,
>> the controller drivers (Cuda,PMU) do not only ADB but all sort of other
>> machine admin tasks (like power control, I2C, ...) and so are needed even
>> whithout ADB support as part of "PowerMac" support. Cuda can be shared
>> with m68k, maybe PMU too, so drivers/macintosh is not a so bad place
for it.
>
>would it be a prudent move to relocate most of drivers/macintosh to
>drivers/char, with the exception of mediabay.c to drivers/block/mac-
>mediabay.c?
>
>Something that fits the current layout scheme in a bi-partisan way.

Hum... The system controllers are not char drivers (well, PMU can be
occasionally), mediabay is not really a block driver, and I fell those
generic char and block drivers are already quite messy.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Michael Schmitz]

> > Given the flexibility I was used to on m68k[*], I find this a pity as well...
>
> Well, it looks like I opened up a big can of worms...........
>
> I guess this is something that will get discussed as part of
> "restructuring" the PowerPC source tree when we jump into 2.5.xx.

While I also enjoyed the flexibility on m68k, some of it was paid for in
terms of increased complexity in head.S and entry.S (and especially head.S
wasn't a bit pretty). I'm not sure how your trouble with the embedded
systems can be solved, we kept separate head.S versions for Macs and other
machines for a while as well because things just got too confusing. Maybe
we need to keep separate versions for embedded and other systems here?

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Tom Gall]

Michael Schmitz wrote:
>
> > > Given the flexibility I was used to on m68k[*], I find this a pity as well...
> >
> > Well, it looks like I opened up a big can of worms...........
> >
> > I guess this is something that will get discussed as part of
> > "restructuring" the PowerPC source tree when we jump into 2.5.xx.
>
> While I also enjoyed the flexibility on m68k, some of it was paid for in
> terms of increased complexity in head.S and entry.S (and especially head.S
> wasn't a bit pretty). I'm not sure how your trouble with the embedded
> systems can be solved, we kept separate head.S versions for Macs and other
> machines for a while as well because things just got too confusing. Maybe
> we need to keep separate versions for embedded and other systems here?

Hi All,

  I think we don't want to get too carried away with pulling things
apart here. Afterall I think we'd all like to be able to continue to
pick up a distro with a bootable kernel that works over a wide variety
of machines instead of 10 different kernels to choose from depending on
which box you've got.

  Now obvoiusly I'm going a little overboard here but hopefully you
might see what I'm saying. Granted embedded boxes aren't going to care
about booting from the install cd but I think the rest of us sure do!

--
Hakuna Matata,

Tom

-----------------------------------------------------------
Linux Guy          "My heart is human, my blood is boiling,
tgall@uswest.net    my brain IBM" -- Mr Roboto, Styxx

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Michael Schmitz]

> > While I also enjoyed the flexibility on m68k, some of it was paid for in
> > terms of increased complexity in head.S and entry.S (and especially head.S
> > wasn't a bit pretty). I'm not sure how your trouble with the embedded
> > systems can be solved, we kept separate head.S versions for Macs and other
> > machines for a while as well because things just got too confusing. Maybe
> > we need to keep separate versions for embedded and other systems here?
>
> Hi All,
>
>   I think we don't want to get too carried away with pulling things
> apart here. Afterall I think we'd all like to be able to continue to
> pick up a distro with a bootable kernel that works over a wide variety
> of machines instead of 10 different kernels to choose from depending on
> which box you've got.

That's exactly what won't work now. A kernel built for PowerMac won't work
on embedded systems or APUS, and maybe not even on PReP or CHRP.

>   Now obvoiusly I'm going a little overboard here but hopefully you
> might see what I'm saying. Granted embedded boxes aren't going to care
> about booting from the install cd but I think the rest of us sure do!

I don't see where we would conflict, all I said was maybe keep embedded
separate. By all means unify the rest if at all possible.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Geert Uytterhoeven]

On Thu, 3 Aug 2000, Michael Schmitz wrote:
> > > While I also enjoyed the flexibility on m68k, some of it was paid for in
> > > terms of increased complexity in head.S and entry.S (and especially head.S
> > > wasn't a bit pretty). I'm not sure how your trouble with the embedded
> > > systems can be solved, we kept separate head.S versions for Macs and other
> > > machines for a while as well because things just got too confusing. Maybe
> > > we need to keep separate versions for embedded and other systems here?
> >
> >   I think we don't want to get too carried away with pulling things
> > apart here. Afterall I think we'd all like to be able to continue to
> > pick up a distro with a bootable kernel that works over a wide variety
> > of machines instead of 10 different kernels to choose from depending on
> > which box you've got.

Note that I never said the various CONFIG_* options have to be mutual
exclusive. Enable them all for a generic kernel for a distro, enable what you
need only for a machine-specific kernel.

> That's exactly what won't work now. A kernel built for PowerMac won't work
> on embedded systems or APUS, and maybe not even on PReP or CHRP.

PowerMac kernels should work on PReP and CHRP as well.

> >   Now obvoiusly I'm going a little overboard here but hopefully you
> > might see what I'm saying. Granted embedded boxes aren't going to care
> > about booting from the install cd but I think the rest of us sure do!
>
> I don't see where we would conflict, all I said was maybe keep embedded
> separate. By all means unify the rest if at all possible.

The rest is unified. But it's so unified that I can't get rid of e.g. all
PowerMac-only code when I want to compile a kernel for a CHRP box. Much
PowerMac specific stuff is indeed freed up later when the pmac section is
released, but that's all.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Dan Malek]

Tom Rini wrote:

> Well, where are the specific breakages?  (CONFIG_MAC is used for 68k only
> right now, IIRC.)

Sorry, I guess I haven't looked at it in a while.....I just noticed
this with the recent 2.4.0-test5 BitKeeper tree.

All CONFIG_PPC builds include drivers/macintosh, and I guess there are
more changes happening there that require additional configuration
options.  For example, you can't build a PowerPC without Machintosh
and USB (and ADB, and keyboards, and....).  So, when I have a PowerPC
that isn't a Mac, I can't link a kernel unless I have all of these
devices configured.  Then, it likes to probe for this stuff, or look
for OF device trees, or something else I don't have.

However, there is a good side :-).  For the first time I am able to
build a kernel without _any_  Mac drivers, which is really nice.

I modified the Makefiles to remove the line:
	DRIVERS-$(CONFIG_PPC) += drivers/macintosh/macintosh.o

and other places where CONFIG_PPC included the macintosh subdir.


This at least works for my embedded systems.  The interesting part
is that in all of these cases, there is an identical Makefile line
or logic for CONFIG_MAC, so I kind of assumed that if you really want
Mac drivers, you could just configure this.....

I am now about to experiment with building for my iMacs and G4s.
I would like to know what people think CONFIG_MAC or CONFIG_PPC or
some of these others are supposed to mean, or assumptions they make.

Thanks.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Iain Sandoe]

On  Sat, Jul 29, 2000,  Geert Uytterhoeven wrote:

[...]
>
> The Master PPC Penguin decided to no longer allow to build machine specific
> kernels, but treat PowerMac/PReP/MTX/CHRP as one big machine type
> (`CONFIG_ALL_PPC').

Ah! so that's why it changed... it's not very helpful for the dmasound stuff
(as I'm sure you already know :-)

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Iain Sandoe]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="", Size: 899 bytes --]


On  Sun, Jul 30, 2000,  Geert Uytterhoeven wrote:
> On Sun, 30 Jul 2000, Michel [iso-8859-1] Dänzer wrote:
>> Geert Uytterhoeven wrote:
>> > The Master PPC Penguin decided to no longer allow to build machine specific
>> > kernels, but treat PowerMac/PReP/MTX/CHRP as one big machine type
>> > (`CONFIG_ALL_PPC').
[snip]
> Personally I'd more like a configuration where you can select whatever you
> want of
>
>   - PowerMac (CONFIG_PMAC)
>   - PReP (CONFIG_PREP)
>   - MTX (CONFIG_MTX)
>   - CHRP (CONFIG_CHRP)
>   - Gemini (CONFIG_GEMINI)
>   - EST8260 (CONFIG_EST8260)
>   - APUS (CONFIG_APUS)
>
> with of course some extra logic to prevent illegal combinations.

This would definitely get my vote too.  There are too many cases where you
can enable conflicting build options at present - it causes much
frustration.

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Johnnie Peters]

Iain Sandoe wrote:

> On  Sun, Jul 30, 2000,  Geert Uytterhoeven wrote:
> > On Sun, 30 Jul 2000, Michel [iso-8859-1] Dänzer wrote:
> >> Geert Uytterhoeven wrote:
> >> > The Master PPC Penguin decided to no longer allow to build machine specific
> >> > kernels, but treat PowerMac/PReP/MTX/CHRP as one big machine type
> >> > (`CONFIG_ALL_PPC').
> [snip]
> > Personally I'd more like a configuration where you can select whatever you
> > want of
> >
> >   - PowerMac (CONFIG_PMAC)
> >   - PReP (CONFIG_PREP)
> >   - MTX (CONFIG_MTX)
> >   - CHRP (CONFIG_CHRP)
> >   - Gemini (CONFIG_GEMINI)
> >   - EST8260 (CONFIG_EST8260)
> >   - APUS (CONFIG_APUS)
> >
> > with of course some extra logic to prevent illegal combinations.
>
> This would definitely get my vote too.  There are too many cases where you
> can enable conflicting build options at present - it causes much
> frustration.
>
> Iain.
>

There are also other considerations.  While there is almost always enough memory to

carry the extra functionality it is not always the case.  Some boards are being
booted
out of rom and may still only have a limited amount of space to hold the kernel.
In any
case do we really want to wast the space.

As Dan stated it also causes a lot of extra work on ports to new boards that
probably
do not need all the configuration parameters for the pmacs.

Johnnie

MontaVista Software, Inc.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Michael Schmitz]

> At 18:40 31.07.00, Michael Schmitz wrote:
> > > I am fighting with the "new input layer" right now, although I don't
> > > quite understand why this thing is being inflicted upon innocent ADB
> > > users.
> >
> >My question exactly.
>
> But we are talking about developer trees (2.4 and benh) right now, or? I
> have no problem breaking things here for some time, as long as a working
> version ends up in the stable trees.

I have no problem with you breaking things in the developer trees either,
but I was talking about 2.2.17 which also appears to have the new input
stuff, and that's what bothers me. I already know I have to make a number
of changes to my system with 2.4 (devfs will probably be the first
stumbling block) but didn't expect major breakage with 2.2 kernels.

> >ADB keyboard and mouse work (and button emulation works as well) with
> >CONFIG_NEW_INPUT_LAYER not set. What doesn't work for me anymore is the
> >USB mouse. The 2.2.17 kernel (rsynced last Thursday) only compiled after I
> >added a #ifdef CONFIG_MOUSEDEV somewhere in mac_keyb.c as a consequence of
> >not having CONFIG_NEW_INPUT_LAYER defined. I'd look it up on the Lombard
> >but the box just crashed on me the second time in a row today. 2.2.17 sure
> >is exciting.
>
> I'll try myself without CONFIG_NEW_INPUT_LAYER set later. But I wonder why
> your USB mouse would no longer work. It certainly works for me in console
> and XF4. X or console? Xpmac (which rev?) or XFree? Did you link
> /dev/usbmouse to /dev/input/mice?

Neither gpm nor XFree (never used Xpmac) have the USB mouse working. I've
used /dev/input/mice, /dev/hidbp-mse-0, and the miscdev USB mouse device,
with various combinations of config options in the USB sections, to no
avail.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Michael Schmitz]

> >ADB keyboard and mouse work (and button emulation works as well) with
> >CONFIG_NEW_INPUT_LAYER not set. What doesn't work for me anymore is the
> >USB mouse. The 2.2.17 kernel (rsynced last Thursday) only compiled after I
> >added a #ifdef CONFIG_MOUSEDEV somewhere in mac_keyb.c as a consequence of
> >not having CONFIG_NEW_INPUT_LAYER defined. I'd look it up on the Lombard
> >but the box just crashed on me the second time in a row today. 2.2.17 sure
> >is exciting.
>
> I'll try myself without CONFIG_NEW_INPUT_LAYER set later. But I wonder why
> your USB mouse would no longer work. It certainly works for me in console
> and XF4. X or console? Xpmac (which rev?) or XFree? Did you link
> /dev/usbmouse to /dev/input/mice?

OK, I've tried with CONFIG_NEW_INPUT_LAYER set in the meantime, here's
what I got (on 2.2.17pre13-ben2, to be precise):

- USB mouse works as before both in X and for gpm when I link
/dev/usbmouse to /dev/input/mouse2. OK so far.

- gpm takes input from trackpad, USB mouse and emulation buttons without a
hitch if I use /dev/input/mice as the device. I can most definitely live
with that. No serious, this is a major improvement over the previous
scheme (including Paul's idea to copy all USB mouse packets to the
adbmouse channel, too). I think can see where the new input layer is
heading, and think it was about time for a major rewrite of the keyboard
driver mess, plus it obsoletes the ADB device hack I sent to Paul so that
saves me patching it up for 2.4. I'm mostly for it, but:

- the showstopper: In order to keep my X config backwards compatible with
older kernels, I need /dev/adbmouse as busmouse protocol device. It's dead
now ... but can reactivated if you remove the #ifndef CONFIG_INPUT_MOUSEDEV
conditionals. Even the old way of mouse button emulation via /dev/adbmouse
still works, so why the #ifndef CONFIG_INPUT_MOUSEDEV to remove a fully
functional feature that doesn't even interfere with the new input layer
for all I can see?

Side note: if you use /dev/input/mouse1 to get the trackpad data you will
miss the mouse emulation packets that are on /dev/input/mouse0. That may
be why emulation appeared broken to some.

	Michael

P.S.: the list seems broken right now, any idea who should be notified?


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Michael Schmitz]

> > - USB mouse works as before both in X and for gpm when I link
> > /dev/usbmouse to /dev/input/mouse2. OK so far.
>
> Why not link it to /dev/input/mice? That's what's intended. Actually link
> /dev/mouse to /dev/input/mice and use /dev/mouse everywhere.

Because that breaks the X config for 2.2.15? (2.2.17 has a few other
shortcomings so I don't plan to use it permanently right now.) I'll sure
try using only /dev/input/mice later, just to see if the buttons 4 and 5
for the mouse wheel still work that way.

> > conditionals. Even the old way of mouse button emulation via /dev/adbmouse
> > still works, so why the #ifndef CONFIG_INPUT_MOUSEDEV to remove a fully
> > functional feature that doesn't even interfere with the new input layer
> > for all I can see?
>
> Well, that wasn't the goal here, I wanted a single gpm and X config for all
> mice, and I wanted as much old cruft removed as possible for the
> CONFIG_NEW_INPUT_LAYER case, it has been there for far too long. And who,
> except developers, want's to use old 2.2 kernels if the new kernel works?

Who wants to use new 2.2 kernels if they do things like freeze for no
apparent reason, or wake up from sleep with the display remaining off? I
can't remember a crash with 2.2.15, while 2.2.17 doesn't seem as stable.
At least while I work on fixing 2.2.17 related problems I'd like to fall
back on 2.2.15 for real work.

Removing old cruft is all fine and dandy - for 2.4, IMHO. Please note that
I've not said the new input layer shouldn't be introduced in 2.2, just
that things working before shouldn't break (like adbmouse with the input
layer, or USB without). But perhaps I've just been lucky with previous
2.2.x experimental versions that didn't break.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_PPC != Mac

[Iain Sandoe]

>> The main problem so far is that I cannot get mouse button emulation to
>> work. Has anyone tested this on an ADB keyboard/mouse? Or does it only
>> work if one goes over completely to the "linux" keycodes? I don't want
>> to do this yet, because it will make my system unusable with any other
>> kernel (or maybe unusable at all). Last time I tried, it took me several
>> hours to get a usable system back.
>
> ADB keyboard and mouse work (and button emulation works as well) with
> CONFIG_NEW_INPUT_LAYER not set. What doesn't work for me anymore is the
> USB mouse. The 2.2.17 kernel (rsynced last Thursday) only compiled after I
> added a #ifdef CONFIG_MOUSEDEV somewhere in mac_keyb.c as a consequence of
> not having CONFIG_NEW_INPUT_LAYER defined. I'd look it up on the Lombard
> but the box just crashed on me the second time in a row today. 2.2.17 sure
> is exciting.

2.2.17pre13ben2

Actually, (in contrast to my debacle with the Xserver) this has all gone
very smoothly for me - I'm using the new input layer and USB & ADB work
together beautifully on both B3 beige (with a cheepo USB card) and Lombard
(with a logitech wheel mouse).

It also works fine on my 9600 - which hasn't got the faintest clue of the
existence of USB :-)

The only gottcha I found was (as Ben suggested) that you *do* need to delete
the adbmouse entry in /dev rather than just rename it (OK, so I'm paranoid
sometimes).

I had a nasty crash with 2.2.17pre13ben2 on the Lombard (posted) but this
was IDE disk-related (and prob. something to do with sleep).

I suppose that I'm using Xpmac (still :-) rev.10 which might be why it's all
gone easily.

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/