Building kernel for more than one SoC
tomasz.figa at gmail.com
Wed Aug 13 18:12:29 PDT 2014
On 12.08.2014 01:02, Grant Edwards wrote:
> On 2014-08-11, Russell King - ARM Linux <linux at 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.
Is this maybe what you're looking for?
More information about the linux-arm-kernel