[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] arm: add device tree support
From: |
Paul Brook |
Subject: |
Re: [Qemu-devel] [PATCH] arm: add device tree support |
Date: |
Sun, 29 Jan 2012 11:15:42 +0000 |
User-agent: |
KMail/1.13.7 (Linux/3.1.0-1-amd64; KDE/4.6.5; x86_64; ; ) |
> There is a lot of configuration in the .dts file that the QEMU user may
> want to manipulate; particularly when using QEMU for testing embedded
> platforms. The direction I want to go is to select the machine model based
> on the top level DT compatible property (making -M optional), and then
> also allow a lot of the machine layout to be driven by DT data. ie.
> populate emulated devices from DT data.
I want to remove -M, and the associated board specific knowledge altogether.
A system that can only create limited variants of hardcoded boards is IMO not
a viable medium/long term solution.
> > This gets slightly more interesting when you have custom machine variants
> > (i.e. once we fix the object model, and have proper dynamic machine
> > construction). Even then I'd expect the FDT to be derived
> > from/specificed by the machine description, not a separate option.
>
> I started with going down that route, but switched to this model after
> playing with it and noticing that it doesn't seem to fit as well for
> embedded development as providing a .dtb file and having QEMU
> construct a machine that matches the data.
Problem is that a FDT doesn't really tell you everything you need to know in
order to construct the machine. If you look back in the archives you should
find that I tried something similar when I first added the qdev code. While
it appears to be a nice idea at first, it doesn't actually work do well in
practice. It's maybe OK for simple embedded systems with a single system bus,
but when you start looking at more sophisticated machines it doesn't fit so
well. In particular when you look at things like PCI, devices connected via
multiple busses (a sound codec with both I2C [command] and I2S [data]
connections), and some of the stranger bus topographies (some ppc boards have
lots of weirdness in the FDT) the requirements of qemu and linux start to
diverge.
Clearly we need to have some sort of FDT support. However I'm unconvinced
that it's the correct format for the primary data structure. For one thing
it's a hierarchical tree structure, and in my experience describing links
outside that structure gets hairy. One of the things we're doing with QOM is
move from a hierarchical tree/bus to a more general connected web of links
between devices.
Paul
- [Qemu-devel] [PATCH] arm: add device tree support, Grant Likely, 2012/01/27
- Re: [Qemu-devel] [PATCH] arm: add device tree support, Paul Brook, 2012/01/27
- Re: [Qemu-devel] [PATCH] arm: add device tree support, Peter Maydell, 2012/01/29
- Re: [Qemu-devel] [PATCH] arm: add device tree support, John Williams, 2012/01/29
- Re: [Qemu-devel] [PATCH] arm: add device tree support, Grant Likely, 2012/01/29
- Re: [Qemu-devel] [PATCH] arm: add device tree support, Andreas Färber, 2012/01/30
- Re: [Qemu-devel] [PATCH] arm: add device tree support, Grant Likely, 2012/01/30
- Re: [Qemu-devel] [PATCH] arm: add device tree support, Edgar E. Iglesias, 2012/01/29