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.
next prev parent 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 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.