The issue is mmc_init_erase() needs to be updated:
On modern eMMC, we set pref_erase to >ext_csd.hc_erase_size.
hc_erase_size, aka High Capacity Erase Group Size, is the minimum
amount of data that can be erased on that device, not the optimal
amount. It is used to be sure a partition ends on group
On Mon, Sep 14, 2015 at 8:00 AM, Jon Hunter wrote:
> From: Seshagiri Holi
>
> Certain eMMC devices allow vendor specific device information to be read
> via a sequence of vendor commands. These vendor commands must be issued
> in sequence and an atomic fashion. One way to support this would be to
On Thu, Nov 13, 2014 at 8:32 AM, Avi Shchislowski
wrote:
> Add support of FFU for eMMC v5.0
>
> Signed-off-by: Avi Shchislowski
> ---
> drivers/mmc/card/Kconfig |8 +
> drivers/mmc/card/block.c |5 +
> drivers/mmc/core/Makefile |1 +
> drivers/mmc/core/mmc_ffu.c | 487
> +
For eMMC 5.0 compliant device, firmware version is stored in ext_csd.
Report firmware as a 64bit hexa decimal. Vendor can use hexa or ascii
string to report firmware version.
Also add FFU related EXT_CSD register and note if the device is FFU capable.
Signed-off-by: Gwendal Grignou
---
drivers
On Thu, Oct 16, 2014 at 6:28 AM, Ulf Hansson wrote:
> On 16 October 2014 01:04, Gwendal Grignou wrote:
>> For eMMC 5.0 compliant device, firmware version is stored in ext_csd.
>> Report firmware as a 64bit hexa decimal. Vendor can use hexa or ascii
>> string to report firm
For eMMC 5.0 compliant device, firmware version is stored in ext_csd.
Report firmware as a 64bit hexa decimal. Vendor can use hexa or ascii
string to report firmware version.
Also add FFU related EXT_CSD register and note if the device is FFU capable.
Signed-off-by: Gwendal Grignou
---
drivers
, Gwendal Grignou wrote:
> Avi,
> We should revisit the 2 ioctls approach: Accroding to the spec:
> """When in FFU_MODE and host sends other commands which are not part
> of the recommended flow, device behavior may be undefined."""
>
> To be safe, no co
s well.
Gwendal.
On Mon, Jul 21, 2014 at 11:01 AM, Gwendal Grignou wrote:
> Avi,
>
> The patch still does not work for me. After the upgrade, the eMMC is
> not in a good state timing out every IOs. A power cycle fixes the
> problem.
> I am investigating how the reset patch is wor
gned-off-by: Alex Lemberg
>
> ---
> V8:
> - Modified according to Gwendal Grignou comments and patch:
>[PATCH] Fix on top of sandisk patches
>
> V7:
> - fixed mangled white space
>
> V5:
> - provides udev (request_firmware) implementation as advised in patch
>
not the right thing to do: the
caller called us with the lock held, we should not release it behind
its back.
We also need to revisit the eMMC reset, I had to drop the lock there as well.
>
> Alex
>
>> -Original Message-
>> From: Gwendal Grignou [mailto:gwen...@chromium
To apply on top of
[RFC PATCH 1/1 v7]mmc: Support-FFU-for-eMMC-v5.0
Signed-off-by: Gwendal Grignou
---
Avi,
As I mentioned earlier, I found several problems with your patch.
Here is a patch that allows to go further.
It is still not working reliably. The eMMC I am using has a problem
being
g, it will be always 1. Is there a
way to use an existing function instead of recopying what is in
mmc_test.c?
Gwendal.
On Wed, Jul 2, 2014 at 1:35 PM, Gwendal Grignou wrote:
> [resent in text mode]
> Avi,
> + I am testing the patch on a system where the firmware image is on
> the emmc
[resent in text mode]
Avi,
+ I am testing the patch on a system where the firmware image is on
the emmc itself. It fails most of the time. The problem is
mmc_ffu_download has been call with mmc_claim_host called, preventing
mmcqd from pulling the firmware from the disk. The dead lock situation
caus
driven by the device, resulting in a CRC error.
With this patch, we wait for both interrupts to be received before
completing the command.
Change-Id: I43b7467d59eb133d8c545115b48a5acbc450c2dd
Signed-off-by: Hankyung Yu
Signed-off-by: Chanho Min
Signed-off-by: Gwendal Grignou
---
I reformated
max_discard_sectors can not be larger than UINT_MAX>>9,
otherwise, there is a risk that discard requests would be merged
into a request larger than 4GB.
Signed-off-by: Gwendal Grignou
---
drivers/mtd/mtd_blkdevs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drive
max_discard_sectors can not be larger than UINT_MAX>>9,
otherwise, there is a risk that discard requests would be merged
into a request larger than 4GB.
Signed-off-by: Gwendal Grignou
---
drivers/block/nbd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block
max_discard_sectors can not be larger than UINT_MAX>>9,
otherwise, there is a risk that discard requests would be merged
into a request larger than 4GB.
Ensure that max_discard_sectors is in unit of sectors.
Signed-off-by: Gwendal Grignou
---
drivers/mmc/core/core.c | 6 --
1 file c
max_discard_sectors can not be larger than UINT_MAX>>9,
otherwise, there is a risk that discard requests would be merged
into a request larger than 4GB.
Signed-off-by: Gwendal Grignou
---
block/blk-lib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/blk-lib.c b
units of 512 bytes
sectors.
Gwendal Grignou (4):
Limit max_discard_sectors to UINT_MAX>>9
Limit max_discard_sectors to UINT_MAX>>9
Limit max_discard_sectors to UINT_MAX>>9
Limit max_discard_sectors to UINT_MAX>>9
block/blk-lib.c | 2 +-
drivers/block/nbd.c
nt: Saturday, March 01, 2014 1:21 AM
>> To: Grant Grundler
>> Cc: Avi Shchislowski; c...@laptop.org; linux-mmc@vger.kernel.org; Alex
>> Lemberg; Gwendal Grignou; Puthikorn Voravootivat
>> Subject: Re: [RFC PATCH 1/1] mmc-utils: Support-sending-eMMC-5.0-FFU
>>
>> On Fri
65536 KiB
...
Signed-off-by: Gwendal Grignou
Reviewed-by: Grant Grundler
---
mmc_cmds.c | 146 ++---
1 file changed, 102 insertions(+), 44 deletions(-)
diff --git a/mmc_cmds.c b/mmc_cmds.c
index b8afa74..4b9b12e 100644
--- a/mmc_cmds.c
+++ b/
21 matches
Mail list logo
