[U-Boot] [PATCH v4 5/8] x86: qemu: add qemu_fwcfg_fdt_fixup()

Simon Glass sjg at chromium.org
Thu Dec 31 06:08:13 CET 2015


Hi Maio,

On 30 December 2015 at 19:55, Miao Yan <yanmiaobest at gmail.com> wrote:
> Add a function to fix up 'cpus' node in dts files for qemu target.
>
> Signed-off-by: Miao Yan <yanmiaobest at 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


More information about the U-Boot mailing list