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:
>>
>> On 29 December 2016 at 10:04, Philip Prindeville
>> <philipp_s...@redfish-solutions.com> wrote:
>>> I wanted to add a new target for x86, or possibly several.
>>>
>>> I have an immediate need for an optimized build to run on Xeon-based 1U
>>> servers for a project that I’m working on. My work in progress is here:
>>>
>>> https://github.com/pprindeville/openwrt/commit/67a11380ed69351e320a410ec18c04e62fb548d3
>>>
>>> but I’m not clear on what ARCH_PACKAGES is or when it’s used… or why only
>>> target/linux/x86/ seems to use it.
>>>
>>> Looked on the Wiki but there doesn’t seem to be a blow-by-blow
>>> decomposition of what a target directory looks like.
>>>
>>> Also, I wanted to build targets with virtio drivers (net and scsi) for
>>> running on Parallels or KVM/Qemu… so that none-platform stuff could be
>>> tested, possibly in an automated testing environment.
>>
>> Very likely you can just add xeon-specific bits to x86/64 subtarget.
>> I think it's intended to be both "modern" and "generic". It already
>> contains various virtio device drivers and we even have qemu-2.6.2
>> with kvm support ready for it.
>
>
> 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.
>
>>
>> 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.
>
>
>>>
>>> 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
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
