test/py main_signon

U-Boot Michal Simek 4 participants 11 messages Feb 16, 2016 – Feb 17, 2016

lore

Share & tools

lore

Michal Simek

author

2016-02-16 12:12 UTC #0 lore raw

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.
"""

Quoted 1 line

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: ' +

Quoted 1 line

                                  self.bad_pattern_ids[m - 1])

E Exception: Bad pattern found on
console: main_signon

test/py/u_boot_console_base.py:310: Exception

Heiko Schocher

2016-02-16 13:32 UTC #1 lore raw

Hello Michal,

Am 16.02.2016 um 13:12 schrieb Michal Simek:

Quoted 8 lines

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

Quoted 81 lines

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.
"""
Quoted 1 line
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: ' +
Quoted 1 line
                                   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 at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Signature · 2 lines

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Michal Simek

author

2016-02-16 16:04 UTC #2 lore raw

Hi Heiko,

Quoted 5 lines · Heiko Schocher

Hello Michal,
Am 16.02.2016 um 13:12 schrieb Michal Simek:
Quoted 2 lines
Hi Stephen,

Quoted 8 lines

Quoted 6 lines
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.

Quoted 2 lines

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

Stephen Warren

2016-02-16 16:39 UTC #3 lore raw

Quoted 17 lines · Michal Simek

Hi Heiko,
Quoted 5 lines · Heiko Schocher
Hello Michal,
Am 16.02.2016 um 13:12 schrieb Michal Simek:
Quoted 2 lines
Hi Stephen,
Quoted 8 lines
Quoted 6 lines
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?

Quoted 8 lines

I do load u-boot via jtag that's why SPL logs are not visible.
Quoted 2 lines
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?

Michal Simek

2016-02-16 19:08 UTC #4 lore raw

Hi Stephen,

2016-02-16 17:39 GMT+01:00 Stephen Warren <[email protected]>:

Quoted 29 lines · Michal Simek

Quoted 28 lines
Hi Heiko,
Quoted 9 lines · Heiko Schocher
Hello Michal,
Am 16.02.2016 um 13:12 schrieb Michal Simek:
Quoted 5 lines
Hi Stephen,
trying to run the latest testing on zynq board and getting this main_signon error.
Quoted 7 lines
Quoted 4 lines
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:
Quoted 2 lines
http://patchwork.ozlabs.org/patch/583348/

Quoted 7 lines

Quoted 4 lines
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

Signature · 5 lines

Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform

Stephen Warren

2016-02-16 21:38 UTC #5 lore raw

Quoted 52 lines · Michal Simek

Hi Stephen,
2016-02-16 17:39 GMT+01:00 Stephen Warren <[email protected] <mailto:[email protected]>>:
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?

Quoted 1 line

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)

Michal Simek

2016-02-17 08:42 UTC #6 lore raw

Hi Stephen,

Quoted 68 lines · Stephen Warren

Quoted 52 lines · Michal Simek
Hi Stephen,
2016-02-16 17:39 GMT+01:00 Stephen Warren <[email protected] <mailto:[email protected]>>:
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?
Quoted 1 line
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

Quoted 5 lines

... 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

Signature · 14 lines

Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160217/e7c4d476/attachment.sig>

Heiko Schocher

2016-02-17 09:05 UTC #7 lore raw

Hello Michal,

Am 17.02.2016 um 09:42 schrieb Michal Simek:

Quoted 75 lines

Hi Stephen,
Quoted 72 lines · Stephen Warren
Quoted 52 lines · Michal Simek
Hi Stephen,
2016-02-16 17:39 GMT+01:00 Stephen Warren <[email protected] <mailto:[email protected]>>:
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?
Quoted 1 line
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:

Quoted 5 lines

Quoted 1 line
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

Quoted 6 lines

Stephen: Do you have your u-boot-test-hooks for qemu?
Thanks,
Michal

Signature · 2 lines

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Stephen Warren

2016-02-17 18:38 UTC #8 lore raw

In reply to Michal Simek

On 02/17/2016 01:42 AM, Michal Simek wrote:
...

Quoted 1 line

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.

Heiko Schocher

2016-02-17 06:34 UTC #9 lore raw

In reply to Michal Simek

Hello Michal,

Am 16.02.2016 um 17:04 schrieb Michal Simek:

Quoted 17 lines

Hi Heiko,
Quoted 5 lines · Heiko Schocher
Hello Michal,
Am 16.02.2016 um 13:12 schrieb Michal Simek:
Quoted 2 lines
Hi Stephen,
Quoted 8 lines
Quoted 6 lines
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?

Quoted 8 lines

I do load u-boot via jtag that's why SPL logs are not visible.
Quoted 2 lines
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

Signature · 2 lines

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Michal Simek

author

2016-02-17 07:24 UTC #10 lore raw

Hi Heiko,

Quoted 34 lines · Heiko Schocher

Hello Michal,
Am 16.02.2016 um 17:04 schrieb Michal Simek:
Quoted 17 lines
Hi Heiko,
Quoted 5 lines · Heiko Schocher
Hello Michal,
Am 16.02.2016 um 13:12 schrieb Michal Simek:
Quoted 2 lines
Hi Stephen,
Quoted 8 lines
Quoted 6 lines
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?
Quoted 8 lines
I do load u-boot via jtag that's why SPL logs are not visible.
Quoted 2 lines
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 ...

Quoted 6 lines

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