Support for RPi2

[pleasantone]

Looks like we need to update the kernel? Mine are coming on Monday, will let you know.

[diederikdehaas]

I'm surprised that only now this issue is reported :-P

AFAIK both new kernel and firmware are needed.
But I have no idea when those will become available in the raspbian archives.

[kpfleming]

I have one in my hands, have been experimenting with just moving over my working Jessie install from a B+. So far I have not been able to locate a .deb package of the Pi2 kernel, only the image files that rpi-update pulls from the Foundation's images. It certainly isn't in the Raspbian repositories yet.

[diederikdehaas]

I have one too and by running rpi-update on the B+, removing /etc/udev/rules.d/70-persistent-net.rules (see #103) and commenting out the kernel and initramfs lines in /boot/config.txt I could move my SD card over to my RPi2 and boot up succesfully.

[kpfleming]

Same here, Pi2 is has now replaced my B+. In addition I removed the old 3.12-1-rpi kernel package just for safety.

[ghost]

Does this mean, users with a Pi2 can't use this? I've got a RPi model B so can't switch Cards and slapped this on microSD and it failed to boot. Hopefully this can be patched as noobs installed so much crap on Raspbian.

[kpfleming]

That is correct; the older kernel and firmware won't work on a Pi2. The net installer will have to be rebuilt with the new firmware and kernel.

[Mausy5043]

Is it possible to detect the hardware (A/B/A+/B+/2) at install time?
or does this mean several installers are needed and the user needs to select the correct installer for the hardware in question?

Given that @diederikdehaas now has RPi2 hardware does this mean development for older hardware will be phased out?
I prefer to use the old hardware as development/experimental stages. The newer hardware is used for production environments.

[diederikdehaas]

Given that @diederikdehaas now has RPi2 hardware does this mean development for older hardware will be phased out?

No. The primary target for this installer will still be the RPi1 B/B+.
I do want to add support for the RPi2 at some point, but it could take a while as I don't know @plugwash's plans for adding a RPi2 supported kernel to the archive (firmware needs to be updated as well, but I don't think that's an issue).
I think that it also needs (support for) Device Tree and I don't know whether you need a 3.18 kernel (as the rpf uses), which is different from the kernel for jessie (3.16).
And then there's the question whether the RPi2 should use the 'real' Debian armhf port instead of raspbian.

Is it possible to detect the hardware (A/B/A+/B+/2) at install time?

I think so by parsing /proc/cpuinfo
EDIT: See http://www.raspberrypi.org/forums/viewtopic.php?p=687491#p687491 for details

[goranche]

the question whether the RPi2 should use the 'real' Debian armhf port

from what I understand, it might take a few months to get to the answer of this question, there will be benchmarks and stuff, but it seems they are trying to avoid having to maintain 2 different distributions, and of course, given that the A+ and B+ will still be manufactured and sold (and there are a lot of them out there anyway), dropping support for those isn't really an option...

there is talk about having "critical" packages built for armv7, but most of raspbian will probably be armv6

[diederikdehaas]

All true 😄

I was just thinking out loud, since (theoretically) it should be possible to use the Debian armhf port (+ special firmware and optionally special kernel) for the RPi2 only.
My plan is to wait and see for the coming months to see what the Raspberry Pi Foundation will do and what Raspbian will do.

[goranche]

it should be, yes... actually, I think this will be the preferred way to run things...
(could be just me, though, I like to make use of the hardware as much as possible)

wait and see for the coming months to see what the Raspberry Pi Foundation will do

I agree that that's probably the best thing to do, yes

[Mausy5043]

Is it possible to detect the hardware (A/B/A+/B+/2) at install time?

I think so by parsing /proc/cpuinfo
EDIT: See http://www.raspberrypi.org/forums/viewtopic.php?p=687491#p687491 for details

Highly unlikely.
I have 2 B's. cat /proc/cpuinfo | grep Rev returns 000e and 000f respectively. That would make them both a model A. Both my Pi B+'s return '0010' which would mean they are a model B.

[diederikdehaas]

Best to respond to that forum thread then.
The explanation seems plausable, it was correct for my Pi2 and I haven't seen a Raspberry Pi Engineer contradict it.

[plugwash]

Mausy5043 wrote:

I have 2 B's. cat /proc/cpuinfo | grep Rev returns 000e and 000f respectively.
That would make them both a model A. Both my Pi B+'s return '0010' which
would mean they are a model B."

AIUI the "scheme" bit indicates whether it's using the new scheme or the old scheme. So you need to check that bit first, if it's set then interpret the bitfields, if it's clear then you need to use the list of values given at http://elinux.org/RPi_HardwareHistory#Board_Revision_History

diederikdehaas wrote:

"I do want to add support for the RPi2 at some point, but it could take a while as I don't know @plugwash's plans for adding a RPi2 supported kernel to the archive (firmware needs to be updated as well, but I don't think that's an issue). "

Afaict the following needs to happen for good support.
1: I need to get usable debian-style kernels built for pi2, my first attempt booted but was unusable (udev failed to start, keyboard was unusable), I tweaked the config and set off another build, I now need to check if that build succeeded and if so whether it is usable.
2: the raspberry pi foundation need to add support for seperately specifying kernels/initrds for pi1/pi2 in config.txt. There is already a bug report for this at raspberrypi/firmware#361
3: I need to upgrade the raspberrypi-firmware-nokernel package to a firmware version with pi2 support and the aforementioned config, this should be fairly trivial.
4: diederik needs to update his installer scripts and his kernel update hook script to take all of the above into account.

[diederikdehaas]

1: I need to get usable debian-style kernels built for pi2, my first attempt booted but was unusable (udev failed to start, keyboard was unusable), I tweaked the config and set off another build, I now need to check if that build succeeded and if so whether it is usable.

Maybe Sjoerd Simons' blog post can help? http://sjoerd.luon.net/posts/2015/02/debian-jessie-on-rpi2/

[plugwash]

On 11/02/15 01:05, Diederik de Haas wrote:

Maybe Sjoerd Simons' blog post can help?
http://sjoerd.luon.net/posts/2015/02/debian-jessie-on-rpi2/

My kernel is still not usable. I'll try and take a look at Sjoerd's to
see if I can learn anything from it but I probablly won't get time until
the weekend.

[diederikdehaas]

That's fine 👍
I'll probably need some more time to do my part ;-)

[plugwash]

On 11/02/15 01:05, Diederik de Haas wrote:

Maybe Sjoerd Simons' blog post can help?
http://sjoerd.luon.net/posts/2015/02/debian-jessie-on-rpi2/

Just tried booting his kernel and it doesn't seem to be usable in a
wheezy environment.

[diederikdehaas]

Bummer :-(

[plugwash]

Status update from my side:

1: I need to get usable debian-style kernels built for pi2, my first attempt booted but was unusable (udev failed to start, keyboard was unusable), I tweaked the config and set off another build, I now need to check if that build succeeded and if so whether it is usable.

Making progress but i've had to resort to taking a bisection approach to the config differences betwen the rpf config and the debian-style config (of which there were about a thousand) so it will take a while before I have a releaseable kernel.

2: the raspberry pi foundation need to add support for seperately specifying kernels/initrds for pi1/pi2 in config.txt. There is already a bug report for this at raspberrypi/firmware#361

The rpf claim this is fixed, I have yet to test this.

3: I need to upgrade the raspberrypi-firmware-nokernel package to a firmware version with pi2 support and the aforementioned config, this should be fairly trivial.

Will do this once I get the kernel package released.

4: diederik needs to update his installer scripts and his kernel update hook script to take all of the above into account.

Still blocked on the other actions.

[diederikdehaas]

Thanks for the update 👍

I've already done some research into point 2, but got (quite) a learning curve to go for implementing that. And that's without the potential issues raised by lurch in raspberrypi/firmware#361 (comment).
Python's ConfigParser would likely help, but I'm quite far from supporting Python code in the installer.

(PS: a blank line stops the indentation)

[plugwash]

kernel is coming along nicely, still have some device-tree related stuff to sort out (but if that takes too long i'll release without it). Also need to prepare a corresponding linux-tools-3.18 package so the headers are installable but again that shouldn't be a big deal.

new firmware-nokernel package has been prepared and seems to work for specifying separate kernels/initrds on pi1 and pi2. will upload that soon.

[diederikdehaas]

Got a couple of questions about the implementation:

• Is the plan to provide 2 kernels, one for RPi1 and one for RPi2? (like the rpf)
• Will they be in 1 deb package or in 2 (or more?) with a meta package which depends on both?
• What will be the kernel version and will there be a difference between RPi1 and RPi2?
• Something else entirely?

[plugwash]

On 14/02/15 14:30, Diederik de Haas wrote:

Got a couple of questions about the implementation:

* Is the plan to provide 2 kernels, one for RPi1 and one for RPi2?
  (like the rpf)

Yes.
*
*

* Will they be in 1 deb package or in 2 (or more?)

the kernels will be in linux-image--rpi and
linux-image--rpi2 . As usual there will be corresponding
headers packages etc.

* with a meta package which depends on both?

the existing linux-image-rpi-rpfv and linux-headers-rpi-rpfv
metapackages will be updated to point to the new version of the pi1
kernel and new linux-image-rpi2-rpfv and linux-headers-rpi2-rpfv
metapackage will be created for the pi2 kernel.

Not sure if I should create a metapackage that installs both, Debian
generally doesn't.

Status update:

kernels: seem ok, just waiting for the raspberry pi guys to provide a
version of mkknlimg with proper license information before I release it.
firmware-nokernel: should be ready pretty soon, first attempt didn't
have the dtbs which prevented the system booting in device-tree mode.
linux-tools-3.18: done
linux-latest (metapackages): not started yet but should be trivial.

[diederikdehaas]

Thanks for the answers and the update 👍

Not sure if I should create a metapackage that installs both, Debian generally doesn't.

It's not needed (for me/the installer) since it shouldn't be hard to install both packages if needed.

[diederikdehaas]

Although not needed, I think it can be useful.
Use case: People wanting to swap their sd card between a Pi 1 and a Pi 2 without having to install another kernel package (themselves).
Impact: AFAIK creating a meta package isn't much work and it should be maintainance free.

[plugwash]

On 14/02/15 16:11, Diederik de Haas wrote:

Although not needed, I think it can be useful.
Use case: People wanting to swap their sd card between a Pi 1 and a Pi
2 without having to install another kernel package (themselves).
Impact: AFAIK creating a meta package isn't much work and it should be
maintainance free.

If there was a new metapackage for "all versions of rpi" they would
still have to install the new metapackage. So it wouldn't really help
anyone until if/when raspberry pi 3 appears. People using your hook
script for config.txt would also have to update the hook script.

So I don't see much point in said metapackage personally.

[plugwash]

ok got a reply from phile on the license header for mkknlimg.

just kicked off the build for what should be a releasable set of 3.18 kernel packages. metapackages and firmware packages also built fine and will be uploaded at the same time.

[plugwash]

bad news:

The pi2 kernel works fine in both dt mode and non-dt mode but the pi1 kernel only works in non-dt mode.

I have decided to upload the +rpi9 version without the device tree markers (so it will boot in non-dt mode unless forced) for now. I will hopefully follow up with a version that has the dt markers once the pi1 kernel is working in dt mode.

[goranche]

the pi1 kernel only works in non-dt mode

any idea on why this is? 💭

[plugwash]

No, I initially suspected a kernel configuration difference but I couldn't see anything obvious and my attempt at making the configuration as close as possible to the rpf one for testing didn't help either.

[hertzg]

I've managed to "build" installer for rpi2 by specifying new kernel version in update.sh and boot.sh

diff --git a/update.sh b/update.sh
index 1b79b3b..9ae84bb 100755
@@ -1,6 +1,7 @@
 #!/bin/bash

-KERNEL_VERSION=3.12-1-rpi
+#KERNEL_VERSION=3.12-1-rpi
+KERNEL_VERSION=3.18.0-trunk-rpi2

 mirror=http://archive.raspbian.org/raspbian/
 release=jessie

diff --git a/build.sh b/build.sh
index 661cc03..6cb7096 100755
@@ -2,7 +2,9 @@

 set -e

-KERNEL_VERSION=3.12-1-rpi
+#KERNEL_VERSION=3.12-1-rpi
+KERNEL_VERSION=3.18.0-trunk-rpi2
+
 INSTALL_MODULES="kernel/fs/f2fs/f2fs.ko"
 INSTALL_MODULES="$INSTALL_MODULES kernel/fs/btrfs/btrfs.ko"
 INSTALL_MODULES="$INSTALL_MODULES kernel/drivers/usb/storage/usb-storage.ko"
@@ -90,7 +92,7 @@ rm -rf bootfs
 mkdir -p bootfs

 # raspberrypi-bootloader-nokernel components and kernel
-cp tmp/boot/* bootfs/
+cp -r tmp/boot/* bootfs/
 rm bootfs/System*
 rm bootfs/config-*
 mv bootfs/vmlinuz* bootfs/kernel_install.img

Boots like a charm 👍

_UPDATE_
The rpi2 was not booting after the installation and the reason was the config.txt which contained line kernel=vmlinuz- and there was no file with that name.

So I've downloaded the linux-image-3.18.0-trunk-rpi2_3.18.5-1~exp1+rpi9_armhf.deb package, extracted the contents of boot folder into the boot partition on the sdcard.
Modified the config.txt to point to correct kernel image

kernel=vmlinuz-3.18.0-trunk-rpi2

Works like a charm 👍

The only question i have is the initramfs initrd.img- followkernel line. Where should this file be (or is). Is it in vmlinuz?

[diederikdehaas]

I haven't tried it yet, but I'm pretty confident that your image won't work on a RPi1 and this installer needs to support both.

A big problem (for me) is updating the kernel upgrade handler script.
If that script was working properly, you would not have had kernel=vmlinuz-, but kernel=vmlinuz-3.18.0-trunk-rpi2 but the KERNEL_VERSION variable isn't detected correctly.
In the old situation there was only linux-image-rpi-rpfv, but for the RPi2 you need the linux-image-rpi2-rpfv. The .deb file you downloaded is a dependency of that RPi2 meta-package and a normal install would've created the initramfs file. (and again the KERNEL_VERSION part is missing from the line you posted.

But the main issue is that instead of single config lines in /boot/config.txt which can easily be parsed with sed and grep, they now need to be evaluated in context (and added or updated in context with possibly deleting other entries) since there are now categories like [pi1], [pi2], [all] and (afaik) several for specific monitor settings.
And there are some more things which makes it non-trivial to create a proper kernel-upgrade-script.

[johnsmith87]

@hertzg: I have tried your version of getting raspbian-ua-netinst running on my raspberry pi 2. So far it boots. But when trying to set up wifi, even after installing the wifi-firmware I cannot get it up. lsmod is empty, iwconfig not showing wlan0, either does ifconfig -a. Any suggestions?
Thanks in advance.

[ghost]

@johnsmith87 sounds like you need a kernel upgrade? Try installing via apt-get (should install modules)

[hertzg]

@diederikdehaas I'm also aware that this script is not working as it should be. It was just making sure it was still possible to use this script.

I'll check/provide the install log later today.

What about providing a way to build installer for specific versions of pi (something like --target=rpi2 switch or alike) and distributing them separately?

_UPDATE_

Configuring bootloader to start the installed system...
Kernel version: ''
Creating kernel upgrade handler script... OK
Running the kernel upgrade script... OK
Copying kernel to /boot/kernel.img... cp: can't stat '/rootfs/boot/vmlinuz-': No such file or directory
FAILED !

[diederikdehaas]

It was just making sure it was still possible to use this script.

Thanks for that 👍

What about Instead of providing one universal kernel install script, provide one for each version of pi, execute the one for the current pi and cleanup the other?

That would rule out ppl having a system which can be switched between a Pi2 and Pi1, not something I'm in favor of.

What about providing a way to build installer for specific versions (something like --target=rpi2 switch or alike) and distributing them separately?

Creating that would probably be more work then one for both Pi1 and Pi2 and it would mean that ppl would have to use different installers based on whether they want to use it on a Pi1 or Pi2.
I'm not in favor of this either.
Thanks for thinking along though :)

I may have an intermediate solution in mind ...

[johnsmith87]

@IRCdDev: I already did upgrade the kernel with rpi-update, still no success. Any other suggestions?

[hertzg]

@johnsmith87 Install the linux-image-rpi2-rpfv metapackage. If theres still a problem with the wifi then either you are missing drivers or its probably the classic rtl8192cu driver issue.

[johnsmith87]

@hertzg That one worked. Thanks alot. Now the workaround is usable for me. Looking forward for "real" RPi2 Support. You guys do a great job.

[diederikdehaas]

I have decided to upload the +rpi9 version without the device tree markers (so it will boot in non-dt mode unless forced) for now.

So it's now operation like /boot/config.txt has device_tree= without specifying it or does it need to be specified? (From the README in raspberrypy-bootloader-nokernel package)

[plugwash]

On 27/02/15 02:09, Diederik de Haas wrote:

I have decided to upload the +rpi9 version without the device tree
markers (so it will boot in non-dt mode unless forced) for now.

So it's now operation like |/boot/config.txt| has |device_tree=|
without specifying it

Right

[diederikdehaas]

Thanks 👍

[diederikdehaas]

We've just released version 1.0.7-beta of the Raspbian UnAttended Netinstaller, which should fix this issue: https://github.com/debian-pi/raspbian-ua-netinst/releases/tag/v1.0.7-beta.

As can be read in the release notes the kernel-upgrade-script has been removed from that since it's not working properly. See also this issue in the raspbian-tools repository for that.
Everyone is hereby invited to help fix that one 😉

[bbinet]

do you know if linux kernel v3.12 will be supported on the rpi2?

[diederikdehaas]

No, I don't know it, but I highly doubt it. I don't think there will be a new 3.12 release or even a 3.18 release as debian doesn't have them (anymore).
Why?

[diederikdehaas]

This issue is now fixed with the release of v1.0.7 of the Raspbian unattended netinstaller.