CELF Project Proposal/Add Device Tree emulation support to QEMU
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 4BF9BB22.2000603-VWkGxi2CTS+6c6uEtOJ/[email protected]
(cc'ing devicetree-discuss and others)
Quoted 7 lines · Nigel Cunningham
http://elinux.org/CELF_Project_Proposal/Add_Device_Tree_emulation_support_to_QEMU
Grant, I've joined the devicetree-discuss mailing list, and am seeking to get up to speed with things, but want to find out before I get too carried away what your thoughts are on Rob's proposal. In your opinion, is there a useful contribution I can make in this area, or do you already have it all in hand and not need any help? (I'm not sure how old Rob's proposal is).
Hi Nigel,
A bunch of work has already been done in this area, but not all of it has been pushed upstream. Edgar Ingesias and John Williams collaborated to bring up QEMU microblaze support, including a device tree parser. I believe John & Petalogix is continuing to pursue this work, but I don't know what the state of it is. Much of the Microblaze support is in mainline, but I don't think the device tree parser has been pushed up yet. John and Edgar can tell you about this much better than I.
Independently, Jeremy Kerr added QEMU support for passing a device tree to the kernel on the ARM architecture via an ATAG, and I added code for generating the device tree contents from the set of instantiated devices. This approach is rather different from what John and Edgar have done as it still requires a separate method of configuring QEMU. While I find it useful, this approach probably isn't the best long term solution.
I'm not actively working on this other than adding the bits and pieces I need to improve the ARM device tree support in the kernel. You'll have to coordinate with John and Edgar to figure out if there is a useful contribution that you can make.
Cheers,
g.
A message that is not in the archive (sent off-list or not yet received): AANLkTilCe5FyT6Pcz61FnhpbpdLhg2EGSfk4jZlKdQKA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 7 lines · Grant Likely
(cc'ing devicetree-discuss and others)
Quoted 2 lines · Nigel Cunningham
http://elinux.org/CELF_Project_Proposal/Add_Device_Tree_emulation_support_to_QEMU
Just in case anyone is interested -
One Laptop Per Child is doing some ARM work, so I have resurrected FirmWorks' ARM version of Open Firmware. It's in the open source OFW tree at http://openfirmware.info/Open_Firmware . There is a build that runs under QEMU, in the subdirectory cpu/arm/versatilepb . FirmWorks' core ARM stuff is fairly solid, having been developed to shipping quality for Digital's "Shark" (aka DNARD) system, just prior to Digital's demise and the sale of StrongARM to Intel.
I'll be adding more elaborations in the near future. One item on the short list is to auto-generate a flattened device tree from the real device tree. It's a pity that the dynamic device tree has to be projected onto a static structure, but I guess that Gresham's Law applies to software too.
Quoted 39 lines
Quoted 6 lines
Grant, I've joined the devicetree-discuss mailing list, and am seeking to get up to speed with things, but want to find out before I get too carried away what your thoughts are on Rob's proposal. In your opinion, is there a useful contribution I can make in this area, or do you already have it all in hand and not need any help? (I'm not sure how old Rob's proposal is).
Hi Nigel,
A bunch of work has already been done in this area, but not all of it has been pushed upstream. Edgar Ingesias and John Williams collaborated to bring up QEMU microblaze support, including a device tree parser. I believe John & Petalogix is continuing to pursue this work, but I don't know what the state of it is. Much of the Microblaze support is in mainline, but I don't think the device tree parser has been pushed up yet. John and Edgar can tell you about this much better than I.
Independently, Jeremy Kerr added QEMU support for passing a device tree to the kernel on the ARM architecture via an ATAG, and I added code for generating the device tree contents from the set of instantiated devices. This approach is rather different from what John and Edgar have done as it still requires a separate method of configuring QEMU. While I find it useful, this approach probably isn't the best long term solution.
I'm not actively working on this other than adding the bits and pieces I need to improve the ARM device tree support in the kernel. You'll have to coordinate with John and Edgar to figure out if there is a useful contribution that you can make.
Cheers,
g.
_______________________________________________
devicetree-discuss mailing list devicetree-discuss-uLR06cmDAlY/[email protected]
https://lists.ozlabs.org/listinfo/devicetree-discuss
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 17 lines · Mitch Bradley
Quoted 5 lines · Grant Likely
(cc'ing devicetree-discuss and others)
Quoted 1 line · Nigel Cunningham
http://elinux.org/CELF_Project_Proposal/Add_Device_Tree_emulation_support_to_QEMU
Just in case anyone is interested -
One Laptop Per Child is doing some ARM work, so I have resurrected FirmWorks' ARM version of Open Firmware. It's in the open source OFW tree at http://openfirmware.info/Open_Firmware . There is a build that runs under QEMU, in the subdirectory cpu/arm/versatilepb . FirmWorks' core ARM stuff is fairly solid, having been developed to shipping quality for Digital's "Shark" (aka DNARD) system, just prior to Digital's demise and the sale of StrongARM to Intel.
Quoted 3 lines
I'll be adding more elaborations in the near future. One item on the short list is to auto-generate a flattened device tree from the real device tree.
That should be pretty easy to do. In fact, this was one of the use-cases I explicitly thought of when writing libfdt. If you're using libfdt (and if not, why not) and it's missing something handy for this, I'll be happy to add it.
Quoted 3 lines
It's a pity that the dynamic device tree has to
be projected onto a static structure, but I guess that Gresham's Law applies to software too.
Signature · 4 lines
David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Quoted 14 lines · Grant Likely
(cc'ing devicetree-discuss and others)
Quoted 7 lines · Nigel Cunningham
http://elinux.org/CELF_Project_Proposal/Add_Device_Tree_emulation_support_to_QEMU
Grant, I've joined the devicetree-discuss mailing list, and am seeking to get up to speed with things, but want to find out before I get too carried away what your thoughts are on Rob's proposal. In your opinion, is there a useful contribution I can make in this area, or do you already have it all in hand and not need any help? (I'm not sure how old Rob's proposal is).
Hi Nigel,
Quoted 8 lines
A bunch of work has already been done in this area, but not all of it has been pushed upstream. Edgar Ingesias and John Williams collaborated to bring up QEMU microblaze support, including a device tree parser. I believe John & Petalogix is continuing to pursue this work, but I don't know what the state of it is. Much of the Microblaze support is in mainline, but I don't think the device tree parser has been pushed up yet. John and Edgar can tell you about this much better than I.
Hi Grant and others,
There are many ways one could use device tree's in QEMU. In fact, upstream QEMU already has some support for parsing and editing the device trees prior to starting machines (e.g for kernel cmdline passing etc).
For MicroBlaze we wanted to instantiate machines based on a pre-existing device tree format. With pre-existing format I mean that we didn't want to create QEMU specific entries in the device tree file. We wanted to reuse fdt files with device names and properties that were already widely used.
Our implementation is very simple but also limited, it wraps a device-tree layer around QEMU. There are very few changes to existing QEMU code, most of the work is done in a new machine file. QEMU takes a device tree and instantiates the machine based on it.
The implementation is very geared towards Xilinx machines, nothing else is supported. The machine makes lot's of hardcoded assumptions that really should have been picked up from the device-tree.
I'd be happy to clean the code up and also to address specific comments people may have. At the moment though, I'm pretty chocked and cannot drive discussions to reach wide consensus on how this thing should be properly done & integrated to fit all archs/machines/etc in order to go upstream.
The fdt support for Xilinx MicroBlaze is available here:git://repo.or.cz/qemu/cris-port.git
Cheers,
Edgar
Quoted 16 lines
Independently, Jeremy Kerr added QEMU support for passing a device tree to the kernel on the ARM architecture via an ATAG, and I added code for generating the device tree contents from the set of instantiated devices. This approach is rather different from what John and Edgar have done as it still requires a separate method of configuring QEMU. While I find it useful, this approach probably isn't the best long term solution.
I'm not actively working on this other than adding the bits and pieces I need to improve the ARM device tree support in the kernel. You'll have to coordinate with John and Edgar to figure out if there is a useful contribution that you can make.
Cheers,
g.