[RFC 0/7] ARM: vf610m4: Add Vybrid Cortex-M4 support

[RFC 0/7] ARM: vf610m4: Add Vybrid Cortex-M4 support

[Stefan Agner]

This adds Vybrid SoC support for the !MMU Cortex-M4 core. The patchset is
its current state is more a collection of hacks than anything mergabel,
advice and ideas how to beat it in good shape are welcome. I added some
thoughts as comments in the individual patches.

I wrote also some more info about Vybrid Cortex-M4 support in my blog
post:
http://falstaff.agner.ch/2014/10/05/make-it-two-tuxes-on-one-soc/

One thing I noticed that when I move the xipImage below the DRAM base
address, the kernel freezes:
...
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[freeze]

I think it happens when the scheduler gets started. Any idea what could
go wrong here?

Stefan Agner (7):
  ARM: vf610: add low level debug support for !MMU
  clocksource: add dependencies for Vybrid pit clocksource
  ARM: vf610m4: add new machine and SoC for Vybrid on Cortex-M4
  ARM: dts: add support for Vybrid running on Cortex-M4
  irqchip: nvic: increase number of external interrupts to 112
  ARM: vf610m4: HACK: get dtb pointer from SRC_GPR3
  ARM: vf610m4: add defconfig for Linux on Vybrids Cortex-M4

 arch/arm/Kconfig                   |  12 ++++
 arch/arm/Kconfig.debug             |   4 +-
 arch/arm/Makefile                  |   1 +
 arch/arm/boot/dts/Makefile         |   1 +
 arch/arm/boot/dts/armv7-m.dtsi     |   1 -
 arch/arm/boot/dts/vf610m4.dts      | 144 +++++++++++++++++++++++++++++++++++++
 arch/arm/configs/vf610m4_defconfig |  37 ++++++++++
 arch/arm/include/debug/vf.S        |  10 +++
 arch/arm/kernel/entry-v7m.S        |   4 +-
 arch/arm/kernel/head-nommu.S       |   8 +++
 arch/arm/mach-imx/Kconfig          |  22 ++++++
 arch/arm/mach-imx/Makefile         |   1 +
 arch/arm/mach-imx/Makefile.boot    |   0
 arch/arm/mach-imx/mach-vf610m4.c   |  16 +++++
 drivers/clocksource/Kconfig        |   2 +
 drivers/irqchip/irq-nvic.c         |   2 +
 drivers/mmc/host/Kconfig           |   2 +-
 drivers/pinctrl/Kconfig            |   2 +-
 18 files changed, 262 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/boot/dts/vf610m4.dts
 create mode 100644 arch/arm/configs/vf610m4_defconfig
 create mode 100644 arch/arm/mach-imx/Makefile.boot
 create mode 100644 arch/arm/mach-imx/mach-vf610m4.c

-- 
2.1.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 1/7] ARM: vf610: add low level debug support for !MMU

[Stefan Agner]

Add support for !MMU low level debug required for the secondary
Cortex-M4 core in Vybrid.

Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
---
 arch/arm/include/debug/vf.S | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/include/debug/vf.S b/arch/arm/include/debug/vf.S
index b889338..63c7ef7 100644
--- a/arch/arm/include/debug/vf.S
+++ b/arch/arm/include/debug/vf.S
@@ -17,12 +17,22 @@
 
 #define VF_UART_VIRTUAL_BASE	0xfe000000
 
+#ifdef CONFIG_MMU
+
 	.macro	addruart, rp, rv, tmp
 	ldr	\rp, =VF_UART_PHYSICAL_BASE 	@ physical
 	and	\rv, \rp, #0xffffff		@ offset within 16MB section
 	add	\rv, \rv, #VF_UART_VIRTUAL_BASE
 	.endm
 
+#else /* !CONFIG_MMU */
+
+	.macro	addruart, rx, tmp
+	ldr	\rx, =(VF_UART_PHYSICAL_BASE)	@ physical
+	.endm
+
+#endif /* CONFIG_MMU */
+
 	.macro	senduart, rd, rx
 	strb	\rd, [\rx, #0x7]	@ Data Register
 	.endm
-- 
2.1.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/7] ARM: vf610: add low level debug support for !MMU

[Arnd Bergmann]

On Sunday 12 October 2014 20:13:55 Stefan Agner wrote:
> Add support for !MMU low level debug required for the secondary
> Cortex-M4 core in Vybrid.
> 
> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
> ---
>  arch/arm/include/debug/vf.S | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm/include/debug/vf.S b/arch/arm/include/debug/vf.S
> index b889338..63c7ef7 100644
> --- a/arch/arm/include/debug/vf.S
> +++ b/arch/arm/include/debug/vf.S
> @@ -17,12 +17,22 @@
>  
>  #define VF_UART_VIRTUAL_BASE	0xfe000000
>  
> +#ifdef CONFIG_MMU
> +
>  	.macro	addruart, rp, rv, tmp
>  	ldr	\rp, =VF_UART_PHYSICAL_BASE 	@ physical
>  	and	\rv, \rp, #0xffffff		@ offset within 16MB section
>  	add	\rv, \rv, #VF_UART_VIRTUAL_BASE
>  	.endm
>  
> +#else /* !CONFIG_MMU */
> +
> +	.macro	addruart, rx, tmp
> +	ldr	\rx, =(VF_UART_PHYSICAL_BASE)	@ physical
> +	.endm
> +
> +#endif /* CONFIG_MMU */
> +
>  	.macro	senduart, rd, rx
>  	strb	\rd, [\rx, #0x7]	@ Data Register
>  	.endm
> 
Hmm, I've previously needed to add this patch for randconfig testing:

index 78c91b5f97d4..ea9646cc2a0e 100644
--- a/arch/arm/kernel/debug.S
+++ b/arch/arm/kernel/debug.S
@@ -35,7 +35,7 @@
 
 #else /* !CONFIG_MMU */
                .macro  addruart_current, rx, tmp1, tmp2
-               addruart        \rx, \tmp1
+               addruart        \rx, \tmp1, \tmp2
                .endm
 
 #endif /* CONFIG_MMU */



If we do this instead, could we avoid your patch?

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/7] ARM: vf610: add low level debug support for !MMU

[Stefan Agner]

Am 2014-10-12 20:48, schrieb Arnd Bergmann:
> On Sunday 12 October 2014 20:13:55 Stefan Agner wrote:
>> Add support for !MMU low level debug required for the secondary
>> Cortex-M4 core in Vybrid.
>>
>> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
>> ---
>>  arch/arm/include/debug/vf.S | 10 ++++++++++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/include/debug/vf.S b/arch/arm/include/debug/vf.S
>> index b889338..63c7ef7 100644
>> --- a/arch/arm/include/debug/vf.S
>> +++ b/arch/arm/include/debug/vf.S
>> @@ -17,12 +17,22 @@
>>
>>  #define VF_UART_VIRTUAL_BASE	0xfe000000
>>
>> +#ifdef CONFIG_MMU
>> +
>>  	.macro	addruart, rp, rv, tmp
>>  	ldr	\rp, =VF_UART_PHYSICAL_BASE 	@ physical
>>  	and	\rv, \rp, #0xffffff		@ offset within 16MB section
>>  	add	\rv, \rv, #VF_UART_VIRTUAL_BASE
>>  	.endm
>>
>> +#else /* !CONFIG_MMU */
>> +
>> +	.macro	addruart, rx, tmp
>> +	ldr	\rx, =(VF_UART_PHYSICAL_BASE)	@ physical
>> +	.endm
>> +
>> +#endif /* CONFIG_MMU */
>> +
>>  	.macro	senduart, rd, rx
>>  	strb	\rd, [\rx, #0x7]	@ Data Register
>>  	.endm
>>
> Hmm, I've previously needed to add this patch for randconfig testing:
> 
> index 78c91b5f97d4..ea9646cc2a0e 100644
> --- a/arch/arm/kernel/debug.S
> +++ b/arch/arm/kernel/debug.S
> @@ -35,7 +35,7 @@
>  
>  #else /* !CONFIG_MMU */
>                 .macro  addruart_current, rx, tmp1, tmp2
> -               addruart        \rx, \tmp1
> +               addruart        \rx, \tmp1, \tmp2
>                 .endm
>  
>  #endif /* CONFIG_MMU */
> 
> 
> 
> If we do this instead, could we avoid your patch?

Not completely, we then could just ifdef the base address, so it would
make it simpler. We could also pass a boolean in the third, currently
temporary argument to distinguish that during run time in order to get
rid of the compile time ifdef... 

--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 2/7] clocksource: add dependencies for Vybrid pit clocksource

[Stefan Agner]

Add the minimal dependencies required to use the Vybrid PIT
clocksource driver. Those are not part of the SoC dependencies.

Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
---
 drivers/clocksource/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index cfd6519..26464dd 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -146,6 +146,8 @@ config FSL_FTM_TIMER
 
 config VF_PIT_TIMER
 	bool
+	select CLKSRC_MMIO
+	select CLKSRC_OF
 	help
 	  Support for Period Interrupt Timer on Freescale Vybrid Family SoCs.
 
-- 
2.1.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 2/7] clocksource: add dependencies for Vybrid pit clocksource

[Uwe Kleine-König]

Hello,

On Sun, Oct 12, 2014 at 08:13:56PM +0200, Stefan Agner wrote:
> Add the minimal dependencies required to use the Vybrid PIT
> clocksource driver. Those are not part of the SoC dependencies.
> 
> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
> ---
>  drivers/clocksource/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index cfd6519..26464dd 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -146,6 +146,8 @@ config FSL_FTM_TIMER
>  
>  config VF_PIT_TIMER
>  	bool
> +	select CLKSRC_MMIO
> +	select CLKSRC_OF
>  	help
>  	  Support for Period Interrupt Timer on Freescale Vybrid Family SoCs.
This one seems to qualify as a fix for the MMU stuff, right?

Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 2/7] clocksource: add dependencies for Vybrid pit clocksource

[Stefan Agner]

Am 2014-10-12 20:18, schrieb Uwe Kleine-König:
> Hello,
> 
> On Sun, Oct 12, 2014 at 08:13:56PM +0200, Stefan Agner wrote:
>> Add the minimal dependencies required to use the Vybrid PIT
>> clocksource driver. Those are not part of the SoC dependencies.
>>
>> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
>> ---
>>  drivers/clocksource/Kconfig | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>> index cfd6519..26464dd 100644
>> --- a/drivers/clocksource/Kconfig
>> +++ b/drivers/clocksource/Kconfig
>> @@ -146,6 +146,8 @@ config FSL_FTM_TIMER
>>
>>  config VF_PIT_TIMER
>>  	bool
>> +	select CLKSRC_MMIO
>> +	select CLKSRC_OF
>>  	help
>>  	  Support for Period Interrupt Timer on Freescale Vybrid Family SoCs.
> This one seems to qualify as a fix for the MMU stuff, right?

Well, this appeared when working on the !MMU stuff. Because on the MMU
SoC, CLKSRC_OF is selected by ARCH_MULTIPLATFORM and CLKSRC_MMIO is
selected by ARCH_MXC, it would not be a problem for MMU SOC_VF610. But I
guess we should try to define dependencies on the lowest level, so it is
probably a general fix?

--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 2/7] clocksource: add dependencies for Vybrid pit clocksource

[Uwe Kleine-König]

Hallo,

On Mon, Oct 13, 2014 at 11:46:06AM +0200, Stefan Agner wrote:
> >> --- a/drivers/clocksource/Kconfig
> >> +++ b/drivers/clocksource/Kconfig
> >> @@ -146,6 +146,8 @@ config FSL_FTM_TIMER
> >>
> >>  config VF_PIT_TIMER
> >>  	bool
> >> +	select CLKSRC_MMIO
> >> +	select CLKSRC_OF
> >>  	help
> >>  	  Support for Period Interrupt Timer on Freescale Vybrid Family SoCs.
> > This one seems to qualify as a fix for the MMU stuff, right?
> 
> Well, this appeared when working on the !MMU stuff. Because on the MMU
> SoC, CLKSRC_OF is selected by ARCH_MULTIPLATFORM and CLKSRC_MMIO is
> selected by ARCH_MXC, it would not be a problem for MMU SOC_VF610. But I
> guess we should try to define dependencies on the lowest level, so it is
> probably a general fix?
Just notice that VF_PIT_TIMER isn't user selectable, so it's at least
not urgent.

Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 3/7] ARM: vf610m4: add new machine and SoC for Vybrid on Cortex-M4

[Stefan Agner]

This patch adds a new machine ARCH_MXCM4 which requires !MMU and
!MULTIARCH and is meant as machine for the hetregenous multi-core
Vybrid/i.MX SoC's to run Linux on the Cortex-M4.

The first SoC supported is Vybrid on Cortex-M4 (SOC_VF610M4).

Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
---
Not sure whether we really need a new MACH, but since MACH_MXC needs
MULTIARCH, which in turn conflicts with !MMU, I guess there is no
easier way to do it... And then, this also needs a new SOC.

 arch/arm/Kconfig                 | 12 ++++++++++++
 arch/arm/Kconfig.debug           |  4 ++--
 arch/arm/Makefile                |  1 +
 arch/arm/mach-imx/Kconfig        | 22 ++++++++++++++++++++++
 arch/arm/mach-imx/Makefile       |  1 +
 arch/arm/mach-imx/Makefile.boot  |  0
 arch/arm/mach-imx/mach-vf610m4.c | 16 ++++++++++++++++
 drivers/mmc/host/Kconfig         |  2 +-
 drivers/pinctrl/Kconfig          |  2 +-
 9 files changed, 56 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/mach-imx/Makefile.boot
 create mode 100644 arch/arm/mach-imx/mach-vf610m4.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 32cbbd5..69f0bad 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -455,6 +455,18 @@ config ARCH_FOOTBRIDGE
 	  Support for systems based on the DC21285 companion chip
 	  ("FootBridge"), such as the Simtec CATS and the Rebel NetWinder.
 
+menuconfig ARCH_MXCM4
+	bool "Freescale Vybrid/i.MX family on Cortex-M4" if !MMU
+	select ARCH_REQUIRE_GPIOLIB
+	select ARM_CPU_SUSPEND if PM
+	select CLKSRC_MMIO
+	select GENERIC_IRQ_CHIP
+	select PINCTRL
+	select PM_OPP if PM
+	select SOC_BUS
+	help
+	  Support for Freescale Vybrid/iMX-based family of processors on Cortex-M4
+
 config ARCH_NETX
 	bool "Hilscher NetX based"
 	select ARM_VIC
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index b11ad54..3ac00e7 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -435,7 +435,7 @@ choice
 
 	config DEBUG_VF_UART
 		bool "Vybrid UART"
-		depends on SOC_VF610
+		depends on SOC_VF610 || SOC_VF610M4
 		help
 		  Say Y here if you want kernel low-level debugging support
 		  on Vybrid based platforms.
@@ -994,7 +994,7 @@ config DEBUG_VF_UART_PORT
 	int "Vybrid Debug UART Port Selection" if DEBUG_VF_UART
 	default 1
 	range 0 3
-	depends on SOC_VF610
+	depends on SOC_VF610 || SOC_VF610M4
 	help
 	  Choose UART port on which kernel low-level debug messages
 	  should be output.
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 0ce9d0f..55339fd 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -174,6 +174,7 @@ machine-$(CONFIG_ARCH_MSM)		+= msm
 machine-$(CONFIG_ARCH_MV78XX0)		+= mv78xx0
 machine-$(CONFIG_ARCH_MVEBU)		+= mvebu
 machine-$(CONFIG_ARCH_MXC)		+= imx
+machine-$(CONFIG_ARCH_MXCM4)		+= imx
 machine-$(CONFIG_ARCH_MEDIATEK)		+= mediatek
 machine-$(CONFIG_ARCH_MXS)		+= mxs
 machine-$(CONFIG_ARCH_NETX)		+= netx
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index be9a51a..7ed3ab9 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -739,3 +739,25 @@ endif
 source "arch/arm/mach-imx/devices/Kconfig"
 
 endif
+
+if !MMU && ARCH_MXCM4
+
+config SOC_VF610M4
+	bool "Vybrid Family VF610 support for Cortex-M4"
+	select ARCH_REQUIRE_GPIOLIB
+	select PINCTRL_VF610
+	select PINCTRL_IMX
+	select ARM_NVIC
+	select AUTO_ZRELADDR
+	select CPU_V7M
+	select COMMON_CLK
+	select GENERIC_CLOCKEVENTS
+	select NO_DMA
+	select NO_IOPORT_MAP
+	select SPARSE_IRQ
+	select USE_OF
+	select VF_PIT_TIMER
+	help
+	  Support for Vybrid Familiy VF610's Cortex-M4
+
+endif
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index 23c0293..d326220 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -113,5 +113,6 @@ obj-$(CONFIG_SOC_IMX51) += mach-imx51.o
 obj-$(CONFIG_SOC_IMX53) += mach-imx53.o
 
 obj-$(CONFIG_SOC_VF610) += clk-vf610.o mach-vf610.o
+obj-$(CONFIG_SOC_VF610M4) += clk-vf610.o mach-vf610m4.o
 
 obj-y += devices/
diff --git a/arch/arm/mach-imx/Makefile.boot b/arch/arm/mach-imx/Makefile.boot
new file mode 100644
index 0000000..e69de29
diff --git a/arch/arm/mach-imx/mach-vf610m4.c b/arch/arm/mach-imx/mach-vf610m4.c
new file mode 100644
index 0000000..d534f01
--- /dev/null
+++ b/arch/arm/mach-imx/mach-vf610m4.c
@@ -0,0 +1,16 @@
+#include <linux/kernel.h>
+
+#include <asm/v7m.h>
+
+#include <asm/mach/arch.h>
+
+static const char *const vf610m4_compat[] __initconst = {
+	"fsl,vf610m4",
+	NULL
+};
+
+
+DT_MACHINE_START(VF610M4DT, "VF610 on Cortex-M4 (Device Tree Support)")
+	.dt_compat = vf610m4_compat,
+	.restart = armv7m_restart,
+MACHINE_END
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 4511358..eef90c0 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -155,7 +155,7 @@ config MMC_SDHCI_CNS3XXX
 
 config MMC_SDHCI_ESDHC_IMX
 	tristate "SDHCI support for the Freescale eSDHC/uSDHC i.MX controller"
-	depends on ARCH_MXC
+	depends on ARCH_MXC || ARCH_MXCM4
 	depends on MMC_SDHCI_PLTFM
 	select MMC_SDHCI_IO_ACCESSORS
 	help
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index bfd2c2e..508dc95 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -181,7 +181,7 @@ config PINCTRL_IMX6SX
 
 config PINCTRL_VF610
 	bool "Freescale Vybrid VF610 pinctrl driver"
-	depends on SOC_VF610
+	depends on SOC_VF610 || SOC_VF610M4
 	select PINCTRL_IMX
 	help
 	  Say Y here to enable the Freescale Vybrid VF610 pinctrl driver
-- 
2.1.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 3/7] ARM: vf610m4: add new machine and SoC for Vybrid on Cortex-M4

[Arnd Bergmann]

On Sunday 12 October 2014 20:13:57 Stefan Agner wrote:
> This patch adds a new machine ARCH_MXCM4 which requires !MMU and
> !MULTIARCH and is meant as machine for the hetregenous multi-core
> Vybrid/i.MX SoC's to run Linux on the Cortex-M4.
> 
> The first SoC supported is Vybrid on Cortex-M4 (SOC_VF610M4).
> 
> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
> ---
> Not sure whether we really need a new MACH, but since MACH_MXC needs
> MULTIARCH, which in turn conflicts with !MMU, I guess there is no
> easier way to do it... And then, this also needs a new SOC.

I've carried an experimental patch to enable !MMU in combination with
MULTIPLATFORM for a while, it's probably time to do this for real now,
especially since we now have two !MMU platforms that can be built
together. Independent of the question of whether such a combined kernel
could run on real hardware or anybody would want to run such a kernel
if it were possible, I think it's very useful to be able to build
allmodconfig with MMU disabled and get all drivers for the available
platforms for build testing.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 3/7] ARM: vf610m4: add new machine and SoC for Vybrid on Cortex-M4

[Stefan Agner]

Am 2014-10-12 20:51, schrieb Arnd Bergmann:
> On Sunday 12 October 2014 20:13:57 Stefan Agner wrote:
>> This patch adds a new machine ARCH_MXCM4 which requires !MMU and
>> !MULTIARCH and is meant as machine for the hetregenous multi-core
>> Vybrid/i.MX SoC's to run Linux on the Cortex-M4.
>>
>> The first SoC supported is Vybrid on Cortex-M4 (SOC_VF610M4).
>>
>> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
>> ---
>> Not sure whether we really need a new MACH, but since MACH_MXC needs
>> MULTIARCH, which in turn conflicts with !MMU, I guess there is no
>> easier way to do it... And then, this also needs a new SOC.
> 
> I've carried an experimental patch to enable !MMU in combination with
> MULTIPLATFORM for a while, it's probably time to do this for real now,
> especially since we now have two !MMU platforms that can be built
> together. Independent of the question of whether such a combined kernel
> could run on real hardware or anybody would want to run such a kernel
> if it were possible, I think it's very useful to be able to build
> allmodconfig with MMU disabled and get all drivers for the available
> platforms for build testing.

Are these patches online somewhere?

That sounds interesting. I guess I can get rid of ARCH_MXCM4 then.
Still, SOC_VF610M4 will be needed. We just need to make ARCH_MXC also
available on !MMU and use if to distinguish !MMU/MMU SoC's.

--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 3/7] ARM: vf610m4: add new machine and SoC for Vybrid on Cortex-M4

[Arnd Bergmann]

On Monday 13 October 2014 12:03:12 Stefan Agner wrote:
> Am 2014-10-12 20:51, schrieb Arnd Bergmann:
> > On Sunday 12 October 2014 20:13:57 Stefan Agner wrote:
> >> This patch adds a new machine ARCH_MXCM4 which requires !MMU and
> >> !MULTIARCH and is meant as machine for the hetregenous multi-core
> >> Vybrid/i.MX SoC's to run Linux on the Cortex-M4.
> >>
> >> The first SoC supported is Vybrid on Cortex-M4 (SOC_VF610M4).
> >>
> >> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
> >> ---
> >> Not sure whether we really need a new MACH, but since MACH_MXC needs
> >> MULTIARCH, which in turn conflicts with !MMU, I guess there is no
> >> easier way to do it... And then, this also needs a new SOC.
> > 
> > I've carried an experimental patch to enable !MMU in combination with
> > MULTIPLATFORM for a while, it's probably time to do this for real now,
> > especially since we now have two !MMU platforms that can be built
> > together. Independent of the question of whether such a combined kernel
> > could run on real hardware or anybody would want to run such a kernel
> > if it were possible, I think it's very useful to be able to build
> > allmodconfig with MMU disabled and get all drivers for the available
> > platforms for build testing.
> 
> Are these patches online somewhere?
> 
> That sounds interesting. I guess I can get rid of ARCH_MXCM4 then.
> Still, SOC_VF610M4 will be needed. We just need to make ARCH_MXC also
> available on !MMU and use if to distinguish !MMU/MMU SoC's.

I have a long series of patches at
http://git.kernel.org/cgit/linux/kernel/git/arnd/playground.git
and I should upload a newer version of that.

The part with !MMU support has to be changed anyway, but you can
get a lot of useful patches from my tree if you look carefully.

We should probably have a Kconfig symbol

config ARCH_MULTIPLATFORM_STRICT
	bool "Allow only configurations that do not break multiplatform support"
	depends on ARCH_MULTIPLATFORM && EXPERT

and then make this mutually exclusive with all options that are known
to break multiplatform: !MMU, CPU_BIG_ENDIAN, DEBUG_LL, XIP_KERNEL,
!AUTO_ZRELADDR, !ARM_PATCH_PHYS_VIRT and a lot of the errata workarounds
that are currently 'depends on !MULTIPLATFORM'.

Also, we currently have a rather complex setup to pick the allowed
CPU architecture levels in arbitrary combinations. Adding in V7M
would make this even more complicated, so I'd rather simplify it first,
and change it into a "minimum architecture level" choice statement,
which in effect isn't all that different to what we have today.

Something like

choice "CPU Core family selection"

config ARCH_MULTI_V4_MIN
	bool "ARMv4 based platforms (FA526)"
	select ARCH_MULTI_V4
	select ARCH_MULTI_V4T
	select ARCH_MULTI_V5

config ARCH_MULTI_V4T_MIN
	bool "ARMv4T based platforms (ARM720T, ARM920T, ...)"
	select ARCH_MULTI_V4T
	select ARCH_MULTI_V5

config ARCH_MULTI_V5_MIN
	bool "ARMv5 based platforms (ARM926T, PJ1, ...)"
	select ARCH_MULTI_V5

config ARCH_MULTI_V6_MIN
	bool "ARMv6 based platforms (ARM1136r0)"
	select ARCH_MULTI_V6
	select ARCH_MULTI_V6K
	select ARCH_MULTI_V7
	select ARCH_MULTI_V7_VE

config ARCH_MULTI_V6K_MIN
	bool "ARMv6K based platforms (ARM1136r1, ARM1176, ARM11MPCORE)"
	select ARCH_MULTI_V6K
	select ARCH_MULTI_V7
	select ARCH_MULTI_V7VE

config ARCH_MULTI_V7_MIN
	bool "ARMv7 based platforms (Cortex-A5/A8/A9, PJ4, Scorpion)"
	select ARCH_MULTI_V7
	select ARCH_MULTI_V7VE

config ARCH_MULTI_V7_VEMIN
	bool "ARMv7VE based platforms (Cortex-A7/A12/A15/A17, Brahma-B15, Krait)"
	select ARCH_MULTI_V7VE

config ARCH_MULTI_V7M
	bool "ARMv7-M based platforms (Cortex-M3/M4/M7)"

endchoice

I'm not sure about the exact symbol names, we should try to minimize the
impact on existing configuration file when doing this.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 4/7] ARM: dts: add support for Vybrid running on Cortex-M4

[Stefan Agner]

This adds an initial device tree to run Linux on the Cortex-M4 on
Vybrid.

HACK: Because we include armv7-m.dtsi, the soc node happens to
be before the clock node. This is a problem for vf610-clk.c, which
tries to optain the fixed clocks defined in the clock nodes. But
because clock drivers are initialized sequencially, and we do not
have support for deferred probing, the clock initialization fails
horrible.
Move the armv7-m.dtsi include to the bottom to temporarily work
work around this...

Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
---
Maybe a dummy soc entry in armv7-m.dtsi also helps here. But a
hack as well. Is it common acceptable that the kernel depends
on DTS order?

 arch/arm/boot/dts/Makefile     |   1 +
 arch/arm/boot/dts/armv7-m.dtsi |   1 -
 arch/arm/boot/dts/vf610m4.dts  | 144 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 145 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/vf610m4.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b8c5cd3..b1c6c1d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -64,6 +64,7 @@ dtb-$(CONFIG_ARCH_BRCMSTB) += \
 dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
 	da850-evm.dtb
 dtb-$(CONFIG_ARCH_EFM32) += efm32gg-dk3750.dtb
+dtb-$(CONFIG_SOC_VF610M4) += vf610m4.dtb
 dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
 	exynos4210-smdkv310.dtb \
 	exynos4210-trats.dtb \
diff --git a/arch/arm/boot/dts/armv7-m.dtsi b/arch/arm/boot/dts/armv7-m.dtsi
index 5a660d0..0516484 100644
--- a/arch/arm/boot/dts/armv7-m.dtsi
+++ b/arch/arm/boot/dts/armv7-m.dtsi
@@ -1,4 +1,3 @@
-#include "skeleton.dtsi"
 
 / {
 	nvic: nv-interrupt-controller  {
diff --git a/arch/arm/boot/dts/vf610m4.dts b/arch/arm/boot/dts/vf610m4.dts
new file mode 100644
index 0000000..61488fe
--- /dev/null
+++ b/arch/arm/boot/dts/vf610m4.dts
@@ -0,0 +1,144 @@
+/*
+ * Device tree for VF610 Cortex-M4 support
+ */
+
+/dts-v1/;
+#include "skeleton.dtsi"
+#include "vf610-pinfunc.h"
+#include <dt-bindings/clock/vf610-clock.h>
+
+/ {
+	model = "VF610 Cortex-M4";
+	compatible = "fsl,vf610m4";
+
+	chosen {
+		bootargs = "console=ttyLP0,115200 ignore_loglevel ihash_entries=64 dhash_entries=64 earlyprintk clk_ignore_unused init=/linuxrc root=/dev/mmcblk0p2 rootwait";
+	};
+
+	memory {
+		reg = <0x88000000 0x2000000>;
+	};
+
+	aliases {
+		serial0 = &uart2;
+	};
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		sxosc {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+
+		fxosc {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <24000000>;
+		};
+	};
+
+	soc {
+		aips0: aips-bus@40000000 {
+			compatible = "fsl,aips-bus", "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			reg = <0x40000000 0x70000>;
+			ranges;
+
+/*
+			uart0: serial@40027000 {
+				compatible = "fsl,vf610-lpuart";
+				reg = <0x40027000 0x1000>;
+				interrupts = <61>;
+				clocks = <&clks VF610_CLK_UART0>;
+				clock-names = "ipg";
+				status = "okay";
+			};
+
+			uart1: serial@40028000 {
+				compatible = "fsl,vf610-lpuart";
+				reg = <0x40028000 0x1000>;
+				interrupts = <62>;
+				clocks = <&clks VF610_CLK_UART1>;
+				clock-names = "ipg";
+				status = "okay";
+			};
+*/
+			uart2: serial@40029000 {
+				compatible = "fsl,vf610-lpuart";
+				reg = <0x40029000 0x1000>;
+				interrupts = <63>;
+				clocks = <&clks VF610_CLK_UART2>;
+				clock-names = "ipg";
+				status = "okay";
+			};
+
+			pit: pit@40037000 {
+				compatible = "fsl,vf610-pit";
+				reg = <0x40037000 0x1000>;
+				interrupts = <39>;
+				clocks = <&clks VF610_CLK_PIT>;
+				clock-names = "pit";
+			};
+
+			iomuxc: iomuxc@40048000 {
+				compatible = "fsl,vf610-iomuxc";
+				reg = <0x40048000 0x1000>;
+				#gpio-range-cells = <3>;
+
+				vf610-colibri {
+					pinctrl_esdhc1: esdhc1grp {
+						fsl,pins = <
+							VF610_PAD_PTA24__ESDHC1_CLK	0x31ef
+							VF610_PAD_PTA25__ESDHC1_CMD	0x31ef
+							VF610_PAD_PTA26__ESDHC1_DAT0	0x31ef
+							VF610_PAD_PTA27__ESDHC1_DAT1	0x31ef
+							VF610_PAD_PTA28__ESDHC1_DATA2	0x31ef
+							VF610_PAD_PTA29__ESDHC1_DAT3	0x31ef
+							VF610_PAD_PTB20__GPIO_42	0x219d
+						>;
+					};
+				};
+			};
+
+			anatop@40050000 {
+				compatible = "fsl,vf610-anatop";
+				reg = <0x40050000 0x1000>;
+			};
+
+			clks: ccm@4006b000 {
+				compatible = "fsl,vf610-ccm";
+				reg = <0x4006b000 0x1000>;
+				#clock-cells = <1>;
+			};
+		};
+
+		aips1: aips-bus@40080000 {
+			compatible = "fsl,aips-bus", "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			reg = <0x40080000 0x80000>;
+			ranges;
+
+
+			esdhc1: esdhc@400b2000 {
+				compatible = "fsl,imx53-esdhc";
+				reg = <0x400b2000 0x1000>;
+				interrupts = <28>;
+				clocks = <&clks VF610_CLK_IPG_BUS>,
+					<&clks VF610_CLK_PLATFORM_BUS>,
+					<&clks VF610_CLK_ESDHC1>;
+				clock-names = "ipg", "ahb", "per";
+				bus-width = <4>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_esdhc1>;
+				status = "okay";
+			};
+		};
+	};
+};
+
+#include "armv7-m.dtsi"
-- 
2.1.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 4/7] ARM: dts: add support for Vybrid running on Cortex-M4

[Arnd Bergmann]

On Sunday 12 October 2014 20:13:58 Stefan Agner wrote:
> This adds an initial device tree to run Linux on the Cortex-M4 on
> Vybrid.
> 
> HACK: Because we include armv7-m.dtsi, the soc node happens to
> be before the clock node. This is a problem for vf610-clk.c, which
> tries to optain the fixed clocks defined in the clock nodes. But
> because clock drivers are initialized sequencially, and we do not
> have support for deferred probing, the clock initialization fails
> horrible.

I thought that was fixed recently.

> Move the armv7-m.dtsi include to the bottom to temporarily work
> work around this...
> 
> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
> ---
> Maybe a dummy soc entry in armv7-m.dtsi also helps here. But a
> hack as well. Is it common acceptable that the kernel depends
> on DTS order?

Generally speaking, the kernel should not rely on the order of
nodes in the dtb.

> diff --git a/arch/arm/boot/dts/vf610m4.dts b/arch/arm/boot/dts/vf610m4.dts
> new file mode 100644
> index 0000000..61488fe
> --- /dev/null
> +++ b/arch/arm/boot/dts/vf610m4.dts
> @@ -0,0 +1,144 @@
> +/*
> + * Device tree for VF610 Cortex-M4 support
> + */
> +
> +/dts-v1/;
> +#include "skeleton.dtsi"
> +#include "vf610-pinfunc.h"
> +#include <dt-bindings/clock/vf610-clock.h>
> +
> +/ {
> +	model = "VF610 Cortex-M4";
> +	compatible = "fsl,vf610m4";
> +
> +	chosen {
> +		bootargs = "console=ttyLP0,115200 ignore_loglevel ihash_entries=64 dhash_entries=64 earlyprintk clk_ignore_unused init=/linuxrc root=/dev/mmcblk0p2 rootwait";
> +	};
> +
> +	memory {
> +		reg = <0x88000000 0x2000000>;
> +	};
> +
> +	aliases {
> +		serial0 = &uart2;
> +	};

All of these are board specific, the common way to handle this is to make
a vf610m4.dtsi file and include that from a v6610m4-myboard.dts file
which sets the properties.

The command line should actually be set by the boot loader.

Also, it would be good to make the uart driver handle the early console
setup through the stdout-path property.

> +
> +	soc {
> +		aips0: aips-bus@40000000 {
> +			compatible = "fsl,aips-bus", "simple-bus";
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			reg = <0x40000000 0x70000>;
> +			ranges;
> +
> +/*
> +			uart0: serial@40027000 {
> +				compatible = "fsl,vf610-lpuart";
> +				reg = <0x40027000 0x1000>;
> +				interrupts = <61>;
> +				clocks = <&clks VF610_CLK_UART0>;
> +				clock-names = "ipg";
> +				status = "okay";
> +			};
> +
> +			uart1: serial@40028000 {
> +				compatible = "fsl,vf610-lpuart";
> +				reg = <0x40028000 0x1000>;
> +				interrupts = <62>;
> +				clocks = <&clks VF610_CLK_UART1>;
> +				clock-names = "ipg";
> +				status = "okay";
> +			};
> +*/

Don't comment out nodes, just make them as 'status="disabled"'.

For any peripherals that are accessible to both the m4 and the a5
core, it might be nice to put them into a shared .dtsi file.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 4/7] ARM: dts: add support for Vybrid running on Cortex-M4

[Stefan Agner]

Am 2014-10-12 20:56, schrieb Arnd Bergmann:
> On Sunday 12 October 2014 20:13:58 Stefan Agner wrote:
>> This adds an initial device tree to run Linux on the Cortex-M4 on
>> Vybrid.
>>
>> HACK: Because we include armv7-m.dtsi, the soc node happens to
>> be before the clock node. This is a problem for vf610-clk.c, which
>> tries to optain the fixed clocks defined in the clock nodes. But
>> because clock drivers are initialized sequencially, and we do not
>> have support for deferred probing, the clock initialization fails
>> horrible.
> 
> I thought that was fixed recently.

Unless it was very recently, it didn't solve my case.

Both, clk-fixed-rate as well as clk-vf610 are initialized using
CLK_OF_DECLARE. So I guess its the dt order. Or is it compile time
order? But I think driver code is linked before arch code. 

> 
>> Move the armv7-m.dtsi include to the bottom to temporarily work
>> work around this...
>>
>> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
>> ---
>> Maybe a dummy soc entry in armv7-m.dtsi also helps here. But a
>> hack as well. Is it common acceptable that the kernel depends
>> on DTS order?
> 
> Generally speaking, the kernel should not rely on the order of
> nodes in the dtb.
> 
>> diff --git a/arch/arm/boot/dts/vf610m4.dts b/arch/arm/boot/dts/vf610m4.dts
>> new file mode 100644
>> index 0000000..61488fe
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/vf610m4.dts
>> @@ -0,0 +1,144 @@
>> +/*
>> + * Device tree for VF610 Cortex-M4 support
>> + */
>> +
>> +/dts-v1/;
>> +#include "skeleton.dtsi"
>> +#include "vf610-pinfunc.h"
>> +#include <dt-bindings/clock/vf610-clock.h>
>> +
>> +/ {
>> +	model = "VF610 Cortex-M4";
>> +	compatible = "fsl,vf610m4";
>> +
>> +	chosen {
>> +		bootargs = "console=ttyLP0,115200 ignore_loglevel ihash_entries=64 dhash_entries=64 earlyprintk clk_ignore_unused init=/linuxrc root=/dev/mmcblk0p2 rootwait";
>> +	};
>> +
>> +	memory {
>> +		reg = <0x88000000 0x2000000>;
>> +	};
>> +
>> +	aliases {
>> +		serial0 = &uart2;
>> +	};
> 
> All of these are board specific, the common way to handle this is to make
> a vf610m4.dtsi file and include that from a v6610m4-myboard.dts file
> which sets the properties.
> 
> The command line should actually be set by the boot loader.

Hm, this would then be a feature needed in the small boot loader I plan
to integrate with m4boot.


> Also, it would be good to make the UART driver handle the early console
> setup through the stdout-path property.

Ok, having a look at that. Do I see things right that this is somewhat
like a default "console=" argument? But probably not picked up by
user-space (systemd) later on...

> 
>> +
>> +	soc {
>> +		aips0: aips-bus@40000000 {
>> +			compatible = "fsl,aips-bus", "simple-bus";
>> +			#address-cells = <1>;
>> +			#size-cells = <1>;
>> +			reg = <0x40000000 0x70000>;
>> +			ranges;
>> +
>> +/*
>> +			uart0: serial@40027000 {
>> +				compatible = "fsl,vf610-lpuart";
>> +				reg = <0x40027000 0x1000>;
>> +				interrupts = <61>;
>> +				clocks = <&clks VF610_CLK_UART0>;
>> +				clock-names = "ipg";
>> +				status = "okay";
>> +			};
>> +
>> +			uart1: serial@40028000 {
>> +				compatible = "fsl,vf610-lpuart";
>> +				reg = <0x40028000 0x1000>;
>> +				interrupts = <62>;
>> +				clocks = <&clks VF610_CLK_UART1>;
>> +				clock-names = "ipg";
>> +				status = "okay";
>> +			};
>> +*/
> 
> Don't comment out nodes, just make them as 'status="disabled"'.
> 
> For any peripherals that are accessible to both the m4 and the a5
> core, it might be nice to put them into a shared .dtsi file.

Hm, actually all peripherals are accessible from both core. However,
since we do have different interrupt controllers, the interrupt property
looks different. But I guess it's perfectly ok to add this property in
the m4 and a5 specific dtsi.

We already discussed the shared dtsi issue for Vybird in a different
thread (VF500 support). Considering we want to create a shared dtsi for
both cores and all variants, I guess it would something look like that:

vfxxx.dtsi => vf500.dtsi (Cortex-A5, single core)
           => vf600m4.dtsi (Cortex-M4)
           => vf600.dtsi (Cortex-A5)
           => vf610.dtsi (Cortex-A5 with L2 Cache)

Or do we want the core included on all dtsi?

vfxxx.dtsi => vf500a5.dtsi (Cortex-A5, single core)
           => vf600m4.dtsi (Cortex-M4)
           => vf600a5.dtsi (Cortex-A5)
           => vf610a5.dtsi (Cortex-A5 with L2 Cache)

--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 4/7] ARM: dts: add support for Vybrid running on Cortex-M4

[Mark Rutland]

On Sun, Oct 12, 2014 at 07:13:58PM +0100, Stefan Agner wrote:
> This adds an initial device tree to run Linux on the Cortex-M4 on
> Vybrid.
> 
> HACK: Because we include armv7-m.dtsi, the soc node happens to
> be before the clock node. This is a problem for vf610-clk.c, which
> tries to optain the fixed clocks defined in the clock nodes. But
> because clock drivers are initialized sequencially, and we do not
> have support for deferred probing, the clock initialization fails
> horrible.
> Move the armv7-m.dtsi include to the bottom to temporarily work
> work around this...
> 
> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
> ---
> Maybe a dummy soc entry in armv7-m.dtsi also helps here. But a
> hack as well. Is it common acceptable that the kernel depends
> on DTS order?

The kernel should not depend on DTS ordering. We should sort out
deferred probing if there is an issue with it.

[...]

> +	clocks {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		sxosc {
> +			compatible = "fixed-clock";
> +			#clock-cells = <0>;
> +			clock-frequency = <32768>;
> +		};
> +
> +		fxosc {
> +			compatible = "fixed-clock";
> +			#clock-cells = <0>;
> +			clock-frequency = <24000000>;
> +		};
> +	};

Please get rid of the clocks node and put these under the root node.
There is nothing special about clocks, and the kernel in no way handles
a clocks node specially.

> +
> +	soc {
> +		aips0: aips-bus@40000000 {
> +			compatible = "fsl,aips-bus", "simple-bus";
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			reg = <0x40000000 0x70000>;

Out of curiosity, given that this can be driven as a simple-bus, what do
the aips bus registers allow to be configured?

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 4/7] ARM: dts: add support for Vybrid running on Cortex-M4

[Stefan Agner]

Am 2014-10-13 12:32, schrieb Mark Rutland:
> On Sun, Oct 12, 2014 at 07:13:58PM +0100, Stefan Agner wrote:
>> This adds an initial device tree to run Linux on the Cortex-M4 on
>> Vybrid.
>>
>> HACK: Because we include armv7-m.dtsi, the soc node happens to
>> be before the clock node. This is a problem for vf610-clk.c, which
>> tries to optain the fixed clocks defined in the clock nodes. But
>> because clock drivers are initialized sequencially, and we do not
>> have support for deferred probing, the clock initialization fails
>> horrible.
>> Move the armv7-m.dtsi include to the bottom to temporarily work
>> work around this...
>>
>> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
>> ---
>> Maybe a dummy soc entry in armv7-m.dtsi also helps here. But a
>> hack as well. Is it common acceptable that the kernel depends
>> on DTS order?
> 
> The kernel should not depend on DTS ordering. We should sort out
> deferred probing if there is an issue with it.
> 
> [...]

Yes I guess to make this working independent of device tree order, we
need to defer probing of vf610-clk when the fixed clocks are not
initialized yet. 

Clock initialization (using CLK_OF_DECLARE) doesn't support EPROBE_DEFER
currently. 

We seem to have already a work around merged because of this.
http://thread.gmane.org/gmane.linux.kernel/1635576

Anybody tried to reverse device tree parsing to unveil how many such
assumptions are still slumbering?

 
>> +	clocks {
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +
>> +		sxosc {
>> +			compatible = "fixed-clock";
>> +			#clock-cells = <0>;
>> +			clock-frequency = <32768>;
>> +		};
>> +
>> +		fxosc {
>> +			compatible = "fixed-clock";
>> +			#clock-cells = <0>;
>> +			clock-frequency = <24000000>;
>> +		};
>> +	};
> 
> Please get rid of the clocks node and put these under the root node.
> There is nothing special about clocks, and the kernel in no way handles
> a clocks node specially.
> 
>> +
>> +	soc {
>> +		aips0: aips-bus@40000000 {
>> +			compatible = "fsl,aips-bus", "simple-bus";
>> +			#address-cells = <1>;
>> +			#size-cells = <1>;
>> +			reg = <0x40000000 0x70000>;
> 
> Out of curiosity, given that this can be driven as a simple-bus, what do
> the aips bus registers allow to be configured?
> 

There is a chapter about the AIPS lite bus in the RM, but according to
this the AIPS lite bus itself has no registers by itself. 

--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 4/7] ARM: dts: add support for Vybrid running on Cortex-M4

[Arnd Bergmann]

On Monday 13 October 2014 13:08:12 Stefan Agner wrote:
> Am 2014-10-13 12:32, schrieb Mark Rutland:
> > On Sun, Oct 12, 2014 at 07:13:58PM +0100, Stefan Agner wrote:
> >> This adds an initial device tree to run Linux on the Cortex-M4 on
> >> Vybrid.
> >>
> >> HACK: Because we include armv7-m.dtsi, the soc node happens to
> >> be before the clock node. This is a problem for vf610-clk.c, which
> >> tries to optain the fixed clocks defined in the clock nodes. But
> >> because clock drivers are initialized sequencially, and we do not
> >> have support for deferred probing, the clock initialization fails
> >> horrible.
> >> Move the armv7-m.dtsi include to the bottom to temporarily work
> >> work around this...
> >>
> >> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
> >> ---
> >> Maybe a dummy soc entry in armv7-m.dtsi also helps here. But a
> >> hack as well. Is it common acceptable that the kernel depends
> >> on DTS order?
> > 
> > The kernel should not depend on DTS ordering. We should sort out
> > deferred probing if there is an issue with it.
> > 
> > [...]
> 
> Yes I guess to make this working independent of device tree order, we
> need to defer probing of vf610-clk when the fixed clocks are not
> initialized yet. 
> 
> Clock initialization (using CLK_OF_DECLARE) doesn't support EPROBE_DEFER
> currently. 
> 
> We seem to have already a work around merged because of this.
> http://thread.gmane.org/gmane.linux.kernel/1635576

Ah, maybe that's what I remembered. The clock handling should probably
do something similar to what we do for irqchips, where we probe the
parents first.

> Anybody tried to reverse device tree parsing to unveil how many such
> assumptions are still slumbering?

Not that I'm aware of. Sounds like a good thing to try.

> >> +
> >> +    soc {
> >> +            aips0: aips-bus@40000000 {
> >> +                    compatible = "fsl,aips-bus", "simple-bus";
> >> +                    #address-cells = <1>;
> >> +                    #size-cells = <1>;
> >> +                    reg = <0x40000000 0x70000>;
> > 
> > Out of curiosity, given that this can be driven as a simple-bus, what do
> > the aips bus registers allow to be configured?
> > 
> 
> There is a chapter about the AIPS lite bus in the RM, but according to
> this the AIPS lite bus itself has no registers by itself. 

I just noticed that the only child you list below this node uses
registers within the area of the bus. I suspect you just confused
'reg' and 'ranges' here, please use 'ranges' to list which registers
are visible on the bus, and modify the 'reg' properties of the children
as necessary.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 4/7] ARM: dts: add support for Vybrid running on Cortex-M4

[Stefan Agner]

Am 2014-10-13 13:24, schrieb Arnd Bergmann:
> On Monday 13 October 2014 13:08:12 Stefan Agner wrote:
>> Am 2014-10-13 12:32, schrieb Mark Rutland:
>> > On Sun, Oct 12, 2014 at 07:13:58PM +0100, Stefan Agner wrote:
>> >> This adds an initial device tree to run Linux on the Cortex-M4 on
>> >> Vybrid.
>> >>
>> >> HACK: Because we include armv7-m.dtsi, the soc node happens to
>> >> be before the clock node. This is a problem for vf610-clk.c, which
>> >> tries to optain the fixed clocks defined in the clock nodes. But
>> >> because clock drivers are initialized sequencially, and we do not
>> >> have support for deferred probing, the clock initialization fails
>> >> horrible.
>> >> Move the armv7-m.dtsi include to the bottom to temporarily work
>> >> work around this...
>> >>
>> >> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
>> >> ---
>> >> Maybe a dummy soc entry in armv7-m.dtsi also helps here. But a
>> >> hack as well. Is it common acceptable that the kernel depends
>> >> on DTS order?
>> >
>> > The kernel should not depend on DTS ordering. We should sort out
>> > deferred probing if there is an issue with it.
>> >
>> > [...]
>>
>> Yes I guess to make this working independent of device tree order, we
>> need to defer probing of vf610-clk when the fixed clocks are not
>> initialized yet.
>>
>> Clock initialization (using CLK_OF_DECLARE) doesn't support EPROBE_DEFER
>> currently.
>>
>> We seem to have already a work around merged because of this.
>> http://thread.gmane.org/gmane.linux.kernel/1635576
> 
> Ah, maybe that's what I remembered. The clock handling should probably
> do something similar to what we do for irqchips, where we probe the
> parents first.
> 

Would parent really work here? I mean, vf610-"clk"'s parent is
"aips-bus", then "soc" versus "fxosc"'s parent is "clock" (which I can
omit according to Mark), so different branches starting from the root. A
depth based initialization order would help, but this looks rather
arbitrary.

>> Anybody tried to reverse device tree parsing to unveil how many such
>> assumptions are still slumbering?
> 
> Not that I'm aware of. Sounds like a good thing to try.
> 
>> >> +
>> >> +    soc {
>> >> +            aips0: aips-bus@40000000 {
>> >> +                    compatible = "fsl,aips-bus", "simple-bus";
>> >> +                    #address-cells = <1>;
>> >> +                    #size-cells = <1>;
>> >> +                    reg = <0x40000000 0x70000>;
>> >
>> > Out of curiosity, given that this can be driven as a simple-bus, what do
>> > the aips bus registers allow to be configured?
>> >
>>
>> There is a chapter about the AIPS lite bus in the RM, but according to
>> this the AIPS lite bus itself has no registers by itself.
> 
> I just noticed that the only child you list below this node uses
> registers within the area of the bus. I suspect you just confused
> 'reg' and 'ranges' here, please use 'ranges' to list which registers
> are visible on the bus, and modify the 'reg' properties of the children
> as necessary.

Oh yes, these seems wrong. I copied this from the vf610.dtsi, but when
we make one common file we can fix it for all then.

--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 4/7] ARM: dts: add support for Vybrid running on Cortex-M4

[Arnd Bergmann]

On Monday 13 October 2014 18:11:19 Stefan Agner wrote:
> Am 2014-10-13 13:24, schrieb Arnd Bergmann:
> > On Monday 13 October 2014 13:08:12 Stefan Agner wrote:
> >> Am 2014-10-13 12:32, schrieb Mark Rutland:
> >> > On Sun, Oct 12, 2014 at 07:13:58PM +0100, Stefan Agner wrote:
> >> >> This adds an initial device tree to run Linux on the Cortex-M4 on
> >> >> Vybrid.
> >> >>
> >> >> HACK: Because we include armv7-m.dtsi, the soc node happens to
> >> >> be before the clock node. This is a problem for vf610-clk.c, which
> >> >> tries to optain the fixed clocks defined in the clock nodes. But
> >> >> because clock drivers are initialized sequencially, and we do not
> >> >> have support for deferred probing, the clock initialization fails
> >> >> horrible.
> >> >> Move the armv7-m.dtsi include to the bottom to temporarily work
> >> >> work around this...
> >> >>
> >> >> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
> >> >> ---
> >> >> Maybe a dummy soc entry in armv7-m.dtsi also helps here. But a
> >> >> hack as well. Is it common acceptable that the kernel depends
> >> >> on DTS order?
> >> >
> >> > The kernel should not depend on DTS ordering. We should sort out
> >> > deferred probing if there is an issue with it.
> >> >
> >> > [...]
> >>
> >> Yes I guess to make this working independent of device tree order, we
> >> need to defer probing of vf610-clk when the fixed clocks are not
> >> initialized yet.
> >>
> >> Clock initialization (using CLK_OF_DECLARE) doesn't support EPROBE_DEFER
> >> currently.
> >>
> >> We seem to have already a work around merged because of this.
> >> http://thread.gmane.org/gmane.linux.kernel/1635576
> > 
> > Ah, maybe that's what I remembered. The clock handling should probably
> > do something similar to what we do for irqchips, where we probe the
> > parents first.
> > 
> 
> Would parent really work here? I mean, vf610-"clk"'s parent is
> "aips-bus", then "soc" versus "fxosc"'s parent is "clock" (which I can
> omit according to Mark), so different branches starting from the root. A
> depth based initialization order would help, but this looks rather
> arbitrary.

I meant parents in the clock tree not the device tree. The clock parents
are the nodes listed in the 'clocks' property of a child clock device
node.

This would be similar to how it works for interrupt-controllers, where
we follow the "interrupt-parent" properties.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 4/7] ARM: dts: add support for Vybrid running on Cortex-M4

[Stefan Agner]

Am 2014-10-13 21:54, schrieb Arnd Bergmann:
> On Monday 13 October 2014 18:11:19 Stefan Agner wrote:
>> Am 2014-10-13 13:24, schrieb Arnd Bergmann:
>> > On Monday 13 October 2014 13:08:12 Stefan Agner wrote:
>> >> Am 2014-10-13 12:32, schrieb Mark Rutland:
>> >> > On Sun, Oct 12, 2014 at 07:13:58PM +0100, Stefan Agner wrote:
>> >> >> This adds an initial device tree to run Linux on the Cortex-M4 on
>> >> >> Vybrid.
>> >> >>
>> >> >> HACK: Because we include armv7-m.dtsi, the soc node happens to
>> >> >> be before the clock node. This is a problem for vf610-clk.c, which
>> >> >> tries to optain the fixed clocks defined in the clock nodes. But
>> >> >> because clock drivers are initialized sequencially, and we do not
>> >> >> have support for deferred probing, the clock initialization fails
>> >> >> horrible.
>> >> >> Move the armv7-m.dtsi include to the bottom to temporarily work
>> >> >> work around this...
>> >> >>
>> >> >> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
>> >> >> ---
>> >> >> Maybe a dummy soc entry in armv7-m.dtsi also helps here. But a
>> >> >> hack as well. Is it common acceptable that the kernel depends
>> >> >> on DTS order?
>> >> >
>> >> > The kernel should not depend on DTS ordering. We should sort out
>> >> > deferred probing if there is an issue with it.
>> >> >
>> >> > [...]
>> >>
>> >> Yes I guess to make this working independent of device tree order, we
>> >> need to defer probing of vf610-clk when the fixed clocks are not
>> >> initialized yet.
>> >>
>> >> Clock initialization (using CLK_OF_DECLARE) doesn't support EPROBE_DEFER
>> >> currently.
>> >>
>> >> We seem to have already a work around merged because of this.
>> >> http://thread.gmane.org/gmane.linux.kernel/1635576
>> >
>> > Ah, maybe that's what I remembered. The clock handling should probably
>> > do something similar to what we do for irqchips, where we probe the
>> > parents first.
>> >
>>
>> Would parent really work here? I mean, vf610-"clk"'s parent is
>> "aips-bus", then "soc" versus "fxosc"'s parent is "clock" (which I can
>> omit according to Mark), so different branches starting from the root. A
>> depth based initialization order would help, but this looks rather
>> arbitrary.
> 
> I meant parents in the clock tree not the device tree. The clock parents
> are the nodes listed in the 'clocks' property of a child clock device
> node.
> 
> This would be similar to how it works for interrupt-controllers, where
> we follow the "interrupt-parent" properties.
> 

Ah ok I see. This parent/child relation is not yet part of the Vybrid
device tree:


slowosc: sxosc {
	compatible = "fixed-clock";
	#clock-cells = <0>;
	clock-frequency = <32768>;
};
fastosc: fxosc {
	compatible = "fixed-clock";
	#clock-cells = <0>;
	clock-frequency = <24000000>;
};

....

clks: ccm@4006b000 {
	compatible = "fsl,vf610-ccm";
	reg = <0x4006b000 0x1000>;
	#clock-cells = <1>;
};

So we would need something like:

clocks = <&slowosc>, <&fastosc>;
clock-names = "sxosc", "fxosc";

But how can we identify clock tree entries? There is no marker like
"clock-controller;" currently, is there?

--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 4/7] ARM: dts: add support for Vybrid running on Cortex-M4

[Arnd Bergmann]

On Monday 13 October 2014 23:20:38 Stefan Agner wrote:
> Ah ok I see. This parent/child relation is not yet part of the Vybrid
> device tree:
> 
> 
> slowosc: sxosc {
>         compatible = "fixed-clock";
>         #clock-cells = <0>;
>         clock-frequency = <32768>;
> };
> fastosc: fxosc {
>         compatible = "fixed-clock";
>         #clock-cells = <0>;
>         clock-frequency = <24000000>;
> };
> 
> ....
> 
> clks: ccm@4006b000 {
>         compatible = "fsl,vf610-ccm";
>         reg = <0x4006b000 0x1000>;
>         #clock-cells = <1>;
> };
> 
> So we would need something like:
> 
> clocks = <&slowosc>, <&fastosc>;
> clock-names = "sxosc", "fxosc";
> 
> But how can we identify clock tree entries? There is no marker like
> "clock-controller;" currently, is there?

Actually it seems the of_clk_init does have all the code it needs:

        for_each_matching_node_and_match(np, matches, &match) {
                struct clock_provider *parent =
                        kzalloc(sizeof(struct clock_provider),  GFP_KERNEL);

                parent->clk_init_cb = match->data;
                parent->np = np;
                list_add_tail(&parent->node, &clk_provider_list);
        }

        while (!list_empty(&clk_provider_list)) {
                is_init_done = false;
                list_for_each_entry_safe(clk_provider, next,
                                        &clk_provider_list, node) {
                        if (force || parent_ready(clk_provider->np)) {

                                clk_provider->clk_init_cb(clk_provider->np);
                                of_clk_set_defaults(clk_provider->np, true);

                                list_del(&clk_provider->node);
                                kfree(clk_provider);
                                is_init_done = true;
                        }
                }

                /*
                 * We didn't manage to initialize any of the
                 * remaining providers during the last loop, so now we
                 * initialize all the remaining ones unconditionally
                 * in case the clock parent was not mandatory
                 */
                if (!is_init_done)
                        force = true;
        }

You are just missing the clock properties to describe the hierarchy
in your dts.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 5/7] irqchip: nvic: increase number of external interrupts to 112

[Stefan Agner]

So far only vectors for up to 48 external interrupts have been
registred in the vector table. Increase the amount of registred
external vectors to 112. Also add a warning in case NVIC reports
support for more interrupts than 128.

Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
---
 arch/arm/kernel/entry-v7m.S | 4 ++--
 drivers/irqchip/irq-nvic.c  | 2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/entry-v7m.S b/arch/arm/kernel/entry-v7m.S
index 2260f18..1c5deac 100644
--- a/arch/arm/kernel/entry-v7m.S
+++ b/arch/arm/kernel/entry-v7m.S
@@ -136,6 +136,6 @@ ENTRY(vector_table)
 	.long	__invalid_entry		@ 13 - Reserved
 	.long	__pendsv_entry		@ 14 - PendSV
 	.long	__invalid_entry		@ 15 - SysTick
-	.rept	64 - 16
-	.long	__irq_entry		@ 16..64 - External Interrupts
+	.rept	128 - 16
+	.long	__irq_entry		@ 16..128 - External Interrupts
 	.endr
diff --git a/drivers/irqchip/irq-nvic.c b/drivers/irqchip/irq-nvic.c
index 4ff0805..3ecb5fe 100644
--- a/drivers/irqchip/irq-nvic.c
+++ b/drivers/irqchip/irq-nvic.c
@@ -69,6 +69,8 @@ static int __init nvic_of_init(struct device_node *node,
 	if (irqs > NVIC_MAX_IRQ)
 		irqs = NVIC_MAX_IRQ;
 
+	WARN(irqs > 128, "vector table in entry-v7m.S configured for 128 irqs");
+
 	nvic_irq_domain =
 		irq_domain_add_linear(node, irqs, &irq_generic_chip_ops, NULL);
 	if (!nvic_irq_domain) {
-- 
2.1.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 6/7] ARM: vf610m4: HACK: get dtb pointer from SRC_GPR3

[Stefan Agner]

Get DTB pointer (located in r2) from SRC_GPR3 (argument register
for secondary core)

Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
---
This is clearly a hack but it works around the need of a boot loader
on the Cortex-M4. I guess there is no way neither its acceptable to
do this on machine level..? But then, this can also be done with a
minimal boot loader loaded just in front of the kernel by the m4boot
utility.

 arch/arm/kernel/head-nommu.S | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
index cc176b6..0468683 100644
--- a/arch/arm/kernel/head-nommu.S
+++ b/arch/arm/kernel/head-nommu.S
@@ -37,6 +37,10 @@
  *
  */
 
+#define	SRC_BASE	0x4006e000
+#define SRC_GPR2	0x28
+#define SRC_GPR3	0x2c
+
 	__HEAD
 
 #ifdef CONFIG_CPU_THUMBONLY
@@ -57,6 +61,10 @@ ENTRY(stext)
 #if defined(CONFIG_CPU_CP15)
 	mrc	p15, 0, r9, c0, c0		@ get processor id
 #elif defined(CONFIG_CPU_V7M)
+
+	ldr	r0, =SRC_BASE
+	ldr	r1, =0xffffffff		@ Machine ID
+	ldr	r2, [r0, #SRC_GPR3 ] 	@ DT pointer from argument register
 	ldr	r9, =BASEADDR_V7M_SCB
 	ldr	r9, [r9, V7M_SCB_CPUID]
 #else
-- 
2.1.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 6/7] ARM: vf610m4: HACK: get dtb pointer from SRC_GPR3

[Arnd Bergmann]

On Sunday 12 October 2014 20:14:00 Stefan Agner wrote:
> Get DTB pointer (located in r2) from SRC_GPR3 (argument register
> for secondary core)
> 
> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
> ---
> This is clearly a hack but it works around the need of a boot loader
> on the Cortex-M4. I guess there is no way neither its acceptable to
> do this on machine level..? But then, this can also be done with a
> minimal boot loader loaded just in front of the kernel by the m4boot
> utility.
> 

How do you actually enter the kernel on the m4? Do you use a
decompressor or XIP_KERNEL at the moment? There are probably 
lots of ways to do this, my first idea would be to have a vybrid
specific boot wrapper that consists of just a few assembly
instructions to set up the initial environment from wherever
it gets started.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 6/7] ARM: vf610m4: HACK: get dtb pointer from SRC_GPR3

[Stefan Agner]

Am 2014-10-12 21:00, schrieb Arnd Bergmann:
> On Sunday 12 October 2014 20:14:00 Stefan Agner wrote:
>> Get DTB pointer (located in r2) from SRC_GPR3 (argument register
>> for secondary core)
>>
>> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
>> ---
>> This is clearly a hack but it works around the need of a boot loader
>> on the Cortex-M4. I guess there is no way neither its acceptable to
>> do this on machine level..? But then, this can also be done with a
>> minimal boot loader loaded just in front of the kernel by the m4boot
>> utility.
>>
> 
> How do you actually enter the kernel on the m4? Do you use a
> decompressor or XIP_KERNEL at the moment? There are probably 
> lots of ways to do this, my first idea would be to have a vybrid
> specific boot wrapper that consists of just a few assembly
> instructions to set up the initial environment from wherever
> it gets started.

I use the XIP_KERNEL at the moment. There is a special memory area which
can be accessed through code bus of the Cortex-M4 (the ARM-v7m
architecture has two buses to the CPU, one for data, one for code. On
Vybrid you can distinguish between those two buses by using different
memory areas). So in order to make use of the Code bus, I would like to
place the kernel there, XIP kernel probably the easiest way to do
this...

--
Stefan 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 7/7] ARM: vf610m4: add defconfig for Linux on Vybrids Cortex-M4

[Stefan Agner]

Add defconfig for Linux on Vybrid (vf610) on the secondary Cortex-
M4 CPU. Currently, we use a XIP image which is loaded to the end
of RAM at 0x8f000000. DRAM base address is at 0x88000000.

Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
---
 arch/arm/configs/vf610m4_defconfig | 37 +++++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 arch/arm/configs/vf610m4_defconfig

diff --git a/arch/arm/configs/vf610m4_defconfig b/arch/arm/configs/vf610m4_defconfig
new file mode 100644
index 0000000..90c5a6c
--- /dev/null
+++ b/arch/arm/configs/vf610m4_defconfig
@@ -0,0 +1,37 @@
+CONFIG_NAMESPACES=y
+# CONFIG_SGETMASK_SYSCALL is not set
+CONFIG_EMBEDDED=y
+# CONFIG_SECCOMP is not set
+CONFIG_HZ_100=y
+# CONFIG_SUSPEND is not set
+# CONFIG_UEVENT_HELPER is not set
+# CONFIG_STANDALONE is not set
+# CONFIG_PREVENT_FIRMWARE_BUILD is not set
+# CONFIG_FIRMWARE_IN_KERNEL is not set
+CONFIG_SRAM=y
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_KEYBOARD_ATKBD is not set
+CONFIG_KEYBOARD_GPIO=y
+CONFIG_KEYBOARD_GPIO_POLLED=y
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+# CONFIG_VT is not set
+CONFIG_SERIAL_NONSTANDARD=y
+CONFIG_SERIAL_FSL_LPUART=y
+CONFIG_SERIAL_FSL_LPUART_CONSOLE=y
+# CONFIG_HW_RANDOM is not set
+CONFIG_GPIOLIB=y
+# CONFIG_HID is not set
+# CONFIG_USB_SUPPORT is not set
+CONFIG_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_PLTFM=y
+# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_EXT3_FS=y
+CONFIG_FRAME_WARN=1024
+# CONFIG_UNUSED_SYMBOLS is not set
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_DEBUG_MEMORY_INIT=y
+CONFIG_LOCKUP_DETECTOR=y
+# CONFIG_FTRACE is not set
+# CONFIG_VIRTUALIZATION is not set
-- 
2.1.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 0/7] ARM: vf610m4: Add Vybrid Cortex-M4 support

[Andreas Färber]

Hi Stefan,

Am 12.10.2014 um 20:13 schrieb Stefan Agner:
> One thing I noticed that when I move the xipImage below the DRAM base
> address, the kernel freezes:
> ...
> Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
> Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
> [freeze]
> 
> I think it happens when the scheduler gets started. Any idea what could
> go wrong here?

I ran into a similar issue on STM32F4 recently - hanging there, or:

Unhandled exception: IPSR = 00000006 LR = fffffff1
CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-rc5-00003-g489983a-dirty #25
task: 90432000 ti: 90434000 task.ti: 90434000

Unhandled exception: IPSR = 00000003 LR = fffffff1
CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-rc5-00003-g489983a-dirty #25
task: 90432000 ti: 90434000 task.ti: 90434000
-Boot 2010.03-00003-g934021a-dirty (Nov 26 2014 - 06:52:49)

My debugging indicated that %pF was not working, used among others in
checking for blacklisted initcalls. Disabling CONFIG_KALLSYMS worked
around this, so I assume something there is not compatible with XIP...

Regards,
Andreas

-- 
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 21284 AG Nürnberg
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 0/7] ARM: vf610m4: Add Vybrid Cortex-M4 support

[Stefan Agner]

Hi Andreas,

On 2014-11-28 15:17, Andreas Färber wrote:
> Hi Stefan,
> 
> Am 12.10.2014 um 20:13 schrieb Stefan Agner:
>> One thing I noticed that when I move the xipImage below the DRAM base
>> address, the kernel freezes:
>> ...
>> Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
>> Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
>> [freeze]
>>
>> I think it happens when the scheduler gets started. Any idea what could
>> go wrong here?
> 
> I ran into a similar issue on STM32F4 recently - hanging there, or:
> 
> Unhandled exception: IPSR = 00000006 LR = fffffff1
> CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-rc5-00003-g489983a-dirty #25
> task: 90432000 ti: 90434000 task.ti: 90434000
> 
> Unhandled exception: IPSR = 00000003 LR = fffffff1
> CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-rc5-00003-g489983a-dirty #25
> task: 90432000 ti: 90434000 task.ti: 90434000
> -Boot 2010.03-00003-g934021a-dirty (Nov 26 2014 - 06:52:49)
> 
> My debugging indicated that %pF was not working, used among others in
> checking for blacklisted initcalls. Disabling CONFIG_KALLSYMS worked
> around this, so I assume something there is not compatible with XIP...

Hm, interesting! So it needs to be somewhere in lib/vsprintf.c or even
kernel/kallsyms.c. If XIP is incompatible with the KALLSYMS, we should
fix this dependency. Maybe it's easily fixable, however I did not look
into that symbolic stuff. I would be helpful to have symbols even on M4
thought :-) Will probably have a look into it this weekend.

--
Stefan


> 
> Regards,
> Andreas

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html