[U-Boot] Sharing a hardware lab
Harald Seiler
hws at denx.de
Mon Mar 23 11:30:02 CET 2020
Hello Simon,
On Sun, 2020-03-22 at 12:42 -0600, Simon Glass wrote:
> Hi Harald,
>
> On Sun, 22 Mar 2020 at 03:56, Harald Seiler <hws at denx.de> wrote:
> > Hi Simon,
> >
> > On Sat, 2020-03-21 at 13:07 -0600, Simon Glass wrote:
[...]
> >
> > Huh, actually I messed up in the patch I sent you. Please apply the following
> > diff:
> >
> > diff --git a/kea.py b/kea.py
> > index a3ca968dc41e..f65d91b67f1d 100644
> > --- a/kea.py
> > +++ b/kea.py
> > @@ -39,7 +39,7 @@ class KeaLab(
> > # toolchain is identified by a (unique) string. For pcduino3 in this
> > # example, a toolchain named `armv7-a` is defined.
> > return {
> > - "armv7-a": ArmV7Toolchain,
> > + "armv7-a": ArmV7Toolchain(),
> > }
> >
> > def build(self):
> >
> > This will make everything work as intended and the patch you needed in tbot is
> > also no longer necessary (Passing a class instead of an instance will not
> > bind the method's `self` argument so you got an error from a weird place.
> > Maybe I should add a check against this kind of mistake ...).
>
> OK that fixes it, thanks.
>
> Actually I can call 'buildman -A <board>' to get the toolchain prefix
> for a board, so perhaps I should figure out how to work that in
> somehow, and just have a generic toolchain problem,
That's not too difficult, actually. I suggest creating a generic UBootBuilder
class from which your individual board's builders inherit:
import abc
import contextlib
class BuildmanUBootBuilder(uboot.UBootBuilder):
@abc.abstractmethod
@property
def buildman_board(self) -> str:
raise Exception("abstract method")
# Overload `do_toolchain` to customize toolchain behavior
@contextlib.contextmanager
def do_toolchain(self, bh):
prefix = bh.exec0("buildman", "-A", self.buildman_board)
with bh.subshell():
# Setup toolchain here
bh.env("ARCH", "arm")
yield None
# and for each board
class MyBoardUBootBuilder(BuildmanUBootBuilder):
buildman_board = "tegra"
I have never used buildman myself so I am not really sure about the
details of what needs to be done here ... But if this would be a useful
feature I could look into supporting it directly in the UBootBuilder
class.
> > > So my next question is how to load U-Boot onto the board. I can see
> > > methods for poweron/poweroff but not for actually writing to the
> > > board. Is there a built-in structure for this? I cannot find it.
> > >
> > > I am hoping that the Pcduino3 class can define a method like
> > > 'load_uboot()' to write U-Boot to the board?
> >
> > I added something similar to this in our DENX internal tbot configurations but
> > did not yet publish it anywhere (maybe I should add it to tbot_contrib?). Just
> > for you, here is what I did:
>
> To me this should be a core feature, not contrib.
I guess the split of what belongs where is not yet clearly defined and I still
need to work on separating the different components better. For me, core is
just the code for interacting with machines; anything that looks like
a testcase should be separate from that. Right now I've got tbot_contrib for
this but I guess the naming might not be optimal ...
By the way, are you subscribed to tbot at lists.denx.de? I'll be posting updates
regarding this (and other things) over there.
> I wonder if there is an upstream for tbot labs? I think it would be
> useful to have a directory containing people's labs like we do for
> pytest. Then we can end up with common functions for doing things.
Maybe it makes sense to add a place in upstream tbot for these as well.
Thanks for the idea!
> > 1. In the board configs, each U-Boot class defines a `flash()` method:
> >
> > from tbot.tc import shell, git
> >
> > class P2020RdbUBoot(board.Connector, board.UBootShell):
> > name = "p2020rdb-uboot"
> > prompt = "=> "
> > build = P2020RdbUBootBuilder()
> >
> > def flash(self, repo: git.GitRepository) -> None:
> > self.env("autoload", "no")
> > self.exec0("dhcp")
> > self.env("serverip", "192.168.1.1")
> >
> > tftpdir = self.host.fsroot / "tftpboot" / "p2020rdb" / "tbot2"
> > if not tftpdir.is_dir():
> > self.host.exec0("mkdir", "-p", tftpdir)
> >
> > name = "u-boot-with-spl.bin"
> > tbot.log.message(f"Fetching {name} ...")
> > shell.copy(repo / name, tftpdir / name)
> >
> > addr = 0x10000000
> > self.exec0("tftp", hex(addr), "p2020rdb/tbot2/" + name)
> > size = int(self.env("filesize"), 16)
> > tbot.log.message(f"Downoad succeeded:\n U-Boot: {size} bytes")
> >
> > tbot.log.message("Flashing ...")
> > self.exec0("nand", "device", "0")
> > self.exec0("nand", "erase.spread", "0", hex(size))
> > self.exec0("nand", "write", hex(addr), "0", hex(size))
> >
> > As you can see, it get the repository (as a GitRepository [1]) where
> > U-Boot was built, passed as an argument, and copies the relevant
> > binaries to a tftp directory on the lab-host (using shell.copy() [2]).
> > Then it downloads and flashes U-Boot like you would manually.
> >
> > Alternatively, I could imagine the implementation connecting to
> > a hardware debugger and uploading the binary to flash that way.
>
> Thanks very much. That explained it for me. I tried this out and ended
> up moving it to the board class instead of the U-Boot class, since I
> don't know what state the board is in. I just want to turn it off and
> program it.
During `flash()` (in my implementation), the board is powered on and waiting
for commands at the U-Boot prompt. I know this won't work for the case where
U-Boot is failing to boot. Alternatively, I could change it so the
implementation decides on its own whether it needs U-Boot running. E.g.:
class MyBoardUBoot(board.Connector, board.UBootShell):
@classmethod
def flash(cls, board: board.Board, repo: git.GitRepository):
# Board is powered on. An implementation using a debugger could
# now flash U-Boot.
with board.host.run("arm-linux-gnu-gdb", elf) as gdb:
gdb.read_until_prompt("(gdb) ")
gdb.sendline("target remote localhost:3333")
gdb.read_until_prompt("(gdb) ")
gdb.sendline("load")
gdb.read_until_prompt("(gdb) ")
gdb.sendline("quit")
gdb.terminate0()
# An implementation like mine above initializes the UBoot machine
# and then continues like before:
with cls(board) as ub:
ub.exec0("dhcp")
ub.exec0("nand", "update", ...)
Hope this makes sense ...
> I think a lot of my confusion is all the classes and inheritance and
> things like selectable.py where objects are updated outside the
> module. Plus all the decorators, getattr/setattr...
Ideally I'd want all that to stay hidden from the user. I know that right
now I have not really archieved that and the code is really messy in some
places because of it.
I'd love some feedback on the things that aren't explained well in the
documentation or places where features are lacking and you needed to dig
into the internals.
> > 2. I defined a few testcases for flashing. Namely, `uboot_build_and_flash`
> > (build U-Boot and then flash the new version) and `uboot_bare_flash` (don't
> > rebuild, just flash the artifacts from the last build). These then use the
> > board-specific U-Boot builder and flash method.
> >
> > I also added a feature where you can specify `-fsafe` on the tbot
> > command-line. This will, in case something goes wrong while flashing,
> > drop you onto the interactive U-Boot command-line instead of powering
> > off the board and reporting a failure.
> >
> > I uploaded the testcases here:
> >
> > https://gitlab.denx.de/snippets/10
>
> OK thanks. I am slowly getting the hang of it.
>
> My current problem is how to execute Python code on the host (the
> machine that has the hardware attached). I end up having to call
> host.exec() but it if I want to open a file and modify it, I cannot do
> that easily remotely. Is it possible to run a tbot function on the lab
> machine?
The idea is that you shouldn't ever need to run Python code on the
lab-host (so we don't have to make assumptions about the environment of
the lab-host). What things do you need to do that can't be done right now?
I'd argue that tbot should provide API to do them without manual (Python)
scripting on the lab-host.
For accessing files in particular, I just added some methods
(`read_text()` [1], `write_text()` [2], `read_bytes()` [3], and
`write_bytes` [4]) a few days ago. Maybe they can help?
[1]: http://tbot.tools/modules/machine_linux.html#tbot.machine.linux.Path.read_text
[2]: http://tbot.tools/modules/machine_linux.html#tbot.machine.linux.Path.write_text
[3]: http://tbot.tools/modules/machine_linux.html#tbot.machine.linux.Path.read_bytes
[4]: http://tbot.tools/modules/machine_linux.html#tbot.machine.linux.Path.write_bytes
--
Harald
More information about the U-Boot
mailing list