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?
From: Tony Mantler <hidden> Date: 2000-07-29 17:26:32
At 11:38 AM -0500 7/29/2000, Tom Rini wrote:
On Fri, Jul 28, 2000 at 07:57:11PM -0400, Dan Malek wrote:
quoted
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/
From: Dan Malek <hidden> Date: 2000-07-29 17:36:33
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/
From: Dan Malek <hidden> Date: 2000-07-29 17:40:19
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/
From: Tony Mantler <hidden> Date: 2000-07-29 17:56:40
At 12:40 PM -0500 7/29/2000, Dan Malek wrote:
Tony Mantler wrote:
quoted
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/
On Fri, Jul 28, 2000 at 07:57:11PM -0400, Dan Malek wrote:
quoted
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/
From: Martin Costabel <hidden> Date: 2000-07-30 02:24:58
Tony Mantler wrote:
At 12:40 PM -0500 7/29/2000, Dan Malek wrote:
quoted
Tony Mantler wrote:
quoted
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/
From: Tony Mantler <hidden> Date: 2000-07-30 02:40:27
At 9:24 PM -0500 7/29/2000, Martin Costabel wrote:
Tony Mantler wrote:
quoted
At 12:40 PM -0500 7/29/2000, Dan Malek wrote:
quoted
Tony Mantler wrote:
quoted
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/
From: Michel D�nzer <hidden> Date: 2000-07-30 13:03:19
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/
On Sun, 30 Jul 2000, Michel [iso-8859-1] Dänzer wrote:
Geert Uytterhoeven wrote:
quoted
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/
From: Franz Sirl <hidden> Date: 2000-07-31 12:12:54
At 04:24 30.07.00, Martin Costabel wrote:
Tony Mantler wrote:
quoted
At 12:40 PM -0500 7/29/2000, Dan Malek wrote:
quoted
Tony Mantler wrote:
quoted
Add a CONFIG_PMAC maybe? I don't really object to sharing CONFIG_MAC
with
quoted
quoted
quoted
PPC, except that it would be easy to assume that CONFIG_MAC ==
CONFIG_MAC
quoted
quoted
quoted
&& __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/
From: Martin Costabel <hidden> Date: 2000-07-31 13:11:04
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/
From: Franz Sirl <hidden> Date: 2000-07-31 13:37:18
At 15:11 31.07.00, Martin Costabel wrote:
Franz Sirl wrote:
[]
quoted
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/
From: Andreas Tobler <hidden> Date: 2000-07-31 14:17:57
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/
From: Martin Costabel <hidden> Date: 2000-07-31 15:23:52
Franz,
Franz Sirl wrote:
At 15:11 31.07.00, Martin Costabel wrote:
[]
quoted
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.
quoted
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/
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/
From: Michael Schmitz <hidden> Date: 2000-07-31 16:40:24
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/
From: Dan Malek <hidden> Date: 2000-07-31 23:22:56
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/
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/
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/
From: Dan Malek <hidden> Date: 2000-08-02 15:17:47
Geert Uytterhoeven wrote:
On Mon, 31 Jul 2000, Franz Sirl wrote:
quoted
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/
From: Dan Malek <hidden> Date: 2000-08-02 19:56:53
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/
From: Ani Joshi <hidden> Date: 2000-08-02 20:04:18
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/
From: Benjamin Herrenschmidt <hidden> Date: 2000-08-02 21:15:35
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/
From: Joseph Garcia <hidden> Date: 2000-08-02 21:42:04
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/
From: Michael Schmitz <hidden> Date: 2000-08-02 22:02:27
quoted
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/
From: Benjamin Herrenschmidt <hidden> Date: 2000-08-02 22:02:45
quoted
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/
From: Michael Schmitz <hidden> Date: 2000-08-02 22:16:54
quoted
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/
From: Martin Costabel <hidden> Date: 2000-08-02 22:35:46
Michael Schmitz wrote:
quoted
quoted
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 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/
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/
From: Michael Schmitz <hidden> Date: 2000-08-03 09:33:51
quoted
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/
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.
quoted
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/
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/
On Sun, 30 Jul 2000, Michel [iso-8859-1] Dänzer wrote:
quoted
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/
From: Gabriel Paubert <hidden> Date: 2000-08-31 10:54:33
On Wed, 30 Aug 2000, Geert Uytterhoeven wrote:
quoted hunk
On Sun, 30 Jul 2000, Geert Uytterhoeven wrote:
quoted
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/
From: Benjamin Herrenschmidt <hidden> Date: 2000-08-31 11:39:09
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/
From: Gabriel Paubert <hidden> Date: 2000-08-31 11:53:27
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/
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/
From: Dan Malek <hidden> Date: 2000-08-31 15:58:53
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/
From: Gabriel Paubert <hidden> Date: 2000-08-31 16:04:16
On Thu, 31 Aug 2000, Geert Uytterhoeven wrote:
quoted
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!
quoted
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/
From: Gabriel Paubert <hidden> Date: 2000-08-31 16:10:55
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/
From: Benjamin Herrenschmidt <hidden> Date: 2000-08-31 16:19:17
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.
From: Michel D�nzer <hidden> Date: 2000-08-31 16:20:13
Gabriel Paubert wrote:
On Thu, 31 Aug 2000, Dan Malek wrote:
quoted
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/
From: Benjamin Herrenschmidt <hidden> Date: 2000-08-31 16:22:09
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/
From: Joseph Garcia <hidden> Date: 2000-08-31 19:03:52
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/
From: Michel D�nzer <hidden> Date: 2000-08-31 19:18:23
Joseph Garcia wrote:
quoted
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/
From: Martin Costabel <hidden> Date: 2000-08-31 20:36:23
Dan Malek wrote:
Michel Dänzer wrote:
quoted
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/
From: Michel Lanners <hidden> Date: 2000-08-31 21:30:46
On 31 Aug, this message from Dan Malek echoed through cyberspace:
Michel Dänzer wrote:
quoted
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/
From: Benjamin Herrenschmidt <hidden> Date: 2000-08-31 21:47:24
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/
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/
From: Matt Brubeck <hidden> Date: 2000-08-31 22:35:24
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/
From: Martin Costabel <hidden> Date: 2000-09-01 01:12:46
Benjamin Herrenschmidt wrote:
quoted
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/
From: Benjamin Herrenschmidt <hidden> Date: 2000-09-01 10:57:38
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/
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...
quoted
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/
On Thu, 31 Aug 2000, Benjamin Herrenschmidt wrote:
quoted
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/
From: Dan Malek <hidden> Date: 2000-09-01 16:31:36
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/
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/
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/
From: Michel Lanners <hidden> Date: 2000-09-11 20:00:43
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/
From: Benjamin Herrenschmidt <hidden> Date: 2000-09-12 09:01:20
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/