From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HYkZP-0006Bv-M2 for qemu-devel@nongnu.org; Tue, 03 Apr 2007 11:05:15 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HYkZP-0006Bj-4u for qemu-devel@nongnu.org; Tue, 03 Apr 2007 11:05:15 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HYkZP-0006Bg-2R for qemu-devel@nongnu.org; Tue, 03 Apr 2007 11:05:15 -0400 Received: from wr-out-0506.google.com ([64.233.184.226]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HYkWE-0000tM-Rz for qemu-devel@nongnu.org; Tue, 03 Apr 2007 11:01:59 -0400 Received: by wr-out-0506.google.com with SMTP id i20so3207695wra for ; Tue, 03 Apr 2007 08:01:58 -0700 (PDT) Message-ID: Date: Tue, 3 Apr 2007 17:01:57 +0200 From: "andrzej zaborowski" Sender: balrogg@gmail.com Subject: Re: [Qemu-devel] Simtec BAST emulation In-Reply-To: <1175594976.8149.6.camel@petitemort.i.digital-scurf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1175522199.18271.19.camel@petitemort.i.digital-scurf.org> <1175594976.8149.6.camel@petitemort.i.digital-scurf.org> Reply-To: balrogg@gmail.com, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dsilvers@simtec.co.uk Cc: qemu-devel@nongnu.org Hi, On 03/04/07, Daniel Silverstone wrote: > On Tue, 2007-04-03 at 01:04 +0200, andrzej zaborowski wrote: > > We have also implemented emulation of the S3C2410x SoC. I hope we can > > merge both implementations to come up with better emulation. Our tree > > is accessible at http://svn.openmoko.org/trunk/src/host/qemu-neo1973/ > > and our main target machine is the FIC Neo1973 which you mention > > above. The tree is still heavily a work-in-progress but the processor > > part (S3C2410 with on-chip preripherals) is quite mature. > > Perhaps we should work together to get your processor core merged into > QEMU proper? I could work on patching our BAST stuff against your core > and then together we could look at getting it merged. Agreed, that would be very nice. I'm going to try to add the watchdog timer this week and get the S3C2410 part of the tree into some clean state. The watchdog timer is very low priority but Linux uses it for rebooting, so let's have it in for completeness as it's not so easy to get improvements merged into qemu tree later. My concern with preparing and submitting patches at this moment, or even syncing the openmoko tree with CVS changes, is that we submitted patches for PXA2xx SoC processors emulation some two weeks ago and the S3C2410 uses a number of the same structures as PXA2xx (e.g the NAND emulator, SD card, I2C framework, some GPIO bits). These patches have not been merged, but also have not been rejected. Paul Brook (*poke*) expressed that he is willing to merge them when he has time, and I know that he will make lots of changes when he's applying them (which is good), so the openmoko tree will have to be rebased anyway. > > > All of the on-chip peripherals described in the S3C2410A User Manual > > rev 1.0 except the Watchdog timer and USB Slave are emulated with high > > level of detail. The OHCI USB uses the same routine as the PXA2xx > > emulator. > > That sounds excellent. Far further than we had gotten thus-far. > > > Things that are tested to work: > > OpenMoko firmware from the real device boots as a NAND Flash image. > > Cool. Is the NAND format with, or without OOB? Normally it is with OOB. Here's how it works: On init, hw/nand.c takes only the manufacturer and chip IDs as arguments and based on a table of chip IDs it looks up the size of the chip. Now, if a NAND image was given on commandline with "-mtblock" it will read and write data to this image, otherwise the initial state of the memory is filled with 0xff bytes and changes are only stored in memory. Now, if the size of the image is greater or equal (number of pages) * (page size + OOB size) then the image is interpreted as page data interleaved with OOB data. If it's below this value then it is taken the image contains only page data, and OOB part is malloc()ed, initially filled with 0xff bytes. > > > The OpenMoko rootfs can also be booted off the emulated SD card. We > > use the u-boot and kernel images from the original device. Input is > > through GPIO buttons or touchscreen connected to the on-chip ADC, > > output through on-chip UARTs and LCD. Audio through a codec connected > > to on-chip I2C and I2S busses. > > Out of interest, which codec is it? It's the Wolfson Microsystems WM8753. The tree also has WM8750. > > > There is also an SPI-connected > > peripheral (can be driven either through the on-chip SPI interface or > > GPIO bit-banging). > > *nod* > > > S3C2410 idle mode is supported. > > Aha, this is wonderful news. > > > There's no save/restore support. > > Hmm, perhaps we could work on that together. This would be very nice. > > > Apparently there's some code duplication, which is sad but I hope we > > can get both machines (BAST and Neo1973) to use common code. Briefly > > looking at your patch, the openmoko tree seems to have a more > > complete/specs-conformant S3C2410 part. > > Yes, our S3C2410 part was only as far as we needed to get Linux and ABLE > booting on the emulator. Yours is much more mature and really deserves > to be merged once we can get a system emulation in place which you're > happy to offer for merging. > > I assume you too have noticed that the longer you leave it before > offering patches for merging, the scarier the diff becomes. Yes, but I also notice the way qemu tree is maintained, "release early, realease often" wouldn't work very well. > > I will take a look at your tree and at how hard it will be to merge the > Simtec board emulation into it. I hope it's not too difficult, we're trying to use APIs similar to those in the rest of qemu. Maybe looking at hw/neo1973.c can help getting some things right if you're willing to rebase the BAST board to use S3C2410 from openmoko tree. This would very nice as then we could work with only one implementation of S3C2410. To quickly get a working Neo1973 emulator, I've put some demo instructions at http://wiki.openmoko.org/wiki/OpenMoko_under_QEMU Regards, Andrzej