linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: slash.tmp@free.fr (Mason)
To: linux-arm-kernel@lists.infradead.org
Subject: Building an uImage with appended DTB
Date: Wed, 25 Nov 2015 23:41:49 +0100	[thread overview]
Message-ID: <5656392D.8030904@free.fr> (raw)
In-Reply-To: <20151125184556.GP8644@n2100.arm.linux.org.uk>

On 25/11/2015 19:45, Russell King - ARM Linux wrote:
> On Wed, Nov 25, 2015 at 04:38:35PM +0000, Grant Likely wrote:
>> On Wed, Nov 25, 2015 at 4:16 PM, Mason wrote:
>>> Hello,
>>>
>>> Per Russell's advice (IIRC) I have a script to generate a uImage
>>> of a kernel with an appended DTB:
>>>
>>> export LOADADDR=0x80008000
>>> MAKE="make -j2 ARCH=arm"
>>> $MAKE dtbs zImage && \
>>> cat arch/arm/boot/zImage arch/arm/boot/dts/tango4-vantage-1172.dtb >zImage.tmp && \
>>> mv zImage.tmp arch/arm/boot/zImage && \
>>> $MAKE uImage
>>>
>>> Russell's version uses an explicit mkimage instead of "MAKE uImage"
>>> perhaps in part to get around the following limitation:
>>>
>>> if there is nothing to be done, cat+mv will update arch/arm/boot/zImage
>>> thus the uImage will be rebuilt even when it's not necessary.
>>>
>>> Doesn't the top-level Makefile support a target to build a uImage
>>> with appended DTB?
>>>
>>> (I suppose someone has submitted a patch for that. Was it perhaps
>>> never merged? Or did I just miss the feature?)
>>
>> I don't remember what happened there. That was a long time ago. I
>> think it got nacked, but cannot remember the reason.
> 
> It got nacked because we don't want these special boot loader specific
> formats in the kernel, and it's getting beyond a joke.  It was a mistake
> to merge the uImage target in the first place IMHO.
> 
> Previous to uboot, boot loaders were perfectly happy with zImage.  Today,
> all boot loaders are perfectly happy with a zImage - it's only the old
> legacy uboot versions that insist on uImage now.  There's now even less
> of a reason to think about merging some uImage based DT munging than there
> was several years ago.

Actually, I'm using a fairly recent version of U-Boot (2014.04)
IIUC, bootz should do the trick... But I'm not finding much doc
about it... <confused>

If I pass U-Boot a zImage, where should I load it, and how does
U-Boot know where to relocate it? (LOADADDR?)
And why is LOADADDR 0x80008000 and not 0x80000000 (the start
of the RAM)?

Misc links for my own reference:
https://patchwork.ozlabs.org/patch/146848/
https://stackoverflow.com/questions/22322304/image-vs-zimage-vs-uimage
https://unix.stackexchange.com/questions/122526/how-to-convert-a-zimage-into-uimage-for-booting-with-u-boot
http://lists.denx.de/pipermail/u-boot/2015-March/208551.html
http://www.denx.de/wiki/DULG/Manual

> Just do it in an external script, like I do here for platforms where it's
> necessary.  Absolutely no need to hack around in the kernel with special
> crap, like passing environment variables to make (which, you need a script
> for anyway, because its laborious to have to keep on typing them.)

How do you prevent your script from rebuilding the uImage every
time it is invoked?

> If you're writing a build script so you don't have to remember lots of
> environment variables for the kernel, you might as well write the build
> script to do the mkimage step for you.
> 
> So having it in the kernel is totally pointless and insane.

I understand.

Regards.

  reply	other threads:[~2015-11-25 22:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-25 16:16 Building an uImage with appended DTB Mason
2015-11-25 16:38 ` Grant Likely
2015-11-25 18:45   ` Russell King - ARM Linux
2015-11-25 22:41     ` Mason [this message]
2015-11-26  1:20       ` Russell King - ARM Linux
2015-11-27 17:23         ` Nicolas Pitre

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=5656392D.8030904@free.fr \
    --to=slash.tmp@free.fr \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).