[LEDE-DEV] Adding new targets/subtargets

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




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

On 31 December 2016 at 20:23, Philip Prindeville
<philipp_subx@redfish-solutions.com> wrote:
>
>> On Dec 31, 2016, at 9:32 AM, Yousong Zhou <yszhou4tech@gmail.com> wrote:
>>
>> On 31 December 2016 at 06:13, Philip Prindeville
>> <philipp_subx@redfish-solutions.com> wrote:
>>>
>>> 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


If this is going to be the road we travel down (I'm bikeshedding here)
wouldn't a  BUILDBOT_INTERVAL:=daily/3d/7d/14d make more sense?

We have more then a few full on targets that for the most part are
much less popular then say ar71xx.

> On Jan 1, 2017, at 8:34 AM, Weedy <weedy2887@gmail.com> wrote:
> 
> On 31 December 2016 at 20:23, Philip Prindeville
> <philipp_subx@redfish-solutions.com> wrote:
>> 
>> 
>> 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
> 
> 
> If this is going to be the road we travel down (I'm bikeshedding here)
> wouldn't a  BUILDBOT_INTERVAL:=daily/3d/7d/14d make more sense?
> 
> We have more then a few full on targets that for the most part are
> much less popular then say ar71xx.


That’s an even better idea.

-Philip

Hi,

> Pruning useful subtargets to solve a buildbot resource shortage seems
> like taking a sledgehammer to kill a fly.

Saving resources was only one of the considerations to cut back the
amount of sub targets.

The introduction of per-device/per-profile rootfs support in LEDE
allowed us to build images with a different package selection per device
so sub targets that merely selected different kmods become completely
needless.

> Why not instead just add a profile attribute like:
> 
> BUILDBOT_BUILD_ME:=no

Because we want to have complete coverage. Experience has shown that
untested subtargets quickly become stale and broken.

~ Jo

Hi,

> If this is going to be the road we travel down (I'm bikeshedding here)
> wouldn't a  BUILDBOT_INTERVAL:=daily/3d/7d/14d make more sense?

it wouldn't as buildbot activity is distributed randomly and the master
currently lacks suitable scheduling logic to implement such behavior.

Besides that, we're incrementally building anyway already means we'd not
save any resources doing that while adding a huge amount of complexity
to the build scheduling logic.

> We have more then a few full on targets that for the most part are
> much less popular then say ar71xx.

~ Jo

> On Jan 2, 2017, at 10:08 AM, Jo-Philipp Wich <jo@mein.io> wrote:
> 
>> Why not instead just add a profile attribute like:
>> 
>> BUILDBOT_BUILD_ME:=no
> 
> Because we want to have complete coverage. Experience has shown that
> untested subtargets quickly become stale and broken.
> 
> ~ Jo


Then we need more buildbot resources, not fewer targets…

-Philip

> On Dec 31, 2016, at 6:23 PM, Philip Prindeville <philipp_subx@redfish-solutions.com> wrote:
> 
> 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


Actually, I tested this and it doesn’t quite work.

Tried to do some digging:


philip@ubuntu:~/bertram/bmu-philip/openwrt$ make -j1 target/linux/clean V=s DUMP=1
/bin/sh: 1: mindepth: not found
Collecting package info: doneing...
/bin/sh: 1: mindepth: not found
Collecting target info: doneing...
make: *** prereq: No such file or directory.  Stop.
make[4]: *** [prereq] Error 2
make[3]: *** [target/linux/prereq] Error 2
make[2]: *** [/home/philip/bertram/bmu-philip/openwrt/staging_dir/target-_-/stamp/.target_prereq] Error 2
make[1]: *** [prereq] Error 2
make: *** [target/linux/clean] Error 2
philip@ubuntu:~/bertram/bmu-philip/openwrt$


Okay, so that didn’t work…  So I try to write out $(ARCH) from inside include/target.mk and it looks like it’s set to “arm” even though I’m building the x86/64 target.


philip@ubuntu:~/bertram/bmu-philip/openwrt$ grep '^CONFIG_' .config | head
CONFIG_MODULES=y
CONFIG_HAVE_DOT_CONFIG=y
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_64=y
CONFIG_TARGET_x86_64_Generic=y
CONFIG_HAS_SUBTARGETS=y
CONFIG_TARGET_BOARD="x86"
CONFIG_TARGET_SUBTARGET="64"
CONFIG_TARGET_ARCH_PACKAGES="x86_64"
CONFIG_DEFAULT_TARGET_OPTIMIZATION="-Os -pipe"
philip@ubuntu:~/bertram/bmu-philip/openwrt$


so I don’t know how to go about root-causing this.

Is there an easy way to see what the target-related settings are from within include/target.mk?

Maybe add a target/xyzzy which writes to stdout all the settings?

-Philip