From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43072) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X6khM-0004fR-FE for qemu-devel@nongnu.org; Mon, 14 Jul 2014 14:10:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X6khE-0007ZF-W8 for qemu-devel@nongnu.org; Mon, 14 Jul 2014 14:10:00 -0400 Received: from mail.tu-berlin.de ([130.149.7.33]:11131) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X6khE-0007Xd-QT for qemu-devel@nongnu.org; Mon, 14 Jul 2014 14:09:52 -0400 Message-ID: <53C41CEC.5030705@campus.tu-berlin.de> Date: Mon, 14 Jul 2014 20:09:48 +0200 From: Alexander Graf MIME-Version: 1.0 References: <53C295C8.5040309@antistatix.de> <53C3C32A.4060705@redhat.com> In-Reply-To: <53C3C32A.4060705@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] hw/arm: add Lego NXT board List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , qemu-devel@nongnu.org Cc: peter.maydell@linaro.org On 07/14/2014 01:46 PM, Paolo Bonzini wrote: > Il 13/07/2014 16:20, Alexander Graf ha scritto: >> The >> environment simulator is an external program which is connected to >> several qemu instances via posix named pipes using a simple >> communication protocol. Without pipe interaction the emulator can still >> be used to debug NXT firmware images without sensor/actuator interaction. > > What does your protocol look like, and what kind of bus do the actual > sensors and actuators use? > > If it is I2C or SPI, having generic i2c-over-chardev or spi-over-chardev > protocols and devices would be a nice addition to QEMU. The actual sensor hardware is not emulated. This was not required for my demand to inject sonsor values. I use an abstraction over the sensor hardware using IO memory. My firmware is something like: uint32_t readUltrasonicSensor() { #ifdef QEMU_SIMULATION_IMAGE // This triggers pipe communication in Qemu // No hardware emulation return SOME_IO_MEMORY_REGISTER_SPECIFIC_FOR_THE_SENSOR; #else // do the actual I2C bus transaction to read the value #endif } So the protocol basically allows to forward read and write accesses on IO memory to processes outside of Qemu. My protocol uses two named pipes as transport. One from Qemu to an outside process and one back into Qemu. It is a binary protocol with basically three messages: get: request: REQUEST_GET | uint16_t sequence # | uint16_t requested register response: uint16_t sequence # | uint32_t register content set: request: REQUEST_SET | uint16_t sequence # | uint16_t register | uint32_t register value response: uint16_t sequence # sync tick: request: REQUEST_TICK | uint16_t sequence # response: uint16_t sequence # Get and set transactions are triggered by Qemu on an IO memory read operation or write operation respectively. The pipe communication blocks Qemu until a value is available/the value was published. The sync tick operation is to tell the remote process that the system tick timer interrupt has occured. (Another requirement for my SIL simulator.) For a generic memory-io-over-chardev device this could be removed. In addition for a truly generic implementation the memory access size (byte, word, ... access) needs to be integrated into the protocol. I like the *-over-chardev idea. This could be a benefit for people who want to couple simulators or test oracles for embedded system tests or in general to other software in a simple way. Regards Alexander