Colibri T30 eMMC write/erase cycles (reliability)

Technical Support
, , ,
1

Hi Toradex, support and community,

We are developping a system based on Colibri T30 modules. Our software environnent is based on:

We still use nvflash to flash our boards since we need a standalone USB tool to program the SoM at manufacturing. New scheme with U-Boot only is not possible right now.

In our continuous integration system, we noticed that flashing the Colibri started to sometimes fail in the middle of a flashing operation with nvflash (stucked in the middle of the process) with no alternative to restart a flashing (including config block which gets lost in these situations).

The error condition occurred more and more often up to the point where we could hardly ever succeed to program the whole module.

We suspect an eMMC wear-out which could explain why we saw the fail ratio increase over the time.
I couldn’t find any information on the number of erase/write cycles of the Hynix eMMC mounted on Colibri T30.

Toradex Knowledge Base on Flash gives some numbers for raw flash (SLC and MLC) but nothing for the eMMC. Do you have some specification on the possible number of writes on your eMMC ?

Do you know if the eMMC will internally perform wear-levelling on the whole flash area or if the same blocks get written if we always flash at the same linearr address with nvflash ? In other words, does the flashing at always the same address/offset always hit the same blocks/pages or do these low-level writes benefit from wear-leveling done at the eMMC layer.

Thanks for any help helping us to track down our issues.

Romain

2

We are developing a system based on Colibri T30 modules. Our software environment is based on:

Toradex Linux kernel from BSP V2.6

U-Boot 2011.06 of “Toradex Colibri T30 Linux BSP V2.3 Beta 1” built from sources

Rootfs generated with Buildroot (https://buildroot.org/)

We still use nvflash to flash our boards since we need a standalone USB tool to program the SoM at manufacturing. New scheme with U-Boot only is not possible right now.

Nothing speaks against doing so using our latest BSP as well. Antmicro is e.g. using this to deploy Android onto our modules. Our upcoming Toradex Easy Installer tool will also integrate this in a manner easy to integrate into custom manufacturing deployments.

In our continuous integration system, we noticed that flashing the Colibri started to sometimes fail in the middle of a flashing operation with nvflash (stucked in the middle of the process) with no alternative to restart a flashing (including config block which gets lost in these situations).

Which is one of the many reasons we no longer support NVIDIA’s proprietary Fastboot/NvFlash.

The error condition occurred more and more often up to the point where we could hardly ever succeed to program the whole module.

We suspect an eMMC wear-out which could explain why we saw the fail ratio increase over the time. I couldn’t find any information on the number of erase/write cycles of the Hynix eMMC mounted on Colibri T30.

I really don’t think this has anything to do with eMMC wear-out as one typically would have to write to the eMMC extensively (e.g. continuous writing for weeks or even months) to hit any such issues.

Toradex Knowledge Base on Flash gives some numbers for raw flash (SLC and MLC) but nothing for the eMMC. Do you have some specification on the possible number of writes on your eMMC ?

eMMC are typically based on MLC technology so the same 3’000 up to 10’000 program/erase cycles apply there as well. The exact number is depending on the particular eMMC part/vendor.

Do you know if the eMMC will internally perform wear-levelling on the whole flash area or if the same blocks get written if we always flash at the same linearr address with nvflash ?

Of course, the firmware running on the eMMC internal controller will take care of this.

In other words, does the flashing at always the same address/offset always hit the same blocks/pages or do these low-level writes benefit from wear-leveling done at the eMMC layer.

Using eMMC wear levelling is entirely managed by the controller/firmware inside.

Thanks for any help helping us to track down our issues.

You are very welcome.

3

Hi Marcel,
Thanks for the fast feedback.

Nothing speaks against doing so using
our latest BSP as well. Antmicro is
e.g. using this to deploy Android onto
our modules. Our upcoming Toradex Easy
Installer tool will also integrate
this in a manner easy to integrate
into custom manufacturing deployments.

Do you have any documentation on this functionality (Antmicro deployment process) ?

Do you have any timeline for the “Toradex Easy Installer” release ?

From what I read on Flashing from Scratch and Txx Recovery Mode we can boot the Colibri in Recovery Mode, download a U-Boot binary directly in RAM and then from the U-Boot prompt executes commands to flash the desired images into eMMC getting them from USB, network or SD-card.

Is their a way to flash using only the USB port like with nvflash (no USB, no SD-card, no network)?

Thanks for your good support!

4

Hi Romain

Nothing speaks against doing so using our latest BSP as well. Antmicro is e.g. using this to deploy Android onto our modules. Our upcoming Toradex Easy Installer tool will also integrate this in a manner easy to integrate into custom manufacturing deployments.

Do you have any documentation on this functionality (Antmicro deployment process) ?

Not really, no. Basically you just deploy a U-Boot binary which automatically re-connects via USB device connection using USB mass storage emulation (e.g. ums 0 mmc 0 as bootcmd).

You may also download Antmicro’s Android pre-view image and have a look at their update script for reference.

Do you have any timeline for the “Toradex Easy Installer” release ?

Milestone 1 which will be available by the end of this year concentrates on Apalis/Colibri iMX6 for now. The other modules especially the eMMC ones will follows suit shortly. Them NAND modules may take some more integration work and will follow later next year.

From what I read on Flashing from Scratch and Txx Recovery Mode we can boot the Colibri in Recovery Mode, download a U-Boot binary directly in RAM and then from the U-Boot prompt executes commands to flash the desired images into eMMC getting them from USB, network or SD-card.

Exactly, but one can fully automate that later step by having U-Boot automatically execute it upon having been loaded into RAM.

Is their a way to flash using only the USB port like with nvflash (no USB, no SD-card, no network)?

Yes, using UMS as mentioned above.

Thanks for your good support!

You are very welcome.

Cheers

Marcel

Platform Manager Embedded Linux

5

Hi Marcel,

Thanks for the detailed information. In the meantime I had downloaded the Antmicro’s Android pre-view image and have had a look at their update.sh script which uses the ums storage process you described.
I find the solution really elegant and easy to deploy, especially at manufacturing.
I’ll have a deeper look at it and will try to use it on our own system. We have a slightly different configuration than with your evalboards (serial console on other UART, different uses of USB ports) but I should be able to adapt accordingly.

Regards,
Romain