| Message ID | 20191106124439.10532-1-Quirin.Gylstorff@siemens.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add rzg2m support | expand |
On 06.11.19 13:44, Q. Gylstorff wrote: > From: Quirin Gylstorff <quirin.gylstorff@siemens.com> > > Add the rzg2m reference board. > Add the option to build rootfs tarballs for LAVA tests. > This option needs to be activated in the gitlab-ci.yml by > adding it to the builds for testing. > Nice! Beyond building and actually deploying this, what else would be missing to hook up the result with a board in the lab? Jan > > Quirin Gylstorff (4): > kas: Increase Isar version > classes: add wic-targz-img.bbclass > hihope-rzg2m: Add board support > ci: add hihope-rzg2m to ci chain > > .gitlab-ci.yml | 4 + > board-rzg2m.yml | 16 + > classes/wic-targz-img.bbclass | 13 + > conf/machine/bbb.conf | 2 +- > conf/machine/hihope-rzg2m.conf | 17 + > conf/machine/iwg20m.conf | 2 +- > conf/machine/qemu-amd64.conf | 2 +- > conf/machine/simatic-ipc227e.conf | 2 +- > kas.yml | 2 +- > opt-targz-img.yml | 20 ++ > .../linux/files/hihope-rzg2m_defconfig | 330 ++++++++++++++++++ > scripts/deploy-cip-core.sh | 4 + > wic/hihope-rzg2m.wks | 15 + > 13 files changed, 424 insertions(+), 5 deletions(-) > create mode 100644 board-rzg2m.yml > create mode 100644 classes/wic-targz-img.bbclass > create mode 100644 conf/machine/hihope-rzg2m.conf > create mode 100644 opt-targz-img.yml > create mode 100644 recipes-kernel/linux/files/hihope-rzg2m_defconfig > create mode 100644 wic/hihope-rzg2m.wks >
On 11/6/19 3:12 PM, Jan Kiszka wrote: > Nice! Beyond building and actually deploying this, what else would be > missing to hook up the result with a board in the lab? We would need to change the configuration of the LAVA jobs in [1] to use the tarballs generated by the build. [1]: https://gitlab.com/cip-project/cip-testing/linux-cip-ci/blob/next/lava_templates/ From what I see the actions use a hardcoded rootfs url to boot via nfs. We could use the same template mechanism from Chris for dtb and Kernel for the rootfs. Kind regards, Quirin
Hello, > From: Gylstorff Quirin <quirin.gylstorff@siemens.com> > Sent: 06 November 2019 14:37 > > > > On 11/6/19 3:12 PM, Jan Kiszka wrote: > > Nice! Beyond building and actually deploying this, what else would be > > missing to hook up the result with a board in the lab? > > We would need to change the configuration of the LAVA jobs in [1] to > use the tarballs generated by the build. Yes, at the moment they are painfully hardcoded. I plan to at least have them point to the 'latest' CIP Core. However for your use case, you'll want to test the binaries you just created. I guess we should decide on whether we want to re-use linux-cip-ci for CIP Core testing, or just end up creating a separate version for CIP Core. Linux-cip-ci could easily be modified to support both CIP Linux & Core testing (we could just add another version of submit_tests.sh for CIP Core), and I think this would be easier to maintain down the line. Is this something you'd like to have a go at? I'm happy to do it, but I may struggle to find time in the next few weeks. Kind regards, Chris > > [1]: > https://gitlab.com/cip-project/cip-testing/linux-cip- > ci/blob/next/lava_templates/ > > From what I see the actions use a hardcoded rootfs url to boot via nfs. > We could use the same template mechanism from Chris for dtb and Kernel > for the rootfs. > > Kind regards, > > Quirin
On 11/6/19 5:19 PM, Chris Paterson wrote: > Hello, > >> From: Gylstorff Quirin <quirin.gylstorff@siemens.com> >> Sent: 06 November 2019 14:37 >> >> >> >> On 11/6/19 3:12 PM, Jan Kiszka wrote: >>> Nice! Beyond building and actually deploying this, what else would be >>> missing to hook up the result with a board in the lab? >> >> We would need to change the configuration of the LAVA jobs in [1] to >> use the tarballs generated by the build. > > Yes, at the moment they are painfully hardcoded. I plan to at least have them point to the 'latest' CIP Core. > However for your use case, you'll want to test the binaries you just created. > > I guess we should decide on whether we want to re-use linux-cip-ci for CIP Core testing, or just end up creating a separate version for CIP Core. > Linux-cip-ci could easily be modified to support both CIP Linux & Core testing (we could just add another version of submit_tests.sh for CIP Core), and I think this would be easier to maintain down the line. > > Is this something you'd like to have a go at? > I'm happy to do it, but I may struggle to find time in the next few weeks. I have some other projects in the next weeks. Afterwards if time permits I will try to look into it. We can sync each other when one of use can start with it. Kind regards, Quirn
From: Quirin Gylstorff <quirin.gylstorff@siemens.com> Add the rzg2m reference board. Add the option to build rootfs tarballs for LAVA tests. This option needs to be activated in the gitlab-ci.yml by adding it to the builds for testing. Quirin Gylstorff (4): kas: Increase Isar version classes: add wic-targz-img.bbclass hihope-rzg2m: Add board support ci: add hihope-rzg2m to ci chain .gitlab-ci.yml | 4 + board-rzg2m.yml | 16 + classes/wic-targz-img.bbclass | 13 + conf/machine/bbb.conf | 2 +- conf/machine/hihope-rzg2m.conf | 17 + conf/machine/iwg20m.conf | 2 +- conf/machine/qemu-amd64.conf | 2 +- conf/machine/simatic-ipc227e.conf | 2 +- kas.yml | 2 +- opt-targz-img.yml | 20 ++ .../linux/files/hihope-rzg2m_defconfig | 330 ++++++++++++++++++ scripts/deploy-cip-core.sh | 4 + wic/hihope-rzg2m.wks | 15 + 13 files changed, 424 insertions(+), 5 deletions(-) create mode 100644 board-rzg2m.yml create mode 100644 classes/wic-targz-img.bbclass create mode 100644 conf/machine/hihope-rzg2m.conf create mode 100644 opt-targz-img.yml create mode 100644 recipes-kernel/linux/files/hihope-rzg2m_defconfig create mode 100644 wic/hihope-rzg2m.wks