Touble with LibBSD and Beaglebone Black

Good Morning,

I am currently trying to build an application using rtems7 with libbsd on the beaglebone black and I am having some strange issues with the libbsd part that brings up the network interfaces.

nexus0: <RTEMS Nexus device>
ofwbus0: <Open Firmware Device Tree> on nexus0
simplebus0: <Flattened device tree simple bus> on ofwbus0
simplebus1: <Flattened device tree simple bus> on simplebus0
simplebus2: <Flattened device tree simple bus> mem 0x200000-0x203fff on simplebu                                               s1
ti_scm0: <TI OMAP Control Module> mem 0x210000-0x211fff on simplebus1
sdhci_ti0: <TI MMCHS (SDHCI 2.0)> mem 0x48060000-0x48060fff irq 64 on simplebus0
sdhci_ti0: Can not find mmc_clk
device_attach: sdhci_ti0 attach returned 6
sdhci_ti0: <TI MMCHS (SDHCI 2.0)> mem 0x481d8000-0x481d8fff irq 28 on simplebus0
sdhci_ti0: Can not find mmc_clk
device_attach: sdhci_ti0 attach returned 6
cpswss0: <3-port Switch Ethernet Subsystem> mem 0x4a100000-0x4a1007ff,0x4a101200                                               -0x4a1012ff irq 40,41,42,43 on simplebus0
cpswss0: CPSW SS Version 1.12 (0)
cpswss0: Initial queue size TX=128 RX=384
cpsw0: <Ethernet Switch Port> on cpswss0
cpsw0: Failed to find syscon node
cpsw0: Failed to get syscon
device_attach: cpsw0 attach returned 6

This was all the output I got when I attempted to used rtems_bsd_initialize(). For reference I was using the lastest source using 7-freebsd-14 (hash: 307d84eca8cbda05416da1488907fbe17fe3a2be) and this was the
device tree that I was using for the beaglebone black.
am335x-boneblack.dts.txt (59.3 KB)

Very Respectfully,
Rahul Vishnoi

I am a little confused with the boot log reporting a 3-port ethernet switch. I do not think there is one on the standard BBB and the BeagleBone Black Overview does not mention an ethernet switch?

The maybe FDT does not contain any switch nodes because there is no device on the BBB?

I think there is a 3 port ethernet switch on their for some reason internally? For reference aswell, this is what I got when I ran the same application code but compiled to the beaglebone using rtems 5 with the rtems5 version of the libbsd

sdhci_ti0: <TI MMCHS (SDHCI 2.0)> mem 0x48060000-0x48060fff irq 64 on simplebus0
mmc0: <MMC/SD bus> on sdhci_ti0
sdhci_ti1: <TI MMCHS (SDHCI 2.0)> mem 0x481d8000-0x481d8fff irq 28 on simplebus0
mmc1: <MMC/SD bus> on sdhci_ti1
usbss0: <TI AM33xx integrated USB OTG controller> mem 0x47400000-0x47400fff on simplebus0
usbss0: TI AM335X USBSS v0.0.13
musbotg0: <TI AM33xx integrated USB OTG controller> mem 0x47401400-0x474017ff,0x47401000-0x474011ff irq 18 on usbss0
usbus0: Dynamic FIFO sizing detected, assuming 16Kbytes of FIFO RAM
usbus0 on musbotg0
musbotg1: <TI AM33xx integrated USB OTG controller> mem 0x47401c00-0x47401fff,0x47401800-0x474019ff irq 19 on usbss0
usbus1: Dynamic FIFO sizing detected, assuming 16Kbytes of FIFO RAM
usbus1 on musbotg1
cpswss0: <3-port Switch Ethernet Subsystem> mem 0x4a100000-0x4a1007ff,0x4a101200-0x4a1012ff irq 40,41,42,43 on simplebus0
cpswss0: CPSW SS Version 1.12 (0)
cpswss0: Initial queue size TX=128 RX=384
cpsw0: <Ethernet Switch Port> on cpswss0
miibus0: <MII bus> on cpsw0
ukphy0: <Generic IEEE 802.3u media interface> PHY 0 on miibus0
ukphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
info: cpsw0: Ethernet address: d0:39:72:29:a2:9f
fb0: <AM335x LCD controller> mem 0x4830e000-0x4830efff irq 36 on simplebus0
mmcsd0: 30GB <SDHC SD32G 3.0 SN 0000C12A MFG 04/2022 by 39 PH> at mmc0 48.0MHz/4bit/65535-block
mmcsd1: 4GB <MMCHC MMC04G 4.2 SN B2AC41E8 MFG 04/2014 by 254 0x004e> at mmc1 48.0MHz/8bit/65535-block
mmcsd1boot: Additional partition. This is currently not supported in RTEMS.mmcsd1boot0: 1MB partition 1 at mmcsd1
mmcsd1boot: Additional partition. This is currently not supported in RTEMS.mmcsd1boot1: 1MB partition 2 at mmcsd1
mmcsd1rpmb: 131kB partition 3 at mmcsd1
usbus0: 480Mbps High Speed USB v2.0
usbus1: 480Mbps High Speed USB v2.0
Found first Ethernet interface called cpsw0

It looks like all the same steps execpt this time it does not seem to be erroring out with error code 6. I am using the same device tree and the the same function as before to get this. I also ran this with the same hardware configurations as before.

Thanks for checking.

Is freebsd/sys/dev/extres/syscon/syscon.c in the 7-freebsd-14 build?

Is sys/contrib/device-tree/src/arm/ti/omap/am33xx-l4.dtsi from FreeBSD missing from you FDT?

yup, I compiled the 7-freebsd-14 branch of libbsd in for my build when I was setting up my bsp.

I think it is but I am not sure if it is. Is there a way I can check and make sure that i am? I am gonna be real, the whole device tree stuff tends to confuse me quite a bit still :frowning:

I am not sure. I wish we handled FDT better.

The syscon node was not in the FDT you posted so it may mean these include pieces need to be pulled together in some way.

I suggest you have a look in the upstream FreeBSD sources to see how they build the blob. It may give you some hints on which extra FDT pieces you need?

I would welcome a change to the Beagle section of our Beagle User Manual sources to provide some documentation?

So I attempted to just make the device tree by itself using the following commands within the version of freebsd-src that is pointed to by the rtems-libbsd and I got the following results (hash: 5982521fe3dd) :

hokusai@hokusai:~/freebsd-src/sys/contrib/device-tree$ make src/arm/am335x-boneblack.dtb
  DTC     src/arm/am335x-boneblack.dtb
src/arm/am33xx-l4.dtsi:159.18-179.6: Warning (interrupt_provider): /ocp/interconnect@44c00000/segment@200000/target-module@7000/gpio@0: Missing #address-cells in interrupt provider
  also defined at src/arm/am335x-boneblack.dts:28.8-62.3
src/arm/am335x-bone-common.dtsi:211.14-213.4: Warning (interrupt_provider): /ocp/interconnect@44c00000/segment@200000/target-module@b000/i2c@0/tps@24: Missing #address-cells in interrupt provider
  also defined at src/arm/tps65217.dtsi:11.6-68.3
  also defined at src/arm/am335x-bone-common.dtsi:278.6-354.3
src/arm/am33xx-l4.dtsi:1468.18-1480.6: Warning (interrupt_provider): /ocp/interconnect@48000000/segment@0/target-module@4c000/gpio@0: Missing #address-cells in interrupt provider
  also defined at src/arm/am335x-boneblack.dts:64.8-98.3
src/arm/am33xx-l4.dtsi:1871.18-1882.6: Warning (interrupt_provider): /ocp/interconnect@48000000/segment@100000/target-module@ac000/gpio@0: Missing #address-cells in interrupt provider
  also defined at src/arm/am335x-boneblack.dts:100.8-134.3
src/arm/am33xx-l4.dtsi:1907.18-1920.6: Warning (interrupt_provider): /ocp/interconnect@48000000/segment@100000/target-module@ae000/gpio@0: Missing #address-cells in interrupt provider
  also defined at src/arm/am335x-boneblack.dts:136.8-170.3
src/arm/am33xx-l4.dtsi:899.44-909.7: Warning (interrupt_provider): /ocp/interconnect@4a000000/segment@0/target-module@300000/pruss@0/interrupt-controller@20000: Missing #address-cells in interrupt provider
src/arm/am33xx.dtsi:206.39-211.5: Warning (interrupt_provider): /ocp/interrupt-controller@48200000: Missing #address-cells in interrupt provider
hokusai@hokusai:~/freebsd-src/sys/contrib/device-tree$ git status
HEAD detached at 5982521fe3dd
Untracked files:
  (use "git add <file>..." to include in what will be committed)
	src/arm/.am335x-boneblack.dtb.cmd
	src/arm/.am335x-boneblack.dtb.d.dtc.tmp
	src/arm/.am335x-boneblack.dtb.d.pre.tmp
	src/arm/.am335x-boneblack.dtb.dts.tmp
	src/arm/am335x-boneblack.dtb

nothing added to commit but untracked files present (use "git add" to track)
hokusai@hokusai:~/freebsd-src/sys/contrib/device-tree$ 

When I ran this I got a slightly different error but still the same error code of 6 which I think means that the device tree does not have the contents rtems’ looks for ?

nexus0: <RTEMS Nexus device>
ofwbus0: <Open Firmware Device Tree> on nexus0
ti_sysc0: <TI SYSC Interconnect> on ofwbus0
device_attach: ti_sysc0 attach returned 6
ti_sysc0: <TI SYSC Interconnect> on ofwbus0
device_attach: ti_sysc0 attach returned 6

I did not change anything in the application itself. I am really sure where or what to try doing next ngl.

If you have the previous version and this one I would diff them to see what changed?

I guess this will need to be debugged to get it working?

That is true, I will have to take a look at it on the weekend. I wonder if I can try just building a freebsd os for the beaglebone black and then just rip the device tree of it once I see that it works with freebsd?

I guess one question I do have is, how exactly does rtems utilize device trees and how do the drivers actually work with rtems? I feel like that is the biggest black box for me rn

FDT is RTEMS is not uniform and has been added on an ad-hoc basis to a number of BSPs. I understand your frustration and why you consider it a black box, I also think of the support that way.

LibBSD is moving more and more to FDT support as this is used more and more in FreeBSD. The FDT on the BBB is needed for LibBSD and it needs to match the version of LibBSD you are using.

Wanted to mention that I’m getting the exact same errors as the original poster. Running RTEMS 7 with 7-freebsd-14 and generated the dtb using the freebsd tools from the corresponding hash. I saw on a different post from @Ning that he was able to run RTEMS7 on a beagleboneblack using the following info:

  • Located in BBB Debian system:
    • /boot/dtbs/5.10.168-ti-r71/am335x-boneblack.dtb

^Pasted from his post. Does this mean we have to build the debian image and grab the dtb from there? Not sure if he was able to solve this, but rolling back to RTEMS 5 for the time being.