On Fri, Jan 24, 2014 at 7:52 AM, Andreas Färber <afaer...@suse.de> wrote: > Am 23.01.2014 21:02, schrieb rajan pathak: >>> I'm not clear what you're trying to do here; could >>> you try rephrasing your question? Are you just trying >>> to use the existing working QEMU emulation of a >>> Cortex-A15 board and ethernet controller, or to do >>> something else? >> >> To be very specific I am trying to emulate Ethernet controller of >> KeyStone 2 device from TI >>
Device tree driven Linux should minimise the pain of swapping ethernet drivers out to give you a guest that tests such a strange (and non-existant board). TBH, its not a bad starting point to: 1: Write your device model in hw/net 2: Take an ARM Linux port you know works on QEMU 3: Switch on your enet driver in Kconfig 4: Hack device tree to have your ethernet rather than the actual one 5: Hack qemu to have your ethernet instead of real one 6: Boot. But Andreas is right. To do it properly you really need to get the machine model for your actual system going. >> http://processors.wiki.ti.com/index.php/MCSDK_User_Guide_for_KeyStone_II >> >> It is based on CortexA-15 Processor series. So I thought I can use >> vexpress_defconfig and can call >> my Emulated Ethernet controller instead of LAN9118 from vexpress.c. >> Why is the ARM variant really relevant to ethernet controller bringup anyway? I'm not sure what A15 specific features are going to warrant bending over backwards to make a hybrid that has A15 + substituted ethernet. >> After that I will place my Emulated Ethernet controller code(which >> haven't started) inside hw/net . >> >> Is the right way to go forward? > > No, it isn't. If you want to emulate the KeyStone II SoC, then please do > just that. You will find recent examples on the list of new SoCs that > have been added, including sunxi/A10 and DIGIC. Allwinner is a particularly relevant example. They upstreamed their baseport (CPU, RAM, UART, Timer and Intc only) recently as a minimal series, but are just now adding their ethernet as follow up. This is a good approach, upstream the absolute bare minimum machine model as first series to get a boot. Then go after the optional peripheral device models. So, the Ethernet > controller would be a new device in hw/net/, it is initialized by a SoC > device in hw/arm/ and to use it you need a standard machine definition, > such as the EVMK2Hx in your case (some evaluation/reference board rather > than custom industry boards). Then test that code using a Linux (or > firmware or other OS) that runs on the real board. > Yes, just a new ethernet controller in hw/net is going to be a hard sell without going the extra effort of adding a relevant machine model that uses it. Regards, Peter > Regards, > Andreas > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg >
