Add ISEE IGEPv2 board definition (an OMAP3730 based board).
Signed-off-by: Javier Martinez Canillas javier@dowhile0.org --- Makefile.target | 2 +- hw/igep.c | 123 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 124 insertions(+), 1 deletions(-) create mode 100644 hw/igep.c
diff --git a/Makefile.target b/Makefile.target index 409748f..2923dd7 100644 --- a/Makefile.target +++ b/Makefile.target @@ -349,7 +349,7 @@ obj-arm-y += omap1.o omap_lcdc.o omap_dma.o omap_clk.o omap_mmc.o omap_i2c.o \ obj-arm-y += omap2.o omap_dss.o soc_dma.o omap_gptimer.o omap_synctimer.o \ omap_gpmc.o omap_sdrc.o omap_spi.o omap_tap.o omap_l4.o obj-arm-y += omap3.o omap_usb.o omap3_boot.o omap3_mmc.o dsi.o -obj-arm-y += twl4030.o beagle.o overo.o +obj-arm-y += twl4030.o beagle.o overo.o igep.o obj-arm-y += omap_sx1.o palm.o tsc210x.o obj-arm-y += nseries.o blizzard.o onenand.o vga.o cbus.o tusb6010.o usb-musb.o obj-arm-y += mst_fpga.o mainstone.o diff --git a/hw/igep.c b/hw/igep.c new file mode 100644 index 0000000..5254ddf --- /dev/null +++ b/hw/igep.c @@ -0,0 +1,123 @@ +/* + * ISEE IGEPv2 board emulation. + * + * Copyright (c) 2012 ISEE 2007, SL + * Written by Javier Martinez Canillas (based on Gumstix Overo emulation code) + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, see http://www.gnu.org/licenses/. + */ + +#include "qemu-common.h" +#include "sysemu.h" +#include "omap.h" +#include "arm-misc.h" +#include "boards.h" +#include "i2c.h" +#include "net.h" +#include "devices.h" +#include "flash.h" +#include "sysbus.h" +#include "blockdev.h" +#include "exec-memory.h" + +#define IGEP_NAND_CS 0 +#define IGEP_NET_CS 5 + +struct igep_s { + struct omap_mpu_state_s *cpu; + + DeviceState *nand; + void *twl4030; + DeviceState *eth; + DeviceState *ddc; +}; + +static void igep_init(ram_addr_t ram_size, + const char *boot_device, + const char *kernel_filename, + const char *kernel_cmdline, + const char *initrd_filename, + const char *cpu_model) +{ + MemoryRegion *sysmem = get_system_memory(); + struct igep_s *s = (struct igep_s *) g_malloc0(sizeof(*s)); + DriveInfo *dmtd = drive_get(IF_MTD, 0, 0); + DriveInfo *dsd = drive_get(IF_SD, 0, 0); + + if (ram_size > 1024 * 1024 * 1024) { + fprintf(stderr, "igep: maximum permitted RAM size 1024MB\n"); + exit(1); + } + + if (!dmtd && !dsd) { + hw_error("%s: SD or NAND image required", __func__); + } + s->cpu = omap3_mpu_init(sysmem, omap3630, ram_size, + NULL, NULL, serial_hds[0], NULL); + + s->nand = qdev_create(NULL, "onenand"); + qdev_prop_set_uint16(s->nand, "manufacturer_id", NAND_MFR_STMICRO); + qdev_prop_set_uint16(s->nand, "device_id", 0x40); + qdev_prop_set_uint16(s->nand, "version_id", 0x121); + qdev_prop_set_int32(s->nand, "shift", 1); + if (dmtd && dmtd->bdrv) { + qdev_prop_set_drive_nofail(s->nand, "drive", dmtd->bdrv); + } + qdev_init_nofail(s->nand); + omap_gpmc_attach(s->cpu->gpmc, IGEP_NAND_CS, + sysbus_mmio_get_region(sysbus_from_qdev(s->nand), 0)); + + if (dsd) { + omap3_mmc_attach(s->cpu->omap3_mmc[0], dsd->bdrv, 0, 0); + } + + /* FAB revs >= 2516: 4030 interrupt is GPIO 0 (earlier ones were 112) */ + s->twl4030 = twl4030_init(omap_i2c_bus(s->cpu->i2c, 0), + qdev_get_gpio_in(s->cpu->gpio, 0), + NULL, NULL); + + /* Wire up an I2C slave which returns EDID monitor information; + * newer Linux kernels won't turn on the display unless they + * detect a monitor over DDC. + */ + s->ddc = i2c_create_slave(omap_i2c_bus(s->cpu->i2c, 2), "i2c-ddc", 0x50); + + omap_lcd_panel_attach(s->cpu->dss); + + /* Strictly this should be a LAN9221 */ + if (nd_table[0].vlan) { + /* The ethernet chip hangs off the GPMC */ + NICInfo *nd = &nd_table[0]; + qemu_check_nic_model(nd, "lan9118"); + s->eth = qdev_create(NULL, "lan9118"); + qdev_set_nic_properties(s->eth, nd); + qdev_init_nofail(s->eth); + omap_gpmc_attach(s->cpu->gpmc, IGEP_NET_CS, + sysbus_mmio_get_region(sysbus_from_qdev(s->eth), 0)); + sysbus_connect_irq(sysbus_from_qdev(s->eth), 0, + qdev_get_gpio_in(s->cpu->gpio, 176)); + } +} + +QEMUMachine igep_machine = { + .name = "igep", + .desc = "ISEE IGEPv2 board (OMAP3730)", + .init = igep_init, +}; + +static void igep_machine_init(void) +{ + qemu_register_machine(&igep_machine); +} + +machine_init(igep_machine_init);
On 11 January 2012 08:43, Javier Martinez Canillas javier@dowhile0.org wrote:
Add ISEE IGEPv2 board definition (an OMAP3730 based board).
Signed-off-by: Javier Martinez Canillas javier@dowhile0.org
It's polite to mention that patches are against qemu-linaro if you cc qemu-devel.
So my initial reaction to this is to ask what the benefit is of adding another basically-just-an-OMAP3 model. We already have beagle and overo, and this is obviously just cut-n-paste from overo (it still has the comment about "FAB revisions" which is specific to Overo, which doesn't give me a great deal of confidence that this is actually correctly modelling the IGEPv2 rather than just something random which happens to be able to boot an IGEPv2 kernel...)
GPLv2-only rather than v2-or-later is also going to be a problem, although I appreciate that that's because you've based this on the v2-only overo.c [which is going to be a problem for me later on when I try to upstream that :-)]
-- PMM
On Wed, Jan 11, 2012 at 12:15 PM, Peter Maydell peter.maydell@linaro.org wrote:
On 11 January 2012 08:43, Javier Martinez Canillas javier@dowhile0.org wrote:
Add ISEE IGEPv2 board definition (an OMAP3730 based board).
Signed-off-by: Javier Martinez Canillas javier@dowhile0.org
Hello Peter,
It's polite to mention that patches are against qemu-linaro if you cc qemu-devel.
Yes, you are right. Sorry for not mention that in the patch.
So my initial reaction to this is to ask what the benefit is of adding another basically-just-an-OMAP3 model. We already have beagle and overo, and this is obviously just cut-n-paste from overo (it still has the comment about "FAB revisions" which is specific to Overo, which doesn't give me a great deal of confidence that this is actually correctly modelling the IGEPv2 rather than just something random which happens to be able to boot an IGEPv2 kernel...)
Yes, the IGEPv2 and the Overo are indeed very similar machines so we base the hardware modeling on the Overo.
The only differences here are which OMAP version is used to initialize the MPU (3630 instead of 3430) and the NAND memory used, Numonyx OneNAND instead of Micron NAND.
What is the benefit to have yet another OMAP3 device? Well.. I don't know ;-)
We just add this device model for our clients so I thought it was a good idea to post the patch upstream. But feel free to ignore me if you think that it doesn't add any value to Linaro QEMU.
GPLv2-only rather than v2-or-later is also going to be a problem, although I appreciate that that's because you've based this on the v2-only overo.c [which is going to be a problem for me later on when I try to upstream that :-)]
-- PMM
Sorry about that, I didn't know that GPLv2 or later was the norm in the QEMU project.
Also, is good to notice that the Versatile Express board (hw/vexpress.c) and the StrongARM emulation support (hw/strongarm.c) also use GPLv2-only license. If you need to fix those too.
Thanks a lot and best regards, Javier
On 11 January 2012 11:53, Javier Martinez Canillas javier@dowhile0.org wrote:
Yes, the IGEPv2 and the Overo are indeed very similar machines so we base the hardware modeling on the Overo.
The only differences here are which OMAP version is used to initialize the MPU (3630 instead of 3430) and the NAND memory used, Numonyx OneNAND instead of Micron NAND.
That's pretty minor -- can you just use the overo model as is? I bet nothing at the software level cares that much about the OMAP version or NAND manufacturer...
We just add this device model for our clients so I thought it was a good idea to post the patch upstream. But feel free to ignore me if you think that it doesn't add any value to Linaro QEMU.
I appreciate the patch. My pushback is really that every new board we accept carries an implicit future cost for testing/maintenance/etc, so there needs to be a reasonable set of users who would use this and not the overo or beagle.
Sorry about that, I didn't know that GPLv2 or later was the norm in the QEMU project.
We've just changed recently to asking people to include the "or later" clause for new code (this is why, as you note, there are some existing bits of code which are v2-only).
-- PMM
On Wed, Jan 11, 2012 at 1:20 PM, Peter Maydell peter.maydell@linaro.org wrote:
On 11 January 2012 11:53, Javier Martinez Canillas javier@dowhile0.org wrote:
Yes, the IGEPv2 and the Overo are indeed very similar machines so we base the hardware modeling on the Overo.
The only differences here are which OMAP version is used to initialize the MPU (3630 instead of 3430) and the NAND memory used, Numonyx OneNAND instead of Micron NAND.
That's pretty minor -- can you just use the overo model as is? I bet nothing at the software level cares that much about the OMAP version or NAND manufacturer...
Yes, I guess we can use the Overo as is.
We just add this device model for our clients so I thought it was a good idea to post the patch upstream. But feel free to ignore me if you think that it doesn't add any value to Linaro QEMU.
I appreciate the patch. My pushback is really that every new board we accept carries an implicit future cost for testing/maintenance/etc, so there needs to be a reasonable set of users who would use this and not the overo or beagle.
Yes, I totally understand. Then just feel free to just ignore the patch, sorry for the noise.
Sorry about that, I didn't know that GPLv2 or later was the norm in the QEMU project.
We've just changed recently to asking people to include the "or later" clause for new code (this is why, as you note, there are some existing bits of code which are v2-only).
-- PMM
Best regards, Javier
linaro-toolchain@lists.linaro.org
-
Javier Martinez Canillas -
Peter Maydell