Caesar,OK, it should delay more time.
On Sat, Jun 6, 2015 at 7:51 PM, Caesar Wang <wxt@xxxxxxxxxxxxxx> wrote:
@@ -150,13 +159,15 @@ static int __cpuinit rockchip_boot_secondary(unsignedOK, I'm OK with this, but I'd like to get Heiko's opinion.
int cpu,
* sram_base_addr + 4: 0xdeadbeaf
* sram_base_addr + 8: start address for pc
* */
- udelay(10);
+ udelay(20);
I increased the 'udelay(20)' or 'udelay(50)' in rockchip_boot_secondary().
Set#2 also can repro this issue over 22600 cycles with testing scripts.
(about 1 hours)
log:
================= 226 ============
[ 4069.134419] CPU1: shutdown
[ 4069.164431] CPU2: shutdown
[ 4069.204475] CPU3: shutdown
......
[ 4072.454453] CPU1: shutdown
[ 4072.504436] CPU2: shutdown
[ 4072.554426] CPU3: shutdown
[ 4072.577827] CPU1: Booted secondary processor
[ 4072.582611] CPU2: Booted secondary processor
[ 4072.587426] CPU3: Booted secondary processor
<hang>
The set #4 will be better work.
Also:
* Just for kicks, does mdelay(1) work? I know that's 100x more than
udelay(10), but previously we were actually looping waiting for the
power domain, right? ...so maybe the old code used to introduce a
pretty big delay.
* Does anyone from the chip design team have any idea why patch set #4
works but patch set #2 doesn't? I know it's Sunday morning in China
right now, but maybe you could ask Monday?
Thanks!
-Doug