Build guide 2.0 Updates for BSP Image#8
Conversation
|
This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation. |
a1f4080 to
a0efff1
Compare
|
|
||
| cd <workspace_path>/build-qcom-wayland/tmp-glibc/deploy/images/qcs6490-rb3gen2-vision-kit/qcom-multimedia-image | ||
| ls -al system.img No newline at end of file | ||
| cd <workspace-dir>/build/tmp/deploy/images/<MACHINE>/<IMAGE>-<MACHINE>.rootfs-<DATE>.qcomflash/ |
There was a problem hiding this comment.
We should probably explain what is qcomflash (dir has the same content as the tarball).
There was a problem hiding this comment.
I've added an explanation based on this commit. Please let me know if my understanding is correct.
| # source setup-environment: Sets the environment, creates the build directory build-qcom-wayland, | ||
| # and enters into build-qcom-wayland directory. | ||
| # Copy generated meta-qcom-extras kas fragment to meta-qcom | ||
| cp meta-qcom-extras/ci/extras.yml meta-qcom/ci/extras.yml |
There was a problem hiding this comment.
I know it is outside the scope of the documentation, but this process used for meta-qcom-extras is not really great, kas users do expect to run the build by cloning only one repository and not really executing additional scripts.
Downloading the lock file is OK, but more than that it gets a bit too complicated, and users will often have to redo the build process multiple times.
There was a problem hiding this comment.
If we want to build meta-qcom-extras with kas, we have two options:
- Maintain a kas fragment for meta-qcom-extras and extend meta-qcom kas configs.
- Copy and maintain all meta-qcom kas configs as part of the meta-qcom-extras repo.
kas does support cross-repo references in its configuration. However, we would still need to maintain per machine/distro files in meta-qcom-extras. Maintaining a copy of all the configurations was not preferable, so we decided to go with the kas fragment approach.
There was a problem hiding this comment.
Extending meta-qcom to include a kas file for meta-qcom-extras would probably be OK, as in the end this is just a kas file.
There was a problem hiding this comment.
I'll raise a separate issue on meta-qcom to discuss if we can host the meta-qcom-extras kas config in meta-qcom and any potential issues we may face.
| # Run the following commands inside the base image build location | ||
| bash | ||
| docker run -it -v "${HOME}/.gitconfig":"/home/${USER}/.gitconfig" -v "${HOME}/.netrc":"/home/${USER}/.netrc" -v $(pwd):$(pwd) -w $(pwd) qcom-6.6.116-qli.1.7-ver.1.1_22.04 /bin/bash | ||
| kas/kas-container build --skip repos_checkout meta-qcom/ci/<machine>:meta-qcom/ci/<distro> |
There was a problem hiding this comment.
The problem of doing kas checkout lock first is that the user will have to use --skip repos_checkout, and in case the user forgets about this command, the repository content will often be different, causing a huge mess.
Giving the lock file to kas build (kas build meta-qcom/ci/:meta-qcom/ci/:lock.yml) would be the expected flow.
There was a problem hiding this comment.
kas parses the configuration files before checkout/setup steps. If we follow this approach, we would get something like this:
git clone https://github.com/qualcomm-linux/meta-qcom-releases
git clone https://github.com/qualcomm-linux/meta-qcom
cp meta-qcom-releases/lock.yml meta-qcom/ci/
# this is incorrect, because we are using the wrong version of the config files
kas build meta-qcom/ci/qcs9100-ride-sx.yml:meta-qcom/ci/qcom-distro.yml:meta-qcom/ci/lock.ymlIf we want to avoid the --skip repos_checkout flag, we can do this instead.
git clone https://github.com/qualcomm-linux/meta-qcom-releases
kas checkout meta-qcom-releases/lock.yml
cp meta-qcom-releases/lock.yml meta-qcom/ci/
kas build meta-qcom/ci/qcs9100-ride-sx.yml:meta-qcom/ci/qcom-distro.yml:meta-qcom/ci/lock.yml|
@angolini @quaresmajose @koenkooi mind having a look? (@kprosise fyi) |
76dc6e0 to
a644341
Compare
| - A ``sudo`` permission is required to run a few commands | ||
|
|
||
| .. note:: Code compilation on a VM is a slow process and can take a few hours. Qualcomm recommends using an Ubuntu host computer for compilation. To set up a virtual machine (VM) running Ubuntu 22.04 on Microsoft\ :sup:`®` Windows\ :sup:`®` or Apple\ :sup:`®` macOS\ :sup:`®`, see `Qualcomm Linux Virtual Machine Setup Guide <https://docs.qualcomm.com/bundle/publicresource/topics/80-70023-41/>`__. No newline at end of file | ||
| .. note:: Code compilation on a VM is a slow process and can take a few hours. Qualcomm recommends using an Ubuntu host computer for compilation. To set up a virtual machine (VM) running Ubuntu 22.04 on Microsoft\ :sup:`®` Windows\ :sup:`®` or Apple\ :sup:`®` macOS\ :sup:`®`, see `Qualcomm Linux Virtual Machine Setup Guide <https://docs.qualcomm.com/bundle/publicresource/topics/80-70023-41/>`__. |
There was a problem hiding this comment.
With kas-container Ubuntu in not mandatory anymore and any linux host can be used
There was a problem hiding this comment.
Even if we recommend Ubuntu, it should really be 24.04.
But +1 to say that the kas-container can be used instead in any host with docker support.
a644341 to
c89f221
Compare
sbanerjee-quic
left a comment
There was a problem hiding this comment.
I do not see a reference to qcom-multimedia-proprietary-image
Ensures POSIX-compliant text files and avoids diff noise. Signed-off-by: Abin Joseph <abinjose@qti.qualcomm.com>
Remove the qsc-launcher section from the build guide, as it is no longer applicable. Signed-off-by: Abin Joseph <abinjose@qti.qualcomm.com>
cb795f3 to
87647d5
Compare
This is documented as part of the @sbanerjee-quic Do we need to explain configs 1-5 as part of the build guide? |
87647d5 to
531a6cd
Compare
c2d3a77 to
bbe0496
Compare
|
@ricardosalveti @quaresmajose @sbanerjee-quic I've revised the PR based on all the suggestions/feedback. I'm planning to merge this PR, unless there is any major feedback. We will raise subsequent PRs for any minor changes and for firmware/QSC-CLI updates. Can you sign-off on the change if no concerns? |
QIM SDK layer is now integrated as part of meta-qcom layer and will be available as part of the qcom-multimedia-image and qcom-multimedia-prop-image recipes. Signed-off-by: Abin Joseph <abinjose@qti.qualcomm.com>
QIR SDK workflows are not supported in the build guide and can be removed. Signed-off-by: Abin Joseph <abinjose@qti.qualcomm.com>
real-time meta layer is now integrated as part of meta-qcom. Remove these sections from the build guide. Signed-off-by: Abin Joseph <abinjose@qti.qualcomm.com>
To align with upstream community best practices, the default build instructions now use kas. To avoid breaking existing customer workflows from QLI 1.0, a repo manifest–based workflow is also supported as an alternate option. Signed-off-by: Abin Joseph <abinjose@qti.qualcomm.com>
meta-qcom uses the qcomflash IMAGE_FSTYPE which creates a single tarball containing all the relevant files to perform a full clean flash, including partition metadata, boot firmware, ESP partition and the rootfs. Update all references accordingly to reflect the correct artifact names and paths. Also updates the image recipes currently supported by meta-qcom. Signed-off-by: Abin Joseph <abinjose@qti.qualcomm.com>
To align with upstream community best practices, the meta-qcom-extras build workflow now uses kas. Metalayers are synced using kas-lock files. Milestone releases will create a tag on meta-qcom-extras-releases repository, which customers can use to sync critical release workspaces. Build instructions have been revised to reflect the kas based workflow. Signed-off-by: Abin Joseph <abinjose@qti.qualcomm.com>
This section can be merged with the "Build from GitHub for registered users" since both have duplicate content. Signed-off-by: Abin Joseph <abinjose@qti.qualcomm.com>
The unregistered and registerd user build guides have been merged into a single section as the primary recommended workflow. qsc-cli installation instructions have been removed as it is not used in the current workflow. Docker instructions are added as a footnote and uses the siemens/kas container instead. Signed-off-by: Abin Joseph <abinjose@qti.qualcomm.com>
The “Build with GitHub” sections for registered and unregistered users contained duplicate instructions. To streamline the documentation, only the Docker build steps are now documented under the registered users section. Section titles were renamed to better reflect their actual content: - Build with GitHub for unregistered users -> Build from Source - Build with GitHub for registered users -> Build with Docker - Build with GitHub using firmware and extras -> Build from Source (with firmware and extras) Signed-off-by: Abin Joseph <abinjose@qti.qualcomm.com>
The build workflows have been reworked to use kas based instructions. Align eSDK generation instructions to use kas as well. Signed-off-by: Abin Joseph <abinjose@qti.qualcomm.com>
bbe0496 to
f86c4c5
Compare
Overview
Host System Requirements
Build Instruction Updates
siemens/kascontainer.How Tosection.Removed Sections