[U-Boot] merge arm64 to arm

[Måns Rullgård]

Tom Rini <trini at ti.com> writes:

> On 08/19/2013 08:32 AM, Måns Rullgård wrote:
>> Tom Rini <trini at ti.com> writes:
>>
>>> On 08/18/2013 11:46 PM, Sharma Bhupesh-B45370 wrote:
>>>> [Re-posting as original msg was rejected due to HTML
>>>> content..]
>>>>
>>>>>> FengHua <fenghua at phytium.com.cn> writes:
>>>>>>
>>>>>>>> FengHua <fenghua at phytium.com.cn> writes:
>>>>>>>>
>>>>>>>>> hi tom, hi albert, yes, it's right. the u-boot could
>>>>>>>>> be more uniformly and maintainable if merging armv8
>>>>>>>>> to arm architecture. I will try to migrate arm64 to
>>>>>>>>> armv8 subarchitecture of arm. do you have any other
>>>>>>>>> advice?
>>>>>>>>
>>>>>>>> Why?  The architectures are vastly different, arm64
>>>>>>>> (aarch64) being only loosely inspired by the 32-bit
>>>>>>>> arm. It is not like with x86/amd64 where a lot of code
>>>>>>>> can be shared.
>>>>>>>
>>>>>>> Of course, with a seperated architecture the arm64 code
>>>>>>> will be clear and simple. when it merged with arm a few
>>>>>>> file should be duplicated with the name "_v8" appended
>>>>>>> and many macro switch should be added. but most of the
>>>>>>> code will be in armv8 directory which paralleled with
>>>>>>> armv7. it seems that this implementation are more nice.
>>>>>>
>>>>>> ARMv8 defines both a 32-bit (aarch32) and a 64-bit
>>>>>> (aarch64) instruction set.  The naming you are suggesting
>>>>>> would be misleading.
>>>>>>
>>>>>
>>>>> aarch32 state is compatible with armv7. armv8 directory only
>>>>> provide aarch64 state support. as you said, it would be a
>>>>> little misleading.
>>>>>
>>>>
>>>> ARMv8 ARM (Architecture Reference Manual) mentions that the
>>>> ARMv8 architecture has support for both AArch32 and AArch64 and
>>>> the ARM can switch b/w the two instruction sets via
>>>> exceptions.
>>>>
>>>> So, whether choosing a naming convention similar to linux
>>>> (arch/arm64) would be more suitable is something to consider
>>>> (even though some of the files might be a copy of what is
>>>> available in arch/arm/cpu/armv7)?
>>>
>>> I think we'll see what happens with a single directory first.
>>> We aren't talking about a binary that has to work on all cases
>>> (right now...)
>>
>> A single binary can obviously never work.
>>
>>> and we want to avoid massive duplication of all of the C code
>>> that really won't change.
>>
>> If there's a lot of code shared between these architectures, why is
>> it in an architecture-specific directory in the first place?  Maybe
>> the proper solution is to move it out of arch/arm rather than
>> moving code for an entirely different architecture in there.
>
> We are working in that direction (and one of the requests was to hook
> into that code, rather than duplicate things).  Think of it as "all
> ARM Ltd licensed cores" not "all 32bit-only ARM cores".

Why does it matter which company designed it?  By that reasoning, you'd
put i960 (were it supported) under arch/x86 because it's from Intel.

-- 
Måns Rullgård
mans at mansr.com