Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #52206 > unrolled thread

Testing versatile kernel on Raspberry Pi?

Back to article view | Back to linux.debian.kernel

Contents

  Testing versatile kernel on Raspberry Pi? Diederik de Haas <didi.debian@cknow.org> - 2016-01-16 03:30 +0100
    Re: Testing versatile kernel on Raspberry Pi? Ian Campbell <ijc@debian.org> - 2016-01-25 14:30 +0100
      Re: Testing versatile kernel on Raspberry Pi? Diederik de Haas <didi.debian@cknow.org> - 2016-01-25 15:50 +0100
        Re: Testing versatile kernel on Raspberry Pi? Ben Hutchings <ben@decadent.org.uk> - 2016-01-25 16:00 +0100
          Re: Testing versatile kernel on Raspberry Pi? Ian Campbell <ijc@debian.org> - 2016-01-25 16:10 +0100
            Re: Testing versatile kernel on Raspberry Pi? Diederik de Haas <didi.debian@cknow.org> - 2016-01-25 17:30 +0100
        Re: Testing versatile kernel on Raspberry Pi? Ian Campbell <ijc@debian.org> - 2016-01-25 16:00 +0100
          Re: Testing versatile kernel on Raspberry Pi? Diederik de Haas <didi.debian@cknow.org> - 2016-01-25 17:40 +0100
            Re: Testing versatile kernel on Raspberry Pi? Sebastian Reichel <sre@debian.org> - 2016-01-25 18:10 +0100
              Re: Testing versatile kernel on Raspberry Pi? Ian Campbell <ijc@debian.org> - 2016-01-26 09:30 +0100
                Re: Testing versatile kernel on Raspberry Pi? Sebastian Reichel <sre@debian.org> - 2016-01-26 14:00 +0100
                  Re: Testing versatile kernel on Raspberry Pi? Ben Hutchings <ben@decadent.org.uk> - 2016-01-26 14:50 +0100
                    Re: Testing versatile kernel on Raspberry Pi? Ben Hutchings <ben@decadent.org.uk> - 2016-01-27 18:50 +0100
                      Re: Testing versatile kernel on Raspberry Pi? Sebastian Reichel <sre@debian.org> - 2016-01-27 19:20 +0100
                        Re: Testing versatile kernel on Raspberry Pi? Ben Hutchings <ben@decadent.org.uk> - 2016-01-27 19:30 +0100
                          Re: Testing versatile kernel on Raspberry Pi? Sebastian Reichel <sre@debian.org> - 2016-01-27 21:00 +0100
                Re: Testing versatile kernel on Raspberry Pi? Diederik de Haas <didi.debian@cknow.org> - 2016-01-26 16:20 +0100
              Re: Testing versatile kernel on Raspberry Pi? Ian Campbell <ijc@hellion.org.uk> - 2016-01-26 10:50 +0100

#52206 — Testing versatile kernel on Raspberry Pi?

[Multipart message — attachments visible in raw view] — view raw

Hi!

I have a Raspberry Pi 1B, 1B+ and 2B and I'd love to test Debian's 4.4 kernel 
for it. At least it is/was my understanding that the versatile kernel is meant 
for the Raspberry Pi. 

But when I (globally) compare config-4.4.0-rc8-versatile with kernel configs 
taken from my Pi's I see HUGE differences. Among them the ones starting with 
CONFIG_ARCH_ and I also see no difference accounting for the difference 
between the Pi 1 and Pi 2.

Is my understanding of it (completely) wrong? 
Can I use/test the versatile kernel on my Pi? If so, would you like me to look 
out and/or test for specific things? Would I (still) need to use the 
raspberrypi-bootloader(-nokernel) package for the firmware files needed for the 
Pi?

TIA for any answers,
  Diederik

PS: I'm not subscribed to the debian-kernel ML, but will check the ML archive 
regularly. But a CC to me personal would be appreciated.

[toc] | [next] | [standalone]

#52415

On Sat, 2016-01-16 at 03:22 +0100, Diederik de Haas wrote:
> Hi!
> 
> I have a Raspberry Pi 1B, 1B+ and 2B and I'd love to test Debian's 4.4 kernel 
> for it. At least it is/was my understanding that the versatile kernel is meant 
> for the Raspberry Pi. 

The versatile kernel is meant for ARM "veratile" development boards, and it
also happens to be a reasonable platform emulated by QEMU.

It's not "versatile" in the sense of "adaptable".

I wasn't aware that any of the RPi support (for any model) had gone
upstream.

In any case for the RPi variants which use the older (non-armhf) processor
you are most likely better off with the Raspbian derived distro than Debian
armel.

For the variant with the newer CPU core which is armhf compatible we should
consider enabling support in the armhf kernels, for which support being in
the mainline kernel is a prerequisite.

Ian.

[toc] | [prev] | [next] | [standalone]

#52418

[Multipart message — attachments visible in raw view] — view raw

Thanks for your response :-)

On Monday 25 January 2016 13:23:20 Ian Campbell wrote:
> > I have a Raspberry Pi 1B, 1B+ and 2B and I'd love to test Debian's 4.4
> > kernel  for it. At least it is/was my understanding that the versatile
> > kernel is meant for the Raspberry Pi.
> 
> The versatile kernel is meant for ARM "veratile" development boards, and it
> also happens to be a reasonable platform emulated by QEMU.
> 
> It's not "versatile" in the sense of "adaptable".

I know. A slightly adapted version of the versatile kernel is used to do Pi 
simulation in QEMU and I've (also) created a repo for it: 
https://github.com/diederikdehaas/raspbian-kernel (default branch is 
kernel-3.18.x-qemu).

If you look at the changelog on linux (4.4~rc8-1~exp1) [1] you see the 
Raspberry Pi 2 explicitly mentioned and also references to BCM2836 (=Pi 2), 
BCM2835 (=Pi 1) and vc4 which stands for VideoCore4 which is the graphics chip 
for both the Pi 1 and 2.
Further reports on /. and phoronix [2] suggested that (full?) support for the 
Pi 1 and 2 was added to the upstream kernel and the changelog hinted at that 
as well. (A more recent report on /. [3] indicates that kernel 4.5 is more 
likely and it could be that it is primarily for the Pi 2.)

> I wasn't aware that any of the RPi support (for any model) had gone
> upstream.

It has taken a while, but it seems that major parts are now upstream-ed. 
See the changelog mentioned earlier.

> In any case for the RPi variants which use the older (non-armhf) processor
> you are most likely better off with the Raspbian derived distro than Debian
> armel.

That is correct, but I'm solely talking about the kernel here.

While most of the Raspbian packages work excellent, the kernel has always been 
somewhat of an issue. The Raspberry Pi Foundation (RPF) has their own linux 
kernel repo [4] (forked from upstream) and that has of course the best support 
for the RPi boards. But it is not 'properly packaged' (Debian style) and 
therefor doesn't have a linux-headers-* package [5] and all the other goodies 
I'm accustomed to with Debian kernels.

Plugwash has created Debian style kernels for the RPi, but that has its own 
drawbacks as it can safely be considered a hack and several things aren't 
working properly. And it's also quite a lot of work, which is a problem as 
he's the sole ftp-master/maintainer of the Raspbian repository. This is 
probably the reason that that kernel is still at 3.18, while the distributed 
kernel by the RPF has been on 4.1 for a while now.

As I got the impression that support for the RPi was now present in upstream 
and (therefor) the Debian kernels, I wanted to offer my help in testing it, if 
needed.
And being familiar with both Debian and the RPi and being the lead  
developer/maintainer of the Raspbian NetInstaller [6], I think I'm in a good 
position to do that.

Cheers,
  Diederik

[1] http://metadata.ftp-master.debian.org/changelogs/main/l/linux/linux_4.4-1~exp1_changelog
[2] https://www.phoronix.com/scan.php?page=article&item=linux-44-features
[3] http://linux.slashdot.org/story/16/01/24/1329206/linux-45-adds-raspberry-pi-2-support-amd-gpu-re-clocking-intel-kaby-lake
[4] https://github.com/raspberrypi/linux
[5] https://github.com/RPi-Distro/repo/issues/11
[6] https://github.com/debian-pi/raspbian-ua-netinst

[toc] | [prev] | [next] | [standalone]

#52420

[Multipart message — attachments visible in raw view] — view raw

On Mon, 2016-01-25 at 15:46 +0100, Diederik de Haas wrote:
> Thanks for your response :-)
> 
> On Monday 25 January 2016 13:23:20 Ian Campbell wrote:
> > > I have a Raspberry Pi 1B, 1B+ and 2B and I'd love to test Debian's 4.4
> > > kernel  for it. At least it is/was my understanding that the versatile
> > > kernel is meant for the Raspberry Pi.
> > 
> > The versatile kernel is meant for ARM "veratile" development boards, and it
> > also happens to be a reasonable platform emulated by QEMU.
> > 
> > It's not "versatile" in the sense of "adaptable".
> 
> I know. A slightly adapted version of the versatile kernel is used to do Pi 
> simulation in QEMU and I've (also) created a repo for it: 
> https://github.com/diederikdehaas/raspbian-kernel (default branch is 
> kernel-3.18.x-qemu).
> 
> If you look at the changelog on linux (4.4~rc8-1~exp1) [1] you see the 
> Raspberry Pi 2 explicitly mentioned and also references to BCM2836 (=Pi 2), 
> BCM2835 (=Pi 1) and vc4 which stands for VideoCore4 which is the graphics chip 
> for both the Pi 1 and 2.
> Further reports on /. and phoronix [2] suggested that (full?) support for the 
> Pi 1 and 2 was added to the upstream kernel and the changelog hinted at that 
> as well. (A more recent report on /. [3] indicates that kernel 4.5 is more 
> likely and it could be that it is primarily for the Pi 2.)
[...]

The armmp kernel flavour should now support the BCM2836 and the Pi 2,
but *not* the BCM2835.  Also, Debian's armhf port is built for ARMv7
whereas the BCM2835 implements ARMv6.  Most of the peripherals are the
same between these two chips, so the driver names include 'bcm2835'.

I haven't yet had confirmation that it actually does work.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
                                    A fail-safe circuit will destroy others.

[toc] | [prev] | [next] | [standalone]

#52423

On Mon, 2016-01-25 at 14:56 +0000, Ben Hutchings wrote:
> On Mon, 2016-01-25 at 15:46 +0100, Diederik de Haas wrote:
> > Thanks for your response :-)
> > 
> > On Monday 25 January 2016 13:23:20 Ian Campbell wrote:
> > > > I have a Raspberry Pi 1B, 1B+ and 2B and I'd love to test Debian's
> > > > 4.4
> > > > kernel  for it. At least it is/was my understanding that the
> > > > versatile
> > > > kernel is meant for the Raspberry Pi.
> > > 
> > > The versatile kernel is meant for ARM "veratile" development boards,
> > > and it
> > > also happens to be a reasonable platform emulated by QEMU.
> > > 
> > > It's not "versatile" in the sense of "adaptable".
> > 
> > I know. A slightly adapted version of the versatile kernel is used to
> > do Pi 
> > simulation in QEMU and I've (also) created a repo for it: 
> > https://github.com/diederikdehaas/raspbian-kernel (default branch is 
> > kernel-3.18.x-qemu).
> > 
> > If you look at the changelog on linux (4.4~rc8-1~exp1) [1] you see the 
> > Raspberry Pi 2 explicitly mentioned and also references to BCM2836 (=Pi
> > 2), 
> > BCM2835 (=Pi 1) and vc4 which stands for VideoCore4 which is the
> > graphics chip 
> > for both the Pi 1 and 2.
> > Further reports on /. and phoronix [2] suggested that (full?) support
> > for the 
> > Pi 1 and 2 was added to the upstream kernel and the changelog hinted at
> > that 
> > as well. (A more recent report on /. [3] indicates that kernel 4.5 is
> > more 
> > likely and it could be that it is primarily for the Pi 2.)
> [...]
> 
> The armmp kernel flavour should now support the BCM2836 and the Pi 2,

I missed this going in, thanks!

> but *not* the BCM2835.  Also, Debian's armhf port is built for ARMv7
> whereas the BCM2835 implements ARMv6.  Most of the peripherals are the
> same between these two chips, so the driver names include 'bcm2835'.
> 
> I haven't yet had confirmation that it actually does work.

Ian.

[toc] | [prev] | [next] | [standalone]

#52428

[Multipart message — attachments visible in raw view] — view raw

On Monday 25 January 2016 15:07:50 Ian Campbell wrote:
> > The armmp kernel flavour should now support the BCM2836 and the Pi 2,
> 
> I missed this going in, thanks!
> 
> > but *not* the BCM2835.  Also, Debian's armhf port is built for ARMv7
> > whereas the BCM2835 implements ARMv6.  Most of the peripherals are the
> > same between these two chips, so the driver names include 'bcm2835'.

Thanks Ian and Ben for the clarification!

> > I haven't yet had confirmation that it actually does work.

I just installed linux-image-4.4.0-trunk-armmp-lpae (as /proc/cpuinfo showed 
lpae) and rebooted ... and that failed completely. I didn't even see the 
message "Uncompressing Linux... done, booting the kernel."

I'll grab the latest RPi firmware files and put that in the device and see 
whether that makes any difference...

[toc] | [prev] | [next] | [standalone]

#52421

On Mon, 2016-01-25 at 15:46 +0100, Diederik de Haas wrote:
> > I wasn't aware that any of the RPi support (for any model) had gone
> > upstream.
> 
> It has taken a while, but it seems that major parts are now upstream-ed. 
> See the changelog mentioned earlier.

Great!

[...]
> 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).

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.

Probably those two cases ought to be separate wishlist bugs for armhf vs
armel.

>  I wanted to offer my help in testing it, if needed.

Once someone does the work to enable them then testing would be valuable
(of course). Perhaps you can take on the former?

Ian.

[toc] | [prev] | [next] | [standalone]

#52429

[Multipart message — attachments visible in raw view] — view raw

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/configs/bcm2709_defconfig 
(which does not seem part of 
https://sources.debian.net/src/linux/4.4-1~exp1/arch/arm/configs/)

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

Cheers,
  Diederik

[toc] | [prev] | [next] | [standalone]

#52430

[Multipart message — attachments visible in raw view] — view raw

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/configs/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]) and one could use armel userland + armmp kernel from armhf.

-- Sebastian

[toc] | [prev] | [next] | [standalone]

#52447

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, 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.

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.

Ian.

>  and one could use armel userland + armmp kernel from armhf.
> 
> -- Sebastian

[toc] | [prev] | [next] | [standalone]

#52454

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#52455

[Multipart message — attachments visible in raw view] — view raw

On Tue, 2016-01-26 at 13:53 +0100, Sebastian Reichel wrote:
> On Tue, Jan 26, 2016 at 08:24:16AM +0000, Ian Campbell wrote:
[...]
> > 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 multiplatform would be nice, but we're constrained by the size of
flash partitions on the small machines that are supported so I don't
think this would work.

> -armv5     kirkwood + orion5x + versatile
> -armv6     bcm2036
> 
> [0] http://lkml.iu.edu/hypermail/linux/kernel/1601.2/03005.html

I don't think we're going to add any more hardware support to the armel
port at this stage.

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today, ignorance or apathy?
A.  I don't know and I couldn't care less.

[toc] | [prev] | [next] | [standalone]

#52476

[Multipart message — attachments visible in raw view] — view raw

On Tue, 2016-01-26 at 13:48 +0000, Ben Hutchings wrote:
> On Tue, 2016-01-26 at 13:53 +0100, Sebastian Reichel wrote:
> > On Tue, Jan 26, 2016 at 08:24:16AM +0000, Ian Campbell wrote:
> [...]
> > > 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 multiplatform would be nice, but we're constrained by the size of
> flash partitions on the small machines that are supported so I don't
> think this would work.

I had another think about this and compared kirkwood and orion5x.  It
seems that they are similar enough that we can combine them without
breaking the size limit (~2 MB compressed), though the result is very
close.  Combining with versatile is probably not possible.

After reducing the number of flavours in this way, we could add a v6
kernel for armel too, but who would use it?  RPi 1 users expect armhf
(rebuilt for v6) not armel.

Ben.

> > -armv5     kirkwood + orion5x + versatile
> > -armv6     bcm2036
> > 
> > [0] http://lkml.iu.edu/hypermail/linux/kernel/1601.2/03005.html
> 
> I don't think we're going to add any more hardware support to the armel
> port at this stage.
> 
> Ben.
> 
-- 
Ben Hutchings
73.46% of all statistics are made up.

[toc] | [prev] | [next] | [standalone]

#52477

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Wed, Jan 27, 2016 at 05:41:58PM +0000, Ben Hutchings wrote:
> > ARMv5 multiplatform would be nice, but we're constrained by the size of
> > flash partitions on the small machines that are supported so I don't
> > think this would work.
> 
> I had another think about this and compared kirkwood and orion5x.  It
> seems that they are similar enough that we can combine them without
> breaking the size limit (~2 MB compressed), though the result is very
> close.  Combining with versatile is probably not possible.

2MB is... tiny :( I guess it's an arbitrary limit from the
bootloaders? In that case it could be circumvented by chainloading
another bootloader? Probably not worth the trouble (since it's old
HW), though.

> After reducing the number of flavours in this way, we could add a v6
> kernel for armel too, but who would use it?  RPi 1 users expect armhf
> (rebuilt for v6) not armel.

As I wrote, I do not care much for the extra performance win of
armhf (v6) vs armel on the RPi1 (the RPi1s I have lying around
have Debian armel images with kernel from RPi Foundation). In my
environment (often hanging around in a hackspace) the main usecase
of the RPi is attaching hardware, like sensors, to wired network.
This is not really a CPU intensive task.

OTOH I don't know how many people use the RPis that way and since
there is the RPi2 now, I can just use them and get rid of my old
RPi1s.

> > > -armv5     kirkwood + orion5x + versatile
> > > -armv6     bcm2036

^^^ I meant s/bcm2036/bcm2835 here.

> > > 
> > > [0] http://lkml.iu.edu/hypermail/linux/kernel/1601.2/03005.html
> > 
> > I don't think we're going to add any more hardware support to the armel
> > port at this stage.

I can live with that.

-- Sebastian

[toc] | [prev] | [next] | [standalone]

#52479

[Multipart message — attachments visible in raw view] — view raw

On Wed, 2016-01-27 at 19:16 +0100, Sebastian Reichel wrote:
> Hi,
> 
> On Wed, Jan 27, 2016 at 05:41:58PM +0000, Ben Hutchings wrote:
> > > ARMv5 multiplatform would be nice, but we're constrained by the size of
> > > flash partitions on the small machines that are supported so I don't
> > > think this would work.
> > 
> > I had another think about this and compared kirkwood and orion5x.  It
> > seems that they are similar enough that we can combine them without
> > breaking the size limit (~2 MB compressed), though the result is very
> > close.  Combining with versatile is probably not possible.
> 
> 2MB is... tiny :( I guess it's an arbitrary limit from the
> bootloaders? In that case it could be circumvented by chainloading
> another bootloader? Probably not worth the trouble (since it's old
> HW), though.
[...]

It's a limitation of the flash partitioning scheme, though I expect
that's built into the bootloader.  Several other NAS boxes have even
smaller partitions for the kernel (1.4 or 1.5 MB), which was just
barely supportable with 3.16 (jessie) but not any more.

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.

[toc] | [prev] | [next] | [standalone]

#52480

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Wed, Jan 27, 2016 at 06:25:59PM +0000, Ben Hutchings wrote:
> On Wed, 2016-01-27 at 19:16 +0100, Sebastian Reichel wrote:
> > On Wed, Jan 27, 2016 at 05:41:58PM +0000, Ben Hutchings wrote:
> > > > ARMv5 multiplatform would be nice, but we're constrained by the size of
> > > > flash partitions on the small machines that are supported so I don't
> > > > think this would work.
> > > 
> > > I had another think about this and compared kirkwood and orion5x.  It
> > > seems that they are similar enough that we can combine them without
> > > breaking the size limit (~2 MB compressed), though the result is very
> > > close.  Combining with versatile is probably not possible.
> > 
> > 2MB is... tiny :( I guess it's an arbitrary limit from the
> > bootloaders? In that case it could be circumvented by chainloading
> > another bootloader? Probably not worth the trouble (since it's old
> > HW), though.
>
> [...]
> 
> It's a limitation of the flash partitioning scheme, though I expect
> that's built into the bootloader.  Several other NAS boxes have even
> smaller partitions for the kernel (1.4 or 1.5 MB), which was just
> barely supportable with 3.16 (jessie) but not any more.

So it could be avoided by putting a secondary bootloader with
support for the rootfs filesystem into the kernel partition.
Probably it's not worth the effort for those old systems, but
it would remove the requirement of really small kernels.

-- Sebastian

[toc] | [prev] | [next] | [standalone]

#52457

[Multipart message — attachments visible in raw view] — view raw

On Tuesday 26 January 2016 08:24:16 Ian Campbell wrote:
> 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, 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.

Nor would I want that.
My assumption was that the new Debian versatile kernel would/could work 
(pretty much) unmodified on a RPi 1 and 2. But I now know that that assumption 
was wrong. I never wanted or intended for Debian to change something as major 
as their, properly documented, definition of armhf.

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

That Debian's armhf and armel didn't make full use of the RPi hardware is the 
whole reason that Raspbian was born and there's nothing wrong with that and it 
works fine.
The only downside to the kernels used (and made by the RPF) on the RPi is that 
it doesn't have a linux-headers-* package, but there are ways around that too 
[1].

As for getting the armmp kernel working on the Pi 2, I'll better leave that to 
the RPF kernel folks as they can (as opposed to me) asses whether that is 
feasible and/or desirable. 
When I compared "config ARCH_MULTIPLATFORM" [2] with what is enabled in the RPF 
kernels, most of them were off. I can look up the definition of those settings, 
but I (very likely) would still have no clue whether enabling them would have 
any adverse side effects. 
While I love the enthusiasm and help I've gotten here, I think it's better and 
safer to acknowledge that this is outside my area of expertise.

Cheers,
  Diederik

[1] https://github.com/diederikdehaas/cknow.org/blob/master/rpi/compile-kernel-module-on-raspberrypi.md
[2] https://sources.debian.net/src/linux/4.4-1~exp1/arch/arm/Kconfig/#L320

[toc] | [prev] | [next] | [standalone]

#52449

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/configs/bc
> > m2709_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.

Also note that the Debian kernels don't use anything from arch/*/configs.

The configuration is built from snippets (global, per arch, per flavour,
etc) under debian/configs. The armhf/armmp specific bits are
in debian/config/armhf/config.armmp and it is this I would expect to need
changes to support a new armhf platform.

When making changes it is useful to use kconfigeditor from http://anonscm.d
ebian.org/cgit/kernel/kernel-team.git/ to re-normalise the changes (just
run kernel-team.git/utils/kconfigeditor2/process.py <source dir>).

It's also likely that things will need adding under
debian/installer/armhf/modules/ in order for the platform to work in the
installer environment.

There's more info on ther Debian kernel packaging in the Debian Kernel
Handbook at https://www.debian.org/doc/manuals/debian-kernel-handbook/index
.html

Ian.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web