Currently, tarball builds for powerpc kernels don't have any boot
images (other than vmlinux) present.
Add support for powerpc builds in the buildtar script, to include
a few default images.
Signed-off-by: Jeremy Kerr <[email protected]>
---
RFC: any requests for more/less boot images?
---
scripts/package/buildtar | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/scripts/package/buildtar b/scripts/package/buildtar
index 28574ae..85e5563 100644
--- a/scripts/package/buildtar
+++ b/scripts/package/buildtar
@@ -72,6 +72,16 @@ case "${ARCH}" in
x86|i386|x86_64)
[ -f "${objtree}/arch/x86/boot/bzImage" ] && cp -v -- "${objtree}/arch/x86/boot/bzImage" "${tmpdir}/boot/vmlinuz-${KERNELRELEASE}"
;;
+ powerpc)
+ for img in zImage zImage.pseries zImage.iseries \
+ dtbImage dtbImage.ps3
+ do
+ imgpath=arch/powerpc/boot/${img}
+ [ -f "${objtree}/${imgpath}" ] || continue
+ cp -v -- "${objtree}/${imgpath}" \
+ "${tmpdir}/boot/${img}-${KERNELRELEASE}"
+ done
+ ;;
alpha)
[ -f "${objtree}/arch/alpha/boot/vmlinux.gz" ] && cp -v -- "${objtree}/arch/alpha/boot/vmlinux.gz" "${tmpdir}/boot/vmlinuz-${KERNELRELEASE}"
;;
> Currently, tarball builds for powerpc kernels don't have any boot
> images (other than vmlinux) present.
>
> Add support for powerpc builds in the buildtar script, to include
> a few default images.
>
> Signed-off-by: Jeremy Kerr <jk at ozlabs.org>
>
> ---
> RFC: any requests for more/less boot images?
>
..
> + for img in zImage zImage.pseries zImage.iseries \
> + dtbImage dtbImage.ps3
Yes. How about all dtbImage, zImage, cuboot, treeboot, etc
that are newer than vmlinux?
milton
Milton,
> Yes. How about all dtbImage, zImage, cuboot, treeboot, etc
> that are newer than vmlinux?
The existing arch code doesn't do any checks for timestamps, perhaps
this would be better implemented as an arch-independent change?
(but would you like me to add treeboot and cuboot?)
Cheers,
Jeremy
On Jul 24, 2008, at 8:11 PM, Jeremy Kerr wrote:
> Milton,
>
>> Yes. How about all dtbImage, zImage, cuboot, treeboot, etc
>> that are newer than vmlinux?
>
> The existing arch code doesn't do any checks for timestamps, perhaps
> this would be better implemented as an arch-independent change?
The problem is some people might want to add intermediate files that are
younger than vmlinux (eg .config). We know our boot-image should be
newer. But I don't know how one would express the expected ages.
The reason I suggested the check was to eliminate images that are not
in the current config. I figured a test for relative file age could
be done in the for loop -- possibly replace shell wildcard with
find arch/$(ARCH)/boot/{zImage*,dtbImage*,uImage*,cuImage*,treeboot*}
-newer vmlinux -print.
> (but would you like me to add treeboot and cuboot?)
I don't see why we should prefer the workstations and servers over the
embedded boards. zImage is just a link to the first boot image, but
one can build a multiple formats and the order is somewhat arbitrary.
So I see it as fairness. Otherwise, there are a few other platforms
that are "user" based vs embedded (like efkia, no?).
milton
On Thu, Jul 24, 2008 at 9:08 PM, Milton Miller <[email protected]> wrote:
>
>> Currently, tarball builds for powerpc kernels don't have any boot
>> images (other than vmlinux) present.
>>
>> Add support for powerpc builds in the buildtar script, to include
>> a few default images.
>>
>> Signed-off-by: Jeremy Kerr <jk at ozlabs.org>
>>
>> ---
>> RFC: any requests for more/less boot images?
>>
> ..
>> + for img in zImage zImage.pseries zImage.iseries \
>> + dtbImage dtbImage.ps3
>
> Yes. How about all dtbImage, zImage, cuboot, treeboot, etc
> that are newer than vmlinux?
dtbImage is not a buildable image. Neither is cuImage, treeImage or
simpleImage. All of those targets embed a device tree which is
specified by adding the .dts filename to the target name.
so, for example, 'make cuImage' fails. Instead you do 'make
cuImage.lite5200b' which pulls in dts/lite5200b.dts.
Also, zImage is a 'meta' target that builds all the default image
targets (the $image-y list). The zImage is actually just a symlink to
the first file in the list of default images. So zImage can actually
point to any kind of kernel image depending on how the kernel is
configured. I wonder if we should just remove the zImage file
entirely, or at least make it always linked to one particular image
type.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
On Jul 25, 2008, at 11:55 PM, Grant Likely wrote:
> On Thu, Jul 24, 2008 at 9:08 PM, Milton Miller <[email protected]> wrote:
>>> Add support for powerpc builds in the buildtar script, to include
>>> a few default images.
>>> ---
>>> RFC: any requests for more/less boot images?
>> ..
>>> + for img in zImage zImage.pseries zImage.iseries \
>>> + dtbImage dtbImage.ps3
>>
>> Yes. How about all dtbImage, zImage, cuboot, treeboot, etc
>> that are newer than vmlinux?
>
> dtbImage is not a buildable image. Neither is cuImage, treeImage or
> simpleImage. All of those targets embed a device tree which is
> specified by adding the .dts filename to the target name.
I intended "all dtbImage" as a wildcard for dtbImage.*, etc.
> so, for example, 'make cuImage' fails. Instead you do 'make
> cuImage.lite5200b' which pulls in dts/lite5200b.dts.
The user does make zImage which makes cuImage.lite5200b based on
Kconfig. Or it was that way until your change in 2.6.25 to allow the
later, but they can still do the former.
Hmm, we really need to fix our calls to make boot images with make -j.
Something for my todo list.
> Also, zImage is a 'meta' target that builds all the default image
> targets (the $image-y list). The zImage is actually just a symlink to
> the first file in the list of default images. So zImage can actually
> point to any kind of kernel image depending on how the kernel is
> configured. I wonder if we should just remove the zImage file
> entirely, or at least make it always linked to one particular image
> type.
I think its fine as it is. It says "make what is configured" that
lets cross-platform building scripts be dumb and not need to know
specificially what image makes sense to make. Perhaps we should make
it default to our additional target in Kconfig if specified, this
allowing the user to specify which version he gets.
milton
On Sat, Jul 26, 2008 at 1:20 PM, Milton Miller <[email protected]> wrote:
> On Jul 25, 2008, at 11:55 PM, Grant Likely wrote:
>>
>> On Thu, Jul 24, 2008 at 9:08 PM, Milton Miller <[email protected]> wrote:
>>>>
>>>> Add support for powerpc builds in the buildtar script, to include
>>>> a few default images.
>>>> ---
>>>> RFC: any requests for more/less boot images?
>>>
>>> ..
>>>>
>>>> + for img in zImage zImage.pseries zImage.iseries \
>>>> + dtbImage dtbImage.ps3
>>>
>>> Yes. How about all dtbImage, zImage, cuboot, treeboot, etc
>>> that are newer than vmlinux?
>>
>> dtbImage is not a buildable image. Neither is cuImage, treeImage or
>> simpleImage. All of those targets embed a device tree which is
>> specified by adding the .dts filename to the target name.
>
> I intended "all dtbImage" as a wildcard for dtbImage.*, etc.
Yeah, okay. That's a good idea.
>> so, for example, 'make cuImage' fails. Instead you do 'make
>> cuImage.lite5200b' which pulls in dts/lite5200b.dts.
>
> The user does make zImage which makes cuImage.lite5200b based on Kconfig.
> Or it was that way until your change in 2.6.25 to allow the later, but they
> can still do the former.
Yes, both methods should work (at least they both work for me). There
is also now a Kconfig option (CONFIG_EXTRA_TARGETS) which can be used
to add additional images to the zImage target list. Should be useful
for some of the defconfigs.
> Hmm, we really need to fix our calls to make boot images with make -j.
> Something for my todo list.
Good idea
>
>> Also, zImage is a 'meta' target that builds all the default image
>> targets (the $image-y list). The zImage is actually just a symlink to
>> the first file in the list of default images. So zImage can actually
>> point to any kind of kernel image depending on how the kernel is
>> configured. I wonder if we should just remove the zImage file
>> entirely, or at least make it always linked to one particular image
>> type.
>
> I think its fine as it is. It says "make what is configured" that lets
> cross-platform building scripts be dumb and not need to know specificially
> what image makes sense to make. Perhaps we should make it default to our
> additional target in Kconfig if specified, this allowing the user to specify
> which version he gets.
It makes sense if only one target is ever built at a time; but since
we build multiple targets, I don't want users to get caught just using
zImage and then get bitten when a a config or source change causes it
to be linked to a different kernel type.
Come to think of it, I'd support just removing the zImage symlink
entirely to eliminate confusion so that everyone knows that 'make
zImage' is the 'make all' for default image targets.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
On Sat, Jul 26, 2008 at 01:53:57PM -0400, Grant Likely wrote:
. . .
> Come to think of it, I'd support just removing the zImage symlink
> entirely to eliminate confusion so that everyone knows that 'make
> zImage' is the 'make all' for default image targets.
That ("zImage" means all default image targets) seems pretty non-intui-
tive; why not something like 'make all_def_images'?
Tom
--
/"\ ASCII Ribbon Campaign |
\ / | Email to user 'CTZ001'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
On Mon, Jul 28, 2008 at 11:34:35AM -0500, T Ziomek wrote:
> On Sat, Jul 26, 2008 at 01:53:57PM -0400, Grant Likely wrote:
> . . .
> > Come to think of it, I'd support just removing the zImage symlink
> > entirely to eliminate confusion so that everyone knows that 'make
> > zImage' is the 'make all' for default image targets.
>
> That ("zImage" means all default image targets) seems pretty non-intui-
> tive; why not something like 'make all_def_images'?
It is purely historical. zImage and modules have been the default
make targets for a long time. I'm not opposed to changing it, but it is
a change that affects almost everyone. I'd like to see some consensus
before going down this path.
g.