Dear Wolfgang Wegner,
In message 20091027125146.GA3216@leila.ping.de you wrote:
We hacked our U-Boot to provide non-blocking variants for flash access for the relevant functions, which are:
...
Is such a use case generally acceptable in U-Boot, and if so, does anybody have an idea how to implement those without all this duplicate code? Of course I can also implement this stuff in our board code, but it seems a bit unlogical to break the flash handling apart and the bloat would remain, just in a different place.
I understand your use case, and why it makes sense to you (or at least seems to make sense).
From your description I feel little enthusiasm for such code to go
mainline.
First, U-Boot is by design single-threaded. There are no such things as "background tasks" running, and adding these seems little attractive to me. If you need such complicated things or protocols you should be using an OS instead.
Second, I recommend not to implement such an update scheme. It suffers from the problem that you first have to erase valid data (without backup), before you know if you will get a replacement for these. Normally I recommend never to start erasing the flash before the download of the new image has been completed, and the image has been checked for consistency. This makes reliable update procedures much easier. Agin, quite often it makes sense to implement this not in U-Boot, but in an OS instead.
Third, your decription makes it clear that the use of this new feature depends on a proprietary download protocol, which nobody else uses (and probably nobody ever will use), i. e. you are the only user of this feature.
On the other hand, our rul for accepting code is that it should be useful at least to some, as long as it doesn't hurt others. So before making a definitive statement I think we should be able to have a look at the code first.
Best regards,
Wolfgang Denk