1
0
mirror of git://projects.qi-hardware.com/wernermisc.git synced 2024-11-15 17:15:20 +02:00
wernermisc/m1rc3/norruption
2011-09-08 19:07:18 -03:00
..
LOG m1rc3/norruption/: next round of tests, just resetting without power-cycling 2011-09-08 19:07:18 -03:00
loop moved m1/torture/ to more specific m1rc3/norruption/ 2011-09-07 04:23:32 -03:00
loop2 m1rc3/norruption/loop2: shorter loop (17 s instead of 77 s) that cycles in RTEMS boot, without rendering 2011-09-07 05:12:03 -03:00
loop4 m1rc3/norruption/: next round of tests, just resetting without power-cycling 2011-09-08 19:07:18 -03:00
README m1rc3/norruption/: next round of tests, just resetting without power-cycling 2011-09-08 19:07:18 -03:00

power-cycling torture test, to see if booting into FN and then
power-cycling causes NOR corruption.

You need:
- an M1 with JTAG board
- a Lab Switch (../../labsw) to control power to the M1
- a USB connection to the Lab Switch
- the Lab Switch control tool "labsw" installed
- a USB connection to the JTAG board
- UrJTAG installed, see
  http://milkymist.org/wiki/index.php?title=Flashing_the_Milkymist_One#compile_urjtag
- neocon from http://svn.openmoko.org/developers/werner/neocon/
  (or any other program to monitor and log an outbound serial line)

Run
neocon -a -l log -T /dev/ttyUSB0

Then
./loop

This will:
- power-cycle the M1, leaving it powered off for 5 seconds
- give it two seconds to power on
- boot the "regular" bitstream, i.e., Flickernoise
- wait 70 seconds for Flickernoise to start and to render the
  "The Tunnel" for a few seconds
- repeat this forever

The log file records the console output from the M1, plus time
stamps and cycle numbers written from the "loop" script.

Update: there's another test, loop2, which performs a shorter loop,
which still produces corruption.

Update: loop4 does the same as loop2, but uses "pld reconfigure" instead
of power-cycling. Since loop2 was used for a test run #2 (NOR unlocked)
and a test run #3 (first 55 pages of NOR locked), there is no loop3
script.