From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MiSlL-0004dP-Vm for qemu-devel@nongnu.org; Tue, 01 Sep 2009 08:47:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MiSlH-0004Yj-E3 for qemu-devel@nongnu.org; Tue, 01 Sep 2009 08:47:00 -0400 Received: from [199.232.76.173] (port=57174 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MiSlG-0004YN-9e for qemu-devel@nongnu.org; Tue, 01 Sep 2009 08:46:58 -0400 Received: from n20.bullet.mail.ukl.yahoo.com ([87.248.110.137]:34004) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MiSlF-0007JW-Lr for qemu-devel@nongnu.org; Tue, 01 Sep 2009 08:46:58 -0400 Message-ID: <348599.74411.qm@web27002.mail.ukl.yahoo.com> Date: Tue, 1 Sep 2009 05:46:56 -0700 (PDT) From: bifferos MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Qemu GPIO support List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Greetings,=0A=0AI thought I should probably announce here my work on GPIO s= upport for Qemu. I've favoured correctness of operation and flexibility ove= r speed, since I'm generally emulating embedded devices anyhow.=0A=0AHere a= re the requirements:=0A=0A1) Multiple peripherals can be connected to the s= ame pins=0A2) Multiple machines (Qemu instances) can be connected to the sa= me pins=0A3) The system must arbitrate to determine pin state, and take int= o account pull-up resistors, and signal when pins are in contention=0A4) Pe= ripherals can be unplugged at any time=0A5) Machines can be unplugged at an= y time=0A6) The system should be as efficient as possible given the above r= equirements.=0A7) The system should be portable (Windows, Linux)=0A8) The s= ystem should allow writing peripherals in any programming language=0A=0AThe= approach I've adopted was to write a tcp socket server to which Qemu and o= ther peripherals can connect to. The closest analogy is that it behaves as= a terminal block. Clients connect, inform the server which pins they are = connecting to, and whether they are passively pulled high, actively driven = high, or actively driven low. The server then arbitrates and tells the cli= ents what the pins values are when asked. They can be either logic '1', '0= ' or in contention. Clients can subscribe to pin changes (useful for perip= herals), or they can simply poll (the Qemu client(s) will generally do this= )=0A=0AFor the moment, I have implemented the server, a Qemu patch to acces= s =0Asome gpio pins via PCI northbridge (this is how RDC chips do it, other= =0Ax86 systems will just use basic IO ports), and also a trivial LED emulat= ion client.=0A=0AAll this stuff can be seen in action over here:=0Ahttp://s= ites.google.com/site/bifferboard/Home/howto/qemu=0A=0AIt is currently heavi= ly biased towards the Bifferboard, which is a =0A1W x86-compatible controll= er, but can easily be adapted to other x86 machines, probably other archite= ctures can use the same approach.=0A=0AI will be adding MMC/HD47780/i2c/but= ton emulation and so on as time permits.=0A=0Acheers,=0ABiff.=0A=0A=0A=0A= =0A=0A