Re: Going from 2.2.12 to 2.2.17pre10

On Mon, Jul 10, 2000 at 02:25:19PM +0200, Gabriel Paubert wrote:

On Sun, 9 Jul 2000, Matt Porter wrote:

quoted

quoted

Getting those changes into PPCBUG would be great.

All you need is a big customer of MCG's to push them to do it.  Money
is a powerful motivator.

Hopeless for me...

Yeah, it's a tough spot since their aren't really any serious competitors
for the PPC VMEbus business.  CPCI is another story though.

quoted

quoted

Would it be possible to make one image for 2300 cards and one for 2400
cards or does memory size affect the residual data?

See above, you could make a lowest common denominator version of the
data and lose some memory.  Honestly, I'd just hack the kernel...PPCBUG
and residual data are a horrible burden.  Look through prep_* and
mm/init.c for every place residual data is used and hardcode for your
MCG boards.  In init.c, prep_find_end_of_memory() can detect a Raven
bridge then use the documented board registers to identify memory size
(see online user manual).  A 2400 puts memory size across the I2C bus
in a EEPROM containing all sorts of useful information.  Bug MCG to get
specs on the layout of these VPD records.

I disagree, the residual data of the device/property tree of OF are great
things. I want to boot _exactly_ the same kernel on machines with
different amounts of memory... A lot of the initizalization should be
moved to early boot or to a first stage bootloader (before uncompressing
the kernel) and then the kernel should receive important information in a
predigested form.

That would be fine in a perfect world, but the reality is that MCG
continually puts out buggy firmware with holes in the residual data.
Since residual data is a dead standard, they are patching in new packet
types as new board features are added to make so Frankensteinian
PReP residual data standard.  Again, the only useful thing being
garnered from residual data for the PReP port is memory size.  This
is almost as easily gathered from the board registers on boards
< MVME2400 and from the VPD on those boards >= MVME2400.

Back to original point, I'm not against using a residual data or
device tree if it doesn't have to have dozens of fixups applied.
I just don't see that coming out of the proprietary hardware/software
houses to use their broken data...

For the VPD records, the information in the MVME2400 programmer's guide
(mvme2400apg.pdf) looks sufficient (page 1-27 and appendix B).

The PrPMC750 and latter boards have define VPD packets a bit different
IIRC.  2400 was the first board to define VPD and it _almost_ was
standardized but not quite. :)

--
Matt Porter
mmporter@home.com
This is Linux Country. On a quiet night, you can hear Windows reboot.

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

Matt Porter wrote:

Back to original point, I'm not against using a residual data or
device tree if it doesn't have to have dozens of fixups applied.
I just don't see that coming out of the proprietary hardware/software
houses to use their broken data...

Residual data is useful for things like finding the memory size, and for
chips designed inside Apple. For almost everything else Linux already
contains a device tree, built by PCI probing when the kernel boots^*. I
don't see much need for a parallel, architecture specific, device tree.

- Adrian Cox, AG Electronics
*) Apologies to MCA and Nubus users.

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

Residual data is useful for things like finding the memory size, and for
chips designed inside Apple. For almost everything else Linux already
contains a device tree, built by PCI probing when the kernel boots^*. I
don't see much need for a parallel, architecture specific, device tree.

In the case of Apple HW, the OF device tree is the only way to know about:

 - Interrupt routing & sense type (level/edge)
 - Machine model (for the machine device-specific stuffs we have)
 - Bits inside Apple ASICs (we could hard code everything, but that doesn't
   sound like a good idea, and the device tree also provide things like the
   MAC address of the eth chip)
 - Firmware boot path (to setup the OF boot and configure the bootloader)
 - PCI hierarchy with the Uni-N chip
 - Memory size (of course)
 - What else did I forget ?


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

Benjamin Herrenschmidt wrote:

In the case of Apple HW, the OF device tree is the only way to know about:
[big list of things Apple OF tells you]

Actually, I'm whining about nothing. I just did a search of the drivers
tree, and the only generic PCI device that uses the OF tree is
chipsfb.c. Of course, that's the one I've been porting to a more generic
PCI device driver aimed at the later C&T devices.

As Geert has declared intent to move the FB drivers to PCI probing, this
is a non-issue.

- Adrian

btw: Off topic: which Powerbook uses chipsfb? If they're cheap
secondhand I'll consider becoming my own guinea-pig for the merged
driver.

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

On Tue, 11 Jul 2000, Adrian Cox wrote:

Benjamin Herrenschmidt wrote:

quoted

In the case of Apple HW, the OF device tree is the only way to know about:
[big list of things Apple OF tells you]

Actually, I'm whining about nothing. I just did a search of the drivers
tree, and the only generic PCI device that uses the OF tree is
chipsfb.c. Of course, that's the one I've been porting to a more generic
PCI device driver aimed at the later C&T devices.

As Geert has declared intent to move the FB drivers to PCI probing, this
is a non-issue.

Well, some (control/platinum/valkyrie) will keep on using OF probing since
they're used on PowerMac only. But their initialization routine will no longer
be called by offb.

Prepare to see an (untested, as usual :-) patch for this RSN...

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/

At 1:57 PM +0100 7/11/00, Adrian Cox wrote:

btw: Off topic: which Powerbook uses chipsfb? If they're cheap
secondhand I'll consider becoming my own guinea-pig for the merged
driver.

The 2400, 3400, and original G3 (the one that looks just like a
3400).  The 2400 and 3400 have a 65550 with 1MB VRAM, the G3 has a
65554 with 2MB VRAM.

The cheapest of these would be the 3400, but it won't come that
cheap.  The 2400 is the coolest one IMO because it was the last
subnotebook Apple made, and can be upgraded to G3 (if you can still
locate an upgrade card for a reasonable price that is).  However the
2400 is more expensive than it should be precisely because it was the
last subnotebook Apple made.

  Tim Seufert

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

Well, some (control/platinum/valkyrie) will keep on using OF probing since
they're used on PowerMac only. But their initialization routine will no

longer

be called by offb.

Prepare to see an (untested, as usual :-) patch for this RSN...

BTW. I didn't look in details yet what's wrong, but I noticed that with
the current bk 2.4test3:

 - video=ofonly doesn't work. We need to find some kludge to get this one
back, as it's useful on some setup with broken video (and can be the only
way to get the machine up)

 - aty128fb doesn't intialize console_fb_info (the Xpmac compat stuff).
This is easily fixed by copy&pasting code from another driver, I'll have
a fix for this in bk tonight

 - More annoying: I couldn't get XF4 to work on the Pismo with this
kernel. I tried with or without aty128fb in the kernel, I tried XF4 with
the plain fbdevhw driver, with the r128 driver without fbdev, and with
the r128 driver on top of fbdev, and all I could get is a hung XFree on a
black screen (I found no way to get the screen back with a console, but
the machine still answer to telnet).
The exact same XF4 binary works nicely on 2.2

Ben.


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

On Wed, 12 Jul 2000, Benjamin Herrenschmidt wrote:

quoted

Well, some (control/platinum/valkyrie) will keep on using OF probing since
they're used on PowerMac only. But their initialization routine will no

longer

quoted

be called by offb.

Prepare to see an (untested, as usual :-) patch for this RSN...

BTW. I didn't look in details yet what's wrong, but I noticed that with
the current bk 2.4test3:

 - video=ofonly doesn't work. We need to find some kludge to get this one
back, as it's useful on some setup with broken video (and can be the only
way to get the machine up)

I don't have the bk tree here at hand. Where is the check for `video=ofonly'?
In Linus' tree it's in offb. So the kernel argument should be
`video=offb:ofonly'.

It also depends on the frame buffer device you are using. Atyfb, aty128fb and
matroxfb are initialized before offb (controlfb etc. will be soon), so ofonly
can't work for these. There's one exception: if you have any `video=offb[:*]'
before any other video options, offb will be initialized first (through
pref_init_funcs[] in fbmem.c). Thanks to the resource management system, all
cards used by offb will be marked busy and e.g. atyfb will no longer try to use
the card.

Now my question: exactly what does BootX pass to the kernel if you specify `no
video driver', and where (before or after the other kernel arguments)?

If it passes `video=offb:ofonly' (or plain `video=offb') before any other
options, it should still work fine.
If it passes `video=ofonly', you need to add a test to video_setup() in
fbmem.c to move the initfunc for offb to the top of pref_init_funcs[] if that
option is specified.

Gr{oetje,eeting}s,

						Geert

P.S. Sorry, my patch is delayed until this evening.

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