Tom Rini <tr...@ti.com> writes: > 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".
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 m...@mansr.com _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
