Re: Going from 2.2.12 to 2.2.17pre10

On Sun, Jul 09, 2000 at 08:12:26AM +0200, Michael Lundkvist wrote:

Matt Porter [off-list ref] writes:

quoted

quoted

Nope. I think I'll go for Bugboot. Ramix also talked about the
possibility of modifying PPCBug to add support for the Ramix 233.

I really have to recommend against that.  Once Ramix sees the icky PPCBUG
code they will hate as much as I do.  I gave well documented changes to
the PPCBUG guys so that BUGBOOT wasn't needed to boot a kernel from
FLASH on a PowerPlus board but they haven't incorporated those changes
after a full year now. :)

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.

How board specific is the residual data that Bugboot needs?

For the single processor boards, the only thing used for the prep port
is the memory sizing information.  You can always hack that or fix
the kernel to get memory size from the board registers or VPD (in the
case of the MVME2400 and later boards).

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.

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

On Sun, 9 Jul 2000, Matt Porter wrote:

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

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.

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

	Regards,
	Gabriel.


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