[U-Boot] test/py main_signon
Hi Stephen,
trying to run the latest testing on zynq board and getting this main_signon error.
This is what I am running ./test/py/test.py --bd zynq_zc702 --build --board-identity zc702 and getting below.
Thanks, Michal
U-Boot 2016.03-rc2 (Feb 16 2016 - 13:10:03 +0100)
Model: Zynq ZC702 Development Board Board: Xilinx Zynq I2C: ready DRAM: ECC disabled 1 GiB
Bad pattern found on console: main_signon
FAILED: request = <SubRequest 'u_boot_console' for <Function 'test_version'>>
@pytest.fixture(scope='function') def u_boot_console(request): """Generate the value of a test's u_boot_console fixture.
Args: request: The pytest request.
Returns: The fixture value. """
console.ensure_spawned()
test/py/conftest.py:311: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = <u_boot_console_exec_attach.ConsoleExecAttach object at 0x7f2b33dee8d0>
def ensure_spawned(self): """Ensure a connection to a correctly running U-Boot instance.
This may require spawning a new Sandbox process or resetting target hardware, as defined by the implementation sub-class.
This is an internal function and should not be called directly.
Args: None.
Returns: Nothing. """
if self.p: return try: self.log.start_section('Starting U-Boot') self.at_prompt = False self.p = self.get_spawn() # Real targets can take a long time to scroll large amounts of # text if LCD is enabled. This value may need tweaking in the # future, possibly per-test to be optimal. This works for 'help' # on board 'seaboard'. if not self.config.gdbserver: self.p.timeout = 30000 self.p.logfile_read = self.logstream if self.config.buildconfig.get('config_spl', False) == 'y': m = self.p.expect([pattern_u_boot_spl_signon] + self.bad_patterns) if m != 0: raise Exception('Bad pattern found on console: ' +
self.bad_pattern_ids[m - 1])
E Exception: Bad pattern found on console: main_signon
test/py/u_boot_console_base.py:310: Exception
Hello Michal,
Am 16.02.2016 um 13:12 schrieb Michal Simek:
Hi Stephen,
trying to run the latest testing on zynq board and getting this main_signon error.
This is what I am running ./test/py/test.py --bd zynq_zc702 --build --board-identity zc702 and getting below.
Does this board has SPL support without SPL serial output?
If so, can you try my patch: http://patchwork.ozlabs.org/patch/583348/
Thanks!
bye, Heiko
Thanks, Michal
U-Boot 2016.03-rc2 (Feb 16 2016 - 13:10:03 +0100)
Model: Zynq ZC702 Development Board Board: Xilinx Zynq I2C: ready DRAM: ECC disabled 1 GiB
Bad pattern found on console: main_signon
FAILED: request = <SubRequest 'u_boot_console' for <Function 'test_version'>>
@pytest.fixture(scope='function') def u_boot_console(request): """Generate the value of a test's u_boot_console fixture. Args: request: The pytest request. Returns: The fixture value. """console.ensure_spawned()test/py/conftest.py:311: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = <u_boot_console_exec_attach.ConsoleExecAttach object at 0x7f2b33dee8d0>
def ensure_spawned(self): """Ensure a connection to a correctly running U-Boot instance. This may require spawning a new Sandbox process or resettingtarget hardware, as defined by the implementation sub-class.
This is an internal function and should not be called directly. Args: None. Returns: Nothing. """ if self.p: return try: self.log.start_section('Starting U-Boot') self.at_prompt = False self.p = self.get_spawn() # Real targets can take a long time to scroll large amounts of # text if LCD is enabled. This value may need tweaking in the # future, possibly per-test to be optimal. This works for 'help' # on board 'seaboard'. if not self.config.gdbserver: self.p.timeout = 30000 self.p.logfile_read = self.logstream if self.config.buildconfig.get('config_spl', False) == 'y': m = self.p.expect([pattern_u_boot_spl_signon] +self.bad_patterns) if m != 0: raise Exception('Bad pattern found on console: ' +
self.bad_pattern_ids[m - 1])E Exception: Bad pattern found on console: main_signon
test/py/u_boot_console_base.py:310: Exception
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Hi Heiko,
On 16.2.2016 14:32, Heiko Schocher wrote:
Hello Michal,
Am 16.02.2016 um 13:12 schrieb Michal Simek:
Hi Stephen,
trying to run the latest testing on zynq board and getting this main_signon error.
This is what I am running ./test/py/test.py --bd zynq_zc702 --build --board-identity zc702 and getting below.
Does this board has SPL support without SPL serial output?
I do load u-boot via jtag that's why SPL logs are not visible.
If so, can you try my patch: http://patchwork.ozlabs.org/patch/583348/
I have applied your patch but it is still not working.
If I run full flow with SPL then I can't see any issue.
Thanks, Michal
On 02/16/2016 09:04 AM, Michal Simek wrote:
Hi Heiko,
On 16.2.2016 14:32, Heiko Schocher wrote:
Hello Michal,
Am 16.02.2016 um 13:12 schrieb Michal Simek:
Hi Stephen,
trying to run the latest testing on zynq board and getting this main_signon error.
This is what I am running ./test/py/test.py --bd zynq_zc702 --build --board-identity zc702 and getting below.
Does this board has SPL support without SPL serial output?
I do load u-boot via jtag that's why SPL logs are not visible.
If so, can you try my patch: http://patchwork.ozlabs.org/patch/583348/
I have applied your patch but it is still not working.
If I run full flow with SPL then I can't see any issue.
I assume this is resolved then?
Hi Stephen,
2016-02-16 17:39 GMT+01:00 Stephen Warren swarren@wwwdotorg.org:
On 02/16/2016 09:04 AM, Michal Simek wrote:
Hi Heiko,
On 16.2.2016 14:32, Heiko Schocher wrote:
Hello Michal,
Am 16.02.2016 um 13:12 schrieb Michal Simek:
Hi Stephen,
trying to run the latest testing on zynq board and getting this main_signon error.
This is what I am running ./test/py/test.py --bd zynq_zc702 --build --board-identity zc702 and getting below.
Does this board has SPL support without SPL serial output?
I do load u-boot via jtag that's why SPL logs are not visible.
If so, can you try my patch:
I have applied your patch but it is still not working.
If I run full flow with SPL then I can't see any issue.
I assume this is resolved then?
Unfortunately both cases should work because SPL is not only one first stage bootloader which can be used. I didn't test zynqmp but there is no SPL and the same problem is probably there too. Or is there any dependency that if SPL is not build than testing system is not expecting it?
I will look tmr at jtag boot mode with SPL if I can get it work.
Thanks, Michal
On 02/16/2016 12:08 PM, Michal Simek wrote:
Hi Stephen,
2016-02-16 17:39 GMT+01:00 Stephen Warren <swarren@wwwdotorg.org mailto:swarren@wwwdotorg.org>:
On 02/16/2016 09:04 AM, Michal Simek wrote: Hi Heiko, On 16.2.2016 14:32, Heiko Schocher wrote: Hello Michal, Am 16.02.2016 um 13:12 schrieb Michal Simek: Hi Stephen, trying to run the latest testing on zynq board and getting this main_signon error. This is what I am running ./test/py/test.py --bd zynq_zc702 --build --board-identity zc702 and getting below. Does this board has SPL support without SPL serial output? I do load u-boot via jtag that's why SPL logs are not visible. If so, can you try my patch: http://patchwork.ozlabs.org/patch/583348/ I have applied your patch but it is still not working. If I run full flow with SPL then I can't see any issue. I assume this is resolved then?Unfortunately both cases should work because SPL is not only one first stage bootloader which can be used. I didn't test zynqmp but there is no SPL and the same problem is probably there too. Or is there any dependency that if SPL is not build than testing system is not expecting it?
I will look tmr at jtag boot mode with SPL if I can get it work.
The test scripts currently assume that if SPL is enabled in the U-Boot configuration file, then U-Boot SPL will run and print its signon message to the serial console. If you're starting U-Boot using a technique that invalidates this assumption, it won't work currently, as you found.
It's pretty easy to add a flag in the boardenv file to tell the system not to expect SPL signon. If you take a look at my second suggestion in:
http://lists.denx.de/pipermail/u-boot/2016-February/245759.html [U-Boot] [PATCH] test/py: only check for SPL signature if SPL uses serial output
... then it's probably a simple as adding a third variable into the if condition, where that variable gets looks up from the "board environment", similar to:
spl_skipped = u_boot_console.config.env.get('env__spl_skipped', False)
Hi Stephen,
On 16.2.2016 22:38, Stephen Warren wrote:
On 02/16/2016 12:08 PM, Michal Simek wrote:
Hi Stephen,
2016-02-16 17:39 GMT+01:00 Stephen Warren <swarren@wwwdotorg.org mailto:swarren@wwwdotorg.org>:
On 02/16/2016 09:04 AM, Michal Simek wrote: Hi Heiko, On 16.2.2016 14:32, Heiko Schocher wrote: Hello Michal, Am 16.02.2016 um 13:12 schrieb Michal Simek: Hi Stephen, trying to run the latest testing on zynq board and getting this main_signon error. This is what I am running ./test/py/test.py --bd zynq_zc702 --build --board-identity zc702 and getting below. Does this board has SPL support without SPL serial output? I do load u-boot via jtag that's why SPL logs are not visible. If so, can you try my patch: http://patchwork.ozlabs.org/patch/583348/ I have applied your patch but it is still not working. If I run full flow with SPL then I can't see any issue. I assume this is resolved then?Unfortunately both cases should work because SPL is not only one first stage bootloader which can be used. I didn't test zynqmp but there is no SPL and the same problem is probably there too. Or is there any dependency that if SPL is not build than testing system is not expecting it?
I will look tmr at jtag boot mode with SPL if I can get it work.
The test scripts currently assume that if SPL is enabled in the U-Boot configuration file, then U-Boot SPL will run and print its signon message to the serial console. If you're starting U-Boot using a technique that invalidates this assumption, it won't work currently, as you found.
It's pretty easy to add a flag in the boardenv file to tell the system not to expect SPL signon. If you take a look at my second suggestion in:
http://lists.denx.de/pipermail/u-boot/2016-February/245759.html [U-Boot] [PATCH] test/py: only check for SPL signature if SPL uses serial output
... then it's probably a simple as adding a third variable into the if condition, where that variable gets looks up from the "board environment", similar to:
spl_skipped = u_boot_console.config.env.get('env__spl_skipped', False)
ok. I see. Anyway I have done this change locally and it is working good. Heiko: Are you able to add this one more checking to your patch? Or should I wait till you add your patch to the tree?
Stephen: Do you have your u-boot-test-hooks for qemu?
Thanks, Michal
Hello Michal,
Am 17.02.2016 um 09:42 schrieb Michal Simek:
Hi Stephen,
On 16.2.2016 22:38, Stephen Warren wrote:
On 02/16/2016 12:08 PM, Michal Simek wrote:
Hi Stephen,
2016-02-16 17:39 GMT+01:00 Stephen Warren <swarren@wwwdotorg.org mailto:swarren@wwwdotorg.org>:
On 02/16/2016 09:04 AM, Michal Simek wrote: Hi Heiko, On 16.2.2016 14:32, Heiko Schocher wrote: Hello Michal, Am 16.02.2016 um 13:12 schrieb Michal Simek: Hi Stephen, trying to run the latest testing on zynq board and getting this main_signon error. This is what I am running ./test/py/test.py --bd zynq_zc702 --build --board-identity zc702 and getting below. Does this board has SPL support without SPL serial output? I do load u-boot via jtag that's why SPL logs are not visible. If so, can you try my patch: http://patchwork.ozlabs.org/patch/583348/ I have applied your patch but it is still not working. If I run full flow with SPL then I can't see any issue. I assume this is resolved then?Unfortunately both cases should work because SPL is not only one first stage bootloader which can be used. I didn't test zynqmp but there is no SPL and the same problem is probably there too. Or is there any dependency that if SPL is not build than testing system is not expecting it?
I will look tmr at jtag boot mode with SPL if I can get it work.
The test scripts currently assume that if SPL is enabled in the U-Boot configuration file, then U-Boot SPL will run and print its signon message to the serial console. If you're starting U-Boot using a technique that invalidates this assumption, it won't work currently, as you found.
It's pretty easy to add a flag in the boardenv file to tell the system not to expect SPL signon. If you take a look at my second suggestion in:
http://lists.denx.de/pipermail/u-boot/2016-February/245759.html [U-Boot] [PATCH] test/py: only check for SPL signature if SPL uses serial output
... then it's probably a simple as adding a third variable into the if condition, where that variable gets looks up from the "board environment", similar to:
spl_skipped = u_boot_console.config.env.get('env__spl_skipped', False)
ok. I see. Anyway I have done this change locally and it is working good. Heiko: Are you able to add this one more checking to your patch? Or should I wait till you add your patch to the tree?
I just posted a v2 of my patch ... I vote, that you send your patch based on mine to the ML.
bye, Heiko
Stephen: Do you have your u-boot-test-hooks for qemu?
Thanks, Michal
On 02/17/2016 01:42 AM, Michal Simek wrote: ...
Stephen: Do you have your u-boot-test-hooks for qemu?
I only have some local hacks that aren't at all generic. They're on my laptop at home so I can't share them right now, but I can describe them from memory:
u-boot-test-flash: Does nothing
u-boot-test-reset: Does nothing (I assume the test/py code will kill and restart the u-boot-test-console process each time it executes u-boot-test-reset).
u-boot-test-console: exec()s qemu with whatever target-specific options are required to make it execute the appropriate U-Boot binary as firmware (rather than the more common option of booting a Linux kernel for example), and with the emulated serial port connected to qemu's stdin/stdout. Something like:
exec qemu-system-arm -M raspi2 -serial stdio -fw /path/to/u-boot.bin ...
I had considered a new u_boot_console_qemu to standardize this a bit more. I'm not sure how useful this is since the user will still need to provide some configuration e.g. where the qemu binary is located, if there's a disk image to use for the emulated SD card, whether their system can support emulated Ethernet in qemu, etc. So, they may as well use u_boot_console_exec_attach, and implement the same hook scripts as any other system.
I had also wondered about updating .travis.yml to test via qemu too. Maybe that's better done by an external test system though.
Hello Michal,
Am 16.02.2016 um 17:04 schrieb Michal Simek:
Hi Heiko,
On 16.2.2016 14:32, Heiko Schocher wrote:
Hello Michal,
Am 16.02.2016 um 13:12 schrieb Michal Simek:
Hi Stephen,
trying to run the latest testing on zynq board and getting this main_signon error.
This is what I am running ./test/py/test.py --bd zynq_zc702 --build --board-identity zc702 and getting below.
Does this board has SPL support without SPL serial output?
I do load u-boot via jtag that's why SPL logs are not visible.
If so, can you try my patch: http://patchwork.ozlabs.org/patch/583348/
I have applied your patch but it is still not working.
If I run full flow with SPL then I can't see any issue.
I am not an expert of test/py (I still try to dig into it), but as I understand it, it looks if CONFIG_SPL is defined, if so, the framework expects a SPL output first, if not found, it raises the error you see ...
My patch fixes this, for boards which use SPL, but without serial SPL output ...
Now you test only u-boot with SPL configured with SPL serial output ...
I think Stephen can say here more, how to solve this ...
bye, Heiko
Hi Heiko,
On 17.2.2016 07:34, Heiko Schocher wrote:
Hello Michal,
Am 16.02.2016 um 17:04 schrieb Michal Simek:
Hi Heiko,
On 16.2.2016 14:32, Heiko Schocher wrote:
Hello Michal,
Am 16.02.2016 um 13:12 schrieb Michal Simek:
Hi Stephen,
trying to run the latest testing on zynq board and getting this main_signon error.
This is what I am running ./test/py/test.py --bd zynq_zc702 --build --board-identity zc702 and getting below.
Does this board has SPL support without SPL serial output?
I do load u-boot via jtag that's why SPL logs are not visible.
If so, can you try my patch: http://patchwork.ozlabs.org/patch/583348/
I have applied your patch but it is still not working.
If I run full flow with SPL then I can't see any issue.
I am not an expert of test/py (I still try to dig into it), but as I understand it, it looks if CONFIG_SPL is defined, if so, the framework expects a SPL output first, if not found, it raises the error you see ...
My patch fixes this, for boards which use SPL, but without serial SPL output ...
Now you test only u-boot with SPL configured with SPL serial output ...
I think Stephen can say here more, how to solve this ...
Ok. I have spent some time on this. Your patch is covering a little bit different case than I have. We have in general two used cases. One is to use SPL as first stage bootloader and then private full featured FSBL. Both of them works with the same u-boot image. It means I can build uboot with SPL and run two test sets. One with SPL which is working fine and the second without but there is no reason to rebuild u-boot without SPL just to pass testing. It means the feature I am looking for is more about ignoring SPL signon instead of supporting cases where SPL doesn't print anything.
Thanks, Michal
participants (4)
-
Heiko Schocher -
Michal Simek -
Michal Simek -
Stephen Warren