Wolfgang Wegner wrote:
Hi,
we have an update protocol that normally relies on data being received while the previous block is written to flash.
We hacked our U-Boot to provide non-blocking variants for flash access for the relevant functions, which are:
flash_status_check_nb() flash_full_status_check_nb() flash_erase_nb() (single-sector only) flash_write_cfibuffer_nb() write_buff_nb()
Apart from flash_status_check_nb() and flash_erase_nb() (the latter being reduced to handle only one sector at a time), these are mainly the same functions as the originals, but use flash_[full_]status_check_nb() instead, so there is much duplicate code.
Is such a use case generally acceptable in U-Boot, and if so,
I'll defer to Wolfgang Denk, Stefan Roese, (Scott Wood?), and others for this half.
My 2c: Overlapping data transfer with flash erase/write operations can be beneficial as it can reduce the programming time substantially. (Erase is less beneficial than write since erases don't happen as often and take a relatively long time, so the overlap optimization savings is a smaller percentage of the total erase time - Amdahl's Law.)
anybody have an idea how to implement those without all this duplicate code?
Move the code to the non-blocking functions (which you have already done), and then implement the blocking versions as wrappers that simply call the non-blocking write followed by a loop calling flash_status_check_nb() until the write is complete. For erase, you would need a loop to do the multi-sector erase as multiple non-blocking + wait operations.
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.
Yes, that would be horrible.
[I am bringing this topic up because I am trying to prepare patches for sending to the list, and this one seems to me as a real show-stopper right now.]
Regards, Wolfgang
Best regards, gvb