We use cookies to provide our visitors with an optimal site experience. View our privacy notice and cookie notice to learn more about how we use cookies and how to manage your settings. By proceeding on our website you consent to the use of cookies.
Here’s what Google AI says about the subject. Of course there’s no device tree examples for switch mode.
The dual_emac property in the CPSW device tree node has been replaced by a different mechanism using VLAN filtering in recent Linux kernels, including kernel 6.1.
Instead of a dedicated dual_emac property, the kernel now uses a switchdev model, where the desired operation mode (switch or dual EMAC) is determined by how the network interfaces are configured in the Linux networking stack (e.g., using a bridge and VLAN settings), rather than a static device tree property.
Specifically:
The driver defaults to a switch mode configuration, presenting a single network interface (e.g., eth0) to the host CPU, with all physical ports part of the internal switch.
To achieve the functionality previously provided by dual_emac mode (where two separate network interfaces, e.g., eth0 and eth1, are exposed), you must now configure a software bridge in the Linux network stack and set it to a VLAN-unaware mode, or adjust the default PVIDs of the individual switch ports. The driver then manages the ports using internal VLAN IDs (typically 1 and 2 by default for the two slaves) to segregate traffic and achieve the dual interface behavior.
This change allows for more flexible configuration through standard Linux networking tools (like ip and bridge commands) instead of requiring a specific device tree flag. You can find more details on how to configure this in the Linux Kernel Documentation for the TI CPSW switchdev driver.
Now I’m having issues with gpiod. I remember having the same issues back when I tried migrating to 5.10-bone-rt, but it worked fine with 5.10-ti–rt, so I used it instead. The problem with the 5.x and 6.x bone-rt kernel is that all the gpios are off by one port. According to the Beagbone Black device tree and schematic, the usr0-usr3 LEDs should be on gpiochip1, not gpiochip0.
debian@BeagleBone:~$ gpioinfo -c gpiochip0
gpiochip0 - 32 lines:
line 0: “P8_25 [mmc1_dat0]” input
line 1: “[mmc1_dat1]” input
line 2: “P8_5 [mmc1_dat2]” input
line 3: “P8_6 [mmc1_dat3]” input
line 4: “P8_23 [mmc1_dat4]” input
line 5: “P8_22 [mmc1_dat5]” input
line 6: “P8_3 [mmc1_dat6]” input
line 7: “P8_4 [mmc1_dat7]” input
line 8: “NC” output active-low consumer=“PHY reset”
line 9: “NC” input
line 10: “NC” input
line 11: “NC” input
line 12: “P8_12” input
line 13: “P8_11” input
line 14: “P8_16” input
line 15: “P8_15” input
line 16: “P9_15A” input
line 17: “P9_23” input
line 18: “P9_14 [ehrpwm1a]” input
line 19: “P9_16 [ehrpwm1b]” input
line 20: “[emmc rst]” input
line 21: “[usr0 led]” output consumer=“beaglebone:green:usr0”
line 22: “[usr1 led]” output consumer=“beaglebone:green:usr1”
line 23: “[usr2 led]” output consumer=“beaglebone:green:usr2”
line 24: “[usr3 led]” output consumer=“beaglebone:green:usr3”
line 25: “[hdmi irq]” input
line 26: “[usb vbus oc]” input
line 27: “[hdmi audio]” output consumer=“enable”
line 28: “P9_12” input
line 29: “P8_26” input
line 30: “P8_21 [emmc]” input
line 31: “P8_20 [emmc]” input
Oh ya… now I remember you suggesting this last time hit this problem. The only thing keeping me from using the gpio-leds and gpio-key on all of my gpio is that some of them are constantly changing their direction, similar to how a keyboard matrix works when it “scans” for a key press.
Fortunately, the bidirectional gpios are not on gpiochip0, so I can just subtract 1 from the gpiochipX for those gpios.
Oh, but I found here where you said it was due to a race condition:
So I can’t count on the “subtract 1” method to work everytime.
The last comment in the thread said:
“Since it is because of random race conditions, I use device tree overlay and load manually when boot. Seems libgpiod is happy now.”
I’m making some progress on my gpios, except for the bi-directional pins. I think I’m missing some magic that the “dir-changeable” property of the “gpio-of-helper” was doing to make things work. I can’t find any documentation on what that property actually did.
Well this is embarrassing… When I removed the “gpio-of-helper” section from my v5.10 device tree to make my v6.1 device tree, I didn’t realize there was no longer anything setting the pin muxes for my gpios.
That’s the magic I was missing, not the “dir-changeable” property.
I noticed the newer kernel isn’t cleaning up the /tmp folder on reboot like the older one I’ve been using. I can probably come up with my own way to do this, but it might be better to figure out what changed, and change it back.
Do you know what changed in the kernel that caused it now to clean up the /tmp folder on reboots?
Do you know if I can execute that command when I’m chroot’ed into Linux partition during my SD card image build? Or does it need to be done on first time boot?
