Re: [Qemu-devel] [PATCH 07/13] mxs/imx23: Implements the pin mux, GPIOs
All noted, and thanks for all the bits you reviewed so far, I'll do the
changes and resubmit.
M
On 6 January 2014 15:52, Peter Maydell peter.mayd...@linaro.org wrote:
On 11 December 2013 13:56, Michel Pollet buser...@gmail.com wrote:
Implements the pinctrl and GPIO block for the imx23
It handles GPIO output, and GPIO input from qemu translated
into pin values and interrupts, if appropriate.
Signed-off-by: Michel Pollet buser...@gmail.com
---
hw/arm/Makefile.objs | 2 +-
hw/arm/imx23_pinctrl.c | 293
+
2 files changed, 294 insertions(+), 1 deletion(-)
create mode 100644 hw/arm/imx23_pinctrl.c
diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index 9adcb96..ea53988 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -5,4 +5,4 @@ obj-y += tosa.o versatilepb.o vexpress.o virt.o
xilinx_zynq.o z2.o
obj-y += armv7m.o exynos4210.o pxa2xx.o pxa2xx_gpio.o pxa2xx_pic.o
obj-y += omap1.o omap2.o strongarm.o
-obj-$(CONFIG_MXS) += imx23_digctl.o
+obj-$(CONFIG_MXS) += imx23_digctl.o imx23_pinctrl.o
diff --git a/hw/arm/imx23_pinctrl.c b/hw/arm/imx23_pinctrl.c
new file mode 100644
index 000..ecfb755
--- /dev/null
+++ b/hw/arm/imx23_pinctrl.c
@@ -0,0 +1,293 @@
+/*
+ * imx23_pinctrl.c
+ *
+ * Copyright: Michel Pollet buser...@gmail.com
+ *
+ * QEMU Licence
+ */
+
+/*
+ * Implements the pinctrl and GPIO block for the imx23
+ * It handles GPIO output, and GPIO input from qemu translated
+ * into pin values and interrupts, if appropriate.
+ */
+#include hw/sysbus.h
+#include hw/arm/mxs.h
+
+#define D(w)
+
+enum {
+PINCTRL_BANK_COUNT = 3,
+
+PINCTRL_CTRL = 0,
+PINCTRL_BANK_MUXSEL = 0x10,
+PINCTRL_BANK_BASE = 0x40,
+
+/* these are not 4 register numbers, these are 8 register
numbers */
+PINCTRL_BANK_PULL = 0x4,
+PINCTRL_BANK_OUT = 0x5,
+PINCTRL_BANK_DIN = 0x6,
+PINCTRL_BANK_DOE = 0x7,
+PINCTRL_BANK_PIN2IRQ = 0x8,
+PINCTRL_BANK_IRQEN = 0x9,
+PINCTRL_BANK_IRQLEVEL = 0xa,
+PINCTRL_BANK_IRQPOL = 0xb,
+PINCTRL_BANK_IRQSTAT = 0xc,
+
+PINCTRL_BANK_INTERNAL_STATE = 0xd,
+PINCTRL_MAX = 0xe0,
+};
+
+#define PINCTRL_BANK_REG(_bank, _reg) ((_reg 8) | (_bank 4))
+
+enum {
+MUX_GPIO = 0x3,
+};
+
+
+typedef struct imx23_pinctrl_state {
+SysBusDevice busdev;
+MemoryRegion iomem;
+
+uint32_t r[PINCTRL_MAX];
+qemu_irq irq_in[3];
+qemu_irq irq_out[PINCTRL_BANK_COUNT * 32];
+
+uint32_t state[PINCTRL_BANK_COUNT];
+} imx23_pinctrl_state;
+
+static uint64_t imx23_pinctrl_read(
+void *opaque, hwaddr offset, unsigned size)
+{
+imx23_pinctrl_state *s = (imx23_pinctrl_state *) opaque;
+uint32_t res = 0;
+
+switch (offset 4) {
+case 0 ... PINCTRL_MAX:
+res = s-r[offset 4];
+break;
+default:
+qemu_log_mask(LOG_GUEST_ERROR,
+%s: bad offset 0x%x\n, __func__, (int) offset);
+break;
+}
+
+return res;
+}
+
+static uint8_t imx23_pinctrl_getmux(
+imx23_pinctrl_state *s, int pin)
+{
+int base = pin / 16, offset = pin % 16;
+return (s-r[PINCTRL_BANK_MUXSEL + base] (offset * 2)) 0x3;
+}
+
+/*
+ * usage imx23_pinctrl_getbit(s, PINCTRL_BANK_IRQEN, 48)...
+ */
+static uint8_t imx23_pinctrl_getbit(
+imx23_pinctrl_state *s, uint16_t reg, int pin)
+{
+int bank = pin / 32, offset = pin % 32;
+uint32_t * latch = s-r[PINCTRL_BANK_REG(bank, reg) 4];
+//printf(%s bank %d offset %d reg %d : %04x=%08x\n, __func__,
bank, offset, reg,
+//PINCTRL_BANK_REG(bank, reg),
+//*latch);
+return (*latch offset) 0x1;
+}
+
+static void imx23_pinctrl_setbit(
+imx23_pinctrl_state *s, uint16_t reg, int pin, int value)
+{
+int bank = pin / 32, offset = pin % 32;
+uint32_t * latch = s-r[PINCTRL_BANK_REG(bank, reg) 4];
+*latch = (*latch ~(1 offset)) | (!!value offset);
deposit32() will make this clearer to read.
+}
+
+static void imx23_pinctrl_write_bank(
+imx23_pinctrl_state *s, int bank,
+int reg, uint32_t value,
+uint32_t mask)
+{
+int set, pin;
+switch (reg) {
+/*
+ * Linux has a way of using the DOEPULL register to toggle the
pin
+ */
Why is this comment here? We should ideally not care what
guest OS we run, we should just implement the h/w correctly.
+case PINCTRL_BANK_PULL:
+case PINCTRL_BANK_DOE:
+/*
+ * Writing to the Data OUT register just triggers the
+ * output qemu IRQ for any further peripherals
+ */
+case PINCTRL_BANK_OUT: {
+while ((set = ffs(mask)) 0) {
+
Re: [Qemu-devel] [PATCH 06/13] mxs/imx23: Add digctl driver
On 6 January 2014 15:46, Peter Maydell peter.mayd...@linaro.org wrote:
On 11 December 2013 13:56, Michel Pollet buser...@gmail.com wrote:
This implements just enough of the digctl IO block to allow
linux to believe it's running on (currently only) an imx23.
Signed-off-by: Michel Pollet buser...@gmail.com
---
hw/arm/Makefile.objs | 1 +
hw/arm/imx23_digctl.c | 110
++
2 files changed, 111 insertions(+)
create mode 100644 hw/arm/imx23_digctl.c
diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index 78b5614..9adcb96 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -5,3 +5,4 @@ obj-y += tosa.o versatilepb.o vexpress.o virt.o
xilinx_zynq.o z2.o
obj-y += armv7m.o exynos4210.o pxa2xx.o pxa2xx_gpio.o pxa2xx_pic.o
obj-y += omap1.o omap2.o strongarm.o
+obj-$(CONFIG_MXS) += imx23_digctl.o
diff --git a/hw/arm/imx23_digctl.c b/hw/arm/imx23_digctl.c
new file mode 100644
index 000..b7cd1ff
--- /dev/null
+++ b/hw/arm/imx23_digctl.c
@@ -0,0 +1,110 @@
+/*
+ * imx23_digctl.c
+ *
+ * Copyright: Michel Pollet buser...@gmail.com
+ *
+ * QEMU Licence
+ */
+
+/*
+ * This module implements a very basic IO block for the digctl of the
imx23
+ * Basically there is no real logic, just constant registers return,
the most
+ * used one bing the chip id that is used by the various linux drivers
+ * to differentiate between imx23 and 28.
+ *
+ * The module consists mostly of read/write registers that the
bootloader and
+ * kernel are quite happy to 'set' to whatever value they believe they
set...
+ */
+
+#include hw/sysbus.h
+#include hw/arm/mxs.h
+
+enum {
+HW_DIGCTL_RAMCTL = 0x3,
+HW_DIGCTL_CHIPID = 0x31,
+};
+
+typedef struct imx23_digctl_state {
+SysBusDevice busdev;
+MemoryRegion iomem;
+
+uint32_t reg[0x2000 / 4];
+} imx23_digctl_state;
I'm not generally a fan of big reg[] array like this.
In real hardware are these typically constant read/only
registers, or do they actually do something? Does the
hardware really have a full set of 2048 registers here,
or are there gaps?
This block contains most of the 'general purpose' registers, ram timing and
all that jazz; there are a lot of write to it at init time, but it's
otherwise mostly ignored. Also, there's very little to do about it
functionally for qemu's purpose.
I'd rather have us implement just the minimal set
required for things to boot, with LOG_UNIMP (and
read-zero/write-ignored) for the rest. That makes
it easier to add actual implementations later
(and your migration state is not 0x2000 bytes of random
undifferentiated stuff).
I will re-add the trace for both write and read and see if I can narrow the
range down; it will be linux specific, tho, that's why I thought a
'catchall' block was more appropriate.
thanks
-- PMM
Thanks,
M
Re: [Qemu-devel] [PATCH 00/13] Freescale mxs/imx23 + Olimex Olinuxino support
Can someone give me a pointer on how the review (if any) is done for these patches? I have to say I'm rather amazed at the rate of submission on the mailing list, and I worried to see these patches buried further and further down in such a short timescale :-) Michael On Wed, Dec 11, 2013 at 1:56 PM, Michel Pollet buser...@gmail.com wrote: This series adds support for the imx233 SoC, and also adds support for emulating an Olinux Olinuxino board with a few peripherals, as a test harness. The emulation works pretty well, boots linux 3.12 vanilla from an emulated SD card, has USB bridge support (but no support for USB 1.1 devices like mouse+keyboard), RTC and quite a few other bits (some of them fairly skeletal) This series has been in used for quite a few months; it was posted here a few month back and one of the question was to wether I would stick around to support it. Perhaps the fact that I reworked it all on trunk and reposted it will help answer this question. This patch series is also available on this github branch, in case its' more convenient to use the inline comment function there. https://github.com/buserror-uk/qemu-buserror/commits/dev-imx233 Michel Pollet (13): mxs/imx23: Add main header file mxs: Add CONFIG_MXS to the arm-softmmu config mxs/imx23: Add uart driver mxs/imx23: Add DMA driver mxs/imx23: Add the interrupt collector mxs/imx23: Add digctl driver mxs/imx23: Implements the pin mux, GPIOs mxs/imx23: Add SSP/SPI driver mxs/imx23: Add the RTC block mxs/imx23: Add the timers mxs/imx23: Add the USB driver mxs/imx23: Main core instantiation and minor IO blocks mxs/imx23: Adds support for an Olinuxino board default-configs/arm-softmmu.mak | 1 + hw/arm/Makefile.objs| 2 + hw/arm/imx233-olinuxino.c | 169 + hw/arm/imx23_digctl.c | 110 hw/arm/imx23_pinctrl.c | 293 ++ hw/arm/mxs.c| 388 hw/arm/mxs.h| 208 + hw/char/Makefile.objs | 1 + hw/char/mxs_uart.c | 146 +++ hw/dma/Makefile.objs| 1 + hw/dma/mxs_dma.c| 347 +++ hw/intc/Makefile.objs | 1 + hw/intc/mxs_icoll.c | 200 + hw/ssi/Makefile.objs| 1 + hw/ssi/mxs_spi.c| 239 + hw/timer/Makefile.objs | 1 + hw/timer/mxs_rtc.c | 147 +++ hw/timer/mxs_timrot.c | 271 hw/usb/Makefile.objs| 1 + hw/usb/mxs_usb.c| 254 ++ 20 files changed, 2781 insertions(+) create mode 100644 hw/arm/imx233-olinuxino.c create mode 100644 hw/arm/imx23_digctl.c create mode 100644 hw/arm/imx23_pinctrl.c create mode 100644 hw/arm/mxs.c create mode 100644 hw/arm/mxs.h create mode 100644 hw/char/mxs_uart.c create mode 100644 hw/dma/mxs_dma.c create mode 100644 hw/intc/mxs_icoll.c create mode 100644 hw/ssi/mxs_spi.c create mode 100644 hw/timer/mxs_rtc.c create mode 100644 hw/timer/mxs_timrot.c create mode 100644 hw/usb/mxs_usb.c -- 1.8.5.1
Re: [Qemu-devel] [PATCH 00/13] Freescale mxs/imx23 + Olimex Olinuxino support
Thanks Peter, very helpful -- and err, sorry to land you more work than you already had :-) Would I contribute anything by also reviewing and/or testing the sus mentioned patches? I can at least test the A10 and raspi if this helps... M On Fri, Dec 13, 2013 at 1:29 PM, Peter Maydell peter.mayd...@linaro.orgwrote: On 13 December 2013 12:53, M P buser...@gmail.com wrote: Can someone give me a pointer on how the review (if any) is done for these patches? I have to say I'm rather amazed at the rate of submission on the mailing list, and I worried to see these patches buried further and further down in such a short timescale :-) The rough process is: * people reply to your email with review comments; when you've accumulated enough you send out a fixed set of patches for further review * if nobody replies at all within say 2 weeks you can send out a 'ping' followup to this coverletter to bring the set back to peoples' attention http://wiki.qemu.org/Contribute/SubmitAPatch is where we try to describe how the process works. In this particular case, I have tagged your mail in my mail client as 'must-review'; however since my review queue is currently pretty full (you're one of four new ARM board/soc support patchsets, the others being Allwinner A10, Canon DIGIC and RaspberryPi; then there's the TrustZone support patchset and all the 64 bit support work) I'm afraid I can't currently promise a particularly rapid turnaround time. If you can find the mail threads relating to the other recent board/soc support patchsets I listed above and look through review comments to see if any of them would apply to your board that would probably help. thanks -- PMM
[Qemu-devel] [PATCH] ds18s20: Add onewire thermal sensor
Support for a dallas/maxim onewire sensor, enough of it to
fool linux's w1-gpio driver
Signed-off-by: Michel Pollet buser...@gmail.com
---
hw/misc/Makefile.objs | 2 +
hw/misc/w1-ds18s20.c | 332
++
2 files changed, 334 insertions(+)
create mode 100644 hw/misc/w1-ds18s20.c
diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index f674365..b42c231 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -42,3 +42,5 @@ obj-$(CONFIG_SLAVIO) += slavio_misc.o
obj-$(CONFIG_ZYNQ) += zynq_slcr.o
obj-$(CONFIG_PVPANIC) += pvpanic.o
+
+obj-y += w1-ds18s20.o
diff --git a/hw/misc/w1-ds18s20.c b/hw/misc/w1-ds18s20.c
new file mode 100644
index 000..cea3d6e
--- /dev/null
+++ b/hw/misc/w1-ds18s20.c
@@ -0,0 +1,332 @@
+/*
+ * w1-ds18s20.c
+ *
+ * Copyright: Michel Pollet buser...@gmail.com
+ *
+ * QEMU Licence
+ */
+
+/*
+ * This device will behave like a DS18S20 onewire temperature sensor,
+ * Linux's w1-gpio driver will be fooled into talking to it.
+ *
+ * w1-gpio (and other onewire masters?) attempts to fudge the bit timing
+ * to try to adapt to 'bad' wires, most real hardware sensors must have a
+ * PLL of sort are seems to be able to adapt, this implementation doesn't
+ * and 'sometime' drops from the bus for a short time, in a way it's
+ * rather nice as it simulates a moderately bad wire.
+ *
+ * To instantiate this driver, you just need one IRQ in and out, there
+ * is a second input IRQ to set the temperature. A nice 'todo' would
+ * possibly to have a monitor command to do so.
+ *
+ * Another nice todo would possibly be to handle a proper qemu 'bus'
+ * and have a way to specify the hardware ID of the device.
+ *
+ * Example instantiation for this device:
+{
+DeviceState * dev = sysbus_create_simple(ds18s20, -1, 0);
+
+qdev_connect_gpio_out(gpio, GPIO_W1, qdev_get_gpio_in(dev, 0));
+qdev_connect_gpio_out(dev, 0, qdev_get_gpio_in(gpio, GPIO_W1));
+}
+ * Test case (assuming your w1-gpio knows it's GPIO from a .dts):
+/ # modprobe w1-therm
+/ # modprobe w1-gpio
+/ # cat /sys/bus/w1/devices/28-deadbeeff00d/w1_slave
+50 05 8d e0 ff fd 03 40 14 : crc=cb NO
+00 00 00 00 00 00 00 00 00 t=85000
+/ # cat /sys/bus/w1/devices/28-deadbeeff00d/w1_slave
+50 05 0d f0 7f ff 00 10 45 : crc=45 YES
+50 05 0d f0 7f ff 00 10 45 t=85000
+ *
+ */
+#include hw/sysbus.h
+
+
+#define D(w)
+
+typedef struct OneWireDevice {
+SysBusDevice busdev;
+MemoryRegion dummy_iomem;
+
+qemu_irqout;
+
+int current_temp_mc;// in millicelcius
+uint64_tw1_id; // full w1 ID, including CRC
+uint64_tw1_id_received; // for comparisons
+int muted; // set to 1 when 'offline' awaiting
start
+int addr_bit; // current address bit sent/received
+
+int64_t stamp; // timestamp of last low edge
+
+uint8_t write_buffer; // incoming bits from master
+int write_count;
+uint64_tread_buffer;// outgoing bits to master
+int read_count;
+uint8_t read_crc; // CRC, for scratchpad
+uint8_t command;// current command
+} OneWireDevice;
+
+enum {
+W1_CMD_SEARCH_ROM = 0xf0,
+W1_CMD_MATCH_ROM = 0x55,
+W1_CMD_SKIP_ROM = 0xcc,
+W1_CMD_READ_PSU = 0xb4,
+W1_CMD_CONVERT_TEMP = 0x44,
+W1_CMD_READ_SCRATCHPAD = 0xbe,
+// MISSING write scratchpad, unused in linux
+};
+
+/* CRC bits here were nicked from linux's */
+static uint8_t w1_crc8_table[] = {
+0, 94, 188, 226, 97, 63, 221, 131, 194, 156, 126, 32, 163, 253, 31, 65,
+157, 195, 33, 127, 252, 162, 64, 30, 95, 1, 227, 189, 62, 96, 130, 220,
+35, 125, 159, 193, 66, 28, 254, 160, 225, 191, 93, 3, 128, 222, 60, 98,
+190, 224, 2, 92, 223, 129, 99, 61, 124, 34, 192, 158, 29, 67, 161, 255,
+70, 24, 250, 164, 39, 121, 155, 197, 132, 218, 56, 102, 229, 187, 89,
7,
+219, 133, 103, 57, 186, 228, 6, 88, 25, 71, 165, 251, 120, 38, 196,
154,
+101, 59, 217, 135, 4, 90, 184, 230, 167, 249, 27, 69, 198, 152, 122,
36,
+248, 166, 68, 26, 153, 199, 37, 123, 58, 100, 134, 216, 91, 5, 231,
185,
+140, 210, 48, 110, 237, 179, 81, 15, 78, 16, 242, 172, 47, 113, 147,
205,
+17, 79, 173, 243, 112, 46, 204, 146, 211, 141, 111, 49, 178, 236, 14,
80,
+175, 241, 19, 77, 206, 144, 114, 44, 109, 51, 209, 143, 12, 82, 176,
238,
+50, 108, 142, 208, 83, 13, 239, 177, 240, 174, 76, 18, 145, 207, 45,
115,
+202, 148, 118, 40, 171, 245, 23, 73, 8, 86, 180, 234, 105, 55, 213,
139,
+87, 9, 235, 181, 54, 104, 138, 212, 149, 203, 41, 119, 244, 170, 72,
22,
+233, 183, 85, 11, 136, 214, 52, 106, 43, 117, 151, 201, 74, 20, 246,
168,
+116, 42, 200, 150, 21, 75, 169, 247, 182, 232, 10, 84, 215, 137, 107,
53
+};
+
+static uint8_t w1_calc_crc8(uint8_t * data, int len)
+{
+uint8_t crc = 0;
+while (len--)
+crc =
Re: [Qemu-devel] [PATCH] ds18s20: Add onewire thermal sensor
I've just posted the imx233 patch series, with a board that uses this driver. M On Wed, Dec 11, 2013 at 12:44 PM, Peter Maydell peter.mayd...@linaro.orgwrote: On 11 December 2013 12:22, M P buser...@gmail.com wrote: Support for a dallas/maxim onewire sensor, enough of it to fool linux's w1-gpio driver Is there a board in QEMU's current set that would use this, or is this part of a larger set of patches that would add a board that uses it? thanks -- PMM
Re: [Qemu-devel] [RFC] i.MX233 / olinuxino support
On Tue, Dec 11, 2012 at 3:11 PM, Peter Maydell peter.mayd...@linaro.orgwrote: On 11 December 2012 15:08, M P buser...@gmail.com wrote: On Tue, Dec 11, 2012 at 2:57 PM, Peter Maydell peter.mayd...@linaro.org wrote: Showing 11 changed files with 2,236 additions and 0 deletions. That commit absolutely has to be broken up into a coherent set of smaller patches; it is far too big to code review as it stands. Well I pondered that, but really I don't see how to split that since they are all new files.., and all the bits are part of one 'unit'.. Any suggestion ? The usual approach is one of: * a patch per device, then one patch at the end with the board model or if you have a lot of devices: * a patch per device for a few basic devices (uart etc) * then a patch for a board model using those and able to boot a very stripped down kernel * then add more complicated devices later, with a patch per device which adds the device source file and modifies the board model to instantiate it Bear in mind that QEMU should compile at every stage between every patch; it's not enough for it to just compile at the end when all patches are applied. Hi guys. I've reworked the patch to follow the coding rules (I hope) and split it into devices, and verified they all work independently. Could you please have a quick eyeball before I post the patches on the list, if appropriate ? I've added quite a few functional things since the last request, I got a pretty good emulation working now. https://github.com/buserror-uk/qemu-buserror/commits/dev-imx233 Thanks, Michel thanks -- PMM
[Qemu-devel] ehci and low/full speed peripherals
In the i.MX23 emulation, there is a EHCI sysbus device which is supported and seems to work well already (using -usbdevice host:...) However most of the other peripherals (serial, hub, net) fail do to a 'speed mismatch' error. I looked into a bit more details, and it seems the EHCI has to be complimented to support lower speed peripherals. However, none of the attempts I made at 'complimenting' my ehci instance with ohci seems to work, and grepping doesn't shows any other device using this. How is this supposed to work ? Michael
Re: [Qemu-devel] ehci and low/full speed peripherals
On Thu, Dec 13, 2012 at 12:25 PM, Gerd Hoffmann kra...@redhat.com wrote:
On 12/13/12 11:38, M P wrote:
In the i.MX23 emulation, there is a EHCI sysbus device which is supported
and seems to work well already (using -usbdevice host:...)
However most of the other peripherals (serial, hub, net) fail do to a
'speed mismatch' error. I looked into a bit more details, and it seems
the
EHCI has to be complimented to support lower speed peripherals.
However, none of the attempts I made at 'complimenting' my ehci instance
with ohci seems to work, and grepping doesn't shows any other device
using
this.
How is this supposed to work ?
See docs/ich9-ehci-uhci.cfg how that works in the x86 world. Using ohci
instead of uhci works too. You need a single ohci controller only when
setting the num-ports property to 6.
Doing the same on sysbus needs some coding work to add masterbus +
firstport properties and to wind up initialization accordingly.
HTH,
Gerd
I added the properties (see patch lower down) and I Use the following to
create a companion ohci, however qemu starts, seems to let me attach lower
speed devices, but linux reports:
hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad I have to
say I'm not sure where that comes from -- so I need some sort of kernel
support for companion ports perhaps?
+ DeviceState * d = qdev_create(NULL, sysbus-ohci);
+ qdev_prop_set_string(d, masterbus, u-bus.qbus.name);
+ qdev_prop_set_uint32(d, firstport, 0);
+ qdev_prop_set_uint32(d, num-ports, 6);
+ qdev_init_nofail(d);
-- patch bellow to hcd-ohci.c appears straigthforward enough
@@ -1849,7 +1849,9 @@ static int usb_ohci_initfn_pci(struct PCIDevice *dev)
typedef struct {
SysBusDevice busdev;
OHCIState ohci;
+char *masterbus;
uint32_t num_ports;
+uint32_t firstport;
dma_addr_t dma_offset;
} OHCISysBusState;
@@ -1858,8 +1860,9 @@ static int ohci_init_pxa(SysBusDevice *dev)
OHCISysBusState *s = FROM_SYSBUS(OHCISysBusState, dev);
/* Cannot fail as we pass NULL for masterbus */
-usb_ohci_init(s-ohci, dev-qdev, s-num_ports, s-dma_offset, NULL,
0,
- dma_context_memory);
+usb_ohci_init(s-ohci, dev-qdev, s-num_ports, s-dma_offset,
+s-masterbus, s-firstport,
+dma_context_memory);
sysbus_init_irq(dev, s-ohci.irq);
sysbus_init_mmio(dev, s-ohci.mem);
@@ -1897,6 +1900,8 @@ static TypeInfo ohci_pci_info = {
static Property ohci_sysbus_properties[] = {
DEFINE_PROP_UINT32(num-ports, OHCISysBusState, num_ports, 3),
DEFINE_PROP_DMAADDR(dma-offset, OHCISysBusState, dma_offset, 3),
+DEFINE_PROP_STRING(masterbus, OHCISysBusState, masterbus),
+DEFINE_PROP_UINT32(firstport, OHCISysBusState, firstport, 0),
DEFINE_PROP_END_OF_LIST(),
};
[Qemu-devel] [RFC] i.MX233 / olinuxino support
I've added imx23 support to qemu, with quite a lot of working peripherals, and enough to boot linux with SD card and USB working. There are bits missing (audio, video outputs) but it's otherwise working pretty well. I've collated and cleaned the patches onto this github branch, I'd appreciate any comments and/or complementary work before I submit the patches for merging here... https://github.com/buserror-uk/qemu-buserror/commits/dev-imx233 Michael
Re: [Qemu-devel] [RFC] i.MX233 / olinuxino support
On Tue, Dec 11, 2012 at 2:57 PM, Peter Maydell peter.mayd...@linaro.orgwrote: On 11 December 2012 13:08, M P buser...@gmail.com wrote: I've added imx23 support to qemu, with quite a lot of working peripherals, and enough to boot linux with SD card and USB working. There are bits missing (audio, video outputs) but it's otherwise working pretty well. I've collated and cleaned the patches onto this github branch, I'd appreciate any comments and/or complementary work before I submit the patches for merging here... https://github.com/buserror-uk/qemu-buserror/commits/dev-imx233 Showing 11 changed files with 2,236 additions and 0 deletions. That commit absolutely has to be broken up into a coherent set of smaller patches; it is far too big to code review as it stands. Well I pondered that, but really I don't see how to split that since they are all new files.., and all the bits are part of one 'unit'.. Any suggestion ? You don't seem to be following the QEMU coding style. (CODING_STYLE and scripts/checkpatch.pl may be of use). I'll study the coding style. I have to say I did a bit of cut/paste from other files and 'tried' to stick to what I've seen, and otherwise defaulted to kernel mode.. Information on how to test the board model would be good. Also unit tests, maybe? Are you going to be sticking around to help maintain and improve the board model in the future? Yes I'd definitely would want that, as well as add imx28 -- I did the mini2440 qemu support years ago, but let it diverge and always regretted that as now it's it would require more or less a rewrite... http://wiki.qemu.org/Contribute/SubmitAPatch has more pointers on patch submission. Thanks, thats exactly the sort of information I wanted :-) thanks -- PMM Michael
Re: [Qemu-devel] emulated ARM performance vs real processor ?
On Fri, Sep 2, 2011 at 5:04 PM, Julien Heyman bidsom...@gmail.com wrote: Thanks Dave. I use system emulation, and my main concern is just to know that the actual board will run faster than the emulation. So based on your example, and even though my target board (mini2440) is nowhere as fast as a Panda board, this should be the case by a comfortable margin. Now, as I am focusing on boot time, the time to read from flash (i.e. much faster in the emulated context than on the real flash) will counter-balance this a lot. Hopefully these two factors will even out and what I measure now will not be dramatically different than what I will get on the real board, but...we'll see. I wrote the mini2440 support for qemu and used it a LOT, and it can pretty easily emulate full speed on a core2. Some stuff is a bit slower, but most is quite a bit faster somehow. Note that emulates more than an armv4t, so if the code you run is not compiled properly, it might just work in qemu, and fail miserably on the real hardware.. Michael Regards, Julien On Fri, Sep 2, 2011 at 4:31 PM, David Gilbert david.gilb...@linaro.org wrote: On 1 September 2011 08:32, Julien Heyman bidsom...@gmail.com wrote: Hi, I was wondering if anyone had some data regarding the relative performance of any given ARM board emulated in QEMU versus the real thing. Yes, I do know this depends a lot on the host PC running qemu, but some ballpark/example figures would help. Say, I emulate a 400 Mhz ARM9 processor on a Core2Duo laptop @ 2 Ghz, what kind of performance/timing ratio should I expect, one way or the other ? For example, for boot time. I have no idea whether the overhead of emulation is over-compensated by the huge processing power of the host compared to the real HW target, and by which factor. Comparing performance is always a bit tricky, and I've not really got a solid set of benchmarks ready to run to try it but to give some numbers: 1) Boot times Comparing the Linaro 11.08 ubuntu desktop images, time to boot to desktop Real Panda board (dual core A9 at 1GHz, 1GB RAM, running off SD card) - 2minutes to desktop QEMU vexpress (2xA9 core, 1GB RAM, emulated sd card, running on a Core2 Duo T9400 2.53GHz laptop) - 3minutes to desktop (The times are scarily close to exact minutes - timeout somewhere?) Now, QEMU system mode only ever uses one host core when emulating multiple cores, so there is a factor 2 disadvantage there, but on the plus side the memory bandwidth of the host and the disk speed is probably much higher than the Panda. 2) Simple md5sum benchmark As a really simple benchmark the test: time (dd if=/dev/zero bs=1024k count=1000 | md5sum) Panda board 14.5s real, 10.7 user, 3.8s system Emulated Overo board (single A8 processor on same laptop as above) - 41s real, 24.7s user, 16.4s system User mode emulated - 14.2s real, 14s user, 0.5s system Native on x86 host - 3.2s real, 2.5s user, 1.2s system So, that's two sets of pretty bogus dummy simple benchmarks! I suppose one observation is that the boot time isn't that bad compared to the real (different) hardware, the user mode emulation was comparable to the Panda, but the system emulation on a simple test seems a lot slower. These things will vary wildly depending what your benchmark is; but as a summary I'd say that the ARM system mode emulation is fast enough to use interactively but CPU wise is noticeably slower than user mode emulation. Dave
Re: [Qemu-devel] QEMU forks survey
On Tue, Dec 21, 2010 at 6:28 PM, Andreas Färber andreas.faer...@web.de wrote: Since Christmas and the New Year with its good intensions are approaching, apart from z80 there's some more feature forks around: http://repo.or.cz/w/qemu.git/forks?o=age - hpoussin.git ppc contains the 40p machine that I'm reviewing for upstream inclusion currently. * qemu-loongson.git I guess was fully upstreamed recently? * ar7.git: Stefan, what's the state and scope of your work? What about TCI? Apparently abandoned (no recent activity): * avr32.git * es40.git (alpha) * hppa.git * openrisc.git * mmix.git Unclear to me: * mini2440.git I did that fully working mini2440 port, since last year or so. that include s3c2440 and many associated peripherals. Unfortunately it's hard to follow qemu's tree and I decided to keep my port as is instead of constantly trying to keep it up to date... I still use it a lot tho... Michael
