Basically all it does is doing a checksumming of the RAW bytes found on /dev/sdb up to the exact count of bytes sdcard.img contains.

Here are my questions.
- When resetting USB power and doing a new rpiboot, the checksum are different, despite the partitions being correct. I suppose this is some kind of wear leveling/TRIM/block redordering done by the eMMC? Would there be a way to circumvent this? Basically be able to checksum the flash even after a power off? TL;DR How can we checksum N bytes on the eMMC consistently?

- When using dd, the checksum is often wrong (after writing with fsync) even though power wasn't turned off. On the other hand, when using something like usb-creator-gtk (on Ubuntu), the checksum is systematically correct. Checking their source code, it seems the latter software relies on udisks. I wonder if anybody has an idea on why it doesn't work correctly with dd, but does with Canonical's usb-creator-gtk.

I think it's likely that Linux is opening the partitions while you are checksumming. It will then write to the partitions... How about you read the partitions back using dd afterwards and see where the differences are?

How about using a 3rd party software? We are using Etcher (https://www.balena.io/etcher/) that software has a check built in and has support for compute modules. It even supports writing one image to multiple devices simultaneously.

I think it's likely that Linux is opening the partitions while you are checksumming. It will then write to the partitions... How about you read the partitions back using dd afterwards and see where the differences are?

Gordon

Hi Gordon, it indeed was that. Damn! I was starting to think it was a problem with my flashing PCB.

More specifically it was udisks2 service automounting the partitions. Disabling completely the service fixed once and for all my issues. I wasn't too aware mounting (non read-only) actually changed the checksums of a partition! I always thought mounting was "harmless" (in a I/O sense) until you actually wrote to the partition. Is it journaling stuff or something (considering the image contains ext4 partitions)?

On another note since I have your attention. I wonder if it's possible to flash the CM3 with USB3 speed capabilities? Would be useful for us given the shear volume of CM3s that goes outside the factory.

How about using a 3rd party software? We are using Etcher (https://www.balena.io/etcher/) that software has a check built in and has support for compute modules. It even supports writing one image to multiple devices simultaneously.

No it's not an option sadly. Altough I didn't know the software (seems well done indeed, and I might actually start copying some stuff from their UI), we can't simply because the PCB also does voltage examinations on our mainboard, some diagnosis of GPIOs, power tests, even digital HDMI screen testing (using a FPGA). Those are quality control tests that are integrated and done in the flashing software, while flashing (to make speed OK).

On another note since I have your attention. I wonder if it's possible to flash the CM3 with USB3 speed capabilities? Would be useful for us given the shear volume of CM3s that goes outside the factory.

If speed is a concern, you can also consider running a script on the CM to let it do its own flashing and verification.
Allows streaming a compressed image, needing less bandwidth.