This Time Self-Hosted
dark mode light mode Search

Me and a RaspberryPi: Don’t Open That I/O Port

The article’s title is a play on the phrase “don’t open that door”, and makes more sense in Italian as we use the same word for ‘door’ and ‘port’…

So you left your hero (me) working on setting up a Raspberry Pi with at least a partial base of cross-compilation. The whole thing worked to a decent extent, but it wasn’t really as feasible as I hoped. Too many things, including Python, cannot cross-compile without further tricks, and the time it takes to figure out how to cross-compile them, tend to be more than that needed to just wait for it to build on the board itself. I guess this is why there is that little interest in getting cross-compilation supported.

But after getting a decent root, or stage4 as you prefer to call it, I needed to get a kernel to boot the device. This wasn’t easy.; there is no official configuration file published — what they tell you is, if you want to build a new custom kernel, to zcat /proc/config.gz from Raspian. I didn’t want to use Raspian, so I looked further. The next step is to check out the defconfig settings that the kernel repository includes, a few, different of them exist.

You’d expect them to be actually thought out to enable exactly what the RaspberryPi provides, and nothing more or less. Some leeway can be expected for things like network options, but at least the “cutdown” version should not include all of IrDA, Amateur Radio, Wireless, Bluetooth, USB network, PPP, … After disabling a bunch of options, since the system I need to run will have very few devices connected – in particular, only the Davis Vantage Pro station, maybe a printer – I built the kernel and copied it over the SD card. It booted, it crashed. Kernel panicked right away, due to a pointer dereference.

After some rebuild-copy-test cycles I was able to find out what the problem is. It’s a problem that is not unique to the RPi actually, as I found the same trace from an OMAP3 user reporting it somewhere else. The trick was disabling the (default-enabled) in-kernel debugger – which I couldn’t access anyway, as I don’t have an USB keyboard at hand right now – so that it would print the full trace of the error .That pointed at the l4_init function, which is the initialization of the Lightning 4 gameport controller — an old style, MIDI game port.

My hunch is that this expansion card is an old-style ISA card, since it does not rely on PCI structures to probe for the device — I cannot confirm it because googling for “lightning 4” only comes up with images of iPad and accessories. What it does, is simply poking at the 0x201 address, and the moment when it does, you get a bad dereference from the kernel exactly at that address. I’ve sent a (broken, unfortunately) patch to the LKML to see if there is an easy way to solve this.

To be honest and clear, if you just take a defconfig and build it exactly as-is, you won’t be hitting that problem. The problem happens to me because in this kernel, like in almost every other one I built, I do one particular thing: I disable modules so that a single, statically build kernel. This in turn means that all the drivers are initialized when you start the kernel, and the moment when the L4 driver is started, it crashes the kernel. Possibly it’s not the only one.

This is most likely not strictly limited to the RaspberryPi but it doesn’t help that there is no working minimal configuration – mine is, by the way, available here – and I’m pretty sure there are other similar situations even when the arch is x86… I guess it’s just a matter of reporting them when you encounter them.

Comments 11
  1. …. As, I saw numerous ppl say it is a good thing, but i’m wondering about the real benefits. And how to mitigate its cons.

  2. @Steve Schnepp: Yes, one good rationale to disable modules could be security (it’s the most obvious way to get malicious code running in the kernel). On the Pi, I imagine it’s more of a minimalism thing – why have all these modules if you don’t (and won’t) have the hardware to use?Flameeyes, did the moduleless kernel boot after disabling the L4 driver?

  3. Yes it did boot. But I disabled almost everything else that I didn’t have, including Bluetooth, wireless, all the game ports, and most of the input devices. I didn’t want to spend the whole day with the SD card in my hand trying to get it to boot.

  4. @vlad thx. But I suppose it doesn’t really fit the distributions way of doing things. Wondering about having a “supported” custom-built kernel…

  5. Distributions cannot really do non-modular kernels by design. But if you run a defined system, be it a server or an embedded device, having a kernel without modules is very easy.It also avoids the uncertainties of whether @kmod@ is going to work today or not.

  6. Thanks for this series (and while I’m here, your Autotools stuff).I’m just starting to put together a simple RPi system, and settingup a cross-compiler is the first task on the list.Will

  7. Thanks a lot man. I just couldn’t figure out why my kernel kept crashing on it.On the same lines, have you tried XFS? There seems to be some issue with that, it always gets corrupted on boot (though this doesn’t happen with ext4).

  8. If you’re looking to cross-build to stuff like the RPi – worth a peek at ptxdist, who have collated patches specifically for cross-building packages and a Kconfig-based configuration system for building userlands. They have patches for python for example.

  9. Some time ago I worked a bit on improving cross-compilation; I was able to build a booting “stage3” *completely* with cross-compilation, for ARMv7 and ARMv5. The overlay is at… but it’s outdated now. I’ve filed bugs for most of the fixes.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.