Compute module - kernel for wheezy

[yarmooh]

Hello,
I'm using Compute Module at my own device. Currently running Wheezy with kernel 4.1.16+ #832
However, if I try to upgrade kernel to the newest (4.4.*) - using rpi-update I've got 'rainbow screen' during boot.
The similar device with Jessie and kernel 4.4.13+ #894 is running fine.
Question is - which kernel is the newest for wheezy, why can't I update it and run 4.4 ?
Unfortunately - I need it, because of troubles with some USB device.

[DougieLawson]

Wheezy has been end of life since 25th April 2016.
Jessie has been current since 25th Sept 2015

So the last version of Wheezy is http://downloads.raspberrypi.org/raspbi ... 015-05-07/

The kernel version on there is

Code: Select all

DTOKLinux version 3.18.11+ (dc4@dc4-XPS13-9333) (gcc version 4.8.3 20140303 (prerelease) (crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) ) #781 PREEMPT Tue Apr 21 18:02:18 BST 2015

Anything beyond that isn't guaranteed to work.

The time to upgrade to Jessie Lite is NOW!

[yarmooh]

Dougie,
thank you for your answer.
As far as I know Wheezy still has LTS support, and upgrade to Jessie currently is not possible (would need to setup whole platform), that's why I need to get 4.4 kernel work with my Wheezy instalation.
Can I achieve that? 4.1 kernels are working well with CM.

[fruitoftheloom]

Dougie,
thank you for your answer.
As far as I know Wheezy still has LTS support, and upgrade to Jessie currently is not possible (would need to setup whole platform), that's why I need to get 4.4 kernel work with my Wheezy instalation.
Can I achieve that? 4.1 kernels are working well with CM.

LTS support is Community Led and not Debian Supported, RPF have decided not to offer LTS, it is extremely time consuming to maintain and the resources are better used elsewhere. Also you have to be aware that Debian ARMHF is ARMv7, whilst Raspbian is ARMHF ARMv6. Time for Jessie Lite is NOW

https://wiki.debian.org/LTS

Debian LTS will not be handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success.

[yarmooh]

Guys,

I understand that Wheezy is EoL, but as I've mentioned before - ugprade to Jessie is not possible currently, that's why I need to get 4.4 kernel work with my Wheezy instalation.
How can I achieve that? Do you know any developer for hire who can help with that?

[RaTTuS]

why will Jessie not work for you

[yarmooh]

Clean Jessie install is working at my device, but upgrading Wheezy to Jessie fails - device is not booting - I've got 'rainbow screen' during boot.
As I'm using ComputeModule in industrial/commercial use I can change whole platform for new installations (which will take few days at least), but at the moment can't provide upgrade possibility for current devices.
All I need is 4.4 kernel ,and getting it for current Wheezy seems better/faster/easier for me, and that's what I need right now.

[6by9]

At a guess you've added the line "devicetree=" to /boot/config.txt.
The 4.4 kernel no longer has support for not using device tree and will probably stall on the rainbow screen.

If it's not that, then post the full contents of config.txt (under the code tags please) as stuff in there is about the only thing that will stop the kernel from booting.

[yarmooh]

Here's my config txt:

Code: Select all

# For more options and information see 
# http://www.raspberrypi.org/documentation/configuration/config-txt.md
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi

# Additional overlays and parameters are documented /boot/overlays/README
#dtdebug=1

#dtoverlay=dht11,gpiopin=2
#hdmi_force_hotplug=1

# Enable audio (added by raspberrypi-sys-mods)
dtparam=audio=on

Content is same as on device with Jessie...and all I've got is rainbow screen.

[6by9]

Here's my config txt:

Blows my idea out of the water

It's just possible that there is something quirky in the dt-blob files from the upgrade. You could try copying across the files from /boot/overlays and /boot/*.dtb from the Jessie system. rpi-update should have dealt with them, but there could be something missed.

Or possibly /boot/cmdline.txt.

[yarmooh]

Here's my config txt:

Blows my idea out of the water

It's just possible that there is something quirky in the dt-blob files from the upgrade. You could try copying across the files from /boot/overlays and /boot/*.dtb from the Jessie system. rpi-update should have dealt with them, but there could be something missed.

Or possibly /boot/cmdline.txt.

well..this is actually really helpfull!
Indeed I had my own modified files:

Code: Select all

-rwxr-xr-x 1 root root  9436 Sep 25  2015 bcm2708-rpi-cm.dtb
-rwxr-xr-x 1 root root 11146 Sep 25  2015 bcm2708-rpi-cm.dts
-rwxr-xr-x 1 root root  1770 Sep 25  2015 dt-blob.bin
-rwxr-xr-x 1 root root  2484 Sep 25  2015 dt-blob.dts

which I used to overwrite default ones. Now when I didn't overwrite them device boots up and is working! hooray!
Other thing would be to find how to change those files to work with new kernel.

[6by9]

well..this is actually really helpfull!
Indeed I had my own modified files:

Code: Select all

-rwxr-xr-x 1 root root  9436 Sep 25  2015 bcm2708-rpi-cm.dtb
-rwxr-xr-x 1 root root 11146 Sep 25  2015 bcm2708-rpi-cm.dts
-rwxr-xr-x 1 root root  1770 Sep 25  2015 dt-blob.bin
-rwxr-xr-x 1 root root  2484 Sep 25  2015 dt-blob.dts

which I used to overwrite default ones. Now when I didn't overwrite them device boots up and is working! hooray!
Other thing would be to find how to change those files to work with new kernel.

dt-blob.[bin|dts] are never shipped via rpi-update or Raspbian images. There is a default baked into start.elf that covers 99.99% of the users. The CM is the exception where there is an expectation that things will change. I don't recall any changes to the CM section of that blob for quite a while.

bcm2708-rpi-cm.dtb is shipped. The source dts file lives in the kernel tree.
You have a dts file there so you could try a simple diff, although it also then includes various other files.

Try replacing one of those at a time to confirm which one is causing the boot failure.

[yarmooh]

[
dt-blob.[bin|dts] are never shipped via rpi-update or Raspbian images. There is a default baked into start.elf that covers 99.99% of the users. The CM is the exception where there is an expectation that things will change. I don't recall any changes to the CM section of that blob for quite a while.

bcm2708-rpi-cm.dtb is shipped. The source dts file lives in the kernel tree.
You have a dts file there so you could try a simple diff, although it also then includes various other files.

Try replacing one of those at a time to confirm which one is causing the boot failure.

I found that replacing default bcm2708-rpi-cm.dtb with my own causes the crash. I guess that I need to 'remake' bcm2708-rpi-cm.dts' for a new structure?
So is this the correct way:
get default dtb from jessie and recompile it to dts
compare 'old' one with a 'new' and apply changes
compile new dts to dtb and check if it works?