On Tue, Jan 26, 2016 at 08:24:16AM +0000, Ian Campbell wrote: > On Mon, 2016-01-25 at 17:59 +0100, Sebastian Reichel wrote: > > Hi, > > > > On Mon, Jan 25, 2016 at 05:39:40PM +0100, Diederik de Haas wrote: > > > On Monday 25 January 2016 14:58:27 Ian Campbell wrote: > > > > > As I got the impression that support for the RPi was now > > present in > > > > > upstream and (therefor) the Debian kernels, > > > > > > > > The "therefor" won't happen automatically, someone will need to > > file a > > > > wishlist bug asking for the relevant options to be enabled in the > > Debian > > > > kernel configuration. > > > > > > > > For the RPi's with the newer CPU cores it makes clear sense to do > > that in > > > > the armhf/armmp kernel flavour (since it is the "multiplatform" > > flavour, > > > > and the only one we want to support). > > > > > > I'll give it a try, but first have to learn about the armmp stuff. > > > > > > Here is the default kernel configuration for the RPi 2: > > > https://github.com/raspberrypi/linux/blob/rpi-4.4.y/arch/arm/config > > s/bcm2709_defconfig > > > (which does not seem part of > > > https://sources.debian.net/src/linux/4.4-1~exp1/arch/arm/configs/) > > > > The kernel from the Raspberry Pi foundation and the mainline kernel > > have different config options, so that won't be of much use. Check > > mainline's arch/arm/configs/bcm2835_defconfig instead. > > > > > > For the RPi's with the older cores it wouldn't seem to make much > > sense to > > > > enable it in the armel/versatile flavour (because I can't see why > > it fits > > > > there, despite folks apparently adding it there), but equally I'm > > not sure > > > > we want to be adding new flavours to armel (which is essentially > > on the > > > > downward slope of the support lifecycle at this stage). Perhaps > > others > > > > around here feel differently though. > > > > > > Bummer for me as it won't solve the issue I hoped it would solve, > > but I'll try > > > other avenues for that. But still, thanks for clarifying :-) > > > > Another option would be adding RPi1 support to the armhf armmp > > kernel. I guess the benefits of ARMv7 vs ARMv6 is neglectable for > > the kernel (no floating point operations and Thumb2 should stay > > disabled because of errata 430973 on some older Cortex-A8s [i.e. > > on N900]) > > The Debian armhf kernels do not have support for ARMv6 enabled. AIUI > moving to a v6+v7 capable kernel, other than muddying the waters WRT > what "armhf" means,
An amd64 kernel can also boot i386, so imho kernel is always special. > would also mean falling back to ARMv6 features only missing out on > ARMv7 additions like improvements to SMP barriers and atomic > operations. I don't think we'd want to do that. Ok, I assumed the kernel was capable of checking runtime if it can use those features. Never mind then. > IMHO RPi1 is best supported by Raspbian, or if people really want it in > Debian then by armel, but not by an armhf+armel hybrid which involves > supporting v6 in some way on armhf. I had a few RPi1s running with armel. For simple tasks (e.g. network2gpio or i2c) it's more than enough. I wonder if an armel -armmp kernel would be worth the trouble. We currently have the following armel kernel targets: -kirkwood (multiplatform support since v3.14 (ba5a37e521942)) -orion5x (multiplatform support since v4.5 [0]) -versatile (DT only since v4.5 [0]) So maybe switch to -armv5 and -armv6 multiplatform kernels from v4.5+? -armv5 kirkwood + orion5x + versatile -armv6 bcm2036 [0] http://lkml.iu.edu/hypermail/linux/kernel/1601.2/03005.html -- Sebastian
signature.asc
Description: PGP signature
