[U-Boot] non-blocking flash functions - is this possible/acceptable?

Jerry Van Baren
2009-10-27T13:21:25Z

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