Kernel overwrite by default

[flbuddymooreiv]

I installed a custom kernel with the ums-cypress code built into the kernel (to use external USB mass storage as a root device). When I run rpi-update with default options, it overwrites my kernel with a stock kernel (which has ums-cypress as a module rather than built in).
Now, I kernel panic at boot because no root device appears.

The solution to this problem (which was actually my first attempt, after giving up and building the module in) is to use an initramfs. My journies have led me to discover that the initramfs support is disabled in the stock kernel, so I'm assuming this kernel overwrite would "undo" that functionality as well.

Do you have any idea how rpi-update should be used differently to prevent this problem by default (at best), manually, or not at all (at worst)? If I cannot do anything manually (because, say, the firmware needs a new kernel, or something like that), then maybe something in the tool itself should detect whether a recognized stock kernel or custom kernel is being used.

[licaon-kter]

edit Makefile -> EXTRAVERSION = -mykernel
also copy zImage to /boot/kernel-mykernel.img and edit /boot/config.txt with kernel=kernel-mykernel.img ;)

[flbuddymooreiv]

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.

[licaon-kter]

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.

[flbuddymooreiv]

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 .

[licaon-kter]

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. :)

[flbuddymooreiv]

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. :)