Hi Andrew, On Fri, Jul 31, 2015 at 8:30 PM, Andrew Bradford <[email protected]> wrote: > Hi Bin, > > On 07/30 12:12, Bin Meng wrote: >> Hi Simon, >> >> When adding x86 multi-cpu initialization on a board with 4 cores, I found: >> >> => cpu list >> 0: cpu@0 Genuine Intel(R) CPU @ 1.58GHz >> 1: cpu@1 Genuine Intel(R) CPU @ 1.58GHz >> 2: cpu@2 Genuine Intel(R) CPU @ 1.58GHz >> 2: cpu@3 Genuine Intel(R) CPU @ 1.58GHz >> >> cpu@2 and cpu@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. >> >> What does this mean? >> >> - Driver model is not smp safe. But given U-Boot is a single-threaded >> environment, I don't think we want to add such support to driver >> model. >> >> OR: >> >> - We are using driver model incorrectly on x86 mp initialization codes. >> >> What do you think? > > I'm not sure what to do about this (if anything) but I also see this on > an E3845 based board. I don't think it has affected me in any way. >
So far I only see the seq number is not correct. Booting Linux with MP table seems to be OK as Linux can start all 4 cores correctly. > Does this also affect non-x86 processors? > I believe currently the cpu uclass is only implemented on x86, so only x86 is affected for now. > => cpu list > 0: cpu@0 Intel(R) Atom(TM) CPU E3845 @ 1.91GHz > 2: cpu@1 Intel(R) Atom(TM) CPU E3845 @ 1.91GHz > 2: cpu@2 Intel(R) Atom(TM) CPU E3845 @ 1.91GHz > 1: cpu@3 Intel(R) Atom(TM) CPU E3845 @ 1.91GHz > Regards, Bin _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
