Re: [Fuego] First steps with fuego

From: Rafael Gago Castano <RGC@hms.se>
To: "Bird, Timothy" <Tim.Bird@sony.com>,
	"fuego@lists.linuxfoundation.org"
	<fuego@lists.linuxfoundation.org>
Subject: Re: [Fuego] First steps with fuego
Date: Wed, 10 May 2017 13:12:25 +0000	[thread overview]
Message-ID: <HE1PR06MB303659837650F88F67692F4AC2EC0@HE1PR06MB3036.eurprd06.prod.outlook.com> (raw)
In-Reply-To: <ECADFF3FD767C149AD96A924E7EA6EAF1FA877E1@USCULXMSG01.am.sony.com>

I got some time today to keep investigating today, it was trivial to integrate with one of our boards, so the Wiki it's up to date and good. It was a very easy and trouble free setup. 

Then I wanted as an exercise to write test a for rs485 (the same case happens with CAN) but I have been looking at "fuego-core/engine/tests" and I couldn't answer the questions myself.

1.) Our current setup does device poweon/off the device (custom commands in LAVA), fetches a kernel, dtb and rootfs from our build servers and copies the images to the DUT's RAM for RAM booting (tftp + Uboot commands integrated in LAVA). How does these steps are best integrated in fuego?

LAVA has this feature integrated, but we already have an internal Python program that handles this, so we don't need fuego to talk with UBoot, just to know the best place to launch the tool. Spontaneusly and with what I know I only can think about doing it on the "test_pre_check" function or as the first (dummy) test of a DUT specific tesplan, but both would have its drawbacks.

2.) Let's say that we have the desired image running on the device and we want to test RS485 TX/RX at different baudrates. Now with LAVA we boot, wait until both machines are booted (using the "lava-send" and "lava-wait" synchronization primitives) set the baudrate in both sides, start the receiver side (either host or DUT), synchronize with the sender side (either host or DUT) , start sending and then we start the cycle again with another baudrate - TX/RX cfg. We do the same type of test for CAN too (using cansequence).

I haven't figured out how I would implement such test with fuego. Both sender and receiver would need to be able to signal a failure, but there is only a "run_test" function and it's running on the DUT. Is there any way to implement this or any sane workaround?

3.) This one is very easy to add/contribute, but some inbuilt support to specify inside a test a git + branch + commit sha instead of a tarball would be nice to avoid duplication of tests for different library versions (e.g. when testing previous image releases that get backports).

BR,
Rafa.