Re: [Qemu-devel] Emulating Ethernet controller based on Cortex-A15 platforms

[Peter Crosthwaite]

On Fri, Jan 24, 2014 at 7:52 AM, Andreas Färber <address@hidden> 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
>