Page 2 of 3

Re: Upcoming Device Tree changes

Posted: Sun Mar 13, 2016 6:15 pm
by DougieLawson
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

Re: Upcoming Device Tree changes

Posted: Sun Mar 13, 2016 6:38 pm
by PhilE
But it was fixed before you posted this...

Re: Upcoming Device Tree changes

Posted: Sun Mar 13, 2016 6:44 pm
by PhilE
@DirkS Dom has kindly rebuilt BRANCH=next, so you should be able to update your PiZero now.

Re: Upcoming Device Tree changes

Posted: Sun Mar 13, 2016 6:49 pm
by DougieLawson
PhilE wrote:But it was fixed before you posted this...
It wasn't fixed before I backed out the rpi-update this morning.

Re: Upcoming Device Tree changes

Posted: Sun Mar 13, 2016 6:56 pm
by DirkS
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]

Re: Upcoming Device Tree changes

Posted: Sun Mar 13, 2016 7:51 pm
by PhilE
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.)

Re: Upcoming Device Tree changes

Posted: Mon Mar 14, 2016 7:39 pm
by DirkS
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!

Re: Upcoming Device Tree changes

Posted: Mon Mar 14, 2016 8:20 pm
by PhilE
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.

Re: Upcoming Device Tree changes

Posted: Tue Mar 15, 2016 5:10 pm
by PhilE
@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.

Re: Upcoming Device Tree changes

Posted: Tue Mar 15, 2016 6:57 pm
by DirkS
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)?

Re: Upcoming Device Tree changes

Posted: Tue Mar 15, 2016 7:32 pm
by PhilE
Try again - the automatic rules don't cover the .so files.

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

Re: Upcoming Device Tree changes

Posted: Tue Mar 15, 2016 8:32 pm
by PhilE
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.

Re: Upcoming Device Tree changes

Posted: Tue Mar 15, 2016 9:28 pm
by DirkS
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.

Re: Upcoming Device Tree changes

Posted: Sun Mar 20, 2016 7:11 pm
by PeterO
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

Re: Upcoming Device Tree changes

Posted: Sun Mar 20, 2016 7:20 pm
by DougieLawson
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.

Re: Upcoming Device Tree changes

Posted: Sun Mar 20, 2016 7:43 pm
by PeterO
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 !

Re: Upcoming Device Tree changes

Posted: Wed Mar 23, 2016 10:45 am
by PeterO
It looks like this didn't made it into the latest 2016-03-18 Raspbian release ?
PeterO

Re: Upcoming Device Tree changes

Posted: Wed Mar 23, 2016 10:59 am
by PhilE
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.

Re: Upcoming Device Tree changes

Posted: Wed Mar 23, 2016 11:05 am
by PeterO
Thanks for the update/timeline Phil. I won't bother building a disk for the newest Raspbian then.
PeterO

Re: Upcoming Device Tree changes

Posted: Wed Apr 20, 2016 8:14 pm
by skywatch
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.

Re: Upcoming Device Tree changes

Posted: Wed Apr 20, 2016 10:53 pm
by DirkS
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.

Re: Upcoming Device Tree changes

Posted: Thu Apr 21, 2016 9:04 am
by PhilE
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.

Re: Upcoming Device Tree changes

Posted: Thu Apr 21, 2016 6:04 pm
by skywatch
@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

Re: Upcoming Device Tree changes

Posted: Thu Apr 21, 2016 8:13 pm
by PhilE
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.

Re: Upcoming Device Tree changes

Posted: Sat Apr 23, 2016 10:19 pm
by skywatch
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.