* [Qemu-devel] [PATCH 0/6] Add i.MX6 (Single/Dual/Quad) support @ 2016-01-26 21:44 Jean-Christophe Dubois 2016-01-28 14:57 ` Peter Maydell 0 siblings, 1 reply; 5+ messages in thread From: Jean-Christophe Dubois @ 2016-01-26 21:44 UTC (permalink / raw) To: qemu-devel, peter.maydell, rosthwaite.peter; +Cc: Jean-Christophe Dubois This patch series adds support for the Freescale i.MX6 processor. For now we only support the following devices: * up to 4 Cortex A9 cores * A9 MPCORE (SCU, GIC, TWD) * 5 i.MX UARTs * 2 EPIT timers * 1 GPT timer * 7 GPIO controllers * 6 SDHC controllers * 1 CCM device * 1 SRC device * various ROM/RAM areas. This also adds the sabrelite board as a an actual platform for i.MX6. This series was tested by booting a 4.4 linux kernel (using the imx_v6_v7_defconfig file as kernel configuration). Note: In order for Linux to work I had to customize a bit the arch/arm/boot/dts/imx6qdl-sabrelite.dtsi device tree file. Jean-Christophe Dubois (6): i.MX: Allow GPT timer to rollover. i.MX: simplify CCM to only handle clock required by timers. i.MX: Add i.MX6 CCM and ANALOG device. i.MX: Add i.MX6 System Reset Controller device. i.MX: Add i.MX6 SOC implementation. i.MX: Add sabrelite i.MX6 emulation. default-configs/arm-softmmu.mak | 1 + hw/arm/Makefile.objs | 1 + hw/arm/fsl-imx6.c | 402 +++++++++++++++++++++ hw/arm/sabrelite.c | 93 +++++ hw/misc/Makefile.objs | 2 + hw/misc/imx25_ccm.c | 35 +- hw/misc/imx31_ccm.c | 38 +- hw/misc/imx6_ccm.c | 764 ++++++++++++++++++++++++++++++++++++++++ hw/misc/imx6_src.c | 353 +++++++++++++++++++ hw/timer/imx_epit.c | 8 +- hw/timer/imx_gpt.c | 43 +-- include/hw/arm/fsl-imx6.h | 447 +++++++++++++++++++++++ include/hw/misc/imx6_ccm.h | 195 ++++++++++ include/hw/misc/imx6_src.h | 72 ++++ include/hw/misc/imx_ccm.h | 10 +- 15 files changed, 2368 insertions(+), 96 deletions(-) create mode 100644 hw/arm/fsl-imx6.c create mode 100644 hw/arm/sabrelite.c create mode 100644 hw/misc/imx6_ccm.c create mode 100644 hw/misc/imx6_src.c create mode 100644 include/hw/arm/fsl-imx6.h create mode 100644 include/hw/misc/imx6_ccm.h create mode 100644 include/hw/misc/imx6_src.h -- 2.5.0 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] [PATCH 0/6] Add i.MX6 (Single/Dual/Quad) support 2016-01-26 21:44 [Qemu-devel] [PATCH 0/6] Add i.MX6 (Single/Dual/Quad) support Jean-Christophe Dubois @ 2016-01-28 14:57 ` Peter Maydell 2016-01-28 19:22 ` Jean-Christophe DUBOIS 0 siblings, 1 reply; 5+ messages in thread From: Peter Maydell @ 2016-01-28 14:57 UTC (permalink / raw) To: Jean-Christophe Dubois; +Cc: rosthwaite.peter, QEMU Developers On 26 January 2016 at 21:44, Jean-Christophe Dubois <jcd@tribudubois.net> wrote: > This patch series adds support for the Freescale i.MX6 processor. > > For now we only support the following devices: > * up to 4 Cortex A9 cores > * A9 MPCORE (SCU, GIC, TWD) > * 5 i.MX UARTs > * 2 EPIT timers > * 1 GPT timer > * 7 GPIO controllers > * 6 SDHC controllers > * 1 CCM device > * 1 SRC device > * various ROM/RAM areas. > > This also adds the sabrelite board as a an actual platform for i.MX6. > > This series was tested by booting a 4.4 linux kernel (using the > imx_v6_v7_defconfig file as kernel configuration). > > Note: In order for Linux to work I had to customize a bit the > arch/arm/boot/dts/imx6qdl-sabrelite.dtsi device tree file. What changes did you have to make to the dt, and why? thanks -- PMM ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] [PATCH 0/6] Add i.MX6 (Single/Dual/Quad) support 2016-01-28 14:57 ` Peter Maydell @ 2016-01-28 19:22 ` Jean-Christophe DUBOIS 2016-02-02 17:01 ` Peter Maydell 0 siblings, 1 reply; 5+ messages in thread From: Jean-Christophe DUBOIS @ 2016-01-28 19:22 UTC (permalink / raw) To: Peter Maydell; +Cc: qemu-arm, QEMU Developers, crosthwaite.peter [-- Attachment #1.1: Type: text/plain, Size: 1908 bytes --] Hello Peter, Le 28/01/2016 15:57, Peter Maydell a écrit : > On 26 January 2016 at 21:44, Jean-Christophe Dubois <jcd@tribudubois.net> wrote: >> This patch series adds support for the Freescale i.MX6 processor. >> >> For now we only support the following devices: >> * up to 4 Cortex A9 cores >> * A9 MPCORE (SCU, GIC, TWD) >> * 5 i.MX UARTs >> * 2 EPIT timers >> * 1 GPT timer >> * 7 GPIO controllers >> * 6 SDHC controllers >> * 1 CCM device >> * 1 SRC device >> * various ROM/RAM areas. >> >> This also adds the sabrelite board as a an actual platform for i.MX6. >> >> This series was tested by booting a 4.4 linux kernel (using the >> imx_v6_v7_defconfig file as kernel configuration). >> >> Note: In order for Linux to work I had to customize a bit the >> arch/arm/boot/dts/imx6qdl-sabrelite.dtsi device tree file. > What changes did you have to make to the dt, and why? Please find attached the diff file for the linux imx6qdl-sabrelite.dtsi file. Basically, it boils down to the following: * Sabrelite uses uart2 for console but on qemu, this is uart1 that is wired to the default stdout. Consequently, I changed stdout-path in "chosen" to uart1. * For now i.MX6 SOC code does not emulate SPI controller. During the boot Linux was getting stuck trying to access a SPI device that is supposed to be there. Therefore I disabled the SPI controller in the device tree. * The sabrelite is supposed to have a bunch of push buttons (home, power, back, vol up, vol down) wired to various GPIOs. I guess these buttons might have pull up or pull down resistors on the real hardware but obviously on qemu we have no such things. As a results the GPIOs were triggering a lot of interrupts for nothing. So I commented out the GPIO sections were the buttons were defined. Regards JC > > thanks > -- PMM > [-- Attachment #1.2: Type: text/html, Size: 2772 bytes --] [-- Attachment #2: imx6qdl-sabrelite.dtsi.diff --] [-- Type: text/x-patch, Size: 845 bytes --] diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi index 1a69a34..760020e 100644 --- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi +++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi @@ -44,7 +44,8 @@ / { chosen { - stdout-path = &uart2; + bootargs = "console=ttymxc0,115200"; + stdout-path = &uart1; }; memory { @@ -96,6 +97,7 @@ }; }; +/* gpio-keys { compatible = "gpio-keys"; pinctrl-names = "default"; @@ -138,6 +140,7 @@ linux,code = <KEY_VOLUMEDOWN>; }; }; +*/ sound { compatible = "fsl,imx6q-sabrelite-sgtl5000", @@ -245,7 +248,7 @@ cs-gpios = <&gpio3 19 0>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_ecspi1>; - status = "okay"; + /* status = "okay"; */ flash: m25p80@0 { compatible = "sst,sst25vf016b", "jedec,spi-nor"; ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] [PATCH 0/6] Add i.MX6 (Single/Dual/Quad) support 2016-01-28 19:22 ` Jean-Christophe DUBOIS @ 2016-02-02 17:01 ` Peter Maydell 2016-02-07 18:44 ` Jean-Christophe DUBOIS 0 siblings, 1 reply; 5+ messages in thread From: Peter Maydell @ 2016-02-02 17:01 UTC (permalink / raw) To: Jean-Christophe DUBOIS; +Cc: qemu-arm, QEMU Developers, Peter Crosthwaite On 28 January 2016 at 19:22, Jean-Christophe DUBOIS <jcd@tribudubois.net> wrote: > Sabrelite uses uart2 for console but on qemu, this is uart1 that is wired to > the default stdout. Consequently, I changed stdout-path in "chosen" to > uart1. This I find a bit awkward: we'd like to get eventually to the point where you can run the stock device tree unedited. The other items on your list are just "we don't emulate something yet", so the path forward is to (eventually) emulate the missing things. But it's not clear to me what we need to do to be able to stop editing stdout-path in the future. Perhaps the answer is just to use QEMU command line arguments to make stdout be the uart2 rather than uart1? > For now i.MX6 SOC code does not emulate SPI controller. During the boot > Linux was getting stuck trying to access a SPI device that is supposed to be > there. Therefore I disabled the SPI controller in the device tree. This is OK for now, though I guess it means the SPI controller is worth emulating to at least some extent. > The sabrelite is supposed to have a bunch of push buttons (home, power, > back, vol up, vol down) wired to various GPIOs. I guess these buttons might > have pull up or pull down resistors on the real hardware but obviously on > qemu we have no such things. As a results the GPIOs were triggering a lot of > interrupts for nothing. So I commented out the GPIO sections were the > buttons were defined. This is OK for now, though it would be nice to wire all the GPIOs to 0 or something if that helps avoid the problem without editing the DT. thanks --- PMM ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] [PATCH 0/6] Add i.MX6 (Single/Dual/Quad) support 2016-02-02 17:01 ` Peter Maydell @ 2016-02-07 18:44 ` Jean-Christophe DUBOIS 0 siblings, 0 replies; 5+ messages in thread From: Jean-Christophe DUBOIS @ 2016-02-07 18:44 UTC (permalink / raw) To: Peter Maydell; +Cc: qemu-arm, QEMU Developers, Peter Crosthwaite Le 02/02/2016 18:01, Peter Maydell a écrit : > On 28 January 2016 at 19:22, Jean-Christophe DUBOIS <jcd@tribudubois.net> wrote: >> Sabrelite uses uart2 for console but on qemu, this is uart1 that is wired to >> the default stdout. Consequently, I changed stdout-path in "chosen" to >> uart1. > This I find a bit awkward: we'd like to get eventually to the point > where you can run the stock device tree unedited. The other items > on your list are just "we don't emulate something yet", so the path > forward is to (eventually) emulate the missing things. But it's not > clear to me what we need to do to be able to stop editing stdout-path > in the future. > > Perhaps the answer is just to use QEMU command line arguments to make > stdout be the uart2 rather than uart1? I'll send a new version where the platform (sabrelite) can chose (through properties) which uart of the SOC (i.MX6) it wants to use as default output. > >> For now i.MX6 SOC code does not emulate SPI controller. During the boot >> Linux was getting stuck trying to access a SPI device that is supposed to be >> there. Therefore I disabled the SPI controller in the device tree. > This is OK for now, though I guess it means the SPI controller is > worth emulating to at least some extent. I'll see what I can do next. > >> The sabrelite is supposed to have a bunch of push buttons (home, power, >> back, vol up, vol down) wired to various GPIOs. I guess these buttons might >> have pull up or pull down resistors on the real hardware but obviously on >> qemu we have no such things. As a results the GPIOs were triggering a lot of >> interrupts for nothing. So I commented out the GPIO sections were the >> buttons were defined. > This is OK for now, though it would be nice to wire all the GPIOs to 0 or > something if that helps avoid the problem without editing the DT. Ditto. > > thanks > --- PMM > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-02-07 18:44 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-01-26 21:44 [Qemu-devel] [PATCH 0/6] Add i.MX6 (Single/Dual/Quad) support Jean-Christophe Dubois 2016-01-28 14:57 ` Peter Maydell 2016-01-28 19:22 ` Jean-Christophe DUBOIS 2016-02-02 17:01 ` Peter Maydell 2016-02-07 18:44 ` Jean-Christophe DUBOIS
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).