Erase eMMC and start over? Or boot from SD Card?

Hello. I have a working OS installed on my eMMC. I am trying to erase it, and start over so I can boot from the SD card again.

If I remove the eMMC module the board won’t boot at all.

I can’t seem to get it to boot from the SD card… if I could do that I could “dd” the eMMC again.

I think I remember changing some option to force the eMMC as the main boot device but I can’t remember what I did.

Are you using a 4K display by chance? Currently there’s a bug in our u-boot that crashes with 4K displays. It’s in the process of getting fixed.

ROC-RK3328-CC
32gb eMMC

I am using a 1080p monitor but mostly I don’t use a monitor.
I am running Debian 11 bullseye, booting from the eMMC module.
This works great. Much better than the SD card!

I would like to change the role of the computer and install a different OS.

I can’t boot from SD card… How do I delete the eMMC, erase Debian 11, and boot from the SD card so I can start over and install a new OS on the eMMC?

Are you sure you’re flashing the right image correctly on the MicroSD card? Without the eMMC module, it will boot the MicroSD card. To delete the eMMC bootloader, simply run:

sudo dd if=/dev/zero of=/dev/mmcblk0 bs=512 skip=1 count=2047

I was doing it wrong. Thanks for the help!

I fixed the SD card and I can now boot from the SD card but if I have the eMMC connected it automatically boots from the eMMC card, not the SD card. Is there a way to swap the boot order? Or do I need to hot plug the eMMC after booting from the SD card?

Boards have a fixed search order for the bootloader. Once it has found the bootloader on the eMMC, it will boot from it. You can set the operating system boot order via creating a boot.ini file with the necessary boot_targets order saved on the device that the board is booting from.

boot_targets=mmc1 mmc0

This is what worked for me:
I had to use terminal or command line for this.
Open a terminal and change directory to boot/efi.
“cd /boot/efi”
Start nano as admin to create the file.
“sudo nano boot.ini”
add your boot targets.
“boot_targets=mmc1 mmc0”
Save the file, exit nano, and reboot.

The file needs to be on the first FAT/EFI partition. So mounting points may vary but it’s generally /boot/efi.

I corrected “etc” to “efi”. I left that post for anyone that might read it later, it might help them figure it out. Thank you for the correction!

echo "boot_targets=usb mmc1 mmc0" > /boot/efi/boot.ini

Until it is included in every image, must need to be done after every image writing.

Does this apply for Alta board?
I tried it, but seems isn’t has any affect.

It applies for all of our products. If it does not detect a bootable OS, then it skips to the next one.

1 Like

I just tried adding a boot.ini file to my Alta board.
I used echo “boot_targets=mmc1 mmc0” > /boot/efi/boot.ini. My dir now shows “boot.ini EFI ubootefi.var” in the /boot/efi partition.
When I try the Alta with both an SD and eMMC, I get “device /dev/mmcblk1p2 already registered with higher generation, found 333 expect 4684”. This is similar to the error that we got previously, without the new redirected boot.
Any ideas?

By the way, I started with a “sweet potato” and progressed to “Alta” because of speed. Looks like the Alta is going to be plenty fast enough for my needs.

1 Like

That means you have the same image on two different disks. The disk UUID is the same and btrfs is not designed to support two different partitions with the same UUID. You have to change the internal UUID on one of the partitions and update any associated boot information using update-grub on that image.

Looks like you’re right about the duplicate UUID’s = I used dd initially to write your debian-12-gnome-arm64+arm64.img onto my SD card and then, after Debian was up on the SD card, I used dd again to transfer the same debian-12… source image onto my eMMC card.

Looks like there are actually five UUID’s associated with my eMMC -

  • For the boot partition there are two = /dev/mmcblk0p1: SEC_TYPE=“msdos” LABEL_FATBOOT=“boot” LABEL=“boot” UUID=“537D-C620” BLOCK_SIZE=“512” TYPE=“vfat” PARTUUID=“45749835-01”

  • For the btrfs (OS) partition, there are three = /dev/mmcblk0p2: LABEL=“root” UUID=“a9812dd2-63a9-4fdc-b0e7-8b3e6353ab18” UUID_SUB=“494b5053-7a96-4e19-9a5f-286ac01d0117” BLOCK_SIZE=“4096” TYPE=“btrfs” PARTUUID=“45749835-02”

From your comments, I believe you are recommending that I change the PARTUUID for the btrfs partition PARTUUID=“45749835-02”?? Just wanted to double check with you before proceeding.

Thanks very much for your help,
Jim

I checked the UUIDs for the SD on my linux desktop = the UUID & UUID_SUB were identical to the ones for the eMMC sent to you yesterday).

I then used btrfstune to update the btrfs partition UUID on the SD image (it changed only root & left the same UUID_SUB as before).

After installing in SD back in the ALTA, things improved drastically = it boots up on the eMMC board without any error + I can now see mmcblk1, partitioned correctly, using gparted.

boot.ini file is still in /boot/efi of the ALTA eMMC, but it does not divert the boot from the eMMC to the SD.

Any ideas??

Thanks again for your help,
Jim

When you are in u-boot, run env print and check the boot_targets variable. That variable controls the search path. See if boot.ini on the eMMC properly applied to the boot environment.

It’s showing
boot_targets=mmc1 mmc0

Noticed earlier on gparted that the boot sector for the SD is not loaded whereas the boot sector for the eMMC is loaded. Did not reassign a new UUID for partition on the SD; so, it still duplicates the UUID number of boot on the eMMC
??

/dev/mmcblk0p1: SEC_TYPE=“msdos” LABEL_FATBOOT=“boot” LABEL=“boot” UUID=“537D-C620” BLOCK_SIZE=“512” TYPE=“vfat” PARTUUID=“45749835-01”

/dev/mmcblk1p1: SEC_TYPE=“msdos” LABEL_FATBOOT=“boot” LABEL=“boot” UUID=“537D-C620” BLOCK_SIZE=“512” TYPE=“vfat” PARTUUID=“357bbc6a-01”

Note also that (gparted) partition 1 on the eMMC is showing a mount point = /boot/efi and part 1 on SD is not showing a mount point + there’s a symbol indicating that gparted has a problem reading partition 1 on the SD

Thoughts??

Thanks,
Jim