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

[rajan pathak]

Also, I am just wondering why anyone hasn't suggested me to look into TI OMAP emulation code present in QEMU.

Thanks

Rajan

On Sat, Jan 25, 2014 at 5:52 AM, rajan pathak <address@hidden> wrote:

OK,Peter Thanks.

I got your point,In my case SoC is from TI which uses cortexa-15 as CPU core and example(Borad) would be keystone 2 EVM .

I guess I need to divide my emulation in three steps

1)Emulation of SoC

2)Emulation of board.

3)Emulation of Devices(Ethernet controller).

Please correct me if I am wrong .

Thanks

Rajan

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

On Sat, Jan 25, 2014 at 5:18 PM, rajan pathak <address@hidden> wrote:
> 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,

Yes.

right(it would be equivalent of
> adding machine model) ?
>

And no - SoC are not machine models. There are several violators of
this rule in-tree including Zynq and Highbank off the top of my head.
Our suggestion to look at Allwinner is because it is the most recently
reviewed and accepted so it is stylistically up to date.

Boards are machine models (more about that below) - you will need that too.

> 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?
>

Not at all. That's a Kernel problem. We do have device tree support in
QEMU from a bootloader point-of-view, but such kernel design
descisions do not (or rather should not) flow-on to QEMU hardware
emulation in any way. Just think about the hardware and the kernel is
merely one of many possible softwares that could run on your model.

> 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());
> +}
> +
>

Yes that looks like a good place to be reading - that is SoC level code.

> 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
>

Do you have an easily-obtainable eval board that you are using or
would ideally use for your work should you be doing this in real
hardware? If so - that's what you should model. In Allwinners case,
the one picked was the "cubieboard".

Check the later versions of the allwinner series to see the clear
separation of the three levels - Board, SoC and Devices.
hw/arm/cubieboard.c is good reading WRT to this.

Regards,
Peter

>
> 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
>> >
>
>