[BPI-R2] Kernel Development

Maybe “” have to be <>…afaik quotes referencing header in same directory and <> in include-path

Could you try to build with builddir enabled? Cause i currently run out-of time :frowning:

… will try to clone your latest GIT and give it a shot, however not sure I will do much on it tonight anymore, but will get back to you as soon as I found something.

And it is a big mess. This driver is a big mess :-). As it often happens when we’ve got a driver that was written by vendor targeting specific Adnroid version without any control/review from mainline kernel devs.

@lexa2 / @sisyphos Have you reproduced the build-errors i’ve got with 5.4-merged? Or is my setup still unclear?

I can’t seem to get ip over dhcp after few reboots.

Is this what you wanted me to test?

Maybe I have to reconfigure it again?

Can you show “ip a”, ethtool of the affected interfaces and full bootlog?

Sorry, @frank-w just cloned the image so haven’t got to the compile yet

I will get it tomorrow.

After fixing my build environment I am now down that it miss the include file:

pi@ububuild:~/BPI-R2-4.14$ cat build.log 
../drivers/misc/mediatek/btif/common/mtk_btif.c:37:10: fatal error: btif_pub.h: No such file or directory
 #include "btif_pub.h"
          ^~~~~~~~~~~~
compilation terminated.
make[6]: *** [drivers/misc/mediatek/btif/common/mtk_btif.o] Error 1
make[5]: *** [drivers/misc/mediatek/btif/common] Error 2
make[4]: *** [drivers/misc/mediatek/btif] Error 2
make[3]: *** [drivers/misc/mediatek] Error 2
make[2]: *** [drivers/misc] Error 2
make[1]: *** [drivers] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [sub-make] Error 2

Already started importing the build in my IDE and it seems the IDE has no issue to resolve the link to the include file. Will have a deeper look…

A bit too late actually but I think I might have something.

mtk_btif.c > references inc/mtk_btif.h > references ../plat_inc/btif_pub.h > which itself is referenced in mtk_btif.c

so might be a circular dependency that is messing things up, because running the compile with

./build > complete.log

reveals that the entry point for the error is one step before:

  ccache arm-linux-gnueabihf-gcc -Wp,-MD,drivers/misc/mediatek/btif/common/.mtk_btif.o.d  -nostdinc -isystem /usr/lib/gcc-cross/arm-linux-gnueabihf/7/include -I../arch/arm/include -I./arch/arm/include/generated -I../include -I./include -I../arch/arm/include/uapi -I./arch/arm/include/generated/uapi -I../include/uapi -I./include/generated/uapi -include ../include/linux/kconfig.h -include ../include/linux/compiler_types.h -D__KERNEL__ -mlittle-endian -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Wno-format-security -std=gnu89 -fno-dwarf2-cfi-asm -fno-omit-frame-pointer -mapcs -mno-sched-prolog -fno-ipa-sra -mabi=aapcs-linux -mfpu=vfp -marm -Wa,-mno-warn-deprecated -D__LINUX_ARM_ARCH__=7 -march=armv7-a -msoft-float -Uarm -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -O2 --param=allow-store-data-races=0 -Wframe-larger-than=1024 -fstack-protector-strong -Wno-unused-but-set-variable -Wimplicit-fallthrough -Wno-unused-const-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-var-tracking-assignments -g -pg -fno-inline-functions-called-once -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -fno-strict-overflow -fno-merge-all-constants -fmerge-constants -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -Werror -I../drivers/misc/mediatek/include/mt-plat/ -I../drivers/misc/mediatek/include/mt-plat/mt7623/include -I../arch/arm/mach-mt7623/include/mach -I../drivers/misc/mediatek/include/mt-plat -Idrivers/misc/mediatek/btif/common/inc -Idrivers/misc/mediatek/btif/common/plat_inc -I ../drivers/misc/mediatek/btif/common -I ./drivers/misc/mediatek/btif/common    -DKBUILD_BASENAME='"mtk_btif"' -DKBUILD_MODNAME='"btif"' -c -o drivers/misc/mediatek/btif/common/mtk_btif.o ../drivers/misc/mediatek/btif/common/mtk_btif.c
In file included from ../drivers/misc/mediatek/btif/common/mtk_btif.c:40:0:
../drivers/misc/mediatek/btif/common/inc/mtk_btif.h:37:10: fatal error: btif_pub.h: No such file or directory
 #include "btif_pub.h"
          ^~~~~~~~~~~~
compilation terminated.
../scripts/Makefile.build:265: recipe for target 'drivers/misc/mediatek/btif/common/mtk_btif.o' failed
../scripts/Makefile.build:509: recipe for target 'drivers/misc/mediatek/btif/common' failed
../scripts/Makefile.build:509: recipe for target 'drivers/misc/mediatek/btif' failed
../scripts/Makefile.build:509: recipe for target 'drivers/misc/mediatek' failed
../scripts/Makefile.build:509: recipe for target 'drivers/misc' failed
make[6]: *** [drivers/misc/mediatek/btif/common/mtk_btif.o] Error 1
make[5]: *** [drivers/misc/mediatek/btif/common] Error 2
make[4]: *** [drivers/misc/mediatek/btif] Error 2
make[3]: *** [drivers/misc/mediatek] Error 2
make[2]: *** [drivers/misc] Error 2
/home/pi/BPI-R2-4.14/Makefile:1649: recipe for target 'drivers' failed
make[1]: *** [drivers] Error 2
make[1]: *** Waiting for unfinished jobs....

It’s mid-week so hadn’t had a chance to take a good peek at it. Been busy with doing stuff at - you guessed it - main place of employment. :frowning:

Reproduced it. I’m wondering is it a first time you attempt to do an out-of-tree build for kernel tree with wifi driver?

Quick fix: replace all occurrences of “-I$(src)” in driver makefiles with “-I$(srctree)/$(src)”.

TL/DR: Problem happens due to $(src) being always a relative path to the location of the currently processed makefile from the source tree root. Thus produced C preprocessor search path directives end up to contain relative paths too. It works OK for in-tree build as something like ./drivers/misc/mediatek/inc is resolved to the expected in-tree directory containing required includes. But it does not work for out-of-tree build as PWD at compile time equals to KBUILD_OUTPUT and you won’t expect that required include files are available in there. It means that for include paths you should use -I$(srctree)/$(src)/... instead or simple -I$(src)/.... Constructs like this are in process of being updated all over the kernel - you may want to check the output of this command pipeline:
# git grep 'cflags-y' | grep -- '-I' | grep -- '$(src)'

1 Like

It is first time i do this (regardless of wifi-driver)…to take care of my ssd i want to build in ram only.

It seems you have not done this before :slight_smile: or is this already fixed in one of your last commits?

Yes, I wasn’t using out of tree build for linux kernel as traditionally it always was an in-tree build and my devops experience with other projects tell that moving from in tree to out of tree builds is an error-prone process - which you don’t want when you’re building such a significant thing as a kernel.

My PR to your 5.4-wifi branch had been updated with this commit:

1 Like

thanks, tried adding your commits to my merged tree, but ran into “no space left” and “echo: I/O error”…seems like 2G ramdisk is not enough :stuck_out_tongue: after resize ramdisk i see build is consuming 2.2G :wink: build was working so far

updated 5.4-merged and uploaded compiled kernel here

2 Likes

What is new in this build?

I have included lexa2s patches and upgraded to rc5

I mean in regards to wifi :stuck_out_tongue: BTW that was a quick response. Thanks

Reason for asking: If there is significant changes then maybe I will make a new build for arch.

You should use this for testing wifi only…

Two main highlights:

  1. Fixed debugging functionality so it is possible to compile driver with -DDBG=1 patched into Makefile and enable dynamic printk for various prints in driver code. Without fixes debug building was broken.
  2. Fixed building as a module. This is the main target for testing. In theory driver should work the same be it module or built-in but in practice I’ve seen some nasty problems from time to time when running wifi driver as a module. Sometimes problems looks like a driver hang, other times it might be something failing in another part of the kernel, like getting fake ext4 errors reported while fs is OK in reality. Bottom line is: don’t build wifi as a module if you’re targeting wide user audience. But if you want to test it on your own in non-prod environment - feel free to do it and report your findings back please. Your help is really appreciated.