What is purpose of /dev/mmcblk2boot devices?

[greenais]

Please give me a tip - what is purpose of /dev/mmcblk2boot block devices created?
Quite small size - 4MB - ones, do they serve to something u-boot needs at boot time?
There are no records for them in fstab so I assume they are created by zram, but what happens to them after boot when they aren't needed anymore?

 

Board Orangepi 3LTS with bookworm minimal
 

Also as a matter of wondering - why there are two zram devices: one of 1/2 of RAM (as usual) and another of quite small 50MB only, what is it for?

 

 

root@heaven:~# fdisk -l
<redacted>

Disk /dev/mmcblk2boot0: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mmcblk2boot1: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

<redacted>

Disk /dev/zram0: 987,53 MiB, 1035497472 bytes, 252807 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/zram1: 50 MiB, 52428800 bytes, 12800 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

 

[Werner]

 

18 minutes ago, greenais said:

/dev/mmcblk2boot

Good question. Have you tried to use binwalk oder strings on it?

 

18 minutes ago, greenais said:

e two zram devices:

One is for ramlog and should be mounted to /var/log. The other is zram which by default is half of your actual memory.

In the early days SBCs hat very limited memory, so using zram was a simple way to increase that by sacrificing some cpu resources. Nowadays SBCs come with a lot more memory and some may not even need zram anymore. Depending on your setup you can disable it as well. Check /etc/default/armbian-* files.

[greenais]

1 hour ago, Werner said:

One is for ramlog and should be mounted to /var/log. The other is zram which by default is half of your actual memory.

In fact in image's default fstab they aren't mounted so those probably could be assumed as a kind of waste of RAM this way? Or there is chance that they actually mounted somewhere else but fstab?
 

root@heaven:~# cat /etc/fstab
# <file system>                                 <mount point>   <type>  <options>                                      <dump>   <pass>
tmpfs                                           /tmp            tmpfs   defaults,nosuid                                00
UUID=fb077685-a428-49f2-b013-287dc5fc9672       /               ext4    defaults,noatime,commit=120,errors=remount-ro,x-gvfs-hide       0       1

 

Thank you for tip regarding /var/log, I was suspecting that it should be there as soon as device created.

 

 

1 hour ago, Werner said:

Have you tried to use binwalk oder strings on it?

Do you mean to inspect with binwalk/strngs those devices in hope to find out what is there? I'd gave a try - there is nothing:

root@heaven:~# binwalk /dev/mmcblk2boot0
DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
root@heaven:~# binwalk /dev/mmcblk2boot1
DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
root@heaven:~# strings /dev/mmcblk2boot0
root@heaven:~#

 

They also can't be mounted - dmesg excerpt:

[390869.014377] F2FS-fs (mmcblk2boot0): Magic Mismatch, valid(0xf2f52010) - read(0x0)
[390869.014508] F2FS-fs (mmcblk2boot0): Can't find valid F2FS filesystem in 1th superblock

Magic mismatch - mystic things unsolved)

[Werner]

2 minutes ago, greenais said:

In fact in image's default fstab they aren't mounted so those probably could be assumed as a kind of waste of RAM this way?

Have you checked "mount" command to list actualy mounts?  I am quite confident mount is happening by the ramlog service and is not integrated into fstab.

some more background: sdcards have a limited amount of writes until its cells die. Since everytime some service or whatever writes some logs this issues a write event. To drastically increase the lifespan of the microsd log entries are buffered to (compressed) memory and then recurringly written all at once.

[greenais]

9 minutes ago, Werner said:

I am quite confident mount is happening by the ramlog service and is not integrated into fstab.

 

You are completely right - at least 50MB one is there

/dev/zram1 on /var/log type ext4 (rw,nosuid,nodev,noexec,relatime,discard)

But big 987MB /dev/zram0 isn't at all - so it looks like it's useless and could be removed from zram config, right?

Both mystic /dev/mmcblk2bootX are still in question

[Werner]

2 hours ago, greenais said:

987MB

I explained above what zram is created for. OPi3LTS should have 2G  of memory, so having 1G of zram makes perfect sense here.

[greenais]

28 minutes ago, Werner said:

what zram is created for

Yes, but since this created device isn't mounted anywhere it makes no sense - no service or whatever could use it anyway, what definitely turns this creature into just waste of RAM for nothing, am I wrong?

[laibsch]

not everything is mounted, at least not in the way you expect it.

 

check "swapon -s"

[greenais]

19 minutes ago, laibsch said:

check "swapon -s"

Wow, I didn't know those command and mechanism even exist...  Thank you for your tip!
Any ideas regarding main (mmcblk2boot) topic question, perhaps?

[SteeMan]

I have only ever seen mmcblk?boot? Partitions on media that was setup for Android as the A/B is part of how Android installs updates and can fall back to the previous version.  I've never seen them on an Armbian created media.

[greenais]

I didn't mention, sorry, probably it matters somehow - my bookworm is already transferred to emmc, so system boots and runs from there, not from SD-card

[SteeMan]

59 minutes ago, greenais said:

already transferred to emmc

How was this transfered?

What was on the eMMC before the transfer?

Was the eMMC wiped before the transfer?

My guess is that your eMMC has Android loaded on it, you didn't wipe it and now you have partitions left over from the Android install.

[greenais]

16 minutes ago, SteeMan said:

How was this transfered?

What was on the eMMC before the transfer?

Was the eMMC wiped before the transfer?

Using included in image armbian-config script as many times for other boards before.
I have no idea what was there and I didn't care because
Script formats emmc before transfer (with "Warning! All data will be destroyed - proceed?")
So there is no chance to leave any trails of anything rested on emmc before

[cuker]

The mmcblkXbootX partitions are hardware defined partitions on eMMC storage device and can be used by 

storing boot firmware.

[greenais]

16 hours ago, cuker said:

hardware defined partitions on eMMC

Please elaborate what do you mean by "hardware defined".
Both obviously were created by armbian-config script after full emmc format during system transfer to emmc.
Questions remain the same: what for and where are they used?

Edited Tuesday at 07:07 AM by greenais

[devAtronia]

Quote

@greenaisPlease elaborate what do you mean by "hardware defined".

It seems that eMMC has built-in boot partitions. eMMC devices are not just "raw storage" (like SD-Cards) they have special reserved hardware partitions defined by the JEDEC eMMC standard.

These include:

• boot0 – a small partition (usually a few MB) reserved for bootloader code.
• boot1 – a second small boot partition, often used as a backup.
• RPMB (Replay Protected Memory Block) – a secure partition for keys and counters.

The SoC’s boot ROM (first-stage loader) can be configured to read directly from boot0 or boot1 when powering on. Also, these partitions are read-only to decrease the risk of having corrupted boot code.

Beware that they’re not used by the Linux filesystem unless explicitly written to (usually via dd when flashing U-Boot).

Edited Tuesday at 09:06 AM by devAtronia

[SteeMan]

4 hours ago, greenais said:

Both obviously were created by armbian-config script after full emmc format during system transfer to emmc.

No that is not true.  These are not from Armbian.  As I said earlier if your eMMC previously had Android (which defines and uses these special partitions) even after a normal Linux repartitioning these will still appear.

[MaxT]

These are not from Armbian. 

I wouldn't be so categorical - I have rock pi 4b, which never saw android or any os other than armbian, which has same thing- two boot devices on emmc. Since it doesn't bother me, I didn't investigate further.

[greenais]

For those who will bump here looking for an answer to the topic's question:

 

Quote

eMMC Boot0 refers to the first of two special, high-reliability hardware partitions on an eMMC flash storage device, which is specifically designed to store and execute the initial bootloader for an embedded system, such as the U-Boot firmware on Texas Instruments (TI) processors. Unlike the standard user partition, Boot0 and Boot1 are accessed through dedicated boot modes configured via hardware pins or software commands, enabling the device's ROM to load the bootloader from this protected area, allowing for a more robust boot process. 
 

 

Purpose and Function

 

Bootloader Storage:

The primary purpose of the Boot0 partition is to hold the initial bootloader (like U-Boot) that the system's hardware ROM will execute upon power-up. 

High Reliability:

Boot partitions (Boot0 and Boot1) are implemented with more reliable storage technology than the standard user area (User Data Area, or UDA). 

Boot Mode Configuration:

The system's boot mode is determined by hardware pins or software settings, which tell the ROM to look for bootable code in the Boot0 or Boot1 partition. 

Firmware Updates:

Flashing firmware to the Boot0 partition is a common step in preparing an eMMC for booting an embedded system, often done after booting the device from another media like an SD card. 

 

 

Key Characteristics

 

Hardware Partition:

Boot0 is a distinct, vendor-specific hardware partition that is separate from the standard user partition. 

Access via mmc Commands:

In environments like U-Boot, commands such as mmc dev 0 1 (for Boot0) or mmc dev 0 2 (for Boot1) are used to interact with these partitions. 

Configuration with Extended CSD:

To enable proper booting from Boot0, settings within the eMMC's Extended CSD register, such as BUS_WIDTH and PARTITION_CONFIG, must be configured. 

 

[MaxT]

an answer to the topic's question

Thanks, very helpful.

Maybe someone will be able to bring some light on how second partition could appear (uboot update script transition bug?), while being not a part of Armbian's functionality.