Today I tried a stage1 installation for the second time and found out what went wrong the first: it was a matter of CFLAGS containing -mcpu=74xx (don't remember, but I think it was not 7447) instead of -mtune=G4, which worked.
Apart from that, I discovered that pegasos-dev-sources does not exist any more and that a newkernel version appeared as "pegasos-sources". Wow!
Unfortunately I had some problems with it...
First of all, emufx.c, of the emu10k1 driver, was bugged, with two cases in a switch that didn't appear to be integer (couldn't find out why... My C is fading... ). I commented them out (surely rendering bugged the whole driver) and went on.
It ends up with a warning about a module, but it didn't seem of any importance.
The big problem is: at boot, the kerenel image does not inflate (when it says gunzipping, the second line of output after the boot command in OpenFirmware), and the error message has no other explanation. Only an error code -5.
What could that be??

http://svn.debian.org/wsvn/kernel/trunk ... rev=0&sc=0

This is the official fix.
This is discussed along with a few other Gentoo installation bugs, at Stuart Herbert's diary;

http://stu.gnqs.org/diary/archives/2004/12/15/77/

What happens is the OpenFirmware boots the small Linux CHRP boot loader, which decompresses a kernel image into a small area of memory. By default this is located at the 4MB boundary - OF variable "load-base" contains the absolute address. The kernel ends up decompressing over it's own code and the zipped image because of the way the firmware memory map.

What you can do is set your "load-base" variable such that it is set to the 32MB boundary (setenv load-base 0x2000000) so that it is mapped BEYOND the firmware memory area, and has plenty of space to decompress into (up to the limit of available memory).

The load-base is set so low in order to allow systems to boot with less than 32MB of memory. Unless you have a decompressed kernel more than 4MB in size you should never run into it.

Again the fix is to "setenv load-base 0x2000000" at the OF prompt.

--
Matt Sealey <matt@genesi.co.uk>
Manager, Genesi, Developer Relations

Couldn't solve the boot problem! Are you sure the boot file is zImage.chrp as stated on the Gentoo Handbook? I also saw that in the linked site the suggested OF command is different (a value like 020000000):?:

Any Idea? Could there be one or two options that raise the weight too much and are not necessary?

I've solved the problem with pegasos-sources2.6.10r2... Good work Gentoo guys!
Unfortuantely, I had another unbelievable error emerging Xorg...
Here are some details:

----------------------------------------
bitscale.c: in function 'BitmapOpenScalable'

insn does not satisfy its constraints

bitscale.c:1897: internal compiler error: in reload_cse_simplify_operands, at postreload.c:391
----------------------------------------
Ofcourse, the error was classified as a non-reproduceable OS error...


I think another time the same error appeared within "image.c".
It's the font engine, isn't it? I tried USEing "bitmap-fonts" as suggested before Xorg compilation, but nothing changed.

Regarding the internal compiler error, did you enable preemption in the kernel? Preemption does not work well on desktop PowerPC systems. Internal compiler errors are very common if you have enabled it.

I solved the problem! I don't really understood if that was thanks to 2.6.10r2 or to a little change in my USE flags (it seems a package was searching for SSE...)
Now my Gentooed-Pegasos really rocks!
Only one thing: I'm going on with the bugged ALSA driver in wich I brutally commented out the guilty piece of code... That was because I didn't know how to use the .dpatch file! How to use it?

cd into your kernel source and run "patch -p1 < /path/to/patch".