On Mon, Aug 11, 2014 at 09:15:22PM +0000, Grant Edwards wrote:

On 2014-08-11, Russell King - ARM Linux [off-list ref] wrote:

quoted

On Mon, Aug 11, 2014 at 08:43:35PM +0000, Grant Edwards wrote:

quoted

On 2014-08-11, Robert Nelson [off-list ref] wrote:

quoted

quoted

Now it's up to somebody else to decide if the price difference between
a G20 and G25 is worth the engineering time to upgrade U-Boot and
Linux kernel to versions that know about device trees...

http://cateee.net/lkddb/web-lkddb/ARM_APPENDED_DTB.html

Interesting.  That would still require modifying U-Boot so that at
run-time it detects the SoC type and appends the proper DTB to the
kernel image, but it that may be less work than "real" DTB support in
U-Boot.

The idea of that feature is:

- You take the kernel zImage
- You take the appropriate dtb file
- You concatenate the dtb file into the zImage
- You run mkimage on the resulting combined image to create the special
  uboot format file for uboot to load

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. :)

quoted

- You use it with uboot as you have done in the past with non-DT
  kernels.

Logistically, there's little difference between that and compiling the
kernel twice.  It's more elegant than compiling the kernel twice, but 
in the end it requires the maintenance of two separate kernel images
and some way for customers to figure out which one they should
download (and no matter what you do, when given a choice between two
files, they will download and attempt to install the wrong one more
than half of the time).

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.

If you don't have a shell on the target, then write a C program to do it
instead.

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

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.