Linux kernel is now 4.0

[dom]

The default firmware branch has been updated to use the 4.0 kernel.
The source tree has been available for a few months and is being used by OpenELEC amongst others.

Update with:

Code: Select all

sudo rpi-update

Ideally nothing much will change. The newer kernel tree does support more devices (e.g. USB devices like wifi and dvb).

Please report if there are any regressions compared to the 3.18 kernel. If testing is positive it will appear in "apt-get upgrade" and on new raspbian images in the near future.

The default source tree on https://github.com/raspberrypi/linux is now rpi-4.0.y. This tree is now considered the stable kernel source tree and will merge in minor bumps to the kernel version, rather than rebase.
There is now a 4.1 kernel tree where more experimental kernel commits may go (in general moving closer to upstream).

[YemSalat]

Yay!
So far so good.. (*after ~7 minutes of usage)

[tonyscam]

Just loaded up 4.0, uptime @ 10 minutes and counting. So far so good and it'll be interesting to see if the USB WiFi dongle finally works. Never got it working with the previous kernels.

[dcrystalj]

I love to see things moving, but can you tell me how to install linux-headers-4.05+ ? i cannot find it anymore

[Douglas6]

Great news. It appears some new features in BlueZ require 4.1+. Good to see we're getting there.

[swe_toast]

Did the update but it still reports
*** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
*** Performing self-update
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 10102 100 10102 0 0 19322 0 --:--:-- --:--:-- --:--:-- 19352
*** Relaunching after update
*** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
*** Your firmware is already up to date

uname -r
3.18.0-trunk-rpi

uname -a
Linux 3.18.0-trunk-rpi #1 PREEMPT Debian 3.18.5-1~exp1+rpi16 (2015-03-28) armv6l GNU/Linux

and there is no image in the repo for the 4.0.5 kernel
aptitude search linux-image-
p linux-image-3.10-3-rpi - Linux 3.10 for RaspberryPI
p linux-image-3.12-1-rpi - Linux 3.12 for RaspberryPI
p linux-image-3.16.0-4-rpi - Linux 3.16 for RaspberryPI
i linux-image-3.18.0-trunk-rpi - Linux 3.18 for RaspberryPI
p linux-image-3.18.0-trunk-rpi2 - Linux 3.18 for RaspberryPI2
p linux-image-3.6-trunk-rpi - Linux 3.6 for RaspberryPI
p linux-image-rpi - Linux for RaspberryPI (meta-package)
i linux-image-rpi-rpfv - This metapackage will pull in the raspbian kernel for the raspberry pi 1
p linux-image-rpi2-rpfv - This metapackage will pull in the raspbian kernel for the raspberry pi 2

[dom]

uname -r
3.18.0-trunk-rpi

uname -a
Linux 3.18.0-trunk-rpi #1 PREEMPT Debian 3.18.5-1~exp1+rpi16 (2015-03-28) armv6l GNU/Linux

This doesn't look a standard raspbian kernel. What distribution are you using?

[r0land]

RTC pcf8563 finally started working. It wasn't working for me in all 3.18 firmware versions

[swe_toast]

https://github.com/debian-pi/raspbian-ua-netinst

[Massi]

anyone testing the new kernel can check if finalyi r8188eu dongles are working "out of the box"?

[DougieLawson]

anyone testing the new kernel can check if finalyi r8188eu dongles are working "out of the box"?

They don't work reliably OOB, the connection keeps dying. I had to install Mr Engman's driver for the 4.0.5-v7+ kernel.

[Massi]

They don't work reliably OOB, the connection keeps dying. I had to install Mr Engman's driver for the 4.0.5-v7+ kernel.

Damn
i really can't understand where the problem is. Good drivers are available (MrEngman has been using them for ages).

(ps: dougie i'm counting a lot on you to find a good python scheduler )

[DougieLawson]

(MrEngman has been using them for ages).

(ps: dougie i'm counting a lot on you to find a good python scheduler )

I'm puzzled that the updated drivers haven't been rolled into the RPF kernel source (or even the upstream source).

I found https://apscheduler.readthedocs.org/en/latest/

[dom]

https://github.com/debian-pi/raspbian-ua-netinst

It's probably safest to ask there if running rpi-update is safe. You are using a custom kernel and running rpi-update will lose any custom mods.
Probably best to wait for raspbian-ua-netinst to produce an update with 4.0 kernel.

[DougieLawson]

https://github.com/debian-pi/raspbian-ua-netinst

It's probably safest to ask there if running rpi-update is safe. You are using a custom kernel and running rpi-update will lose any custom mods.
Probably best to wait for raspbian-ua-netinst to produce an update with 4.0 kernel.

I've successfully updated a raspbian-ua-netinst kernel with rpi-update in the past.

[dom]

They don't work reliably OOB, the connection keeps dying. I had to install Mr Engman's driver for the 4.0.5-v7+ kernel.

If there are fixes to wireless drivers they should be submitted to the upstream linux kernel, where they can be peer reviewed by the driver experts. If accepted we can pull in the commits.

[tonyscam]

Still no luck with wpa_supplicant and the supplied USB wireless dongle. Tried it on both raspberry pi 1 and raspi 2 boards, no luck with either. I should note that I have a distro of Ubuntu 15.04 running on a different SD card and the wireless dongle does work correctly in that distro. Of course, 15.04 is not an officially supported distro but the point is the wifi dongle can work properly.

[Massi]

They don't work reliably OOB, the connection keeps dying. I had to install Mr Engman's driver for the 4.0.5-v7+ kernel.

If there are fixes to wireless drivers they should be submitted to the upstream linux kernel, where they can be peer reviewed by the driver experts. If accepted we can pull in the commits.

ok, is there a way in this forum to call a member into this topic?
i'd REALLY like MrEngman to read this

[MrEngman]

They don't work reliably OOB, the connection keeps dying. I had to install Mr Engman's driver for the 4.0.5-v7+ kernel.

If there are fixes to wireless drivers they should be submitted to the upstream linux kernel, where they can be peer reviewed by the driver experts. If accepted we can pull in the commits.

ok, is there a way in this forum to call a member into this topic?
i'd REALLY like MrEngman to read this

I have.

As far as I know there is a policy in Linux where drivers will not be accepted into the source if they include firmware in the source code like the drivers I compile.


MrEngman

[PhilE]

Can you explain why the firmware is in the source of your drivers? I presume that isn't true for all drivers with firmware blobs, otherwise there wouldn't be any in the kernel at all.

[I'm asking because I don't know.]

[deskanubis]

So far, my Tontec 3,5" mz61581 screen is not working after "sudo rpi-update"

Worked fine on 3.18 kernel

[MrEngman]

Can you explain why the firmware is in the source of your drivers? I presume that isn't true for all drivers with firmware blobs, otherwise there wouldn't be any in the kernel at all.

[I'm asking because I don't know.]

Because that's the way the code was written. Ask Realtek why. A rather extreme example but in one of the drivers I compile there are two files each about 475-500kB in size with large blocks of hex characters which get translated to binary when compiled and provide the firmware.

e.g.

Code: Select all

0x01, 0x95, 0x10, 0x00, 0x0F, 0x00, 0x00, 0x00, 0x05, 0x14, 0x10, 0x48, 0x84, 0x7A, 0x00, 0x00,
0xCC, 0xCC, 0xCC, 0xCC, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x02, 0x4C, 0xB1, 0x02, 0x60, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x02, 0x61, 0x0E, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x02, 0x70, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x02, 0x60, 0x85, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x6F, 0x7E, 0x00, 0x00,
0x15, 0xF0, 0xFF, 0x0F, 0x00, 0x00, 0x00, 0x15, 0xF0, 0x0F, 0x00, 0x00, 0x00, 0x00, 0x05, 0xF0,

with one file having in excess of 4500 lines and the other more than 5000 lines like these.

As far as I'm concerned this is far more convenient that requiring a separate firmware file, especially if the driver is included in the image but the firmware is not and is not included in any of the firmware packages that can be downloaded.


MrEngman

[allfox]

Greetings.

I couldn't find /proc/config.gz anymore, wish to opt-in CONFIG_IKCONFIG_PROC.

[PhilE]

It's a module now, to reduce the kernel size. If you:

Code: Select all

sudo modprobe configs

(or add it to /etc/modules) /proc/config.gz will appear.

[allfox]

Got it~ thanks!