ARM: vf610m4: Add Vybrid Cortex-M4 support

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

Signed-off-by Stefan Agner <[email protected]>

---
 arch/arm/include/debug/vf.S | 10 ++++++++++
 1 file changed, 10 insertions(+)

arch/arm/include/debug/vf.S +3 -0

index b889338..63c7ef7 100644
@@ -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 */

Quoted 26 lines

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

Signed-off-by Stefan Agner <[email protected]>

---
 arch/arm/include/debug/vf.S | 10 ++++++++++
 1 file changed, 10 insertions(+)

arch/arm/include/debug/vf.S +3 -0

index b889338..63c7ef7 100644
@@ -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 */

arch/arm/include/debug/vf.S line 38

Quoted 10 lines

arch/arm/include/debug/vf.S +7 -0

+
+	.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

arch/arm/kernel/debug.S +1 -1

@@ -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?

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 <[email protected]>

---
 drivers/clocksource/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

drivers/clocksource/Kconfig +0 -0

index cfd6519..26464dd 100644

Hello,

Quoted 14 lines · 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 <[email protected]>

---
 drivers/clocksource/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

drivers/clocksource/Kconfig +0 -0

index cfd6519..26464dd 100644
@@ -146,6 +146,8 @@ config FSL_FTM_TIMER
 

drivers/clocksource/Kconfig config FSL_FTM_TIMER · line 152

Quoted 6 lines

drivers/clocksource/Kconfig +2 -0

 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?

Quoted 11 lines

drivers/clocksource/Kconfig config FSL_FTM_TIMER · line 152

Quoted 10 lines

drivers/clocksource/Kconfig +2 -0

@@ -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?

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 <[email protected]>

---
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.

Quoted 11 lines

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 <[email protected]>

---
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.

Am 2014-10-12 20:51, schrieb Arnd Bergmann:

Quoted 13 lines · On Sunday 12 October 2014 20:13:57 Stefan Agner wrote:

Quoted 11 lines

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 <[email protected]>

---
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.

Quoted 8 lines

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.

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 <[email protected]>

---
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/vf610m4.dts new file +14 -0

new file mode 100644
index 0000000..61488fe
@@ -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 {

arch/arm/boot/dts/vf610m4.dts new file +18 -0

+
+	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";
+			};

Quoted 9 lines

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.

Quoted 9 lines

Move the armv7-m.dtsi include to the bottom to temporarily work work around this...

Signed-off-by Stefan Agner <[email protected]>

---
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.

Quoted 20 lines

arch/arm/boot/dts/vf610m4.dts new file +14 -0

new file mode 100644
index 0000000..61488fe
@@ -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 {

arch/arm/boot/dts/vf610m4.dts line 24

Quoted 10 lines

arch/arm/boot/dts/vf610m4.dts new file +10 -0

+		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.

Quoted 19 lines

arch/arm/boot/dts/vf610m4.dts new file +18 -0

+
+	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";
+			};

arch/arm/boot/dts/vf610m4.dts line 69

Quoted 10 lines

arch/arm/boot/dts/vf610m4.dts new file +10 -0

+
+			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.

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 <[email protected]>

---
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/vf610m4.dts new file +6 -0

+	clocks {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		sxosc {
+			compatible = "fixed-clock";

Quoted 12 lines

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...

Quoted 5 lines

Signed-off-by Stefan Agner <[email protected]>

---
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.

[...]

Quoted 6 lines

arch/arm/boot/dts/vf610m4.dts new file +6 -0

+	clocks {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		sxosc {
+			compatible = "fixed-clock";

arch/arm/boot/dts/vf610m4.dts line 41

Quoted 10 lines

arch/arm/boot/dts/vf610m4.dts new file +10 -0

+			#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.

arch/arm/boot/dts/vf610m4.dts line 48

Quoted 7 lines

arch/arm/boot/dts/vf610m4.dts new file +7 -0

+
+	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?

Am 2014-10-13 12:32, schrieb Mark Rutland:

Quoted 19 lines · Stefan Agner

Quoted 12 lines

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...

Quoted 5 lines

Signed-off-by Stefan Agner <[email protected]>

---
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?

Quoted 4 lines

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?

Quoted 8 lines

Quoted 7 lines

arch/arm/boot/dts/vf610m4.dts new file +7 -0

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

Quoted 3 lines

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.

Quoted 32 lines

Am 2014-10-13 12:32, schrieb Mark Rutland:

Quoted 19 lines · Stefan Agner

Quoted 12 lines

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...

Quoted 5 lines

Signed-off-by Stefan Agner <[email protected]>

---
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?

Quoted 4 lines

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.

Quoted 2 lines

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.

Quoted 2 lines

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.

Quoted 12 lines

Quoted 11 lines

arch/arm/boot/dts/vf610m4.dts line 48

Quoted 7 lines

arch/arm/boot/dts/vf610m4.dts new file +7 -0

+
+    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?

Quoted 2 lines

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.

Am 2014-10-13 13:24, schrieb Arnd Bergmann:

Quoted 33 lines · On Monday 13 October 2014 13:08:12 Stefan Agner wrote:

Quoted 32 lines

Am 2014-10-13 12:32, schrieb Mark Rutland:

Quoted 19 lines · Stefan Agner

Quoted 12 lines

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...

Quoted 5 lines

Signed-off-by Stefan Agner <[email protected]>

---
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?

Quoted 4 lines

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.

Quoted 7 lines

Quoted 2 lines

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.

Quoted 42 lines

Am 2014-10-13 13:24, schrieb Arnd Bergmann:

Quoted 33 lines · On Monday 13 October 2014 13:08:12 Stefan Agner wrote:

Quoted 32 lines

Am 2014-10-13 12:32, schrieb Mark Rutland:

Quoted 19 lines · Stefan Agner

Quoted 12 lines

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...

Quoted 5 lines

Signed-off-by Stefan Agner <[email protected]>

---
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?

Quoted 4 lines

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.

Quoted 7 lines

Quoted 2 lines

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.

Quoted 5 lines

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?

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

Signed-off-by Stefan Agner <[email protected]>

---
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.

Quoted 11 lines

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

Signed-off-by Stefan Agner <[email protected]>

---
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.

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?

Hi Stefan,

Am 12.10.2014 um 20:13 schrieb Stefan Agner:

Quoted 9 lines

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