uboot_testpy: POWERON and POWEROFF in the wrong sequence about tbot

[Rahix]

Hi,

first of all, I think a space in your board name is not something I properly care for here. Not sure what problems this will cause (if any), but to be safe I'd replace that with a '-'.

Target uboot_testpy powers the board on before collecting the unit tests and powers it off before executing the unit tests. Obviously this leads to failures in all tests.

Powering on before starting test/py is expected. Then, after test/py has collected all testcases, it will issue a board reset. That's why the board is powered off again at the beginning of tests. If everything works, tbot will first call your poweroff() method and then poweron(). What is weird is that only the first command from your poweron() method is sent.

Digging into your lab-config, I see

    def build(self):
        tbot.log.message(tbot.log.c("Message").yellow.bold + ": MyLabHost.build")
        return self

Try making that a

    def build(self):
        tbot.log.message(tbot.log.c("Message").yellow.bold + ": MyLabHost.build")
        return self.clone()

The problem here is that uboot_testpy expects to have separate connections to lab-host and build-host but you gave it the same for both. So it's trying to execute the power commands on the same session where test/py is currently running! I thought, I had built in checks to catch that but apparently something slipped through ... I'll see how I can protect against this mistake.

Files u-boot-test-console u-boot-test-flash u-boot-test-quit u-boot-test-reset are missing.

Those are in /tmp/tbot-workdir/uboot-testpy-tbot if you're curious.

[Rahix]

Pushed commit 39f21f0 ("test/py: Issue a warning for incorrectly configured lab-hosts") which will warn about and attempt to fix such configurations.

[xypron]

@Rahix
Thank you for reviewing my code. With the suggested changes is works as expected.

Adding the following information to the online documentation would have helped me:

• description of the build() and enable() methods of a Lab instance detailing how they work
• how to setup a a build host that is not the lab host
• how to use DistroToolchain(). I never got it to use the cross-compiler for the board.

Best regards

Heinrich

[Rahix]

Thanks for the feedback, I really appreciate it!

description of the build() and enable() methods of a Lab instance detailing how they work

Yeah, the docs about this could really use some touch up, I agree. I've been holding off from that because I don't like the current implementation (especially of build()) very much and I am in the process of overhauling that to make it easier and more flexible.

how to setup a a build host that is not the lab host

Wow, the docs actually don't show any example of this ... I'll add one but in the mean time, I hope this helps:

class SomeBuildHost(connector.SSHConnector, linux.Bash, linux.Builder):
    hostname = "some-build-host.example.com"

    @property
    def toolchains(self):
        ...

class SomeLabHost(..., linux.Lab):
    def build(self):
        SomeBuildHost(self)

and later, you can copy files back to the labhost in a testcase like this:

from tbot.tc import shell

...

target = lh.workdir / "some-file"
with lh.build() as bh:
    source = bh.workdir / "some-file"

    shell.copy(source, target)

how to use DistroToolchain(). I never got it to use the cross-compiler for the board.

Hmm, doing this in your labconfig doesn't work?

    @property
    def toolchains(self) -> typing.Dict[str, linux.build.Toolchain]:
        """ Define Toolchains
        """
        return {
            "arm": linux.build.DistroToolchain("arm", "arm-linux-gnueabihf-"),
            "arm64": linux.build.DistroToolchain("arm64", "aarch64-linux-gnu-"),
            "riscv": linux.build.DistroToolchain("riscv", "riscv64-linux-gnu-"),
        }

[xypron]

@Rahix
I just rechecked DistroToolchain. It is usable. Probably in my early experiments I had something wrong in introducing the toolchain.