> 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.
>
>>
>>>
>>> I cannot find direct reference to ARCH_PACKAGES in target/ dir. I
>>> think it's a string intended to represent the arch of packages built
>>> for current target/subtarget. Previously in OpenWrt, we build
>>> packages like pppd separately for targets like ramips and ar71xx, even
>>> though they are of the same arch "mips_24kc" (there was a time ar71xx
>>> was optimized for 34kc though). Now these packages are arch-specific
>>> and will reside in dir bin/packages/<CONFIG_TARGET_ARCH_PACKAGES>.
>>
>> Doing the following:
>>
>> openwrt$ grep -r -n -E -e ‘\<ARCH\>' -e ‘\<ARCH_PACKAGES\>’ include/ target/
>> include/image.mk:122: mkimage -A $(ARCH) -O linux -T kernel -C $(1) -a
>> $(2) -e $(3) \
>
> <snip>
>
>>
>>
>> so it seems to be used for a few different things including image naming.
>> ARCH also seems to be overloaded, from what I can tell…
>>
>> ARCH_SUFFIX is taken from CONFIG_CPU_TYPE, but in my setup that value seems
>> to have been set to “ “ which I can’t say I understand.
>>
>
> 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.
>
>>
>>
>>>>
>>>> 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
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
