All of lore.kernel.org
 help / color / mirror / Atom feed
From: <Tim.Bird@sony.com>
To: pooja.sm@pathpartnertech.com, tbird20d@yahoo.com,
	fuego@lists.linuxfoundation.org
Subject: Re: [Fuego] Regarding ttc configuration
Date: Thu, 7 Jan 2021 00:41:23 +0000	[thread overview]
Message-ID: <BYAPR13MB25035FD365CFE6DFEE011636FDAF0@BYAPR13MB2503.namprd13.prod.outlook.com> (raw)
In-Reply-To: <CAO08rzuZx8q=JK0j8rN-hcXd-CN858aO9qAKJciQems04-tRpw@mail.gmail.com>



> -----Original Message-----
> From: Pooja Sanjay More <pooja.sm@pathpartnertech.com>
> 
> Hi,
> 
> We have installed "ttc" outside the container and configured it for basic commands like console and login. Using ttc commands we are
> able to login into rpi board.
> Also, for rpi hard reboot  "rpireboot.py"  script is assign to "reboot_cmd".
> 
> ttc.conf:
> 
> 
> ipaddr=192.168.3.162
> console_cmd=minicom -D /dev/ttyUSB0 -b 115200
> login_cmd=ssh pi@192.168.3.162 <mailto:pi@192.168.3.162>
> reboot_cmd=~/fuego/fuego-core/scripts/rpireboot.py

Sounds good.  I'm glad to hear it's working outside the container.

I have been thinking about the problem of where to place ttc helper scripts.
I have some problems in my own lab, with some ttc operations working
outside the Fuego container (that is, working when ttc is executed
directly on the host), but not working inside the container.

I have thought about putting ttc helper scripts into /usr/local/bin
(or maybe even a new directory /usr/test/bin), and bind-mounting
that into the Fuego container, so that 'ttc' in the container can use
the same helper scripts as 'ttc' outside the container.   Let me know
if you have any thoughts about this.  The 'labcontrol' project is intended
to provide a web-based rest API for board control, which will make
this situation go away.  However, that project is not quite ready yet,
and raises some issues of its own.

Note that the provisioning test uses the Fuego function 'target_reboot',
which currently only does a software reboot of the system.

However, there is an overlay function for hardware reboot:
ov_board_control_reboot(), which currently calls 'ftc power-cycle'
(which ends up using the BOARD_CONTROL variable in the system
to call either pdudaemon or ttc to perform a hard reboot of the board).

If you have 'ttc reboot' support inside the container, then you should be
able to add:
BOARD_CONTROL="ttc"
to your rpi board file (along with the TTC_TARGET setting),
and then Fuego should have hardware power control of the board.

Once your board settings are correct, and you can do 'ttc reboot' inside
the container, then you should also be able to do 'ftc power-cycle' both
inside and outside the container, to control power to your boards.

I'll try to get the Functional.reboot test working to test the different
reboot options and configurations in Fuego, so you can test your configuration
there.  The board control support was in flux that last time anyone worked on it, so I'm
not sure the state of it.  But I'd like to get it working in your lab.  And once the
design is settled, it all needs to get documented.
  -- Tim

      reply	other threads:[~2021-01-07  0:41 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-06 11:04 [Fuego] Regarding ttc configuration Pooja Sanjay More
2021-01-07  0:41 ` Tim.Bird [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BYAPR13MB25035FD365CFE6DFEE011636FDAF0@BYAPR13MB2503.namprd13.prod.outlook.com \
    --to=tim.bird@sony.com \
    --cc=fuego@lists.linuxfoundation.org \
    --cc=pooja.sm@pathpartnertech.com \
    --cc=tbird20d@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.