[U-Boot] test.py and tftp crc32 test?

[Stephen Warren]

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.