Consider adding RPi-specific Kconfig patch which pre-selects hardware-essential options

[srcshelton]

Moving from an original RPi to an RPi2 has caused several issues when building custom kernels (especially in relation to the MMC/SDHC controller), partly because it's not immediately obvious what kernel options are mandatory for the RPi to boot with full functionality (e.g. SDHC, access to VideoCore, appropriate DT options set, etc.).

It would be a huge benefit to integrate a patch such as:

https://github.com/gtgt/gt-overlay/blob/master/patches/sys-kernel/pf-sources/3.11.1-4567_distro-Gentoo-Kconfig.patch

... which Gentoo uses to provide an optional but highly intuitive method of ensuring that the kernel has minimal functionality to try to guarantee that it will at least boot. The use-case would be when other areas of the kernel config have been extensively customised (thus making running 'make defconfig' and importing the changes a long job) but where the hardware-specific choices need to be re-applied.

This would also provide a mechanism to black-list any known-bad options which, for a given release, are known to cause issues.

Thanks in advance,

Stuart

[Ferroin]

+1 on this, making it harder for people to shoot themselves in the foot when building their own kernels is a good thing.

[Belphemur]

👍 It would facilitate a lot instead of juggling with defconfig.

[Ruffio]

@srcshelton has your issue been resolved? If so, please close this issue. Thanks.

[srcshelton]

Still not resolved, no. I was going to submit a patch, but my RPi kernel builds broke just after I filed this issue (the system didn't want to see its SDHC hardware on boot) and I've not had chance to fix things since.

I've recently picked it up again, though, so I'm going to try a stock 4.4.y kernel shortly...

[srcshelton]

PR #1631 - We're actually more limited in what can be achieved due to Kconfig only being able to select options to be built-in (with no supported method I could see for selecting tri-state options as modules or for deselecting other options without changing their dependencies) , but hopefully still of some use...

[clivem]

huge benefit to integrate a patch such as...

How so? You use the bcmrpi_defconfig or bcm2709_defconfig and your kernel will have all the neccesary options configured to boot. Am I missing something here? It feels like you are trying to fix something that never needed fixing.....

[mi-hol]

@srcshelton is this still active or should it be closed?

[JamesH65]

PR#1631 is still open so will leave this open for the moment.

[srcshelton]

This is surely the project's collective call: I've made some suggestions and submitted a patch in PR #1631 which I personally think has value, and there are a couple of posts above in agreement. At the same time, there appear to be an equal number of down-votes ;)

@clivem To answer your question, the advantage I see is that you can, say, do a make tinyconfig, then enable the RPi-specific options added in this patch for the specific hardware you're interested in, and instantly have a minimal kernel with the functionality specifically needed. It also aids in moving configurations between architectures, where the generic options are set as required but the machine-specific ones may need to be adjusted. Last time I looked, the bcmrpi/bcm2709 defconfigs include many selections which aren't strictly necessary to boot an RPi system, and include many options to support HATs and additional add-on hardware, plus entire sub-systems which aren't needed when running headless - which is fine, but it does make building a kernel slower if all additional functionality is retained, or more awkward if attempting to pare things down without breaking base functionality.

If it were felt to have value then I'd be happy to resurrect this patch against current kernel version - but only if there's a chance that it might be merged. If what I've suggested is simply never going to gain traction then let's agree on that now and we can all move on!

[JamesH65]

Ping @popcornmix @pelwell