Is there a way to set the boot partition (/dev/mmcblk0boot0) to read-write from userspace? I tried to set force_ro to 0 in /sys but was refused even when prefacing the echo command with sudo.
Hi, I’m the Toradex AI Assistant.
I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.
Did you like my answer? 
Setting Boot Partition to Read-Write Mode
Yes, you can set the boot partition to read-write mode from userspace(1). The correct approach is to disable the read-only protection using the force_ro sysfs interface.
Standard Method
For i.MX6 based modules, use the following commands to make the boot partition writable(1):
root@colibri-imx6:~# echo 0 > /sys/block/mmcblk0boot0/force_ro
After writing to the boot partition, you should re-enable the read-only protection(1):
root@colibri-imx6:~# echo 1 > /sys/block/mmcblk0boot0/force_ro
Important Notes
- By default, eMMC boot partitions are read-only and disabling via
force_rois only temporary and does not persist(1) - The change takes effect immediately and does not require any power-cycle(1)
Alternative Method for Newer Systems
If you’re using newer BSPs where the sysfs interface is no longer available, you can use the mmc-utils package instead(1). You’ll need to install mmc-utils first(2):
mmc bootpart enable <1 or 2> 1 /dev/mmcblk2
Troubleshooting
If you’re still getting permission denied errors even with sudo, ensure that:
- You’re running as root (not just using sudo)
- The filesystem is mounted read-write
- Your kernel supports the sysfs interface for boot partition control
The syntax is compatible between the sysfs method and the U-Boot mmc command(1).
Best regards, Toradex AI Assistant.
In our Linux images, the /dev/mmcblk0p1 partition is mounted as read-write by default. You can freely add device tree overlays there or modify the overlays.txt file from user space.
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,gid=6,fmask=0007,dmask=0007,allow_utime=0020,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
Thanks Alex but your solution won’t do. I need to be able to write to mmcblk0boot0 because I need to update u-boot in the field. Remotely. The solution suggested by the AI Assistant above is workable but I have the root user disabled in my image and it won’t work (as noted by the agent) from another sudoer.
However, the automated script that would runs my remote update runs as root I believe so that might be able to change force_ro directly …
It’s obviously possible because TEZI does it and I have another solution that involves using TEZI but it is cumbersome and has additional fail points.
The mmcblk0boot0 is a raw partition and does not contain a filesystem. Yes, it is write-protected, and the only way I know to make it writable is by writing 0 to /sys/block/mmcblk0boot0/force_ro using root credentials. If the root user is disabled, you can temporarily enable it. The Toradex Easy Installer does not have this issue, since the root user is not disabled there.
Precisely correct. I understand it is a raw partition and contains the raw, binary, u-boot executable. I want to write this raw partition with a new, raw, binary, uboot executable (using dd), generated by the bitbake process, from userspace. More precisely, from a Mender Update Module. Now here is the reason I would want to do such a mad thing:
I have hundreds of devices in the field running an image built against Dunfell (Toradex BSP 5). I want to update all those devices to a new image built against Kirkstone (Toradex BSP 6). Only problem with that is, that the Dunfell based u-boot image residing in mmcblk0boot0 will not boot the Kirkstone image. It tries to load the devicetree binary and silently locks up. However, if I flash the device with the same Kirkstone build using TEZI, which writes the new Kirkstone-based u-boot to mmcblk0boot0 it boots fine.
Regardless of what causes this issue, I have to come up with a way to remotely update the Dunfell-based u-boot executable residing on mmcblk0boot0, using Mender, with a new Kirkstone-based u-boot. One alternative is to create a bootable TEZI image, suitable for writing to the spare 32G sdcard I have in MMC1 which would contain an autoloading, TEZI repo directory containing this new Kirkstone-based image (u-boot, rootfs, whole shooting match - standard TEZI image). That image would have one minor patch to the u-boot environment:
boot_targets=”mmc0, mmc1, dhcp”
as opposed to the factory default of:
boot_targets=”mmc1, mmc0,dhcp”
Once this sdcard image is written to the mmcblk1p1 on this spare sdcard, and the device reboots, TEZI runs (because of the default boot order), finds the autoloading image on it local storage, flashes mmc0 (including mmcblk0boot0) and reboots again.
Now, the new Kirkstone-based u-boot image boots off mmc0 instead of mmc1 (because of patched boot order) and as a result, the new Kirkstone-based kernel loads, the Kirkstone-based rootfs gets mounted and everybody is happy. If this becomes an issue in the future, say between Kirkstone and Scarthgap, manipulating the TEZI image and the boot order can be used in the same way.
On inspection, this is a full-blown, Larry Lightbulb solution. However, it works and has been tested, with the minor exception of the Mender Update module to write the TEZI image to mmcblk1p1 (which is fairly trivial). In fact as I started writing that module it occurred to me to just write the Kirkstone-based u-boot image directly to mmcblk0boot0 directly and bag TEZI on mmc1 all together. No boot-order patch, no extra steps, nothing. That would simplify things tremendously and send Larry Lightbulb back to the cash register at Radio Shack where he belongs.
However, I wanted to verify that I could write the new u-boot image to mmcblk0boot0 from a bash shell first which is where I ran into the write protection problem on that partition. Hence my original question. Maybe it is not an issue though as the Mender Client (which runs the update modules) runs as root. So maybe it can change force_ro property on mmcblk0boot0 to 0 even though the root user is not enabled. I would suspect that to be the case and I will test that theory today.
Whew! That was exhausting. Long winded I know, but couldn’t figure out how to convey the question more precisely without explaining the whole thing …
1 Like
Thank you for the detailed explanation. Your solution should work if the root user is enabled. Unfortunately, I have no idea how to make mmcblk0boot0 writable without root privileges. You can also configure U-Boot to update itself using U-Boot commands and scripts, which can be modified from Linux user space with fw-utils. However, these utilities also require root privileges.