-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/19/2013 08:32 AM, Måns Rullgård wrote: > Tom Rini <tr...@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 <feng...@phytium.com.cn> writes: >>>>> >>>>>>> FengHua <feng...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
