From: Scott Wood <hidden> Date: 2007-01-24 21:06:58
This will be required by the u-boot compatibility code to obtain a
compatible bd_t layout, to determine how to calculate the timebase, and
to know what soc fields need to be modified.
Signed-off-by: Scott Wood <redacted>
---
arch/powerpc/boot/Makefile | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
From: David Gibson <hidden> Date: 2007-01-24 23:51:50
On Wed, Jan 24, 2007 at 03:06:54PM -0600, Scott Wood wrote:
This will be required by the u-boot compatibility code to obtain a
compatible bd_t layout, to determine how to calculate the timebase, and
to know what soc fields need to be modified.
Erm.. I believe the omission of *all* kernel header files from the
boot wrapper code, including the config, is a deliberate decision.
The idea is that the wrapping can, if necessary, be done independent
of the kernel build.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: Kumar Gala <hidden> Date: 2007-01-25 02:08:09
On Jan 24, 2007, at 5:51 PM, David Gibson wrote:
On Wed, Jan 24, 2007 at 03:06:54PM -0600, Scott Wood wrote:
quoted
This will be required by the u-boot compatibility code to obtain a
compatible bd_t layout, to determine how to calculate the
timebase, and
to know what soc fields need to be modified.
Erm.. I believe the omission of *all* kernel header files from the
boot wrapper code, including the config, is a deliberate decision.
The idea is that the wrapping can, if necessary, be done independent
of the kernel build.
I think the problem is how to resolve the variations of the u-boot/
ppcboot bd_t that changes from board to board and based on config.
- k
From: David Gibson <hidden> Date: 2007-01-25 02:21:11
On Wed, Jan 24, 2007 at 08:08:02PM -0600, Kumar Gala wrote:
On Jan 24, 2007, at 5:51 PM, David Gibson wrote:
quoted
On Wed, Jan 24, 2007 at 03:06:54PM -0600, Scott Wood wrote:
quoted
This will be required by the u-boot compatibility code to obtain a
compatible bd_t layout, to determine how to calculate the
timebase, and
to know what soc fields need to be modified.
Erm.. I believe the omission of *all* kernel header files from the
boot wrapper code, including the config, is a deliberate decision.
The idea is that the wrapping can, if necessary, be done independent
of the kernel build.
I think the problem is how to resolve the variations of the u-boot/
ppcboot bd_t that changes from board to board and based on config.
Don't do that. We're trying to get rid of this config dependant crap
that means the kernel must be built for a single board. Instead make
the different bd_t options different options to the wrapper script.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: Paul Mackerras <hidden> Date: 2007-01-25 02:40:59
Kumar Gala writes:
I think the problem is how to resolve the variations of the u-boot/
ppcboot bd_t that changes from board to board and based on config.
The wrapper should be able to build bootable images for any of the
boards, that is, for any given bd_t variant, there should be a flag to
wrapper that tells it to build an image that understands that variant.
It's reasonable for arch/powerpc/boot/Makefile to pass different flags
to wrapper depending on the kernel config. I don't want wrapper
itself, or anything it uses, to be config-dependent.
Paul.
From: Scott Wood <hidden> Date: 2007-01-25 17:39:42
On Thu, Jan 25, 2007 at 01:40:59PM +1100, Paul Mackerras wrote:
Kumar Gala writes:
quoted
I think the problem is how to resolve the variations of the u-boot/
ppcboot bd_t that changes from board to board and based on config.
The wrapper should be able to build bootable images for any of the
boards, that is, for any given bd_t variant, there should be a flag to
wrapper that tells it to build an image that understands that variant.
It's reasonable for arch/powerpc/boot/Makefile to pass different flags
to wrapper depending on the kernel config. I don't want wrapper
itself, or anything it uses, to be config-dependent.
So basically, there'd be several lines in the arch/powerpc/boot/Makefile
like this?
cflags-$(CONFIG_6xx) += -DCONFIG_6xx
cflags-$(CONFIG_8xx) += -DCONFIG_8xx
cflags-$(CONFIG_E500) += -DCONFIG_E500
BOOTCFLAGS += $(cflags-y)
I don't really see the point (a simple grep will show you all the config
dependencies in the bootwrapper, to verify that it's only platform stuff
and not actual options), but I can do it that way if you really want.
One way or another, the information has to be there, and it has to be
compile-time or else the bd_info struct layout will be wrong.
-Scott
From: Paul Mackerras <hidden> Date: 2007-01-25 22:15:10
Scott Wood writes:
So basically, there'd be several lines in the arch/powerpc/boot/Makefile
like this?
cflags-$(CONFIG_6xx) += -DCONFIG_6xx
cflags-$(CONFIG_8xx) += -DCONFIG_8xx
cflags-$(CONFIG_E500) += -DCONFIG_E500
BOOTCFLAGS += $(cflags-y)
No no no. I said the Makefile could pass different flags to wrapper
depending on the config, that is, to the *invocation* of wrapper, not
the building of wrapper. As it does already - if you have
CONFIG_PPC_PMAC, it runs wrapper with "-p pmac"; if you have
CONFIG_PPC_PSERIES, it runs wrapper with "-p pseries". In your case
you would be using "-p myboard_uboot_bd_t_variant_59" or something
(hopefully more concise than that, of course :).
I don't really see the point (a simple grep will show you all the config
dependencies in the bootwrapper, to verify that it's only platform stuff
and not actual options), but I can do it that way if you really want.
One way or another, the information has to be there, and it has to be
compile-time or else the bd_info struct layout will be wrong.
So you will end up with a bunch of .o files, one for each possible
bd_t variant. They will all get built and the appropriate one will
get selected by wrapper based on the value you give with the -p
option. The line in arch/powerpc/boot/Makefile that defines src-plat
will list all of them.
Paul.