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: a...@cn-eng.de _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot