qcs615-adp-air: add UFS-based partition.conf

[ricardosalveti]

Move partition.conf support under their expected storage configuration folder and add UFS-based partition.conf for qcs615-adp-air.

This is a breaking change and will require qcom-deb-images and meta-qcom updates due the new partition.conf path used.

[lumag]

It's unclear, is the device switchable between emmc and UFS? If so, we should probably provide both configurations.

[ricardosalveti]

As part of the latest qclinux 1.5 release we have emmc files for the other targets as well, but it is unclear to me how this was even tested, let me try to find that out.

[ndechesne]

qcom-ptool was not designed to support multiple disk variants. we will need to add it. likely an emmc or ufs folder inside each platform subfolder..

[lumag]

qcom-ptool was not designed to support multiple disk variants. we will need to add it. likely an emmc or ufs folder inside each platform subfolder..

Yep. Both configurations.

[ricardosalveti]

It's unclear, is the device switchable between emmc and UFS? If so, we should probably provide both configurations.

It needs modified hardware (as with other targets supporting eMMC as well as part of qclinux 1.5), so we can include both, but we won't really be able to validate the eMMC files unless we have access to the modified boards.

[lool]

While we sort out the plan for eMMC across all boards, can we merge the UFS version? I believe it's the higher priority one to have in the repo and to validate as the eMMC one requires hardware changes

[lumag]

This needs to be rebased.

[ricardosalveti]

I updated based on the changes from @ndechesne to move current configurations under their specific storage configuration folders (emmc / ufs), and added the UFS-based partition.conf for qcs615-adp-air.

I can break the pr in 2 if needed, had the other changes here more as a dependency so we can discuss how things will end up looking like.

@lool this is a breaking change as it adds a new directory for the partition.conf path.

[lool]

I updated based on the changes from @ndechesne to move current configurations under their specific storage configuration folders (emmc / ufs), and added the UFS-based partition.conf for qcs615-adp-air.

I can break the pr in 2 if needed, had the other changes here more as a dependency so we can discuss how things will end up looking like.

@lool this is a breaking change as it adds a new directory for the partition.conf path.

Thanks for the heads-up @ricardosalveti; it should be simple/quick enough to prepare an update to qcom-deb-images when this lands.

We should think of third parties consuming qcom-ptool data. If we had releases (#17), we would have:

• a place to announce breaking changes or new features (new boards being added)
• a time where people would ingest these changes
• something to package for distros if they want to produce flat images

[lool]

It's unclear, is the device switchable between emmc and UFS? If so, we should probably provide both configurations.

It needs modified hardware (as with other targets supporting eMMC as well as part of qclinux 1.5), so we can include both, but we won't really be able to validate the eMMC files unless we have access to the modified boards.

Now that this is closer to merging, I am thinking again about what we're trying to achieve through these files.

For me, qcom-ptool is a collection of data files and helper scripts to manage partition information for actual reference platforms. I guess it's meant to support official Qualcomm platforms so that meta-qcom, qcom-deb-images, LmP etc. can leverage the data and scripts to generate flat images.

Do we have a clear policy on what data should go in ptool? For instance:

• vision kits are considered a different board from a CDT and commercial perspective, but in ptool they are supported through the same platform; we could also have partitions data per board rather than per platform, stating the exact cdt filename that should be used (currently we track the cdt filenames in meta-qcom and in qcom-deb-images)
• would we accept third party boards if they had a different partition layout due to boot/hardware needs, say rubikpi?

Here, the new situation is that it's existing boards that are being modified to change from UFS boot to eMMC. Is this being defined as a new board from a CDT or from a commercial perspective? Is this officially supported in the documentation?

My proposal would be as follow:

• this ptool repo is only to be used for boards and hardware configurations (e.g. setting a jumper) that are officially supported in Qualcomm Linux releases (meta-qcom or qcom-deb-images)
• if you are doing your own board or software, you can use the ptool tools but you have to maintain your own data files
• we might break/update the format of the data files, in which case we'll document this in releases

[lumag]

I am spoiled by the OE world, but I don't see a direct need for 'releases'. We have the changing tip branch. Once in a while we might spawn the feature branches (e.g. once per QLI major or minor) and backport some of the platforms from the tip to the feature branch. Other than that all users (aka all distros) should be fine with the branch + commit-ID

[lumag]

In the end, all branches except tip are expected to be non-breaking, backwards-compatible, etc.