[LEDE-DEV] Adding new targets/subtargets

Philip Prindeville philipp_subx at redfish-solutions.com
Sat Dec 31 17:23:38 PST 2016


> On Dec 31, 2016, at 9:32 AM, Yousong Zhou <yszhou4tech at gmail.com> wrote:
> 
> On 31 December 2016 at 06:13, Philip Prindeville
> <philipp_subx at redfish-solutions.com> wrote:
>> 
>>> On Dec 29, 2016, at 7:46 PM, Yousong Zhou <yszhou4tech at gmail.com> wrote:
>>> 
>>> On 30 December 2016 at 03:29, Philip Prindeville
>>> <philipp_subx at redfish-solutions.com> wrote:
>>>> On Dec 28, 2016, at 7:57 PM, Yousong Zhou <yszhou4tech at 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




More information about the Lede-dev mailing list