Linux 5.x new release uses refined device trees and includes. Nice, but how do you patch now the bit that was in a DTS is now in a DTSI. Disabling the HDMI so I can use SPI0

268 views

Skip to first unread message

Rich_d

unread,

Apr 9, 2020, 8:59:37 PM4/9/20

to BeagleBoard

Hi,

I have been told to stay indoors for 12 weeks. So I decided to learn the AM355x, Linux and C++ and sort out some code that is well past its sell by date.

This is for a clinical project I am doing

My board is a hacked beaglebone black, it has a real time clock, a SPIO to drive a FT800 based LCD display, an I2C to drive some instruments. All has worked for years but the software was really bad so I decided to make my own, since I have time on my hands. The last programming I did was in Pascal.

Last week I learned to use Buildroot, made a new beaglebone black Linux, and then started to update my patches.

C++ is coming along nicely, as it doesn't completely crash your PC like it did 25 years ago. (so far so good)

HDMI used on the regular board will interfere with my use of SPI0. Easily done with a patch. The old blackbone source, had a source called boneblack.dts which had the HDMI pin definitions in it. Now there is a problem with recent blackbone device tree sources, to tidy things up they have moved the definitions over from the DTS to a new DTSI.

The old Linux had a DTS like this:

/*
* Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
/dts-v1/;

#include "am33xx.dtsi"
#include "am335x-bone-common.dtsi"
#include <dt-bindings/display/tda998x.h>

/ {
model = "TI AM335x BeagleBone Black";
compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx";
};

&ldo3_reg {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
};

&mmc1 {
vmmc-supply = <&vmmcsd_fixed>;
};

&mmc2 {
vmmc-supply = <&vmmcsd_fixed>;
pinctrl-names = "default";
pinctrl-0 = <&emmc_pins>;
bus-width = <8>;
status = "okay";
};

&am33xx_pinmux {
nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x9b0, PIN_OUTPUT_PULLDOWN | MUX_MODE3) /* xdma_event_intr0 */
AM33XX_IOPAD(0x8a0, PIN_OUTPUT | MUX_MODE0) /* lcd_data0.lcd_data0 */
AM33XX_IOPAD(0x8a4, PIN_OUTPUT | MUX_MODE0) /* lcd_data1.lcd_data1 */
AM33XX_IOPAD(0x8a8, PIN_OUTPUT | MUX_MODE0) /* lcd_data2.lcd_data2 */
AM33XX_IOPAD(0x8ac, PIN_OUTPUT | MUX_MODE0) /* lcd_data3.lcd_data3 */
AM33XX_IOPAD(0x8b0, PIN_OUTPUT | MUX_MODE0) /* lcd_data4.lcd_data4 */
AM33XX_IOPAD(0x8b4, PIN_OUTPUT | MUX_MODE0) /* lcd_data5.lcd_data5 */
AM33XX_IOPAD(0x8b8, PIN_OUTPUT | MUX_MODE0) /* lcd_data6.lcd_data6 */
AM33XX_IOPAD(0x8bc, PIN_OUTPUT | MUX_MODE0) /* lcd_data7.lcd_data7 */

So to patch

@@ -9,7 +9,6 @@

#include "am33xx.dtsi"
#include "am335x-bone-common.dtsi"
-#include <dt-bindings/display/tda998x.h>

/ {
  model = "TI AM335x BeagleBone Black";
@@ -44,142 +43,3 @@
   opp-supported-hw = <0x06 0x0100>;
  };
};
-
-&am33xx_pinmux {
- nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins {
-  pinctrl-single,pins = <
-   0x1b0 0x03      /* xdma_event_intr0, OMAP_MUX_MODE3 | AM33XX_PIN_OUTPUT */
-   0xa0 0x08       /* lcd_data0.lcd_data0, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xa4 0x08       /* lcd_data1.lcd_data1, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xa8 0x08       /* lcd_data2.lcd_data2, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */

etc etc etc.

However, in newer versions these definitions are pushed out neatly into some "dtsi" includes.

The DTSI has the branch defintions in it now:-

So, according to my understanding:

Making patches to change the DTS is fine, as this DTS refers to a single board, however making changes to the DTSI

is a definitely "no-no".

If you change the DTSI, other DTS which refer to it will just cause error - with Buildroot this is like an error 2, (i.e. fatal).

My plan is to patch the DTS but this time, deactivating and de-allocate the HDMI pins and disable devices declared by default in the DTSI, for example:-

&tda19988 {

status = "disabled";
};

&mcasp0 {
status = "disabled";
};

/* remove the HDMI as it will stop the SPI0 working */

&am33xx_pinmux {
nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins {
pinctrl-single,pins = <
AM33XX_IOPAD(0x9b0, ????? ) /* xdma_event_intr0 */
AM33XX_IOPAD(0x8a0, ????? ) /* lcd_data0.lcd_data0 */
AM33XX_IOPAD(0x8a4, ????? ) /* lcd_data1.lcd_data1 */

If this is the right approach, where on earth can I find the constant definitions and notes to choose the right ones?

I would just like to reallocate with no pull up or down, disconnect any clocks, etc etc so I can get on and add my other patches.

Is there a file somewhere I can see the definitions of the constants, so I can overlay the HDMI definitions so they don't get assigned?

Take care, may the only viruses you encounter be viral videos of funny kittens.

Cheers

Rich

Robert Nelson

unread,

Apr 9, 2020, 11:47:49 PM4/9/20

to Beagle Board, culb...@gmail.com

On Thu, Apr 9, 2020 at 7:59 PM Rich_d <culb...@gmail.com> wrote:
>
>
> Hi,
>
> I have been told to stay indoors for 12 weeks. So I decided to learn the AM355x, Linux and C++ and sort out some code that is well past its sell by date.
>
> This is for a clinical project I am doing
>
> My board is a hacked beaglebone black, it has a real time clock, a SPIO to drive a FT800 based LCD display, an I2C to drive some instruments. All has worked for years but the software was really bad so I decided to make my own, since I have time on my hands. The last programming I did was in Pascal.
>
> Last week I learned to use Buildroot, made a new beaglebone black Linux, and then started to update my patches.
> C++ is coming along nicely, as it doesn't completely crash your PC like it did 25 years ago. (so far so good)
>
> HDMI used on the regular board will interfere with my use of SPI0. Easily done with a patch. The old blackbone source, had a source called boneblack.dts which had the HDMI pin definitions in it. Now there is a problem with recent blackbone device tree sources, to tidy things up they have moved the definitions over from the DTS to a new DTSI.

So based on your details so far... Why are you still booting it as
"BeagleBone Black"? Your hardware more closely resembles, the
"BeagleBone Green"

Green = Black with no HDMI (plus 1 more usart enabled..)

If i was in your shoe's, i'd just start with the BeagleBone Green's
dts and add what you need..

Regards,

--
Robert Nelson
https://rcn-ee.com/

Reply all

Reply to author

Forward

0 new messages