> On Dec 31, 2016, at 9:32 AM, Yousong Zhou <yszhou4t...@gmail.com> wrote:
>
> On 31 December 2016 at 06:13, Philip Prindeville
> <philipp_s...@redfish-solutions.com> wrote:
>>
>>> On Dec 29, 2016, at 7:46 PM, Yousong Zhou <yszhou4t...@gmail.com> wrote:
>>>
>>> On 30 December 2016 at 03:29, Philip Prindeville
>>> <philipp_s...@redfish-solutions.com> wrote:
>>>> On Dec 28, 2016, at 7:57 PM, Yousong Zhou <yszhou4t...@gmail.com> wrote:
>>>>
>>>> The x86/64/config-default is missing the following switches:
>>>>
>>>> CONFIG_MCORE2=y
>>>> CONFIG_MDIO=y
>>>> CONFIG_X86_USE_PPRO_CHECKSUM=y
>>>>
>>>> otherwise they should be identical (unless I’ve overlooked other values
>>>> which are needed).
>>>>
>>>
>>> Well, it seems that the built kernel with CONFIG_MCORE2 set may not
>>> run on other older x86_64 cpus as it will enable -march=core2
>>> optimisation flag. "make kernel_menuconfig" can be used to select
>>> those symbols. But I think they are not appropriate to go into
>>> x86/64 subtarget, yet adding another subtarget for such minor diff
>>> seems overkill.
>>
>>
>> That actually might not be optimized enough. The appliance that I’m
>> targeting does a lot of crypto, so enabling the Xeon-specific AES operations
>> should help a lot with AES-CBC and AES-EBC sessions.
>>
>
> Well, I think the build system should be flexible enough to allow you
> to do such customisations.
I’m sure it is. The question is will it be easy (straightforward) or
complicated?
>>>
>>> CPU_TYPE is mainly used for forming compiler optimisation flags. It's
>>> empty for x86_64 because LEDE does not have specific flags for the
>>> arch yet.
>>>
>>> BTW. now sure how OpenWrt repo goes these days, but I guess build
>>> system of LEDE is likely to has received more care than the OpenWrt
>>> one. So it's worth a try.
>>
>>
>>
>> How does CPU_TYPE end up affecting the CFLAGS that are used to compile both
>> target/ and packages/ ? The settings for CONFIG_TARGET_OPTIMIZATION seem
>> pretty generic.
>
> Take a look at include/target.mk, CPU_CFLAGS_$(CPU_TYPE) will form
> part of the default cflags and these are used to do release builds.
> CONFIG_TARGET_OPTIMIZATION can be used to override that when you are
> building on your own.
Okay, that’s curious.
There’s a test for “ifeq ($(ARCH),i386) … endif” but I don’t see code for
x86_64. Do we need something like:
diff --git a/include/target.mk b/include/target.mk
index 8211ba0..5e3aae6 100644
--- a/include/target.mk
+++ b/include/target.mk
@@ -227,6 +227,13 @@ ifeq ($(DUMP),1)
CPU_CFLAGS_pentium4 = -march=pentium4
CPU_CFLAGS_geode = -march=geode -mmmx -m3dnow
endif
+ ifeq ($(ARCH),x86_64)
+ CPU_TYPE ?= k8
+ CPU_CFLAGS_k8 = -march=k8
+ CPU_CFLAGS_core2 = -march=core2+crypto
+ CPU_CFLAGS_i7 = -march=corei7
+ CPU_CFLAGS_atom64 = -march=atom
+ endif
ifneq ($(findstring arm,$(ARCH)),)
CPU_TYPE ?= xscale
CPU_CFLAGS_arm920t = -march=armv4t -mtune=arm920t
>
>>>>>> Is there any unofficial documentation (i.e. not on the wiki) about how
>>>>>> to go about adding platforms?
>>>>>>
>>>>>> There’s a wiki entry on “adding a new device” but doesn’t seem to be
>>>>>> applicable to what I’m doing.
>>>>>>
>>>>>> Any pointers are appreciated.
>>>>>
>>>>> Adding target/subtarget does not happen very often, but the build
>>>>> system changes a lot in various aspects. Probably nobody bothers to
>>>>> add such doc. But we can always consult git log/mail history to see
>>>>> how previous ones are added.
>>>>>
>>>>> yousong
>>>>
>>>>
>>>> Actually, all the subtargets have been purged, from what I can tell. I
>>>> don’t see any subtargets (just profiles?) so I don’t even know if the
>>>> subtarget machinery is still intact or not.
>>>>
>>>> -Philip
>>>>
>>>
>>> Hmm, not sure I understand your concern about this one. Subtarget
>>> machinery is certainly still there as all these
>>> x86/{generic,64,legacy} subtargets at least still build.
>>>
>>> yousong
>>
>>
>> I noticed that in Openwrt a lot of the x86 subtargets (alix, geos, net5501)
>> had gone away (well, been combined into a generic “geode” image).
>>
>> -Philip
>>
>
> I can only guess it's very likely for the purpose of saving buildbot
> resources. But I never played those subtargets myself and have no
> idea whether they still work (they should though)
>
> yousong
Pruning useful subtargets to solve a buildbot resource shortage seems like
taking a sledgehammer to kill a fly.
Why not instead just add a profile attribute like:
BUILDBOT_BUILD_ME:=no
Whether it’s still useful to *build* a subtarget is a different question that
whether it’s still useful (from a pedagogical perspective) to *keep* a
subtarget in the SCM… and these questions shouldn’t be conflated.
-Philip
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
