On Monday 23 October 2006 7:33 pm, Paul Brook wrote: > My intention is that a machine config file would remove the "motherboard" bits > altogether. ie. the config file describes everything that pc_init_1 does. The > first half of pc.c would remain because that's device emulation.
Sounds highly cool. I'm quite in favor of _that_ kind of config file. > For things like network/serial/disks we need to figure out how to make the > machine description adapt to the config the user requested. Proably want to > replace the fixed tables eg. bs_table with some mechanism for > identifying/requesting disks by name. If some of the hardware could be hotpluggable, that would be cool. (I've hotpluged real IDE disks, ill-advised as that is.) I dunno what has ordering requirements (or more specifically, dependencies on previous hardware) though. > Take the Integrator/CP board as an example. I'd expect the machine config to > look something like: > > ram {base=0; size=RAM_SIZE, physaddr=0} > ram {base=0x80000000; size=RAM_SIZE, physaddr=0} > integrator_core{ram_size=RAM_SIZE}; > arm_cpu_pic {cpu_index=0, pic_name="CPU0"} > integrator_pic {pic_name="PRIMARY", base=0x14000000,parent="CPU0", > parent_irq=0, parent_fiq=1} > integrator_pic {pic_name="SECONDARY", base=0xca000000, pic="PRIMARY",irq=0, > fiq=1} > integrator_pit{base=0x13000000, pic="PRIMARY", irq=5} > pl011{base=0x16000000, name="serial0", pic="PRIMARY", irq=1} > etc. > > The syntax I just made up, and there are the issues I mentioned above, but > hopefully you get the idea. The syntax looks fine to me, and I can see where bits of that come from hw/integratorcp.c intergratorcp_init(), but when in that file I also see things like struct integratorcm_state and icp_pic_read() in there, and I don't know how they relate. The "here's a new device: it's a DMA controller" and "here's a new motherboard that has all these chips and devices on it wired together this way" is all mixed together in the same files. I have trouble figure out which bits belong to which categories. Possibly I should be poking at application emulation first, rather than system emulation. Easier to follow what's happening when you run "hello world"... Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel