Hi
The ptool repo uses two patterns for distinct situations:
- multiple storage options: one subdir for each supported storage option, with NHLOS + HLOS bits going to the same storage; for instance platforms/iq-8275-evk/emmc or platforms/iq-8275-evk/ufs
- separate storage for NHLOS and HLOS: one subdir for each storage that has to be provisioned; for instance platforms/glymur-crd/nvme and platforms/glymur-crd/spinor
This doesn't allow conveying the supported configurations and requires hardcoding multiple calls to ptool scripts to generate the right data.
I also suspect it hurts contents.xml generation, as I believe Axiom's contents.xml support can convey multiple storage backends to flash.
Even on platforms with just UFS documented, there can be use of SPINOR storage for SAIL, as seen in platforms/qcs8300-ride-sx/ufs/contents.xml.in, albeit we don't seem to carry partition data for SAIL on SPINOR.
Lastly, there's the case for identical storage but two different usages: platforms/qrb2210-unoq has emmc-16GB and emmc-16GB-arduino targeting the same hardware, but with two sets of HLOS partitions.
How should we address this? Here are the options I have in mind:
- we could keep the platform subdirectories as use cases / scenarios, and move the NHLOS definitions underneath; this would keep the top-level structure the same, and only NHLOS would have to be special cased as a subdir; problem is that this could cause more duplication, for instance if we keep NHLOS partitions.conf for SPINOR copies under both ufs/ and emmc/ or similar
- or we could add a metadata file at the top of platforms//configurations.yaml that would summarize the supported configs and refer to files in subdirs
- like 2), but with contents.xml: I haven't researched this, but it's possible that contents.xml allow expressing this, so we could also switch to maintain contents.xml as our master for creating various partitions.conf
- like 1), but we extend the partitions.conf format instead to allow a single file to convey all target storage
I'd be happy to propose a PR, but would like if other maintainers weigh in on the target layout – perhaps others have nicer ideas on how to go about this too!
Hi
The ptool repo uses two patterns for distinct situations:
This doesn't allow conveying the supported configurations and requires hardcoding multiple calls to ptool scripts to generate the right data.
I also suspect it hurts contents.xml generation, as I believe Axiom's contents.xml support can convey multiple storage backends to flash.
Even on platforms with just UFS documented, there can be use of SPINOR storage for SAIL, as seen in platforms/qcs8300-ride-sx/ufs/contents.xml.in, albeit we don't seem to carry partition data for SAIL on SPINOR.
Lastly, there's the case for identical storage but two different usages: platforms/qrb2210-unoq has emmc-16GB and emmc-16GB-arduino targeting the same hardware, but with two sets of HLOS partitions.
How should we address this? Here are the options I have in mind:
I'd be happy to propose a PR, but would like if other maintainers weigh in on the target layout – perhaps others have nicer ideas on how to go about this too!