This is a cache of https://discuss.96boards.org/t/contents-of-boot0-boot1-emmc-partitions/264. It is a snapshot of the page at 2024-11-01T02:58:21.817+0000.
Contents of boot0/boot1 eMMC partitions - DragonBoard410c - 96Boards Forum

Contents of boot0/boot1 eMMC partitions

Could anyone check contents of their boot0/boot1 eMMC partitions (i.e. /dev/mmcblk0boot0 and /dev/mmcblk0boot1)?

Are they empty or contain some code?

I’m trying to figure out what have happened to my board (it’s not able to boot from eMMC even after recovery procedure).

I suspect there was something flashed either on one of boot partitions or in rpmb that I’m not aware of (and is not inside recovery package).

1 Like

we’ve seen an issue (twice) where switching back and forth between Android and ubuntu would put the board in a non bootable state. and even the SD rescue or SD install would fix that. the ‘workaround’ for that issue is:

  1. cat /dev/zero > /dev/mmbclk0
  2. boot from SD rescue and reflash the bootloaders

We’ve not been able to debug the issue so far… our issue happened (twice) when trying to reflash Android while Linux was installed. So I don’t think this is same issue as yours, but clearly there is something in the GPT or the first eMMC blocks (where we are the proprietary blobs) that can prevent the board from booting… so in your u-boot development, you might have reproduced that somehow…

can you try to zero out the emmc as mentioned above.

and to answer your question: I don’t know why we have the boot0 and boot1, i will try to get that information.

Nope, manual flushing mmcblk0 didn’t help either.

But I managed to solve the problem;

The problem was in fact that I somehow switched boot partition on eMMC.

If I understand correctly, it is possible to tell eMMC which partition to use as “boot” - either one of boot partitions (/dev/mmcblk0boot0|1), or so called user area (/dev/mmcblk0).

On Dragonboard we seem not to use boot partitions as boot images take much more space than boot partitions (4MiB each)

With eMMC command it is possible to re-configure that (command is called PARTITION_CONFIG).

To switch my board to “working state” I had to enable CONFIG_SUPPORT_EMMC_BOOT in u-boot and then reconfigure partitions:
=> mmc partconf 0 0 7 0
Param explanation:
0 - device, SDC1
0 - boot_ack - disable boot acknowledge (default)
7 - boot_partition_enable - user area enabled for boot (not default - default is “device not boot enabled”)
0 - partition_access - no access to boot partition (default)

Probably it’s possible to do the same using Linux.

Just a reminder - boot0/boot1 have nothing to do with eMMC Linux partitions (i.e. ‘aboot’, ‘boot’, etc.) - they are handled by hardware.