v3.10 - big endian core support

v3.10 - big endian core support

[Thomas Petazzoni]

Dear Vijay Kilari,

On Fri, 12 Jul 2013 17:09:12 +0530, Vijay Kilari wrote:

> > Ben Dooks has a separate branch on top of this base branch for
> > big-endian support, that adds atags compat code to convert the ATAGs
> > data from LE to BE. See the baserock/311/be/atags branch in
> > git://git.baserock.org/delta/linux. Or
> > http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags.
> 
>  ARM VE TC2 board, enabling CONFIG_THUMB2_KERNEL failed to boot in BE mode
> It hangs at very early stage of boot

Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
of the TODO-list. I think Ben said he would probably not have much time
to work on this. I might be able to spare some time on this, so just
let me know if I should start working on this. If I remember correctly,
it's mainly the fixup_pv_table code that needed some Thumb2/BE love.

Will, is getting Thumb2 working a requirement to get the BE support
merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

v3.10 - big endian core support

[Vijay Kilari]

On Fri, Jul 12, 2013 at 5:17 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Vijay Kilari,
>
> On Fri, 12 Jul 2013 17:09:12 +0530, Vijay Kilari wrote:
>
>> > Ben Dooks has a separate branch on top of this base branch for
>> > big-endian support, that adds atags compat code to convert the ATAGs
>> > data from LE to BE. See the baserock/311/be/atags branch in
>> > git://git.baserock.org/delta/linux. Or
>> > http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags.
>>
>>  ARM VE TC2 board, enabling CONFIG_THUMB2_KERNEL failed to boot in BE mode
>> It hangs at very early stage of boot
>
> Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
> of the TODO-list. I think Ben said he would probably not have much time
> to work on this. I might be able to spare some time on this, so just
> let me know if I should start working on this. If I remember correctly,
> it's mainly the fixup_pv_table code that needed some Thumb2/BE love.

In fact, I tried with below changes.. still it fails

diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 2de1114..7df64c7 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -592,8 +592,14 @@ __fixup_a_pv_table:
        b       2f
 1:     add     r7, r3
        ldrh    ip, [r7, #2]
+#ifdef CONFIG_CPU_ENDIAN_BE8
+       rev     ip, ip
+#endif
        and     ip, 0x8f00
        orr     ip, r6  @ mask in offset bits 31-24
+#ifdef CONFIG_CPU_ENDIAN_BE8
+       rev     ip, ip
+#endif
        strh    ip, [r7, #2]
 2:     cmp     r4, r5
        ldrcc   r7, [r4], #4    @ use branch for delay slot

>
> Will, is getting Thumb2 working a requirement to get the BE support
> merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?
>
> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com

v3.10 - big endian core support

[Ben Dooks]

On 12/07/13 12:47, Thomas Petazzoni wrote:
> Dear Vijay Kilari,
>
> On Fri, 12 Jul 2013 17:09:12 +0530, Vijay Kilari wrote:
>
>>> Ben Dooks has a separate branch on top of this base branch for
>>> big-endian support, that adds atags compat code to convert the ATAGs
>>> data from LE to BE. See the baserock/311/be/atags branch in
>>> git://git.baserock.org/delta/linux. Or
>>> http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags.
>>
>>   ARM VE TC2 board, enabling CONFIG_THUMB2_KERNEL failed to boot in BE mode
>> It hangs at very early stage of boot
>
> Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
> of the TODO-list. I think Ben said he would probably not have much time
> to work on this. I might be able to spare some time on this, so just
> let me know if I should start working on this. If I remember correctly,
> it's mainly the fixup_pv_table code that needed some Thumb2/BE love.
>
> Will, is getting Thumb2 working a requirement to get the BE support
> merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?

I would like to sort out getting this code merged as it seems to have
been tested by several people now outside Codethink.

I could try doing the THUMB2 support, but I do not have a lot of
experience with building THUMB2 kernels.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

v3.10 - big endian core support

[Ben Dooks]

On 12/07/13 12:56, Vijay Kilari wrote:
> On Fri, Jul 12, 2013 at 5:17 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com>  wrote:
>> Dear Vijay Kilari,
>>
>> On Fri, 12 Jul 2013 17:09:12 +0530, Vijay Kilari wrote:
>>
>>>> Ben Dooks has a separate branch on top of this base branch for
>>>> big-endian support, that adds atags compat code to convert the ATAGs
>>>> data from LE to BE. See the baserock/311/be/atags branch in
>>>> git://git.baserock.org/delta/linux. Or
>>>> http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags.
>>>
>>>   ARM VE TC2 board, enabling CONFIG_THUMB2_KERNEL failed to boot in BE mode
>>> It hangs at very early stage of boot
>>
>> Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
>> of the TODO-list. I think Ben said he would probably not have much time
>> to work on this. I might be able to spare some time on this, so just
>> let me know if I should start working on this. If I remember correctly,
>> it's mainly the fixup_pv_table code that needed some Thumb2/BE love.
>
> In fact, I tried with below changes.. still it fails
>
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index 2de1114..7df64c7 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -592,8 +592,14 @@ __fixup_a_pv_table:
>          b       2f
>   1:     add     r7, r3
>          ldrh    ip, [r7, #2]
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +       rev     ip, ip
> +#endif

Do you need a rev16 here? I think you may have tried
reversing the full 32 bits here instead of just the
16bits of instruction that was loaded.

>          and     ip, 0x8f00
>          orr     ip, r6  @ mask in offset bits 31-24
> +#ifdef CONFIG_CPU_ENDIAN_BE8
> +       rev     ip, ip
> +#endif
>          strh    ip, [r7, #2]
>   2:     cmp     r4, r5
>          ldrcc   r7, [r4], #4    @ use branch for delay slot
>
>>
>> Will, is getting Thumb2 working a requirement to get the BE support
>> merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?
>>
>> Thanks!
>>
>> Thomas
>> --
>> Thomas Petazzoni, Free Electrons
>> Kernel, drivers, real-time and embedded Linux
>> development, consulting, training and support.
>> http://free-electrons.com


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

v3.10 - big endian core support

[Thomas Petazzoni]

Dear Ben Dooks,

On Fri, 12 Jul 2013 12:58:45 +0100, Ben Dooks wrote:

> > Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
> > of the TODO-list. I think Ben said he would probably not have much time
> > to work on this. I might be able to spare some time on this, so just
> > let me know if I should start working on this. If I remember correctly,
> > it's mainly the fixup_pv_table code that needed some Thumb2/BE love.
> >
> > Will, is getting Thumb2 working a requirement to get the BE support
> > merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?
> 
> I would like to sort out getting this code merged as it seems to have
> been tested by several people now outside Codethink.

I briefly talked with Will this week at LCE, and apparently he was
generally ok with the patches. He only mentioned that the series should
be split between core ARM stuff (that goes through Russell's tree), and
the platform-specific changes, that go through the different
maintainers tree.

> I could try doing the THUMB2 support, but I do not have a lot of
> experience with building THUMB2 kernels.

Ok. Let me know if you need some help. I'd really like to see this BE
work make it into 3.12.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

v3.10 - big endian core support

[Ben Dooks]

On 12/07/13 13:06, Thomas Petazzoni wrote:
> Dear Ben Dooks,
>
> On Fri, 12 Jul 2013 12:58:45 +0100, Ben Dooks wrote:
>
>>> Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
>>> of the TODO-list. I think Ben said he would probably not have much time
>>> to work on this. I might be able to spare some time on this, so just
>>> let me know if I should start working on this. If I remember correctly,
>>> it's mainly the fixup_pv_table code that needed some Thumb2/BE love.
>>>
>>> Will, is getting Thumb2 working a requirement to get the BE support
>>> merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?
>>
>> I would like to sort out getting this code merged as it seems to have
>> been tested by several people now outside Codethink.
>
> I briefly talked with Will this week at LCE, and apparently he was
> generally ok with the patches. He only mentioned that the series should
> be split between core ARM stuff (that goes through Russell's tree), and
> the platform-specific changes, that go through the different
> maintainers tree.

The 311/be/core series which was the first posted has a few machine
specific bits in it (vexpress, highbank and mvebu) but is mainly the
ARM core code and bits of peripheral specific support which still live
under arch/arm.

I left there there as they're fairly small patches and would tend to get
lost. I can remove these before asking RMK to pull the core support and
possibly the atag/boot-endian patches.

>> I could try doing the THUMB2 support, but I do not have a lot of
>> experience with building THUMB2 kernels.
>
> Ok. Let me know if you need some help. I'd really like to see this BE
> work make it into 3.12.

Thanks for the testing. I'll see if I can get some time in early next
week to re-test and send against 3.11-rc series.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

v3.10 - big endian core support

[Will Deacon]

On Fri, Jul 12, 2013 at 12:58:45PM +0100, Ben Dooks wrote:
> On 12/07/13 12:47, Thomas Petazzoni wrote:
> > Dear Vijay Kilari,
> >
> > On Fri, 12 Jul 2013 17:09:12 +0530, Vijay Kilari wrote:
> >
> >>> Ben Dooks has a separate branch on top of this base branch for
> >>> big-endian support, that adds atags compat code to convert the ATAGs
> >>> data from LE to BE. See the baserock/311/be/atags branch in
> >>> git://git.baserock.org/delta/linux. Or
> >>> http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags.
> >>
> >>   ARM VE TC2 board, enabling CONFIG_THUMB2_KERNEL failed to boot in BE mode
> >> It hangs at very early stage of boot
> >
> > Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
> > of the TODO-list. I think Ben said he would probably not have much time
> > to work on this. I might be able to spare some time on this, so just
> > let me know if I should start working on this. If I remember correctly,
> > it's mainly the fixup_pv_table code that needed some Thumb2/BE love.
> >
> > Will, is getting Thumb2 working a requirement to get the BE support
> > merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?
> 
> I would like to sort out getting this code merged as it seems to have
> been tested by several people now outside Codethink.
> 
> I could try doing the THUMB2 support, but I do not have a lot of
> experience with building THUMB2 kernels.

I think we should try and get Thumb-2 supported before merging this as there
isn't any real reason why the instruction set should cause endianness
issues. We're also only almost at -rc1, so there's still time to fix this
properly for 3.12 instead of adding a fake Kconfig dependency.

As for building a Thumb-2 kernel; just enable the option in menuconfig and
you're done. The compiler should "do the right thing".

Will

v3.10 - big endian core support

[jgq516 at gmail.com]

On 07/12/2013 08:00 PM, Ben Dooks wrote:
> On 12/07/13 12:56, Vijay Kilari wrote:
>> On Fri, Jul 12, 2013 at 5:17 PM, Thomas Petazzoni
>> <thomas.petazzoni@free-electrons.com>  wrote:
>>> Dear Vijay Kilari,
>>>
>>> On Fri, 12 Jul 2013 17:09:12 +0530, Vijay Kilari wrote:
>>>
>>>>> Ben Dooks has a separate branch on top of this base branch for
>>>>> big-endian support, that adds atags compat code to convert the ATAGs
>>>>> data from LE to BE. See the baserock/311/be/atags branch in
>>>>> git://git.baserock.org/delta/linux. Or
>>>>> http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags. 
>>>>>
>>>>
>>>>   ARM VE TC2 board, enabling CONFIG_THUMB2_KERNEL failed to boot in 
>>>> BE mode
>>>> It hangs at very early stage of boot
>>>
>>> Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
>>> of the TODO-list. I think Ben said he would probably not have much time
>>> to work on this. I might be able to spare some time on this, so just
>>> let me know if I should start working on this. If I remember correctly,
>>> it's mainly the fixup_pv_table code that needed some Thumb2/BE love.
>>
>> In fact, I tried with below changes.. still it fails
>>
>> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
>> index 2de1114..7df64c7 100644
>> --- a/arch/arm/kernel/head.S
>> +++ b/arch/arm/kernel/head.S
>> @@ -592,8 +592,14 @@ __fixup_a_pv_table:
>>          b       2f
>>   1:     add     r7, r3
>>          ldrh    ip, [r7, #2]
>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>> +       rev     ip, ip
>> +#endif
>
> Do you need a rev16 here? I think you may have tried
> reversing the full 32 bits here instead of just the
> 16bits of instruction that was loaded.
>
Thanks Ben, 3.4 kernel booted ok with your suggested modifications.

gjiang at gjiang-desktop:~/work/be-a15$ git diff
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 0ad3af8..1a0196c 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -600,8 +600,10 @@ __fixup_a_pv_table:
         b       2f
  1:     add     r7, r3
         ldrh    ip, [r7, #2]
+       rev16   ip, ip @be8
         and     ip, 0x8f00
         orr     ip, r6  @ mask in offset bits 31-24
+       rev16   ip, ip @be8
         strh    ip, [r7, #2]
  2:     cmp     r4, r5
         ldrcc   r7, [r4], #4    @ use branch for delay slot

root at localhost:~# zcat /proc/config.gz |grep BE8
CONFIG_CPU_ENDIAN_BE8=y
CONFIG_CPU_BE8_BOOT_LE=y
root at localhost:~# zcat /proc/config.gz |grep THUMB
CONFIG_ARM_THUMB=y
# CONFIG_ARM_THUMBEE is not set
CONFIG_THUMB2_KERNEL=y
CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11=y


Regards,
Xiao
>>          and     ip, 0x8f00
>>          orr     ip, r6  @ mask in offset bits 31-24
>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>> +       rev     ip, ip
>> +#endif
>>          strh    ip, [r7, #2]
>>   2:     cmp     r4, r5
>>          ldrcc   r7, [r4], #4    @ use branch for delay slot
>>
>>>
>>> Will, is getting Thumb2 working a requirement to get the BE support
>>> merged, or can we for now make the BE option depends on 
>>> !THUMB2_KERNEL ?
>>>
>>> Thanks!
>>>
>>> Thomas
>>> -- 
>>> Thomas Petazzoni, Free Electrons
>>> Kernel, drivers, real-time and embedded Linux
>>> development, consulting, training and support.
>>> http://free-electrons.com
>
>

v3.10 - big endian core support

[Vijay Kilari]

Yes, It works now after using rev16

Regards
Vijay

On Mon, Jul 15, 2013 at 8:20 AM,  <jgq516@gmail.com> wrote:
> On 07/12/2013 08:00 PM, Ben Dooks wrote:
>>
>> On 12/07/13 12:56, Vijay Kilari wrote:
>>>
>>> On Fri, Jul 12, 2013 at 5:17 PM, Thomas Petazzoni
>>> <thomas.petazzoni@free-electrons.com>  wrote:
>>>>
>>>> Dear Vijay Kilari,
>>>>
>>>> On Fri, 12 Jul 2013 17:09:12 +0530, Vijay Kilari wrote:
>>>>
>>>>>> Ben Dooks has a separate branch on top of this base branch for
>>>>>> big-endian support, that adds atags compat code to convert the ATAGs
>>>>>> data from LE to BE. See the baserock/311/be/atags branch in
>>>>>> git://git.baserock.org/delta/linux. Or
>>>>>>
>>>>>> http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags.
>>>>>
>>>>>
>>>>>   ARM VE TC2 board, enabling CONFIG_THUMB2_KERNEL failed to boot in BE
>>>>> mode
>>>>> It hangs at very early stage of boot
>>>>
>>>>
>>>> Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
>>>> of the TODO-list. I think Ben said he would probably not have much time
>>>> to work on this. I might be able to spare some time on this, so just
>>>> let me know if I should start working on this. If I remember correctly,
>>>> it's mainly the fixup_pv_table code that needed some Thumb2/BE love.
>>>
>>>
>>> In fact, I tried with below changes.. still it fails
>>>
>>> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
>>> index 2de1114..7df64c7 100644
>>> --- a/arch/arm/kernel/head.S
>>> +++ b/arch/arm/kernel/head.S
>>> @@ -592,8 +592,14 @@ __fixup_a_pv_table:
>>>          b       2f
>>>   1:     add     r7, r3
>>>          ldrh    ip, [r7, #2]
>>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>>> +       rev     ip, ip
>>> +#endif
>>
>>
>> Do you need a rev16 here? I think you may have tried
>> reversing the full 32 bits here instead of just the
>> 16bits of instruction that was loaded.
>>
> Thanks Ben, 3.4 kernel booted ok with your suggested modifications.
>
> gjiang at gjiang-desktop:~/work/be-a15$ git diff
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index 0ad3af8..1a0196c 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -600,8 +600,10 @@ __fixup_a_pv_table:
>
>         b       2f
>  1:     add     r7, r3
>         ldrh    ip, [r7, #2]
> +       rev16   ip, ip @be8
>
>         and     ip, 0x8f00
>         orr     ip, r6  @ mask in offset bits 31-24
> +       rev16   ip, ip @be8
>
>         strh    ip, [r7, #2]
>  2:     cmp     r4, r5
>         ldrcc   r7, [r4], #4    @ use branch for delay slot
>
> root at localhost:~# zcat /proc/config.gz |grep BE8
> CONFIG_CPU_ENDIAN_BE8=y
> CONFIG_CPU_BE8_BOOT_LE=y
> root at localhost:~# zcat /proc/config.gz |grep THUMB
> CONFIG_ARM_THUMB=y
> # CONFIG_ARM_THUMBEE is not set
> CONFIG_THUMB2_KERNEL=y
> CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11=y
>
>
> Regards,
> Xiao
>
>>>          and     ip, 0x8f00
>>>          orr     ip, r6  @ mask in offset bits 31-24
>>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>>> +       rev     ip, ip
>>> +#endif
>>>          strh    ip, [r7, #2]
>>>   2:     cmp     r4, r5
>>>          ldrcc   r7, [r4], #4    @ use branch for delay slot
>>>
>>>>
>>>> Will, is getting Thumb2 working a requirement to get the BE support
>>>> merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?
>>>>
>>>> Thanks!
>>>>
>>>> Thomas
>>>> --
>>>> Thomas Petazzoni, Free Electrons
>>>> Kernel, drivers, real-time and embedded Linux
>>>> development, consulting, training and support.
>>>> http://free-electrons.com
>>
>>
>>
>

v3.10 - big endian core support

[Ben Dooks]

On 14/07/13 22:53, Will Deacon wrote:
> On Fri, Jul 12, 2013 at 12:58:45PM +0100, Ben Dooks wrote:
>> On 12/07/13 12:47, Thomas Petazzoni wrote:
>>> Dear Vijay Kilari,
>>>
>>> On Fri, 12 Jul 2013 17:09:12 +0530, Vijay Kilari wrote:
>>>
>>>>> Ben Dooks has a separate branch on top of this base branch for
>>>>> big-endian support, that adds atags compat code to convert the ATAGs
>>>>> data from LE to BE. See the baserock/311/be/atags branch in
>>>>> git://git.baserock.org/delta/linux. Or
>>>>> http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags.
>>>>
>>>>    ARM VE TC2 board, enabling CONFIG_THUMB2_KERNEL failed to boot in BE mode
>>>> It hangs at very early stage of boot
>>>
>>> Yeah, the Thumb2 code is not supported by Ben Dooks patches, it's part
>>> of the TODO-list. I think Ben said he would probably not have much time
>>> to work on this. I might be able to spare some time on this, so just
>>> let me know if I should start working on this. If I remember correctly,
>>> it's mainly the fixup_pv_table code that needed some Thumb2/BE love.
>>>
>>> Will, is getting Thumb2 working a requirement to get the BE support
>>> merged, or can we for now make the BE option depends on !THUMB2_KERNEL ?
>>
>> I would like to sort out getting this code merged as it seems to have
>> been tested by several people now outside Codethink.
>>
>> I could try doing the THUMB2 support, but I do not have a lot of
>> experience with building THUMB2 kernels.
>
> I think we should try and get Thumb-2 supported before merging this as there
> isn't any real reason why the instruction set should cause endianness
> issues. We're also only almost at -rc1, so there's still time to fix this
> properly for 3.12 instead of adding a fake Kconfig dependency.
>
> As for building a Thumb-2 kernel; just enable the option in menuconfig and
> you're done. The compiler should "do the right thing".

I can build it, I just don't have the time and hardware to give it a
test at the moment. However it seems that changing to using 'rev16'
instead of 'rev'. I will make the necessary changes and get this ready
to go.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

v3.10 - big endian core support

[Thomas Petazzoni]

Dear Ben Dooks,

On Mon, 15 Jul 2013 09:03:28 +0100, Ben Dooks wrote:

> > As for building a Thumb-2 kernel; just enable the option in menuconfig and
> > you're done. The compiler should "do the right thing".
> 
> I can build it, I just don't have the time and hardware to give it a
> test at the moment. However it seems that changing to using 'rev16'
> instead of 'rev'. I will make the necessary changes and get this ready
> to go.

I am willing to give some testing to early patches, if needed. Do not
hesitate to send me things to test.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

v3.10 - big endian core support

[jgq516 at gmail.com]

On 07/15/2013 04:36 PM, Thomas Petazzoni wrote:
> Dear Ben Dooks,
>
> On Mon, 15 Jul 2013 09:03:28 +0100, Ben Dooks wrote:
>
>>> As for building a Thumb-2 kernel; just enable the option in menuconfig and
>>> you're done. The compiler should "do the right thing".
>> I can build it, I just don't have the time and hardware to give it a
>> test at the moment. However it seems that changing to using 'rev16'
>> instead of 'rev'. I will make the necessary changes and get this ready
>> to go.
> I am willing to give some testing to early patches, if needed. Do not
> hesitate to send me things to test.
I can test it too if needed :).

Thanks,
Xiao
> Thanks!
>
> Thomas

v3.10 - big endian core support

[Ben Dooks]

On 15/07/13 09:36, Thomas Petazzoni wrote:
> Dear Ben Dooks,
>
> On Mon, 15 Jul 2013 09:03:28 +0100, Ben Dooks wrote:
>
>>> As for building a Thumb-2 kernel; just enable the option in menuconfig and
>>> you're done. The compiler should "do the right thing".
>>
>> I can build it, I just don't have the time and hardware to give it a
>> test at the moment. However it seems that changing to using 'rev16'
>> instead of 'rev'. I will make the necessary changes and get this ready
>> to go.
>
> I am willing to give some testing to early patches, if needed. Do not
> hesitate to send me things to test.

I've pushed out two new branches on git.baserock.org/delta/linux.git
as:
	baserock/311/be/core-v2
	baserock/311/be/atags-v2

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

v3.10 - big endian core support

[Thomas Petazzoni]

Dear Ben Dooks,

On Mon, 15 Jul 2013 11:26:09 +0100, Ben Dooks wrote:

> I've pushed out two new branches on git.baserock.org/delta/linux.git
> as:
> 	baserock/311/be/core-v2
> 	baserock/311/be/atags-v2

I've tested baserock/311/be/core-v2, after rebasing it on top of
3.11-rc1. I've tested the following combination on an Armada XP board:
little endian ARM, big endian ARM, little endian Thumb2 and big endian
Thumb2. They all worked fine.

There were minor conflicts in arch/arm/kernel/sleep.S and
arch/arm/mach-mvebu/headsmp.S when doing the rebase on top of 3.11-rc1,
but nothing major.

Ben, do you have the time to rebase on 3.11-rc1 and post the patches
for merging?

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

v3.10 - big endian core support

[jgq516 at gmail.com]

On 07/15/2013 06:26 PM, Ben Dooks wrote:
> On 15/07/13 09:36, Thomas Petazzoni wrote:
>> Dear Ben Dooks,
>>
>> On Mon, 15 Jul 2013 09:03:28 +0100, Ben Dooks wrote:
>>
>>>> As for building a Thumb-2 kernel; just enable the option in 
>>>> menuconfig and
>>>> you're done. The compiler should "do the right thing".
>>>
>>> I can build it, I just don't have the time and hardware to give it a
>>> test at the moment. However it seems that changing to using 'rev16'
>>> instead of 'rev'. I will make the necessary changes and get this ready
>>> to go.
>>
>> I am willing to give some testing to early patches, if needed. Do not
>> hesitate to send me things to test.
>
> I've pushed out two new branches on git.baserock.org/delta/linux.git
> as:
>     baserock/311/be/core-v2
I have tested the 10 patches on this branch with latest mainline kernel 
(commit 47188d).
Vexpress a15 tc2 boards works with the combos: BE+LPAE on/off, 
BE+THUMB2+LPAE on and LE.

There are some conflicts existed between your patch set and latest kernel.

Thanks,
Xiao
>     baserock/311/be/atags-v2
>

v3.10 - big endian core support

[Ben Dooks]

On 16/07/13 09:00, jgq516 at gmail.com wrote:
> On 07/15/2013 06:26 PM, Ben Dooks wrote:
>> On 15/07/13 09:36, Thomas Petazzoni wrote:
>>> Dear Ben Dooks,
>>>
>>> On Mon, 15 Jul 2013 09:03:28 +0100, Ben Dooks wrote:
>>>
>>>>> As for building a Thumb-2 kernel; just enable the option in
>>>>> menuconfig and
>>>>> you're done. The compiler should "do the right thing".
>>>>
>>>> I can build it, I just don't have the time and hardware to give it a
>>>> test at the moment. However it seems that changing to using 'rev16'
>>>> instead of 'rev'. I will make the necessary changes and get this ready
>>>> to go.
>>>
>>> I am willing to give some testing to early patches, if needed. Do not
>>> hesitate to send me things to test.
>>
>> I've pushed out two new branches on git.baserock.org/delta/linux.git
>> as:
>> baserock/311/be/core-v2
> I have tested the 10 patches on this branch with latest mainline kernel
> (commit 47188d).
> Vexpress a15 tc2 boards works with the combos: BE+LPAE on/off,
> BE+THUMB2+LPAE on and LE.
>
> There are some conflicts existed between your patch set and latest kernel.

I will do a rebase onto HEAD in the next few days and then see if it
can be prepared for merging in the next merge window.


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

v3.10 - big endian core support

[Thomas Petazzoni]

Dear Will Deacon,

On Mon, 8 Jul 2013 18:03:53 +0100, Will Deacon wrote:
> On Mon, Jul 08, 2013 at 12:02:02PM +0100, Will Deacon wrote:
> > On Mon, Jul 08, 2013 at 10:51:59AM +0100, jgq516 at gmail.com wrote:
> > > The printascii can output before "b __enable_mmu", after move it to
> > > __mmap_switched, nothing can be printed. But if disable LPAE, printascii
> > > works again in __mmap_switched.
> > 
> > Ok, so the page tables are broken. The code is there to swap the two words,
> > but perhaps something ends up being off-by-4 or the like. I'll try and take
> > a look.
> 
> Right, I managed to have a quick play with a 3.10 kernel and the good news
> is that the page tables are fine. The bad part is that using
> CONFIG_ARM_ATAG_DTB_COMPAT to get my command-line from ATAGs into the FDT
> results in a NULL command line, so I don't see any output. If I hardcode the
> command line in the kernel image, things work fine.

Ben Dooks has a separate branch on top of this base branch for
big-endian support, that adds atags compat code to convert the ATAGs
data from LE to BE. See the baserock/311/be/atags branch in
git://git.baserock.org/delta/linux. Or
http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/311/be/atags.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

v3.10 - big endian core support

[jgq516 at gmail.com]

On 07/09/2013 05:55 PM, jgq516 at gmail.com wrote:
> On 07/09/2013 03:45 PM, Will Deacon wrote:
>> On Tue, Jul 09, 2013 at 04:34:45AM +0100, jgq516 at gmail.com wrote:
>>> On 07/09/2013 09:18 AM, jgq516 at gmail.com wrote:
>>>> On 07/09/2013 01:03 AM, Will Deacon wrote:
>>>>> On Mon, Jul 08, 2013 at 12:02:02PM +0100, Will Deacon wrote:
>>>>>> On Mon, Jul 08, 2013 at 10:51:59AM +0100, jgq516 at gmail.com wrote:
>>>>>>> The printascii can output before "b __enable_mmu", after move it to
>>>>>>> __mmap_switched, nothing can be printed. But if disable LPAE,
>>>>>>> printascii
>>>>>>> works again in __mmap_switched.
>>>>>> Ok, so the page tables are broken. The code is there to swap the two
>>>>>> words,
>>>>>> but perhaps something ends up being off-by-4 or the like. I'll try
>>>>>> and take
>>>>>> a look.
>>>>> Right, I managed to have a quick play with a 3.10 kernel and the good
>>>>> news
>>>>> is that the page tables are fine. The bad part is that using
>>>>> CONFIG_ARM_ATAG_DTB_COMPAT to get my command-line from ATAGs into the
>>>>> FDT
>>>>> results in a NULL command line, so I don't see any output. If I
>>>>> hardcode the
>>>>> command line in the kernel image, things work fine.
>>>>>
>>> Hi Will,
>>>
>>> Which kernel tree are you used? I tried latest mainline kernel (used
>>> vexpress_defconfig
>>> and vexpress-v2p-ca15_a7.dtb) without any modification, but it hangs as
>>> follows.
>> Just try 3.10 at the moment -- we're currently in the middle of the 
>> merge
>> window and I know that there is some timer breakage that people have 
>> been
>> talking about.
Forget to say, 3.10 kernel (vexpress_defconfig + 
vexpress-v2p-ca15_a7.dtb) still has
the same problem as the newest mainline kernel.

## Booting kernel from Legacy Image at 80000000 ...
    Image Name:   Linux-3.10.0
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    2843016 Bytes = 2.7 MiB
    Load Address: 60008000
    Entry Point:  60008000
    Verifying Checksum ... OK
## Flattened Device Tree blob at 81f00000
    Booting using the fdt blob at 0x81f00000
    Loading Kernel Image ... OK
OK
    reserving fdt memory region: addr=ff000000 size=1000000
    Loading Device Tree to 9fee9000, end 9feee0a9 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Initializing cgroup subsys cpuset
Linux version 3.10.0 (gjiang at gjiang-desktop) (gcc version 4.6.3 
(Sourcery CodeBench Lite 2012.03-57) ) #2 SMP Tue Jul 9 17:56:53 CST 2013
CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
Machine: ARM-Versatile Express, model: V2P-CA15_CA7
bootconsole [earlycon0] enabled
Memory policy: ECC disabled, Data cache writealloc
------------[ cut here ]------------
WARNING: at arch/arm/kernel/devtree.c:147 arm_dt_init_cpu_maps+0x134/0x1bc()
DT /cpu 5 nodes greater than max cores 4, capping them
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.0 #2
[<80014e5c>] (unwind_backtrace+0x0/0xf8) from [<80011e94>] 
(show_stack+0x10/0x14)
[<80011e94>] (show_stack+0x10/0x14) from [<800209a8>] 
(warn_slowpath_common+0x54/0x68)
[<800209a8>] (warn_slowpath_common+0x54/0x68) from [<80020a50>] 
(warn_slowpath_fmt+0x30/0x40)
[<80020a50>] (warn_slowpath_fmt+0x30/0x40) from [<804cac80>] 
(arm_dt_init_cpu_maps+0x134/0x1bc)
[<804cac80>] (arm_dt_init_cpu_maps+0x134/0x1bc) from [<804ca190>] 
(setup_arch+0x658/0x6e4)
[<804ca190>] (setup_arch+0x658/0x6e4) from [<804c759c>] 
(start_kernel+0x90/0x30c)
[<804c759c>] (start_kernel+0x90/0x30c) from [<80008074>] (0x80008074)
---[ end trace 1b75b31a2719ed1c ]---
SMP: 5 cores greater than maximum (4), clipping
PERCPU: Embedded 7 pages/cpu @80d4f000 s7040 r8192 d13440 u32768
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
Kernel command line: root=/dev/nfs console=ttyAMA0,38400n8 rw 
init=/linuxrc nfsroot=128.224.163.23:/home/gjiang/work/a15fs ip=dhcp 
earlyprintk
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1024MB = 1024MB total
Memory: 1034012k/1034012k available, 14564k reserved, 0K highmem
Virtual kernel memory layout:
     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
     vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
     lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
     modules : 0x7f000000 - 0x80000000   (  16 MB)
       .text : 0x80008000 - 0x804c6fe0   (4860 kB)
       .init : 0x804c7000 - 0x804f8b80   ( 199 kB)
       .data : 0x804fa000 - 0x80523780   ( 166 kB)
        .bss : 0x80523780 - 0x80545b7c   ( 137 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
Hierarchical RCU implementation.
NR_IRQS:16 nr_irqs:16 16
Failed to obtain parent clocks for SP810!
sp804: arm,sp804 clock not found: -2
sp804: clock not found: -2
sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
Console: colour dummy device 80x30
Calibrating delay loop...

Thanks,
Xiao

v3.10 - big endian core support

[Ben Dooks]

On 09/07/13 10:53, jgq516 at gmail.com wrote:
>
>> My notes show I did a custom 3.5 backport for a customer's kernel
>> so was not testing with the latest. I think I tried 3.9 with LPAE
>> but cannot find confirmation in my notes that this actually happened.
>>
>>
> Thanks for your feedback, it give me more confidence to make it work with
> 3.4 kernel, actually it works now :)

There where several fixes done pre v3.10 which sorted out some kernel
bugs where endian-ness was assumed.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

v3.10 - big endian core support

[jgq516 at gmail.com]

On 07/09/2013 03:45 PM, Will Deacon wrote:
> On Tue, Jul 09, 2013 at 04:34:45AM +0100, jgq516 at gmail.com wrote:
>> On 07/09/2013 09:18 AM, jgq516 at gmail.com wrote:
>>> On 07/09/2013 01:03 AM, Will Deacon wrote:
>>>> On Mon, Jul 08, 2013 at 12:02:02PM +0100, Will Deacon wrote:
>>>>> On Mon, Jul 08, 2013 at 10:51:59AM +0100, jgq516 at gmail.com wrote:
>>>>>> The printascii can output before "b __enable_mmu", after move it to
>>>>>> __mmap_switched, nothing can be printed. But if disable LPAE,
>>>>>> printascii
>>>>>> works again in __mmap_switched.
>>>>> Ok, so the page tables are broken. The code is there to swap the two
>>>>> words,
>>>>> but perhaps something ends up being off-by-4 or the like. I'll try
>>>>> and take
>>>>> a look.
>>>> Right, I managed to have a quick play with a 3.10 kernel and the good
>>>> news
>>>> is that the page tables are fine. The bad part is that using
>>>> CONFIG_ARM_ATAG_DTB_COMPAT to get my command-line from ATAGs into the
>>>> FDT
>>>> results in a NULL command line, so I don't see any output. If I
>>>> hardcode the
>>>> command line in the kernel image, things work fine.
>>>>
>> Hi Will,
>>
>> Which kernel tree are you used? I tried latest mainline kernel (used
>> vexpress_defconfig
>> and vexpress-v2p-ca15_a7.dtb) without any modification, but it hangs as
>> follows.
> Just try 3.10 at the moment -- we're currently in the middle of the merge
> window and I know that there is some timer breakage that people have been
> talking about.
Thanks a lot, it works after cherry pick patches from 3.10 kernel.

Thanks,
Xiao
> Will

v3.10 - big endian core support

[jgq516 at gmail.com]

> My notes show I did a custom 3.5 backport for a customer's kernel
> so was not testing with the latest. I think I tried 3.9 with LPAE
> but cannot find confirmation in my notes that this actually happened.
>
>
Thanks for your feedback, it give me more confidence to make it work with
3.4 kernel, actually it works now :)

Xiao

v3.10 - big endian core support

[Will Deacon]

On Tue, Jul 09, 2013 at 04:34:45AM +0100, jgq516 at gmail.com wrote:
> On 07/09/2013 09:18 AM, jgq516 at gmail.com wrote:
> > On 07/09/2013 01:03 AM, Will Deacon wrote:
> >> On Mon, Jul 08, 2013 at 12:02:02PM +0100, Will Deacon wrote:
> >>> On Mon, Jul 08, 2013 at 10:51:59AM +0100, jgq516 at gmail.com wrote:
> >>>> The printascii can output before "b __enable_mmu", after move it to
> >>>> __mmap_switched, nothing can be printed. But if disable LPAE, 
> >>>> printascii
> >>>> works again in __mmap_switched.
> >>> Ok, so the page tables are broken. The code is there to swap the two 
> >>> words,
> >>> but perhaps something ends up being off-by-4 or the like. I'll try 
> >>> and take
> >>> a look.
> >> Right, I managed to have a quick play with a 3.10 kernel and the good 
> >> news
> >> is that the page tables are fine. The bad part is that using
> >> CONFIG_ARM_ATAG_DTB_COMPAT to get my command-line from ATAGs into the 
> >> FDT
> >> results in a NULL command line, so I don't see any output. If I 
> >> hardcode the
> >> command line in the kernel image, things work fine.
> >>
> Hi Will,
> 
> Which kernel tree are you used? I tried latest mainline kernel (used 
> vexpress_defconfig
> and vexpress-v2p-ca15_a7.dtb) without any modification, but it hangs as 
> follows.

Just try 3.10 at the moment -- we're currently in the middle of the merge
window and I know that there is some timer breakage that people have been
talking about.

Will

v3.10 - big endian core support

[jgq516 at gmail.com]

On 07/09/2013 09:18 AM, jgq516 at gmail.com wrote:
> On 07/09/2013 01:03 AM, Will Deacon wrote:
>> On Mon, Jul 08, 2013 at 12:02:02PM +0100, Will Deacon wrote:
>>> On Mon, Jul 08, 2013 at 10:51:59AM +0100, jgq516 at gmail.com wrote:
>>>> The printascii can output before "b __enable_mmu", after move it to
>>>> __mmap_switched, nothing can be printed. But if disable LPAE, 
>>>> printascii
>>>> works again in __mmap_switched.
>>> Ok, so the page tables are broken. The code is there to swap the two 
>>> words,
>>> but perhaps something ends up being off-by-4 or the like. I'll try 
>>> and take
>>> a look.
>> Right, I managed to have a quick play with a 3.10 kernel and the good 
>> news
>> is that the page tables are fine. The bad part is that using
>> CONFIG_ARM_ATAG_DTB_COMPAT to get my command-line from ATAGs into the 
>> FDT
>> results in a NULL command line, so I don't see any output. If I 
>> hardcode the
>> command line in the kernel image, things work fine.
>>
Hi Will,

Which kernel tree are you used? I tried latest mainline kernel (used 
vexpress_defconfig
and vexpress-v2p-ca15_a7.dtb) without any modification, but it hangs as 
follows.

## Booting kernel from Legacy Image at 80000000 ...
    Image Name:   Linux-3.10.0+
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    2857168 Bytes = 2.7 MiB
    Load Address: 60008000
    Entry Point:  60008000
    Verifying Checksum ... OK
## Flattened Device Tree blob at 81f00000
    Booting using the fdt blob at 0x81f00000
    Loading Kernel Image ... OK
OK
    reserving fdt memory region: addr=ff000000 size=1000000
    Loading Device Tree to 9fee9000, end 9feee0a9 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Initializing cgroup subsys cpuset
Linux version 3.10.0+ (gjiang at gjiang-desktop) (gcc version 4.6.3 
(Sourcery CodeBench Lite 2012.03-57) ) #1 SMP Tue Jul 9 11:18:52 CST 2013
CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
Machine: ARM-Versatile Express, model: V2P-CA15_CA7
bootconsole [earlycon0] enabled
Memory policy: ECC disabled, Data cache writealloc
------------[ cut here ]------------
WARNING: at arch/arm/kernel/devtree.c:147 arm_dt_init_cpu_maps+0x134/0x1bc()
DT /cpu 5 nodes greater than max cores 4, capping them
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.0+ #1
[<80015b0c>] (unwind_backtrace+0x0/0xf8) from [<80011f20>] 
(show_stack+0x10/0x14)
[<80011f20>] (show_stack+0x10/0x14) from [<803a9c08>] (dump_stack+0x70/0x88)
[<803a9c08>] (dump_stack+0x70/0x88) from [<80021c10>] 
(warn_slowpath_common+0x54/0x68)
[<80021c10>] (warn_slowpath_common+0x54/0x68) from [<80021cb8>] 
(warn_slowpath_fmt+0x30/0x40)
[<80021cb8>] (warn_slowpath_fmt+0x30/0x40) from [<804d0cac>] 
(arm_dt_init_cpu_maps+0x134/0x1bc)
[<804d0cac>] (arm_dt_init_cpu_maps+0x134/0x1bc) from [<804cfd1c>] 
(setup_arch+0x680/0x898)
[<804cfd1c>] (setup_arch+0x680/0x898) from [<804cd640>] 
(start_kernel+0x90/0x310)
[<804cd640>] (start_kernel+0x90/0x310) from [<80008074>] (0x80008074)
---[ end trace 1b75b31a2719ed1c ]---
SMP: 5 cores greater than maximum (4), clipping
PERCPU: Embedded 7 pages/cpu @80d56000 s7296 r8192 d13184 u32768
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
Kernel command line: root=/dev/nfs console=ttyAMA0,38400n8 rw 
init=/linuxrc nfsroot=128.224.163.23:/home/gjiang/work/a15fs ip=dhcp 
earlyprintk
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1033984K/1048576K available (3867K kernel code, 166K rwdata, 
1012K rodata, 199K init, 137K bss, 14592K reserved)
Virtual kernel memory layout:
     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
     vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
     lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
     modules : 0x7f000000 - 0x80000000   (  16 MB)
       .text : 0x80008000 - 0x804cc208   (4881 kB)
       .init : 0x804cd000 - 0x804fec80   ( 200 kB)
       .data : 0x80500000 - 0x80529a60   ( 167 kB)
        .bss : 0x80529a60 - 0x8054c0bc   ( 138 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
Hierarchical RCU implementation.
NR_IRQS:16 nr_irqs:16 16
Failed to obtain parent clocks for SP810!
sp804: arm,sp804 clock not found: -2
sp804: clock not found: -2
sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
Console: colour dummy device 80x30
Calibrating delay loop...

Thanks,
Xiao
>> What kernel are you using, and how are you passing your command line?
> 3.4 kernel and command line is passed from uboot, I will try 3.10 
> kernel, then cherry pick
> some related patches from 3.10 if 3.10 works.
>
> Thanks,
> Xiao
>> Will
>

v3.10 - big endian core support

[jgq516 at gmail.com]

On 07/09/2013 01:03 AM, Will Deacon wrote:
> On Mon, Jul 08, 2013 at 12:02:02PM +0100, Will Deacon wrote:
>> On Mon, Jul 08, 2013 at 10:51:59AM +0100, jgq516 at gmail.com wrote:
>>> The printascii can output before "b __enable_mmu", after move it to
>>> __mmap_switched, nothing can be printed. But if disable LPAE, printascii
>>> works again in __mmap_switched.
>> Ok, so the page tables are broken. The code is there to swap the two words,
>> but perhaps something ends up being off-by-4 or the like. I'll try and take
>> a look.
> Right, I managed to have a quick play with a 3.10 kernel and the good news
> is that the page tables are fine. The bad part is that using
> CONFIG_ARM_ATAG_DTB_COMPAT to get my command-line from ATAGs into the FDT
> results in a NULL command line, so I don't see any output. If I hardcode the
> command line in the kernel image, things work fine.
>
> What kernel are you using, and how are you passing your command line?
3.4 kernel and command line is passed from uboot, I will try 3.10 
kernel, then cherry pick
some related patches from 3.10 if 3.10 works.

Thanks,
Xiao
> Will

v3.10 - big endian core support

[Will Deacon]

On Mon, Jul 08, 2013 at 12:02:02PM +0100, Will Deacon wrote:
> On Mon, Jul 08, 2013 at 10:51:59AM +0100, jgq516 at gmail.com wrote:
> > The printascii can output before "b __enable_mmu", after move it to
> > __mmap_switched, nothing can be printed. But if disable LPAE, printascii
> > works again in __mmap_switched.
> 
> Ok, so the page tables are broken. The code is there to swap the two words,
> but perhaps something ends up being off-by-4 or the like. I'll try and take
> a look.

Right, I managed to have a quick play with a 3.10 kernel and the good news
is that the page tables are fine. The bad part is that using
CONFIG_ARM_ATAG_DTB_COMPAT to get my command-line from ATAGs into the FDT
results in a NULL command line, so I don't see any output. If I hardcode the
command line in the kernel image, things work fine.

What kernel are you using, and how are you passing your command line?

Will

v3.10 - big endian core support

[Ben Dooks]

On 08/07/13 11:03, jgq516 at gmail.com wrote:
> On 07/08/2013 05:58 PM, Ben Dooks wrote:
>> On 08/07/13 06:39, jgq516 at gmail.com wrote:
>>> On 07/01/2013 07:03 PM, Ben Dooks wrote:
>>>> The latest big-endian changes, now on:
>>>>
>>>> git://git.baserock.org/delta/linux baserock/311/be/core
>>>>
>>>> This has a minor fix from the last version where a rebase missed a
>>>> change
>>>> in the smp_scu code.
>>>>
>>> Hello Ben,
>>>
>>> Thanks for you patches at first. I can boot BE kernel on vexpress a15
>>> tc2
>>> board with LPAE disabled.
>>>
>>> However if enable LPAE, kernel seems hang after turn on mmu on since
>>> printascii can't output any character in __mmap_switched.
>>> Did you happen to try BE kernel with LPAE enabled before? or am I missed
>>> something?
>>
>> I thought I did try the vexpress with LPAE, however it may have been
>> with a previous revision of the patches.
>>
> Which revision? does it also existed in your tree? I want to give it a
> try :)

My notes show I did a custom 3.5 backport for a customer's kernel
so was not testing with the latest. I think I tried 3.9 with LPAE
but cannot find confirmation in my notes that this actually happened.


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

v3.10 - big endian core support

[Will Deacon]

On Mon, Jul 08, 2013 at 10:51:59AM +0100, jgq516 at gmail.com wrote:
> On 07/08/2013 04:49 PM, Will Deacon wrote:
> > Well, I hacked head.S recently to fix booting with LPAE and BE8, but I was
> > unable to test early console since I was using virtio-console. It could be
> > that the page table entries mapping the uart aren't quite right, but no
> > obvious issues jump out from looking at the code.
> Good to know you tried LPAE and BE8, and I can test the hack code if you 
> wish.

The hack got merged, since it fixed booting (which I managed to test), I
just couldn't test earlyprintk. Maybe I can try and get something up and
running on the model.

> > How much visibility do you have on your platform?
> The printascii can output before "b __enable_mmu", after move it to
> __mmap_switched, nothing can be printed. But if disable LPAE, printascii
> works again in __mmap_switched.

Ok, so the page tables are broken. The code is there to swap the two words,
but perhaps something ends up being off-by-4 or the like. I'll try and take
a look.

Will

v3.10 - big endian core support

[jgq516 at gmail.com]

On 07/08/2013 05:58 PM, Ben Dooks wrote:
> On 08/07/13 06:39, jgq516 at gmail.com wrote:
>> On 07/01/2013 07:03 PM, Ben Dooks wrote:
>>> The latest big-endian changes, now on:
>>>
>>> git://git.baserock.org/delta/linux baserock/311/be/core
>>>
>>> This has a minor fix from the last version where a rebase missed a 
>>> change
>>> in the smp_scu code.
>>>
>> Hello Ben,
>>
>> Thanks for you patches at first. I can boot BE kernel on vexpress a15 
>> tc2
>> board with LPAE disabled.
>>
>> However if enable LPAE, kernel seems hang after turn on mmu on since
>> printascii can't output any character in __mmap_switched.
>> Did you happen to try BE kernel with LPAE enabled before? or am I missed
>> something?
>
> I thought I did try the vexpress with LPAE, however it may have been
> with a previous revision of the patches.
>
Which revision? does it also existed in your tree? I want to give it a 
try :)

Thanks,
Xiao

v3.10 - big endian core support

[Ben Dooks]

On 08/07/13 06:39, jgq516 at gmail.com wrote:
> On 07/01/2013 07:03 PM, Ben Dooks wrote:
>> The latest big-endian changes, now on:
>>
>> git://git.baserock.org/delta/linux baserock/311/be/core
>>
>> This has a minor fix from the last version where a rebase missed a change
>> in the smp_scu code.
>>
> Hello Ben,
>
> Thanks for you patches at first. I can boot BE kernel on vexpress a15 tc2
> board with LPAE disabled.
>
> However if enable LPAE, kernel seems hang after turn on mmu on since
> printascii can't output any character in __mmap_switched.
> Did you happen to try BE kernel with LPAE enabled before? or am I missed
> something?

I thought I did try the vexpress with LPAE, however it may have been
with a previous revision of the patches.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

v3.10 - big endian core support

[jgq516 at gmail.com]

On 07/08/2013 04:49 PM, Will Deacon wrote:
> On Mon, Jul 08, 2013 at 06:39:21AM +0100, jgq516 at gmail.com wrote:
>> On 07/01/2013 07:03 PM, Ben Dooks wrote:
>>> The latest big-endian changes, now on:
>>>
>>> 	git://git.baserock.org/delta/linux baserock/311/be/core
>>>
>>> This has a minor fix from the last version where a rebase missed a change
>>> in the smp_scu code.
>>>
>> Hello Ben,
>>
>> Thanks for you patches at first. I can boot BE kernel on vexpress a15 tc2
>> board with LPAE disabled.
>>
>> However if enable LPAE, kernel seems hang after turn on mmu on since
>> printascii can't output any character in __mmap_switched.
>> Did you happen to try BE kernel with LPAE enabled before? or am I missed
>> something?
> Well, I hacked head.S recently to fix booting with LPAE and BE8, but I was
> unable to test early console since I was using virtio-console. It could be
> that the page table entries mapping the uart aren't quite right, but no
> obvious issues jump out from looking at the code.
Good to know you tried LPAE and BE8, and I can test the hack code if you 
wish.
> How much visibility do you have on your platform?
The printascii can output before "b __enable_mmu", after move it to
__mmap_switched, nothing can be printed. But if disable LPAE, printascii
works again in __mmap_switched.
>   Can you take a look at the page table entries and check they look ok please?
Sorry, do you mean the section of __create_page_tables? could you please 
elaborate it?

Thanks,
Xiao

> Cheers,
>
> Will
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>

v3.10 - big endian core support

[Will Deacon]

On Mon, Jul 08, 2013 at 06:39:21AM +0100, jgq516 at gmail.com wrote:
> On 07/01/2013 07:03 PM, Ben Dooks wrote:
> > The latest big-endian changes, now on:
> >
> > 	git://git.baserock.org/delta/linux baserock/311/be/core
> >
> > This has a minor fix from the last version where a rebase missed a change
> > in the smp_scu code.
> >
> Hello Ben,
> 
> Thanks for you patches at first. I can boot BE kernel on vexpress a15 tc2
> board with LPAE disabled.
> 
> However if enable LPAE, kernel seems hang after turn on mmu on since
> printascii can't output any character in __mmap_switched.
> Did you happen to try BE kernel with LPAE enabled before? or am I missed
> something?

Well, I hacked head.S recently to fix booting with LPAE and BE8, but I was
unable to test early console since I was using virtio-console. It could be
that the page table entries mapping the uart aren't quite right, but no
obvious issues jump out from looking at the code.

How much visibility do you have on your platform? Can you take a look at the
page table entries and check they look ok please?

Cheers,

Will

v3.10 - big endian core support

[jgq516 at gmail.com]

On 07/01/2013 07:03 PM, Ben Dooks wrote:
> The latest big-endian changes, now on:
>
> 	git://git.baserock.org/delta/linux baserock/311/be/core
>
> This has a minor fix from the last version where a rebase missed a change
> in the smp_scu code.
>
Hello Ben,

Thanks for you patches at first. I can boot BE kernel on vexpress a15 tc2
board with LPAE disabled.

However if enable LPAE, kernel seems hang after turn on mmu on since
printascii can't output any character in __mmap_switched.
Did you happen to try BE kernel with LPAE enabled before? or am I missed
something?

Thanks,
Xiao

> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>

v3.10 - big endian core support

[Ben Dooks]

On 01/07/13 15:33, Thomas Petazzoni wrote:
> Dear Ben Dooks,
>
> On Mon,  1 Jul 2013 12:03:58 +0100, Ben Dooks wrote:
>> The latest big-endian changes, now on:
>>
>> 	git://git.baserock.org/delta/linux baserock/311/be/core
>>
>> This has a minor fix from the last version where a rebase missed a change
>> in the smp_scu code.
>
> Patches 1, 2, 3, 4 and 9:
>
> Tested-by: Thomas Petazzoni<thomas.petazzoni@free-electrons.com>

Thanks.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

v3.10 - big endian core support

[Thomas Petazzoni]

Dear Ben Dooks,

On Mon,  1 Jul 2013 12:03:58 +0100, Ben Dooks wrote:
> The latest big-endian changes, now on:
> 
> 	git://git.baserock.org/delta/linux baserock/311/be/core
> 
> This has a minor fix from the last version where a rebase missed a change
> in the smp_scu code.

Patches 1, 2, 3, 4 and 9:

Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

on an Armada XP GP board. The other patches are not exercised by this
particular testing.

I'm interested in seeing this series merged.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

v3.10 - big endian core support

[Ben Dooks]

The latest big-endian changes, now on:

	git://git.baserock.org/delta/linux baserock/311/be/core

This has a minor fix from the last version where a rebase missed a change
in the smp_scu code.