Add a way to test upcoming firmware

[lumag]

The main meta-qcom layer is settled on using linux-firmware and hexagon-dsp-binaries. However it might make sense to be able to test firmware (and boot firmware) before it gets released. Add a sublayer which provides support for testing the pending firmware changes from QArtifactory.

[github-actions]

Test Results

 4 files  ±0   8 suites  ±0   3m 37s ⏱️ ±0s
31 tests ±0  31 ✅ ±0  0 💤 ±0  0 ❌ ±0 
80 runs  ±0  80 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit 1ee1d52. ± Comparison against base commit 7384748.

♻️ This comment has been updated with latest results.

[github-actions]

Test jobs for commit 1b44c8a

• Job 72185 on qcs6490
• Job 72186 on qrb2210-rb1
• Job 72184 on qcs9100

[ricardosalveti]

I understand that having this as an additional meta layer makes sense, but also not a fan of having extra layers mixed up with meta-qcom, at least based on how the files are currently structured, would be nice to find a way for this to be part of meta-qcom and enabled with a custom override.

Also, for boot firmware we are basically using this to test what is already released downstream, would probably just make more sense to propose the updates once they are available directly, as in the end we don't have other providers and don't expect this to be updated outside qualcomm linux releases (at least not for now). Once we have weekly development snapshots this would make more sense to have (to use for continuous testing).

[ricardosalveti]

Updated boot firmware for qcs9100 is also part of #847, and I'm about to propose a similar update for 6490 (won't conflict much in the end).

[vkraleti]

If intention here is to test latest drop of firmware before accepting, can dev-upstream be used to pull latest version?

[lumag]

If intention here is to test latest drop of firmware before accepting, can dev-upstream be used to pull latest version?

I can give it a thought, but do you have any idea on your mind how to implement it?

[vkraleti]

If intention here is to test latest drop of firmware before accepting, can dev-upstream be used to pull latest version?

I can give it a thought, but do you have any idea on your mind how to implement it?

Unfortunately, there is no predictable way to know what the latest firmware will be. Generally, the one with the highest number is the latest. May be firmware recipes can scan all the directory names and pick the one with the highest number as dev-upstream variant.

[lumag]

If intention here is to test latest drop of firmware before accepting, can dev-upstream be used to pull latest version?

I can give it a thought, but do you have any idea on your mind how to implement it?

Unfortunately, there is no predictable way to know what the latest firmware will be. Generally, the one with the highest number is the latest. May be firmware recipes can scan all the directory names and pick the one with the highest number as dev-upstream variant.

This is AUTOREV, not devupstream. And I'd rather not implement such scanning. Traversing directories on the web server can open a can of worms.

[github-actions]

Test jobs for commit 36d19d0

• Job 73695 on qcs6490
• Job 73693 on qrb2210-rb1
• Job 73692 on qcs9100
• Job 73694 on qcs9100-rb8

[sbanerjee-quic]

firmware-qcom-qcs6490: package latest firmware for QCS9100

The changes are for qcs9100, but subject says qcs6490 @lumag

[ricardosalveti]

I would prefer not mixing one layer into another here (as we might also have additional layers as we saw with the axiom related changes), should we move everything under meta-qcom into a meta-qcom folder then?

Would be a bit similar to https://github.com/jonmason/meta-arm and https://git.yoctoproject.org/meta-ti/tree/.

[github-actions]

Test jobs for commit 368e3c7

• Job 74700 on qcs9100
• Job 74703 on qcs6490
• Job 74702 on qcs9100-rb8
• Job 74701 on qrb2210-rb1

[lumag]

@ricardosalveti moved meta-qcom to the subdir

[ricardosalveti]

@ricardosalveti moved meta-qcom to the subdir

Sure, this would work for me, might just need to update ci/kas/.github and README to point to the new directory.

@ndechesne @vkraleti @sbanerjee-quic this would allow for us to host additional meta layers that are relevant to meta-qcom (e.g. tip testing, axiom integration, extras, etc) as part of this repo, a common behavior that is found in several other bsp layers.

[github-actions]

Test jobs for commit 1ee1d52

• Job 75411 on qcs9100
• Job 75409 on qcs9100-rb8
• Job 75410 on qcs6490
• Job 75408 on qrb2210-rb1

[mwasilew]

I think we're missing test jobs using the new firmware. Or is the new firmware already included in the default builds?

[koenkooi]

@ricardosalveti moved meta-qcom to the subdir

Sure, this would work for me, might just need to update ci/kas/.github and README to point to the new directory.

@ndechesne @vkraleti @sbanerjee-quic this would allow for us to host additional meta layers that are relevant to meta-qcom (e.g. tip testing, axiom integration, extras, etc) as part of this repo, a common behavior that is found in several other bsp layers.

This would be a nice solution to being able to host more BSP related layers. I do warn about moving non-BSP layers like meta-qcom-distro into this, it makes coupling the DISTRO to the BSP a bit too easy, usually breaking standalone BSP usage.