0

I want to add entries to a vendor-provided defconfig for a Yocto distribution. In order to add the new drivers I want, I usually use the following process in my Linux directory:

$ cp $YOCTO_MYKERNEL/files/defconfig .config
$ make menuconfig
$ # I select some drivers I want to add and save .config file
$ make savedefconfig
$ cp defconfig $YOCTO_MYKERNEL/files/defconfig

The savedefconfig step adds my drivers correctly, but is also removing some important drivers that are vendor-provided:

$ diff -u $YOCTO_MYKERNEL/files/defconfig defconfig
--- $YOCTO_MYKERNEL/files/defconfig
+++ defconfig
@@ -1,22 +1,11 @@
-CONFIG_FHANDLE=y
 CONFIG_NO_HZ=y
 CONFIG_HIGH_RES_TIMERS=y
 CONFIG_CGROUPS=y
 CONFIG_BLK_DEV_INITRD=y
-CONFIG_PERF_EVENTS=y
 CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
-CONFIG_ARCH_SUNXI=y
 CONFIG_SMP=y
 CONFIG_NR_CPUS=8
-CONFIG_AEABI=y
-CONFIG_HIGHMEM=y
-CONFIG_ARM_APPENDED_DTB=y
-CONFIG_ARM_ATAG_DTB_COMPAT=y
-CONFIG_CPU_FREQ=y
-CONFIG_CPUFREQ_DT=y
-CONFIG_VFP=y
-CONFIG_NEON=y
[...]

If I understood the savedefconfig step well, it is removing options that are already set by default and thus redundant. However removing all these vendor-provided drivers are causing the newly compiled kernel to not boot at all after uboot.

I even tried only the savedefconfig step without adding any drivers, and vendor drivers are removed and kernel hangs.

Do you have any idea why savedefconfig is removing these entries, and how to make it stop? Currently I have to isolate diff changes by hand and manually add new lines that I am interested in into the Yocto defconfig file.

MicroJoe
  • 267
  • 3
  • 12
  • You perform `cp defconfig $YOCTO_MYKERNEL/files/defconfig`, and then `diff -u $YOCTO_MYKERNEL/files/defconfig defconfig` shows that **copied** file is not identical... Has some other actions been skipped in your workflow? – Tsyvarev Jan 28 '18 at 12:27
  • The diff call is started before the last `cp` command in order to compare it to the old defconfig before overriding it. I use this workflow on other Yocto distributions but on this one not because it will loose me vendor drivers. – MicroJoe Jan 28 '18 at 16:54
  • Hm, that shouldn't be the case, except perhaps $YOCTO_MYKERNEL/files/defconfig is not used as a real defconfig. In that case, you shoudl avoid `cp defconfig $YOCTO_MYKERNEL/files/defconfig` and instead pick the new options from the new defconfig and put them all manually into the yocto defconfig. I guess that's what you are doing now. – Ezequiel Garcia Jan 30 '18 at 19:48
  • You may also check this https://stackoverflow.com/questions/27899104/creating-defconfig-file-from-config/27918677#27918677 – 0andriy Feb 06 '18 at 17:51

1 Answers1

3

I have found the reason for all of this: I was calling make savedefconfig without specifying the ARM architecture, thus I think the build system will remove any non-revevant entries like all the SUNXI_* drivers (because they are not used on x86_64).

This call does not mangles important drivers:

make ARCH=arm savedefconfig

In order to not forget to do this step, one can use the Yocto steps instead that will automatically use the relevant architecture:

bitbake -c menuconfig virtual/kernel
bitbake -c savedefconfig virtual/kernel

Bitbake will print the path of the generated defconfig file that you will have to copy over the older one in order to take the changes into account.

MicroJoe
  • 267
  • 3
  • 12