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