[U-Boot] [RFC] skip area in flash/memory commands (cp, cmp, ...)

[U-Boot] [RFC] skip area in flash/memory commands (cp, cmp, ...)

[Andreas Pretzsch]

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 ?


-- 

carpe noctem engineering
Ingenieurbuero fuer Hard- & Software-Entwicklung Andreas Pretzsch
Dipl.-Ing. (FH) Andreas Pretzsch          Tel. +49-(0)731-5521572
Hahnengasse 3                             Fax: +49-(0)731-5521573
89073 Ulm, Germany                        email: apr at cn-eng.de

[U-Boot] [RFC] skip area in flash/memory commands (cp, cmp, ...)

[Albert ARIBAUD]

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.

[U-Boot] [RFC] skip area in flash/memory commands (cp, cmp, ...)

[Andreas Pretzsch]

Am Montag, den 11.04.2011, 21:31 +0200 schrieb Albert ARIBAUD:
> 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.

Or simply not to waste flash when having a few small sectors.

> 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.

ACK. The most obvious and simple approach for this scenario. And
rewriting the environment during an U-Boot update doesn't hurt that much
either, the possible window of data loss is reasonably small.


-- 

carpe noctem engineering
Ingenieurbuero fuer Hard- & Software-Entwicklung Andreas Pretzsch
Dipl.-Ing. (FH) Andreas Pretzsch          Tel. +49-(0)731-5521572
Hahnengasse 3                             Fax: +49-(0)731-5521573
89073 Ulm, Germany                        email: apr at cn-eng.de

[U-Boot] [RFC] skip area in flash/memory commands (cp, cmp, ...)

[Wolfgang Denk]

Dear Andreas Pretzsch,

In message <1302551856.13241.146.camel@ws-apr.office.loc> you wrote:
>
> > > What do you think, worth the effort, acceptable in mainline or
> > > over-engineering ?
> > 
> > Over-engineering IMO.

I agree with Albert here.

> > 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.
> 
> Or simply not to waste flash when having a few small sectors.

Right, that's exactly why this was invented.

> > 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.
> 
> ACK. The most obvious and simple approach for this scenario. And

No. It may be obvious, but there are far easier ways.

The most simple way is a sequence of tftp, protect off, erase, cp,
and finally saveenv.

As long as your flash layout does not change (and experience shows
that these are extremely rare cases) a simple "saveenv" is enough to
update your current environment in the freshly written U-Boot image.

For more fancy operations, you can use "env export".

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
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
I don't see any direct evidence ...  but, then, my crystal ball is in
dire need of an ectoplasmic upgrade. :-)              -- Howard Smith

[U-Boot] [RFC] skip area in flash/memory commands (cp, cmp, ...)

[Andreas Pretzsch]

Am Montag, den 11.04.2011, 23:08 +0200 schrieb Wolfgang Denk:
> > > 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.
> > 
> > ACK. The most obvious and simple approach for this scenario. And
> 
> No. It may be obvious, but there are far easier ways.
> 
> The most simple way is a sequence of tftp, protect off, erase, cp,
> and finally saveenv.

True, but it would pollute the env with transient variables like
fileaddr, filesize and serveraddr. Nothing serious, of course.
But in case of bootlimit enabled, it would also save "bootcount", which
might be a bad idea...

BTW, not sure if it's worth the effort (or a good idea at all), but one
might think about a concept of transient variables (in standard parser,
not checked hush parser).

-- 

carpe noctem engineering
Ingenieurbuero fuer Hard- & Software-Entwicklung Andreas Pretzsch
Dipl.-Ing. (FH) Andreas Pretzsch          Tel. +49-(0)731-5521572
Hahnengasse 3                             Fax: +49-(0)731-5521573
89073 Ulm, Germany                        email: apr at cn-eng.de

[U-Boot] [RFC] skip area in flash/memory commands (cp, cmp, ...)

[Wolfgang Denk]

Dear Andreas Pretzsch,

In message <1302614926.27200.12.camel@ws-apr.office.loc> you wrote:
>
> True, but it would pollute the env with transient variables like
> fileaddr, filesize and serveraddr. Nothing serious, of course.

Do you really care to delete these before each and every saveenv?
Or is your environment so small that you have to worry about 20 or 30
additional bytes?

> But in case of bootlimit enabled, it would also save "bootcount", which
> might be a bad idea...

Why?  It does not matter at all.

> BTW, not sure if it's worth the effort (or a good idea at all), but one
> might think about a concept of transient variables (in standard parser,
> not checked hush parser).

You can use hush, and plain shell variables there.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
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
Question: How does one get fresh air into a Russian church?
Answer:   One clicks on an icon, and a window opens!

[U-Boot] [RFC] skip area in flash/memory commands (cp, cmp, ...)

[Andreas Pretzsch]

Am Dienstag, den 12.04.2011, 16:15 +0200 schrieb Wolfgang Denk:
> Dear Andreas Pretzsch,
> 
> In message <1302614926.27200.12.camel@ws-apr.office.loc> you wrote:
> >
> > True, but it would pollute the env with transient variables like
> > fileaddr, filesize and serveraddr. Nothing serious, of course.
> 
> Do you really care to delete these before each and every saveenv?
> Or is your environment so small that you have to worry about 20 or 30
> additional bytes?

Neither. As stated, pure, irrelevant cosmetics.


> > But in case of bootlimit enabled, it would also save "bootcount", which
> > might be a bad idea...
> 
> Why?  It does not matter at all.

ACK. Looked at the code, bootcount is initialized via board-specific
bootcount_load(), not from env. So again, pure cosmetics. Sorry for the
noise.


-- 

carpe noctem engineering
Ingenieurbuero fuer Hard- & Software-Entwicklung Andreas Pretzsch
Dipl.-Ing. (FH) Andreas Pretzsch          Tel. +49-(0)731-5521572
Hahnengasse 3                             Fax: +49-(0)731-5521573
89073 Ulm, Germany                        email: apr at cn-eng.de