Peter Crosthwaite <peter.crosthwa...@xilinx.com> writes: > On Wed, Jan 8, 2014 at 11:47 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: >> Il 08/01/2014 14:40, Andreas Färber ha scritto: >>> > Either you fix "info qtree" to cope with your change to the device >>> > graph, or the change needs to be reverted until somebody fixes it or it >>> > goes away. >>> Sharing a backtrace would be a start, rather than just throwing around >>> the word "crash" to justify reverting patches. :) >> >> I mentioned the root cause in the previous message: a Device cannot be >> added to main_system_bus, but that's what the patch does. The fix isn't >> trivial, because most of the affected board are not even qdevified. >> > > So I made progress here with the needed QOMification. Finally I have a > sane info qtree WRT NAND: > > $ arm-softmmu/qemu-system-arm -M spitz -nographic -S > (qemu) info qtree > bus: main-system-bus > type System > ... > dev: sl-nand, id "" > manf_id = 236 > chip_id = 115 > irq 0 > mmio 000000000c000000/0000000000000040 > bus: nand > type nand-bus > dev: nand, id "" > manufacturer_id = 236 > chip_id = 115 > drive = <null> > > With just the proposed revert info qtree does work again, but is bogus: > > (qemu) info qtree > bus: main-system-bus > type System > ... > dev: nand, id "" > manufacturer_id = 236 > chip_id = 115 > drive = <null> > irq 0 > dev: sl-nand, id "" > manf_id = 236 > chip_id = 115 > irq 0 > mmio 000000000c000000/0000000000000040
Progress! > Patches sometime next week hopefully. I think we can wait that long :)
