Re: [Fuego] Board setup

[Michal Simek <monstr@monstr.eu>]

[-- Attachment #1.1: Type: text/plain, Size: 5914 bytes --]

On 11.4.2017 20:25, Bird, Timothy wrote:
>> -----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's the schedule for 1.2? I see you have tagged 1.1.1 some hours ago.

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

This is working fine. Thanks for pointers. In bigger boardfarm it will
take take time to ask for a board and get an access to it.


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

This is working but the problem is with sercp which reports
ERROR: Port must be configured before it can be used.

sersh is fine with this serial setup

SERIAL="/dev/serial/by-path/pci-0000:00:1d.0-usb-0:1.7.1.2.4.4:1.0-port0"

Both are pointing to the same file that's why I expect that issue is there.

In serio.git there is
9daaf498e0fc4a086fd50e32c2edd3d7410d47ae

You have this in commit message.
    You can _not_ use /dev/ttyACM0 for host1 and host2 because the '/'
    before a ':' is how scp determines that you are trying to copy
    a file with a ':' in the name instead of specifying a host name.

Frank: Can you please comment?


>> 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 found that stuff a little bit later that serio is that magic serial
tool which is doing sersh or sercp and copy that stuff over serial line.

It will be worth to separate load channel from command channel. The
reason is simple suspend tests which I am playing with.
It is not a problem to move files to target via ethernet/wifi but if you
want to test wakeup from uart you need to have this channel setup.


Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]