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