Improving usage of device trees

Using device trees is one of the most complicated and important, and sometimes risky, elements of using a Beagle to make use of add-on hardware. With the addition of the AM5729-based BeagleBone AI to the family of boards sporting BeagleBone headers, the complications have increased, requiring additional considerations with dependencies on different processor pins connected to different header pins and a different peripheral mix. Further, AM5729 won’t be the last processor where Beagle uses on a board with BeagleBone headers!

Further, in community efforts to add dynamic support for device tree overlays into the upstream Linux, much has changed for users in how changes to the device tree can be applied. This has resulted in many resources for working with device tree and Beagle to be out of date.

Beagle is committed to making this experience better for all embedded Linux users. We’ve introduced some ideas we think will help resolve much of this complexity for end users. To that end, we’ve begun a project with Bootlin to bring some of these ideas to fruition as well as to provide some definitive documentation for users.

We’ll be starting with a blog series that begins with how things work today, with an eye on the challenges that might be addressed moving forward. When reviewing the first blog post, I had some concerns it didn’t dive deeply enough into some of our proposed solution elements. To that end, I wanted to make this introductory post to let you know that more is coming!

P.S. For those that like to read-ahead, this elinux wiki page provides some preliminary work on how some BeagleBone header abstraction might be provided and this kernel documentation provides a bit of information on how the running device tree can be modified in the upstream kernel.

One thought on “Improving usage of device trees

  1. Hi

    I am using the Beaglebone black Rev C.1 (AM3358 ZCZ) board to interface DP83848I-POE-EK Texas Instruments to evaluate the ethernet PHY TI DP83848i
    over MII interface.
    However, as I know the BBB Debian Linux OS mdio bus device driver supports for LAN8710, DB83848c,..etc,
    I had planned to use the BBB Debian Linux OS to interface DP83848I-POE-EK by setting as following

    Set pr1_mii0_xxx pins mux options for pr1 MII0 Signals instead LAN8710 interface. The MII0 Signals are coming on the P8 connector.
    decided to disable or set GPIO mode of the GPMII1 mode0 interface which are currently being used for LAN7810A.
    mux setting of GPI and pr1_mii0 to be done by using .dts config without any code changes.

    In this above said condition the LAN7810A shall not be interfaced and the DP83848I PHY must be detected for mac interface without any device driver modification or development .

    But I am facing one problem for accessing the MDIO,MDC pins interface for DP83848I. I don’t see the pins MDC and MDIO coming to P8 or P9 connector to use different PHY options as pr1_mii0 control signals are coming on the P8 connector.

    Kindly let me know anybody had tried to use another PHY transceiver interfaces with BBB (AM3358 ZCZ) by using MII0 and MDIO,MDC pin interface.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.