With this new rule, only the medias that contain a filesystem
on them are mounted, filtering several calls to mount.sh.
I have checked that this change doesn't increase the boot time
at all.
https://onedigi.atlassian.net/browse/DEL-8826
Signed-off-by: Francisco Gil <francisco.gilmartinez@digi.com>
The nodes "/dev/ramX" and "/dev/loopX" are mounted on boot.
Each node calls the mount.sh script, but they are not mounted
because these nodes are blacklisted in the "blacklist.conf" file.
In the ccmp13 adding this modification in the rule saves
around 4 seconds per boot.
In the ccmp15 and ccimx6ul around 2 seconds are saved.
https://onedigi.atlassian.net/browse/DEL-8725
Signed-off-by: Francisco Gil <francisco.gilmartinez@digi.com>
The ccmp1 has two MTD partitions (UBI, UBI_2) with different system
volumes.
Previously, the fact of having two ubi devices was taken as proof of
being on a multi-MTD system (one that has one UBI volume per partition).
Instead, this commit reformulates the condition to having a partition of
the same name than the UBI volume.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
This commit fixes the issue in Jira
https://onedigi.atlassian.net/browse/DEL-7827 (and in GitHub
91bfa01a52#),
that is being manifest again in a CC6UL with 1GB although it may affect other
hardware.
Partitions are mounted:
* For multi-MTD systems, when an MTD subsystem event is received.
* For single-MTD systems, when a UBI subsystem event is received.
This commit avoids process UBI subsystem events in multi-MTD systems.
The automount rules filter UBI subsystem events to only process 'ubi0*' (the
only UBI device/volumes in a single-MTD) and then the executed script
'mount_digiparts.sh' checks for the existance of '/dev/ubi1' node to consider
the system multi-MTD instead of using 'singlemtdsys' U-Boot variable that only
exists on CC6UL.
Signed-off-by: Tatiana Leon <Tatiana.Leon@digi.com>
These folders /mnt/linux, /mnt/update and /mnt/data are
created by the automount_block.sh script. In a read only
system, these folders are not created raising some errors.
Creating these folders solves the issue.
Signed-off-by: Francisco Gil <francisco.gilmartinez@digi.com>
Traditionally, platforms based on NAND, used one UBI volume
per MTD partition.
Now it's possible to use only one MTD partition containing many
UBI volumes.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://onedigi.atlassian.net/browse/DEL-7614
The current scripts used the standard mount binary at /bin/mount
for mounting the partitions. Systemd however seems to have a monitor
that eventually umounts such partitions if not mounted by systemd's
specific command 'systemd-mount`.
For platforms using systemd, we need to use this binary together with
parameter --no-block so that partitions are mounted correctly during
the boot process.
This commit merges the two scripts for Digi-handled partitions into
just one:
mount_bootparts.sh
\
+--> mount_digiparts.sh
/
mount_partition.sh
The merged script:
- checks if running with systemd, to use its binary.
- checks if running with busybox, to not use the unsupported '-o'
attribute.
- checks if mounting the 'linux' partition, to mount it read-only.
- checks for already-attached UBI devices, to avoid re-attaching.
This commit also combines the Digi-handled partitions (linux, update)
into the same udev rule, to simplify it, and breaks the rules lines
for readability.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-6744
The boot partions name has been changed in u-boot, so change it also
here to match current u-boot.
https://jira.digi.com/browse/DEL-949
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
These files were needed in previous versions of Yocto to overcome
different problems. Remove them as the default ones in current Yocto
version are good enough for our platforms.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
So the IMX udev rules can be used without meta-digi-dey layer. For
example when building core-image-minimal with poky distro.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>