[PATCH 0/5] V7/Cortex/omap34xx fixes for 2.6.33-rc1: DCC, kexec, atags

[PATCH 0/5] V7/Cortex/omap34xx fixes for 2.6.33-rc1: DCC, kexec, atags

[Tony Lindgren]

Hi all,

Here are some v7 fixes, mostly to make kexec work.

Using 2.6.33-rc1, these fixes, and kexec from kexec-tools
git repo, I can reboot my n900 in a loop reliably.

To clarify, this works booting 2.6.33-rc1 in a loop, booting
the Maemo kernel with kexec does not seem to boot very far
at all for some reason. I'll look into that next.

FYI, if anybody wants to play with it, I used something
like this for kexec:

#!/bin/sh

./kexec -l zImage --command-line="$(cat /proc/cmdline)"
sync
kexec -e

Regards,

Tony


---

Tony Lindgren (5):
      arm: Fix DCC console for v7
      arm: Fix cpu_proc_fin() for proc-v7.S and make kexec work
      arm: Flush TLB entries in setup_mm_for_reboot()
      arm: Fix init_atags_procfs() to check tag->hdr.size
      arm: Fix typo in cacheflush.h and remove unnecessary comments


 arch/arm/boot/compressed/head.S   |    8 ++++++++
 arch/arm/boot/compressed/misc.c   |   12 ++++++++++++
 arch/arm/include/asm/cacheflush.h |    2 +-
 arch/arm/include/asm/setup.h      |   12 +++++++++---
 arch/arm/kernel/atags.c           |    2 +-
 arch/arm/kernel/compat.c          |    2 +-
 arch/arm/kernel/debug.S           |   20 ++++++++++++++++++++
 arch/arm/kernel/setup.c           |    4 ++--
 arch/arm/mach-orion5x/common.c    |    2 +-
 arch/arm/mm/mmu.c                 |    3 +++
 arch/arm/mm/proc-v6.S             |    2 --
 arch/arm/mm/proc-v7.S             |   11 ++++++++---
 12 files changed, 66 insertions(+), 14 deletions(-)

-- 
Signature

[PATCH 1/5] arm: Fix DCC console for v7

[Tony Lindgren]

Without this patch arch/arm/compressed/head.S defaults to generic
DCC code that does not work for v7.

For more information on the v7 DCC, see Cortex-A8 TRM
"12.11.1 Debug communications channel".

To use it with post 2.6.33-rc1 or later, you need to have:

CONFIG_DEBUG_LL=y
ONFIG_DEBUG_ICEDCC=y
CONFIG_EARLY_PRINTK=y

Earlier kernels need commit 93fd03a8c6728b58879f8af20ffd55d9c32a778b
backported.

Tested on omap3430.

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/boot/compressed/head.S |    8 ++++++++
 arch/arm/boot/compressed/misc.c |   12 ++++++++++++
 arch/arm/kernel/debug.S         |   20 ++++++++++++++++++++
 3 files changed, 40 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index d356af7..4fddc50 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -27,6 +27,14 @@
 		.macro	writeb, ch, rb
 		mcr	p14, 0, \ch, c0, c5, 0
 		.endm
+#elif defined(CONFIG_CPU_V7)
+		.macro	loadsp, rb
+		.endm
+		.macro	writeb, ch, rb
+wait:		mrc	p14, 0, pc, c0, c1, 0
+		bcs	wait
+		mcr	p14, 0, \ch, c0, c5, 0
+		.endm
 #elif defined(CONFIG_CPU_XSCALE)
 		.macro	loadsp, rb
 		.endm
diff --git a/arch/arm/boot/compressed/misc.c b/arch/arm/boot/compressed/misc.c
index 17153b5..2d1e819 100644
--- a/arch/arm/boot/compressed/misc.c
+++ b/arch/arm/boot/compressed/misc.c
@@ -48,6 +48,18 @@ static void icedcc_putc(int ch)
 
 	asm("mcr p14, 0, %0, c0, c5, 0" : : "r" (ch));
 }
+
+#elif defined(CONFIG_CPU_V7)
+
+static void icedcc_putc(int ch)
+{
+	asm(
+	"wait:	mrc	p14, 0, pc, c0, c1, 0			\n\
+		bcs	wait					\n\
+		mcr     p14, 0, %0, c0, c5, 0			"
+	: : "r" (ch));
+}
+
 #elif defined(CONFIG_CPU_XSCALE)
 
 static void icedcc_putc(int ch)
diff --git a/arch/arm/kernel/debug.S b/arch/arm/kernel/debug.S
index b121b60..5c91add 100644
--- a/arch/arm/kernel/debug.S
+++ b/arch/arm/kernel/debug.S
@@ -49,6 +49,26 @@
 1002:
 		.endm
 
+#elif defined(CONFIG_CPU_V7)
+
+		.macro	addruart, rx
+		.endm
+
+		.macro	senduart, rd, rx
+		mcr	p14, 0, \rd, c0, c5, 0
+		.endm
+
+		.macro	busyuart, rd, rx
+busy:		mrc	p14, 0, pc, c0, c1, 0
+		bcs	busy
+		.endm
+
+		.macro	waituart, rd, rx
+wait:		mrc	p14, 0, pc, c0, c1, 0
+		bcs	wait
+
+		.endm
+
 #elif defined(CONFIG_CPU_XSCALE)
 
 		.macro	addruart, rx

[PATCH 2/5] arm: Fix cpu_proc_fin() for proc-v7.S and make kexec work

[Tony Lindgren]

The comments in arm_machine_restart() suggest that cpu_proc_fin()
will clean and disable cache and turn off interrupts. This does
not seem to be implemented for proc-v7.S, implement it the same
way as for proc-v6.S.

This also makes kexec work for v7. Note that a related TLB and
branch traget flush patch is also needed to avoid kexec
"crc error".

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mm/proc-v7.S |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 3a28521..d2a8074 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -45,7 +45,14 @@ ENTRY(cpu_v7_proc_init)
 ENDPROC(cpu_v7_proc_init)
 
 ENTRY(cpu_v7_proc_fin)
-	mov	pc, lr
+	stmfd	sp!, {lr}
+	cpsid	if				@ disable interrupts
+	bl	v7_flush_kern_cache_all
+	mrc	p15, 0, r0, c1, c0, 0		@ ctrl register
+	bic	r0, r0, #0x1000			@ ...i............
+	bic	r0, r0, #0x0006			@ .............ca.
+	mcr	p15, 0, r0, c1, c0, 0		@ disable caches
+	ldmfd	sp!, {pc}
 ENDPROC(cpu_v7_proc_fin)
 
 /*

[PATCH 3/5] arm: Flush TLB entries in setup_mm_for_reboot()

[Tony Lindgren]

We need to do that if we tinker with the MMU entries.

This fixes the occasional bug with kexec where the new
fails to uncompress with "crc error". Most likely at
least kexec on v6 and v7 need this fix.

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mm/mmu.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 8c7fbd1..a2802ea 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1068,4 +1068,7 @@ void setup_mm_for_reboot(char mode)
 		pmd[1] = __pmd(pmdval + (1 << (PGDIR_SHIFT - 1)));
 		flush_pmd_entry(pmd);
 	}
+
+	local_flush_tlb_all();
+	flush_cache_all();
 }

Re: [PATCH 3/5] arm: Flush TLB entries in setup_mm_for_reboot()

[Russell King - ARM Linux]

On Fri, Dec 18, 2009 at 07:46:19PM -0800, Tony Lindgren wrote:
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index 8c7fbd1..a2802ea 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -1068,4 +1068,7 @@ void setup_mm_for_reboot(char mode)
>  		pmd[1] = __pmd(pmdval + (1 << (PGDIR_SHIFT - 1)));
>  		flush_pmd_entry(pmd);
>  	}
> +
> +	local_flush_tlb_all();
> +	flush_cache_all();

The cache flush is unnecessary.  The caches should be off at this point.

Re: [PATCH 3/5] arm: Flush TLB entries in setup_mm_for_reboot()

[Tony Lindgren]

[-- Attachment #1: Type: text/plain, Size: 672 bytes --]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [091219 01:04]:
> On Fri, Dec 18, 2009 at 07:46:19PM -0800, Tony Lindgren wrote:
> > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> > index 8c7fbd1..a2802ea 100644
> > --- a/arch/arm/mm/mmu.c
> > +++ b/arch/arm/mm/mmu.c
> > @@ -1068,4 +1068,7 @@ void setup_mm_for_reboot(char mode)
> >  		pmd[1] = __pmd(pmdval + (1 << (PGDIR_SHIFT - 1)));
> >  		flush_pmd_entry(pmd);
> >  	}
> > +
> > +	local_flush_tlb_all();
> > +	flush_cache_all();
> 
> The cache flush is unnecessary.  The caches should be off at this point.

OK, right, cpu_proc_fin() has already disabled caches by then.

Here's the updated version.

Tony

[-- Attachment #2: kexec-fix-tlb-flush-v2.patch --]
[-- Type: text/x-diff, Size: 768 bytes --]

>From f279fdc4c7dc824902d67511bfcb5f18512c8468 Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
Date: Fri, 18 Dec 2009 17:10:51 -0800
Subject: [PATCH] arm: Flush TLB entries in setup_mm_for_reboot()

We need to do that if we tinker with the MMU entries.

This fixes the occasional bug with kexec where the new
fails to uncompress with "crc error". Most likely at
least kexec on v6 and v7 need this fix.

Signed-off-by: Tony Lindgren <tony@atomide.com>

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 8c7fbd1..a311080 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1068,4 +1068,6 @@ void setup_mm_for_reboot(char mode)
 		pmd[1] = __pmd(pmdval + (1 << (PGDIR_SHIFT - 1)));
 		flush_pmd_entry(pmd);
 	}
+
+	local_flush_tlb_all();
 }

Re: [PATCH 3/5] arm: Flush TLB entries in setup_mm_for_reboot()

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [091219 09:53]:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [091219 01:04]:
> > On Fri, Dec 18, 2009 at 07:46:19PM -0800, Tony Lindgren wrote:
> > > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> > > index 8c7fbd1..a2802ea 100644
> > > --- a/arch/arm/mm/mmu.c
> > > +++ b/arch/arm/mm/mmu.c
> > > @@ -1068,4 +1068,7 @@ void setup_mm_for_reboot(char mode)
> > >  		pmd[1] = __pmd(pmdval + (1 << (PGDIR_SHIFT - 1)));
> > >  		flush_pmd_entry(pmd);
> > >  	}
> > > +
> > > +	local_flush_tlb_all();
> > > +	flush_cache_all();
> > 
> > The cache flush is unnecessary.  The caches should be off at this point.
> 
> OK, right, cpu_proc_fin() has already disabled caches by then.
> 
> Here's the updated version.

Hmm, without the flush_cache_all() rebooting with kexec still fails
with crc error eventually.

So it seems like there's a bug somewhere. Maybe something missing from
local_flush_tlb_all()?

I don't see anything obvious in v7_flush_dcache_all that would explain
why it makes local_flush_tlb_all() behave. Like you said caches are
off at this point, and that should also disable the L2 cache.

Regards,
 
Tony



> From f279fdc4c7dc824902d67511bfcb5f18512c8468 Mon Sep 17 00:00:00 2001
> From: Tony Lindgren <tony@atomide.com>
> Date: Fri, 18 Dec 2009 17:10:51 -0800
> Subject: [PATCH] arm: Flush TLB entries in setup_mm_for_reboot()
> 
> We need to do that if we tinker with the MMU entries.
> 
> This fixes the occasional bug with kexec where the new
> fails to uncompress with "crc error". Most likely at
> least kexec on v6 and v7 need this fix.
> 
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index 8c7fbd1..a311080 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -1068,4 +1068,6 @@ void setup_mm_for_reboot(char mode)
>  		pmd[1] = __pmd(pmdval + (1 << (PGDIR_SHIFT - 1)));
>  		flush_pmd_entry(pmd);
>  	}
> +
> +	local_flush_tlb_all();
>  }

[PATCH 4/5] arm: Fix init_atags_procfs() to check tag->hdr.size

[Tony Lindgren]

The tag->hdr.size cannot be larger than XXX.
Otherwise we can getsomething similar during boot:

Unable to handle kernel paging request at virtual address 61a05020
...

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/include/asm/setup.h   |   12 +++++++++---
 arch/arm/kernel/atags.c        |    2 +-
 arch/arm/kernel/compat.c       |    2 +-
 arch/arm/kernel/setup.c        |    4 ++--
 arch/arm/mach-orion5x/common.c |    2 +-
 5 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
index 5ccce0a..3ca36bb 100644
--- a/arch/arm/include/asm/setup.h
+++ b/arch/arm/include/asm/setup.h
@@ -21,6 +21,11 @@
 /* The list ends with an ATAG_NONE node. */
 #define ATAG_NONE	0x00000000
 
+/* Some sanity checks are needed */
+#define ATAG_MAX_SZ	PAGE_SIZE
+#define atag_valid(tag)							\
+	((tag)->hdr.size && ((tag)->hdr.size <= ATAG_MAX_SZ))
+
 struct tag_header {
 	__u32 size;
 	__u32 tag;
@@ -173,9 +178,10 @@ struct tagtable {
 	int (*parse)(const struct tag *);
 };
 
-#define tag_member_present(tag,member)				\
-	((unsigned long)(&((struct tag *)0L)->member + 1)	\
-		<= (tag)->hdr.size * 4)
+#define tag_member_present(tag,member)					\
+	(atag_valid(tag) &&						\
+		(((unsigned long)(&((struct tag *)0L)->member + 1)	\
+			<= (tag)->hdr.size * 4))
 
 #define tag_next(t)	((struct tag *)((__u32 *)(t) + (t)->hdr.size))
 #define tag_size(type)	((sizeof(struct tag_header) + sizeof(struct type)) >> 2)
diff --git a/arch/arm/kernel/atags.c b/arch/arm/kernel/atags.c
index 42a1a14..14d0993 100644
--- a/arch/arm/kernel/atags.c
+++ b/arch/arm/kernel/atags.c
@@ -51,7 +51,7 @@ static int __init init_atags_procfs(void)
 		return -EINVAL;
 	}
 
-	for (; tag->hdr.size; tag = tag_next(tag))
+	for (; atag_valid(tag); tag = tag_next(tag))
 		;
 
 	/* include the terminating ATAG_NONE */
diff --git a/arch/arm/kernel/compat.c b/arch/arm/kernel/compat.c
index 0a13854..3e63ee1 100644
--- a/arch/arm/kernel/compat.c
+++ b/arch/arm/kernel/compat.c
@@ -220,7 +220,7 @@ void __init convert_to_tag_list(struct tag *tags)
 
 void __init squash_mem_tags(struct tag *tag)
 {
-	for (; tag->hdr.size; tag = tag_next(tag))
+	for (; atag_valid(tag); tag = tag_next(tag))
 		if (tag->hdr.tag == ATAG_MEM)
 			tag->hdr.tag = ATAG_NONE;
 }
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index c6c57b6..53d7181 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -556,7 +556,7 @@ request_standard_resources(struct meminfo *mi, struct machine_desc *mdesc)
  */
 static int __init parse_tag_core(const struct tag *tag)
 {
-	if (tag->hdr.size > 2) {
+	if ((atag_valid(tag) && (tag->hdr.size > 2))) {
 		if ((tag->u.core.flags & 1) == 0)
 			root_mountflags &= ~MS_RDONLY;
 		ROOT_DEV = old_decode_dev(tag->u.core.rootdev);
@@ -660,7 +660,7 @@ static int __init parse_tag(const struct tag *tag)
  */
 static void __init parse_tags(const struct tag *t)
 {
-	for (; t->hdr.size; t = tag_next(t))
+	for (; atag_valid(t); t = tag_next(t))
 		if (!parse_tag(t))
 			printk(KERN_WARNING
 				"Ignoring unrecognised tag 0x%08x\n",
diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
index f87fa12..8afee34 100644
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion5x/common.c
@@ -717,7 +717,7 @@ void __init orion5x_init(void)
 void __init tag_fixup_mem32(struct machine_desc *mdesc, struct tag *t,
 			    char **from, struct meminfo *meminfo)
 {
-	for (; t->hdr.size; t = tag_next(t))
+	for (; atag_valid(t); t = tag_next(t))
 		if (t->hdr.tag == ATAG_MEM &&
 		    (!t->u.mem.size || t->u.mem.size & ~PAGE_MASK ||
 		     t->u.mem.start & ~PAGE_MASK)) {

Re: [PATCH 4/5] arm: Fix init_atags_procfs() to check tag->hdr.size

[Russell King - ARM Linux]

On Fri, Dec 18, 2009 at 07:46:30PM -0800, Tony Lindgren wrote:
> The tag->hdr.size cannot be larger than XXX.
> Otherwise we can getsomething similar during boot:
> 
> Unable to handle kernel paging request at virtual address 61a05020
> ...

NAK.

Why can't people get the simple ATAG setup right?  Fix the boot loader.

Re: [PATCH 4/5] arm: Fix init_atags_procfs() to check tag->hdr.size

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [091219 01:02]:
> On Fri, Dec 18, 2009 at 07:46:30PM -0800, Tony Lindgren wrote:
> > The tag->hdr.size cannot be larger than XXX.
> > Otherwise we can getsomething similar during boot:
> > 
> > Unable to handle kernel paging request at virtual address 61a05020
> > ...
> 
> NAK.
> 
> Why can't people get the simple ATAG setup right?  Fix the boot loader.

In this case why can't the kernel get ATAG setup right?

This only happens when kexec rebooting multiple times in a row.

Sounds like something is not memset/kzalloc'd somewhere?

Regards,

Tony

Re: [PATCH 4/5] arm: Fix init_atags_procfs() to check tag->hdr.size

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [091219 09:43]:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [091219 01:02]:
> > On Fri, Dec 18, 2009 at 07:46:30PM -0800, Tony Lindgren wrote:
> > > The tag->hdr.size cannot be larger than XXX.
> > > Otherwise we can getsomething similar during boot:
> > > 
> > > Unable to handle kernel paging request at virtual address 61a05020
> > > ...
> > 
> > NAK.
> > 
> > Why can't people get the simple ATAG setup right?  Fix the boot loader.
> 
> In this case why can't the kernel get ATAG setup right?
> 
> This only happens when kexec rebooting multiple times in a row.
> 
> Sounds like something is not memset/kzalloc'd somewhere?

Heh. I can't reproduce this any longer. I bet it was caused by
the bug in my earlier reboot script that kept appending another
root= to the cmdline every reboot :)

Tony

[PATCH 5/5] arm: Fix typo in cacheflush.h and remove unnecessary comments

[Tony Lindgren]

While dealing with the kexec fixes, I noticed these.

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/include/asm/cacheflush.h |    2 +-
 arch/arm/mm/proc-v6.S             |    2 --
 arch/arm/mm/proc-v7.S             |    2 --
 3 files changed, 1 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h
index 730aefc..e9fb1d3 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -154,7 +154,7 @@
  *	Please note that the implementation of these, and the required
  *	effects are cache-type (VIVT/VIPT/PIPT) specific.
  *
- *	flush_cache_kern_all()
+ *	flush_cache_all()
  *
  *		Unconditionally clean and invalidate the entire cache.
  *
diff --git a/arch/arm/mm/proc-v6.S b/arch/arm/mm/proc-v6.S
index 395cc90..7a5337e 100644
--- a/arch/arm/mm/proc-v6.S
+++ b/arch/arm/mm/proc-v6.S
@@ -59,8 +59,6 @@ ENTRY(cpu_v6_proc_fin)
  *	to what would be the reset vector.
  *
  *	- loc   - location to jump to for soft reset
- *
- *	It is assumed that:
  */
 	.align	5
 ENTRY(cpu_v6_reset)
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index d2a8074..7aaf88a 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -63,8 +63,6 @@ ENDPROC(cpu_v7_proc_fin)
  *	to what would be the reset vector.
  *
  *	- loc   - location to jump to for soft reset
- *
- *	It is assumed that:
  */
 	.align	5
 ENTRY(cpu_v7_reset)

Re: [PATCH 0/5] V7/Cortex/omap34xx fixes for 2.6.33-rc1: DCC, kexec, atags

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [091218 19:44]:
> Hi all,
> 
> Here are some v7 fixes, mostly to make kexec work.
> 
> Using 2.6.33-rc1, these fixes, and kexec from kexec-tools
> git repo, I can reboot my n900 in a loop reliably.
> 
> To clarify, this works booting 2.6.33-rc1 in a loop, booting
> the Maemo kernel with kexec does not seem to boot very far
> at all for some reason. I'll look into that next.

After a quick look it seems that the Maemo kernel hangs
at dss_boottime_get_clocks(). Oh well, if anybody has
a patch for that, let me know.

Regards,

Tony

Re: [PATCH 0/5] V7/Cortex/omap34xx fixes for 2.6.33-rc1: DCC, kexec, atags

[Magnus Damm]

Hi Tony,

On Sat, Dec 19, 2009 at 12:45 PM, Tony Lindgren <tony@atomide.com> wrote:
> Here are some v7 fixes, mostly to make kexec work.
>
> Using 2.6.33-rc1, these fixes, and kexec from kexec-tools
> git repo, I can reboot my n900 in a loop reliably.

Thanks for your work on this. I previously tested kexec on ARM V6 and
V7 and noticed that V7 didn't work. I revisited my V7 test after
becoming aware of your patches. The single patch below unbreaks V7 on
my target system.

>      arm: Fix cpu_proc_fin() for proc-v7.S and make kexec work

Cheers,

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

Re: [PATCH 0/5] V7/Cortex/omap34xx fixes for 2.6.33-rc1: DCC, kexec, atags

[Tony Lindgren]

Hi,

* Magnus Damm <magnus.damm@gmail.com> [091227 21:54]:
> Hi Tony,
> 
> On Sat, Dec 19, 2009 at 12:45 PM, Tony Lindgren <tony@atomide.com> wrote:
> > Here are some v7 fixes, mostly to make kexec work.
> >
> > Using 2.6.33-rc1, these fixes, and kexec from kexec-tools
> > git repo, I can reboot my n900 in a loop reliably.
> 
> Thanks for your work on this. I previously tested kexec on ARM V6 and
> V7 and noticed that V7 didn't work. I revisited my V7 test after
> becoming aware of your patches. The single patch below unbreaks V7 on
> my target system.
> 
> >      arm: Fix cpu_proc_fin() for proc-v7.S and make kexec work

Cool. Thank you for fixing the kexec source :)

Are you seeing the occasional crc errors when uncompressing the
new kernel on your v7?

I'm seeing those maybe 1 out of 10 times on omap3430 boards unless if
I do an extra (and wrong) flush_cache_all after local_flush_tlb_all
at the end of setup_mm_for_reboot.

If you're not seeing the crc errors, do you have L2 cache on?

Also, what's the Cortex version on your v7? It's rev r2p3 on
omap3430.

Regards,

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

Re: [PATCH 0/5] V7/Cortex/omap34xx fixes for 2.6.33-rc1: DCC, kexec, atags

[Magnus Damm]

On Wed, Dec 30, 2009 at 7:07 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Magnus Damm <magnus.damm@gmail.com> [091227 21:54]:
>> >      arm: Fix cpu_proc_fin() for proc-v7.S and make kexec work
>
> Are you seeing the occasional crc errors when uncompressing the
> new kernel on your v7?

Nope, it's very stable. I boot over USB with kexec for all my ARM
kernel development and I have not seen any issues so far.

> I'm seeing those maybe 1 out of 10 times on omap3430 boards unless if
> I do an extra (and wrong) flush_cache_all after local_flush_tlb_all
> at the end of setup_mm_for_reboot.

My second kernel does not need any workaround, however...

> If you're not seeing the crc errors, do you have L2 cache on?

I'm not sure at this point, but I think L2 is disabled. Will try to turn it on.

> Also, what's the Cortex version on your v7? It's rev r2p3 on
> omap3430.

The data sheet of sh7377 says r2p3 as well.

Cheers,

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

Re: [PATCH 0/5] V7/Cortex/omap34xx fixes for 2.6.33-rc1: DCC, kexec, atags

[Mika Westerberg]

On Tue, Dec 29, 2009 at 02:07:05PM -0800, Tony Lindgren wrote:
> Hi,
> 
> * Magnus Damm <magnus.damm@gmail.com> [091227 21:54]:
> > Hi Tony,
> > 
> > On Sat, Dec 19, 2009 at 12:45 PM, Tony Lindgren <tony@atomide.com> wrote:
> > > Here are some v7 fixes, mostly to make kexec work.
> > >
> > > Using 2.6.33-rc1, these fixes, and kexec from kexec-tools
> > > git repo, I can reboot my n900 in a loop reliably.
> > 
> > Thanks for your work on this. I previously tested kexec on ARM V6 and
> > V7 and noticed that V7 didn't work. I revisited my V7 test after
> > becoming aware of your patches. The single patch below unbreaks V7 on
> > my target system.
> > 
> > >      arm: Fix cpu_proc_fin() for proc-v7.S and make kexec work
> 
> Cool. Thank you for fixing the kexec source :)
> 
> Are you seeing the occasional crc errors when uncompressing the
> new kernel on your v7?
> 
> I'm seeing those maybe 1 out of 10 times on omap3430 boards unless if
> I do an extra (and wrong) flush_cache_all after local_flush_tlb_all
> at the end of setup_mm_for_reboot.

Hi,

I've also been playing with this patch.

One thing I noticed is that If I disable L2 cache in cpu_v7_proc_fin()
then kexec works fine and no crc errors from decompressor (I did
~30 kexec boots). With L2 cache enabled, it fails almost immediately.

Tested with OMAP3430 ES3.1.

Thanks,
MW
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] V7/Cortex/omap34xx fixes for 2.6.33-rc1: DCC, kexec, atags

[Tony Lindgren]

* Mika Westerberg <mika.westerberg@iki.fi> [100105 03:34]:
> On Tue, Dec 29, 2009 at 02:07:05PM -0800, Tony Lindgren wrote:
> > Hi,
> > 
> > * Magnus Damm <magnus.damm@gmail.com> [091227 21:54]:
> > > Hi Tony,
> > > 
> > > On Sat, Dec 19, 2009 at 12:45 PM, Tony Lindgren <tony@atomide.com> wrote:
> > > > Here are some v7 fixes, mostly to make kexec work.
> > > >
> > > > Using 2.6.33-rc1, these fixes, and kexec from kexec-tools
> > > > git repo, I can reboot my n900 in a loop reliably.
> > > 
> > > Thanks for your work on this. I previously tested kexec on ARM V6 and
> > > V7 and noticed that V7 didn't work. I revisited my V7 test after
> > > becoming aware of your patches. The single patch below unbreaks V7 on
> > > my target system.
> > > 
> > > >      arm: Fix cpu_proc_fin() for proc-v7.S and make kexec work
> > 
> > Cool. Thank you for fixing the kexec source :)
> > 
> > Are you seeing the occasional crc errors when uncompressing the
> > new kernel on your v7?
> > 
> > I'm seeing those maybe 1 out of 10 times on omap3430 boards unless if
> > I do an extra (and wrong) flush_cache_all after local_flush_tlb_all
> > at the end of setup_mm_for_reboot.
> 
> Hi,
> 
> I've also been playing with this patch.
> 
> One thing I noticed is that If I disable L2 cache in cpu_v7_proc_fin()
> then kexec works fine and no crc errors from decompressor (I did
> ~30 kexec boots). With L2 cache enabled, it fails almost immediately.
> 
> Tested with OMAP3430 ES3.1.

OK cool. I thought disabling the caches should also disable L2, but
looks like not then.

Regards,

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

Re: [PATCH 0/5] V7/Cortex/omap34xx fixes for 2.6.33-rc1: DCC, kexec, atags

[Paul Walmsley]

Hi, 

On Tue, 29 Dec 2009, Tony Lindgren wrote:

> Also, what's the Cortex version on your v7? It's rev r2p3 on
> omap3430.

Just a quick note - I think it is r1p3 on OMAP34xx ES3.1 and below, and 
r1p7 on ES3.1.2.


- Paul

Re: [PATCH 0/5] V7/Cortex/omap34xx fixes for 2.6.33-rc1: DCC, kexec, atags

[Tony Lindgren]

* Paul Walmsley <paul@pwsan.com> [100105 09:52]:
> Hi, 
> 
> On Tue, 29 Dec 2009, Tony Lindgren wrote:
> 
> > Also, what's the Cortex version on your v7? It's rev r2p3 on
> > omap3430.
> 
> Just a quick note - I think it is r1p3 on OMAP34xx ES3.1 and below, and 
> r1p7 on ES3.1.2.

Oops, sorry for posting wrong info. Yeah it's r1 not r2.

Regards,

Tony

RE: [PATCH 0/5] V7/Cortex/omap34xx fixes for 2.6.33-rc1: DCC, kexec, atags

[Woodruff, Richard]

> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Paul Walmsley
> Sent: Tuesday, January 05, 2010 11:54 AM

> > Also, what's the Cortex version on your v7? It's rev r2p3 on
> > omap3430.
>
> Just a quick note - I think it is r1p3 on OMAP34xx ES3.1 and below, and
> r1p7 on ES3.1.2.

Not quite accurate for the 'below' but as they are non-production they are not so impacting.

Current production CortexA8 chips for 3430:
        es3.2   :       r1p7
        es3.1   :       r1p3
        Earlier esX.Y used r0p0, r1p1, r1p2

Production candidate chips for 3630:
        es1.x   :       r3p2

Regards,
Richard W.