Introduce CDT support #112
Conversation
These firmware recipes are effectively MACHINE_ARCH. We cannot build more than 1 per machine, otherwise we override the files in DEPLOYDIR, even less mixing firmware from machines with different SOC. Signed-off-by: Nicolas Dechesne <[email protected]>
Qualcomm released the CDT file for the RB3 Gen2. There is a different CDT per flavor of the device (core, vision, industrial). For now we only support -core in this layer. The patch is made in such a way that we can add other flavor when we create the corresponding machines. The CDT files for RB3 Gen2 are available here: * https://artifacts.codelinaro.org/artifactory/codelinaro-le/Qualcomm_Linux/QCS6490/cdt/rb3gen2-core-kit.zip * https://artifacts.codelinaro.org/artifactory/codelinaro-le/Qualcomm_Linux/QCS6490/cdt/rb3gen2-vision-kit.zip * https://artifacts.codelinaro.org/artifactory/codelinaro-le/Qualcomm_Linux/QCS6490/cdt/rb3gen2-industrial-kit.zip Signed-off-by: Nicolas Dechesne <[email protected]>
For some platforms, the CDT file is published and can be used when flashing a device with QDL/firehose. Unfortunately, the CDT is not always available, so we have to twist the recipe and the partition conf file only on selected platform. The RB3 Gen2 is the first platform that makes use of the public CDT, the idea is to fixup the partition.conf file and insert "--filename=cdt.bin" on the right line. Signed-off-by: Nicolas Dechesne <[email protected]>
Include cdt.bin for platforms that support it. Signed-off-by: Nicolas Dechesne <[email protected]>
ndechesne
requested review from
quic-vkraleti,
ricardosalveti and
sbanerjee-quic
as code owners
| sed -i '/name=cdt/ s/$/ --filename=cdt.bin/' ${S}/${PARTCONF} | ||
| } | ||
|
|
||
| do_compile:prepend:qcs6490-rb3gen2-core-kit() { |
There was a problem hiding this comment.
Based on the information from https://docs.qualcomm.com/bundle/publicresource/topics/80-70015-254/how_to.html, CDTs for core and vision kits differ (I've compared hashes). Could we also introduce the one for Vision Kit?
This probably will also require a new machine file for qcs6490-rb3gen2-vision-kit
There was a problem hiding this comment.
Yes, they are different. This is why I prepared the recipe so that we can add more MACHINES in here. There will be a -vision .conf file, we just haven't added it yet (see how it is in the 1.x / legacy branch, https://github.com/quic-yocto/meta-qcom-hwe/tree/kirkstone/conf/machine)
There was a problem hiding this comment.
As we currently use qcs6490-rb3gen2-core-kit machine for both kits (I'm testing that build on Vision Kit, for example), my concern is if it can break boot if we deliberately flash wrong CDT?
There was a problem hiding this comment.
hmm. interesting.. we are shipping only 1 DTB, and I would expect the CDT to basically assist in the DTB selection process, nothing else. So I am pretty sure that you can use either one of the 2 CDT , and it will work. Do you want to try?
There was a problem hiding this comment.
I've tested both CDTs no my Vision KIt and confirm Linux boots in both cases
There was a problem hiding this comment.
Just to note: I still consider that changing CDT for the mezzanines is a mistake. What if the user adds industrial mezz on top of the Vision Kit? Which CDT should be flashed in such a case?
There was a problem hiding this comment.
We are only using one DTB in the end via the dtb fat image, since we don't have the extra device-id logic in upstream, that is why the generated image is working fine on both.
We will have to create another machine conf for vision kit as well, which will have its own CDT.
There was a problem hiding this comment.
Just to note: I still consider that changing CDT for the mezzanines is a mistake. What if the user adds industrial mezz on top of the Vision Kit? Which CDT should be flashed in such a case?
Yes, I also don't agree on using CDT here, as this is just a mezzanine in the end, but I don't think there is another mechanism to identify if the mezzanine is available at runtime atm.
There was a problem hiding this comment.
My point is that even with CDT we can not identify the mezzanine (and we have no guarantee that there is just a single mezz). The updated boot-selection mechanism should account for that by e.g. allowing a user to manually name attached mezzanines.
| @@ -27,6 +27,15 @@ PARTCONF ?= "" | |||
| PARTCONF:qcm6490 ?= "qcm6490-partitions.conf" | |||
| PARTCONF:qcs9100 ?= "qcs9100-partitions.conf" | |||
|
|
|||
| # For machines with a published cdt file, let's make sure we flash it | |||
There was a problem hiding this comment.
Could you please also expand on what CDT is and what is contains in the `qcom-partition-confs: add support for CDT" commit message. Thanks!
There was a problem hiding this comment.
Sure. I can add more information. I will update the PR.
CDT is Configuration Data Table. It contains the platform and subtype IDs, the same explained here https://android.googlesource.com/kernel/msm.git/+/android-msm-bullhead-3.10-n-preview-1/Documentation/devicetree/bindings/arm/msm/board-id.txt.
The IDs are 'flashed', at runtime they are read by the bootloader, and it will search through all the DTBs on the system for the one that 'matches' looking at the board-id in the DTB.
That solution was never accepted upstream, and used mostly in Android. We are working on a 'new' solution for qualcomm linux.
It was a bit more convoluted than I wanted.. but here is some initial support for flashing the CDT file.
The CDT file contains some IDs that are used at runtime to identify the board. The CDT is typically flashed in production on the device. However it is possible to erase/corrupt the CDT, which generally bricks the board.
The CDT is published for some devices, at least all flavor of RB3 Gen2. This PR makes changes in every place where it's needed, so that the generated qcomflash package includes the CDT file, and the rawprogram XML file has the instructions to flash it.
There are a few tricks in there..