From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] Inconsistencies in commands regarding load_addr
Date: Fri, 09 Oct 2015 15:18:26 +0200 [thread overview]
Message-ID: <20151009131826.51616382C64@gemini.denx.de> (raw)
In-Reply-To: <56177AC8.1020707@wsystem.com>
Dear Beno?t Th?baudeau,
In message <56177AC8.1020707@wsystem.com> you wrote:
>
> I'm not certain that this would be the least astonishing behavior. When I read
> the documentation, I rather expect the loadaddr environment variable to be used
> whenever the address is omitted in a command invocation. Moreover, one may have
> to read/load several data pieces before booting, and the last loaded piece would
> not necessarily be the one containing the kernel to be booted. This should at
> least be documented.
I agree about the need for documentation part.
Regarding the "load address" topic, be careful, as there has always
been a lot of confusion (due to unfortunate historic choice of names).
There is the "load address" as part of the image formates (uImage, FIT
image), which means the address where the image (OS code) gets loaded
(or even uncompressed) _to_. This is recorded in the image itself,
and has nothing to do woth the "loadaddr" variable, which states where
the image is located in system memory.
A command, that _loads_ an image to memory, should either use the
current setting of "loadaddr" (if no argument is given), of, if the
argument is given, set "loadaddr" to that value, so that further
commands can refer to that address by default.
> Another approach would be to compel users to pass an address for all commands.
That would break a ton of existing scripts, and is just cumbersome.
It is so easy to type for example just
tftp 400000 filename
imi
bootm
without having to care about the "loadaddr" setting.
> Implicit behaviors are always dangerous, all the more if they are undocumented.
I agree that documentation could be a lot better. But then, while many
people tend to critizise the exising documentation, very few actually
contribute to improving it.
> But of course, this would break some existing configurations.
True.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Great teachers have small audiences while they are still alive.
next prev parent reply other threads:[~2015-10-09 13:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-06 15:00 [U-Boot] Inconsistencies in commands regarding load_addr Benoît Thébaudeau
2015-10-06 18:09 ` Stephen Warren
2015-10-06 19:07 ` Benoît Thébaudeau
2015-10-08 4:40 ` Wolfgang Denk
2015-10-08 14:29 ` Stephen Warren
2015-10-08 21:29 ` Wolfgang Denk
2015-10-09 8:28 ` Benoît Thébaudeau
2015-10-09 13:18 ` Wolfgang Denk [this message]
2015-10-09 14:01 ` Benoît Thébaudeau
2015-10-09 14:55 ` Wolfgang Denk
2015-10-09 15:36 ` Stephen Warren
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=20151009131826.51616382C64@gemini.denx.de \
--to=wd@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