All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] merge arm64 to arm
Date: Mon, 19 Aug 2013 08:20:19 -0400	[thread overview]
Message-ID: <52120D83.2070105@ti.com> (raw)
In-Reply-To: <A1A6EA40F8503D48BB002B42BD65974E0A114A73@039-SN2MPN1-013.039d.mgd.msft.net>

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

       reply	other threads:[~2013-08-19 12:20 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <A1A6EA40F8503D48BB002B42BD65974E0A114A73@039-SN2MPN1-013.039d.mgd.msft.net>
2013-08-19 12:20 ` Tom Rini [this message]
2013-08-19 12:32   ` [U-Boot] merge arm64 to arm Måns Rullgård
2013-08-19 12:53     ` Tom Rini
2013-08-19 13:01       ` Måns Rullgård
2013-08-19 13:10         ` Tom Rini
2013-08-19 16:55           ` Scott Wood
2013-08-19 17:33             ` Måns Rullgård
2013-08-19 17:52               ` Tom Rini
2013-08-19 19:50                 ` Måns Rullgård
2013-08-19 19:53                   ` Tom Rini
2013-08-19 18:08               ` Scott Wood
2013-08-17  4:54 FengHua
2013-08-17 11:35 ` Måns Rullgård
2013-08-17 14:32   ` FengHua
2013-08-17 14:52     ` Tom Rini
2013-08-17 14:55     ` Måns Rullgård
2013-08-18  1:03       ` FengHua
2013-08-19 16:34       ` Scott Wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52120D83.2070105@ti.com \
    --to=trini@ti.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.