[U-Boot] merge arm64 to arm

[Måns Rullgård]

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.

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