As for FW file size - we also know about 512KB data and above. Thanks, Alex > -----Original Message----- > From: linux-mmc-owner@xxxxxxxxxxxxxxx [mailto:linux-mmc- > owner@xxxxxxxxxxxxxxx] On Behalf Of Hsin-Hsiang Tseng > Sent: Thursday, September 04, 2014 4:06 AM > To: Ulf Hansson > Cc: Alex Lemberg; linux-mmc@xxxxxxxxxxxxxxx; cjb@xxxxxxxxxx; Grant > Grundler; Avi Shchislowski; Gwendal Grignou (gwendal@xxxxxxxxxxxx) > Subject: Re: [RFC PATCH 1/1 v8]mmc: Support-FFU-for-eMMC-v5.0 > > 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 ��.n��������+%������w��{.n�����{��i��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
