[OpenWrt-Devel] How to get OpenWRT to leave kernel .config the f alone?

[Alexandru Ardelean]

On Fri, Mar 9, 2018 at 7:24 AM, Daniel Santos <daniel.santos at pobox.com> wrote:
> Hello. I'm not very good with make and I need to make many changes to my
> kernel .config for debugging. I wrote a patch to add an option to tell
> OpenWRT to leave it alone, but I don't understand this build system very
> well and it seems to always prevent the kernel .config from being
> modified as well as leading to modules & kernel always being rebuilt.
> Would somebody be kind enough to fix it for me? :)
>

The problem is not the OpenWrt build system here.
It's likely the kernel's Kconfig system and dependency chain.
Your patch is going about it from the wrong angle.

Most symbols in the .config [whether OpenWrt's .config or kernel's
.config] have a dependency chain.
Example: driver bcm2708-spi [don't remember the actual driver name
here] will not be built/installed if CONFIG_SPI is not enabled in
.config.

So, if the symbol for building bcm2708-spi [let's call it
CONFIG_BCM2708_SPI] disappears during build, it's a symptom that the
dependency chain is not correct.
In a way, you may want this behavior, versus leaving it there and not
building it anyway.

What you can do is [in the OpenWrt context]:
* make kernel_menuconfig
* hit the slash key " / "
* type/search for the symbol you want to enable
* once you find it, it will list all symbols it depends on ; and which
you also want enabled
* add those symbols to your kernel config, or enable them via this
menuconfig you are in

Note that this Kconfig build-system is present in many projects [
Linux kernel, OpenWrt, buildroot, etc ].
So, if you learn to use it, the skill will be useful later on.

Typically, what I've noticed, is that the Linux kernel [in newer
versions] will enforce dependencies in drivers/code that were
previously not there, and when you update your kernel, stuff
disappears/gets disabled.
So, if you using an older .config in a newer kernel, or some other
mix, this is possible.

> I'm new to this project and I'm working with a device that has a crappy
> u-boot build installed on it. I need to run a debug kernel, but any time
> I attempt to tftp it to the device (directly to RAM) it fails to boot.
> If I send the whole damn sysupgrade via lcui then it works. Thus, if I
> upload a bad sysupgrade, I can potentially get locked out of the device
> until I manually flash the SPI (and I don't know how to do that yet, I
> guess some type of jtag?). So rather than just manually building my
> kernel and building a sysupgrade by hand, I would rather the build do it
> out of caution for messing it up.
>
> Oh yeah, and I'm using CC at this commit:
> 0625aaa6f37dcf6a2ffb611245fa9b6477642b78 -- of which I have no choice
> about. But if anybody can get that to work for the 17.x head, I can
> backport it.
>
> Thanks in advance!
> Daniel
>

Alex

> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel