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
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,
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
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.
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@denx.de =====================================================================
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.
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
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.
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
participants (4)
-
Behan Webster -
Clemens Koller -
Josh Boyer -
Stefan Roese