Wind River Support Network


LIN6-8626 : wrl 6 : fsl_t4xxx may not boot properly in SMP

Created: Oct 27, 2014    Updated: Dec 3, 2018
Resolved Date: Nov 6, 2014
Found In Version: 6.0
Fix Version:
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..

Steps to Reproduce

wrl 6 RCPL 12 / boot fsl_t4xxx hangs at boot sporadically : 

please see attached patch; that looks very clear. 

Other Downloads

Live chat