>But .... shouldn't have "mmcblk1boot0" and "mmcblk1boot1" have shown up as options,
SD cards DON'T have a *blk?boot? section (it is not a partition)
This is due to the controller on emmc drives, boot0 and boot1 (and rpmb) are
sepearate sections (on the same nand), only 4 mB (and 12mB for rpmb)
This is convenient to know which is emmc and which is SD if they are same size
What's the difference between writing to the eMMC module or SD with "flasher" or "etcher" software , vs. writing to the device with dd of=/dev/rld0 or of=/dev/mmcblk2 ?
I have this idea that the OS knows how to flash and etch these devices, and we might be able to treat them like any random access block device, and in fact it appears that people out there are doing exactly that. Possibly the flasher result would be significantly more compact or something?
Conversely, I'd like to be able to copy raw eMMC to SD - for example, boot from a 128Gb SD and dd and compress the 64Gb eMMC. That could then be reinstalled to recover to that state at the time of the copy.
Thanks for any insight into this.
11-20-2023, 06:22 PM
(This post was last modified: 11-20-2023, 06:29 PM by wdt.)
The only difference, etcher checks that the write was correct, this is nearly always redundent
(and does make it less likely that you will make a.... of=wrong.... mistake,, be careful, use lsblk)
About a year ago,, cd to wherever you want the backup to be, maybe a usb stick?
dd if=/dev/emmc bs=1M |gzip > emmc.backup (replace /dev/emmc with correct mmcblkX, maybe bs=4M might be a little smaller)
-----
Do not do this from a booted system, you want /dev, /proc, /run to be empty,,,, ie from a SD or usb boot
