All of lore.kernel.org
 help / color / mirror / Atom feed
From: grant.b.edwards@gmail.com (Grant Edwards)
To: linux-arm-kernel@lists.infradead.org
Subject: Building kernel for more than one SoC
Date: Mon, 11 Aug 2014 23:02:40 +0000 (UTC)	[thread overview]
Message-ID: <lsbi2f$pib$1@ger.gmane.org> (raw)
In-Reply-To: 20140811224328.GD30401@n2100.arm.linux.org.uk

On 2014-08-11, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>
>> The problem is now you've got a kernel image that won't run on both
>> the '9g20 and the '9g25.  The requirement is to have a kernel image
>> that will run on either.
>
> It depends what you call a kernel image.
>
> As far as I'm concerned (and as I've been concerned from day one of uboot
> coming into ARM), the kernel image is the zImage, not the crap that uboot
> decides to dictate that you must provide for it to use.
>
> I've been pretty clear over the years that I utterly despise uboot's
> custom format - and you're starting to find out why.  Welcome to the
> inflexibility has caused. :)

Yea, I've got my own issues with U-Boot, but that's a whole 'nother
thread.  In the end, it was a lot less painful to put up with U-Boot's
issues than it was to write/port something else.

> While you have a point there, that's a choice of how you do your
> kernel upgrades.
>
> If you supply a zImage, all the dtbs, a script which does the
> programming of the kernel onto the target, and a copy of mkimage,
> then you can do all the steps I've highlighted above on the target -
> without the customer even having to know what platform they're on,
> because your script can work it out.

Good point.

> There's plenty of workarounds possible for the old uboot dilemma...

Definitely.  It all comes to do trying to figure out when the
work-arounds add up to more work than doing it the "right" way and
upgrading everything.

-- 
Grant Edwards               grant.b.edwards        Yow! All of life is a blur
                                  at               of Republicans and meat!
                              gmail.com            

  reply	other threads:[~2014-08-11 23:02 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-31 13:59 Building kernel for more than one SoC Grant Edwards
2014-07-31 21:07 ` Thomas Petazzoni
2014-08-04 19:11   ` Grant Edwards
2014-08-04 20:17 ` Russell King - ARM Linux
2014-08-11 15:42   ` Nicolas Ferre
2014-08-11 15:47     ` Grant Edwards
2014-08-11 16:12       ` Robert Nelson
2014-08-11 20:43         ` Grant Edwards
2014-08-11 20:59           ` Russell King - ARM Linux
2014-08-11 21:15             ` Grant Edwards
2014-08-11 21:38               ` Robert Nelson
2014-08-11 21:57                 ` Grant Edwards
2014-08-11 22:43               ` Russell King - ARM Linux
2014-08-11 23:02                 ` Grant Edwards [this message]
2014-08-14  1:12                   ` Tomasz Figa
2014-08-12  3:52                 ` Olof Johansson

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='lsbi2f$pib$1@ger.gmane.org' \
    --to=grant.b.edwards@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.