Hi, Ulf the data we expected to write in my case is about 288KB. BTW, Alex's FFU flow already implemented on my platform which using exynos SoC without problem. Thanks, Hsinhsiang 2014-09-01 19:27 GMT+08:00 Ulf Hansson <ulf.hansson@xxxxxxxxxx>: > On 1 September 2014 11:26, Alex Lemberg <Alex.Lemberg@xxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
