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.