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

[Milosz Wasilewski]

On Tue, 22 Oct 2019 at 10:59, Jan Lübbe <jlu at pengutronix.de> wrote:
>
> 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.

Some boards (like versatile express family) allow to mount mass
storage device that is later used to load software from.

>
> >          - 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).

this is correct. As a side note we're working on supporting NFS when
using 'fastboot boot <boot.img>'. This is android world alternative to
tftp.

>
> >          - 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)

TI boards also allow to load bootloader using xmodem or ymodem
(depending on the board). LAVA uses this in 'board recovery mode'.

Best Regards,
milosz

>
> 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 |
>
> --
> _______________________________________________
> automated-testing mailing list
> automated-testing at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/automated-testing