[LEDE-DEV] [OpenWrt-Devel] [PATCH] add support for OCTEON TX target

Sat Feb 17 04:44:49 PST 2018

On 02/15/2018 06:42 PM, Tim Harvey wrote:
> On Tue, Feb 13, 2018 at 12:51 PM, Hauke Mehrtens <hauke at hauke-m.de> wrote:
>> On 02/13/2018 09:46 PM, Hauke Mehrtens wrote:
>>> Hi Tim,
>>>
>>> sorry that I haven't reviewed this earlyer, but now I saw some problems,
>>> see my comments inline.
>>>
>>> Can you please create a follow up patch based on current master branch.
> 
> Hauke,
> 
> Thanks for your review! Looks like John committed already (thanks
> John!) but I will send followup patches for the things you point out.
> 
> comments/questions below;
> 
> <snip>
>>>> diff --git a/target/linux/octeontx/Makefile b/target/linux/octeontx/Makefile
>>>> new file mode 100644
>>>> index 0000000..bbe8149
>>>> --- /dev/null
>>>> +++ b/target/linux/octeontx/Makefile
>>>> @@ -0,0 +1,27 @@
>>>> +#
>>>> +# Copyright (C) 2018 OpenWrt.org
>>>> +#
>>>> +# This is free software, licensed under the GNU General Public License v2.
>>>> +# See /LICENSE for more information.
>>>> +#
>>>> +include $(TOPDIR)/rules.mk
>>>> +
>>>> +ARCH:=aarch64
>>>> +BOARD:=octeontx
>>>> +BOARDNAME:=Octeon-TX
>>>> +FEATURES:=targz pcie gpio rtc usb
>>>
>>> I think you should define fpu here, but arm64 anyway has a fpu.
>>>
>>>> +CFLAGS:=-Os -pipe -fno-caller-saves
>>>
>>> You should not define CFLAGS for the toolchain as this will also leak
>>> into other targets if they share the same toolchain.
>>>
>>> Can you try to remove the CFLAGS setting if it still works?
>>> The build system will then set it to "-Os -pipe -mcpu=generic"
> 
> I'll add fpu and remove CFLAGS after testing.
> 
>>>
>>>> +
>>>> +MAINTAINER:=Tim Harvey <tharvey at gateworks.com>
>>>> +
>>>> +KERNEL_PATCHVER:=4.14
>>>> +
>>>> +define Target/Description
>>>> +    Build images for Octeon-TX CN80XX/CN81XX based boards
>>>> +endef
>>>> +
>>>> +include $(INCLUDE_DIR)/target.mk
>>>> +
>>>> +KERNELNAME:=Image
>>>> +
>>>> +$(eval $(call BuildTarget))
>>> ....
>>>> diff --git a/target/linux/octeontx/config-4.14 b/target/linux/octeontx/config-4.14
>>>> new file mode 100644
>>>> index 0000000..97d0cc6
>>>> --- /dev/null
>>>> +++ b/target/linux/octeontx/config-4.14
>>>> @@ -0,0 +1,670 @@
>>> .....
>>>> +# CONFIG_CRYPTO_SHA512_ARM64 is not set
>>>> +CONFIG_CRYPTO_SIMD=y
>>>> +CONFIG_CRYPTO_WORKQUEUE=y
>>>> +CONFIG_DCACHE_WORD_ACCESS=y
>>>> +# CONFIG_DEBUG_ALIGN_RODATA is not set
>>>> +# CONFIG_DEBUG_BLK_CGROUP is not set
>>>> +CONFIG_DEBUG_INFO=y
>>>
>>> Is this needed by default?
> 
> no - will remove
> 
>>>
>>>> +CONFIG_DEFAULT_IOSCHED="noop"
>>>> +CONFIG_DEFAULT_NOOP=y
>>>> +# CONFIG_DEVPORT is not set
>>>> +CONFIG_DEVTMPFS=y
>>>> +CONFIG_DEVTMPFS_MOUNT=y
>>>> +CONFIG_DMADEVICES=y
>>>> +CONFIG_DMA_CMA=y
>>>> +CONFIG_DMA_ENGINE=y
>>>> +# CONFIG_DMA_NOOP_OPS is not set
>>>> +CONFIG_DMA_OF=y
>>>> +CONFIG_DMA_SHARED_BUFFER=y
>>>> +# CONFIG_DMA_VIRT_OPS is not set
>>>> +CONFIG_DNS_RESOLVER=y
>>>> +# CONFIG_DRM_LIB_RANDOM is not set
>>>> +CONFIG_DTC=y
>>>> +CONFIG_DT_IDLE_STATES=y
>>>> +CONFIG_EDAC=y
>>>> +# CONFIG_EDAC_DEBUG is not set
>>>> +CONFIG_EDAC_LEGACY_SYSFS=y
>>>> +CONFIG_EDAC_SUPPORT=y
>>>> +CONFIG_EDAC_THUNDERX=y
>>>> +# CONFIG_EDAC_XGENE is not set
>>>> +CONFIG_EEPROM_AT24=y
>>>> +# CONFIG_EVM is not set
>>>> +CONFIG_EXT2_FS=y
>>>> +CONFIG_EXT3_FS=y
>>>
>>> Please activate ext2 and 3 support in ext4 instead.
> 
> done - I actually am removing all EXT static as I believe F2FS is
> preferred for MMC.
> 
>>>
>>>> +# CONFIG_EXT3_FS_POSIX_ACL is not set
>>>> +# CONFIG_EXT3_FS_SECURITY is not set
>>>> +CONFIG_EXT4_FS=y
>>>> +CONFIG_EXT4_FS_POSIX_ACL=y
>>>> +# CONFIG_F2FS_CHECK_FS is not set
>>>> +CONFIG_F2FS_FS=y
>>>> +# CONFIG_F2FS_FS_SECURITY is not set
>>>> +CONFIG_F2FS_FS_XATTR=y
>>>> +CONFIG_F2FS_STAT_FS=y
>>> ...
>>>
>>> You should run "make kernel_oldconfig" to refresh the configuration.
> 
> I did and it didn't change target/linux/octeontx/config-4.14?

I think this was a false alarm.

> 
>>
>> Please do not deactivate all the CONFIG_NET_VENDOR* options.
> 
> That makes sense in general as they are all enabled in
> target/linux/generic/config-4.14 to allow inclusion of modules. I do
> see there are several targets that undef them like I did.

I think that is a bad practice.

> I did find that undefining them prompts for QCA7000_UART - I'll submit
> a patch that undefs that in target/linux/generic/config-4.14.

Yes add that to target/linux/generic/config-4.14

> Are there a set of general rules when preparing new target kernel
> configs or updating kernel configs for new kernel versions?

I think there are no written rules available.

>>> There is also something missing in this configuration or in the generic
>>> one, see this error from the build bot:
>>> http://phase1.builds.lede-project.org/builders/octeontx%2Fgeneric/builds/0/steps/kmods/logs/stdio
>>>
>>> Please test compile it with this configuration:
>>> CONFIG_TARGET_octeontx=y
>>> CONFIG_TARGET_octeontx_Default=y
>>> CONFIG_TARGET_BOARD="octeontx"
>>> CONFIG_ALL_KMODS=y
>>>
>>
> 
> I haven't encountered any issues with those configs. I'm not quite
> clear how to reproduce the failure from
> http://phase1.builds.lede-project.org/builders/octeontx%2Fgeneric/builds/0/steps/kmods/logs/stdio.

I fixes that problem in this commit:
https://git.openwrt.org/970cbfc3074daa177c6d4868d1a94e70906d2568

After doing so the build ran into the next problem:
http://phase1.builds.lede-project.org/builders/octeontx%2Fgeneric/builds/12/steps/pkgbuild/logs/stdio

When you place this into your .config file:
CONFIG_TARGET_octeontx=y
CONFIG_TARGET_octeontx_Default=y
CONFIG_TARGET_BOARD="octeontx"
CONFIG_ALL_KMODS=y

Then run "make defconfig" and build you should run into this problem.
This should result in the same kernel build as the build bots are doing.

It could be that you have to remove this folder here first:
build_dir/target-aarch64_generic_musl/linux-octeontx/linux-4.14.18/

Hauke