User avatar
jack_the_pi_man
Posts: 7
Joined: Fri Sep 07, 2012 7:01 pm
Location: Derby, United Kingdom

Device Tree Changes for Interfacing LAN951X with CM3+

Tue Apr 30, 2019 6:12 pm

Hi All,

I am looking to interface the CM3+ with a LAN951X on a custom development board. As it seems many people have had queries regarding how to achieve this, once my friend and I have completed and tested the board design we intend to release the board schematics and PCB design as an open-source hardware project, accompanied with all the documentation required to interface the board's peripherals to the CM3+ from the ground up. We are aware that the newer RPi boards make use of the LAN7500 series ICs, offering 1Gbps uplink speeds, and may look to produce a newer board featuring this IC in the future.

I will also admit that I am new to working with the Device Tree. There is much to learn, but it will be time well spent considering the benefits of its usage.

I have read the guide for the default setup of pin configurations using the user-provided Device Tree blob (dt-blob.bin) available here: https://www.raspberrypi.org/documentati ... uration.md.
I have also read the CM specific guidance on interfacing with peripherals via the Device Tree available here: https://www.raspberrypi.org/documentati ... w-guide.md.

Upon initial inspection, I believed that simply adding the following lines to a custom barebones dt-blob.bin would be enough to get the device working happily with the correct device driver installed from Microchip:

Within the pin_config Section:

Code: Select all

[email protected]  { function = "output"; termination = "pull_down";  startup_state = "active"; }; // LAN_RUN

Within the pin_defines Section:

Code: Select all

 [email protected]_RUN { 
	type = "internal";
	number = <6>; 
}; 
[email protected]_CLK { 
	type = "absent"; 
}; 
However, after referring to the ARM DTS file for the RPi 3B within the Raspberry Pi's kernel source tree here (https://github.com/raspberrypi/linux/bl ... pi-3-b.dts), I could see that the ARM DTB includes a file for the LAN951X interface.

My questions are thus:-

1) If I add the include to the bcm2710-rpi-cm3.dts, compile, deploy and point to the new ARM DTB within config.txt , should this be all that is required in terms of changes to the Device Tree in order get this peripheral functioning with the driver from Microchip installed?

2-i) I believe this is clear in the documentation above, but I just wanted to clarify anyway. The purpose of dt-blob.bin is to configure GPIOs/peripherals controlled and owned by the SoC GPU only?

2-ii) Anything core being used via Linux on the ARM should be set within the ARM DTB?

2-iii). Anything non-core being used via Linux on the ARM should be set using DTB overlays?

3) Different board / SoM manufacturers will use different means to apply DTB overlays. The use of config.txt is specific to the RPi. Other manufacturers may have other means of instructing their firmware to load the DTBs into memory prior to passing a pointer to the loaded DTBs to the Linux Kernel?

4) The RPi GPU firmware makes use of the dt-blob.bin DTB to setup the peripherals it owns. But does this information also end up being given over to the Linux Kernel with the rest of the DTBs? I believe the answer is no, from what I've read, but am still a little unsure.

Apologies for this post being a little lengthy, but I hope that the answer to this post will serve as good guidance to anyone else who comes along working from the ground upward on interfacing this peripheral (as well as others).

~Jack
Jack Winch (jack_the_pi_man) | Avid Geek, Lover of Earl Grey Tea & Guardian of a 200+ RPi System
'It turns out that while it’s easy to undo technical mistakes, it’s not as easy to undo personality disorders.' - TLK Documentation

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

Re: Device Tree Changes for Interfacing LAN951X with CM3+

Tue Apr 30, 2019 8:41 pm

OK, deep breath:
1) If I add the include to the bcm2710-rpi-cm3.dts, compile, deploy and point to the new ARM DTB within config.txt , should this be all that is required in terms of changes to the Device Tree in order get this peripheral functioning with the driver from Microchip installed?
Yes, I think so. Provided the LAN951X has a clock and has been reset correctly it is just another USB device. The reason for the Device Tree file is not to tell Linux what USB device is present (USB does that already), but to locate the place to set the MAC address.
2-i) I believe this is clear in the documentation above, but I just wanted to clarify anyway. The purpose of dt-blob.bin is to configure GPIOs/peripherals controlled and owned by the SoC GPU only?
That is the intention. Unless overridden, dt-blob.bin settings will persist for the kernel, but there are usually better ways to configure pins for the kernel.
2-ii) Anything core being used via Linux on the ARM should be set within the ARM DTB?
See above.
2-iii). Anything non-core being used via Linux on the ARM should be set using DTB overlays?
For a Compute Module project with a custom DTB the boundary between base DTB and overlays is fluid. It makes sense to use existing overlays where you can - they are maintained and documented (to a degree) - but its far from compulsory.
3) Different board / SoM manufacturers will use different means to apply DTB overlays. The use of config.txt is specific to the RPi. Other manufacturers may have other means of instructing their firmware to load the DTBs into memory prior to passing a pointer to the loaded DTBs to the Linux Kernel?
U-boot can apply overlays now, but I doubt it understands overlay parameters (a Pi-specific extension). I'm not familiar with other loaders.
4) The RPi GPU firmware makes use of the dt-blob.bin DTB to setup the peripherals it owns. But does this information also end up being given over to the Linux Kernel with the rest of the DTBs? I believe the answer is no, from what I've read, but am still a little unsure.
Certain values (I can think of camera settings, and there may be others) are explicitly read from the dt-blob and converted into DT properties but, in general, no - the dt-blob settings don't end up in the DTB.

User avatar
jack_the_pi_man
Posts: 7
Joined: Fri Sep 07, 2012 7:01 pm
Location: Derby, United Kingdom

Re: Device Tree Changes for Interfacing LAN951X with CM3+

Tue Apr 30, 2019 10:24 pm

Apologies - I know that was a bit long winded. But thank you for your quick reply, PhilE. :D
Yes, I think so. Provided the LAN951X has a clock and has been reset correctly it is just another USB device. The reason for the Device Tree file is not to tell Linux what USB device is present (USB does that already), but to locate the place to set the MAC address.
That makes sense. It's obvious why you'd configure the 'LAN_RUN' pin and even an 'ETH_CLK' pin (if clocking the LAN951X IC via a SoC GPIO) through the DT, but we weren't entirely sure as to the purpose of the contents of that DTSI. So thank you for explaining and saving us ask a further question.
Unless overridden, dt-blob.bin settings will persist for the kernel, but there are usually better ways to configure pins for the kernel.
To clarify - would that most likely be through the use of the base DTB and overlays in conjunction with the Linux PINCTRL Subsystem? Or by other means, such as the GPIO Subsystem? I understand these are open ended questions which will depend on each use-case and application, but any elaboration would be appreciated.
For a Compute Module project with a custom DTB the boundary between base DTB and overlays is fluid. It makes sense to use existing overlays where you can - they are maintained and documented (to a degree) - but its far from compulsory.
Understood and agreed. I would side with the use of overlays for numerous reasons.
U-boot can apply overlays now, but I doubt it understands overlay parameters (a Pi-specific extension).
I'll do some more research into that area. If I find out, I'll let you know.

Thanks for your time,
~ Jack
Jack Winch (jack_the_pi_man) | Avid Geek, Lover of Earl Grey Tea & Guardian of a 200+ RPi System
'It turns out that while it’s easy to undo technical mistakes, it’s not as easy to undo personality disorders.' - TLK Documentation

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

Re: Device Tree Changes for Interfacing LAN951X with CM3+

Wed May 01, 2019 8:17 am

To clarify - would that most likely be through the use of the base DTB and overlays in conjunction with the Linux PINCTRL Subsystem? Or by other means, such as the GPIO Subsystem?
Yes - either of those are better than the dt-blob because i) the kernel is aware of those settings, and ii) custom dt-blobs are harder to maintain because support for new boards or features has to be applied by the downstream provider (if they care). Of the two I would use pinctrl whenever possible - the changes get applied earlier, but if your requirements are to set a specific GPIO to a specific value (e.g. an output driving high) then you may have to resort to the sysfs GPIO interface (although the current kernels do support gpiolib - a more efficient, ioctl-based GPIO API).

One mechanism we haven't touched on yet it is the config.txt "gpio" setting/directive/command. It has most of the advantages of the dt-blob - settings are applied fairly early, doesn't need a kernel driver etc. - but benefits from allowing piecemeal changes, avoiding the maintenance problem. From https://www.raspberrypi.org/documentati ... xt/gpio.md:

Code: Select all

# Select Alt2 for GPIO pins 0 to 27 (for DPI24)
gpio=0-27=a2

# Set GPIO12 to be an output set to 1
gpio=12=op,dh

# Change the pull on (input) pins 18 and 20
gpio=18,20=pu

# Make pins 17 to 21 inputs
gpio=17-21=ip

User avatar
jack_the_pi_man
Posts: 7
Joined: Fri Sep 07, 2012 7:01 pm
Location: Derby, United Kingdom

Re: Device Tree Changes for Interfacing LAN951X with CM3+

Wed May 01, 2019 1:42 pm

Yes - either of those are better than the dt-blob because i) the kernel is aware of those settings, and ii) custom dt-blobs are harder to maintain because support for new boards or features has to be applied by the downstream provider (if they care). Of the two I would use pinctrl whenever possible - the changes get applied earlier, but if your requirements are to set a specific GPIO to a specific value (e.g. an output driving high) then you may have to resort to the sysfs GPIO interface (although the current kernels do support gpiolib - a more efficient, ioctl-based GPIO API).
Makes sense and I have seen the same advice given elsewhere regarding the use of pinctrl and the GPIO subsystem. I am familiar with the sysfs GPIO interface, but was not aware of gpiolib. I will be sure to spend some time looking at that in conjunction with further experimentation with the DT and the pinctrl subsystem.
One mechanism we haven't touched on yet it is the config.txt "gpio" setting/directive/command. It has most of the advantages of the dt-blob - settings are applied fairly early, doesn't need a kernel driver etc. - but benefits from allowing piecemeal changes, avoiding the maintenance problem.
That's a neat feature and handy to know. Thanks for the additional pointer and for your advice.

~ Jack
Jack Winch (jack_the_pi_man) | Avid Geek, Lover of Earl Grey Tea & Guardian of a 200+ RPi System
'It turns out that while it’s easy to undo technical mistakes, it’s not as easy to undo personality disorders.' - TLK Documentation

Return to “Device Tree”