Comments (6)
edit Makefile -> EXTRAVERSION = -mykernel
also copy zImage to /boot/kernel-mykernel.img and edit /boot/config.txt with kernel=kernel-mykernel.img ;)
from rpi-update.
I think this technically answers my question, but I don't think it actually solves my problem (which might not really be the fault of rpi-update).
I believe what I really need is a method to:
- Get the latest firmware
- Get the latest kernel with patches for (if necessary) said firmware
- Pull the current /proc/config.gz
- Compile new kernel with config file
- Install kernel.img and modules
My assumption (which may not be correct and I'd like to know if it isn't) is that new firmware implies updated kernel headers which implies updated kernel code, so a binary distribution of a kernel will not have my drivers built in. Under this assumption, as much as I want to use rpi-update, I cannot come up with a way (even with initramfs) to preserve my custom kernel needs.
from rpi-update.
Firmware and kernel are separated, as long as you compile the current version of the kernel ( and you do, right? ) it will still work. The extraversion string just ensures that a kernel upgrade via apt-get or rpi-update does not delete your custom kernel.
from rpi-update.
I do compile the current version of the kernel, but even using rpi-update with that option is lacking because there is no construct to guarantee that my kernel goes with firmware that rpi-update uses from Hexxeh/rpi-firmware.
After being retrospectively scrutinous, the default behavior of upgrading the kernel with the firmware really is necessary from a dependency standpoint. From the docs:
SKIP_KERNEL
sudo SKIP_KERNEL=1 rpi-update
Will update everything except the kernel.img files and the kernel modules. Use with caution, some firmware updates > might depend on a kernel update.
Regardless of the docs, it makes sense and I should have known going in. Firmware effectively changes your hardware. When your hardware changes, it's possible that a driver will change. When a driver changes, it's possible its kernel header will change. When its kernel header changes, the layout of the whole kernel in memory possibly changes. When the layout of the kernel changes and something is loaded into it against different headers (like an old kernel with updated firmware) very bad things can happen. I'd hazard to guess you could even damage hardware if the firmware mismatches the running kernel in just the right way.
But hey, this is probably over half the reason I was interested in Raspberry Pi. It forces me to learn these things the hard/right way.
My current solution is simply to build everything as documented here: http://elinux.org/RPi_Kernel_Compilation . As far as I can tell, this is the most official documentation for building a Raspberry Pi kernel there is, so I can feel fairly confident in it being compatible with a Raspbian distribution's userland. The only downside is that I cannot use precompiled kernels or rpi-update like I originally thought I could. I've also confirmed one of the big reasons rpi-update exists in the first place: the firmware git repository is enormous, so aside from the time that compiling the kernel takes, getting the RaspberryPi/firmware takes a while, as Hexxeh states here: https://github.com/Hexxeh/rpi-firmware .
from rpi-update.
Yes there's a chance a newer firmware will have something changed, but that's no reason to affect anything as long as you compile the corresponding kernel with your .config anyway.
But I'm puzzled by something, since the firmware is basically closed source, any kernel anyone builds either you, me or the Raspberry Foundation with the current sources IS made to be compatible with the firmware, right? If so why do you say that: there is no construct to guarantee that my kernel goes with firmware that rpi-update ? Hexxeh's repo is just a copy of the main firmware repo anyway.
stock: current firmware + current kernel sources + pre-compiled, downloaded via rpi-update
you: current firmware + current kernel sources + compiled by you, adding a module
See the common part?
I kinda feel this issue is just a misunderstanding of some sorts but I don't know what else to say. :)
from rpi-update.
Thank you for distilling my thoughts so concisely. I'm in a lot of somewhat-new territory here.
Though I mostly agree with you, as a generally skeptical person, I try to (be it that I may frequently fail to) make as few assumptions as possible. One of my assumptions is/was that the firmware isn't necessarily closed source. If I don't know enough about the hardware on the board, then I would go to that level. I'm fully expecting something on this board to eventually be reverse-engineered (or maybe even opened), enabling some developmental/experimental capabilities. As such, I just want to keep my internalized processes compatible with that possibility.
No worries about the misunderstanding bit. As an Unreasonable Man, I am both frequently misunderstood and misunderstanding. :)
from rpi-update.
Related Issues (20)
- Invalid hash given HOT 8
- /boot/kernel7l.img needs to exist to get a V8 kernel installed HOT 5
- PRUNE_MODULES=1 does not seem to do anything HOT 13
- Firmware not activated - ubuntu HOT 2
- log file somewhere? HOT 7
- ssl error when runnung rpi-update on rpi3 HOT 6
- rpi-update on rpi4/8G results in soft FP libs installed HOT 4
- proxy support
- pi@raspberrypi:~ $ sudo rpi-update *** Github API is currently rate limited - please try again after HOT 3
- Boot fails in encrypted sdcard after running `rpi-update` HOT 5
- HDMI output hasn't worked since 78c1429cc1d5a200d824d2629c3ceba4ba4617fe HOT 9
- mismatch of "uname -m" output and "getconf LONG_BIT" HOT 3
- problem running SKIP_DOWNLOAD=1 rpi-update cannot stat '//root/.rpi-firmware/*.elf' issue HOT 9
- OpenCL support HOT 1
- PRUNE_MODULES only runs if there is an update HOT 3
- How would you upgrade/downgrade/restore the current stable "default" firmware? HOT 2
- t HOT 1
- Input output error HOT 2
- How to install new firmware from code (Uninterrupted by -y) ? HOT 2
- Latest firmware update showing 64bit on 32bit OS (armv7l vs aarch64) HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rpi-update.