Re: [Qemu-devel] qemu vl.h hw/arm_boot.c hw/integratorcp.c hw/re...
On Mon, 2007-04-30 at 02:24 +, Andrzej Zaborowski wrote: Account for machine with RAM which is not mapped at 0x0 in arm_boot.c. It seems a pity that you did this in a manner which didn't match the patch I published for the Simtec BAST boards. Now I have a bunch more merging effort to go through if I'm ever to get this patch merged. (Not that anyone has said a word to me since I posted it having solved all the issues that pbrook raised) In particular you call the variable loader_start which seems somewhat misleading since essentially what it is is the emulated_sdram_base which is what I called it. I guess I'll have to do some serious merge work into my working tree and then post another patch. If you're interested. If not then I'll just carry on in my own little world and not bother with submitting to trunk, which seems a serious pity as it simply ends up being more work for all concerned and it forks the project. Hopefully we can come to some agreement about this which isn't a schism in processes. Regards, Daniel -- Daniel Silverstone http://www.simtec.co.uk/ PGP mail accepted and encouraged.Key Id: 2BC8 4016 2068 7895
Re: [Qemu-devel] Simtec BAST emulation
On Mon, 2007-04-02 at 18:45 +0100, Paul Brook wrote: A few issues with the patch, which I think need to be resolved before it can be applied: - You're using global structures to store machine state. While it's debatable whether you'll ever have more than one s3c2410, I think it's definitely still worth allowing for this possibility, and encapsulating the state in a structure, like all the other hardware emulation does. Yes, I concur, this is my next goal. - For the device emulation (dm9000 and ide, maybe others) you should use pic_set_irq_new, instead of passing a separate set_irq function. Other ARM boards already support arbitrary routing of interrupts via hw/arm_pic.[ch]. pic_set_irq_new appears to be missing from trunk unless I'm mistaken or confused. However hw/irq.[ch] seemed like a nice place to start, so I've made the s3c2410x_irq stuff use that, and ported all the other drivers we wrote to this. It has unfortunately added more global state for the s3c2410x which I will work on factoring into a new structure next. - usb_ohci_mmap_init should look more like (or even be the same function as) usb_ohci_init_pxa. I am now using usb_ohci_init_pxa for this. What is the licence for ABLE? Would we be able to distribute it with qemu? ABLE is not going to be distributable *with* qemu, however it may be possible to ensure that the licence is such that anyone wishing to use ABLE with qemu will be allowed to in a free-beer sense by downloading it from Simtec's website. Would you mind casting your eye over the attached diff and tell me if I went the right way with the IRQ stuff? I'll get on with deglobalising (localising?) the s3c2410x state next. D. -- Daniel Silverstone http://www.simtec.co.uk/ PGP mail accepted and encouraged.Key Id: 2BC8 4016 2068 7895
Re: [Qemu-devel] qemu-img qcow and raw format
On Thu, 2007-04-12 at 10:09 +0200, Francois Visconte wrote: qemu-img: Could not open 'deploy-in.fifo' Is there any way to achieve this goal ? It strikes me that it's likely qemu-img assumes it can seek around in the file it is reading from, so perhaps you'll have to look at modifying qemu-img to support a stream mode? D. (Note this is just a guess) -- Daniel Silverstone http://www.digital-scurf.org/ PGP mail accepted and encouraged.Key Id: 2BC8 4016 2068 7895
Re: [Qemu-devel] Simtec BAST emulation
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. 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? 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? 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. 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. I will take a look at your tree and at how hard it will be to merge the Simtec board emulation into it. Thanks, Daniel. -- Daniel Silverstone http://www.simtec.co.uk/ PGP mail accepted and encouraged.Key Id: 2BC8 4016 2068 7895
Re: [Qemu-devel] Simtec BAST emulation
On Mon, 2007-04-02 at 18:45 +0100, Paul Brook wrote: A few issues with the patch, which I think need to be resolved before it can be applied: - You're using global structures to store machine state. While it's debatable whether you'll ever have more than one s3c2410, I think it's definitely still worth allowing for this possibility, and encapsulating the state in a structure, like all the other hardware emulation does. Right, I've basically decided that we're going to go with the OpenMoko core emulation if it turns out to be sensible. However the global state comment is a good one. It's one thing I wasn't quite happy with, but in the end we did it for simplicity since having more than one s3c2410 would be strange. - For the device emulation (dm9000 and ide, maybe others) you should use pic_set_irq_new, instead of passing a separate set_irq function. Other ARM boards already support arbitrary routing of interrupts via hw/arm_pic.[ch]. Right, the interrupt controller on the S3C2410 didn't seem to fit with the hw/arm_pic stuff, but yes, perhaps the separate set_irq stuff was a touch heavy handed. - usb_ohci_mmap_init should look more like (or even be the same function as) usb_ohci_init_pxa. Aha, I'd not spotted that, thanks. The emulation is complete enough to start Simtec's ABLE boot loader (downloadable from www.simtec.co.uk) and also is capable of being direct-booted with a linux kernel/initrd combination as per the versatile etc. What is the licence for ABLE? Would we be able to distribute it with qemu? Unfortunately I don't think so. However I could ask my boss. D. -- Daniel Silverstone http://www.simtec.co.uk/ PGP mail accepted and encouraged.Key Id: 2BC8 4016 2068 7895
