Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1292276 > unrolled thread

Re: [RFC 0/6] mmc: Field Firmware Update

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC 0/6] mmc: Field Firmware Update Ulf Hansson <ulf.hansson@linaro.org> - 2015-12-15 16:40 +0100
    Re: [RFC 0/6] mmc: Field Firmware Update Holger Schurig <holgerschurig@gmail.com> - 2015-12-22 09:20 +0100
      Re: [RFC 0/6] mmc: Field Firmware Update Ulf Hansson <ulf.hansson@linaro.org> - 2015-12-22 10:00 +0100
        Re: [RFC 0/6] mmc: Field Firmware Update Ulf Hansson <ulf.hansson@linaro.org> - 2015-12-22 10:00 +0100
          Re: [RFC 0/6] mmc: Field Firmware Update Olof Johansson <olofj@chromium.org> - 2015-12-22 19:50 +0100
      RE: [RFC 0/6] mmc: Field Firmware Update Alex Lemberg <Alex.Lemberg@sandisk.com> - 2015-12-28 16:50 +0100

#1292276 — Re: [RFC 0/6] mmc: Field Firmware Update

+Chris, Baolin

On 25 November 2015 at 09:56, Holger Schurig <holgerschurig@gmail.com> wrote:
> We had to modify the last patch a bit and was able to update a Kingston
> device from Firmware 0xba to 0xbd. But when doing this in user-space only is
> now the way to go, I should probably not submit it anymore?
>
> BTW, for this Kingston "EMMC16G-WL110-EBAU" the argument in the ext_csd is
> bogus. You need to use the "ffu_arg" hack from the mmc-utils patch and use
> argument 0x0000ffff. Sigh. They can't even stick to the standard.
>
>> Could you please add the original:
>
> Sorry, yes I could. But I won't, because if this can now be done reliably
> from user-space, there is no need to do this in kernel. So I guess the
> chances that a kernel solution get's applies is next to zero.

Hi Holger,

Sorry for the delay.

My advise right now is to try this out via the mmc ioctl in userspace,
yes. Although, if you encounter any issues with that approach that it
might not be reliable, I am open to look into the in-kernel solution
again.

Regarding mmc-utils as where I recommend you to implement this, I have
been thinking of moving this tool into the tools directory in the
kernel.

Baolin Wang, at Linaro is currently looking into this to see if it's
feasible. Ideas/comments are usual greatly appreciated.

Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1296609

> Sorry for the delay.

No problem, I was busy with many other projects as well.

> My advise right now is to try this out via the mmc ioctl in userspace,
> yes. Although, if you encounter any issues with that approach that it
> might not be reliable, I am open to look into the in-kernel solution
> again.

I managed to update my Kingston eMMCs with a slighly modified patch to
what I submitted. I however didn't bother to submit this, as I saw no
chance of getting it applied.

Also I once asked in the mailing list if there is some user-space
example of how to use the multi-block feature that is supposed to enable
this, but I haven't gotten an answer.

> Regarding mmc-utils as where I recommend you to implement this, I have
> been thinking of moving this tool into the tools directory in the
> kernel.

Sounds good to me.



Remotely related:

Do you know that some google people made their own version of mmc-utils
for ChromeOS? And the don't seem to give much effort in unification of
them?  As if the world wouldn't know how hard it can be to re-unite
things again, Google should know from their custom kernels they use on
Android ...  Sigh.


So you can

* git clone git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git
* git clone https://chromium.googlesource.com/chromiumos/third_party/mmc-utils

currently.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1296620

+ Gwendal, Grant, Olof, Seshagiri, Jon

On 22 December 2015 at 09:15, Holger Schurig <holgerschurig@gmail.com> wrote:
>
>> Sorry for the delay.
>
> No problem, I was busy with many other projects as well.
>
>> My advise right now is to try this out via the mmc ioctl in userspace,
>> yes. Although, if you encounter any issues with that approach that it
>> might not be reliable, I am open to look into the in-kernel solution
>> again.
>
> I managed to update my Kingston eMMCs with a slighly modified patch to
> what I submitted. I however didn't bother to submit this, as I saw no
> chance of getting it applied.
>
> Also I once asked in the mailing list if there is some user-space
> example of how to use the multi-block feature that is supposed to enable
> this, but I haven't gotten an answer.
>
>> Regarding mmc-utils as where I recommend you to implement this, I have
>> been thinking of moving this tool into the tools directory in the
>> kernel.
>
> Sounds good to me.
>
>
>
> Remotely related:
>
> Do you know that some google people made their own version of mmc-utils
> for ChromeOS? And the don't seem to give much effort in unification of
> them?  As if the world wouldn't know how hard it can be to re-unite
> things again, Google should know from their custom kernels they use on
> Android ...  Sigh.
>
>
> So you can
>
> * git clone git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git
> * git clone https://chromium.googlesource.com/chromiumos/third_party/mmc-utils

Thanks for sharing the information. Some Chromium folkz has certainly
been helpful in upstreaming activities, but you are right that there
is more to be done for mmc utils.

Perhaps by moving the code into the kernel tools dir and finding
someone who actively wants to maintain it, will enable improved
upstream activities!?

Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1296621

+ Olof (forgot to add him last time)

On 22 December 2015 at 09:55, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> + Gwendal, Grant, Olof, Seshagiri, Jon
>
> On 22 December 2015 at 09:15, Holger Schurig <holgerschurig@gmail.com> wrote:
>>
>>> Sorry for the delay.
>>
>> No problem, I was busy with many other projects as well.
>>
>>> My advise right now is to try this out via the mmc ioctl in userspace,
>>> yes. Although, if you encounter any issues with that approach that it
>>> might not be reliable, I am open to look into the in-kernel solution
>>> again.
>>
>> I managed to update my Kingston eMMCs with a slighly modified patch to
>> what I submitted. I however didn't bother to submit this, as I saw no
>> chance of getting it applied.
>>
>> Also I once asked in the mailing list if there is some user-space
>> example of how to use the multi-block feature that is supposed to enable
>> this, but I haven't gotten an answer.
>>
>>> Regarding mmc-utils as where I recommend you to implement this, I have
>>> been thinking of moving this tool into the tools directory in the
>>> kernel.
>>
>> Sounds good to me.
>>
>>
>>
>> Remotely related:
>>
>> Do you know that some google people made their own version of mmc-utils
>> for ChromeOS? And the don't seem to give much effort in unification of
>> them?  As if the world wouldn't know how hard it can be to re-unite
>> things again, Google should know from their custom kernels they use on
>> Android ...  Sigh.
>>
>>
>> So you can
>>
>> * git clone git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git
>> * git clone https://chromium.googlesource.com/chromiumos/third_party/mmc-utils
>
> Thanks for sharing the information. Some Chromium folkz has certainly
> been helpful in upstreaming activities, but you are right that there
> is more to be done for mmc utils.
>
> Perhaps by moving the code into the kernel tools dir and finding
> someone who actively wants to maintain it, will enable improved
> upstream activities!?
>
> Kind regards
> Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1296979

[sigh, in cleartext this time.]


2015-12-22 0:57 GMT-08:00 Ulf Hansson <ulf.hansson@linaro.org>:
> + Olof (forgot to add him last time)
>
> On 22 December 2015 at 09:55, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>> + Gwendal, Grant, Olof, Seshagiri, Jon
>>
>> On 22 December 2015 at 09:15, Holger Schurig <holgerschurig@gmail.com> wrote:
>>>
>>>> Sorry for the delay.
>>>
>>> No problem, I was busy with many other projects as well.
>>>
>>>> My advise right now is to try this out via the mmc ioctl in userspace,
>>>> yes. Although, if you encounter any issues with that approach that it
>>>> might not be reliable, I am open to look into the in-kernel solution
>>>> again.
>>>
>>> I managed to update my Kingston eMMCs with a slighly modified patch to
>>> what I submitted. I however didn't bother to submit this, as I saw no
>>> chance of getting it applied.
>>>
>>> Also I once asked in the mailing list if there is some user-space
>>> example of how to use the multi-block feature that is supposed to enable
>>> this, but I haven't gotten an answer.
>>>
>>>> Regarding mmc-utils as where I recommend you to implement this, I have
>>>> been thinking of moving this tool into the tools directory in the
>>>> kernel.
>>>
>>> Sounds good to me.
>>>
>>>
>>>
>>> Remotely related:
>>>
>>> Do you know that some google people made their own version of mmc-utils
>>> for ChromeOS?

"Make their own version" makes it sound like we've rewritten it. We
haven't. We've applied some patches locally over the last two years
based on work we've done for our products. It's not a deep fork.

We'd be happy to upstream them if there's interest from other users
and maintainers.

>> Perhaps by moving the code into the kernel tools dir and finding
>> someone who actively wants to maintain it, will enable improved
>> upstream activities!?


Hmm. If there's a well-defined userspace interface there's little
reason to bundle it directly, and I think that's the case here.

Chris has been busy with other stuff the last couple of years, is
there a lot of mmc-utils code that's out there that hasn't been picked
up?


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1298685

Hi Ulf,

We succeeded to run FFU via new mmc multi-command ioctl without any code modification, 
but only by using Single Sector commands (CMD24).

From running the FFU and from code review, we see two minor issues in this way of running FFU:
1. There is no support for Multiple Block write commands (CMD25) in existing IOCTL implementation - 
seems like there is no polling for the card status on data transfer completion.
(The kernel FFU implementation supports FFU using Multiple Block Write commands).
2. As you probably remember, there are two ways to install the new FW in the end of FFU process - 
In case MODE_OPERATION_CODES field is not supported by the device, the host sets to NORMAL state 
and initiates a CMD0/HW_Reset/Power cycle to install the new firmware.
This sequence cannot be done via multi-command ioctl, and requires manual reset of the device/platform.
(The kernel FFU implementation supports both FW install methods).

For running FFU via new mmc multi-command ioctl, we have modified mmc-utils and add new functionality for FFU.
Please let us know if you want us to submit the patch for mmc-utils FFU functionality via multi-command ioctl.

Best regards,
Alex

> -----Original Message-----
> From: Holger Schurig [mailto:holgerschurig@gmail.com]
> Sent: Tuesday, December 22, 2015 10:15 AM
> To: Ulf Hansson
> Cc: Avi Shchislowski; linux-mmc@vger.kernel.org; linux-
> kernel@vger.kernel.org; Alex Lemberg; Chris Ball; Baolin Wang
> Subject: Re: [RFC 0/6] mmc: Field Firmware Update
> 
> 
> > Sorry for the delay.
> 
> No problem, I was busy with many other projects as well.
> 
> > My advise right now is to try this out via the mmc ioctl in userspace,
> > yes. Although, if you encounter any issues with that approach that it
> > might not be reliable, I am open to look into the in-kernel solution
> > again.
> 
> I managed to update my Kingston eMMCs with a slighly modified patch to
> what I submitted. I however didn't bother to submit this, as I saw no chance
> of getting it applied.
> 
> Also I once asked in the mailing list if there is some user-space example of
> how to use the multi-block feature that is supposed to enable this, but I
> haven't gotten an answer.
> 
> > Regarding mmc-utils as where I recommend you to implement this, I have
> > been thinking of moving this tool into the tools directory in the
> > kernel.
> 
> Sounds good to me.
> 
> 
> 
> Remotely related:
> 
> Do you know that some google people made their own version of mmc-utils
> for ChromeOS? And the don't seem to give much effort in unification of
> them?  As if the world wouldn't know how hard it can be to re-unite things
> again, Google should know from their custom kernels they use on Android ...
> Sigh.
> 
> 
> So you can
> 
> * git clone git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git
> * git clone
> https://chromium.googlesource.com/chromiumos/third_party/mmc-utils
> 
> currently.
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web