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