All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Roese <sr@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] In kernel mkimage
Date: Tue, 17 Jul 2007 17:12:55 +0200	[thread overview]
Message-ID: <200707171712.55768.sr@denx.de> (raw)
In-Reply-To: <469CD1E7.2090609@websterwood.com>

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
=====================================================================

  reply	other threads:[~2007-07-17 15:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-17  2:04 [U-Boot-Users] In kernel mkimage Josh Boyer
2007-07-17  9:19 ` Clemens Koller
2007-07-17 11:15   ` Josh Boyer
2007-07-17 14:27   ` Behan Webster
2007-07-17 15:12     ` Stefan Roese [this message]
2007-07-17 15:29       ` Behan Webster
2007-07-17 21:18         ` Josh Boyer
2007-07-17 21:37           ` Behan Webster
2007-07-18  2:24             ` Josh Boyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200707171712.55768.sr@denx.de \
    --to=sr@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.