New device tree kernel is in testing

[dom]

I've just pushed an experimental firmware to "next" branch. You can update to it with:

Code: Select all

sudo BRANCH=next rpi-update

The firmware is the same as the master tree, but the kernel is 3.18 with device tree enabled.
We are using device tree overlays to support HAT cards, and to automatically load the required modules.

The hope is that this will avoid some of the issues we are having with conflicting kernel modules (e.g. having to explicitly enable modules you need and blacklist modules you don't need to avoid conflicts). This is a particular problem currently with I2S audio cards.

So, if you have an add-on "HAT" which identifies itself, the firmware will automatically add a device tree overlay for that card which will result in appropriate modules being loaded.

As there are a number of add-on cards that don't support HAT identifcation you can manually choose the device tree overlay. You can see the currently supported overlays in /boot/overlays:

hifiberry-dac-overlay.dtb
hifiberry-dacplus-overlay.dtb
hifiberry-digi-overlay.dtb
iqaudio-dac-overlay.dtb
iqaudio-dacplus-overlay.dtb

You can manually choose one by adding to the config.txt file a line like:

Code: Select all

device_tree_overlay=overlays/iqaudio-dac-overlay.dtb

In future with cards that support HAT identification this will be automatic.

But, for now, testers are welcome to try this "next" firmware. Even if you don't have any HAT cards, then update and report if anything is broken.
If you have a hifiberry or iqaudio card, then it would be good to hear if it works with this firmware.
You shouldn't need to explicitly enable (in /etc/modules) or blacklist (in /etc/modprobe.d/) modules relating to the audio cards, just the device_tree_overlay line in config.txt is enough.

Phil has done most of the work on this scheme, and I'm sure he'll be along if there are any questions.
We will be moving to this scheme (with a 3.17 or 3.18 kernel) on the master branch in the near future, so testing now will be useful.

EDIT: Latest next branch firmware is now using 3.18 kernel.

[Douglas6]

We will be moving to this scheme (with a 3.17 or 3.18 kernel) on the master branch in the near future, so testing now will be useful.

Aww, I was looking forward to a 3.14 kernel on the Pi. Maybe minor revision 159. Just seemed appropriate.

[PhilE]

Yes, I'm here to help.

A few points:

• The list of currently supported audio cards is just what I have access to - no slight is intended towards the other fine cards out there.
• The source for the existing overlay .dtb files can be found in arch/arm/boot/dts on the 3.17.y branch. Compiling these requires an updated dtc utility because of the references to unresolved symbols. There is a good summary of DT fragments and dtc upgrade instructions here: https://learn.adafruit.com/introduction ... an-overlay
• Without a DT blob, the kernel should work exactly as before. The bootloader in the firmware will now try to pass an appropriate .dtb by default, provided the kernel supports it (see below). This can be overridden or disabled using an alternate (or empty) device_tree line in config.txt.
• To avoid breaking non-DT-capable kernels, kernel.img now includes a trailer to indicate whether the kernel is DT ready. The absence of a trailer is taken as a "no", but can be overridden (see above).
• In the event of a configuration error (broken or missing .dtb, etc.), the bootloader will revert to non-DT operation.

[DougieLawson]

How can I get the 3.17.? kernel source? I've got a custom 3.12.33+ kernel running on my A+ with support for my SPI ENC28J60 ethernet adapter.

[dom]

[*]The list of currently supported audio cards is just what I have access to - no slight is intended towards the other fine cards out there.

If you make an audio card that is not supported, then either create an overlay file that adds support and let us know, or send a card to us.

[*]To avoid breaking non-DT-capable kernels, kernel.img now includes a trailer to indicate whether the kernel is DT ready. The absence of a trailer is taken as a "no", but can be overridden (see above).

We run this scipt on the zImage to produce kernel.img. You can show what is in the trailer with this

[dom]

How can I get the 3.17.? kernel source? I've got a custom 3.12.33+ kernel running on my A+ with support for my SPI ENC28J60 ethernet adapter.

Source is here: https://github.com/raspberrypi/linux/tree/rpi-3.17.y
We build with bcmrpi_defconfig as the config with "CONFIG_BCM2708_DT=y" added.

[joan]

I've just done a next branch update on a headless Pi. I can no longer ssh into the machine. After about two minutes it shows

mercury:~$ ssh harry

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Dec 2 21:09:05 2014 from mercury.lan

but then it hangs (so far).

Unfortunately I carried out a general software update just before so this may not be anything to do with the next branch.

telnet, ftp report connection refused straight away, ping works.

Can't login via tty either.

Raspbian GNU/Linux jessie/sid harry ttyAMA0

harry login: joan

Login timed out after 60 seconds.

Reverted to 3.12.33+ #724 (5ba37078ca6bea96e02ceb94f9f77e95c4621e45) and my Pi is working again.

[bjacobs89]

Quick question:

For the bcm2708-rpi-b.dtb that is generated, do we need to add a device_tree_overlay line to the config.txt pointing to it? Or is this just for seperate HAT files? (Not too familiar with the HAT concept)

Do we need to include the config.txt file lines that were specified when notro achieved 2708 DT support, specifically:

device_tree=bcm2708-rpi-b.dtb
device_tree_address=0x100
kernel_address=0x8000
disable_commandline_tags=2

[PhilE]

The relevant config.txt directives are:
* device_tree= - this selects a base .dtb file. The current choices are bcm2708-rpi-b.dtb and bcm2708-rpi-b-plus.dtb. The former should also work for Model As, and the latter for A+s.
* device_tree_overlay= - this selects an overlay for an attached peripheral card. Overlays replace the platform devices that used to be required in the board support code (bcm2708.c), and only enable the interfaces (I2C, I2S, SPI) that are required by a peripheral. There are currently a number to choose from in the "overlays" folder, so remember to include "overlays/..." in the file name. If using a correctly configured HAT, this line is not necessary since the overlay is read from the HAT EEPROM.

BUT

When the bootloader sees a DT-ready kernel, it will choose a base .dtb file appropriate for the model (by name - if you change the names it won't find them), and set these defaults:
device_tree_address=0x100
kernel_address=0x8000
disable_commandline_tags=2

In other words, you shouldn't need any of those settings, unless the default behaviour is not what you want.

[milhouse]

I ran "sudo BRANCH=next rpi-update" on my Model B, and when the Pi rebooted it was stuck in a loop:



My config.txt is pretty simple:

Code: Select all

gpu_mem=16

arm_freq=1000
core_freq=500
sdram_freq=600
over_voltage=3
over_voltage_sdram=1

current_limit_override=0x5A000020
force_turbo=1

config_hdmi_boost=7
disable_overscan=1

I have no hardware attached, other than a wired ethernet. Boot device is a SanDisk Ultra SD card.

I've now reverted back to 3.12.33+ where all is well.

[PhilE]

@joan and @milhouse, can you try adding "device_tree=" to config.txt? This will disable the device tree support and indicate roughly whether this is a DT-related problem or something else.

[milhouse]

@joan and @milhouse, can you try adding "device_tree=" to config.txt? This will disable the device tree support and indicate roughly whether this is a DT-related problem or something else.

Adding "device_tree=" has allowed 3.17.4 to boot successfully and everything appears normal, many thanks.

[joan]

Ditto.

mercury:~$ ssh harry

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Dec 3 09:43:41 2014 from mercury.lan
harry ~ $ uname -a
Linux harry 3.17.4+ #727 PREEMPT Tue Dec 2 16:09:10 GMT 2014 armv6l GNU/Linux
harry ~ $

[PhilE]

Thanks, both, that's useful feedback. I've been running with an NFS root, so it looks like the SD card needs some more testing.

[joan]

One of the reasons I tried the new branch was the hope that the reserved bus 1 I2C entries 0x1B and 0x3B might go away. But, just like an unwelcome house guest they remain.

Code: Select all

harry ~ $ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
harry ~ $ 

[PhilE]

0x1b is claimed by the tas5713 driver, as used by the hifiberry-amp card. 0x3b is the wm8804 used by the hifiberry-digi.

Once DT is working, those entries will go away.

[PhilE]

Starting with a clean Raspbian install from September, followed by "sudo BRANCH=next rpi-update", I get an image which boots in my B+ and B.

With milhouse's config.txt, I get the same boot loop.

Binary chopping...

[PhilE]

Starting with milhouse's config.txt and setting gpu_mem=64 gets it to boot. gpu_mem=32 doesn't work, but there may be a value less than 64 that still works.

[PhilE]

I've found the problem - an error in the calculation of the /memory/reg property of the DT, the result of which was that the ARM was getting however much RAM the GPU was supposed to have. With that fixed, I can boot with gpu_mem=16.

I've given Dom a patch, and he's going to respin the firmware. Thanks for your assistance.

[PhilE]

Dom has pushed the updated firmware, if you want to give it a try.

[milhouse]

Dom has pushed the updated firmware, if you want to give it a try.

Looks good - I've removed the "device_tree=" line from config.txt and the Pi still boots fine. Many thanks!

[PhilE]

Is /proc/device-tree present? If so, then all is well.

It should now be safe to remove any modules from the blacklist. Please let me know if you find there are still some problematic modules being loaded.

[milhouse]

Is /proc/device-tree present? If so, then all is well.

It should now be safe to remove any modules from the blacklist. Please let me know if you find there are still some problematic modules being loaded.

Yes, with my regular config.txt I see /proc/device-tree, and I've also got "No ATAGs?" in dmesg which may be another indication that DT is detected/enabled:

Code: Select all

[email protected] ~ $ ls -la /proc/device-tree
lrwxrwxrwx 1 root root 29 Dec  3 20:54 /proc/device-tree -> /sys/firmware/devicetree/base

[email protected] ~ $ dmesg | grep ATAG
[    0.093417] No ATAGs?

If I add "device_tree=" to config.txt I see neither of the above.

[joan]

I2C and SPI appear to be broken.

i2c_dev and i2c_bcm2708 can be modprobed but no devices (/dev/i2c?) are created.

spi_bcm2708 can not be modprobed (even though the module exists).

harry ~ $ ls /lib/modules/3.17.4+/kernel/drivers/spi/
spi-bcm2708.ko
harry ~ $ sudo modprobe spi_bcm2708
modprobe: ERROR: could not insert 'spi_bcm2708': No such device
harry ~ $ ls /dev/sp*
ls: cannot access /dev/sp*: No such file or directory

harry ~ $ sudo modprobe i2c_bcm2708
harry ~ $ sudo modprobe i2c_dev
harry ~ $ ls /dev/i2*
ls: cannot access /dev/i2*: No such file or directory
harry ~ $

[PhilE]

They aren't "broken", they are disabled in the device tree. If they were enabled by default then the are some circumstances where they would need to be blacklisted, resulting in two configuration mechanisms where we would rather have one.

It is up to the loaded overlay to enable the needed devices. Ideally these would be written specifically for each peripheral card, but since I2C supports a run-time configuration mechanism it might be useful to have a few generic overlays such as i2c1-on-spi-on-overlay.dtb .

If you give me a list of generic overlays you would like and/or the specifics of your applications, I will write and compile some .dts's for you.