QEMU patches to generate FDT from qdevs
cover QEMU patches to generate FDT from qdevs
Hi everyone,
This is an experimental set of patches for populating the flattened device tree (fdt) data from the actual set of qdevs in the platform. I'm not expecting this to get merged anytime soon, but I wanted to get it out there to solicit comments. My target for this is testing device tree support on ARM.
The approach is by no means final, and there are still a number of details to work out, but I've got it working well with the versatile platform and I've got the kernel using fdt data to bind against the smc91x device driver. I'll be posting my associated kernel patches real-soon-now.
This series is based on Jeremy Kerr's device tree branch found here:
git://kernel.ubuntu.com/jk/dt/qemu.git
Cheers,
g.
---
Grant Likely (7):
devicetree: Add fdt_populate hook to smc91x device
devicetree: Add fdt_populate hook to pl011 device
devicetree: Add helper to register devices with an fdt_populate hook
devicetree: Add sysbus fdt populate hooks.
devicetree: add helper for determining IRQ properties in the device tree
devicetree: auto-populate the device tree with qdev data
devicetree: Add 8k instead of double dtb size when reserving extra memory
device_tree.c | 4 +- hw/arm_boot.c | 3 + hw/pl011.c | 29 ++++++++++-- hw/qdev.c | 139 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ hw/qdev.h | 9 ++++ hw/smc91c111.c | 20 ++++++++ hw/sysbus.c | 107 +++++++++++++++++++++++++++++++++++++++++++ hw/sysbus.h | 4 ++ 8 files changed, 309 insertions(+), 6 deletions(-)
Signature · 1 line
Signature
RFC PATCH 1/7 devicetree: Add 8k instead of double dtb size when reserving extra memory
If a small 'seed' dtb file is loaded into qemu and then heavily modified (say for runtime population of all the device nodes), then 2x the dtb size turns out not to be very much.
This patch changes the device tree loading code to add a fixed 8k of additional space to the dtb buffer.
---
device_tree.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
device_tree.c +2 -2
@@ -41,8 +41,8 @@ void *load_device_tree(const char *filename_path, int *sizep) goto fail; } -/* Expand to 2x size to give enough room for manipulation. */ - dt_size *=2 ; +/* Expand size to give enough room for manipulation. */ + dt_size +=8 *1024 ;/* First allocate space in qemu for device tree */ fdt =qemu_mallocz (dt_size);
Re: [Qemu-devel] [RFC PATCH 1/7] devicetree: Add 8k instead of double dtb size when reserving extra memory
Quoted 6 lines
If a small 'seed' dtb file is loaded into qemu and then heavily modified (say for runtime population of all the device nodes), then 2x the dtb size turns out not to be very much.
This patch changes the device tree loading code to add a fixed 8k of additional space to the dtb buffer.
In that case you almost certainly want double+8k. Or have the calleee tell you how much they're expecting to grow the tree.
Paul
A message that is not in the archive (sent off-list or not yet received): [email protected]
Re: [Qemu-devel] [RFC PATCH 1/7] devicetree: Add 8k instead of double dtb size when reserving extra memory
Quoted 9 lines · Paul Brook
Quoted 6 lines
If a small 'seed' dtb file is loaded into qemu and then heavily modified (say for runtime population of all the device nodes), then 2x the dtb size turns out not to be very much.
This patch changes the device tree loading code to add a fixed 8k of additional space to the dtb buffer.
In that case you almost certainly want double+8k. Or have the calleee tell you how much they're expecting to grow the tree.
Good point. I think I like the latter option.
g.
Signature · 2 lines
Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.
RFC PATCH 2/7 devicetree: auto-populate the device tree with qdev data
In reply to Grant LikelyThis patch adds hooks to the qemu device model to auto-generate device tree nodes from the registered qemu devices, and calls the device tree populate hook when booting ARM platforms.
---
hw/arm_boot.c | 3 ++ hw/qdev.c | 91 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ hw/qdev.h | 8 +++++ 3 files changed, 102 insertions(+), 0 deletions(-)
hw/arm_boot.c +3 -0
@@ -13,6 +13,7 @@#include "sysemu.h" #include "loader.h" #include "elf.h" +#include "qdev.h" #ifdef CONFIG_FDT #include "device_tree.h"
@@ -211,6 +212,8 @@ static int load_dtb(target_phys_addr_t addr, struct arm_boot_info *binfo) }qemu_free (filename); +qdev_fdt_populate (fdt); + rc =qemu_devtree_setprop (fdt,"/memory" ,"reg" , mem_reg_property,sizeof (mem_reg_property));if (rc <0 )
hw/qdev.c +91 -0
94 lines not on this page · raw message
hw/qdev.h +8 -0
@@ -43,10 +43,12 @@ struct DeviceState { };typedef void (*bus_dev_printfn )(Monitor *mon,DeviceState *dev,int indent); +typedef int (*bus_fdt_populatefn )(BusState *bus,void *fdt,int offset);struct BusInfo {const char *name;size_t size;bus_dev_printfn print_dev; +bus_fdt_populatefn fdt_populate;Property *props; };
@@ -119,6 +121,7 @@ BusState *qdev_get_child_bus(DeviceState *dev, const char *name);typedef int (*qdev_initfn )(DeviceState *dev,DeviceInfo *info);typedef int (*qdev_event )(DeviceState *dev);typedef void (*qdev_resetfn )(DeviceState *dev); +typedef int (*qdev_fdt_populatefn )(DeviceState *dev,void *fdt,int offset);struct DeviceInfo {const char *name;
@@ -130,6 +133,7 @@ struct DeviceInfo {/* callbacks */ qdev_resetfn reset; +qdev_fdt_populatefn fdt_populate;/* device state */ const VMStateDescription *vmsd;
@@ -272,4 +276,8 @@ void qdev_prop_set_compat(DeviceState *dev);/* This is a nasty hack to allow passing a NULL bus to qdev_create. */ extern struct BusInfo system_bus_info; +#ifdef CONFIG_FDT +int qdev_fdt_populate (void *fdt); +#endif +#endif
RFC PATCH 3/7 devicetree: add helper for determining IRQ properties in the device tree
In reply to Grant LikelyThis patch adds the qbus_fdt_irq_to_number() helper to determine the interrupt number and phandle needed for adding the interrupts property to a device node in the device tree.
---
hw/qdev.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ hw/qdev.h | 1 + 2 files changed, 49 insertions(+), 0 deletions(-)
hw/qdev.c +48 -0
@@ -751,6 +751,54 @@ void do_device_del(Monitor *mon, const QDict *qdict)#ifdef CONFIG_FDT #include <libfdt.h> +/* Iterate over entire device list looking for the interrupt parent */ +static int __qbus_fdt_irq_to_number (qemu_irq irq,BusState *bus, +uint32_t *phandle); +static int __qbus_fdt_irq_to_number_dev (qemu_irq irq,DeviceState *dev, +uint32_t *phandle) +{ +BusState *child; +int rc, i; + +for (i =0 ; i < dev->num_gpio_in; i++) { +if (irq ==qdev_get_gpio_in (dev, i)) { +if (phandle) + *phandle = (uint64_t )dev; +return i; + } + } + + QLIST_FOREACH(child, &dev->child_bus, sibling) { + rc =__qbus_fdt_irq_to_number (irq, child, phandle); +if (rc >=0 ) +return rc; + } + +return -1 ; +} + +static int __qbus_fdt_irq_to_number (qemu_irq irq,BusState *bus, +uint32_t *phandle) +{ +struct DeviceState *dev; +int rc; + + QLIST_FOREACH(dev, &bus->children, sibling) { + rc =__qbus_fdt_irq_to_number_dev (irq, dev, phandle); +if (rc >=0 ) +return rc; + } + +return -1 ; +} + +int qbus_fdt_irq_to_number (qemu_irq irq,uint32_t *phandle) +{ +return __qbus_fdt_irq_to_number (irq, main_system_bus, phandle); +} + + +static int qbus_fdt_add_bus (void *fdt,BusState *bus,int dev_offset);static int qdev_fdt_add_device (void *fdt,DeviceState *dev,int bus_offset) {
hw/qdev.h +1 -0
@@ -277,6 +277,7 @@ void qdev_prop_set_compat(DeviceState *dev);extern struct BusInfo system_bus_info;#ifdef CONFIG_FDT +int qbus_fdt_irq_to_number (qemu_irq irq,uint32_t *phandle);int qdev_fdt_populate (void *fdt);#endif
RFC PATCH 4/7 devicetree: Add sysbus fdt populate hooks.
In reply to Grant LikelyThis patch adds sysbus specific fdt_populate hooks to fill sysbus device nodes with 'reg' and 'interrupts' properties, and to provide 'ranges' properties for correct address translations.
---
hw/sysbus.c | 92 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ hw/sysbus.h | 2 + 2 files changed, 94 insertions(+), 0 deletions(-)
hw/sysbus.c +92 -0
@@ -22,11 +22,16 @@#include "monitor.h" static void sysbus_dev_print (Monitor *mon,DeviceState *dev,int indent); +static int sysbus_fdt_populate_node (DeviceState *dev,void *fdt,int offset); +static int sysbus_fdt_populate_bus (BusState *bus,void *fdt,int offset);struct BusInfo system_bus_info = { .name ="System" , .size =sizeof (BusState), .print_dev = sysbus_dev_print, +#ifdef CONFIG_FDT + .fdt_populate = sysbus_fdt_populate_bus, +#endif /* CONFIG_FDT */ };void sysbus_connect_irq (SysBusDevice *dev,int n,qemu_irq irq)
@@ -115,6 +120,7 @@ static int sysbus_device_init(DeviceState *dev, DeviceInfo *base)void sysbus_register_withprop (SysBusDeviceInfo *info) { info->qdev.init = sysbus_device_init; + info->qdev.fdt_populate = sysbus_fdt_populate_node; info->qdev.bus_info = &system_bus_info;assert (info->qdev.size >=sizeof (SysBusDevice));
@@ -170,3 +176,89 @@ static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent) indent, "", s->mmio[i].addr, s->mmio[i].size); } } + +#ifdef CONFIG_FDT +#include <libfdt.h> +static int sysbus_fdt_populate_bus (BusState *bus,void *fdt,int offset) +{ +int rc; + + rc =fdt_setprop_string (fdt, offset,"compatible" ,"simple-bus" ); +if (rc <0 ) +return rc; + + rc =fdt_setprop_cell (fdt, offset,"#address-cells" ,1 ); +if (rc <0 ) +return rc; + rc =fdt_setprop_cell (fdt, offset,"#size-cells" ,1 ); +if (rc <0 ) +return rc; + rc =fdt_setprop (fdt, offset,"ranges" ,NULL ,0 ); +if (rc <0 ) +return rc; +return 0 ; +} + +static int sysbus_fdt_populate_node (DeviceState *dev,void *fdt,int offset) +{ +SysBusDevice *s =sysbus_from_qdev (dev); +SysBusDeviceInfo *info =container_of (dev->info, SysBusDeviceInfo, qdev); + +uint32_t reg_data[s->num_mmio *2 ];/* one cell each address and size */ +uint32_t irq_data[s->num_irq]; +uint32_t *pos; +uint32_t phandle; +int i, rc; + +/* Create 'reg' property */ + pos = reg_data; +for (i =0 ; i < s->num_mmio; i++) { +/* By convention, the name is appended with '@<first reg addr>' */ +if (i ==0 ) { +char n[sizeof (dev->info->name) +10 ]; +sprintf (n,"%s@%x" , dev->info->name, (uint32_t )s->mmio[i].addr); + rc =fdt_set_name (fdt, offset, n); +if (rc <0 ) +return rc; + } + *pos++ =cpu_to_be32 (s->mmio[i].addr); + *pos++ =cpu_to_be32 (s->mmio[i].size); + } + rc =fdt_setprop (fdt, offset,"reg" , reg_data,sizeof (reg_data)); +if (rc <0 ) +return rc; + +/* Is this an interrupt controller? */ +if (dev->num_gpio_in) { + rc =fdt_setprop (fdt, offset,"interrupt-controller" ,NULL ,0 ); +if (rc <0 ) +return rc; + rc =fdt_setprop_cell (fdt, offset,"#interrupt-cells" ,1 ); +if (rc <0 ) +return rc; + } + +/* Create 'interrupts' property */ + phandle =0 ; + pos = irq_data; +for (i =0 ; i < s->num_irq; i++) { + *pos++ =cpu_to_be32 (qbus_fdt_irq_to_number (*s->irqp[i], &phandle)); + } +if (phandle) { + rc =fdt_setprop_cell (fdt, offset,"interrupt-parent" , phandle); +if (rc <0 ) +return rc; + rc =fdt_setprop (fdt, offset,"interrupts" , irq_data,sizeof (irq_data)); +if (rc <0 ) +return rc; + } + +if (info->fdt_populate) { + rc = info->fdt_populate (s, fdt, offset); +if (rc <0 ) +return rc; + } + +return 0 ; +} +#endif /* CONFIG_FDT */
hw/sysbus.h +2 -0
@@ -26,6 +26,7 @@ struct SysBusDevice { };typedef int (*sysbus_initfn )(SysBusDevice *dev); +typedef int (*sysbus_fdt_populatefn )(SysBusDevice *dev,void *fdt,int node_offset);/* Macros to compensate for lack of type inheritance in C. */ #define sysbus_from_qdev (dev) ((SysBusDevice *)(dev))
@@ -34,6 +35,7 @@ typedef int (*sysbus_initfn)(SysBusDevice *dev);typedef struct {DeviceInfo qdev;sysbus_initfn init; +sysbus_fdt_populatefn fdt_populate; }SysBusDeviceInfo ;void sysbus_register_dev (const char *name,size_t size,sysbus_initfn init);
RFC PATCH 5/7 devicetree: Add helper to register devices with an fdt_populate hook
In reply to Grant LikelyThis patch allows simple registration of devices to include a device tree node populate function.
---
hw/sysbus.c | 15 +++++++++++++++ hw/sysbus.h | 2 ++ 2 files changed, 17 insertions(+), 0 deletions(-)
hw/sysbus.c +15 -0
@@ -138,6 +138,21 @@ void sysbus_register_dev(const char *name, size_t size, sysbus_initfn init)sysbus_register_withprop (info); } +#if defined(CONFIG_FDT ) +void sysbus_register_dev_fdt (const char *name,size_t size,sysbus_initfn init, +sysbus_fdt_populatefn fdt_populate) +{ +SysBusDeviceInfo *info; + + info =qemu_mallocz (sizeof (*info)); + info->qdev.name =qemu_strdup (name); + info->qdev.size = size; + info->init = init; + info->fdt_populate = fdt_populate; +sysbus_register_withprop (info); +} +#endif +DeviceState *sysbus_create_varargs (const char *name,target_phys_addr_t addr, ...) {
hw/sysbus.h +2 -0
@@ -39,6 +39,8 @@ typedef struct { } SysBusDeviceInfo;void sysbus_register_dev (const char *name,size_t size,sysbus_initfn init); +void sysbus_register_dev_fdt (const char *name,size_t size,sysbus_initfn init, +sysbus_fdt_populatefn fdt_populate);void sysbus_register_withprop (SysBusDeviceInfo *info);void *sysbus_new (void );void sysbus_init_mmio (SysBusDevice *dev,target_phys_addr_t size,int iofunc);
RFC PATCH 6/7 devicetree: Add fdt_populate hook to pl011 device
In reply to Grant Likely---
hw/pl011.c | 29 +++++++++++++++++++++++++---- 1 files changed, 25 insertions(+), 4 deletions(-)
hw/pl011.c +25 -4
@@ -286,6 +286,27 @@ static int pl011_load(QEMUFile *f, void *opaque, int version_id)return 0 ; } +#ifdef CONFIG_FDT +#include <libfdt.h> +static int pl011_fdt_populate (SysBusDevice *dev,void *fdt,int offset) +{ +pl011_state *s =FROM_SYSBUS (pl011_state, dev); +int rc; + + rc =fdt_setprop_string (fdt, offset,"compatible" ,"arm,amba-device" ); +if (rc <0 ) +return rc; + + rc =fdt_setprop (fdt, offset,"arm,amba-deviceid" , s->id,sizeof (s->id)); +if (rc <0 ) +return rc; + +return 0 ; +} +#else +#define pl011_fdt_populate NULL +#endif +static int pl011_init (SysBusDevice *dev,const unsigned char *id) {int iomemtype;
@@ -322,10 +343,10 @@ static int pl011_init_luminary(SysBusDevice *dev)static void pl011_register_devices (void ) { -sysbus_register_dev ("pl011" ,sizeof (pl011_state), - pl011_init_arm); -sysbus_register_dev ("pl011_luminary" ,sizeof (pl011_state), - pl011_init_luminary); +sysbus_register_dev_fdt ("pl011" ,sizeof (pl011_state), + pl011_init_arm, pl011_fdt_populate); +sysbus_register_dev_fdt ("pl011_luminary" ,sizeof (pl011_state), + pl011_init_luminary, pl011_fdt_populate); }device_init (pl011_register_devices)
RFC PATCH 7/7 devicetree: Add fdt_populate hook to smc91x device
In reply to Grant Likely---
hw/smc91c111.c | 20 ++++++++++++++++++++ 1 files changed, 20 insertions(+), 0 deletions(-)
hw/smc91c111.c +20 -0
@@ -721,8 +721,28 @@ static int smc91c111_init1(SysBusDevice *dev)return 0 ; } +#ifdef CONFIG_FDT +#include <libfdt.h> +static int smc91c111_fdt_populate (SysBusDevice *dev,void *fdt,int offset) +{ +smc91c111_state *s =FROM_SYSBUS (smc91c111_state, dev); +int rc; + + rc =fdt_setprop_string (fdt, offset,"compatible" ,"smc,91c111" ); +if (rc <0 ) +return rc; + + rc =fdt_setprop (fdt, offset,"local-mac-address" , s->conf.macaddr.a, +sizeof (s->conf.macaddr.a)); +return 0 ; +} +#endif +static SysBusDeviceInfo smc91c111_info = { .init = smc91c111_init1, +#ifdef CONFIG_FDT + .fdt_populate = smc91c111_fdt_populate, +#endif .qdev.name ="smc91c111" , .qdev.size =sizeof (smc91c111_state), .qdev.props = (Property []) {
Hi Grant,
Quoted 2 lines
This is an experimental set of patches for populating the flattened device tree (fdt) data from the actual set of qdevs in the platform.
Neat. I've pulled these into my qemu tree, and have updated it to the current qemu master branch too (only a minor change, as qemu_error has been removed).
Could you try out the new branch to see if it all works for you?
Cheers,
Jeremy
A message that is not in the archive (sent off-list or not yet received): 201004071501.34711.jeremy.kerr-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org
Quoted 9 lines · Jeremy Kerr
Hi Grant,
Quoted 2 lines
This is an experimental set of patches for populating the flattened device tree (fdt) data from the actual set of qdevs in the platform.
Neat. I've pulled these into my qemu tree, and have updated it to the current qemu master branch too (only a minor change, as
qemu_errorhas been removed).Could you try out the new branch to see if it all works for you?
Mostly, but had to fix my sprintf handling because I had a buffer overflow. I'll send a followup patch.
g.
Quoted 8 lines · Grant Likely
Hi everyone,
This is an experimental set of patches for populating the flattened device tree (fdt) data from the actual set of qdevs in the platform. I'm not expecting this to get merged anytime soon, but I wanted to get it out there to solicit comments. My target for this is testing device tree support on ARM.
Quoted 5 lines
The approach is by no means final, and there are still a number of details to work out, but I've got it working well with the versatile platform and I've got the kernel using fdt data to bind against the smc91x device driver. I'll be posting my associated kernel patches real-soon-now.
It looks like the hook is only used to add some additional properties. I think a data driven approach (fields in qdev structure) would be simpler because the handling code would be only in qdev instead of all devices.
Something like:
static SysBusDeviceInfo smc91c111_info = {
.init = smc91c111_init1,
.qdev.name = "smc91c111",
.qdev.size = sizeof(smc91c111_state),
.qdev.props = (Property[]) {
DEFINE_NIC_PROPERTIES(smc91c111_state, conf),
DEFINE_PROP_END_OF_LIST(),
},
.qdev.fdt_props = (FDTProperty[]) {
DEFINE_FDT_NIC_MACADDR("local-mac-address", smc91c111_state,
conf.macaddr),
DEFINE_FDT_PROP_STR("compatible", "smc,91c111"),
DEFINE_FDT_PROP_END_OF_LIST(),
}
};A separate question is whether the properties should be visible to user, for example shown by "info qdev". If yes, then the FDT properties should be a special case of qdev properties:
.qdev.props = (Property[]) {
DEFINE_NIC_PROPERTIES(smc91c111_state, conf),
DEFINE_FDT_NIC_MACADDR("local-mac-address", smc91c111_state,
conf.macaddr),
DEFINE_FDT_PROP_STR("compatible", "smc,91c111"),
DEFINE_PROP_END_OF_LIST(),
}A message that is not in the archive (sent off-list or not yet received): k2kf43fc5581004071210v810be251nf77b7ab469004e5c-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Thanks for the comments. Replies below...
Quoted 15 lines · Blue Swirl
Quoted 8 lines · Grant Likely
Hi everyone,
This is an experimental set of patches for populating the flattened device tree (fdt) data from the actual set of qdevs in the platform. I'm not expecting this to get merged anytime soon, but I wanted to get it out there to solicit comments. My target for this is testing device tree support on ARM.
Quoted 5 lines
The approach is by no means final, and there are still a number of details to work out, but I've got it working well with the versatile platform and I've got the kernel using fdt data to bind against the smc91x device driver. I'll be posting my associated kernel patches real-soon-now.
Quoted 4 lines
It looks like the hook is only used to add some additional properties. I think a data driven approach (fields in qdev structure) would be simpler because the handling code would be only in qdev instead of all devices.
Hmmm, maybe. I don't really have a good answer yet as I'm still experimenting. It is possible that I'll need more complex behaviour as I add new kinds of devices or for handling different bus types. For example, right now I've got code to change the node name for mmio devices, and that cannot be filled in until the register base is defined and the best name format may be different for different busses/devices. I'm not familiar enough with qemu to know how best to handle this with properties.
Quoted 17 lines
Something like:
static SysBusDeviceInfosmc91c111_info= {
.init =smc91c111_init1,
.qdev.name = "smc91c111",
.qdev.size =sizeof(smc91c111_state),
.qdev.props = (Property[]) {DEFINE_NIC_PROPERTIES(smc91c111_state, conf),DEFINE_PROP_END_OF_LIST(),
},
.qdev.fdt_props = (FDTProperty[]) {DEFINE_FDT_NIC_MACADDR("local-mac-address", smc91c111_state, conf.macaddr),
DEFINE_FDT_PROP_STR("compatible", "smc,91c111"),DEFINE_FDT_PROP_END_OF_LIST(),
}
};
Quoted 10 lines
A separate question is whether the properties should be visible to user, for example shown by "info qdev". If yes, then the FDT properties should be a special case of qdev properties:
.qdev.props = (Property[]) {DEFINE_NIC_PROPERTIES(smc91c111_state, conf),DEFINE_FDT_NIC_MACADDR("local-mac-address", smc91c111_state, conf.macaddr),
DEFINE_FDT_PROP_STR("compatible", "smc,91c111"),DEFINE_PROP_END_OF_LIST(),
}
It would certainly be useful to see the device node(s) associated with a qdev.
g.
Quoted 7 lines
Hi everyone,
This is an experimental set of patches for populating the flattened device tree (fdt) data from the actual set of qdevs in the platform. I'm not expecting this to get merged anytime soon, but I wanted to get it out there to solicit comments. My target for this is testing device tree support on ARM.
I think you need to convert some more interesting machines before it's possible to tell whether this is a sane setup. When investigating FDTs for creation of machine I found it's easy to invent something that can handle the simple integrator/cp board, but it all starts to fall apart when you encounter more complicated boards. In particular things like PCI, USB, I2C, etc. and strange bus configurations when you have both on-chip and external devices.
Paul
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 8 lines · Paul Brook
Quoted 7 lines
Hi everyone,
This is an experimental set of patches for populating the flattened device tree (fdt) data from the actual set of qdevs in the platform. I'm not expecting this to get merged anytime soon, but I wanted to get it out there to solicit comments. My target for this is testing device tree support on ARM.
Quoted 6 lines
I think you need to convert some more interesting machines before it's possible to tell whether this is a sane setup. When investigating FDTs for creation of machine I found it's easy to invent something that can handle the simple integrator/cp board, but it all starts to fall apart when you encounter more complicated boards. In particular things like PCI, USB, I2C, etc. and strange bus configurations when you have both on-chip and external devices.
Certainly. What would be a good (preferably ARM) platform to look at?
I'm fairly new to working with QEMU, so I'm not very familiar with
the platforms that are available.
g.
Signature · 2 lines
Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.
A message that is not in the archive (sent off-list or not yet received): h2ofa686aa41004090747w2422cedasb6f4b51633637816-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 17 lines · Paul Brook
Quoted 8 lines
Quoted 7 lines
Hi everyone,
This is an experimental set of patches for populating the flattened device tree (fdt) data from the actual set of qdevs in the platform. I'm not expecting this to get merged anytime soon, but I wanted to get it out there to solicit comments. My target for this is testing device tree support on ARM.
Quoted 7 lines
I think you need to convert some more interesting machines before it's possible to tell whether this is a sane setup. When investigating FDTs for creation of machine I found it's easy to invent something that can handle the simple integrator/cp board, but it all starts to fall apart when you encounter more complicated boards. In particular things like PCI, USB, I2C, etc. and strange bus configurations when you have both on-chip and external devices.
Quoted 3 lines
Certainly. What would be a good (preferably ARM) platform to look at?
I'm fairly new to working with QEMU, so I'm not very familiar with
the platforms that are available.
The versatile and readview boards both have PCI. The realview-eb-mpcore in particular has entertaining IRQ routing. The Stellaris boards have various devices hanging off I2C/SSI busses and/or GPO pins (though the stellaris boards aren't capable of running linux). The musicpal audio device may also be interesting as it's connected vi both i2s and gpio based i2c. All these should be fairly well qdev-ified.
Arguably the most interesting is the PPC boards as we already know what device tree we need to generate. However these haven't been converted to qdev yet, and it's unclear how well the 4xx boards work to start with.
Paul
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 17 lines · Paul Brook
Quoted 17 lines · Paul Brook
Quoted 15 lines
Quoted 7 lines
Hi everyone,
This is an experimental set of patches for populating the flattened device tree (fdt) data from the actual set of qdevs in the platform. I'm not expecting this to get merged anytime soon, but I wanted to get it out there to solicit comments. My target for this is testing device tree support on ARM.
I think you need to convert some more interesting machines before it's possible to tell whether this is a sane setup. When investigating FDTs for creation of machine I found it's easy to invent something that can handle the simple integrator/cp board, but it all starts to fall apart when you encounter more complicated boards. In particular things like PCI, USB, I2C, etc. and strange bus configurations when you have both on-chip and external devices.
Quoted 5 lines
Quoted 3 lines
Certainly. What would be a good (preferably ARM) platform to look at? I'm fairly new to working with QEMU, so I'm not very familiar with the platforms that are available.
The versatile and readview boards both have PCI.
PCI shouldn't be too hairy. As long as the PCI bridge node is created with the right properties for ranges and irq mapping, then the child devices can be detected by the OS. Unlike the configuration case, I don't have to fully populate this part of the tree. :-D
Quoted 2 lines
The realview-eb-mpcore in
particular has entertaining IRQ routing.
Fun. I'll probably look at this first.
Quoted 3 lines
The Stellaris boards have various
devices hanging off I2C/SSI busses and/or GPO pins (though the stellaris boards aren't capable of running linux).
I'll skip that for now then.
Quoted 3 lines
The musicpal audio device may also be
interesting as it's connected vi both i2s and gpio based i2c. All these should be fairly well qdev-ified.
This looks like a good candidate too then. Getting i2c, spi and gpio sorted out is higher priority for me right now than pci.
Quoted 3 lines
Arguably the most interesting is the PPC boards as we already know what device tree we need to generate. However these haven't been converted to qdev yet, and it's unclear how well the 4xx boards work to start with.
:-)
Thanks for the suggestions. I'll keep you posted on how things go. g.
Signature · 2 lines
Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.