Working with and layering kernel configs

For Developers
1

Hi there,

I am working on bringing up some custom boards based around an i.MX8MP-based SoM. Right now I'm working on bringing up OpenWRT on an eval kit board, but eventually we will be bringing up a fully custom board (still based on the same SoM).

The board vendor has provided me with a fork of Linux with all of their device trees, defconfigs, and patches baked in. For now, I'm pointing OpenWRT's buildroot to use the external repo - but may work on porting everything over in the long run.

OK, with the preamble out of the way - I had a few questions regarding kernel config:

  1. I assume the general idea on kernel built-in drivers vs. kmod-* packages is that if it's required for boot or that it's highly likely you'll always want it to be present, build the driver in (=y) in the kernel config, otherwise rely on packages. Is that a fair assessment?

  2. Does OpenWRT leverage or integrate with the defconfig files provided in <linuxroot>/arch/{arch}/configs at all, like it can with the device trees? Or am I going down a dead end here?

It appears that the Linux kernel configuration as stored by OpenWRT is split across three places: target/linux/generic/config-5.15, target/linux/{target}/config-5.15, and target/linux/{target}/{subtarget}/config-default.

  1. I'm assuming I'll probably never touch linux/generic for my needs. I'm guessing that I should probably not be messing with the linux/{target} copy either... I should put all of my board specific configs in the linux/{target}/{subtarget}/config-default file. Correct?

  2. I'm running make kernel_config TARGET="imx8mp" which should be the subtarget that I added. I (thought) I added an imx8mp subtarget in my build tree. It is there in the imx/Makefile as part of the SUBTARGETS list. However, when I save the kernel config, the target's imx/config-5.15 file gets modified, not the imx/imx8mp/config-default subtarget like I would expect and want. What am I doing wrong here?

  1. This may be related to the previous question: I run make kernel_oldconfig TARGET="imx8mp" when I finish editing things as my kernel / world build will often get interrupted by "new" options needing selection. This seems to only work for me inconsistently. Is this what I should be running to take care of any "new" options? or is there a better workflow here?

Thanks, I really appreciate the help. I've done my best to peruse the wiki and the forums for answers to these questions - but I may have missed something. Feel free to link me to anything I might have missed here.

2
  1. yes
  2. no.
  3. probably (~weak yes), unless there are reasons to do otherwise
1 Like
3

Thanks for the confirmations. Understood on #3. I've not seen a reason thus far - though the way that the imx target folder is currently laid out, I'm wondering if I'm not just better off making my own target altogether... That would sort of make questions 4/5 moot. I can see reasons for both approaches.

Any experience with questions 4/5? I did notice I made a typo in my original post and wrote TARGET="..." instead of CONFIG_TARGET="...". I've tried CONFIG_SUBTARGET="" as well. With imx, imx8mp, and imx_imx8mp as their values. No combination seems to have the intended result.

Figuring out what I'm doing wrong here would save me a lot of time having to babysit what should otherwise be a very fast parallelized build. I'm sure it's something really obvious that I'm just not seeing after staring at this for so long.

4

Supporting a target is rather heavy on resources, both computational (buildbots and mirror storage), as well as human (developers having to take care of it, on every (micro-) kernel bump and many other things), new targets should only be added if (really) necessary (~=unavoidable).

5

Very much understood.

I think that's all the more reason for me to figure out how to achieve a solution to #4 in an automated way. That way my kernel changes are only applying to the subtarget and not affecting the rest of the imx target ecosystem.

I can take another look at the include/*.mk files again in the morning with fresh eyes to see if I can figure out what's going on - but I figured I'd ask in case someone knew off of the top of their head.

6

Well, after perusing the *.mk files with fresh eyes, I did indeed answer my own questions #4 (and #5). So I'll post it here for others even though it is in the wiki:

The argument you pass is CONFIG_TARGET, indeed. And yes, the options are literally target, subtarget, or env. I kept thinking that I needed to substitute those values with the name of my desired target / sub-target... but nope. It's just those literal strings. I should have simply typed subtarget instead of imx8mp. The build system is smart enough to do the right thing since make menuconfig was already run and those values were selected and stored in .config.

So to answer 4/5:

To edit and properly layer a sub-target config:
make kernel_menuconfig CONFIG_TARGET=subtarget

Likewise, to make sure any "new" options are taken care of and not to halt the parallel build just to be dropped into the kernel config again:
make kernel_oldconfig CONFIG_TARGET=subtarget

1 Like