Comment 9 for bug 894828

After many efforts, I succeded to setup my STM trace environment on Snowball with JTAG Lauterbach combiprobe
and took traces after issue a reboot command in console.

One file contains PRCMU trace see trace-PRCMU-reboot-pb.log (in the attached .tar.bz2):
we saw at end the RESET command send by linux kernel: IT6_A9WD_SFTRST_IN & SOFT_RESET_ACTIVE,
after only a specialist can tell if it's OK.

The second file Trace_PRCMU_reboot+ftrace.log (in the attached .tar.bz2) contains a STM capture trace with console+PRCMU+ftrace function interleaved.
How to read this trace:
"ssssss.nnnnnnnnn" is the STM timestamp seconds.nanoseconds
lines begin with [ssssss.nnnnnnnnn 5:00]* ===> PRCMU traces: example "[000113.337969740 5:00]IT6_A9WD_SFTRST_IN"
lines begin with [ssssss.nnnnnnnnn 0:00]<d>string ===> Linux console printk: example " [000113.337983960 0:00]<0>db8500_prcmu_system_reset after writel(1, PRCM_APE_SOFTRST)"
lines begin with [ssssss.nnnnnnnnn 0:00]function <-caller ===> ftrace function traces: example "[000113.315268900 0:00]ux500_restart <-machine_restart+0x58"

I can't do more software traces, the second stage is to analyse in parallel the reset pin behavior with an analyzer.
But before to go further, I wait a Robert Marklund workaround patch based on the usage of a Watchdog (PRCMU or AB).

Remark:
Often, I noticed also that the reset button has no effect on Snowball board, is it an already known hardware problem?