CONFIG_PPC != Mac

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/

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/

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 [email protected]
Winnipeg, Manitoba, Canada http://nicoya.feline.pp.se/

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

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/

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 [email protected]
Winnipeg, Manitoba, Canada http://nicoya.feline.pp.se/

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

??? 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/

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 [email protected]
Winnipeg, Manitoba, Canada http://nicoya.feline.pp.se/

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

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.

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

	-- Dan

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

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/

Franz Sirl wrote:
[]

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/

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 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.

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

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/

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/

Franz,

[]

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.

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/

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 -- [email protected]

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/

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/

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

--
Martin
 

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

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 :-)

I know, cfr. amikeyb.c :-)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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/

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/

My question exactly.

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/

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 -- [email protected]

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/

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/

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

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 -- [email protected]

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/

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/

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 -- [email protected]

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/

So what about this?

@@ -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 -- [email protected]

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/

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/

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).

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.

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/

Ok, I see that we agree...

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.

Ok...

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/

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

Cool!

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 -- [email protected]

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/

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/

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/

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/

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 [email protected] [email protected]
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/

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.

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/

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

	-- Dan

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

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/

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/

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/

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/

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.

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/

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/

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/

On 10 Sep, this message from Takashi Oe echoed through cyberspace:

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   [email protected]            |
http://www.cpu.lu/~mlan        |                     Learn Always. "

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

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/

On 31 Aug, this message from Dan Malek echoed through cyberspace:

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   [email protected]            |
http://www.cpu.lu/~mlan        |                     Learn Always. "

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

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/

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/

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/

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/

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

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...

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

I'll see what I can do.

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

[snip]

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/

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/

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

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.

Tim Seufert

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/

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

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

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

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/

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

Agreed.

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

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.

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/

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/

Right, just like we had 2 years ago.

Yes indeed.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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/

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

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...

^^^^^^^
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 -- [email protected]

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/

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/

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/

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.

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

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).

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 -- [email protected]

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/

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/

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/

don't

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/

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 [email protected] [email protected]
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/

for it.

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/

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/

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,
[email protected] my brain IBM" -- Mr Roboto, Styxx

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

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.

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/

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.

PowerMac kernels should work on PReP and CHRP as well.

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 -- [email protected]

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/

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/