[Automated-testing] Provisioning [Was: Board management API discussion at ATS - my ideas]

Jan Lübbe jlu at pengutronix.de
Tue Oct 22 02:54:38 PDT 2019


Hi Tim,

keeping this separate from the Board Management thread.

On Sun, 2019-10-20 at 08:41 +0000, Tim.Bird at sony.com wrote:
> > > I've started collecting data about different test management layers at:
> > > https://elinux.org/Board_Management_Layer_Notes
> > > 
> > > Let me know what you think.
> > 
> > So if we could find a way to have a common scheduler and control
> > power+console via subprocess calls, shared labs would become a
> > possibility. Then one could use different test frameworks on the same
> > HW, even with interactive developer access, depending on what fits best
> > for each individual use-case.
> > 
> > For use, that would mean using labgrid for the BM layer. Then for tests
    ^ Typo. I meant 'for us'.

I think most would like to keep what they are currently using.

> > which need to control SD-Mux, fastboot, bootloader and similar, we'd
> > continue writing testcases "natively" with labrid+pytest. In addition,
> > we could then also use the same lab for kernelci+lava, which would be
> > very useful.
> 
> Sounds good.
> 
> I assume provisioning now?  If so, what are the main "styles" it supports?
> e.g.  - SDcard hot swapping

Yes, using an sd-mux board connected via USB.

>          - tftp/nfs rootfs mounting

Not explicitly by the "board management layer". In labgrid, that's
under control of the test suite setup code and uses serial console. In
LAVA/kernelci, this is done by the dispatcher based on board type
configuration (I think).

>          - fastboot

Yes.

>          - u-boot manipulation over the serial console
>             (using u- boot networking for file transfers and u-boot commands for flashing)

Yes, in the same way as tftp/nfs rootfs mounting.

>          - swupdate transfers?

Not in the board management layer (except providing information on IP
address or USB bus/device number). We handled this in project/test-
suite specific code. (And you probably meant RAUC not swupdate ;)

>         - etc.

- for difficult cases, we have zmodem up/down-load via UART when in a
Linux shell

- for bootloader upload we us:
  - JTAG via OpenOCD
  - serial-download-mode on i.MX (which is actually via USB)

Regards,
Jan
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |



More information about the automated-testing mailing list