[snip]
> My conclusion from that is (correct me if I am wrong, since it may be vendor
> specific), that only minor modifications should be needed to the mmc ioctl. We
> need to add special treatment for when "cmd.opcode ==
> MMC_FFU_DOWNLOAD_OP". In such scenario the following sequence needs to
> be maintained.
>
> 1. Claim host etc.
> 2. Set FFU mode.
> 3. Write some sectors to the FFU area, but in the same way as any other mmc
> ioctl WRITE is done.
> 4. Set normal mode.
> 5. Relase host etc.
>
> That sequence then needs to be repeated to write the complete firmware,
> depending on buffer size. Between each and every piece of FFU data that is
> written, normal READ/WRITE operations can be served.
> Right?
We checked again the current IOCTL implementation, and we see issues
In implementing FFU as suggested above:
1. No support for multiple Write operations.
For running Multiple I/O, user need to send CMD23 or CMD12.
So structures "sbc" or "stop" of "mmc_blk_request" should be set accordingly.
2. There is a limit in chunk size in current implementation of IOCTL.
From some reason we can't write more than 64KB on our platform,
Although, the MMC_IOC_MAX_BYTES is defined to be 128KB
Based on this, we think that using existing IOCTL implementation is not
a good solution for FFU.
Thanks,
Alex
��.n��������+%������w��{.n�����{��i��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
