From: Detlev Zundel <dzu@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 3/3] image: Allow images to indicate they're loadable at any address
Date: Tue, 08 Nov 2011 17:57:21 +0100 [thread overview]
Message-ID: <m2ipmud026.fsf@ohwell.denx.de> (raw)
In-Reply-To: <20111108155907.1E1BD13BE0C2@gemini.denx.de> (Wolfgang Denk's message of "Tue, 08 Nov 2011 16:59:07 +0100")
Hello Wolfgang and Nicolas,
please allow me to barge in at that point.
As I strongly believe that we all want to advance our software in a
technical sense and not spend time in flame wars - I am trying to think
of ways forward from the current state of affairs.
Without evaluating all the arguments individually, let me pick up
Wolfgangs latest suggestion which indeed seems like a pragmatic way
forward:
> | I suggest the following:
> |
> | - I will apply Stephen's previous patches to support relative images
> | as they are useful for people who want to use "proper" uImages
> | (containing a raw kernel image as payload) on different boards /
> | architectures.
> |
> | - If you want to boot zImages (with the kernel wrapper included and
> | thus fully relocatable), then please feel free and submit patches to
> | add support for booting zImage format in U-Boot. Then you get what
> | you want, and you can use zImages directly, without the 64 byte
> | uImage header that is only hindering for your usage mode.
> |
> | - It would be appreciated if we could get support for real uImages
> | (wrapping a raw kernel image) into Linux, then.
> |
> | This way those who want to use zImages can do so, and those who prefer
> | a different approach can have their ways, too.
My hope is that we can re-start the discussion from this - which
actually looks like a consensus.
For the unlikely but probable case of further disagreement, I propose a
vote on the mailing list as an "emergency tie breaker". As we
previously did not need to resort to such a measure, we do not have a
formal procedure ready for such a thing. Thinking about it a little
while, it would probably make sense to have people vote on the issue
that demonstrably care about the software and have invested substantial
effort in it. A natural choice for such a set people are of course the
custodians. So I would suggest to instantiate a poll among the
custodians as such a "tie breaker" if needed.
What do you think - is this a way forward?
Thanks
Detlev
--
Perfecting oneself is as much unlearning as it is learning.
-- Edsger Dijkstra
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
next prev parent reply other threads:[~2011-11-08 16:57 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-01 16:28 [U-Boot] [PATCH v2 1/3] image: Make image_get_fdt work like image_get_{ram_disk, kernel} Stephen Warren
2011-11-01 16:28 ` [U-Boot] [PATCH v2 2/3] image: Support FDTs already loaded at their load address Stephen Warren
2012-03-06 21:18 ` Wolfgang Denk
2011-11-01 16:28 ` [U-Boot] [PATCH v2 3/3] image: Allow images to indicate they're loadable at any address Stephen Warren
2011-11-05 22:20 ` Wolfgang Denk
2011-11-07 16:56 ` Stephen Warren
2011-11-07 17:09 ` Stephen Warren
2011-11-07 19:47 ` Simon Glass
2011-11-07 20:29 ` Wolfgang Denk
2011-11-07 21:17 ` Stephen Warren
2011-11-07 22:11 ` Wolfgang Denk
2011-11-07 22:30 ` Stephen Warren
2011-11-07 23:08 ` Wolfgang Denk
2011-11-08 0:00 ` Stephen Warren
2011-11-08 0:27 ` Wolfgang Denk
[not found] ` <74CDBE0F657A3D45AFBB94109FB122FF173F9A5035@HQMAIL01.nvidia.com>
2011-11-07 20:26 ` Wolfgang Denk
2011-11-07 21:04 ` Marek Vasut
2011-11-07 21:38 ` Stephen Warren
2011-11-07 21:59 ` Marek Vasut
2011-11-07 22:08 ` Stephen Warren
2011-11-07 22:27 ` Wolfgang Denk
2011-11-07 22:41 ` Stephen Warren
2011-11-07 23:10 ` Wolfgang Denk
2011-11-07 23:43 ` Stephen Warren
2011-11-07 22:57 ` Nicolas Pitre
2011-11-07 23:25 ` Wolfgang Denk
2011-11-08 0:10 ` Stephen Warren
2011-11-08 0:29 ` Wolfgang Denk
2011-11-08 0:48 ` Nicolas Pitre
2011-11-08 8:38 ` Wolfgang Denk
2011-11-08 11:35 ` Marek Vasut
2011-11-08 11:50 ` Wolfgang Denk
2011-11-08 11:52 ` Marek Vasut
2011-11-08 18:17 ` Stephen Warren
[not found] ` <74CDBE0F657A3D45AFBB94109FB122FF173F9A5424@HQMAIL01.nvidia.com>
2011-11-08 19:44 ` Wolfgang Denk
2011-11-08 21:17 ` Wolfgang Denk
2011-11-08 22:27 ` Stephen Warren
2011-11-08 22:46 ` Wolfgang Denk
2011-11-08 0:35 ` Nicolas Pitre
2011-11-08 1:10 ` Simon Glass
2011-11-08 3:51 ` Nicolas Pitre
2011-11-08 5:37 ` Simon Glass
2011-11-08 8:45 ` Wolfgang Denk
2011-11-08 14:22 ` Loïc Minier
2011-11-08 14:52 ` Jason
2011-11-08 20:18 ` Nicolas Pitre
2011-12-10 22:42 ` Linus Walleij
2011-12-10 22:53 ` Wolfgang Denk
2011-12-10 23:21 ` Linus Walleij
2011-12-12 16:25 ` Stephen Warren
2011-11-08 8:33 ` Wolfgang Denk
2011-11-08 14:26 ` Nicolas Pitre
2011-11-08 15:01 ` Marek Vasut
2011-11-08 15:59 ` Wolfgang Denk
2011-11-08 16:57 ` Detlev Zundel [this message]
2011-11-08 20:05 ` Nicolas Pitre
2011-11-07 21:27 ` Stephen Warren
2011-11-07 21:41 ` Nicolas Pitre
2011-11-07 22:42 ` Wolfgang Denk
2011-11-05 18:41 ` [U-Boot] [PATCH v2 1/3] image: Make image_get_fdt work like image_get_{ram_disk, kernel} Marek Vasut
2011-11-05 19:21 ` Simon Glass
2011-11-05 19:39 ` Marek Vasut
2011-11-05 20:38 ` Simon Glass
2011-11-05 20:41 ` Marek Vasut
2011-11-05 20:49 ` Simon Glass
2011-11-05 22:15 ` Wolfgang Denk
2011-11-05 22:18 ` Marek Vasut
2011-11-05 22:06 ` Wolfgang Denk
2011-11-05 21:53 ` Wolfgang Denk
2011-11-05 22:06 ` Marek Vasut
2011-11-05 22:22 ` Wolfgang Denk
2011-11-06 4:52 ` Simon Glass
2011-11-06 8:57 ` Wolfgang Denk
2011-11-05 21:40 ` Wolfgang Denk
2011-11-05 22:06 ` Marek Vasut
2011-11-05 22:24 ` Wolfgang Denk
2011-11-05 22:38 ` Marek Vasut
2011-11-08 14:24 ` Loïc Minier
2011-11-08 16:06 ` Wolfgang Denk
2011-11-08 18:15 ` Stephen Warren
[not found] ` <74CDBE0F657A3D45AFBB94109FB122FF173F9A5415@HQMAIL01.nvidia.com>
2011-11-08 19:33 ` Wolfgang Denk
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=m2ipmud026.fsf@ohwell.denx.de \
--to=dzu@denx.de \
--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