kernel decompressor problem for ARMv7

kernel decompressor problem for ARMv7

[Lin Ming]

Hi all,

I'm porting BSP code from v2.6.36 to v3.10 kernel. It's ARMv7 processor.

But decompressor doesn't work. With a lot of debug, I finally find
below 2 commits related.
Kernel uncompress OK with these commits reverted.

dbece45: ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores
(Introduced in v3.6-rc6)

5010192: ARM: 7583/1: decompressor: Enable unaligned memory access for
v6 and above
(Introduced in v3.7-rc8)

Any hint to fix it?

Thanks,
Lin Ming

kernel decompressor problem for ARMv7

[Will Deacon]

On Fri, Jul 05, 2013 at 09:44:12AM +0100, Lin Ming wrote:
> Hi all,

Hello,

> I'm porting BSP code from v2.6.36 to v3.10 kernel. It's ARMv7 processor.

Which specific processor/SoC?

> But decompressor doesn't work. With a lot of debug, I finally find
> below 2 commits related.
> Kernel uncompress OK with these commits reverted.
> 
> dbece45: ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores
> (Introduced in v3.6-rc6)
> 
> 5010192: ARM: 7583/1: decompressor: Enable unaligned memory access for
> v6 and above
> (Introduced in v3.7-rc8)
> 
> Any hint to fix it?

There's not really enough information to go on here. What specifically
fails? Also, do you have to revert *both* of the above changes to get things
working again?

Cheers,

Will

kernel decompressor problem for ARMv7

[Nicolas Pitre]

On Fri, 5 Jul 2013, Will Deacon wrote:

> On Fri, Jul 05, 2013 at 09:44:12AM +0100, Lin Ming wrote:
> > Hi all,
> 
> Hello,
> 
> > I'm porting BSP code from v2.6.36 to v3.10 kernel. It's ARMv7 processor.
> 
> Which specific processor/SoC?
> 
> > But decompressor doesn't work. With a lot of debug, I finally find
> > below 2 commits related.
> > Kernel uncompress OK with these commits reverted.
> > 
> > dbece45: ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores
> > (Introduced in v3.6-rc6)
> > 
> > 5010192: ARM: 7583/1: decompressor: Enable unaligned memory access for
> > v6 and above
> > (Introduced in v3.7-rc8)
> > 
> > Any hint to fix it?
> 
> There's not really enough information to go on here. What specifically
> fails? Also, do you have to revert *both* of the above changes to get things
> working again?

Also, what is the bootloader used here?

Does the bootloader call the kernel with the MMU off as documented in 
Documentation/arm/Booting?



Nicolas

kernel decompressor problem for ARMv7

[Lin Ming]

On Fri, Jul 5, 2013 at 5:57 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Fri, Jul 05, 2013 at 09:44:12AM +0100, Lin Ming wrote:
>> Hi all,
>
> Hello,
>
>> I'm porting BSP code from v2.6.36 to v3.10 kernel. It's ARMv7 processor.
>
> Which specific processor/SoC?

Cortex-A9 CPU on Cortina-Systems Baseboard

>
>> But decompressor doesn't work. With a lot of debug, I finally find
>> below 2 commits related.
>> Kernel uncompress OK with these commits reverted.
>>
>> dbece45: ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores
>> (Introduced in v3.6-rc6)
>>
>> 5010192: ARM: 7583/1: decompressor: Enable unaligned memory access for
>> v6 and above
>> (Introduced in v3.7-rc8)
>>
>> Any hint to fix it?
>
> There's not really enough information to go on here. What specifically
> fails? Also, do you have to revert *both* of the above changes to get things
> working again?

The "fails" is that the decompressor code never get called.
U-Boot prints "Starting kernel", then the board just hang there.

Yes, need to revert *both*.

>
> Cheers,
>
> Will

kernel decompressor problem for ARMv7

[Lin Ming]

On Sat, Jul 6, 2013 at 12:30 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Fri, 5 Jul 2013, Will Deacon wrote:
>
>> On Fri, Jul 05, 2013 at 09:44:12AM +0100, Lin Ming wrote:
>> > Hi all,
>>
>> Hello,
>>
>> > I'm porting BSP code from v2.6.36 to v3.10 kernel. It's ARMv7 processor.
>>
>> Which specific processor/SoC?
>>
>> > But decompressor doesn't work. With a lot of debug, I finally find
>> > below 2 commits related.
>> > Kernel uncompress OK with these commits reverted.
>> >
>> > dbece45: ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores
>> > (Introduced in v3.6-rc6)
>> >
>> > 5010192: ARM: 7583/1: decompressor: Enable unaligned memory access for
>> > v6 and above
>> > (Introduced in v3.7-rc8)
>> >
>> > Any hint to fix it?
>>
>> There's not really enough information to go on here. What specifically
>> fails? Also, do you have to revert *both* of the above changes to get things
>> working again?
>
> Also, what is the bootloader used here?

uboot.

>
> Does the bootloader call the kernel with the MMU off as documented in
> Documentation/arm/Booting?

How to check this?

I'll check uboot code or add debug code in boot/compressed/head.S to
check it next Monday.

>
> Nicolas

kernel decompressor problem for ARMv7

[Lin Ming]

On Sat, 2013-07-06 at 00:58 +0800, Lin Ming wrote:
> On Sat, Jul 6, 2013 at 12:30 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > On Fri, 5 Jul 2013, Will Deacon wrote:
> >
> >> On Fri, Jul 05, 2013 at 09:44:12AM +0100, Lin Ming wrote:
> >> > Hi all,
> >>
> >> Hello,
> >>
> >> > I'm porting BSP code from v2.6.36 to v3.10 kernel. It's ARMv7 processor.
> >>
> >> Which specific processor/SoC?
> >>
> >> > But decompressor doesn't work. With a lot of debug, I finally find
> >> > below 2 commits related.
> >> > Kernel uncompress OK with these commits reverted.
> >> >
> >> > dbece45: ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores
> >> > (Introduced in v3.6-rc6)
> >> >
> >> > 5010192: ARM: 7583/1: decompressor: Enable unaligned memory access for
> >> > v6 and above
> >> > (Introduced in v3.7-rc8)
> >> >
> >> > Any hint to fix it?
> >>
> >> There's not really enough information to go on here. What specifically
> >> fails? Also, do you have to revert *both* of the above changes to get things
> >> working again?
> >
> > Also, what is the bootloader used here?
> 
> uboot.
> 
> >
> > Does the bootloader call the kernel with the MMU off as documented in
> > Documentation/arm/Booting?
> 
> How to check this?
> 
> I'll check uboot code or add debug code in boot/compressed/head.S to
> check it next Monday.

I added below debug code to print the control reg from lowest 4bits to
highest 4bits.

It prints "B7805C". So the control reg is 0x00c5087b.
Seems bootloader calls the kernel with MMU enabled and Alignment fault
checking enabled.

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 32337ff..9434720 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -125,6 +125,23 @@
 		.rept	7
 		mov	r0, r0
 		.endr
+
+		/* Dirty debug code to print control reg from lowest 4bits to highest 4bits */
+		ldr     r2, =0xf0070120		@ UART
+		mrc     p15, 0, r0, c1, c0, 0   @ read control reg
+	1:
+		cmp     r0, #0
+		beq	2f
+		and     r1, r0, #15
+		cmp	r1, #9
+		addgt	r1, r1, #7
+		add	r1, r1, #48
+		str     r1, [r2]
+		asr     r0, r0, #4
+		b	1b
+	2:
+
+
    ARM(		mov	r0, r0		)
    ARM(		b	1f		)
  THUMB(		adr	r12, BSYM(1f)	)


> 
> >
> > Nicolas

kernel decompressor problem for ARMv7

[Lin Ming]

On Mon, Jul 8, 2013 at 10:27 AM, Lin Ming <minggr@gmail.com> wrote:
> On Sat, 2013-07-06 at 00:58 +0800, Lin Ming wrote:
>> On Sat, Jul 6, 2013 at 12:30 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> > On Fri, 5 Jul 2013, Will Deacon wrote:
>> >
>> >> On Fri, Jul 05, 2013 at 09:44:12AM +0100, Lin Ming wrote:
>> >> > Hi all,
>> >>
>> >> Hello,
>> >>
>> >> > I'm porting BSP code from v2.6.36 to v3.10 kernel. It's ARMv7 processor.
>> >>
>> >> Which specific processor/SoC?
>> >>
>> >> > But decompressor doesn't work. With a lot of debug, I finally find
>> >> > below 2 commits related.
>> >> > Kernel uncompress OK with these commits reverted.
>> >> >
>> >> > dbece45: ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores
>> >> > (Introduced in v3.6-rc6)
>> >> >
>> >> > 5010192: ARM: 7583/1: decompressor: Enable unaligned memory access for
>> >> > v6 and above
>> >> > (Introduced in v3.7-rc8)
>> >> >
>> >> > Any hint to fix it?
>> >>
>> >> There's not really enough information to go on here. What specifically
>> >> fails? Also, do you have to revert *both* of the above changes to get things
>> >> working again?
>> >
>> > Also, what is the bootloader used here?
>>
>> uboot.
>>
>> >
>> > Does the bootloader call the kernel with the MMU off as documented in
>> > Documentation/arm/Booting?
>>
>> How to check this?
>>
>> I'll check uboot code or add debug code in boot/compressed/head.S to
>> check it next Monday.
>
> I added below debug code to print the control reg from lowest 4bits to
> highest 4bits.
>
> It prints "B7805C". So the control reg is 0x00c5087b.
> Seems bootloader calls the kernel with MMU enabled and Alignment fault
> checking enabled.

Hi Nicolas,

Is this information useful?
Or any other information needed for further debug?

Thanks,
Lin Ming

>
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index 32337ff..9434720 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -125,6 +125,23 @@
>                 .rept   7
>                 mov     r0, r0
>                 .endr
> +
> +               /* Dirty debug code to print control reg from lowest 4bits to highest 4bits */
> +               ldr     r2, =0xf0070120         @ UART
> +               mrc     p15, 0, r0, c1, c0, 0   @ read control reg
> +       1:
> +               cmp     r0, #0
> +               beq     2f
> +               and     r1, r0, #15
> +               cmp     r1, #9
> +               addgt   r1, r1, #7
> +               add     r1, r1, #48
> +               str     r1, [r2]
> +               asr     r0, r0, #4
> +               b       1b
> +       2:
> +
> +
>     ARM(                mov     r0, r0          )
>     ARM(                b       1f              )
>   THUMB(                adr     r12, BSYM(1f)   )
>
>
>>
>> >
>> > Nicolas
>
>

kernel decompressor problem for ARMv7

[Nicolas Pitre]

On Tue, 9 Jul 2013, Lin Ming wrote:

> On Mon, Jul 8, 2013 at 10:27 AM, Lin Ming <minggr@gmail.com> wrote:
> > On Sat, 2013-07-06 at 00:58 +0800, Lin Ming wrote:
> >> On Sat, Jul 6, 2013 at 12:30 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> >> > On Fri, 5 Jul 2013, Will Deacon wrote:
> >> >
> >> >> On Fri, Jul 05, 2013 at 09:44:12AM +0100, Lin Ming wrote:
> >> >> > Hi all,
> >> >>
> >> >> Hello,
> >> >>
> >> >> > I'm porting BSP code from v2.6.36 to v3.10 kernel. It's ARMv7 processor.
> >> >>
> >> >> Which specific processor/SoC?
> >> >>
> >> >> > But decompressor doesn't work. With a lot of debug, I finally find
> >> >> > below 2 commits related.
> >> >> > Kernel uncompress OK with these commits reverted.
> >> >> >
> >> >> > dbece45: ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores
> >> >> > (Introduced in v3.6-rc6)
> >> >> >
> >> >> > 5010192: ARM: 7583/1: decompressor: Enable unaligned memory access for
> >> >> > v6 and above
> >> >> > (Introduced in v3.7-rc8)
> >> >> >
> >> >> > Any hint to fix it?
> >> >>
> >> >> There's not really enough information to go on here. What specifically
> >> >> fails? Also, do you have to revert *both* of the above changes to get things
> >> >> working again?
> >> >
> >> > Also, what is the bootloader used here?
> >>
> >> uboot.
> >>
> >> >
> >> > Does the bootloader call the kernel with the MMU off as documented in
> >> > Documentation/arm/Booting?
> >>
> >> How to check this?
> >>
> >> I'll check uboot code or add debug code in boot/compressed/head.S to
> >> check it next Monday.
> >
> > I added below debug code to print the control reg from lowest 4bits to
> > highest 4bits.
> >
> > It prints "B7805C". So the control reg is 0x00c5087b.
> > Seems bootloader calls the kernel with MMU enabled and Alignment fault
> > checking enabled.
> 
> Hi Nicolas,
> 
> Is this information useful?
> Or any other information needed for further debug?

No more info needed.  The kernel has to be booted with the MMU disabled 
as per the booting protocol documentation. You therefore have to fix 
your 
bootloader.


Nicolas

kernel decompressor problem for ARMv7

[Lin Ming]

On Tue, Jul 9, 2013 at 3:39 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Tue, 9 Jul 2013, Lin Ming wrote:
>
>> On Mon, Jul 8, 2013 at 10:27 AM, Lin Ming <minggr@gmail.com> wrote:
>> > On Sat, 2013-07-06 at 00:58 +0800, Lin Ming wrote:
>> >> On Sat, Jul 6, 2013 at 12:30 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> >> > On Fri, 5 Jul 2013, Will Deacon wrote:
>> >> >
>> >> >> On Fri, Jul 05, 2013 at 09:44:12AM +0100, Lin Ming wrote:
>> >> >> > Hi all,
>> >> >>
>> >> >> Hello,
>> >> >>
>> >> >> > I'm porting BSP code from v2.6.36 to v3.10 kernel. It's ARMv7 processor.
>> >> >>
>> >> >> Which specific processor/SoC?
>> >> >>
>> >> >> > But decompressor doesn't work. With a lot of debug, I finally find
>> >> >> > below 2 commits related.
>> >> >> > Kernel uncompress OK with these commits reverted.
>> >> >> >
>> >> >> > dbece45: ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores
>> >> >> > (Introduced in v3.6-rc6)
>> >> >> >
>> >> >> > 5010192: ARM: 7583/1: decompressor: Enable unaligned memory access for
>> >> >> > v6 and above
>> >> >> > (Introduced in v3.7-rc8)
>> >> >> >
>> >> >> > Any hint to fix it?
>> >> >>
>> >> >> There's not really enough information to go on here. What specifically
>> >> >> fails? Also, do you have to revert *both* of the above changes to get things
>> >> >> working again?
>> >> >
>> >> > Also, what is the bootloader used here?
>> >>
>> >> uboot.
>> >>
>> >> >
>> >> > Does the bootloader call the kernel with the MMU off as documented in
>> >> > Documentation/arm/Booting?
>> >>
>> >> How to check this?
>> >>
>> >> I'll check uboot code or add debug code in boot/compressed/head.S to
>> >> check it next Monday.
>> >
>> > I added below debug code to print the control reg from lowest 4bits to
>> > highest 4bits.
>> >
>> > It prints "B7805C". So the control reg is 0x00c5087b.
>> > Seems bootloader calls the kernel with MMU enabled and Alignment fault
>> > checking enabled.
>>
>> Hi Nicolas,
>>
>> Is this information useful?
>> Or any other information needed for further debug?
>
> No more info needed.  The kernel has to be booted with the MMU disabled
> as per the booting protocol documentation. You therefore have to fix
> your
> bootloader.

OK.

But I have to also revert below commit to make decompressor work.

commit 5010192:
ARM: 7583/1: decompressor: Enable unaligned memory access for v6 and above

It seems like caused by bootloader has Alignment fault checking enabled.
Any suggestion how to fix it?

Thanks.

>
>
> Nicolas

kernel decompressor problem for ARMv7

[Will Deacon]

On Tue, Jul 09, 2013 at 08:53:05AM +0100, Lin Ming wrote:
> On Tue, Jul 9, 2013 at 3:39 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > No more info needed.  The kernel has to be booted with the MMU disabled
> > as per the booting protocol documentation. You therefore have to fix
> > your
> > bootloader.
> 
> OK.
> 
> But I have to also revert below commit to make decompressor work.
> 
> commit 5010192:
> ARM: 7583/1: decompressor: Enable unaligned memory access for v6 and above
> 
> It seems like caused by bootloader has Alignment fault checking enabled.
> Any suggestion how to fix it?

Well step 1 is to disable the MMU. Once you've done that, you really don't
want to be issuing unaligned accesses (since memory will be treated as
strongly-ordered), so the value of the alignment trap bit is irrelevant.

Will

kernel decompressor problem for ARMv7

[Lin Ming]

On Tue, Jul 9, 2013 at 4:05 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, Jul 09, 2013 at 08:53:05AM +0100, Lin Ming wrote:
>> On Tue, Jul 9, 2013 at 3:39 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> > No more info needed.  The kernel has to be booted with the MMU disabled
>> > as per the booting protocol documentation. You therefore have to fix
>> > your
>> > bootloader.
>>
>> OK.
>>
>> But I have to also revert below commit to make decompressor work.
>>
>> commit 5010192:
>> ARM: 7583/1: decompressor: Enable unaligned memory access for v6 and above
>>
>> It seems like caused by bootloader has Alignment fault checking enabled.
>> Any suggestion how to fix it?
>
> Well step 1 is to disable the MMU. Once you've done that, you really don't
> want to be issuing unaligned accesses (since memory will be treated as
> strongly-ordered), so the value of the alignment trap bit is irrelevant.

Thanks. Will try it.

>
> Will