Re: boot methods

In message [off-list ref] you wrote:

I would like to make a complete list of the methods people use to boot
the PPC/Linux kernel on different platforms.  As a start, here is what
I can think of off the top of my head:

...

Can others contribute entries to this list please?

The following systems are supported by PPCBoot:

## MPC8xx Systems
#########################################################################

	ADS860		AMX860		CCM		cogent_mpc8xx
	ESTEEM192E	ETX094		FADS823		FADS850SAR
	FADS860T	FLAGADM		FPS850L		GENIETV
	GTH		hermes		ICU862		IP860
	IVML24		IVMS8		LANTEC		lwmon
	MBX		MBX860T		NX823		pcu_e
	RPXlite		SM850		SPD823TS	SXNI855T
	TQM823L		TQM850L		TQM855L		TQM860L

## PPC4xx Systems
#########################################################################

	ADCIOP		AR405		CANBT		CPCI405
	CPCIISER4	CRAYL1		DASA_SIM	ERIC
	OCRTC		PIP405		WALNUT405

## MPC8240 Systems
#########################################################################

	CU824		MOUSSE		Sandpoint8240

## MPC8260 Systems
#########################################################################

	cogent_mpc8260	hymod		MPC8260ADS	PM826
	RPXsuper	rsdproto	sbc8260		TQM8260

## MPC74xx Systems
#########################################################################

	EVB64260

I am particularly interested in the cases where the kernel vmlinux
binary is loaded directly from some external software, because those

That's what PPCBoot does.

are the cases that constrain our freedom to choose how information
gets passed in to the kernel.  From a long-term maintainability
viewpoint, it would be better if we could say that we always have a
zImage-style wrapper, because then we could change the interface
between the wrapper and the kernel at will without breaking anything.

But that would just shift  the  problem  from  the  kernel  into  the
wrapper:  you'd still need a standard way to pass information between
the firmware and  the  wrapper.  I  don't  see  where  there  is  any
improvement, then.

Along those lines, I have been thinking that it would be good if the
wrapper built a data structure describing the hardware in the system,
particularly things like:

- the amount of RAM and any holes
- type and register addresses for PCI host bus adaptors
- ditto for interrupt controllers
- interrupt mapping

The bi_record discussion comes to mind. Is this what you are thinking
of? As soon as such an interface is well defined we  will  make  sure
that it is directly supported by PPCBoot, too.

Thoughts?

There have already been several rounds of  similar  discussions,  but
AFAIK  they  all  ended  with  just  a  declaration  of  intend to do
"something,  sometime".  Is  your  proposal  a  follow-up  to   these
discussions, or a new approach?

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"I've finally learned what `upward compatible' means. It means we get
to keep all our old mistakes." - Dennie van Tassel

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

Wolfgang Denk writes:

The following systems are supported by PPCBoot:

Am I right in thinking that you are the author of PPCBoot?

But that would just shift  the  problem  from  the  kernel  into  the
wrapper:  you'd still need a standard way to pass information between
the firmware and  the  wrapper.  I  don't  see  where  there  is  any
improvement, then.

There is improvement because you can have a separate wrapper for each
firmware, if necessary.  At present if we want to change the way
information is passed into the kernel, we have to synchronously change
several different firmware/booter implementations, which are
maintained in separate places by separate people.  The list includes
(at least) BootX, miboot, yaboot, PPCBoot, and Michael Sokolov's VAX
console.  This is a logistical nightmare.  Just getting the updates
into the firmware/booters is bad enough, but then you create problems
for users who then can't boot old kernels with the new firmware or new
kernels with the old firmware.

I know that if you are the firmware author, it seems easy to you to
change the firmware and install a new version.  But please look at it
from the users' point of view.

The thing about the wrappers is that they are all maintained in the
one tree along with the kernel.  If we want to make a change to the
interface between the wrappers and the kernel we can easily do that in
a coordinated fashion, without creating any compatibility problems -
old kernels naturally use the old wrapper and new kernels use the new
wrapper.  The wrapper can provide any translation necessary between
what the firmware passes in and what the kernel expects.

The bi_record discussion comes to mind. Is this what you are thinking
of? As soon as such an interface is well defined we  will  make  sure
that it is directly supported by PPCBoot, too.

That's great, but I wonder what happens when someone upgrades their
PPCBoot to your new version and then wants to boot the old 2.4.2
kernel that they have lying around to check whether it shows a
particular problem they're chasing.

There have already been several rounds of  similar  discussions,  but
AFAIK  they  all  ended  with  just  a  declaration  of  intend to do
"something,  sometime".  Is  your  proposal  a  follow-up  to   these
discussions, or a new approach?

The reason that nothing has been done is precisely because it is so
hard at present to change the way that information is passed into the
kernel, because we still boot the vmlinux directly in some situations.

I am speaking from bitter experience here.  As another example, we
wanted to change the structure used to represent the OF device tree
node in the kernel.  We couldn't because that structure was also
passed in from BootX, not without implementing a translation layer.

If we absolutely *have* to boot a vmlinux directly without a wrapper,
then probably the best thing is to use bi_recs and pass in a pointer
to them, since that is reasonably flexible and can be made to be
forwards and backwards compatible without too much pain.  Changing to
this scheme is going to cause considerable pain in the short term,
though.

Paul.


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