Fw: [patch 08/16] powerpc: remove EMBEDDED6xx Kconfig entry

Stephen Winiecki stevewin at us.ibm.com
Sat Nov 4 02:30:15 EST 2006








Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote on 11/02/2006
05:30:25 PM:

>
> > What exactly is the intent of PPC_MULTIPLATFORM - the current desc
> > states "Generic desktop/server/laptop" - which doesn't exactly scream
> > 'embedded' to me either.  I guess I saw embedded6xx as a 'catch-all'
> > for everything else.
>
> It's historical. It was the good old prep/chrp/pmac option, meaning that
> more than one board support can be built in the same kernel. I've made
> the policy decision with ARCH=powerpc that we should now make that
> mandatory for new boards (of course provided the CPUs are of the same
> family) since, as Sascha rightfully pointed out, it costs nothing and
> keeps things cleaner.
>
> Thus I'm all about getting rid of the option :)
>

OK - so in this sense PPC_MULTIPLATFORM would be used more to help
categorize (make ppc platforms depend on it in Kconfig) as opposed to
enabling different code/function? (thus some of Sascha's patches getting
rid of CONFIG_PPC_MMULTIPLATFORM ifdefs)

> > This may be slightly off topic - but one other thing I have noticed
> > that the new boot wrapper script supports specific 'types' of zImage
> > files associated w/ 'MUTIPLATFORMS' (PSERIES, CHRP, PREP etc.) and
> > uImage - which is what I think the majority of 'embedded' platforms
> > will use by defining CONFIG_DEFAULT_UIMAGE.
>
> That is not totally clear since they have non-compatible board info.

I should have more properly said "the majority of the existing 'embedded'
platforms (not PSERIES, CHRP, PREP etc.) currently implmented in /power
seem to define CONFIG_DEFAULT_UIMAGE"

> >   For IBM boards with PIBS just 'normal' zImage ELF files get loaded -
> > I'm not sure if there should be another type defined/supported for
> > boards which don't fit necessarily into a PSERIES/CHRP/PREP definition
> > and also don't use uboot - CONFIG_DEFAULT_ZIMAGE?
> >
>
> Ask Paulus about the naming but pSeries is just "normal" in the sense
> that it's "booted from a real OF" support.
>
> The problem is despite the ability to do those nice multiplatform kernel
> images, we still have bootloader incompatibilities. Thus we want to move
> those to the zImage wrapper which can produce, from an already built
> vmlinux binary, any zImage that can be supported for a given firmware
> interface.
>
> In the long run, we hope that firmwares will finally get their gears
> together and use either a real OF entry point or a direct flat
> device-tree entry point, which means that a single zImage (the "normal
> one as you call it) will be able to boot everything.
>
> There's also a glitch with real OF zImages due to the fact that IBM
> pSeries OF requires a Notes section forcing OF into real mode while
> Apple OF is allergic to that (it will crash badly) so we need to keep a
> separate zImage for PowerMac. However, the vmlinux are the same so if
> you use something like yaboot, the same vmlinux cna be booted on all
> those machines.

Makes sense.  Specific to the current wrapper though - the boot Makefile
currently keys off the following for the different zImage 'types'

image-$(CONFIG_PPC_PSERIES)             += zImage.pseries
image-$(CONFIG_PPC_MAPLE)               += zImage.pseries
image-$(CONFIG_PPC_IBM_CELL_BLADE)      += zImage.pseries
image-$(CONFIG_PPC_CHRP)                += zImage.chrp
image-$(CONFIG_PPC_PMAC)                += zImage.pmac
image-$(CONFIG_DEFAULT_UIMAGE)          += uImage

My original point really was that if I have a ppc 'embedded' board which I
don't want to classify/define as PSERIES/MAPLE/CELL_BLADE/CHRP/PMAC, and I
don't want to generate a uImage, I think there needs to be another
definition, something like CONFIG_DEFAULT_ZIMAGE (similar to how
CONFIG_DEFAULT_UIMAGE is used in some of the existing /power platform defs
to create a uImage) which would be used to produce a 'normal' zImage type
(zImage.pseries?).  Basically - a definition analogous to the exisiting
CONFIG_DEFAULT_UIMAGE, but for zImage.  It would be used in a similar way -
where any platform could select in its configuration to result in a
'normal' zImage being created (indeed, could PPC_PSERIES/MAPLE/BLADE just
select this more generic definition and the Makefile use it instead?)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20061103/f859e8ec/attachment.htm>


More information about the Linuxppc-dev mailing list