Comment 9 for bug 872833

First analyze:

Hardware & Sofware:
-----------------------------
Snowball: V5 & V11
PRCMU firmware v3.4.0 & v3.4.3
Kernel: stable-*-ux500-3.0 on Igloo Kernel

The kernel trace:
-----------------------
reboot calls machine_restart()->ux500_restart()->prcmu_system_reset()->db8500_prcmu_system_reset()
which finally call write (1, PRCM_APE_SOFRST) then the kernel freeze here and wait infinitely that PRCMU issue a sofware reset.
On HREF board (PRCMU v3.4.0) with same kernel this sequence reboot at 100% the board.
On my Snowball v5 (PRCMU v3.4.0), this never works but sometime with my SB V11 (PRCMU v3.4.3, same kernel or old 2.6.38) it works but this is not 100% reproductible.

This is a strange behavior and I don't think that it's a kernel problem, but more probably a PRCMU timing reset sequence problem specific to Snowball hardware.

To go further, I need to have a look in PRCMU firmware, analyse the timing reset sequence (needs to look at the schematic to find the right pins) and PRCMU STM trace .... This isn't simple.
Other questions I have:
Is PRCMU firmware Snowball specific and where are the sources?
Even, if I can find PRCMU source and rebuild it how can I reflash it into SB?
...