I’ve installed torizon on my iMX6UL and it is working brilliantly. I see nothing that might stop me using it in production, but toradex recommends against that, I’m wondering:
Greetings @alt.mattr,
I’m glad to hear you’re having a good experience with Torizon on the 6ULL. Allow me to clear up what the situation is regarding the support of this platform.
specifically why is it not
recommended? I assume it is better
tested than any custom yocto image I
might build for example
Torizon as you might’ve figured out relies heavily on container usage rather than traditional embedded workflows. Containers have a overhead when it comes to memory and flash usage compared to non-container equivalents. Since the 6ULL only has 512MB RAM and flash, it is more susceptible to running into issues due to these hardware constraints. As such we usually don’t recommend this configuration just to avoid any potential headaches for customers.
In the end this relies on the exact use-case though. I assume your particular use-case is light enough that it doesn’t run into these issues. Just be aware of these limitations as you work with this platform.
what are the chances that it will work
with torizon OTA in the future?
The support with OTA on the 6ULL is similar to on Torizon. It “should” work on a basic level, but it’s more liable to have issues.
can you give me any recommendations to
start measuring the health of the
flash memory with torizon?
This isn’t an easy question and depends on many factors. I’d suggest looking at this webinar we did about flash memory and monitoring the health of it: Webinar: Flash Memory in Embedded Linux Systems
Out of curiosity though, what kind of work load do you have that you are concerned about the health of the flash?
Finally I just wanted to share that we here at Toradex have planned a variant of the 6ULL with eMMC flash. This variant is planned to be fully supported and tested on Torizon and OTA. So this might be something you should keep an eye out for.
Best Regards,
Jeremias
@jeremias.tx Thanks so much, those are the answers I was hoping for. My application seems to fit just fine with some headroom. I can put a slim debian image with python, sqlite, and the libraries I need on the board no worries. I will experiment with rust next.
My application should only write 256B once every couple of days, but I am not sending anything into the field without measuring it first. There is torizon, debian-slim, python, sqlite, etc, all loaded up and running and none of that code was written by me 
I also need to see with my own eyes that the software layer looking after the memory is working before sending units out into the field.
Imagine one of the things I included in the image is logging without me knowing. Imagine it appends to a file until there is no space, then starts writing over the earlier logs. If it writes every 20 seconds it will hit 100,000 writes within a month. So I suppose a trustworthy measurement of disk writes will get the job done, just so I know for sure I haven’t built an image that is eating away at my writes budget.
The 6ULL with eMMC sounds like a killer product, I look forward to it!
Good to see that you are happy with the news for the new SKU of Colibri iMX6ULL.
But, I ask you to have a little patience because it will take some time until be publicly available, ok?
Thanks for the detailed explanation @jeremias.tx.
Is there anything else we could help you with, @alt.mattr?
Best regards,
André Curvello
Hi @alt.mattr,
I’m looking for a way to do that on Colibri iMX6ULL, the version with NAND memory, ok?
As soon as I have feedback I’ll reply here.
Best regards,
André Curvello
Hi @alt.mattr
The really important number is not amount of flash writes but NAND block erase counters. Because flash get worn not by writing but by block erasing. Each non-bad physical eraseblock of UBI volume has 2 small 64-byte headers :
erase counter header (or EC header) which contains the erase counter of the physical eraseblock (PEB) plus other information;
volume identifier header (or VID header) which stores the volume ID and the logical eraseblock (LEB) number to which this PEB belongs.
A UBI subsystem uses a wear leveling to distribute the erases of heavely used eraseblocks to different eraseblocks. You can get value of maximum erase counter available in /sys/class/ubi/ubi0/max_ec
Colibri iMX6ULL has an SLC NAND Flash and it’s endurance is around 100k erase cycles per block.
@alex.tx thankyou so much. That is exactly the detailed info I needed and it has led me to the subsystem I needed to understand. I’ve been searching high and low and getting nowhere near the UBI stuff, now that I have found it, everything is clear and easy.
Thanks for feedback. Glad I was able to help.
@andrecurvello.tx I’m good thanks. Any advice or direction from folks at toradex who know more about flash writes than I would be appreciated. I just need some way of monitoring global write activity during testing so I can measure it before sending the devices out. Don’t care what process writes, don’t care where, I just need to measure before shipping.
Thanks for the detailed information, @alex.tx.
Is there anything else we could help you with, @alt.mattr?
