Going through the same thing with Yocto-based images because Yocto also doesn’t include the beagle-flasher that I’ve seen. Debian usually included this by default when getting it from here on beagleboard.org. I noticed this deviation when I went custom embedded Linux and appreciated the built-in functionality.
I’d say if you do go down the route of diskdump (dd) to /dev/mmcblk, be careful to not corrupt the unit by stopping it short due to power issues. You should be able to rewrite another image should that happen.
One tool used and recommended by embedded Linux tutorials, Yocto, etc is a Linux tool called bmaptool. Compared to dd, it has verification capabilities as well as faster image writing speeds. I like the validation capabilities it provides because this is critical for embedded system designs. Robustness and ease helps embedded system engineers sleep at night.
An example command would be:
sudo bmaptool copy sdcard.img /dev/sdX
By booting into the manual SD boot button on the board, then running bmaptool to /dev/mmcblk1 (or whatever your eMMC part is), your eMMC image will be overwritten with your custom buildroot image. You’d have to do this for every image write on buildroot image upgrades unless you make a custom script, possibly even an initramfs entry script but that would be more advanced and possibly unnecessary for personal projects.
One current embedded system design implementation out there is the use of upgrade engines such as RAUC, Mender, even SWUpdate. RAUC is supported by buildroot at the time of this response. If you want to make your life easier with image upgrades on a custom designed OS, I’d look at that: Integration — RAUC 1.15.1 documentation
Lastly, if I were you, I’d just make a bash script with the bmaptool commands, outputs, and recovery logic by rewriting the prior image back. You’d basically be standardizing the commands you already were entering in, such as the dd/bmaptool commands. You’d just have to make sure it’s tested and stable which is a useful skill to learn with embedded engineering. Testing would be making sure you get the same results each time, and the system can smoothly apply image changes with helpful outputs.
Pro-tip: Definitely make sure you’re writing to the right device and partition, so you don’t have to reinstall the sdimg to the SD Card. Bmaptool is more robust for that, but it’s better to build that best practice up.
I understand if this is a lot of info, let me know if there’s further questions or clarification and I’ll do my best to help!
Comparison of the image writing tools: Skip flashing unused blocks with UUU | Marcus Folkesson Blog
More info on bmaptool: Using the bmaptool to record disk images safely and quickly | by Domarys Correa | O.S. Systems | Medium