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

[rajan pathak]

Thanks Andreas and Peter Crosthwate for your response .Your comments are really helpful.

What I understood of your answers that firstly, I need to have keystone soc's initialized/emulated inside hw/arm,right(it would be equivalent of adding machine model) ?

To what extent ,we should emulate the SoC ,is it only the CPU we need to emulate?

As Peter pointed out kernel in my case is Device tree driven rather board files approach.

Kernel compiled for Allwinner SoC uses Board files approach,So how different it would to write machine model

in my case?

Can I reuse Allwinner SoC code to emulate Ketsone SoC?

+static void aw_a10_init(Object *obj)
+{
+    AwA10State *s = AW_A10(obj);
+    DeviceState *dev;
+
+    object_initialize(&s->cpu, sizeof(s->cpu), "cortex-a8-" TYPE_ARM_CPU);
+    object_property_add_child(obj, "cpu", OBJECT(&s->cpu), NULL);
+
+    object_initialize(&s->intc, sizeof(s->timer), TYPE_AW_A10_PIC);
+    dev = DEVICE(&s->intc);
+    qdev_set_parent_bus(dev, sysbus_get_default());
+
+    object_initialize(&s->timer, sizeof(s->timer), TYPE_AW_A10_PIT);
+    dev = DEVICE(&s->timer);
+    qdev_set_parent_bus(dev, sysbus_get_default());
+}
+

Also,I didn't understand below lines from Andreas answer.

 >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

 

Thanks

Rajan

 

.

On Fri, Jan 24, 2014 at 4:06 PM, Peter Crosthwaite <address@hidden> wrote:

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
>