On 08/15/2016 05:20 PM, Tom Rini wrote:
On Mon, Aug 15, 2016 at 04:59:02PM -0600, Stephen Warren wrote:
On 08/15/2016 04:49 PM, Tom Rini wrote:
Hey guys,
Is anyone else running the crc32 tftp tests with test.py? I'm trying to
do it locally but even with a 2MiB file it looks like somehow the crc32
is never captured in the output. I've already made sure that the crc32
value is in lowercase to match the U-Boot output and running the test
steps in console gives me the expected output. And the rest of the
network tests pass, any ideas? Thanks!
I'm not certain that anyone other than myself is running test.py on
real HW (vs. sandbox where it's trivial).
If you look at test-log.html it should show what U-Boot outputs on
the console, and where any error was detected in the test.
Alternativeluy, add "-s" to the invocation and U-Boot output should
show up on stdout while the tests are running. What's the error
reported there; just a timeout waiting for the CRC? Here's an
example of what test_net_tftpboot looks like for me:
Tegra210 (P2371-2180) # tftpboot 80000000 ubtest-readable.bin
Using eth_rtl8169 device
TFTP from server 10.20.204.51; our IP address is 10.20.204.52
Filename 'ubtest-readable.bin'.
Load address: 0x80000000
Loading: *%08#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
####################
2.9 MiB/s
done
Bytes transferred = 5058624 (4d3040 hex)
Tegra210 (P2371-2180) # crc32 80000000 $filesize
crc32 for 80000000 ... 804d303f ==> c2244b26
Tegra210 (P2371-2180) #
In the past, I have seen tests pass when run manually but not under
test.py, e.g. due to heap fragmentation, state, or corrupted memory
due to earlier tests, which weren't run in the manual case. Might
that be the issue?
Adding in -s this is part of what I see:
=> .s=> ping $serverip
Waiting for Ethernet connection... done.
Using sms0 device
host 192.168.0.3 is alive
=> .=> tftpboot 80000000 1MiBtest.bin
Waiting for Ethernet connection... done.
Using sms0 device
TFTP from server 192.168.0.3; our IP address is 192.168.0.140
Filename '1MiBtest.bin'.
Load address: 0x80000000
Loading: #################################################################
#################################################################
#################################################################
##########
171.9 KiB/s
done
Bytes transferred = 1048576 (100000 hex)
=> crc32 80000000 $filesize
CRC32 for 80000000 ... 800fffff ==> F2fa737e0
=>
For some reason there's an extra 'F' at the start of the crc32 output.
Looking at it in the html file, it looks all correct there. In the
output from test.py the captured stdout end just before the CRC32 value
would be. I've tried larger test binaries and get the same output so
I'd assume if there was some heap corruption or similar, I'd not tickle
it with bigger files too (2MiB, 4MiB and I think even 8MiB are small
enough to be downloaded in the time the test allows). Thanks!
The "F" is coming from the test infrastructure, not U-Boot's output. A
character is printed per test, such as "." for pass, "s" for skip, and
"F" for fail. For some reason, the test is seeing a failure before it's
read the output from the crc32 command.
Ah, I see the issue now: the command prompt (=>) in use is part of the
output from the crc32 command, so the test infra-structure thinks the
==> printed by crc32 is the end of the crc32 output. Perhaps test.py
should look for "[\r\n]${prompt}" rather than "${prompt}", or this board
could have a prompt that's slightly less likely to trigger false matches.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
