Hi Maio, On 30 December 2015 at 19:55, Miao Yan <yanmiaob...@gmail.com> wrote: > Add a function to fix up 'cpus' node in dts files for qemu target. > > Signed-off-by: Miao Yan <yanmiaob...@gmail.com> > --- > Changes in v4: > - fix a typo in commit log > > arch/x86/cpu/qemu/fw_cfg.c | 65 > ++++++++++++++++++++++++++++++++++++++++++++++ > arch/x86/cpu/qemu/fw_cfg.h | 11 ++++++++ > 2 files changed, 76 insertions(+)
I'm sorry for not reviewing this earlier (Christmas and all that). I don't think you need to update the device tree to make this work. Here's my suggestion: - At present cpu_x86_bind() sets up the CPU APIC ID from the device tree - You can bind new CPU devices in your code on start-up - You can check if you have CPUs which are not available in the device list, by using uclass_find_first/next_device() to iterate through the devices without probing them - Then to create a new one, call device_bind_driver() with the /cpus node as the parent - After binding, update the parent platform data: struct cpu_platdata *plat = dev_get_parent_platdata(dev); plat->cpu_id = ... - Then when it comes to probing, you will have all the devices you need, and you don't need to adjust the device tree. The device tree can just hold a single device, for example. I think it is better to do this than adjust the device tree because it removes the 32-CPU limit and should be faster. It is also simpler as it is a more direct method. Also I believe you only need to do this after relocation - e.g. in arch_early_init_r(), which is before mp_init() is called from cpu_init_r(). I wonder if there is a general way to probe available CPUs (and their APIC IDs)? Or is qemu the only 'CPU' with this feature? Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
