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

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

[rajan pathak]

[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]

Hello Experts

I am new to QEMU development and trying to emulate Ethernet controller
based on
Corext-A15 platform.

Current I am able to up the QEMU console and see it uses SMSC 91C111
Ethernet interface emulation code.

I have compiled the kernel using versatile_defconfig where I can see
CONFIG_SMC91X,So I guess it uses SMSC 91C111 as its Ethernet controller.

I can see call to this  smc91c111_init(nd, 0x10010000, sic[25]); function
is made inside hw/arm/versatilepb.c which triggers the initialization of
emulated SMSC Ethernet controller in hw/net/smc91c111.c.

I am looking to emulate Ethernet controller based on Cortex-A15 platform,so
for
Do I need to use vexpress_defconfig instead of versatile_defconfig?

If I have to use vexpress what would initializtion point of my emulated
Ethernet controller based Cortex-A15 platform?

Would be inside vexpress_common_init() of vexpress.c

/* 0x4e000000 LAN9118 Ethernet */
    if (nd_table[0].used) {
        lan9118_init(&nd_table[0], map[VE_ETHERNET], pic[15]);
    }

Could anyone please confirm this above understanding of mine?

Thanks
Rajan

[-- Attachment #2: Type: text/html, Size: 1458 bytes --]

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

[Peter Maydell]

On 23 January 2014 19:28, rajan pathak <rajanpatha34@gmail.com> wrote:
> I have compiled the kernel using versatile_defconfig where I can see
> CONFIG_SMC91X,So I guess it uses SMSC 91C111 as its Ethernet controller.

> I can see call to this  smc91c111_init(nd, 0x10010000, sic[25]); function is
> made inside hw/arm/versatilepb.c which triggers the initialization of
> emulated SMSC Ethernet controller in hw/net/smc91c111.c.

versatilepb is not a Cortex-A15 board, so neither
the QEMU code for it nor the kernel configuration
for it are relevant here.

> I am looking to emulate Ethernet controller based on
> Cortex-A15 platform,so for
> Do I need to use vexpress_defconfig instead of versatile_defconfig?
>
> If I have to use vexpress what would initializtion point of my emulated
> Ethernet controller based Cortex-A15 platform?

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?

> Would be inside vexpress_common_init() of vexpress.c
>
> /* 0x4e000000 LAN9118 Ethernet */
>     if (nd_table[0].used) {
>         lan9118_init(&nd_table[0], map[VE_ETHERNET], pic[15]);
>     }
>
> Could anyone please confirm this above understanding of mine?

You need to build a kernel configured for the board
model you want to use. In QEMU at the moment the
board models which support the Cortex-A15 are
'vexpress-a15' and the virtual-machine-only 'virt'.
The former uses a LAN9118 and the latter can
support a virtio-net networking device plugging
into the virtio-mmio transport.

thanks
-- PMM

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

[rajan pathak]

[-- Attachment #1: Type: text/plain, Size: 2571 bytes --]

Thanks Peter for your kind response.

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

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.

After that I will place my Emulated Ethernet controller code(which haven't
started)  inside hw/net .

Is the right way to go forward?

Thanks
Rajan



On Thu, Jan 23, 2014 at 11:42 AM, Peter Maydell <peter.maydell@linaro.org>wrote:

> On 23 January 2014 19:28, rajan pathak <rajanpatha34@gmail.com> wrote:
> > I have compiled the kernel using versatile_defconfig where I can see
> > CONFIG_SMC91X,So I guess it uses SMSC 91C111 as its Ethernet controller.
>
> > I can see call to this  smc91c111_init(nd, 0x10010000, sic[25]);
> function is
> > made inside hw/arm/versatilepb.c which triggers the initialization of
> > emulated SMSC Ethernet controller in hw/net/smc91c111.c.
>
> versatilepb is not a Cortex-A15 board, so neither
> the QEMU code for it nor the kernel configuration
> for it are relevant here.
>
> > I am looking to emulate Ethernet controller based on
> > Cortex-A15 platform,so for
> > Do I need to use vexpress_defconfig instead of versatile_defconfig?
> >
> > If I have to use vexpress what would initializtion point of my emulated
> > Ethernet controller based Cortex-A15 platform?
>
> 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?
>
> > Would be inside vexpress_common_init() of vexpress.c
> >
> > /* 0x4e000000 LAN9118 Ethernet */
> >     if (nd_table[0].used) {
> >         lan9118_init(&nd_table[0], map[VE_ETHERNET], pic[15]);
> >     }
> >
> > Could anyone please confirm this above understanding of mine?
>
> You need to build a kernel configured for the board
> model you want to use. In QEMU at the moment the
> board models which support the Cortex-A15 are
> 'vexpress-a15' and the virtual-machine-only 'virt'.
> The former uses a LAN9118 and the latter can
> support a virtio-net networking device plugging
> into the virtio-mmio transport.
>
> thanks
> -- PMM
>

[-- Attachment #2: Type: text/html, Size: 3481 bytes --]

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

[Peter Maydell]

On 23 January 2014 20:02, rajan pathak <rajanpatha34@gmail.com> wrote:
> To be very specific I am trying to emulate Ethernet controller of KeyStone 2
> device from TI
>
> 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.
>
> After that I will place my Emulated Ethernet controller code(which haven't
> started)  inside hw/net .

It seems unlikely that you can simply put an ethernet
controller from an entirely different SoC into the
vexpress board. A versatile express kernel will not be
looking for that SoC or device. Conversely, a kernel
compiled for the KeyStone II will expect to see the
devices present in that SoC, not the versatile express
ones. Embedded SoC devices are not generally
interchangeable between boards and kernels in this way,
though it is not totally impossible to hack something
together if you are prepared to mess with both QEMU
and the kernel.

Why do you need to emulate this specific ethernet
controller?

thanks
-- PMM

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

[Andreas Färber]

Am 23.01.2014 20:42, schrieb Peter Maydell:
> In QEMU at the moment the
> board models which support the Cortex-A15 are
> 'vexpress-a15' and the virtual-machine-only 'virt'.

Surely midway, too?

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

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

[Peter Maydell]

On 23 January 2014 21:42, Andreas Färber <afaerber@suse.de> wrote:
> Am 23.01.2014 20:42, schrieb Peter Maydell:
>> In QEMU at the moment the
>> board models which support the Cortex-A15 are
>> 'vexpress-a15' and the virtual-machine-only 'virt'.
>
> Surely midway, too?

Yes, sorry, I forgot about that one. The point in general
still stands, though.

thanks
-- PMM

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

[Andreas Färber]

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

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

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

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

[rajan pathak]

[-- Attachment #1: Type: text/plain, Size: 4795 bytes --]

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 <
peter.crosthwaite@xilinx.com> wrote:

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

[-- Attachment #2: Type: text/html, Size: 6188 bytes --]

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

[Peter Crosthwaite]

On Sat, Jan 25, 2014 at 5:18 PM, rajan pathak <rajanpatha34@gmail.com> 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
> <peter.crosthwaite@xilinx.com> wrote:
>>
>> On Fri, Jan 24, 2014 at 7:52 AM, Andreas Färber <afaerber@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
>> >
>
>

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

[rajan pathak]

[-- Attachment #1: Type: text/plain, Size: 7103 bytes --]

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 <
peter.crosthwaite@xilinx.com> wrote:

> On Sat, Jan 25, 2014 at 5:18 PM, rajan pathak <rajanpatha34@gmail.com>
> 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
> > <peter.crosthwaite@xilinx.com> wrote:
> >>
> >> On Fri, Jan 24, 2014 at 7:52 AM, Andreas Färber <afaerber@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
> >> >
> >
> >
>

[-- Attachment #2: Type: text/html, Size: 9258 bytes --]

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

[rajan pathak]

[-- Attachment #1: Type: text/plain, Size: 7558 bytes --]

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 <rajanpatha34@gmail.com>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 <
> peter.crosthwaite@xilinx.com> wrote:
>
>> On Sat, Jan 25, 2014 at 5:18 PM, rajan pathak <rajanpatha34@gmail.com>
>> 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
>> > <peter.crosthwaite@xilinx.com> wrote:
>> >>
>> >> On Fri, Jan 24, 2014 at 7:52 AM, Andreas Färber <afaerber@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
>> >> >
>> >
>> >
>>
>
>

[-- Attachment #2: Type: text/html, Size: 9952 bytes --]

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

[Peter Maydell]

On 25 January 2014 19:17, rajan pathak <rajanpatha34@gmail.com> wrote:
> Also, I am just wondering why anyone hasn't suggested me to look into TI
> OMAP emulation code present in QEMU.

Because it's pretty elderly and only supports up to OMAP2 (there's
some OMAP3 support out of tree).

Why do you need a model of this specific ethernet controller,
by the way?

thanks
-- PMM

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

[rajan pathak]

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]

Thanks Peter for addressing this query.

There is no specific reason going for this particular model of Ethernet
controller.

Its just that I wanted to learn it and off late I worked with Key Stone SoC
.

Also,can I use reuse some code from TI OMAP2 emulation to emulate basic
part of KeyStone SoC.

What are minimum components/Device emulation required to emulate Ethernet
Controller in my case?

Thanks
Rajan.





On Sat, Jan 25, 2014 at 11:25 AM, Peter Maydell <peter.maydell@linaro.org>wrote:

> On 25 January 2014 19:17, rajan pathak <rajanpatha34@gmail.com> wrote:
> > Also, I am just wondering why anyone hasn't suggested me to look into TI
> > OMAP emulation code present in QEMU.
>
> Because it's pretty elderly and only supports up to OMAP2 (there's
> some OMAP3 support out of tree).
>
> Why do you need a model of this specific ethernet controller,
> by the way?
>
> thanks
> -- PMM
>

[-- Attachment #2: Type: text/html, Size: 1529 bytes --]

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

[Andreas Färber]

Rajan,

You'll need to follow a few basic rules here working with our busy
community: Please don't send HTML-formatted replies and please don't
top-post, to make it easier for other people to understand the context.

Am 25.01.2014 20:47, schrieb rajan pathak:
> There is no specific reason going for this particular model of Ethernet
> controller.
> 
> Its just that I wanted to learn it and off late I worked with Key Stone
> SoC .
> 
> Also,can I use reuse some code from TI OMAP2 emulation to emulate basic
> part of KeyStone SoC.
> 
> What are minimum components/Device emulation required to emulate
> Ethernet Controller in my case?

Look, if we had all the time to analyze and implement all SoCs that are
out there, then KeyStone II would already be implemented and we wouldn't
be having this conversation in the first place. Reading the reference
manual and/or Linux driver code is part of the implementation job - you
can't expect us to know. We've been pointing you to how to implement a
SoC in general so that it not only works on your local machine but will
also be maintainable for us and thereby acceptable to include in the
main project. You've been therefore pointed to modern examples rather
than ancient, known-buggy, overly complicated code. Since the Allwinner
A10 is a Cortex-A8 and the DIGIC is ARM9, you'll need to look at some
other examples closer to Cortex-A15, too, possibly Versatile Express and
Midway. And this being an Open Source project, no one is stopping you
from reading OMAP2 code. You just can't copy 1:1 from there for good
results. Another example you can peek at for modern Cortex-A* MPCore
usage is my Cortex-A9 based Tegra2 emulation [1] (but beware, if it were
complete and 100% cleaned up, it would be in mainline already ;)).

Let me explain more verbosely why I pointed you to a proper SoC
implementation, hopefully that answers part of your question. In a PC
world you can just mix and match PCI ethernet cards with CPUs of
different vendors, using -device command line. For SoCs that doesn't
work, someone - the SoC device in modern code or formerly functions -
needs to wire the components together. And even if -device worked, MMIO
addresses or IRQ configuration might collide when mixing components of
different SoCs. Therefore it's cleaner, safer and more generally useful
to build from the bottom up. That is, CPU core, MPCore (which will
include GIC) - so far you can reuse existing code in a "Lego" manner -,
UART for testing output, your actual ethernet controller and possibly
anything its implementation or a stripped-down Linux guest turns out
depending on. If you're lucky then you can reuse an existing UART if TI
reused IP or a standardized register interface someone already
implemented, same for ethernet but less likely.

By contrast, implementing the C66x DSP engines is going to be virtually
impossible today (unless you model them as a blackbox for a fixed
firmware, which would be use case specific).

To avoid complications later, [2] may be a good read in advance, in
particular the sections on splitting up patches for review and not
including unrelated bits. Feel free to send early RFC patches, people
are usually happier to discuss patches than theory. :) [3] may serve as
intro to model writing and [4] summarizes some more recent guidelines.

Hope that helps get you started,

Andreas

[1] http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/tegra
[2] http://wiki.qemu.org/Contribute/SubmitAPatch
[3] http://www.linux-kvm.org/wiki/images/f/f6/2012-forum-QOM_CPU.pdf
[4] http://wiki.qemu.org/QOMConventions

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

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

[Peter Maydell]

On 25 January 2014 19:47, rajan pathak <rajanpatha34@gmail.com> wrote:
> There is no specific reason going for this particular model of Ethernet
> controller.
>
> Its just that I wanted to learn it and off late I worked with Key Stone SoC

If this is a learning exercise in how to write QEMU device models
rather than a specific requirement for this exact ethernet controller,
you may find it better to look at adding some missing device to
one of our existing board models. This will:
 (a) be a much simpler and smaller piece of work, because you only
     need to implement a single device, not an entire large and
     complex SoC
 (b) be useful to other people who are already using
     that QEMU board model

Or you could model a PCI ethernet card, which will then be
usable with any QEMU board which has a PCI controller
(this is less generally useful to the community though since
we already have several good PCI ethernet card models).

thanks
-- PMM