On 08/06/2017 10:10 AM, Rob Clark wrote:
Signed-off-by: Rob Clark <robdcl...@gmail.com>
---
Kinda works, but since we don't have an 'exit' command like grub, we
have to reboot, which leaves the "board" in a bad state (I guess,
since the next test fails). I haven't tackled the travis bits to get
travis to download OpenBSD's bootloader, or other little details like
that.
+ # There is no exit, but there is a reboot cmd.. maybe we need to do
+ # more than this to get u-boot running again??
+ u_boot_console.run_command('reboot', wait_for_prompt=False,
wait_for_echo=False)
Assuming that 'reboot' works here, and actually resets the system, it'll
probably end up booting whatever code is in flash/storage, which isn't
necessarily the version of U-Boot that's being tested; the version under
test may not be in flash, but might be downloaded at boot time e.g. over
serial/USB to avoid flash wear. So yes, this test certainly needs to do
something different to restart U-Boot if the test can't simply exit back
to the previous running instance.
There's a core test/py function cons.restart_uboot() that should do
everything required to restart the target system. test/test_vboot.py
already uses it, in particular at the tail end of test_with_algo() in
order to return the target back to the expected state that the next test
expects.
I also recall writing down some ideas about how to add Linux-booting
testing into U-Boot, along with actually running some tests in Linux
mode to validate the boot without having to manually code up all the
command-line request/response logic. That was in an email to the U-Boot
list, perhaps during a conversation with Heiko. However, Google can't
find it right now:-( Still, I don't think it would improve things for
the test you're proposing right now since it's so simple, and it was
mostly just thinking about how to do it rather than actual code anyway.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
