arm and patch phys offset

arm and patch phys offset

[Nicolas Pitre]

On Sun, 11 Dec 2011, Michael Walle wrote:

> 
> [i don't know it this belongs to the arm kernel mailinglist]

It probably does, added.  When in doubt, it never hurt to CC the list.

> Hi Nico,
> 
> i'm facing some weird problem with the PATCH_PHYS_OFFSET config option 
> enabled.
> 
> I have a marvell kirkwood based LS-CHLv2 board and running the latest HEAD of 
> linus tree (with my dts patched for the kirkwood port, but hopefully this 
> should be unrelated to this problem).

Did you try without those patches to be sure?

> There seems to be p2v and v2p calls which aren't patched. Unfortunately i 
> don't have jtag access to the board. So, I use the following function to dump 
> non-patched entries of the pvtable (called from setup_arch()):
> 
> extern unsigned long __pv_table_begin, __pv_table_end;
> static void __init dump_pvtable(void)
> {
> 	unsigned char *b;
> 	unsigned long *cur = &__pv_table_begin;
> 	int i = 0;
> 	early_print("__pvtable %08lx..%08lx\n",
> 		&__pv_table_begin, &__pv_table_end);
> 	while (*cur) {

This is wrong.  You should have this instead:

	while (cur < &__pv_table_end) {

> 		b = (unsigned char *)(*cur);
> 		if (*b == 0x81) {
> 			early_print(" %d %08lx\n", i, *cur);
> 			/* uncommenting the following make the kernel work */
> 			/* *b = 0x40; */

Conceptually, this would be lacking a data vs insn cache 
resynchronization.

> 		    //early_print("   %08lx\n", *((unsigned long*)*cur));
> 		}
> 		cur++;
> 		i++;
> 	}
> 	early_print("total of %d entries\n", i);
> }
> 
> Now i get the following output:
> 
> Uncompressing Linux... done, booting the kernel.
> __pvtable c03f3e6c..c03f43c8
>  7 c03d8508                 
>  27 c03d9208
>  29 c03d9360
>  42 c03d9bfc
>  59 c03dd174
>  73 c03df094
>  77 c03df1b8
>  83 c03dfc54
>  85 c03dfe6c
>  127 c03e07d8
>  129 c03e11ac
> total of 343 entries
> 
> The weird thing is that this output changes if i insert or move some debug 
> prints. I even accomplished to make the board boot completely sometimes.

You must have some memory corrupting bug somewhere.  Please try calling 
this code first thing in start_kernel() for comparison.


Nicolas

arm and patch phys offset

[Michael Walle]

Am Montag 12 Dezember 2011, 01:53:42 schrieb Nicolas Pitre:
> On Sun, 11 Dec 2011, Michael Walle wrote:
> > I have a marvell kirkwood based LS-CHLv2 board and running the latest
> > HEAD of linus tree (with my dts patched for the kirkwood port, but
> > hopefully this should be unrelated to this problem).
> 
> Did you try without those patches to be sure?
clean linux tree with old fashioned setup code now (the one i sent long time 
ago to this mailinglist ;).

> > The weird thing is that this output changes if i insert or move some
> > debug prints. I even accomplished to make the board boot completely
> > sometimes.
> 
> You must have some memory corrupting bug somewhere.  Please try calling
> this code first thing in start_kernel() for comparison.

calling the dump function right at the beginning of start_kernel() won't 
change anything, expect the addresses.

If it would be some memory corruption, shouldn't the table or the p2v/v2p 
stubs be corrupt? But the non-patched entries always points to correct v2p/p2v 
calls and in every case there is the unpatched add/sub instruction. 

-- 
Michael

arm and patch phys offset

[Russell King - ARM Linux]

On Mon, Dec 12, 2011 at 10:12:35PM +0100, Michael Walle wrote:
> Am Montag 12 Dezember 2011, 01:53:42 schrieb Nicolas Pitre:
> > On Sun, 11 Dec 2011, Michael Walle wrote:
> > > I have a marvell kirkwood based LS-CHLv2 board and running the latest
> > > HEAD of linus tree (with my dts patched for the kirkwood port, but
> > > hopefully this should be unrelated to this problem).
> > 
> > Did you try without those patches to be sure?
> clean linux tree with old fashioned setup code now (the one i sent long time 
> ago to this mailinglist ;).
> 
> > > The weird thing is that this output changes if i insert or move some
> > > debug prints. I even accomplished to make the board boot completely
> > > sometimes.
> > 
> > You must have some memory corrupting bug somewhere.  Please try calling
> > this code first thing in start_kernel() for comparison.
> 
> calling the dump function right at the beginning of start_kernel() won't 
> change anything, expect the addresses.

Why do you say that, and what you do mean by "expect the addresses" ?
Presumably you're saying the addresses will be different.  Why do you
think that?

Are you saying that you find that the address of these 'unconverted'
instructions change each time you run your debug function?

> If it would be some memory corruption, shouldn't the table or the p2v/v2p 
> stubs be corrupt? But the non-patched entries always points to correct v2p/p2v 
> calls and in every case there is the unpatched add/sub instruction. 

Have you tried dumping out the entire instruction as well as the
address of the unconverted instruction?

Are you running a Thumb-2 kernel?  Which kernel are you running?

arm and patch phys offset

[Nicolas Pitre]

On Mon, 12 Dec 2011, Michael Walle wrote:

> Am Montag 12 Dezember 2011, 01:53:42 schrieb Nicolas Pitre:
> > On Sun, 11 Dec 2011, Michael Walle wrote:
> > > I have a marvell kirkwood based LS-CHLv2 board and running the latest
> > > HEAD of linus tree (with my dts patched for the kirkwood port, but
> > > hopefully this should be unrelated to this problem).
> > 
> > Did you try without those patches to be sure?
> clean linux tree with old fashioned setup code now (the one i sent long time 
> ago to this mailinglist ;).
> 
> > > The weird thing is that this output changes if i insert or move some
> > > debug prints. I even accomplished to make the board boot completely
> > > sometimes.
> > 
> > You must have some memory corrupting bug somewhere.  Please try calling
> > this code first thing in start_kernel() for comparison.
> 
> calling the dump function right at the beginning of start_kernel() won't 
> change anything, expect the addresses.
> 
> If it would be some memory corruption, shouldn't the table or the p2v/v2p 
> stubs be corrupt?

Not necessarily.  But when memory corruption occurs, anything may 
happen.

> But the non-patched entries always points to correct v2p/p2v 
> calls and in every case there is the unpatched add/sub instruction. 

Then, might it be possible that the cache is not properly turned off 
prior entering the kernel?

What bootloader do you use?

You could try instrumenting the patching code, although it is a bit 
tricky because of the non-standard register life rules in that file.  
But something like this should tell you if the expected amount of fixups 
were applied:

diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 08c82fd844..7f43d1fe01 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -530,14 +530,23 @@ __fixup_a_pv_table:
 	bcc	1b
 	bx	lr
 #else
+	mov	r0, #0
 	b	2f
 1:	ldr	ip, [r7, r3]
 	bic	ip, ip, #0x000000ff
 	orr	ip, ip, r6	@ mask in offset bits 31-24
 	str	ip, [r7, r3]
+	add	r0, r0, #1
 2:	cmp	r4, r5
 	ldrcc	r7, [r4], #4	@ use branch for delay slot
 	bcc	1b
+
+	mov	r6, r2
+	mov	r7, r3
+	bl	printhex8	@ display number of fixups done in r0
+	mov	r2, r6
+	mov	r3, r7
+
 	mov	pc, lr
 #endif
 ENDPROC(__fixup_a_pv_table)


Nicolas

arm and patch phys offset

[Michael Walle]

Am Montag 12 Dezember 2011, 22:34:50 schrieb Russell King - ARM Linux:
> Why do you say that, and what you do mean by "expect the addresses" ?
> Presumably you're saying the addresses will be different.  Why do you
> think that?
> Are you saying that you find that the address of these 'unconverted'
> instructions change each time you run your debug function?
i see different output from the debug function everytime i change the source 
code and recompile the kernel. restarting the same binary results in the same 
unconverted instructions.

> > If it would be some memory corruption, shouldn't the table or the p2v/v2p
> > stubs be corrupt? But the non-patched entries always points to correct
> > v2p/p2v calls and in every case there is the unpatched add/sub
> > instruction.
> 
> Have you tried dumping out the entire instruction as well as the
> address of the unconverted instruction?
yes, the addresses make sense as i can see the unpatched instruction at that 
address in the disassembly and the instruction at these addresses are always:

add/sub rX, rY, #81000000

> Are you running a Thumb-2 kernel?  Which kernel are you running?
what do you mean by which kernel?
linus' master from yesterday, ARCH_KIRKWOOD=y
CONFIG_THUMB2_KERNEL is not set


-- 
Michael

arm and patch phys offset

[Russell King - ARM Linux]

On Mon, Dec 12, 2011 at 04:38:07PM -0500, Nicolas Pitre wrote:
> You could try instrumenting the patching code, although it is a bit 
> tricky because of the non-standard register life rules in that file.  
> But something like this should tell you if the expected amount of fixups 
> were applied:
> 
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index 08c82fd844..7f43d1fe01 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -530,14 +530,23 @@ __fixup_a_pv_table:
>  	bcc	1b
>  	bx	lr
>  #else
> +	mov	r0, #0
>  	b	2f
>  1:	ldr	ip, [r7, r3]
>  	bic	ip, ip, #0x000000ff
>  	orr	ip, ip, r6	@ mask in offset bits 31-24
>  	str	ip, [r7, r3]
> +	add	r0, r0, #1
>  2:	cmp	r4, r5
>  	ldrcc	r7, [r4], #4	@ use branch for delay slot
>  	bcc	1b

If you look at this code, there is _no_ way it can fixup only some entries
in the table and not others - unless the CPU starts executing something
which isn't this code.

It quite simply loads the address of each entry in the table, incrementing
the pointer by a word size.  It then _unconditionally_ loads, modifies
and stores the instruction at the location in question.

The termination condition is when r4 >= r5, which will prevent the loading
of the next pointer _and_ prevent the looping, thus terminating the fixup
altogether.

So, something else is going on.  If I had to guess, I'd suspect the kernel
is being called with caches enabled - which violates the expectations of
the kernel set down many years ago.

arm and patch phys offset

[Russell King - ARM Linux]

On Mon, Dec 12, 2011 at 10:55:40PM +0100, Michael Walle wrote:
> Am Montag 12 Dezember 2011, 22:34:50 schrieb Russell King - ARM Linux:
> > Why do you say that, and what you do mean by "expect the addresses" ?
> > Presumably you're saying the addresses will be different.  Why do you
> > think that?
> > Are you saying that you find that the address of these 'unconverted'
> > instructions change each time you run your debug function?
> i see different output from the debug function everytime i change the source 
> code and recompile the kernel. restarting the same binary results in the same 
> unconverted instructions.
> 
> > > If it would be some memory corruption, shouldn't the table or the p2v/v2p
> > > stubs be corrupt? But the non-patched entries always points to correct
> > > v2p/p2v calls and in every case there is the unpatched add/sub
> > > instruction.
> > 
> > Have you tried dumping out the entire instruction as well as the
> > address of the unconverted instruction?
> yes, the addresses make sense as i can see the unpatched instruction at that 
> address in the disassembly and the instruction at these addresses are always:
> 
> add/sub rX, rY, #81000000
> 
> > Are you running a Thumb-2 kernel?  Which kernel are you running?
> what do you mean by which kernel?
> linus' master from yesterday, ARCH_KIRKWOOD=y
> CONFIG_THUMB2_KERNEL is not set

Yes, that's what I mean.

Right, so the problem you're describing is _impossible_ - there is no way
the fixup function can fix only some instructions and skip over others in
a properly functioning system.

The only options are that either the CPU is not executing the instructions
we're giving it (unlikely as - I assume - your hardware executes older
kernels fine), or for some reason your kernel is being called with caches
still enabled, violating the long-standing kernel's calling requirements.

So, some more questions to try to narrow this down:

1. What boot loader are you using?

2. What file are you taking from the kernel build in order to boot?

3. How are you transfering the kernel file to your target system?

arm and patch phys offset

[Michael Walle]

Am Montag 12 Dezember 2011, 22:38:07 schrieb Nicolas Pitre:
> > But the non-patched entries always points to correct v2p/p2v
> > calls and in every case there is the unpatched add/sub instruction.
> 
> Then, might it be possible that the cache is not properly turned off
> prior entering the kernel?
i'll have a look at that

> What bootloader do you use?
U-Boot 2011.09 + patches for bsp support

> You could try instrumenting the patching code, although it is a bit
> tricky because of the non-standard register life rules in that file.
> But something like this should tell you if the expected amount of fixups
> were applied:
> 
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index 08c82fd844..7f43d1fe01 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -530,14 +530,23 @@ __fixup_a_pv_table:
>  	bcc	1b
>  	bx	lr
>  #else
> +	mov	r0, #0
>  	b	2f
>  1:	ldr	ip, [r7, r3]
>  	bic	ip, ip, #0x000000ff
>  	orr	ip, ip, r6	@ mask in offset bits 31-24
>  	str	ip, [r7, r3]
> +	add	r0, r0, #1
>  2:	cmp	r4, r5
>  	ldrcc	r7, [r4], #4	@ use branch for delay slot
>  	bcc	1b
> +
> +	mov	r6, r2
> +	mov	r7, r3
> +	bl	printhex8	@ display number of fixups done in r0
> +	mov	r2, r6
> +	mov	r3, r7
> +
>  	mov	pc, lr
>  #endif
>  ENDPROC(__fixup_a_pv_table)

Thanks, although the kernel hangs now after it printed the number, i can see 
it patched the correct number of stubs.

I'll have a look at the bootloader now.

-- 
Michael

arm and patch phys offset

[Michael Walle]

Am Montag 12 Dezember 2011, 23:02:47 schrieb Russell King - ARM Linux:
> > > Are you running a Thumb-2 kernel?  Which kernel are you running?
> > 
> > what do you mean by which kernel?
> > linus' master from yesterday, ARCH_KIRKWOOD=y
> > CONFIG_THUMB2_KERNEL is not set
> 
> Yes, that's what I mean.
> 
> Right, so the problem you're describing is _impossible_ - there is no way
> the fixup function can fix only some instructions and skip over others in
> a properly functioning system.
> 
> The only options are that either the CPU is not executing the instructions
> we're giving it (unlikely as - I assume - your hardware executes older
> kernels fine), or for some reason your kernel is being called with caches
> still enabled, violating the long-standing kernel's calling requirements.
> 
> So, some more questions to try to narrow this down:
> 
> 1. What boot loader are you using?
u-boot 2011.09 with own bsp support.

> 2. What file are you taking from the kernel build in order to boot?
generated uImage

> 3. How are you transfering the kernel file to your target system?
tftp

Thanks for helping. I'll now have a look at the bootloader ;)

-- 
Michael

arm and patch phys offset

[Russell King - ARM Linux]

On Mon, Dec 12, 2011 at 11:09:00PM +0100, Michael Walle wrote:
> Am Montag 12 Dezember 2011, 23:02:47 schrieb Russell King - ARM Linux:
> > > > Are you running a Thumb-2 kernel?  Which kernel are you running?
> > > 
> > > what do you mean by which kernel?
> > > linus' master from yesterday, ARCH_KIRKWOOD=y
> > > CONFIG_THUMB2_KERNEL is not set
> > 
> > Yes, that's what I mean.
> > 
> > Right, so the problem you're describing is _impossible_ - there is no way
> > the fixup function can fix only some instructions and skip over others in
> > a properly functioning system.
> > 
> > The only options are that either the CPU is not executing the instructions
> > we're giving it (unlikely as - I assume - your hardware executes older
> > kernels fine), or for some reason your kernel is being called with caches
> > still enabled, violating the long-standing kernel's calling requirements.
> > 
> > So, some more questions to try to narrow this down:
> > 
> > 1. What boot loader are you using?
> u-boot 2011.09 with own bsp support.
> 
> > 2. What file are you taking from the kernel build in order to boot?
> generated uImage

Okay, so this should mean that the kernel's own decompressor has run,
which should turn on/off the mmu and caches, cleaning and invalidating
them, which will take the boot loader completely out of the picture at
this stage.

I think I'll leave this in the hands of Nicolas - from what I remember,
kirkwood is a feroceon based system, and I have little working knowledge
of that ARM derivative.

arm and patch phys offset

[Nicolas Pitre]

On Mon, 12 Dec 2011, Russell King - ARM Linux wrote:

> On Mon, Dec 12, 2011 at 04:38:07PM -0500, Nicolas Pitre wrote:
> > You could try instrumenting the patching code, although it is a bit 
> > tricky because of the non-standard register life rules in that file.  
> > But something like this should tell you if the expected amount of fixups 
> > were applied:
> > 
> > diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> > index 08c82fd844..7f43d1fe01 100644
> > --- a/arch/arm/kernel/head.S
> > +++ b/arch/arm/kernel/head.S
> > @@ -530,14 +530,23 @@ __fixup_a_pv_table:
> >  	bcc	1b
> >  	bx	lr
> >  #else
> > +	mov	r0, #0
> >  	b	2f
> >  1:	ldr	ip, [r7, r3]
> >  	bic	ip, ip, #0x000000ff
> >  	orr	ip, ip, r6	@ mask in offset bits 31-24
> >  	str	ip, [r7, r3]
> > +	add	r0, r0, #1
> >  2:	cmp	r4, r5
> >  	ldrcc	r7, [r4], #4	@ use branch for delay slot
> >  	bcc	1b
> 
> If you look at this code, there is _no_ way it can fixup only some entries
> in the table and not others - unless the CPU starts executing something
> which isn't this code.

As you might imagine, I already know that.  But getting the number out 
helps people gain confidence in the code they might not trust otherwise.


Nicolas

arm and patch phys offset

[Nicolas Pitre]

On Mon, 12 Dec 2011, Russell King - ARM Linux wrote:

> On Mon, Dec 12, 2011 at 11:09:00PM +0100, Michael Walle wrote:
> > Am Montag 12 Dezember 2011, 23:02:47 schrieb Russell King - ARM Linux:
> > > > > Are you running a Thumb-2 kernel?  Which kernel are you running?
> > > > 
> > > > what do you mean by which kernel?
> > > > linus' master from yesterday, ARCH_KIRKWOOD=y
> > > > CONFIG_THUMB2_KERNEL is not set
> > > 
> > > Yes, that's what I mean.
> > > 
> > > Right, so the problem you're describing is _impossible_ - there is no way
> > > the fixup function can fix only some instructions and skip over others in
> > > a properly functioning system.
> > > 
> > > The only options are that either the CPU is not executing the instructions
> > > we're giving it (unlikely as - I assume - your hardware executes older
> > > kernels fine), or for some reason your kernel is being called with caches
> > > still enabled, violating the long-standing kernel's calling requirements.
> > > 
> > > So, some more questions to try to narrow this down:
> > > 
> > > 1. What boot loader are you using?
> > u-boot 2011.09 with own bsp support.
> > 
> > > 2. What file are you taking from the kernel build in order to boot?
> > generated uImage
> 
> Okay, so this should mean that the kernel's own decompressor has run,
> which should turn on/off the mmu and caches, cleaning and invalidating
> them, which will take the boot loader completely out of the picture at
> this stage.
> 
> I think I'll leave this in the hands of Nicolas - from what I remember,
> kirkwood is a feroceon based system, and I have little working knowledge
> of that ARM derivative.

I just compiled vanilla v3.2-rc5 using kirkwood_defconfig and 
successfully booted it on a SheevaPlug and a DB-88F6281-BP development 
board.  And I do have CONFIG_ARM_PATCH_PHYS_VIRT=y.  Both platforms are 
using u-Boot which booted the default uImage produced by the kernel 
build system.

So at this point I wouldn't think the issue is Kirkwood related as I 
can't reproduce it on two different Kirkwood targets.


Nicolas

arm and patch phys offset

[Michael Walle]

Am Montag 12 Dezember 2011, 23:56:38 schrieb Nicolas Pitre:
> I just compiled vanilla v3.2-rc5 using kirkwood_defconfig and
> successfully booted it on a SheevaPlug and a DB-88F6281-BP development
> board.  And I do have CONFIG_ARM_PATCH_PHYS_VIRT=y.  Both platforms are
> using u-Boot which booted the default uImage produced by the kernel
> build system.
> 
> So at this point I wouldn't think the issue is Kirkwood related as I
> can't reproduce it on two different Kirkwood targets.

Seems like the l2 cache is enabled after uboot starts the linux kernel. I'll 
dig deeper into that tomorrow.

For now, i appended
  l2_cache_disable();
to uboots cleanup_before_linux() and all stubs seems to be patched correctly.

void l2_cache_disable(void)
{
	struct kwcpu_registers *cpureg =
		(struct kwcpu_registers *)KW_CPU_REG_BASE;
	writel(readl(&cpureg->l2_cfg) & ~0x18, &cpureg->l2_cfg);
}

l2_cfg is 0xf1020128.

But i don't know if that is correct way of disabling the cache.

Nico, what uboot are you using for your SheeavaPlug? Vanilla uboot?

-- 
michael

arm and patch phys offset

[Nicolas Pitre]

On Tue, 13 Dec 2011, Michael Walle wrote:

> Am Montag 12 Dezember 2011, 23:56:38 schrieb Nicolas Pitre:
> > I just compiled vanilla v3.2-rc5 using kirkwood_defconfig and
> > successfully booted it on a SheevaPlug and a DB-88F6281-BP development
> > board.  And I do have CONFIG_ARM_PATCH_PHYS_VIRT=y.  Both platforms are
> > using u-Boot which booted the default uImage produced by the kernel
> > build system.
> > 
> > So at this point I wouldn't think the issue is Kirkwood related as I
> > can't reproduce it on two different Kirkwood targets.
> 
> Seems like the l2 cache is enabled after uboot starts the linux kernel. I'll 
> dig deeper into that tomorrow.
> 
> For now, i appended
>   l2_cache_disable();
> to uboots cleanup_before_linux() and all stubs seems to be patched correctly.

Strange.  Having l2 enabled shouldn't cause such trouble.

> void l2_cache_disable(void)
> {
> 	struct kwcpu_registers *cpureg =
> 		(struct kwcpu_registers *)KW_CPU_REG_BASE;
> 	writel(readl(&cpureg->l2_cfg) & ~0x18, &cpureg->l2_cfg);
> }
> 
> l2_cfg is 0xf1020128.
> 
> But i don't know if that is correct way of disabling the cache.

I don't remember the details, but I wouldn't think it is that simple.  
The Kirkwood manual would tell you.  It is publicly available.

> Nico, what uboot are you using for your SheeavaPlug? Vanilla uboot?

No, it's whatever u-Boot that shipped with it.  It says:

U-Boot 1.1.4 (Jan 20 2009 - 12:05:46) Marvell version: 3.4.11


Nicolas

arm and patch phys offset

[Michael Walle]

Am Dienstag 13 Dezember 2011, 05:01:30 schrieb Nicolas Pitre:
> > Seems like the l2 cache is enabled after uboot starts the linux kernel.
> > I'll dig deeper into that tomorrow.
> > 
> > For now, i appended
> > 
> >   l2_cache_disable();
> > 
> > to uboots cleanup_before_linux() and all stubs seems to be patched
> > correctly.
> 
> Strange.  Having l2 enabled shouldn't cause such trouble.
There is a similar commit in uboots git tree:
http://git.denx.de/?p=u-
boot.git;a=commit;h=dc7100f4080952798413fb63bb4134b22c57623a

I don't know if this is somehow connected to my problem ;)

> > But i don't know if that is correct way of disabling the cache.
> 
> I don't remember the details, but I wouldn't think it is that simple.
> The Kirkwood manual would tell you.  It is publicly available.
Unfortunately the Functional Specification doesn't mention anything about l2 
caches. It references 'Unified Layer 2 (L2) Cache for Sheeva? CPU Cores 
Addendum, Doc No. MV-S104858-U0', though, which isn't publicly availble i 
guess.

Just for completeness, i'm now using the following to disable the l2 cache.

l2_cache_disable:
	mrc p15, 1, r0, c15, c1, 0  @ marvell extra features register
	bic r0, r0, #0x00400000     @ disable L2 cache
	mcr p15, 1, r0, c15, c1, 0
	mov pc, lr

Google finds some sourcecode for "marvell extra features register". And there 
is of course arch/arm/mm/cache-feroceon-l2.c.

-- 
Michael

arm and patch phys offset

[Tixy]

On Wed, 2011-12-14 at 00:17 +0100, Michael Walle wrote:
> Am Dienstag 13 Dezember 2011, 05:01:30 schrieb Nicolas Pitre:
> > > Seems like the l2 cache is enabled after uboot starts the linux kernel.
> > > I'll dig deeper into that tomorrow.
> > > 
> > > For now, i appended
> > > 
> > >   l2_cache_disable();
> > > 
> > > to uboots cleanup_before_linux() and all stubs seems to be patched
> > > correctly.
> > 
> > Strange.  Having l2 enabled shouldn't cause such trouble.
> There is a similar commit in uboots git tree:
> http://git.denx.de/?p=u-
> boot.git;a=commit;h=dc7100f4080952798413fb63bb4134b22c57623a
> 
> I don't know if this is somehow connected to my problem ;)

Michael, did you discover anything else about the problem?

I just tried 3.2-rc6 on my eSata SheevaPlug and I don't get anything
after "Uncompressing Linux... done, booting the kernel". If I hack
CONFIG_ARM_PATCH_PHYS_VIRT to be disabled, the it boots OK. My U-Boot
reports "U-Boot 2011.03 (Apr 26 2011 - 21:50:07)"

I haven't got time to dig deeper at the moment, but thought I'd report
'me too'.

-- 
Tixy

arm and patch phys offset

[Linus Walleij]

On Tue, Dec 13, 2011 at 1:08 AM, Michael Walle <michael@walle.cc> wrote:

> Seems like the l2 cache is enabled after uboot starts the linux kernel. I'll
> dig deeper into that tomorrow.

Try to disable both L2 and L1 cach in U-Boot. That has solved
similar issues for me.

In include/configs/my_board.h

#define CONFIG_SYS_DCACHE_OFF

Yours,
Linus Walleij

arm and patch phys offset

[Michael Walle]

Hi Linus,

On Tue, January 3, 2012 08:15, Linus Walleij wrote:
> On Tue, Dec 13, 2011 at 1:08 AM, Michael Walle <michael@walle.cc> wrote:
>
>> Seems like the l2 cache is enabled after uboot starts the linux kernel.
>> I'll
>> dig deeper into that tomorrow.
>
> Try to disable both L2 and L1 cach in U-Boot. That has solved
> similar issues for me.
>
> In include/configs/my_board.h
>
> #define CONFIG_SYS_DCACHE_OFF
but also slow things down in uboot, doesnt it? I've posted a patch on the
uboot ml which disables the l2 cache upon linux start.

http://patchwork.ozlabs.org/patch/132533/

You could try that, too.

-- 
michael