* [RFC 1/7] ARM: vf610: add low level debug support for !MMU
2014-10-12 18:13 [RFC 0/7] ARM: vf610m4: Add Vybrid Cortex-M4 support Stefan Agner
@ 2014-10-12 18:13 ` Stefan Agner
2014-10-12 18:48 ` Arnd Bergmann
2014-10-12 18:13 ` [RFC 2/7] clocksource: add dependencies for Vybrid pit clocksource Stefan Agner
` (6 subsequent siblings)
7 siblings, 1 reply; 29+ messages in thread
From: Stefan Agner @ 2014-10-12 18:13 UTC (permalink / raw)
To: linux-arm-kernel
Add support for !MMU low level debug required for the secondary
Cortex-M4 core in Vybrid.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
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
^ permalink raw reply related [flat|nested] 29+ messages in thread* [RFC 1/7] ARM: vf610: add low level debug support for !MMU
2014-10-12 18:13 ` [RFC 1/7] ARM: vf610: add low level debug support for !MMU Stefan Agner
@ 2014-10-12 18:48 ` Arnd Bergmann
2014-10-13 9:26 ` Stefan Agner
0 siblings, 1 reply; 29+ messages in thread
From: Arnd Bergmann @ 2014-10-12 18:48 UTC (permalink / raw)
To: linux-arm-kernel
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@agner.ch>
> ---
> 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
^ permalink raw reply related [flat|nested] 29+ messages in thread* [RFC 1/7] ARM: vf610: add low level debug support for !MMU
2014-10-12 18:48 ` Arnd Bergmann
@ 2014-10-13 9:26 ` Stefan Agner
0 siblings, 0 replies; 29+ messages in thread
From: Stefan Agner @ 2014-10-13 9:26 UTC (permalink / raw)
To: linux-arm-kernel
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@agner.ch>
>> ---
>> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* [RFC 2/7] clocksource: add dependencies for Vybrid pit clocksource
2014-10-12 18:13 [RFC 0/7] ARM: vf610m4: Add Vybrid Cortex-M4 support Stefan Agner
2014-10-12 18:13 ` [RFC 1/7] ARM: vf610: add low level debug support for !MMU Stefan Agner
@ 2014-10-12 18:13 ` Stefan Agner
2014-10-12 18:18 ` Uwe Kleine-König
2014-10-12 18:13 ` [RFC 3/7] ARM: vf610m4: add new machine and SoC for Vybrid on Cortex-M4 Stefan Agner
` (5 subsequent siblings)
7 siblings, 1 reply; 29+ messages in thread
From: Stefan Agner @ 2014-10-12 18:13 UTC (permalink / raw)
To: linux-arm-kernel
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@agner.ch>
---
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
^ permalink raw reply related [flat|nested] 29+ messages in thread* [RFC 2/7] clocksource: add dependencies for Vybrid pit clocksource
2014-10-12 18:13 ` [RFC 2/7] clocksource: add dependencies for Vybrid pit clocksource Stefan Agner
@ 2014-10-12 18:18 ` Uwe Kleine-König
2014-10-13 9:46 ` Stefan Agner
0 siblings, 1 reply; 29+ messages in thread
From: Uwe Kleine-König @ 2014-10-12 18:18 UTC (permalink / raw)
To: linux-arm-kernel
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@agner.ch>
> ---
> 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/ |
^ permalink raw reply [flat|nested] 29+ messages in thread
* [RFC 2/7] clocksource: add dependencies for Vybrid pit clocksource
2014-10-12 18:18 ` Uwe Kleine-König
@ 2014-10-13 9:46 ` Stefan Agner
2014-10-13 10:57 ` Uwe Kleine-König
0 siblings, 1 reply; 29+ messages in thread
From: Stefan Agner @ 2014-10-13 9:46 UTC (permalink / raw)
To: linux-arm-kernel
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@agner.ch>
>> ---
>> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* [RFC 2/7] clocksource: add dependencies for Vybrid pit clocksource
2014-10-13 9:46 ` Stefan Agner
@ 2014-10-13 10:57 ` Uwe Kleine-König
0 siblings, 0 replies; 29+ messages in thread
From: Uwe Kleine-König @ 2014-10-13 10:57 UTC (permalink / raw)
To: linux-arm-kernel
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/ |
^ permalink raw reply [flat|nested] 29+ messages in thread
* [RFC 3/7] ARM: vf610m4: add new machine and SoC for Vybrid on Cortex-M4
2014-10-12 18:13 [RFC 0/7] ARM: vf610m4: Add Vybrid Cortex-M4 support Stefan Agner
2014-10-12 18:13 ` [RFC 1/7] ARM: vf610: add low level debug support for !MMU Stefan Agner
2014-10-12 18:13 ` [RFC 2/7] clocksource: add dependencies for Vybrid pit clocksource Stefan Agner
@ 2014-10-12 18:13 ` Stefan Agner
2014-10-12 18:51 ` Arnd Bergmann
2014-10-12 18:13 ` [RFC 4/7] ARM: dts: add support for Vybrid running " Stefan Agner
` (4 subsequent siblings)
7 siblings, 1 reply; 29+ messages in thread
From: Stefan Agner @ 2014-10-12 18:13 UTC (permalink / raw)
To: linux-arm-kernel
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@agner.ch>
---
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
^ permalink raw reply related [flat|nested] 29+ messages in thread* [RFC 3/7] ARM: vf610m4: add new machine and SoC for Vybrid on Cortex-M4
2014-10-12 18:13 ` [RFC 3/7] ARM: vf610m4: add new machine and SoC for Vybrid on Cortex-M4 Stefan Agner
@ 2014-10-12 18:51 ` Arnd Bergmann
2014-10-13 10:03 ` Stefan Agner
0 siblings, 1 reply; 29+ messages in thread
From: Arnd Bergmann @ 2014-10-12 18:51 UTC (permalink / raw)
To: linux-arm-kernel
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@agner.ch>
> ---
> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* [RFC 3/7] ARM: vf610m4: add new machine and SoC for Vybrid on Cortex-M4
2014-10-12 18:51 ` Arnd Bergmann
@ 2014-10-13 10:03 ` Stefan Agner
2014-10-13 10:57 ` Arnd Bergmann
0 siblings, 1 reply; 29+ messages in thread
From: Stefan Agner @ 2014-10-13 10:03 UTC (permalink / raw)
To: linux-arm-kernel
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@agner.ch>
>> ---
>> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* [RFC 3/7] ARM: vf610m4: add new machine and SoC for Vybrid on Cortex-M4
2014-10-13 10:03 ` Stefan Agner
@ 2014-10-13 10:57 ` Arnd Bergmann
0 siblings, 0 replies; 29+ messages in thread
From: Arnd Bergmann @ 2014-10-13 10:57 UTC (permalink / raw)
To: linux-arm-kernel
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@agner.ch>
> >> ---
> >> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* [RFC 4/7] ARM: dts: add support for Vybrid running on Cortex-M4
2014-10-12 18:13 [RFC 0/7] ARM: vf610m4: Add Vybrid Cortex-M4 support Stefan Agner
` (2 preceding siblings ...)
2014-10-12 18:13 ` [RFC 3/7] ARM: vf610m4: add new machine and SoC for Vybrid on Cortex-M4 Stefan Agner
@ 2014-10-12 18:13 ` Stefan Agner
2014-10-12 18:56 ` Arnd Bergmann
2014-10-13 10:32 ` Mark Rutland
2014-10-12 18:13 ` [RFC 5/7] irqchip: nvic: increase number of external interrupts to 112 Stefan Agner
` (3 subsequent siblings)
7 siblings, 2 replies; 29+ messages in thread
From: Stefan Agner @ 2014-10-12 18:13 UTC (permalink / raw)
To: linux-arm-kernel
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@agner.ch>
---
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 at 40000000 {
+ compatible = "fsl,aips-bus", "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x40000000 0x70000>;
+ ranges;
+
+/*
+ uart0: serial at 40027000 {
+ compatible = "fsl,vf610-lpuart";
+ reg = <0x40027000 0x1000>;
+ interrupts = <61>;
+ clocks = <&clks VF610_CLK_UART0>;
+ clock-names = "ipg";
+ status = "okay";
+ };
+
+ uart1: serial at 40028000 {
+ compatible = "fsl,vf610-lpuart";
+ reg = <0x40028000 0x1000>;
+ interrupts = <62>;
+ clocks = <&clks VF610_CLK_UART1>;
+ clock-names = "ipg";
+ status = "okay";
+ };
+*/
+ uart2: serial at 40029000 {
+ compatible = "fsl,vf610-lpuart";
+ reg = <0x40029000 0x1000>;
+ interrupts = <63>;
+ clocks = <&clks VF610_CLK_UART2>;
+ clock-names = "ipg";
+ status = "okay";
+ };
+
+ pit: pit at 40037000 {
+ compatible = "fsl,vf610-pit";
+ reg = <0x40037000 0x1000>;
+ interrupts = <39>;
+ clocks = <&clks VF610_CLK_PIT>;
+ clock-names = "pit";
+ };
+
+ iomuxc: iomuxc at 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 at 40050000 {
+ compatible = "fsl,vf610-anatop";
+ reg = <0x40050000 0x1000>;
+ };
+
+ clks: ccm at 4006b000 {
+ compatible = "fsl,vf610-ccm";
+ reg = <0x4006b000 0x1000>;
+ #clock-cells = <1>;
+ };
+ };
+
+ aips1: aips-bus at 40080000 {
+ compatible = "fsl,aips-bus", "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x40080000 0x80000>;
+ ranges;
+
+
+ esdhc1: esdhc at 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
^ permalink raw reply related [flat|nested] 29+ messages in thread* [RFC 4/7] ARM: dts: add support for Vybrid running on Cortex-M4
2014-10-12 18:13 ` [RFC 4/7] ARM: dts: add support for Vybrid running " Stefan Agner
@ 2014-10-12 18:56 ` Arnd Bergmann
2014-10-13 10:41 ` Stefan Agner
2014-10-13 10:32 ` Mark Rutland
1 sibling, 1 reply; 29+ messages in thread
From: Arnd Bergmann @ 2014-10-12 18:56 UTC (permalink / raw)
To: linux-arm-kernel
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@agner.ch>
> ---
> 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 at 40000000 {
> + compatible = "fsl,aips-bus", "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x40000000 0x70000>;
> + ranges;
> +
> +/*
> + uart0: serial at 40027000 {
> + compatible = "fsl,vf610-lpuart";
> + reg = <0x40027000 0x1000>;
> + interrupts = <61>;
> + clocks = <&clks VF610_CLK_UART0>;
> + clock-names = "ipg";
> + status = "okay";
> + };
> +
> + uart1: serial at 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
^ permalink raw reply [flat|nested] 29+ messages in thread* [RFC 4/7] ARM: dts: add support for Vybrid running on Cortex-M4
2014-10-12 18:56 ` Arnd Bergmann
@ 2014-10-13 10:41 ` Stefan Agner
0 siblings, 0 replies; 29+ messages in thread
From: Stefan Agner @ 2014-10-13 10:41 UTC (permalink / raw)
To: linux-arm-kernel
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@agner.ch>
>> ---
>> 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 at 40000000 {
>> + compatible = "fsl,aips-bus", "simple-bus";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + reg = <0x40000000 0x70000>;
>> + ranges;
>> +
>> +/*
>> + uart0: serial at 40027000 {
>> + compatible = "fsl,vf610-lpuart";
>> + reg = <0x40027000 0x1000>;
>> + interrupts = <61>;
>> + clocks = <&clks VF610_CLK_UART0>;
>> + clock-names = "ipg";
>> + status = "okay";
>> + };
>> +
>> + uart1: serial at 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* [RFC 4/7] ARM: dts: add support for Vybrid running on Cortex-M4
2014-10-12 18:13 ` [RFC 4/7] ARM: dts: add support for Vybrid running " Stefan Agner
2014-10-12 18:56 ` Arnd Bergmann
@ 2014-10-13 10:32 ` Mark Rutland
2014-10-13 11:08 ` Stefan Agner
1 sibling, 1 reply; 29+ messages in thread
From: Mark Rutland @ 2014-10-13 10:32 UTC (permalink / raw)
To: linux-arm-kernel
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@agner.ch>
> ---
> 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 at 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.
^ permalink raw reply [flat|nested] 29+ messages in thread* [RFC 4/7] ARM: dts: add support for Vybrid running on Cortex-M4
2014-10-13 10:32 ` Mark Rutland
@ 2014-10-13 11:08 ` Stefan Agner
2014-10-13 11:24 ` Arnd Bergmann
0 siblings, 1 reply; 29+ messages in thread
From: Stefan Agner @ 2014-10-13 11:08 UTC (permalink / raw)
To: linux-arm-kernel
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@agner.ch>
>> ---
>> 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 at 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
^ permalink raw reply [flat|nested] 29+ messages in thread* [RFC 4/7] ARM: dts: add support for Vybrid running on Cortex-M4
2014-10-13 11:08 ` Stefan Agner
@ 2014-10-13 11:24 ` Arnd Bergmann
2014-10-13 16:11 ` Stefan Agner
0 siblings, 1 reply; 29+ messages in thread
From: Arnd Bergmann @ 2014-10-13 11:24 UTC (permalink / raw)
To: linux-arm-kernel
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@agner.ch>
> >> ---
> >> 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 at 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
^ permalink raw reply [flat|nested] 29+ messages in thread* [RFC 4/7] ARM: dts: add support for Vybrid running on Cortex-M4
2014-10-13 11:24 ` Arnd Bergmann
@ 2014-10-13 16:11 ` Stefan Agner
2014-10-13 19:54 ` Arnd Bergmann
0 siblings, 1 reply; 29+ messages in thread
From: Stefan Agner @ 2014-10-13 16:11 UTC (permalink / raw)
To: linux-arm-kernel
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@agner.ch>
>> >> ---
>> >> 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 at 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
^ permalink raw reply [flat|nested] 29+ messages in thread* [RFC 4/7] ARM: dts: add support for Vybrid running on Cortex-M4
2014-10-13 16:11 ` Stefan Agner
@ 2014-10-13 19:54 ` Arnd Bergmann
2014-10-13 21:20 ` Stefan Agner
0 siblings, 1 reply; 29+ messages in thread
From: Arnd Bergmann @ 2014-10-13 19:54 UTC (permalink / raw)
To: linux-arm-kernel
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@agner.ch>
> >> >> ---
> >> >> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* [RFC 4/7] ARM: dts: add support for Vybrid running on Cortex-M4
2014-10-13 19:54 ` Arnd Bergmann
@ 2014-10-13 21:20 ` Stefan Agner
2014-10-14 10:01 ` Arnd Bergmann
0 siblings, 1 reply; 29+ messages in thread
From: Stefan Agner @ 2014-10-13 21:20 UTC (permalink / raw)
To: linux-arm-kernel
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@agner.ch>
>> >> >> ---
>> >> >> 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 at 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
^ permalink raw reply [flat|nested] 29+ messages in thread* [RFC 4/7] ARM: dts: add support for Vybrid running on Cortex-M4
2014-10-13 21:20 ` Stefan Agner
@ 2014-10-14 10:01 ` Arnd Bergmann
0 siblings, 0 replies; 29+ messages in thread
From: Arnd Bergmann @ 2014-10-14 10:01 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* [RFC 5/7] irqchip: nvic: increase number of external interrupts to 112
2014-10-12 18:13 [RFC 0/7] ARM: vf610m4: Add Vybrid Cortex-M4 support Stefan Agner
` (3 preceding siblings ...)
2014-10-12 18:13 ` [RFC 4/7] ARM: dts: add support for Vybrid running " Stefan Agner
@ 2014-10-12 18:13 ` Stefan Agner
2014-10-12 18:14 ` [RFC 6/7] ARM: vf610m4: HACK: get dtb pointer from SRC_GPR3 Stefan Agner
` (2 subsequent siblings)
7 siblings, 0 replies; 29+ messages in thread
From: Stefan Agner @ 2014-10-12 18:13 UTC (permalink / raw)
To: linux-arm-kernel
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@agner.ch>
---
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
^ permalink raw reply related [flat|nested] 29+ messages in thread* [RFC 6/7] ARM: vf610m4: HACK: get dtb pointer from SRC_GPR3
2014-10-12 18:13 [RFC 0/7] ARM: vf610m4: Add Vybrid Cortex-M4 support Stefan Agner
` (4 preceding siblings ...)
2014-10-12 18:13 ` [RFC 5/7] irqchip: nvic: increase number of external interrupts to 112 Stefan Agner
@ 2014-10-12 18:14 ` Stefan Agner
2014-10-12 19:00 ` Arnd Bergmann
2014-10-12 18:14 ` [RFC 7/7] ARM: vf610m4: add defconfig for Linux on Vybrids Cortex-M4 Stefan Agner
2014-11-28 14:17 ` [RFC 0/7] ARM: vf610m4: Add Vybrid Cortex-M4 support Andreas Färber
7 siblings, 1 reply; 29+ messages in thread
From: Stefan Agner @ 2014-10-12 18:14 UTC (permalink / raw)
To: linux-arm-kernel
Get DTB pointer (located in r2) from SRC_GPR3 (argument register
for secondary core)
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
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
^ permalink raw reply related [flat|nested] 29+ messages in thread* [RFC 6/7] ARM: vf610m4: HACK: get dtb pointer from SRC_GPR3
2014-10-12 18:14 ` [RFC 6/7] ARM: vf610m4: HACK: get dtb pointer from SRC_GPR3 Stefan Agner
@ 2014-10-12 19:00 ` Arnd Bergmann
2014-10-13 10:10 ` Stefan Agner
0 siblings, 1 reply; 29+ messages in thread
From: Arnd Bergmann @ 2014-10-12 19:00 UTC (permalink / raw)
To: linux-arm-kernel
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@agner.ch>
> ---
> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* [RFC 6/7] ARM: vf610m4: HACK: get dtb pointer from SRC_GPR3
2014-10-12 19:00 ` Arnd Bergmann
@ 2014-10-13 10:10 ` Stefan Agner
0 siblings, 0 replies; 29+ messages in thread
From: Stefan Agner @ 2014-10-13 10:10 UTC (permalink / raw)
To: linux-arm-kernel
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@agner.ch>
>> ---
>> 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
^ permalink raw reply [flat|nested] 29+ messages in thread
* [RFC 7/7] ARM: vf610m4: add defconfig for Linux on Vybrids Cortex-M4
2014-10-12 18:13 [RFC 0/7] ARM: vf610m4: Add Vybrid Cortex-M4 support Stefan Agner
` (5 preceding siblings ...)
2014-10-12 18:14 ` [RFC 6/7] ARM: vf610m4: HACK: get dtb pointer from SRC_GPR3 Stefan Agner
@ 2014-10-12 18:14 ` Stefan Agner
2014-11-28 14:17 ` [RFC 0/7] ARM: vf610m4: Add Vybrid Cortex-M4 support Andreas Färber
7 siblings, 0 replies; 29+ messages in thread
From: Stefan Agner @ 2014-10-12 18:14 UTC (permalink / raw)
To: linux-arm-kernel
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@agner.ch>
---
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
^ permalink raw reply related [flat|nested] 29+ messages in thread* [RFC 0/7] ARM: vf610m4: Add Vybrid Cortex-M4 support
2014-10-12 18:13 [RFC 0/7] ARM: vf610m4: Add Vybrid Cortex-M4 support Stefan Agner
` (6 preceding siblings ...)
2014-10-12 18:14 ` [RFC 7/7] ARM: vf610m4: add defconfig for Linux on Vybrids Cortex-M4 Stefan Agner
@ 2014-11-28 14:17 ` Andreas Färber
2014-11-28 16:00 ` Stefan Agner
7 siblings, 1 reply; 29+ messages in thread
From: Andreas Färber @ 2014-11-28 14:17 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 29+ messages in thread* [RFC 0/7] ARM: vf610m4: Add Vybrid Cortex-M4 support
2014-11-28 14:17 ` [RFC 0/7] ARM: vf610m4: Add Vybrid Cortex-M4 support Andreas Färber
@ 2014-11-28 16:00 ` Stefan Agner
0 siblings, 0 replies; 29+ messages in thread
From: Stefan Agner @ 2014-11-28 16:00 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 29+ messages in thread