mbox series

[isar-cip-core,0/4] Add rzg2m support

Message ID 20191106124439.10532-1-Quirin.Gylstorff@siemens.com (mailing list archive)
Headers show
Series Add rzg2m support | expand

Message

Quirin Gylstorff Nov. 6, 2019, 12:44 p.m. UTC
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

Comments

Jan Kiszka Nov. 6, 2019, 2:12 p.m. UTC | #1
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
>
Quirin Gylstorff Nov. 6, 2019, 2:37 p.m. UTC | #2
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
Chris Paterson Nov. 6, 2019, 4:19 p.m. UTC | #3
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
Quirin Gylstorff Nov. 8, 2019, 12:57 p.m. UTC | #4
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