iMX6ULL storage questions

Dear Community;

We are planing to use the iMX6ULL as main CPU of a new product we plan to lunch. The development of the product has been done on a iMX7D 4GB eMMC CPU. The main problem to port the software from iMX7 to iMX6ULL is lack of internal memory to install all programs and packages we need. To solve that we have thought some solutions:

1.- We have read that is some cases Linux BSP can be boot from and SD card. If this would be possible is it reliable to install the BSP in the SD card an boot from there?

2.-We don’t know if it is possible or not, but other alternative can be to install the BSP on the 512MB SLC NAND module and create a partition with a SD card to install all packages and programs…

Any idea or suggestion is highly appreciated.

Thanks a lot;

Ander.

I have done this before with OpenWRT and guess it would be the same here. There are two techniques: pivot-overlay and pivot-root. pivot-overlay leaves the main part of the rootfs on the flash and allows the overlay to be on SDcard, or the pivot-root allows the entire rootfs to be on SD card. These are the commands I use to setup pivot-overlay on OpenWRT(assuming your sdcard is mmcblk0p1).

$ mkdir /mnt/mmcblk0p1
$ mount /dev/mmcblk0p1 /mnt/mmcblk0p1
$ mount /dev/mmcblk0p1 /mnt ; tar -C /overlay -cvf - . | tar -C /mnt -xf - ; umount /mnt
$ opkg install block-mount
$ /sbin/block detect > /etc/config/fstab
$ vi /etc/config/fstab 
	Change: 	option  target  '/mnt/ mmcblk0p1'
	to:			option target '/overlay'
	Change:	option  enabled '0'
	To:			option  enabled '1'
$ reboot

My first step would be to verify that there is no unnecessary package inside the rootfs image. Have you double-checked that all packages inside rootfs is actually required and there is no room for stripping down the image?

Dear @Andermutu,

@isaac made a good point that you should take into account, which is stripping the image of unneeded software. This may be time consuming but definitely should be your first option.

Answering your questions, Linux SD card booting can be done through the proper Uboot commands as explained here: Once you’ve loaded Uboot (from flash) you can select to boot from the sdcard which may work simply with boot sdcard in Uboot. SD card-based main storage systems are not as reliable as flash, so we would recommend, if there is absolute need in using the SD card as a semi-permanent storage, to leave as much as possible the rootfs in the flash and leave less critical data for the SD card. For this, you can follow @lachlanp, but I haven’t tried this myself.

If you change the location of the packages, you may get away by adding some symbolic links pointing to your moved packages, wherever they are.

Regards, Alvaro.

Thank you @lachlanp for you answer. It look very good but I have problems installing block-mount.
I have tried with : opkg update and then opkg install block-mount but does not find anything (opkg_prepare_url_for_install: Couldn’t find anything to satisfy ‘block-mount’)

Which BSP are you using, or how can I install block-mount?

Thanks a lot.

Hi @alvaro.tx;

Assuming that SD card is not reliable at all I will try @lachlanp solution. I will try to store in the SD card things that I can not in the flash storage. I will dive comment the results…

Thanks.

Good point @isaac. I will have a look. Thanks.

hi, yeah, we will wait for your comments.

Sorry for poor response. I am out of office for some time.
My experience was with OpernWRT not Yocto.

block-mount is simply a command that automatically configures fstab to mount specific blocks devices. Once you created the overlay, you need to automatically mount that overlay when the system loads. Block-mount simply creates auto-mount entries for every block it finds in the system. You then enable the overlay auto-mount. If block-mount does not exist then you can search what it does and create the entry manually.

I presume that yocto systemd still used fstab to automatically load block devices. You may need to check that otherwise there may be somewhere else you need to configure this mounting. I will try to replicate the auto-mount of the overlay when I get back to the office.

hi @Andermutu

Did you try out the suggestion of @lachlanp?

hi @jaski.tx

Sorry, but we ordered an iMX6ULL some days ago and the order was cancelled due to low iMX6ULL stock. As soon as I try the suggestion I’ll comment. However, I have to create manually what block-mount does because isn’t available in Toradex BSP… but I’ll try something.

hi, thanks for this Information. As lachlanp written, you can configure fstab manually and create a service which runs at startup.
Let us know, if this works for you.

The overall explanation of the overlayFS capability is here.

Referring to the manual for mount, the overlay mount command is:

$ mount -t overlay overlay -olowerdir=/,upperdir=/mnt/upper,workdir=mnt/work  /merged

There are many references for using overlayFs including this and this. :=

However, there is a yocto script for installing the overlay here. The recipe sets up a writable root file system overlay on top of a read-only root file system. It is installed using:
BBLAYERS: add /path to layers/meta-readonly-rootfs-overlay
IMAGE_INSTALL_append = “ initscripts-readonly-rootfs-overlay”
Create and install the image
After bootup, locate the script “init” in the root directory and change ROOT_RWDEVICE=”/dev/mmcblk0p1”
Reboot.
However, this does not work as follows:

root@colibri-imx6ull:~# df -h
Filesystem                Size      Used Available Use% Mounted on
ubi0:rootfs             435.0M    150.7M    284.3M  35% /

# opkg install git mosquitto mosquitto-clients ffmpeg nodejs nodejs-npm
Filesystem                Size      Used Available Use% Mounted on
ubi0:rootfs             435.0M    227.6M    207.4M  52% /

Note that the rootfs is still only 435 MB and the /dev/mmcblk0p1 is unused.

To identify the error, I try to use the script manually as follows:
I use a fresh image with filesystem extract as shown:

root@colibri-imx6ull:~# df
Filesystem           1K-blocks      Used Available Use% Mounted on
ubi0:rootfs             445440     89364    356076  20% /
/dev/mmcblk0p1        29766716     44988  28186600   0% /media/mmcblk0p1

root@colibri-imx6ull:~# ls /media
mmcblk0p1
root@colibri-imx6ull:~# ls /mnt
root@colibri-imx6ull:~#
root@colibri-imx6ull:~# ls /
bin    boot   dev    etc    home   lib    media  mnt    proc   run    sbin   sys    tmp    usr    var

####make directories and mount root filesystem to new mount point####

$ mkdir -p /media/ro /media/rw
$ mount -o bind / /media/ro 
root@colibri-imx6ull:/# ls /media/ro
bin    boot   dev    etc    home   lib    media  mnt    proc   run    sbin   sys    tmp    usr    var

####mount the read-write filesystem####

$ mount -o rw,noatime,mode=755 /dev/mmcblk0p1 /media/rw

New filesystem extract as follows:

root@colibri-imx6ull:/# df -h
Filesystem                Size      Used Available Use% Mounted on
ubi0:rootfs             435.0M     80.0M    355.0M  18% /
/dev/mmcblk0p1           28.4G     43.9M     26.9G   0% /media/mmcblk0p1
ubi0:rootfs             435.0M     80.0M    355.0M  18% /media/ro
/dev/mmcblk0p1           28.4G     43.9M     26.9G   0% /media/rw
/dev/mmcblk0p1           28.4G     43.9M     26.9G   0% /media/ro/media/rw
root@colibri-imx6ull:/#

create overlay file systems

$ mkdir -p /media/rw/upperdir /media/rw/work
root@colibri-imx6ull:/# ls /media/rw
upperdir  work

####mount the overlay filesystem ####

$ mount -t overlay overlay -o lowerdir=/media/ro,upperdir=/media/rw/upperdir,workdir=/media/rw/work /mnt

The new filsystem looks like this:

root@colibri-imx6ull:/# df -h
Filesystem                Size      Used Available Use% Mounted on
ubi0:rootfs             435.0M     80.0M    355.0M  18% /
/dev/mmcblk0p1           28.4G     43.9M     26.9G   0% /media/mmcblk0p1
ubi0:rootfs             435.0M     80.0M    355.0M  18% /media/ro
/dev/mmcblk0p1           28.4G     43.9M     26.9G   0% /media/rw
/dev/mmcblk#0p1           28.4G     43.9M     26.9G   0% /media/ro/media/rw
overlay                  28.4G     43.9M     26.9G   0% /mnt
overlay                  28.4G     43.9M     26.9G   0% /media/ro/mnt

root@colibri-imx6ull:/# ls /mnt
bin    boot   dev    etc    home   lib    media  mnt    proc   run    sbin   sys    tmp    usr    var
root@colibri-imx6ull:/# ls /media/rw
upperdir  work
root@colibri-imx6ull:/# ls /mnt/media/rw
root@colibri-imx6ull:/#
root@colibri-imx6ull:/# ls /mnt/media
mmcblk0p1  ro         rw

Move ro and rw root file system into the overlay file system####

root@colibri-imx6ull:/# mount -n --move /media/ro /mnt/media/ro

This gives the follwing error:

mount: /mnt/media/ro: bad option; moving a mount residing under a shared mount is unsupported.

The above error stops going any further.

Remaining commands:

$ mount -n --move /media/rw /mnt/media/rw
$ mount -n --move /proc /mnt/proc
$ mount -n --move /sys /mnt/sys
$ mount -n --move /dev /mnt/dev
$ cd /mnt
# switch to actual init in the overlay root file system
$ exec chroot /mnt /sbin/init

I don’t know how to proceed. If you are successful, then let me know.

@lachlanp: Thanks for the feedback.
@Andermutu: Is this issue still important?

Hi, it isn’t important at the moment. You can close it if you want.

Ok, I will close it. Feel free to ask, if it is needed once. Best regards, Jaski