User avatar
DougieLawson
Posts: 37725
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

Re: Upcoming Device Tree changes

Sun Mar 13, 2016 6:15 pm

I've posted an issue on http://github.com/hexxeh/rpi-firmware, I've written a crude/simple update for rpi-update to get it handling *.dtbo files.

https://github.com/Hexxeh/rpi-firmware/issues/111
Note: Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

Any DMs sent on Twitter will be answered next month.
All non-medical doctors are on my foes list.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2656
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Upcoming Device Tree changes

Sun Mar 13, 2016 6:38 pm

But it was fixed before you posted this...

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2656
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Upcoming Device Tree changes

Sun Mar 13, 2016 6:44 pm

@DirkS Dom has kindly rebuilt BRANCH=next, so you should be able to update your PiZero now.

User avatar
DougieLawson
Posts: 37725
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

Re: Upcoming Device Tree changes

Sun Mar 13, 2016 6:49 pm

PhilE wrote:But it was fixed before you posted this...
It wasn't fixed before I backed out the rpi-update this morning.
Note: Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

Any DMs sent on Twitter will be answered next month.
All non-medical doctors are on my foes list.

DirkS
Posts: 10208
Joined: Tue Jun 19, 2012 9:46 pm
Location: Essex, UK

Re: Upcoming Device Tree changes

Sun Mar 13, 2016 6:56 pm

PhilE wrote:Cool - I think that now explains all the odd behaviour you have seen. I've pushed a patch adding the missing config option to bcmrpi_defconfig, I'll raise the matter of rpi-update failing to install the new overlays (*), and I'll ask nicely if we can respin BRANCH=next.
Both issues resolved: dtbo's are copied and dtoverlay works

And on to the next one :mrgreen:
When I run dtoverlay -l on my Zero with enc28j60 overlay loaded I get 'no overlays loaded'.
I checked /sys/kernel/config/device-tree/overlays and it's empty.
Is this normal?
When I try to load the overlay:

Code: Select all

dtoverlay enc28j60
I get a return code 1 and nothing seems to change

On a Pi2B it's the same initially: 'no modules loaded', even though the enc28j60 must have been loaded (module is working)
When I try to load it with dtoverlay, it seems to succeed:

Code: Select all

[email protected]:~ $ ./dtoverlay -l
Overlays (in load order):
  enc28j60
Of course I get some messages in the logs that the driver is already loaded...

Code: Select all

[  189.237313] device-tree: Duplicate name in [email protected], renamed to "[email protected]#1"
[  189.237387] device-tree: Duplicate name in [email protected], renamed to "[email protected]#1"
[  189.237625] spi-bcm2835 3f204000.spi: chipselect 0 already in use
[  189.237639] spi_master spi0: spi_device register error /soc/[email protected]/[email protected]
[  189.237651] of_spi_notify: failed to create for '/soc/[email protected]/[email protected]'
[  189.237660] __of_changeset_entry_notify: notifier error @/soc/[email protected]/[email protected]

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2656
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Upcoming Device Tree changes

Sun Mar 13, 2016 7:51 pm

Overlays applied by the firmware don't appear as such to the kernel - instead they become part of the base DT. Overlays loaded by the kernel itself are stacked on top of the base DT, and can also be removed (with varying degrees of success). It is clearly possible to have some kernel overlays applied as part of the boot process, but that may require careful timing to have the desired effect.

The automatic renaming looks to be an interesting feature - that may make it possible to load the same overlay multiple times in a way that is useful, e.g. to define multiple instances of something like a GPIO or LED but with different parameters (pin, etc.)

DirkS
Posts: 10208
Joined: Tue Jun 19, 2012 9:46 pm
Location: Essex, UK

Re: Upcoming Device Tree changes

Mon Mar 14, 2016 7:39 pm

I have been experimenting with dynamic loading of overlays today and it actually works :shock:

I had a go with loading the overlay for my Adafruit PiTFT. It uses the pitft28-resistive overlay.

Code: Select all

dtoverlay pitft28r-resistive
con2fbmap 1 1
And the console is visible on the pitft. Great :D
One oddity. Looking at the logs I see

Code: Select all

[ 6614.670762] device-tree: Duplicate name in [email protected], renamed to "[email protected]#1"
[ 6614.670829] device-tree: Duplicate name in [email protected], renamed to "[email protected]#1"
[ 6614.687999] stmpe-spi spi0.1: stmpe610 detected, chip id: 0x811
[ 6614.690399] spi-bcm2835 3f204000.spi: chipselect 0 already in use
[ 6614.690423] spi_master spi0: spi_device register error /soc/[email protected]/[email protected]
[ 6614.690439] spi_master spi0: Failed to create SPI device for /soc/[email protected]/[email protected]
[ 6614.690464] spi-bcm2835 3f204000.spi: chipselect 1 already in use
[ 6614.690477] spi_master spi0: spi_device register error /soc/[email protected]/[email protected]
[ 6614.690490] spi_master spi0: Failed to create SPI device for /soc/[email protected]/[email protected]
[ 6614.729566] input: stmpe-ts as /devices/platform/soc/3f204000.spi/spi_master/spi0/spi0.1/stmpe-ts/input/input0
[ 6614.732367] fbtft: module is from the staging directory, the quality is unknown, you have been warned.
[ 6614.735830] fb_ili9340: module is from the staging directory, the quality is unknown, you have been warned.
[ 6614.738566] fbtft_of_value: buswidth = 8
[ 6614.738595] fbtft_of_value: debug = 0
[ 6614.738606] fbtft_of_value: rotate = 90
[ 6614.738615] fbtft_of_value: fps = 25
[ 6614.913491] graphics fb1: fb_ili9340 frame buffer, 320x240, 150 KiB video memory, 4 KiB DMA buffer memory, fps=25, spi0.0 at 32 MHz
Why would I get the messages about duplicates?
SPI is not activated in config.txt (actually, if I do that, then the drivers will not load)

Removing the overlay also works (although the drivers still seem to be loaded, but the framebuffer /dev/fb1 is removed)
Re-activated the overlay again, and I can get output to the PiTFT without problems.
The number of errors in the logs is getting a bit silly at this stage, but the screen works as expected.

Code: Select all

[ 9328.925072] device-tree: Duplicate name in [email protected], renamed to "[email protected]#1"
[ 9328.925144] device-tree: Duplicate name in [email protected], renamed to "[email protected]#1"
[ 9328.928192] stmpe-spi spi0.1: stmpe610 detected, chip id: 0x811
[ 9328.931661] input: stmpe-ts as /devices/platform/soc/3f204000.spi/spi_master/spi0/spi0.1/stmpe-ts/input/input1
[ 9328.933199] fbtft_of_value: buswidth = 8
[ 9328.933218] fbtft_of_value: debug = 0
[ 9328.933228] fbtft_of_value: rotate = 90
[ 9328.933238] fbtft_of_value: fps = 25
[ 9329.096201] graphics fb1: fb_ili9340 frame buffer, 320x240, 150 KiB video memory, 4 KiB DMA buffer memory, fps=25, spi0.0 at 32 MHz
[ 9329.096276] spi-bcm2835 3f204000.spi: chipselect 0 already in use
[ 9329.096289] spi_master spi0: spi_device register error /soc/[email protected]/[email protected]
[ 9329.096304] spi_master spi0: Failed to create SPI device for /soc/[email protected]/[email protected]
[ 9329.096331] spi-bcm2835 3f204000.spi: chipselect 1 already in use
[ 9329.096348] spi_master spi0: spi_device register error /soc/[email protected]/[email protected]
[ 9329.096363] spi_master spi0: Failed to create SPI device for /soc/[email protected]/[email protected]
[ 9329.096447] spi-bcm2835 3f204000.spi: chipselect 0 already in use
[ 9329.096459] spi_master spi0: spi_device register error /soc/[email protected]/[email protected]
[ 9329.096472] of_spi_notify: failed to create for '/soc/[email protected]/[email protected]'
[ 9329.096481] __of_changeset_entry_notify: notifier error @/soc/[email protected]/[email protected]
[ 9329.096521] spi-bcm2835 3f204000.spi: chipselect 1 already in use
[ 9329.096532] spi_master spi0: spi_device register error /soc/[email protected]/[email protected]
[ 9329.096543] of_spi_notify: failed to create for '/soc/[email protected]/[email protected]'
[ 9329.096551] __of_changeset_entry_notify: notifier error @/soc/[email protected]/[email protected]
So overall I would say this is working quite nicely. Great job!

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2656
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Upcoming Device Tree changes

Mon Mar 14, 2016 8:20 pm

That's good to hear. I'll take a look at how the overlay is written - it may be that there is some small change that can be made, e.g. splitting them into smaller fragments so that nodes don't get overwritten.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2656
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Upcoming Device Tree changes

Tue Mar 15, 2016 5:10 pm

@DirkS I've moved the disabling of the spidev nodes into separate fragments, which I think will remove those error messages you are seeing. There should be a BRANCH=next update later today.

DirkS
Posts: 10208
Joined: Tue Jun 19, 2012 9:46 pm
Location: Essex, UK

Re: Upcoming Device Tree changes

Tue Mar 15, 2016 6:57 pm

PhilE wrote:@DirkS I've moved the disabling of the spidev nodes into separate fragments, which I think will remove those error messages you are seeing.
Cheers Phil.
Tested again and the messages have indeed disappeared.

BTW: I see that dtoverlay is now included in /opt/vc/bin, but I can't find libdtovl.so anywhere. Shouldn't that have been included too (in /opt/vc/lib maybe)?

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2656
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Upcoming Device Tree changes

Tue Mar 15, 2016 7:32 pm

Try again - the automatic rules don't cover the .so files.

The source has also been made available in the userland repo.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2656
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Upcoming Device Tree changes

Tue Mar 15, 2016 8:32 pm

At this point I think it's important to make it clear that while some of the mechanisms that make the dynamic loading of overlays possible are relatively established (although little used) parts of Linux, some are very new, and others either haven't even been accepted or haven't even been sent upstream yet.

By making the dtoverlay command available and keeping its interface rooted in the problem space (overlays and what to do with them) we're aiming to insulate users from any changes to the underlying mechanisms. People should think carefully before making use of the Device Tree configfs interface directly.

DirkS
Posts: 10208
Joined: Tue Jun 19, 2012 9:46 pm
Location: Essex, UK

Re: Upcoming Device Tree changes

Tue Mar 15, 2016 9:28 pm

PhilE wrote:Try again - the automatic rules don't cover the .so files.

The source has also been made available in the userland repo.
Thanks again, Phil.
The lib is now included and the program works as expected.

User avatar
PeterO
Posts: 5623
Joined: Sun Jul 22, 2012 4:14 pm

Re: Upcoming Device Tree changes

Sun Mar 20, 2016 7:11 pm

I'm about to start to work with one of these:
http://www.rs-online.com/designspark/el ... dec-module
It's an I2S codec (ADC and DAC) with I2C control interface.
Bearing in mind this will need some dt "stuff", should I upgrade to the latest development kernel before I start to work to save having to make changes when kernel is upgraded ?

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
DougieLawson
Posts: 37725
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

Re: Upcoming Device Tree changes

Sun Mar 20, 2016 7:20 pm

I'd go with the 4.4.6.kernel because that's going to move to the master branch from next some time in the not too distant future.

Your rpi-source program just worked when I downloaded the source tree on a system running 4.4.6-v7+ today.
Note: Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

Any DMs sent on Twitter will be answered next month.
All non-medical doctors are on my foes list.

User avatar
PeterO
Posts: 5623
Joined: Sun Jul 22, 2012 4:14 pm

Re: Upcoming Device Tree changes

Sun Mar 20, 2016 7:43 pm

DougieLawson wrote:I'd go with the 4.4.6.kernel because that's going to move to the master branch from next some time in the not too distant future.

Your rpi-source program just worked when I downloaded the source tree on a system running 4.4.6-v7+ today.
Sold !
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
PeterO
Posts: 5623
Joined: Sun Jul 22, 2012 4:14 pm

Re: Upcoming Device Tree changes

Wed Mar 23, 2016 10:45 am

It looks like this didn't made it into the latest 2016-03-18 Raspbian release ?
PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2656
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Upcoming Device Tree changes

Wed Mar 23, 2016 10:59 am

It wasn't meant to - that release is probably the final Raspbian release with a 4.1 kernel.

Currently only the "next" branch of rpi-update is on rpi-4.4.y, so the next step is to switch the default ("master") branch to also be rpi-4.4.y. Finally we'll switch over the apt-get upgrade kernel to 4.4, and that will get built into a full Raspbian release. All of those steps assume no major problems are discovered in the previous ones, but many people have be running on 4.4 for quite a while now. The only users likely to be upset are those still running without Device Tree - the board support code on 4.4 has been stripped of its platform devices and non-DT support has been withdrawn.

User avatar
PeterO
Posts: 5623
Joined: Sun Jul 22, 2012 4:14 pm

Re: Upcoming Device Tree changes

Wed Mar 23, 2016 11:05 am

Thanks for the update/timeline Phil. I won't bother building a disk for the newest Raspbian then.
PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
skywatch
Posts: 46
Joined: Tue May 21, 2013 8:17 pm

Re: Upcoming Device Tree changes

Wed Apr 20, 2016 8:14 pm

This looks very interesting for my application....But would it work?

I currently have 2xpi (1 for music with a I2S dac and another with digi dac for surround sound on films).

I have to do this as I cannot get both dacs to work with a single DT overlay.

So my question is this, could I add a script to change the dt hifiberry dac to dt hifiberry digi (and vice versa) on the fly? This would be great and free up a pi for other use.

Thanks for any thoughts on this.

DirkS
Posts: 10208
Joined: Tue Jun 19, 2012 9:46 pm
Location: Essex, UK

Re: Upcoming Device Tree changes

Wed Apr 20, 2016 10:53 pm

skywatch wrote:So my question is this, could I add a script to change the dt hifiberry dac to dt hifiberry digi (and vice versa) on the fly? This would be great and free up a pi for other use.
It could work... or not.
Best way to find out is to try it.

BTW: I hope you're not thinking of swapping boards with the Pi running... a little mistake could fry your Pi.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2656
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Upcoming Device Tree changes

Thu Apr 21, 2016 9:04 am

I've just tried something like this (adding an overlay for a soundcard) and it didn't work - nothing happened. After a small tweak to the base DTB, loading the overlay was enough to cause all of the drivers to be loaded and for the device to appear in ALSA. A similar tweak to the base DTB allowed me to use the new dtparam command to enable and disable the onboard audio ("dtparam audio=on" and "dtparam audio=off").

Less encouraging is that unloading the soundcard overlay crashed the kernel. I have yet to find out why.

I'll merge the changes to the base DTBs into 4.4, assuming I find no problems, but I suspect unloading overlays is going to be a source of many kernel crashes.

User avatar
skywatch
Posts: 46
Joined: Tue May 21, 2013 8:17 pm

Re: Upcoming Device Tree changes

Thu Apr 21, 2016 6:04 pm

@Dirks

No need to swap modules. The stereo dac only has 3 I2S wires to it and so I should be able to wire this in parallel with the digi board.

Then, when I want 5.1 sound I load the hifiberry-digi and select passthrough in kodi. This is already tested on it's own.
If I want better quality stereo, I deselect passthrough in kodi and load the hifiberry dac. This is already tested on it's own.

I just have to now find a way to swap the DToverlays and test it out with both connect in parallel.

@PhilE.

That is very encouraging news! - Please keep us posted with how you progress as I believe a lot of people out there would find this very useful indeed. It is an answer to an old problem for me for sure ;)

Thanks all for the fast replies and taking the time to help try this out. I appreciate it! :D

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2656
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Upcoming Device Tree changes

Thu Apr 21, 2016 8:13 pm

It looks like ALSA doesn't do any kind of reference counting on its components, presumably because it isn't expecting them to be unloaded under its feet. When the overlay is removed the devices are deleted in random order, and this can mean that the codec goes before the board. Unfortunately part of the shutdown sequence for a card is to reset the bias on the codec, which involves using the codec which has already been deleted.

Adding reference counting might turn out to be a simple change, but it might not.

User avatar
skywatch
Posts: 46
Joined: Tue May 21, 2013 8:17 pm

Re: Upcoming Device Tree changes

Sat Apr 23, 2016 10:19 pm

Well at least that is better than "No way will it ever work" ;)

I would imagine that this could pave the way to plug and play on linux at some point?

If you want any help testing it out, let me know (but I will need some clear instructions on what to do)!

Thanks for the update and your time on this one.

Return to “Device Tree”