feat(flash): add glymur NVME support

[gagath]

Add support for generating the flash_glymur-crd/ directory. Note that
the "spi-nor" ptool platform, while supported, is not generated as we do
not have spi-nor support yet.

Closes: #273

[github-actions]

Test Results

 2 files  ±0   6 suites  ±0   4m 18s ⏱️ ±0s
20 tests ±0  20 ✅ ±0  0 💤 ±0  0 ❌ ±0 
64 runs  ±0  64 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit ccdd212. ± Comparison against base commit ed8ea44.

♻️ This comment has been updated with latest results.

[github-actions]

Test jobs for commit 5252229

• Job 162937 on qrb2210-rb1
• Job 162938 on qcs6490

[nivasnaik]

The boot binaries here contain NHLOS firmware that goes into spi-nor and the corresponding partition.conf support is present in ptool. Can we include that as well to make this flat build bootable on Glymur?
"https://softwarecenter.qualcomm.com/nexus/generic/software/chip/qualcomm_linux-spf-0-0/qualcomm-linux-spf-0-0_test_device_public/r0.0_00009.0/glymur-le-0-0/common/build/bin/Glymur_bootbinaries.zip

[lool]

I realize this is still draft, hope it's ok :)

Minor nit about adding the build_glymur var, otherwise this looks ok

Probably also update README for the proper qdl --storage nvme calls?

Could you confirm you've test booted this?

I'm ok to land this and add support for SPI-NOR later

[abickett]

CDT also available : https://artifacts.codelinaro.org/artifactory/codelinaro-le/Qualcomm_Linux/SC8480XP/cdt/sc8480xp-crd.zip - I think this would be able to plug in directly with the CDT replacement logic in linux-debian-flash?

[gagath]

Note that this currently does not work because the glymur device-tree is not present in dtbs.tar.gz, leading to a skip. Hence the draft. And also need to boot test yes, and yes to other comments.

[gagath]

CDT also available : https://artifacts.codelinaro.org/artifactory/codelinaro-le/Qualcomm_Linux/SC8480XP/cdt/sc8480xp-crd.zip - I think this would be able to plug in directly with the CDT replacement logic in linux-debian-flash?

Thanks, added CDT support to the new entry.

[github-actions]

Test jobs for commit ae280b4

• Job 163600 on qrb2210-rb1
• Job 163599 on qcs6490

[github-actions]

Test jobs for commit 1e7aefd

• Job 163601 on qcs6490
• Job 163602 on qrb2210-rb1

[lool]

I'm ok after updates and inclusion of CDT (thanks Adam!)

We can land this as soon as someone tests this manually to make sure the changes are correct (for instance combining rootfs and ESP image from daily glymur build with flash_ dir from this PR build)

[abickett]

Couple things here after trying to use this to flash Glymur. I needed to add the device programmer xbl_s_devprg_ns.melf (used for Hamoa, Glymur) to the copy. The CDT and the rest of the boot binaries are irrelevant to the NVME (as only spinor partition has CDT, boot binary partitions, DTB...) I tested this in context of also adding spinor support. Should this be added as a new PR - or potentially combine this? See my test branch commits for the proposed spinor addition: https://github.com/abickett/qcom-deb-images/commits/pr-332-glymur/

[lool]

Couple things here after trying to use this to flash Glymur. I needed to add the device programmer xbl_s_devprg_ns.melf (used for Hamoa, Glymur) to the copy. The CDT and the rest of the boot binaries are irrelevant to the NVME (as only spinor partition has CDT, boot binary partitions, DTB...) I tested this in context of also adding spinor support. Should this be added as a new PR - or potentially combine this? See my test branch commits for the proposed spinor addition: https://github.com/abickett/qcom-deb-images/commits/pr-332-glymur/

Good stuff in that branch, thanks! I've left a few comments there.

Question: how do you flash? With qdl? Which programmer do you use? I didn't see prog_firehose_ddr.elf in the boot binaries, I wonder if we're using a different programmer on Glymur CRD, or if it should be added to boot binaries and CDT like for the other platforms. (Or if we need a doc update to the README for Glymur CRD)

[gagath]

I tried Adam’s branch and was able to generate the flash_glymur-crd_spinor directory, will try to flash that (EDIT: need to find which programmer elf to use). I just pushed a fix for the cdt_filename to consider the subdirectory while we wait for it to disappear in future upstream releases as explained by @lool.

[abickett]

After building from (https://github.com/abickett/qcom-deb-images/commits/pr-332-glymur/) - I flashed with created directories flash_glymur-crd_nvme, flash_glymur-crd_spinor both with QDL and on Windows/EMMCDL. Device boots. This required change to add the melf programmer to the copied files. Note that this is the only current file from the boot binaries set that needs to be used both for spinor and nvme flash.

Ubuntu/x86 (qdl snap and building from upstream project - disable ModemManager due to USB conflicts)
(in SPINOR directory): qdl --storage spinor xbl_s_devprg_ns.melf rawprogram0.xml patch0.xml
(In NVME directory): qdl --storage nvme xbl_s_devprg_ns.melf rawprogram0.xml patch0.xml

Windows (the tool can use the linux relative paths)
.\EMMCDL.exe -p -f xbl_s_devprg_ns.melf -memoryname spinor -x rawprogram0.xml
.\EMMCDL.exe -p -f xbl_s_devprg_ns.melf -memoryname nvme -x rawprogram0.xml

[lool]

@gagath Can you add the melf changes to your branch?

I think I'm ok to add the spinor changes as well, I can tell landing the ptool changes to support "spinor-nvme" will take slightly longer:

• we can add spinor as an extra ptool platform for now
• I don't understand why we needed a separate find statement for nvme, I'd rather we continue with the original allowlist and extend with *.melf
• I don't like the "if storage is nvme skip these parts" changes

Perhaps we can just test if the target files need CDT to decide whether to copy it?

[github-actions]

Test jobs for commit ccdd212

• Job 164851 on qrb2210-rb1
• Job 164850 on qcs6490

[lool]

So Adam boot tested this; the CDT and DTB changes in this board block are mostly useless right now, but pave the way for SPINOR later, so I'm ok to have the (useless) metadata.

I'm going to land this now to help with daily CI.

[lool]

I've kicked daily glymur and qcom-next builds so that you get fresh images with these changes later today.

[gagath]

Manual run was OK, results at https://github.com/qualcomm-linux/qcom-deb-images/actions/runs/23555159484