[U-Boot-Users] In kernel mkimage

[U-Boot-Users] In kernel mkimage

[Josh Boyer]

Hi All,

As part of my on-going 4xx work in the arch/powerpc kernel, I've been
toying with the idea of creating an in-kernel copy of the mkimage
tool, similar to how we have a mktree tool for the older OpenBIOS
firmware.

The main reason is that there isn't a stand-alone mkimage tool.
Currently, it's only available after you build u-boot itself for a
particular platform.  Ideally, you would be able to do 'make
tools/mkimage' and have it build, but that doesn't seem to be the
case.  And since it's a bit odd to require developers to build u-boot
before building a kernel I thought having an in-kernel copy would be
more efficient.

The tool itself doesn't get frequent updates, so keeping it in sync
shouldn't be a large issue.  However, I'd like to hear what other
people think of the idea before going off and doing that.

josh

[U-Boot-Users] In kernel mkimage

[Clemens Koller]

Josh Boyer schrieb:
> As part of my on-going 4xx work in the arch/powerpc kernel, I've been
> toying with the idea of creating an in-kernel copy of the mkimage
> tool, similar to how we have a mktree tool for the older OpenBIOS
> firmware.

Don't duplicate code, if it ain't necessary. Improve documentation
that  make <foo>  tells what's missing and how to fix it.

Regards,
-- 
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Stra?e 45/1
Linhof Werksgel?nde
D-81379 M?nchen
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

[U-Boot-Users] In kernel mkimage

[Josh Boyer]

On 7/17/07, Clemens Koller <clemens.koller@anagramm.de> wrote:
> Josh Boyer schrieb:
> > As part of my on-going 4xx work in the arch/powerpc kernel, I've been
> > toying with the idea of creating an in-kernel copy of the mkimage
> > tool, similar to how we have a mktree tool for the older OpenBIOS
> > firmware.
>
> Don't duplicate code, if it ain't necessary. Improve documentation
> that  make <foo>  tells what's missing and how to fix it.

I still argue that having 'make <foo>' tell someone they need to go
download u-boot and build it for a platform just to get that tool is a
bit bizarre.

josh

[U-Boot-Users] In kernel mkimage

[Behan Webster]

Clemens Koller wrote:
> Josh Boyer schrieb:
>   
>> As part of my on-going 4xx work in the arch/powerpc kernel, I've been
>> toying with the idea of creating an in-kernel copy of the mkimage
>> tool, similar to how we have a mktree tool for the older OpenBIOS
>> firmware.
>>     
>
> Don't duplicate code, if it ain't necessary. Improve documentation
> that  make <foo>  tells what's missing and how to fix it.
>   
I agree. Code shouldn't be duplicated.

Instead, perhaps the code should be moved (and maintained) in the kernel
tree.

mkimage is used for building kernel images (and other related things
like ramdisk images).  Building u-boot (for the use of one tool) should
not be a necessary part of building a kernel image.  Many people never
need to build u-boot being content with the bootloader that shipped with
their embedded target.

Lowering the barrier to entry to the use of u-boot (i.e. by allowing
kernels to be more easily built for it) will encourage more to use it. 
More people using it will eventually lead to more people interested in
learning about the code.  It also cuts down on people asking a FAQ.

It also puts a tool in the kernel tree which encourages others to use
u-boot as their boot loader. :)

It's a win-win solution.

-- 
Behan Webster
behanw at websterwood.com

[U-Boot-Users] In kernel mkimage

[Stefan Roese]

Hi Behan,

On Tuesday 17 July 2007, Behan Webster wrote:
> > Don't duplicate code, if it ain't necessary. Improve documentation
> > that  make <foo>  tells what's missing and how to fix it.
>
> I agree. Code shouldn't be duplicated.
>
> Instead, perhaps the code should be moved (and maintained) in the kernel
> tree.

Hmmm.

> mkimage is used for building kernel images (and other related things
> like ramdisk images).

And it is being used for building other images too. Not only Linux kernel 
images but other OS images (VxWorks, QNX, etc.), FPGA images, bitmaps and so 
on. Everything related to U-Boot in a way. So the mkimage tool should at 
least be available in the U-Boot source tree.

> Building u-boot (for the use of one tool) should 
> not be a necessary part of building a kernel image.  Many people never
> need to build u-boot being content with the bootloader that shipped with
> their embedded target.

Yes, you have a point here. I remember "porting" mkimage to Windows once 
(working for a different company of course ;-)).

> Lowering the barrier to entry to the use of u-boot (i.e. by allowing
> kernels to be more easily built for it) will encourage more to use it.
> More people using it will eventually lead to more people interested in
> learning about the code.  It also cuts down on people asking a FAQ.
>
> It also puts a tool in the kernel tree which encourages others to use
> u-boot as their boot loader. :)
>
> It's a win-win solution.

I have to support you here, that it should be easier to "use" mkimage in the 
Linux kernel generation. But completely removing it from the U-Boot source 
doesn't make sense to me because of the reasons mentioned above.

The easiest change would be to add a make target to the U-Boot top-level 
Makefile, for mkimage generation. This way the Linux "user" would at least 
not have to worry about compiling U-Boot for a not needed platform.

Just my 0.02$.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot-Users] In kernel mkimage

[Behan Webster]

Stefan Roese wrote:
> Hi Behan,
>   
Hey Stefan.

> On Tuesday 17 July 2007, Behan Webster wrote:
>   
>> mkimage is used for building kernel images (and other related things
>> like ramdisk images).
>>     
>
> And it is being used for building other images too. Not only Linux kernel 
> images but other OS images (VxWorks, QNX, etc.), FPGA images, bitmaps and so 
> on. Everything related to U-Boot in a way. So the mkimage tool should at 
> least be available in the U-Boot source tree.
>   
I was unaware.

It was merely an idea to remove the "duplication of code" concern.


>> Lowering the barrier to entry to the use of u-boot (i.e. by allowing
>> kernels to be more easily built for it) will encourage more to use it.
>> More people using it will eventually lead to more people interested in
>> learning about the code.  It also cuts down on people asking a FAQ.
>>
>> It also puts a tool in the kernel tree which encourages others to use
>> u-boot as their boot loader. :)
>>
>> It's a win-win solution.
>>     
>
> I have to support you here, that it should be easier to "use" mkimage in the 
> Linux kernel generation. But completely removing it from the U-Boot source 
> doesn't make sense to me because of the reasons mentioned above.
>   
Indeed.

> The easiest change would be to add a make target to the U-Boot top-level 
> Makefile, for mkimage generation. This way the Linux "user" would at least 
> not have to worry about compiling U-Boot for a not needed platform.
>   
This is the easiest and a good first step.

However, I agree with Josh that it's still strange that this is
necessary step to build a kernel.

Of course, if mkimage is a seperable tool, then at the very least linux
distributions can start to package it as a seperate tool. This is
something that a lot of users have asked for from what I've seen.

If it is both easy to build mkimage by itself, and can be distributed as
a package for the various distros, then most of this issue goes away.

-- 
Behan Webster
behanw at websterwood.com

[U-Boot-Users] In kernel mkimage

[Josh Boyer]

On 7/17/07, Behan Webster <behanw@websterwood.com> wrote:
> Stefan Roese wrote:
> > The easiest change would be to add a make target to the U-Boot top-level
> > Makefile, for mkimage generation. This way the Linux "user" would at least
> > not have to worry about compiling U-Boot for a not needed platform.
> >
> This is the easiest and a good first step.
>
> However, I agree with Josh that it's still strange that this is
> necessary step to build a kernel.
>
> Of course, if mkimage is a seperable tool, then at the very least linux
> distributions can start to package it as a seperate tool. This is
> something that a lot of users have asked for from what I've seen.

Yes.  I did that with the device tree compiler for Fedora recently.

> If it is both easy to build mkimage by itself, and can be distributed as
> a package for the various distros, then most of this issue goes away.

True.  The one thing that might pop up is that distros might object to
'mkimage' being too generic.  Though I think the chance of that being
a large issue is small.  We should definitely try and make it
standalone in some fashion.

josh

[U-Boot-Users] In kernel mkimage

[Behan Webster]

Josh Boyer wrote:
> On 7/17/07, Behan Webster <behanw@websterwood.com> wrote:
>> If it is both easy to build mkimage by itself, and can be distributed as
>> a package for the various distros, then most of this issue goes away.
>
> True.  The one thing that might pop up is that distros might object to
> 'mkimage' being too generic.  Though I think the chance of that being
> a large issue is small.  We should definitely try and make it
> standalone in some fashion.
This is a good point.  By rights it should be uboot-mkimage or something
like that.

However, stating that the kernel code depends on mkimage being named
mkimage is a good argument.

-- 
Behan Webster
behanw at websterwood.com

[U-Boot-Users] In kernel mkimage

[Josh Boyer]

On 7/17/07, Behan Webster <behanw@websterwood.com> wrote:
> Josh Boyer wrote:
> > On 7/17/07, Behan Webster <behanw@websterwood.com> wrote:
> >> If it is both easy to build mkimage by itself, and can be distributed as
> >> a package for the various distros, then most of this issue goes away.
> >
> > True.  The one thing that might pop up is that distros might object to
> > 'mkimage' being too generic.  Though I think the chance of that being
> > a large issue is small.  We should definitely try and make it
> > standalone in some fashion.
> This is a good point.  By rights it should be uboot-mkimage or something
> like that.

mkuimage would likely suffice.

> However, stating that the kernel code depends on mkimage being named
> mkimage is a good argument.

Surely you must be joking.  What distro are you using that would care
about what an embedded kernel build requires?

Anyway, we've bantered about this long enough. Time for a patch.
Hopefully tomorrow if Stefan doesn't beat me to it *wink* ;)

josh