ARM big-endian on current kernels for linux-3.8

[ben.dooks@codethink.co.uk (Ben Dooks)]

On 13/02/13 15:52, Catalin Marinas wrote:
> On Wed, Feb 13, 2013 at 11:18:35AM +0000, Ben Dooks wrote:
>> On 13/02/13 10:24, Matthieu CASTET wrote:
>>> Ben Dooks a ?crit :
>>>> On 12/02/13 17:13, Russell King - ARM Linux wrote:
>>>>> On Fri, Feb 08, 2013 at 11:17:30PM +0000, Ben Dooks wrote:
>>>>>> I have been working on getting big-endian kernels working, mainly from
>>>>>> little-endian boot envrionments. The following patch series is what I
>>>>>> have been working on, mainly on the highbank and axp systems.
>>>>> What is missing from this is the justification about why we need this
>>>>> additional pain, given that all the supporting userspaces today are all
>>>>> LE based.
>>>>>
>>>>> Sure, I know that telcos have an endless love of big endian and don't
>>>>> understand anything else, but getting this working on non-telco socs
>>>>> seems to be a little odd.
>>>>
>>>> Our problem is we have some code that works on a lot of big endian data
>>>> but is not easy to re-build to work on ARM little endian. The current
>>>> solution is to change to running the system big endian.
>>>>
>>>> Unfortunately we cannot just run user-space big endian as the MMU is
>>>> fetched in the same endian mode as the processor's data.
>>>>
>>> Which architecture are you using ?
>>>
>>> On armv7 the mmu endian mode is selected by SCTLR.EE [1], but userspace can
>>> change it's endian with setend instruction [2].
>>>
>>> As the endian state is stored in cpsr, it should be preserved across context switch.
>>
>> Ah yes, I got confused as there is also an endian mode for the page
>> tables that needs to match the endian mode that the kernel is doing
>> loads/stores in.
>>
>> However if we had BE userland with LE kernel then things are going to
>> get difficult with a BE<>LE syscall issue.
>
> I had an (insane) idea once but no time to pursue. You can enable the
> 'compat' layer for a 32-bit ARM kernel and define all the compat_* types
> to be the same as the native ones. The compat layer has several handlers
> for syscalls which pretty much do the conversion between compat and
> native structures. The compat structures are read/written from/to user
> using get_user/put_user on each member. You then need change the ARM
> get_user/put_user code to test a new TIF_BE flag and do a 'rev' on the
> data. At this point the native kernel structures would have the correct
> little endianness.
>
> I reckon the above would cover 70-80% of the syscalls. You need to chase
> other syscalls and update the binfmt_elf.c to cope with BE ELF files.
> Probably there are other issues as well.

Yes, it is far more work than just running the entire system BE, but
could be done. I however only have a budget of a beer, or maybe two
beers if pushing it.

I might have a go at this if I have some spare time

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