README: Add build instructions #48
Conversation
|
The KAS build timed out while fetching the sstate cache, so I had to remove the sstate mirror and retry. WARNING: Error contacting Hash Equivalence Server unix:///local/mnt/workspace/atul/cse/test_new_readme_wf/build-kas/build/hashserve.sock: Timed out waiting for data |
adhudase
force-pushed
the
readme_update
branch
from
723e422 to
092938e
Compare
README.md
Outdated
|
|
||
| 6. Build images: | ||
| ``` | ||
| bitbake esp-qcom-image && bitbake core-image-minimal |
There was a problem hiding this comment.
This would be better:
bitbake esp-qcom-image core-image-minimal
e.g. avoid running bitbake twice (and parsing recipes, ...)
|
@adhudase note that I can reproduce the issue with the hash server when building from inside the corporate network, FWIW. |
Disabled the sstate-cache mirror by default #49 |
adhudase
force-pushed
the
readme_update
branch
from
092938e to
2363c27
Compare
|
@ndechesne @ricardosalveti Thank you for the review. I’ve updated the commit based on your comments. |
README.md
Outdated
| 1. Clone this layer and its dependencies | ||
| ``` | ||
| git clone https://github.com/quic-yocto/meta-qcom-hwe.git -b main | ||
| git clone git://git.yoctoproject.org/meta-qcom -b master |
There was a problem hiding this comment.
we should use/recommend the http link instead of git://
https://git.yoctoproject.org/meta-qcom
https://git.yoctoproject.org/poky
README.md
Outdated
| MACHINE = "qcs6490-rb3gen2-core-kit" | ||
| ``` | ||
|
|
||
| 5. Set `INITRAMFS_IMAGE` in local.conf |
There was a problem hiding this comment.
We have more settings in local.conf (in our KAS/CI config) such as the switch to systemd. I am not sure what we want to do with that.. but if someone builds using the instructions here, they will end up with an image without systemd for example, which we are not even testing.
There was a problem hiding this comment.
Maybe it would be better to just use kas for build, the necessary configuration is already defined and this way of using it is much simpler.
There was a problem hiding this comment.
right. that's a bit where I wanted to go. I am wondering what we really want to ask our users.. kas here is also new. the QCL 1.x (and LmP) use repo + setup-environment scripts. So we need to decide what we want long term for this branch. Are we even going to use poky here, or will we bring meta-qcom-distro into the build? Is this branch just a mechanism to test the standalone BSP layer, and we will get a 'main' branch in the qcom-manifest to do a full distro build?
There was a problem hiding this comment.
The idea for this branch alone is to be tested with poky only, we will have similar testing done against this branch in meta-qcom-distro, which will indeed cover more use cases and scenarios.
This is why I even removed the instructions here, as folks consuming this layer should really just use it as a BSP layer (but of course we should state what we support here). Maybe just point the instructions to kas and link the configuration used by kas for folks wanting to manually use this layer?
There was a problem hiding this comment.
I’ve made the updates as requested. Please review them.
Add instructions to build esp-qcom-image and core-image-minimal images for supported boards. Signed-off-by: Atul Dhudase <[email protected]>
adhudase
force-pushed
the
readme_update
branch
from
2363c27 to
8e376ad
Compare
|
Thanks. It looks much better. At least for now, the documentation is about what we are really testing/building ourselves. Of course things may change in the future, and we can update the README accordingly. |
Add instructions to build esp-qcom-image and core-image-minimal images for supported boards.