[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Adding -dtb option to qemu
From: |
Grant Likely |
Subject: |
[Qemu-devel] Adding -dtb option to qemu |
Date: |
Mon, 23 Jan 2012 09:32:25 -0700 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Hey Peter,
I need some advice. I'm adding a -dtb option to qemu for specifying a
dtb filename to be passed on to the kernel, similar to how the -initrd
flag works. The dtb filename needs to then be passed on to the
selected machine, and it looks like the machine->init() callback is
the best way to do that.
However, the current init callback prototype looks like this:
typedef void QEMUMachineInitFunc(ram_addr_t ram_size,
const char *boot_device,
const char *kernel_filename,
const char *kernel_cmdline,
const char *initrd_filename,
const char *cpu_model);
Now, I could simply add an new "dtb_filename" to the argument list and
fix up all of the users (looks to be about 90 machines), but that
seems like a lot of churn that will need to be repeated the next time
a new argument needs to be passed to the init func.
Alternately, I could do something like this:
struct machine_args {
ram_addr_t ram_size;
const char *boot_device;
const char *kernel_filename,
const char *kernel_cmdline,
const char *initrd_filename,
const char *dtb_filename,
const char *cpu_model,
};
typedef void QEMUMachineInitFunc(const struct machine_args *args);
And then I'd fix up all the users, which would be about the same
amount of churn, but subsequent additions would be a lot easier.
A third option would be to add a new ".dt_init()" that is executed
instead of .init() if populated, but that seems like an ugly band-aid
to me.
How should I approach this? Or is there a better way to pass data to
so that it is available at machine->init() time?
g.
- [Qemu-devel] [PATCH v12 3/4] arm: add secondary cpu boot callbacks to arm_boot.c, (continued)
- [Qemu-devel] [PATCH v12 3/4] arm: add secondary cpu boot callbacks to arm_boot.c, Mark Langsdorf, 2012/01/19
- [Qemu-devel] [PATCH v12 4/4] arm: SoC model for Calxeda Highbank, Mark Langsdorf, 2012/01/19
- Re: [Qemu-devel] [PATCH v12 4/4] arm: SoC model for Calxeda Highbank, Peter Maydell, 2012/01/19
- Re: [Qemu-devel] [PATCH v12 4/4] arm: SoC model for Calxeda Highbank, Rob Herring, 2012/01/19
- Re: [Qemu-devel] [PATCH v12 4/4] arm: SoC model for Calxeda Highbank, John Williams, 2012/01/19
- Re: [Qemu-devel] [PATCH v12 4/4] arm: SoC model for Calxeda Highbank, Peter Maydell, 2012/01/20
- Re: [Qemu-devel] [PATCH v12 4/4] arm: SoC model for Calxeda Highbank, Rob Herring, 2012/01/20
- Re: [Qemu-devel] [PATCH v12 4/4] arm: SoC model for Calxeda Highbank, Peter Maydell, 2012/01/20
- Re: [Qemu-devel] [PATCH v12 4/4] arm: SoC model for Calxeda Highbank, Grant Likely, 2012/01/21
- Re: [Qemu-devel] [PATCH v12 4/4] arm: SoC model for Calxeda Highbank, Peter Maydell, 2012/01/20
- [Qemu-devel] Adding -dtb option to qemu,
Grant Likely <=
- Re: [Qemu-devel] [PATCH v12 4/4] arm: SoC model for Calxeda Highbank, Mark Langsdorf, 2012/01/20
- Re: [Qemu-devel] [PATCH v12 4/4] arm: SoC model for Calxeda Highbank, Peter Maydell, 2012/01/20
- Re: [Qemu-devel] [PATCH v12 4/4] arm: SoC model for Calxeda Highbank, Mark Langsdorf, 2012/01/20
- Re: [Qemu-devel] [PATCH v12 4/4] arm: SoC model for Calxeda Highbank, Peter Maydell, 2012/01/20
- Re: [Qemu-devel] [PATCH v12 4/4] arm: SoC model for Calxeda Highbank, Mark Langsdorf, 2012/01/20
- Re: [Qemu-devel] [PATCH v12 4/4] arm: SoC model for Calxeda Highbank, Peter Maydell, 2012/01/20
- Re: [Qemu-devel] [PATCH v12 4/4] arm: SoC model for Calxeda Highbank, Grant Likely, 2012/01/21