[U-Boot] merge arm64 to arm

[Tom Rini]

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

On 08/19/2013 09:01 AM, Måns Rullgård wrote:
> 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.

Probably because I didn't get the "it's a whole new unrelated to
everything before world over there!" memo.  Seriously tho, our
directory structure is different from the kernel and it seems like
things might look cleaner this way.  If it doesn't, well, I'll admit
to being wrong and we'll go back to a split arch directory.

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

iQIcBAEBAgAGBQJSEhlZAAoJENk4IS6UOR1Wk6MP/2xKkGHzL4dsAwkVjx620T53
JD+6mpkD5pkaIO2TAE67tltp2ui5appWfAxbuHZeYfpY69cy+J7+To4zzECnbSY3
AYNgrIjQlhNH1+Yh9saNCPtc49VNfHACV84kYaG3lgd/IyS96j6qur82jq5OEO1x
qaqCr3Utmtp5YBfB/0F+gYUlbOGKNuKmWsyZpuptLPNwF16AZKIwYTsKIgorqjLy
UxqokPJO9uTrCynHCfCvEyxXk9yK/LrwFIJaytOR3gjXJO9yYN2VjOXK2P58YW3j
dB2ETNvoSw+CL3h831h+QnYt5VUGfwxVYEs9mhh02SSXX4Ddf6ziv8lvfLg2EWEF
VnGD14k6UwBG9Jr9s0oZjpOPC5i0Vtid01Tmqa/rjvBtcbuFJDeNowYCak+gMuhj
Vc6nZ3wVQtp2mOKY1fQ5or73cG6iXQJ2UzECFvQJrWvxfME2L31RrIFHy2JHMSYj
NEk23OtjLFEFtnRE148+K+lRxfqTVRXYYHuBWoA626TfFg+nqKhJpRzldm7F9ANg
m0Hwmermxis/qfmk7pqvkbP+dc0IKa9x8gFOtPinG+qVIWFLI+YYf/RwYkrm6r5A
M4saocBkKNpbUElqmc1vWxhHOUihy+xG+zM5Cg57sh+a6X0rUXiJa9Nn34C1GmEt
Yh6JXiPw1xZ4/5dshkZ8
=Q1gl
-----END PGP SIGNATURE-----