[U-Boot] merge arm64 to arm

[Tom Rini <trini@ti.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/19/2013 08:32 AM, M?ns Rullg?rd wrote:
> Tom Rini <trini@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@phytium.com.cn> writes:
>>>>> 
>>>>>>> FengHua <fenghua@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".

And maybe it's a little bit of OSS thickheadedness, but looking over
the parts of the code that aren't in the armv8 directory already we
have a lot of "re-use asm-generic file" and "maybe slightly tweak the
existing arm file slightly".

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSEhUuAAoJENk4IS6UOR1W/EoP/itZyVLRjokaOawZaZYtpJ0m
mxut19tS64QS3vjmhh3uJjjr+XOCnrCGYNYwGyst0JgoIld1baXhee99iHQ4o3td
Uz3gsCrjx6RpRuHw3gdkYHCVdRQbUTOGi3V4Cxb/hQa6+0LMvKo/G5Te81TeNnr4
N2NhnQRa3upHESNo59NXLDi2Y8GQF1X+Axsr4SIB+K+p6Wo8Teqk79b+Y431HGCQ
sOrsyPpykT8ooecI/OjJ3zGfF66BTZIBT9Ts9iZaSqhv63mhUInwOWwUBD+VFZD0
zgL39lmd84PFVn/mHhT2u/aAZPcpb+j459wjO8WNvzTl2TIPl+t+3LcvTcfF8J+h
hxYjnj41CmFL8z6jwTlbEB9a0SKoonunFhx7n+yz8as2YnBt0GEsN4yYxCUUeoT0
cDeEhdk5ulGT8zAwGN4ZtpK0Fg/W9AhHXMW/GbqbrA0T7NXoDFpJZAVEFqzxcfNy
mf81bSKV3iSy/FX75fmMCBHxNYBPj+7TnEc+atrBnaqGLzC38LNkZiYA6l9o54Xj
AdxS8NVgRhe6dkNgGJwHcLlpLZY0Yu71wftWNwtXnw6chqJd7RyeJ4RJTPhrhsdk
iS/n45jOTs37QKPEp/aLm8Rr5k0a9qNbVmVUJT0/tIjCNeW04kPXj619a+Z8zEEG
ajyvlLrugY8aCs+k9TT5
=KIu6
-----END PGP SIGNATURE-----