From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] skip area in flash/memory commands (cp, cmp, ...)
Date: Mon, 11 Apr 2011 21:31:56 +0200 [thread overview]
Message-ID: <4DA3572C.6020901@aribaud.net> (raw)
In-Reply-To: <1302547929.13241.128.camel@ws-apr.office.loc>
Le 11/04/2011 20:52, Andreas Pretzsch a ?crit :
> Objective: Skip an area in memory commands
>
> Example use case: Skip over embedded environment when updating U-Boot
>
> In case of an embedded environment, a complete U-Boot binary consists of
> two code sections and an environment block in between. In an update flow
> tftp/erase/cp/cmp conveniently using the complete image, the environment
> is also overwritten. As the env might contain device specific data, this
> is not always desirable.
> Of course, one could overcome this with several approaches, e.g.
> - provide two distinct U-Boot parts on the tftp server
> - load the complete image and erase/cp/cmp only the desired parts,
> either via hardcoded addresses and sizes or via some setexpr magic
> - other ways I simply missed
>
> While this is sufficent, I'd find it handy to be able to skip an area in
> the above commands.
> Possible approaches:
> - explicit via additional parameters to cp, cmp, etc.
> - implicit for the embedded environment (confusing and less generic)
> - based on e.g. some skip_addr, skip_len environment variables or
> even sets (addr1,addr2 + len1,len2)
>
> There might be other use cases I didn't thought of by now. Also, the
> command list is probably not complete.
>
> What do you think, worth the effort, acceptable in mainline or
> over-engineering ?
Over-engineering IMO.
There is a reason why a board defines its environment as embedded, and
it is because it wants it applied when flashing a new U-Boot.
But if you really want to keep the existing embedded environment when
flashing a new U-Boot, then after you have loaded the new U-Boot in RAM
as usual, all you need is to overwrite its environment with the one
already in Flash with a single, standard, cp.b instruction. After that
you can erase Flash and copy from RAM to Flash as usual.
Amicalement,
--
Albert.
next prev parent reply other threads:[~2011-04-11 19:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-11 18:52 [U-Boot] [RFC] skip area in flash/memory commands (cp, cmp, ...) Andreas Pretzsch
2011-04-11 19:31 ` Albert ARIBAUD [this message]
2011-04-11 19:57 ` Andreas Pretzsch
2011-04-11 21:08 ` Wolfgang Denk
2011-04-12 13:28 ` Andreas Pretzsch
2011-04-12 14:15 ` Wolfgang Denk
2011-04-13 19:57 ` Andreas Pretzsch
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=4DA3572C.6020901@aribaud.net \
--to=albert.u.boot@aribaud.net \
--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 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.