A eMMC partitions convention

According to the JEDEC standard, the whole eMMC storage medium can be broken by manufacturer into several independent banks (partitions). Typically, there are two Boot Area partitions and the User Data Area partition, at least.

In BBB, the boot ROM code never switches to Boot Area partitions. Instead, it reads only from the User Data Area partition assuming everything is resided there. But later it’s possible to access every partition programmatically. Actually, in BBB the Boot Area partitions provides a megabytes of high quality non-volatile memory with nice protection features. So the temptation is to use that memory in a projects.

But I have a naive question. It’s OSS, where nothing is documented and everything is constantly changing. How I can be sure the platform maintainers will not start using that partitions for their own needs in a future releases (e.g. to simplify accommodation of new AM62x devices in the code)?

Hi @inu , the “AM335x” boot rom doesn’t know how to use boot0, feel free to use this extra MB of space for your own use…

On the TDA4 (beaglebone ai-64) boot0 is used for storage of the initial bootrom to load u-boot onto the R5…


Hi Robert,

That’s exactly the point. You’ve to deal with increasing number of different SoCs. Some of them boots from the user partition, some from the boot partition and some can be configured to use either, I presume.

So the obvious approach to simplify the things would be to identify in the code a common part and a SoC-dependent parts. With the intention to keep the SoC-dependent parts as small as possible, perhaps at the expense of introduction of some redundancy in the common part.

Now imagine the situation in one future day I’ve updated my BBB board with new platform SW image and all my application data (calibration, settings, keys, whatever) in the boot partition are ruined by the image. Not because it was necessary to update the boot partition but because of your optimization efforts. From your side, it’ll be fine. The functionality is not harmed as this SoC does not use the boot partition and no one ever promised to keep the boot partitions intact. So no problem. That’s the risk I’m seeing.

I see your point.

In the last 8 years on the AM335x, we’ve never specified a usage for it.

While it would be cool to use, the 1 MB in size is actually too small for MLO/u-boot-dtb.img now days…

It was either 5 or 6 years ago, we had the pain of moving from a 1MB → 4MB hole at the start of the partition for MLO/u-boot-dtb.img…