-
Notifications
You must be signed in to change notification settings - Fork 5.2k
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
Comments
+1 on this, making it harder for people to shoot themselves in the foot when building their own kernels is a good thing. |
👍 It would facilitate a lot instead of juggling with defconfig. |
@srcshelton has your issue been resolved? If so, please close this issue. Thanks. |
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... |
…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)
PR #1631 - We're actually more limited in what can be achieved due to Kconfig only being able to |
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..... |
@srcshelton is this still active or should it be closed? |
PR#1631 is still open so will leave this open for the moment. |
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 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! |
Ping @popcornmix @pelwell |
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]>
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
The text was updated successfully, but these errors were encountered: