From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Tue, 16 Aug 2016 07:14:50 +0200 Subject: [U-Boot] test.py and tftp crc32 test? In-Reply-To: <4b004b3c-b448-eb15-e44f-f7e82a136600@wwwdotorg.org> References: <20160815224940.GC5342@bill-the-cat> <4b004b3c-b448-eb15-e44f-f7e82a136600@wwwdotorg.org> Message-ID: <57B2A14A.7080100@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Stephen, Am 16.08.2016 um 00:59 schrieb Stephen Warren: > 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). I run it on real hw, as I start test.py from tbot on at91, am335x and imx6 based boards ... (Ok, I had to admit that I did not found time since my vacation to look, why my cyclic automated tests with buildbot not work ...) but for an older example: http://xeidos.ddns.net/tests/test_db_auslesen.php#60 (may slow as tbot and this webserver runs on a raspberry pi) and click on "test py result" to see test.py output ... But sorry, yes, I did not run the crc32 tftp tests ... bye, Heiko > 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? > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany