[U-Boot] driver model is not smp safe

Simon Glass sjg at chromium.org
Mon Aug 3 20:52:19 CEST 2015


Hi Tom,

On 31 July 2015 at 08:31, Tom Rini <trini at konsulko.com> wrote:
> On Thu, Jul 30, 2015 at 12:12:03PM +0800, Bin Meng wrote:
>
>> Hi Simon,
>>
>> When adding x86 multi-cpu initialization on a board with 4 cores, I found:
>>
>> => cpu list
>>   0: cpu at 0               Genuine Intel(R) CPU         @ 1.58GHz
>>   1: cpu at 1               Genuine Intel(R) CPU         @ 1.58GHz
>>   2: cpu at 2               Genuine Intel(R) CPU         @ 1.58GHz
>>   2: cpu at 3               Genuine Intel(R) CPU         @ 1.58GHz
>>
>> cpu at 2 and cpu at 3 have the same sequence number, which indicates they
>> are running parallelly to get the same sequence number. The call chain
>> on an ap is: mp_init_cpu() -> device_probe() -> uclass_resolve_seq().
>> Apparently ap2 and ap3 are running at the same time to get the same
>> number.
>>
>> Note so far all x86 boards that we have enabled x86 multi-cpu
>> initialization on only have 2 cores, which will not expose such issue
>> as there is no parallel execution among aps.
>
> So what exactly are we doing with these additional cores?  My
> recollection of what we do on other arches when we even deal with other
> cores is that we bring them "up" and then usually put them in a holding
> pattern for the real OS to deal with _or_ it's one of those cases where
> we have multiple OSes running and we do what we need to load and release
> those other OSes.

In this case they end up at stop_this_cpu() which is just a hlt
instruction in each case.

Regards,
Simon


More information about the U-Boot mailing list