Skip to content

Add partition configurations for Nord RRD - #168

Open
Viswanath Kraleti (vkraleti) wants to merge 2 commits into
qualcomm-linux:mainfrom
vkraleti:nord-support
Open

Add partition configurations for Nord RRD#168
Viswanath Kraleti (vkraleti) wants to merge 2 commits into
qualcomm-linux:mainfrom
vkraleti:nord-support

Conversation

@vkraleti

Copy link
Copy Markdown
Collaborator

Adds the partition configurations and contents.xml.in for the Nord RRD board
to support downstream boot flow using QTEE, UEFI and systemd-boot and
open boot flow using TF-A, OP-TEE and U-Boot.

Additional files device_programmer_ddr.elf, oem_misc.mbn,
qti_misc.mbn, soccp.mbn and xbl_ramdump.elf are used by
Nord RRD. Add them to check-missing-files.

Signed-off-by: Viswanath Kraleti <viswanath.kraleti@oss.qualcomm.com>
Add initial partition.conf and contents.xml.in for Nord RRD board
to support the boot firmware stack using QTEE, UEFI and systemd-boot.

Signed-off-by: Viswanath Kraleti <viswanath.kraleti@oss.qualcomm.com>
@ricardosalveti

Copy link
Copy Markdown
Contributor

Can't we try to have a single partitioning scheme that would work for both boot firmware deployments?

@vkraleti

Copy link
Copy Markdown
Collaborator Author

Can't we try to have a single partitioning scheme that would work for both boot firmware deployments?

For open boot flow, bootloader team is proposing to use more generic uboot_spl, boot_fit, ubootenv partitions in place of uefi and tz. Gopinath Sekar (@g-sekar) aswinm94 anushka-qcom can provide more details on this.

@ricardosalveti

Copy link
Copy Markdown
Contributor

We have open boot firmware with lemans and we didn't really need a custom partition layout for it, the only partition that is not there is the one for ubootenv, but that is current being discussed at qualcomm-linux/meta-qcom#2808.

@g-sekar

Copy link
Copy Markdown

In Lemans we have reused
TZ partition for U-Boot SPL.
UEFI partition was used for FIT image (TF-A+OPTEE+U-Boot).
Since we have oppurtunity to define the partition table in Nord we wanted to name them in proper way.

--partition --lun=4 --name=aop_a --size=1024KB --type-guid=D69E90A5-4CAB-0071-F6DF-AB977F141A7F --filename=aop.mbn
--partition --lun=4 --name=aop_config_a --size=512KB --type-guid=3D12F234-C882-4B46-A20C-17D52C8FC03D --filename=aop_devcfg.mbn
--partition --lun=4 --name=apdp_a --size=64KB --type-guid=E6E98DA2-E22A-4D12-AB33-169E7DEAA507 --filename=zeros_1sector.bin
--partition --lun=4 --name=core_nhlos_a --size=122880KB --type-guid=6690B4CE-70E9-4817-B9F1-25D64D888357

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is core_nhlos?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

core_nhlos, along with the quantumfv, quantumsdk, and quantumcontentfv partitions, is part of the Quantum UEFI-stage PIL loading framework, used to load and validate subsystems independent of HLOS.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are they being left empty?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By default PIL are loaded by HLOS, these partitions exist to accommodate the special asks to support UEFI-stage PIL loading.

--partition --lun=4 --name=xbl_ramdump_b --size=2048KB --type-guid=FF608BF6-AEDF-4084-BEC5-C92AB4E4534D --filename=xbl_ramdump.elf

#These are non A/B partitions. In a A/B build these would not be updated via a OTA update
--partition --lun=4 --name=cateloader --size=2048KB --type-guid=AA9A5C4C-4F1F-7D3A-014A-22BD33BF7191

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is it?

@vkraleti Viswanath Kraleti (vkraleti) Sep 8, 2026

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This contains the UEFI TZT CATE (Common Automation & Test Environment) loader primarily used for TrustZone test automation.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it's for the test automation, why does it take space on all production devices?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Internal test automations are also reusing the same partition.xml produced by qcom-ptool. Should this be maintained separately?

@lumag

Copy link
Copy Markdown
Contributor

In Lemans we have reused TZ partition for U-Boot SPL. UEFI partition was used for FIT image (TF-A+OPTEE+U-Boot). Since we have oppurtunity to define the partition table in Nord we wanted to name them in proper way.

Proper way = compatible with the earlier platforms, unless you are required to break functionality.

@g-sekar

Gopinath Sekar (g-sekar) commented Sep 8, 2026

Copy link
Copy Markdown

Proper way = compatible with the earlier platforms, unless you are required to break functionality.

Legacy platforms followed the XBL → QTEE → EDK2 boot flow, whereas the current implementation adopts the open-source boot architecture of SPL → TF-A → OP-TEE → EDK2/U-Boot.

From a customer or ecosystem perspective, requiring users to flash SPL into the TZ partition does not seem logical. The partition layout should be defined based on the requirements of the open boot flow.

If there are differences between the open boot implementations on NORD and other chipsets, that is a valid topic for discussion. However, it is unclear why we need to preserve compatibility between the legacy boot flow and the new open boot flow when the partitioning scheme has already been redesigned to support the open-source architecture.

@lumag

Copy link
Copy Markdown
Contributor

Are we going to support QTEE in addition to TF-A/OP-TEE?

@vkraleti

Copy link
Copy Markdown
Collaborator Author

Are we going to support QTEE in addition to TF-A/OP-TEE?

Yes, Nord is expected to support three boot flows.

  1. U-Boot SPL → TF-A → OP-TEE → U-Boot
  2. U-Boot SPL → TF-A → OP-TEE → upstream EDK2
  3. XBL → QTEE → downstream EDK2(UEFI)

Proposal is to use one partitioning scheme for 1 & 2 boot flows. And a different one for 3.

@ricardosalveti

Copy link
Copy Markdown
Contributor

I still would like for us to come up with one single partition scheme here, that could cover the 3 scenarios. As I said, we are already handling this for lemans and other targets with one single partition table.

@vkraleti

Copy link
Copy Markdown
Collaborator Author

Dmitry Baryshkov (@lumag) Ricardo Salveti (@ricardosalveti) as #132 is bringing in open boot partitions, is it fine if I limit this PR only to downstream boot flow? This will help to kick start CI.

@SShirishQ

Copy link
Copy Markdown

Viswanath Kraleti (@vkraleti) lets not mix proprietary & open boot related requirement discussions, pls split this PR accordingly as discussed yesterday.

@b49020

Copy link
Copy Markdown
Member

Dmitry Baryshkov (Dmitry Baryshkov (@lumag)) Ricardo Salveti (Ricardo Salveti (@ricardosalveti)) as #132 is bringing in open boot partitions, is it fine if I limit this PR only to downstream boot flow? This will help to kick start CI.

#132 is meant to address downstream boot flow as well. Please feel free to test it and comment if we are missing something there.

@vkraleti

Copy link
Copy Markdown
Collaborator Author

Viswanath Kraleti (Viswanath Kraleti (@vkraleti)) lets not mix proprietary & open boot related requirement discussions, pls split this PR accordingly as discussed yesterday.

Dropped the commit that is bringing in open boot flow partitions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants