firmware-qcom-boot-qcs615: add CDT for IQ615 LYRA EVK - #3091
gummadiv-qcom wants to merge 1 commit into
Conversation
Dmitry Baryshkov (lumag)
left a comment
Dmitry Baryshkov (lumag)
left a comment
There was a problem hiding this comment.
Signed-off-by: gummadiv gummadiv@qti.qualcomm.com
Please fix your Git configuration. Also, you've added the Lyra CDT. How is it going to be used?
|
And it doesn't build. |
|
No stray merge commits. |
f2416f1 to
77983c9
Compare
Add IQ-615-LYRA-EVK_V2.zip as CDT source for IQ615 LYRA EVK board Signed-off-by: gummadiv <gummadiv@qti.qualcomm.com>
77983c9 to
00aa63f
Compare
Hi Dmitry Baryshkov (@lumag), it will be placed in flat build created during qcs615 compilation. And customers can simply rename it if they want this CDT to be flashed as per the current procedure for other form factors as well |
|
Also, please help to add 2.1 milestone release tag to this PR |
This was already raised up for #2475 (comment) and then we have #2484. Users should not need to rename anything. If the machine conf supports multiple machines, each requiring the separate CDT, then we need to build a sepate flashing directory / archive for each of those machines. Be user friendly (and scripting-friendly). |
|
#2484 was concluded to open source CDT generation script, we are internally waiting for an update from respective team, but until then can we follow the same procedure |
How will CDT generator script help with this case? |
|
The problem is that so far we only had CDTs covering variations of the hardware, and here it seems to be a different EVK. Would the standard EVK CDT also work on lyra when not copied over by the user? |
|
Responding to both queries together The standard EVK CDT is not expected to work on the Lyra EVK, which is why a separate Lyra CDT is being added. My reference to #2484 was mainly around current solution being discussed around CDT and not as a solution to the packaging problem. I agree that the CDT generator script by itself doesn't address the issue of automatically selecting the correct CDT for a given machine. For this change, we are following the current approach where CDT variants are included in the build artifacts. Since Lyra requires a different CDT, we wanted to ensure users have access to the correct one. I also agree that requiring users to rename or manually select CDT files is not ideal. A machine-specific flashing directory/archive that automatically contains the correct CDT would be a much cleaner solution from both user and scripting perspectives. If there's a preferred mechanism in meta-qcom today for handling machine-specific CDT packaging/artifacts, please point me in that direction and I'm happy to rework this patch accordingly. My goal here is primarily to ensure Lyra support is available in 2.1 release while staying consistent with the current flow |
Then only mechanism available today is "create separate machine configuration". This PR in its current way can't be landed. Please work either on a proper generation of qflash folders or split Lyra to a separate machine. |
The only difference between the Tessolve and Lyra EVK images is the CDT. Introducing a separate machine configuration for Lyra would significantly increase the build matrix, resulting in additional builds, a substantial CI overhead. Generating separate But, considering 2.1 release timelines, could this enhancement be implemented in parallel as a follow-up PR? The existing |
We can't really claim that we support Lyra if the default image that is generated programs wrong CDT. |
And is this just to load a different DTB? |
Test Results 119 files + 38 715 suites +289 16h 8m 57s ⏱️ + 8h 42m 38s For more details on these failures, see this check. Results for commit 00aa63f. ± Comparison against base commit 1efd355. |
Yes, Lyra DTB is going to be part of dtb.bin. (#3103), CDT would help UEFI to load this DTB. |
|
Are we going to add lyra evks to lava as well? |
5 participants
Add IQ-615-LYRA-EVK_V2.zip as CDT source for IQ615 LYRA EVK board