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.crosthwa...@xilinx.com> wrote:
> On Sat, Jan 25, 2014 at 5:18 PM, rajan pathak <rajanpath...@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.crosthwa...@xilinx.com> wrote:
> >>
> >> 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
> >> >
> >
> >
>
