Lazyweb, anyone know good tricks for discovering the kernel .config used on a device (old dev board) where /proc/config.gz was omitted and source was probably published but it's not clear where the relevant version is?
Conversation
Replying to
It's possible that CONFIG_IKCONFIG=y is enabled without CONFIG_IKCONFIG_PROC=y in which case you could use github.com/torvalds/linux. I don't really see a way of accurately figuring it out from the kernel itself, although if they have a standard toolchain you could compare builds.
2
2
Replying to
You should check /proc/version since scripts/setlocalversion sets the version based on git describe. It might have a commit hash to help with finding the correct version of the sources and hopefully the kernel configuration. I'm used to a defconfig in sources but it isn't always.
1
It also has the compiler version and you can potentially figure out the toolchain and build environment they used from that. I always try to reproduce the build and compare it because I don't want to be missing anything like a switch set in the environment rather than defconfig.
1
One issue that I encountered recently is that the 32-bit ARM vdso wasn't being built because of a weird bug in the standard build system requiring an extra variable to be set in some build environments, which is not supposed to be necessary. I think it's still buggy upstream too.
1
Replying to
I think my issue is that it's just not accepting the kernel command line from u-boot, but I'm not sure what options are affecting this. CONFIG_ATAGS was missing and I added it but still no output. Any ideas?
1
Looks like that's long-deprecated stuff and u-boot is supposed to be patching the command line into the DTB. Not sure why that's not getting seen or if that's even the problem now.. :(
1
Replying to
Yeah, modern devices put it in the device tree along with passing entropy there to seed the kernel CSPRNG. You should try ARM_ATAG_DTB_COMPAT instead of ATAGS. I think devices were already passing it in the device tree when I started working on ARM things maybe 7 years ago.
1
Replying to
Looks like that's only for a DTB appended to the kernel image, not one passed in the ABI manner by the bootloader.
1
Replying to
Does it pass a device tree? If it's an older device from 2013 or earlier, I wouldn't really expect that. It's also possible they hard-wired all or part of the command-line into their kernel build. You could try hard-wiring it into the build and see if it works.
Replying to
The kernel that shipped with it is showing the exact cmdline from u-boot environment in its /proc/cmdline, so I'm pretty sure it's accepting it from u-boot, however u-boot passes it. I see them in /proc/device-tree/chosen/bootargs too.
1
1
OK, it was missing earlyprintk (eew, why is that still in use and why don't the exotic serial drivers support earlycon yet??) combined with new kernel not being compatible with old dtb (um, like that defeats the whole point of device tree). Yay arm stuff.
1