[U-Boot] merge arm64 to arm

[U-Boot] merge arm64 to arm

[Tom Rini]

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

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...) and we want to avoid massive duplication of all of the C code
that really won't change.

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

iQIcBAEBAgAGBQJSEg2DAAoJENk4IS6UOR1WTlIQAJ8AGDcx/xBZegNj77wzpv4n
NcOc7c+X3/oupY51BJAogOXQtdlvfY7l9IfPd0IIzdjOmVrley07J4dFi33tq7XN
FV7E/Mu+6ZncG79qxj5O5qRJcQOtaIMookd30GyRdroF7FXHx63O1MmZaFpCYTWF
+dqM2WdiqdhysoaN/8QYqm4091JAMwrAccD6pLO5TJPFcxtSXjSXkUzskVpC2tKP
JDtQMvb99FLsA14V0lQXgNkRKwSO8b1aWjLhto244s0lx9oflpPtqqzUIZVvE/Lh
vB1u26vY8CQS5lwI5XTxaQoKD69icw5f7FoFarz62COp781fxSPjjsHRZ35HkWtU
Ytku/yWXAhCpiwX/GWenyJ2Y90RqSi2bMlUXJa8R7j8XljZfradbVijOivwitjff
XxugrV8wRo3Z6l8J8f93BbEc9Ifj0QUqYrPLfXswV+cX+oSj6wpdDAogXcqOGxPU
wNPoeOxX2jt4juHwhReB8p57VfBmyLIFSYJHqFapH8vOPKwAIzM37Cj1Klr9rzdK
816ZxTw1t2TNGNSNvqcAs5jCeteUc5uz88vVQThEw0Mj3NALDizerEZcACPq/k7B
eNevlMCoHJjxzcbG4mdLbpV4AAWIV7bna9BYAx4iyLC6SHJrj34zh0US97uwSIOG
8iFrBgYGVsJu+91rfQmD
=/nnu
-----END PGP SIGNATURE-----

[U-Boot] merge arm64 to arm

[Måns Rullgård]

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.

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

[U-Boot] merge arm64 to arm

[Tom Rini]

-----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-----

[U-Boot] merge arm64 to arm

[Måns Rullgård]

Tom Rini <trini@ti.com> writes:

> 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".

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

[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@ti.com> writes:
> 
>> 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".
> 
> 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-----

[U-Boot] merge arm64 to arm

[Scott Wood]

On Mon, 2013-08-19 at 09:10 -0400, Tom Rini wrote:
> On 08/19/2013 09:01 AM, M?ns Rullg?rd wrote:
> > Tom Rini <trini@ti.com> writes:
> > 
> >> On 08/19/2013 08:32 AM, M?ns Rullg?rd wrote:
> >>> 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.

Probably because there is still quite a bit of similarity to older ARM.
There's more to it than just the ISA, and even that isn't *that* much
more different than x86 versus x86_64.  i960 is a bad analogy.  It's
often possible to turn arm32 asm into arm64 asm with some search and
replace and minor manual fixups.

>   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.

As I noted before, in Linux a bunch of other architectures started with
a separate arch for 64-bit (x86, sparc, ppc...), and all of them
eventually merged.

-Scott

[U-Boot] merge arm64 to arm

[Måns Rullgård]

Scott Wood <scottwood@freescale.com> writes:

> On Mon, 2013-08-19 at 09:10 -0400, Tom Rini wrote:
>> On 08/19/2013 09:01 AM, M?ns Rullg?rd wrote:
>> > Tom Rini <trini@ti.com> writes:
>> > 
>> >> On 08/19/2013 08:32 AM, M?ns Rullg?rd wrote:
>> >>> 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.
>
> Probably because there is still quite a bit of similarity to older ARM.
> There's more to it than just the ISA, and even that isn't *that* much
> more different than x86 versus x86_64.

It is quite a bit more different.  32-bit x86 is a subset of x86_64
where as arm64 is entirely new, if somewhat inspired by 32-bit arm.

> i960 is a bad analogy.  It's often possible to turn arm32 asm into
> arm64 asm with some search and replace and minor manual fixups.

Only if the original uses none of the distinguishing features of ARM
like predicated instructions or variably shifted operands.  Once you
limit yourself to the remaining basic operations, every (RISC)
architecture looks the same.

>>   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.
>
> As I noted before, in Linux a bunch of other architectures started with
> a separate arch for 64-bit (x86, sparc, ppc...), and all of them
> eventually merged.

In those cases, the 64-bitness is merely an extension to the 32-bit
instruction set.  Most of them don't even have a notion of 32-bit vs
64-bit mode of execution.

AArch64 of course shares certain non-ISA aspects with AArch32.  Page
table formats and other architecturally defined system control features
are the same, and code for managing these things should of course be
shared.  Some other features, e.g. exception handling, are different
enough that sharing code is probably difficult.

There is a tendency to see arm64/aarch64 as yet another 64-bit extension
of a 32-bit architecture, which it is not.  Assuming that software
support will or can follow the model used by the others mentioned is
thus a mistake.

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

[U-Boot] merge arm64 to arm

[Tom Rini]

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

On 08/19/2013 01:33 PM, M?ns Rullg?rd wrote:
> Scott Wood <scottwood@freescale.com> writes:
[snip]
>> i960 is a bad analogy.  It's often possible to turn arm32 asm
>> into arm64 asm with some search and replace and minor manual
>> fixups.
> 
> Only if the original uses none of the distinguishing features of
> ARM like predicated instructions or variably shifted operands.
> Once you limit yourself to the remaining basic operations, every
> (RISC) architecture looks the same.
[snip]
> AArch64 of course shares certain non-ISA aspects with AArch32.
> Page table formats and other architecturally defined system control
> features are the same, and code for managing these things should of
> course be shared.  Some other features, e.g. exception handling,
> are different enough that sharing code is probably difficult.
> 
> There is a tendency to see arm64/aarch64 as yet another 64-bit
> extension of a 32-bit architecture, which it is not.  Assuming that
> software support will or can follow the model used by the others
> mentioned is thus a mistake.

We don't have lots of hand-crafted assembly, and what we do, we
largely have split out already into the cpu directories.  I really
think we just need to try this and see how it goes.

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

iQIcBAEBAgAGBQJSElt6AAoJENk4IS6UOR1Wnr0P/jvHsmIm6WecndYXa6aA6BjD
9SSSFzdvwvm7qZShmgu+dwJNPzPVbYXLi+N9BvuTotcl/aVNthNsDI/LQfFQUQwe
8GimYa5OpzHKCqP18CGgGC/egKv6+RnMzxcjFPx3G3BSUzC7iqVmQLv3+5n6uj4h
/f+TqXUDY4ej6htRTH6DmEHK+UMstOATokVuoqQO5Yoezx5fZfCUvPhAcgMnYcuT
VBD1rr/fB+06k3GpZJpUMi3sfGZDc0G9AaVY7kC6dRA1IfSgt8GJi0E+qOe0hdDH
sMNWV1jRtyUj3NXUbngESnOgTlM4rx5eWGhlI4XWmWqTvr8r7wS5fJoEFJEDUHQM
kX2Z7h7Cl9qY1FbrT9HYOghKwVIW8APhNpVcq5YefZx5S44wAn/tQBUr3PD0+oDl
AWc8rL7AtXXNwwGE2qL1sh1rDHBGFi5d7zjlXhdSZO2FOpMqC6k0GsEZ65adVuxH
hJ8zdrkzAQNNaTI+ggctUZP7YEkyWnslRNgBEnNH1IW0X+ChVvyRwkISOVcq2wCB
YYGo5JUs4daQ1VXLeu1ZKD1p9R2ogigTI/wvLl1We2nJvY4uKLxok56T+kKw1fAc
N4RAwiGr9Mu8b/zs21+Tyd6iDdzIfcOvraUsb0cQPHifM4usQMc4c3TKDvnWbj3i
EAMFOVAXA7JteO6JVXRA
=6mM2
-----END PGP SIGNATURE-----

[U-Boot] merge arm64 to arm

[Måns Rullgård]

Tom Rini <trini@ti.com> writes:

> On 08/19/2013 01:33 PM, M?ns Rullg?rd wrote:
>> Scott Wood <scottwood@freescale.com> writes:
> [snip]
>>> i960 is a bad analogy.  It's often possible to turn arm32 asm
>>> into arm64 asm with some search and replace and minor manual
>>> fixups.
>>
>> Only if the original uses none of the distinguishing features of
>> ARM like predicated instructions or variably shifted operands.
>> Once you limit yourself to the remaining basic operations, every
>> (RISC) architecture looks the same.
> [snip]
>> AArch64 of course shares certain non-ISA aspects with AArch32.
>> Page table formats and other architecturally defined system control
>> features are the same, and code for managing these things should of
>> course be shared.  Some other features, e.g. exception handling,
>> are different enough that sharing code is probably difficult.
>>
>> There is a tendency to see arm64/aarch64 as yet another 64-bit
>> extension of a 32-bit architecture, which it is not.  Assuming that
>> software support will or can follow the model used by the others
>> mentioned is thus a mistake.
>
> We don't have lots of hand-crafted assembly, and what we do, we
> largely have split out already into the cpu directories.  I really
> think we just need to try this and see how it goes.

Fine, let's see what it ends up looking like.

That said, please consider naming things in a way that armv8 does not
imply 64-bit.

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

[U-Boot] merge arm64 to arm

[Tom Rini]

On Mon, Aug 19, 2013 at 08:50:24PM +0100, M?ns Rullg?rd wrote:
> Tom Rini <trini@ti.com> writes:
> 
> > On 08/19/2013 01:33 PM, M?ns Rullg?rd wrote:
> >> Scott Wood <scottwood@freescale.com> writes:
> > [snip]
> >>> i960 is a bad analogy.  It's often possible to turn arm32 asm
> >>> into arm64 asm with some search and replace and minor manual
> >>> fixups.
> >>
> >> Only if the original uses none of the distinguishing features of
> >> ARM like predicated instructions or variably shifted operands.
> >> Once you limit yourself to the remaining basic operations, every
> >> (RISC) architecture looks the same.
> > [snip]
> >> AArch64 of course shares certain non-ISA aspects with AArch32.
> >> Page table formats and other architecturally defined system control
> >> features are the same, and code for managing these things should of
> >> course be shared.  Some other features, e.g. exception handling,
> >> are different enough that sharing code is probably difficult.
> >>
> >> There is a tendency to see arm64/aarch64 as yet another 64-bit
> >> extension of a 32-bit architecture, which it is not.  Assuming that
> >> software support will or can follow the model used by the others
> >> mentioned is thus a mistake.
> >
> > We don't have lots of hand-crafted assembly, and what we do, we
> > largely have split out already into the cpu directories.  I really
> > think we just need to try this and see how it goes.
> 
> Fine, let's see what it ends up looking like.
> 
> That said, please consider naming things in a way that armv8 does not
> imply 64-bit.

Agreed, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130819/a6962f1a/attachment.pgp>

[U-Boot] merge arm64 to arm

[Scott Wood]

On Mon, 2013-08-19 at 18:33 +0100, M?ns Rullg?rd wrote:
> Scott Wood <scottwood@freescale.com> writes:
> 
> > On Mon, 2013-08-19 at 09:10 -0400, Tom Rini wrote:
> >> On 08/19/2013 09:01 AM, M?ns Rullg?rd wrote:
> >> > Tom Rini <trini@ti.com> writes:
> >> > 
> >> >> On 08/19/2013 08:32 AM, M?ns Rullg?rd wrote:
> >> >>> 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.
> >
> > Probably because there is still quite a bit of similarity to older ARM.
> > There's more to it than just the ISA, and even that isn't *that* much
> > more different than x86 versus x86_64.
> 
> It is quite a bit more different.  32-bit x86 is a subset of x86_64

It is not completely a subset.  Various segmentation features, some
obscure instructions, vm86 mode, etc. were dropped.

> where as arm64 is entirely new, if somewhat inspired by 32-bit arm.

It appears heavily inspired to me.

> > i960 is a bad analogy.  It's often possible to turn arm32 asm into
> > arm64 asm with some search and replace and minor manual fixups.
> 
> Only if the original uses none of the distinguishing features of ARM
> like predicated instructions or variably shifted operands.

I'm referring specifically to the experience we had in doing this for
arm64 asm code in U-Boot, which uses these infrequently enough that it
falls under "minor manual fixups".

> Once you limit yourself to the remaining basic operations, every (RISC)
> architecture looks the same.

Some are more "the same" than others. :-P

Converting to sparc, ppc, or mips code would have been much more of a
manual process.

In any case, just how similar the asm is isn't really relevant - they're
different enough that we'd keep the 64-bit asm in separate files (this
is true of x86/x86-64 as well).

> >>   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.
> >
> > As I noted before, in Linux a bunch of other architectures started with
> > a separate arch for 64-bit (x86, sparc, ppc...), and all of them
> > eventually merged.
> 
> In those cases, the 64-bitness is merely an extension to the 32-bit
> instruction set.  Most of them don't even have a notion of 32-bit vs
> 64-bit mode of execution.
> 
> AArch64 of course shares certain non-ISA aspects with AArch32.  Page
> table formats and other architecturally defined system control features
> are the same, and code for managing these things should of course be
> shared.  Some other features, e.g. exception handling, are different
> enough that sharing code is probably difficult.

In the patches posted so far nothing is shared.  Using the same arch
directory will lead to these things being shared by default, and we only
need to fix up the places where things differ.  If some day we manage to
move enough stuff out of arch that it's really mostly just asm code,
with things like page table handling moved out to a place that is easily
shared between arches, then it might make sense to split.  We're a long
way from that, though.

-Scott

[U-Boot] merge arm64 to arm

[FengHua]

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?


Regards.
David

[U-Boot] merge arm64 to arm

[Måns Rullgård]

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.

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

[U-Boot] merge arm64 to arm

[FengHua]

> -----????-----
> ???: "M?ns Rullg?rd" <mans@mansr.com>
> ????: 2013?8?17? ???
> ???: FengHua <fenghua@phytium.com.cn>
> ??: u-boot at lists.denx.de, trini at ti.com, scottwood at freescale.com
> ??: Re: merge arm64 to arm
> 
> 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.
> 
> -- 
> M?ns Rullg?rd
> mans at mansr.com

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.

[U-Boot] merge arm64 to arm

[Tom Rini]

On Sat, Aug 17, 2013 at 10:32:43PM +0800, FengHua wrote:
> 
> 
> 
> > -----????????????-----
> > ?????????: "M??ns Rullg??rd" <mans@mansr.com>
> > ????????????: 2013???8???17??? ?????????
> > ?????????: FengHua <fenghua@phytium.com.cn>
> > ??????: u-boot at lists.denx.de, trini at ti.com, scottwood at freescale.com
> > ??????: Re: merge arm64 to arm
> > 
> > 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.
> > 
> > -- 
> > M??ns Rullg??rd
> > mans at mansr.com
> 
> 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.

Exactly.  Most things will end up in arch/arm/cpu/armv8/ and we won't
have to duplicate the "hook the arch up with the rest of U-Boot" code,
which is C anyhow, for the most part.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130817/91d2286c/attachment.pgp>

[U-Boot] merge arm64 to arm

[Måns Rullgård]

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.

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

[U-Boot] merge arm64 to arm

[FengHua]

> -----????-----
> ???: "M?ns Rullg?rd" <mans@mansr.com>
> ????: 2013?8?17? ???
> ???: FengHua <fenghua@phytium.com.cn>
> ??: "M?ns Rullg?rd" <mans@mansr.com>, trini <trini@ti.com>, u-boot <u-boot@lists.denx.de>, "albert.u.boot" <albert.u.boot@aribaud.net>, scottwood <scottwood@freescale.com>
> ??: Re: merge arm64 to arm
> 
> 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.

> -- 
> M?ns Rullg?rd
> mans at mansr.com

[U-Boot] merge arm64 to arm

[Scott Wood]

On Sat, 2013-08-17 at 15:55 +0100, M?ns Rullg?rd wrote:
> 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.

Yes, the asm files should be suffixed with "64" rather than "_v8".

-Scott