[Fuego] Board setup

Bird, Timothy Tim.Bird at sony.com
Tue Apr 11 18:25:13 UTC 2017


> -----Original Message-----
> From: Michal Simek on Tuesday, April 11, 2017 2:18 AM
> Hi,
> 
> I have started to play with fuego with one arm64 board I have here.
> I have a question about handling board itself. I have multiple
> boards(home boardfarm) connected to my PC and every board needs to get
> certain configuration before starts. At least power on.
> And when test is done power off too.
> How is this handled? I didn't find any hint how to do it.

Well, there *are* some hooks for things like this, but they're a bit kludgy, and
indeed, not document hardly at all.  We are planning on improving this in the
next release (1.2) with some API changes to make board setup and teardown
more straightforward and orthogonal.

What we have now is the following:
During the pre_test phase, if the board has defined a function that does
board setup, and you set the name of that function in the variable
TARGET_SETUP_LINK, it will be executed, before any communication is
attempted with the board.  So you can define this function and set this
variable in your board file, and use it to power on your board, and/or
set up communication channels for the board.

The only documentation reference I could find to this was at:
http://bird.org/fuego/function_pre_test
and it's pretty cursory.

During the post_test phase, there is no similar board-specific function
called.  We are planning on adding one in the 1.2 release.  You can add
one yourself in the meantime.  To do this, in fuego-core/engine/scripts/functions.sh
in the function post_test,  before the end of the function, but after all communication
with the board is complete (logs are downloaded, etc.)  add the following
line:

[ -n "$TARGET_TEARDOWN_LINK" ] && $TARGET_TEARDOWN_LINK

I would put this right before the call to "make_run_file".

Then you can define a function, and in your board file set the
variable TARGET_TEARDOWN_LINK to the name of that function, 
and it will get called prior to test exit.

This system is crude, and would end up power-cycling the board
on every test.  We will be working out a more elegant solution in
the future, but this should get things working for you for now.
> 
> 
> Also default docker is not supporting /dev/serial/* which is elegant way
> how to handle connecting to multiple boards connected to one PC.
> 
> Because what you need to really do is to connect to board via this link
> SERIAL="/dev/serial/by-path/pci-0000:00:1d.0-usb-0:1.7.1.2.4.4:1.0-port0"
> instead of just
> SERIAL="/dev/ttyUSB10"
> which is changing all the time.
> 
> Do you know what to do?
We have a separate "docker-create-container" script for handling ports
that docker needs permission to, and that can change dynamically
on the host at runtime.  It is called
docker-create-usb-privileged-container.sh, and it's in the fuego/fuego-host-scripts
directory.  It makes certain device nodes on the host available inside the target.

I don't have experience with /dev/serial/by-path, but what this script
does is volume-mount certain directories from the host into the container filesystem.
Maybe it would work to add a line like the following to this script:

   -v /dev/serial/by-path:/dev/serial/by-path \

and use that script to create the container.

> I am playing with serial setup and can you please tell me how tests are
> moved from container to target?
> Is there any tree structure expected on the target which should be followed?

Each test moves test material to the target in its test_deploy function.
We strongly suggest that all tests put their materials in the following
location:
$BOARD_TESTDIR/fuego.$TESTDIR
Fuego removes this directory when the test is complete.

BOARD_TESTDIR is defined in the board file, and can be anywhere 
the user would like to configure it. Common places are "/test" and
"/home/test".  I use "/home/a" just to keep the directory name shorter.
$TESTDIR corresponds to the full name of the test: e.g. "Functional.hello_world"

http://bird.org/fuego/function_test_deploy for information about
the test_deploy function.

I hope this is helpful.
 -- Tim



More information about the Fuego mailing list