RB1: Partition table update as well as some cleanup

[b49020]

This PR intends to update RB1 partition layout such that it is compatible with future edk2/UEFI support as well as optimising for size to drop redundant partitions and reducing size for boot partition.

[lool]

Thanks for progressing this @b49020!

Each commit makes sense to me; NB: I haven't tested the updated partitions.

I wonder how we should convey the assumptions and requirements for people consuming these files.

We have an effort in progress to build a companion site to convey the role of each repo under qualcomm-linux and how they work together (perhaps also repositories outside of qualcomm-linux org), but I believe we still want each repo to carry its own documentation when relevant.

If I was trying to convey this in, say, a markdown doc along with qcom-ptool, I'd share my basic understanding of what we're trying to do here and the state of things as follows (this is a bit of a brain dump):

- this repository contains tooling and reference partition layouts for modern Linux based boot architectures for RBx boards
- Qualcomm currently supports two reference Linux based OSes (Yocto with meta-qcom and Debian with qcom-deb-images) to be used with this
- Qualcomm picked partition GUIDs, partition names, and partition size budgets in support of various boot flows

The supported boot flows are:
- "u-boot": PBL => XBL => ABL => U-Boot => high-level OS (Linux) for RB1
- (preferred) "uefi": PBL => XBL => UEFI => high-level OS (Linux) for all other RBx boards

On RB1, the partition layout should enable a future migration to an "uefi" boot flow at the time where UEFI firmware is available.

The currently supported features are:
- A/B boot
- secure boot for the UEFI boot flow
- capsule updates for the UEFI boot flow

The following partitions are used by the following layer for these purposes:
- xbl_a/xbl_b: used by PBL, image of the XBL loader
- xbl_config_a, xbl_config_b: used by XBl, store its config
- ...
- 

[loicpoulain]

LGTM, I guess we will do further cleanup once we know the role of each partition.

[b49020]

@lool

We have an effort in progress to build a companion site to convey the role of each repo under qualcomm-linux and how they work together (perhaps also repositories outside of qualcomm-linux org), but I believe we still want each repo to carry its own documentation when relevant.

Looks like a great idea to me. I will try to document bits along as per your suggestion however some comments on following bits:

The currently supported features are:

I am not sure if this repo is the right place to hold a list of features supported by the firmware as it can easily get out of sync. It's better to put them under overall Qcom Linux documentation specifically under board specific BSP documentation.

The following partitions are used by the following layer for these purposes:

This info makes sense for this repo however we are still collecting information about role of each partition. Once that's available we can document them as well as drop unneeded partitions.

[ndechesne]

thanks. I will wait for @lumag to approve the PR since there are open items to discuss.

@b49020 are you also looking at protecting/hiding the firmware partitions, so that they aren't easy to be overriden from a Linux OS?

[b49020]

@ndechesne

@b49020 are you also looking at protecting/hiding the firmware partitions, so that they aren't easy to be overriden from a Linux OS?

That would really be a nice feature but I am unsure if that's achievable on Qcom platforms since the firmware and the OS partitions co-exist in the main eMMC flash area. One idea could be to support a dedicated flash media for OS installation like SD card then we can restrict eMMC access to firmware only but that will just be a lot of flash space left wasted.

[b49020]

I suppose UFS allows for this kind of partitioning based of different LUNs.

[lool]

@ndechesne

@b49020 are you also looking at protecting/hiding the firmware partitions, so that they aren't easy to be overriden from a Linux OS?

That would really be a nice feature but I am unsure if that's achievable on Qcom platforms since the firmware and the OS partitions co-exist in the main eMMC flash area. One idea could be to support a dedicated flash media for OS installation like SD card then we can restrict eMMC access to firmware only but that will just be a lot of flash space left wasted.

What about eMMC boot partitions? Could we use these as is being done for the CDT?

[ndechesne]

What about eMMC boot partitions? Could we use these as is being done for the CDT?

Indeed. I had that in mind, or perhaps finding something with write protect. there are 2 'features' here. 1) hide the partitions which are not dedicated to the OS, 2) ensure that a user cannot 'easily' erase them.

[loicpoulain]

What about eMMC boot partitions? Could we use these as is being done for the CDT?

Indeed. I had that in mind, or perhaps finding something with write protect. there are 2 'features' here. 1) hide the partitions which are not dedicated to the OS, 2) ensure that a user cannot 'easily' erase them.

To leverage hw boot partition:

• Whatever we flash here should fit into the 2x4MB available (mmcboot0, mmcboot1)
• We probably have to modify the bootloader to look into boot0 and boot1 when looking for its firmware blob, I suspect it only browse the gpt in user partition at the moment? (@b49020)
• It would be good to keep the board-specific CDT isolated from platform-specific blobs/firmwares (devcfg, TZ...).

Note also that GPT has partition attribute flags, like Read-Only or Hidden, and actually all our partitions are marked read-only, however the Linux kernel does not seem to care about it...

[ricardosalveti]

What about eMMC boot partitions? Could we use these as is being done for the CDT?

This will force changing quite a few components, and size might still not be enough.

Following EBBR (https://github.com/ARM-software/ebbr/blob/main/source/chapter4-firmware-media.rst#gpt-partitioning) we can set them as 'required partition'. In the end they will be exposed, but as described in EBBR, ideally those wouldn't automatically be changed by generic linux installers (but would depend on the installer).

[b49020]

What about eMMC boot partitions? Could we use these as is being done for the CDT?

Although we should be able to change later boot-loader stages but the PBL code (ROM code on Qcom platforms) loads XBL-SC from the xbl_* partition. The ROM code is un-modifiable and if it doesn't support loading from an eMMC boot partition then we won't have any option then. I will double check though.

The second main issue will be the size constraint as below:

Whatever we flash here should fit into the 2x4MB available (mmcboot0, mmcboot1)

This will only be able to hold a single uefi_a partition (sz: 8MB) which really will be a blocker to use these partitions if we really want a dedicated storage option for the OS.

Another issue is that the firmware/boot-loader itself uses the same GPT partition layout to load firmware images which is being used by the OS as well. It's really a problem for distro installers as they can't create or alter the GPT partition layout to best suite their needs like dynamic size of ESP partition, rootfs or if user wants to create a separate userdata partition which might be encrypted as well.

[ndechesne]

Although we should be able to change later boot-loader stages but the PBL code (ROM code on Qcom platforms) loads XBL-SC from the xbl_* partition. The ROM code is un-modifiable and if it doesn't support loading from an eMMC boot partition then we won't have any option then. I will double check though.

PBL (like most boot components) will 'search' for partition by looking up GUID. I don't know if they search in user data only, or if they seach in the boot partitions too..

[b49020]

I hope I have addressed all the comments, feel free to review again.