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
