From: Tom Rini <trini@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Call for participation in the U-Boot Mini Summit 2014
Date: Fri, 5 Sep 2014 15:21:57 -0400 [thread overview]
Message-ID: <20140905192157.GL25506@bill-the-cat> (raw)
In-Reply-To: <CAPnjgZ0dMewRtQW9FefaMWfHLfJEpO1K8QbcxRn6Jvwq3bYwgQ@mail.gmail.com>
On Fri, Sep 05, 2014 at 12:08:13PM -0600, Simon Glass wrote:
> Hi Tom,
>
> On 5 September 2014 11:53, Tom Rini <trini@ti.com> wrote:
> > On Fri, Sep 05, 2014 at 07:30:35PM +0200, Marek Vasut wrote:
> >
> > [snip]
> >> > It's easier to work with than fitImage.
> >>
> >> In which way?
> >
> > In most developer work flows at least zImage then uImage then fitImage
> > are the easiest to work with, in that order, for ARM. For ARM64 Image
> > in the next release will probably release uImage as the easiet to work
> > with.
> >
> > fitImage seems useful in a lot of deployment scenarios. Having to craft
> > up a good skeleton device tree in most cases is an annoying to overcome
> > barrier for a development workflow.
>
> I wonder if we could easily address that by building in the
> functionality to mkimage? For the common case of a kernel, FDT and
> ramdisk I don't see why anyone needs to write a .its file. It's just
> boilerplate.
Maybe. Or at least add in an example that doesn't do any reloc to it
AND make it clear that's what it does. Looking over my normally lost
boilerplate its file, it's kernel_noload that doesn't relocate things
around to the load/entry point so a generic example could be made.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140905/a1e35910/attachment.pgp>
next prev parent reply other threads:[~2014-09-05 19:21 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-13 17:12 [U-Boot] Call for participation in the U-Boot Mini Summit 2014 Detlev Zundel
2014-08-11 15:48 ` Przemyslaw Marczak
2014-08-11 21:08 ` Tom Rini
2014-08-12 0:02 ` Masahiro YAMADA
2014-08-12 0:49 ` Marek Vasut
2014-08-12 8:34 ` Igor Grinberg
2014-08-22 3:26 ` Masahiro Yamada
2014-08-30 16:36 ` Marek Vasut
2014-08-30 18:22 ` Lukasz Majewski
2014-09-03 16:36 ` Detlev Zundel
2014-09-03 16:34 ` Detlev Zundel
2014-08-12 0:45 ` Marek Vasut
2014-09-03 16:39 ` Detlev Zundel
2014-09-04 15:01 ` Marek Vasut
2014-09-05 15:50 ` Scott Wood
2014-09-05 17:30 ` Marek Vasut
2014-09-05 17:53 ` Tom Rini
2014-09-05 18:08 ` Simon Glass
2014-09-05 19:21 ` Tom Rini [this message]
2014-09-24 13:15 ` Jagan Teki
2014-08-12 7:15 ` Lukasz Majewski
2014-09-03 16:56 ` Przemyslaw Marczak
2014-09-18 8:52 ` Alexey Brodkin
2014-09-19 4:27 ` Marek Vasut
2014-09-23 11:50 ` Alexey Brodkin
2014-10-02 16:05 ` Detlev Zundel
2014-08-12 7:23 ` Lukasz Majewski
2014-09-03 16:46 ` Detlev Zundel
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=20140905192157.GL25506@bill-the-cat \
--to=trini@ti.com \
--cc=u-boot@lists.denx.de \
/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