On 1 September 2014 11:26, Alex Lemberg <alex.lemb...@sandisk.com> wrote: > [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.
You are right regarding multiple I/O! I suppose using single block write option (CMD24) still can be used for FFU, right? Yes, we would suffer from unoptimized performance, but on the other hand - how much data could we typically be expected to write? Do you have some rough numbers that you can share? > > 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 That is likely because the mmc host driver may limit the size, due to it's controller HW. > > Based on this, we think that using existing IOCTL implementation is not > a good solution for FFU. Okay, let's for now continue with your current approach and try to address those concerns I have raised while reviewing the code. I will happily review new versions of the patch(es). Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
