Fixed
Created: Oct 27, 2014
Updated: Dec 3, 2018
Resolved Date: Nov 6, 2014
Found In Version: 6.0
Fix Version: 6.0.0.14
Severity: Standard
Applicable for: Wind River Linux 6
Component/s: Userspace
When activating the secondary thread, it sometimes reaches
take_timebase before cur_booting_core is set to correct value.
t4240.cpu[0][0]: wrote cur_booting_core 14 new value:0xe
t4240.cpu[7][0]: enters mpc85xx_take_timebase 14
t4240.cpu[0][0]: enters mpc85xx_give_timebase 14
t4240.cpu[0][0]: wrote tb_valid 13 new value:0x1
t4240.cpu[7][0]: wrote tb_valid 14 new value:0x0
t4240.cpu[0][0]: wrote cur_booting_core 15 new value:0xf
t4240.cpu[7][1]: enters mpc85xx_take_timebase 15
t4240.cpu[0][0]: enters mpc85xx_give_timebase 15
t4240.cpu[0][0]: wrote cur_booting_core 16 new value:0x10
t4240.cpu[8][0]: enters mpc85xx_take_timebase 16
t4240.cpu[0][0]: enters mpc85xx_give_timebase 16
t4240.cpu[0][0]: wrote tb_valid 15 new value:0x1
t4240.cpu[8][0]: wrote tb_valid 16 new value:0x0
t4240.cpu[8][1]: enters mpc85xx_take_timebase 17
t4240.cpu[0][0]: wrote cur_booting_core 17 new value:0x11
t4240.cpu[0][0]: enters mpc85xx_give_timebase 17
In this case cpu[8][1] actually manages to reach take_timebase()
before cpu[0][0] has set cur_booting_core to 0x11 (it's still at 0x10).
This will cause cpu[8][1] to go down in take_timebase() and wait
for timebase synchronization to take place, which will not happen...
When give_timebase() on cpu[0][0] is reached, cur_booting_core
now correctly indicate that this is the secondary thread and it
will jump out early, skipping the timebase synchronization
which cpu[8][1] expects..
wrl 6 RCPL 12 / boot fsl_t4xxx hangs at boot sporadically :
please see attached patch; that looks very clear.
