Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
srcshelton opened this issue Jul 15, 2015 · 10 comments
Labels
Waiting for internal comment Waiting for comment from a member of the Raspberry Pi engineering team

Comments

@srcshelton
Copy link

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
Copy link
Contributor

Ferroin commented Jul 16, 2015

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

@Belphemur
Copy link

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

@Ruffio
Copy link

Ruffio commented Aug 16, 2016

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

@srcshelton
Copy link
Author

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 added a commit to srcshelton/rpi-linux that referenced this issue Sep 7, 2016
…olution for Issue raspberrypi#1605)

Add an additional Kconfig which can optionally automatically select relevant kernel options to ensure maximum Raspberry Pi compatibility when building custom kernels

Drawbacks:

 - Kconfig provides no method to directly deselect options

 - Kconfig only allows options to be set to 'Y', rather than enabling an option to be built as a module

(Deselection could be performed by editing other stock Kconfig files to depend on one of the new options provided here being in a certain state - but this is a more intrusive change)
@srcshelton
Copy link
Author

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
Copy link

clivem commented Sep 7, 2016

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
Copy link

mi-hol commented Nov 13, 2016

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

@JamesH65
Copy link
Contributor

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

@srcshelton
Copy link
Author

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 JamesH65 added the Waiting for internal comment Waiting for comment from a member of the Raspberry Pi engineering team label May 18, 2017
@JamesH65
Copy link
Contributor

Ping @popcornmix @pelwell

popcornmix pushed a commit that referenced this issue Aug 11, 2021
Add several test cases for checking update_alu_sanitation_state() under
multiple paths:

  # ./test_verifier
  [...]
  #1061/u map access: known scalar += value_ptr unknown vs const OK
  #1061/p map access: known scalar += value_ptr unknown vs const OK
  #1062/u map access: known scalar += value_ptr const vs unknown OK
  #1062/p map access: known scalar += value_ptr const vs unknown OK
  #1063/u map access: known scalar += value_ptr const vs const (ne) OK
  #1063/p map access: known scalar += value_ptr const vs const (ne) OK
  #1064/u map access: known scalar += value_ptr const vs const (eq) OK
  #1064/p map access: known scalar += value_ptr const vs const (eq) OK
  #1065/u map access: known scalar += value_ptr unknown vs unknown (eq) OK
  #1065/p map access: known scalar += value_ptr unknown vs unknown (eq) OK
  #1066/u map access: known scalar += value_ptr unknown vs unknown (lt) OK
  #1066/p map access: known scalar += value_ptr unknown vs unknown (lt) OK
  #1067/u map access: known scalar += value_ptr unknown vs unknown (gt) OK
  #1067/p map access: known scalar += value_ptr unknown vs unknown (gt) OK
  [...]
  Summary: 1762 PASSED, 0 SKIPPED, 0 FAILED

Signed-off-by: Daniel Borkmann <[email protected]>
Acked-by: Alexei Starovoitov <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Waiting for internal comment Waiting for comment from a member of the Raspberry Pi engineering team
Projects
None yet
Development

No branches or pull requests

7 participants