Glowforge released firmware version 1.3.3-16 on March 9, 2017 for their Pro and Basic model CNC lasers.
You can see a full list of the changed files here.
This build includes a new kernel binary (same version kernel, just a new compilation), and a change in the way the eMMC data partition is formatted on new and troubled systems.
The change is located in /etc/init.d/data-partition:
--- a/etc/init.d/data-partition 2018-02-20 16:08:35.000000000 -0500
+++ b/etc/init.d/data-partition 2018-03-09 15:37:01.000000000 -0500
@@ -33,7 +33,7 @@
if ! mount -o sync -t ext4 $PARTITION $MOUNT_POINT
then
- mkfs.ext4 $PARTITION
+ mkfs.ext4 -E nodiscard $PARTITION
mount -o sync -t ext4 $PARTITION $MOUNT_POINT
fi
This is part of the bootscript that mounts the writable /data partition on the flash storage. This is executed if the partition fails to mount. The default discard option may take a long time if the flash device has a significant amount of data on it, so this would speed the formatting process up. This does come with a performance hit, but I think it is probably negligible given that the data partition is primarily used to store log files.
There’s a thread here that discusses this issue at greater length.
I am wondering how they protect against power off during writes to the flash?
I think you can get corruption of even read only partitions on the same device because of wear levelling at the hardware block level not knowing about partition boundaries. For example consider a device with a large read only partition and a small read write one. The read write partition would soon wear out its blocks unless they were periodically swapped out with the blocks holding the data that is only read. Unless that can be done atomically a power fail during the swap could potential corrupt the read only section.
Seems like a general issue with writeable file systems on flash. Embedded systems I worked on didn’t write to sd cards except during updates but my knowledges is now six years out of date, which is an age in technology.
I don’t believe they do. Without battery backup to the storage device, I am not sure that it is possible.
It seems the most common practice is to expect that it will occur and prepare for it. This white paper has some good insight.
On the Glowforge, they boot from an eMMC device. These have 2 boot partitions that are protected at the hardware level. This would at least allow the device to self recover.
However, Glowforge isn’t using them in a manner that would facilitate that. Under normal operation, they actually boot from the main partition, not the boot partitions. The only time they use a boot partition is when the watchdog is tripped or the button is held during power up. And then, the recovery mode doesn’t do anything but upload logs to Glowforge (assuming it has a network connection at that time).
A more robust method (partially covered in the link above) would be to have U-Boot (the boot loader) check status registered to see if the system is booting normally. That register is set to a temporary value by U-Boot. Once the system boots, the OS reset that register to indicate a proper boot. The Glowforge already does this part.
On a failed boot, U-Boot would recognize that the register hadn’t been reset, and would boot to the secondary boot partition which contains a proper recovery image. That image could download a new firmware image and restore the system.
As it stands now, I haven’t found any built in method for the Glowforge to recover itself from a corrupted firmware image. The best it can do is phone home about it, but it would still require (at this time) a complete replacement of the unit.
Are these all partitions on the same device?
My point is I think flash devices don’t know about partitions, they work at the block level, so if any partition is being written to any block on the same device could be corrupted by an interrupted wear levelling operation.
So you need a separate device with no writeable partitions to boot from. Even then I am not sure if reads eventually cause wear levelling moves. I don’t think reads cause physical wearing like writes but they do eventually cause the data to be lost. Before that happens the device re-writes the data. Those writes eventually lead to wear and wear levelling. Probably not an issue if the device is only used during boot.
eMMC was designed with mobile devices in mind. The ‘boot’ partitions are separate from the ‘user’ data area:
(
Source)
1 Like
