Find common location for machine specific partitioning related data

[ricardosalveti]

Follow up from qualcomm-linux/meta-qcom-hwe#67 (comment), we should have a dedicated repository for the partitioning related data that is consumed by meta-qcom-hwe but not hosted by the layers.

This is so we can start sharing with other common distributions (e.g. debian) later on.

[lumag]

As a note, we have been using https://git.codelinaro.org/linaro/qcomlt/db-boot-tools to contain data for supported devkits. Consider using that repo and using merge requests to provide data for newer boards.

[ndechesne]

We are currently looking into that. In meta-qcom-hwe we've been using an intermediate file format (partition.conf) instead of the XML files. We are planning to have a standalone repo to host these files outside of meta-qcom-hwe. we probably want to host it on a qualcomm github repo. let me think about that.

[lumag]

We settled on using CLO repo as this allowed us to use build artifacts in rescue package generation. If you switch to any other location, please pull in all boards definitions from the repo I have pointed to.

What is the benefit of using non-structured, non-verifiable file format?

[ndechesne]

yes, the distribution of prebuilt binary/rescue package is important, I am aware. For the additional/alternate file format, I am not sure why it was created, and I will check. It does not seem very useful, especially since the tool that converts to XML is not doing much processing, I will investigate more on that.

[ricardosalveti]

Initial repo is now available via https://github.com/qualcomm-linux/qcom-ptool (I have not yet verified the files, but I'm sure @ndechesne tested it). It is not yet aligned to all platforms from https://git.codelinaro.org/linaro/qcomlt/db-boot-tools, but we will look into that (as the initial need was just to have an open source repository we could use to host all those files).

[lumag]

Well, it causes the same questions / issues:

• Why does it use unverifiable .conf instead of an XML? I don't see a benefit.
• Why is it located under qualcomm-linux? I think linux-msm might be a better fit,
• It mixes SoCs and machines. Neither qcm6490 nor qcs9100 define a board (it should be something like rb3gen2 and ride)
• It doesn't leave space for the AOSP vs Linux partition tables.

[ndechesne]

After some internal discussions:

1. the .conf format was designed to support (easily) eMMC vs UFS vs NAND. eg. only contains partition information, not physical storage.
2. however, we've agreed to store XML files instead of the .conf file format, since that's the actual file that we 'ship'
3. It is under qualcomm-linux because we intend to make releases for Qualcomm reference boards, dev boards, and we wanted some level of control on the repo. I am sure we can figure out how to open up to community platforms
4. We should have per board, not per SoC configuration files.
5. While QCOM is unlikely to support/provide AOSP support, this can be added as a community need. Let's discuss how to do that in a proper way.

[lumag]

1. The .conf file also contains storage information: --disk --type=ufs --size=137438953472, --partition --lun=0.
2. yay!
3. Having Bjorn and Konrad as org maintainers also provides some control on the repo. I think it makes sense to have the repo under linux-msm/ as it provides a correct message: a shared repo with Qualcomm and community contibutions. For example, Amit Pundir might be interested in AOSP partition schemes, even for RB3gen2 or other IoT boards. We might be interested in adding partition schemes for other development kits (not limiting ourselves to just HDKs and RB boards). PostmarketOS developmers might add their recommended partition schemes, etc.
4. Agreed :-)
5. At least for some of the existing boards we were providing and generating both Linux-targeted and AOSP-targeted partitioning schemes. In some cases this was just an inertia from existing mobile XML. In other cases it helped AOSP developers. Basically for each of the boards we had either both subdirs, aosp and linux, or just one of those.

[obbardc]

FWIW the --size parameter appears to be unused and I have successfully removed it from my custom rb3gen2 configs