I have recently tried to take some steps into learning how to use Yocto and leverage some of the functionality provided. I have a BeagleBone Black and wanted to use this as my device to build a custom kernel using Yocto. I have been following the following tutorial series to understand the basics of yocto: https://www.youtube.com/watch?v=9vsu67uMcko&list=PLEBQazB0HUyTpoJoZecRK6PpDG31Y7RPB.
My current objective is to patch the existing device tree used by the Poky reference distribution to enable UART4, the UART port that is accessible through the BeagleBone Black through GPIO header.
I have taken a look at the am335x-boneblack.dts file and the included dtsi files and understand which files need to be modified to enable the UART4 port. In specific, I see that the am335x-bone-common.dtsi and am33xx-l4.dtsi files have pertinent snippets of information related to UART.
The patch file that I add to a new layer and apply is shown below:
diff --git a/orig/am335x-bone-common.dtsi b/altered/am335x-bone-common.dtsi
index 0ccdc7c..8a2541c 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
## -95,6 +95,14 ##
AM33XX_PADCONF(AM335X_PIN_UART0_TXD, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
>;
};
+
+ uart4_pins: pinmux_uart4_pins {
+ pinctrl-single,pins = <
+ AM33XX_PADCONF(AM335X_PIN_GPMC_WAIT0, PIN_INPUT_PULLUP, MUX_MODE6)
+ AM33XX_PADCONF(AM335X_PIN_GPMC_WPN, PIN_OUTPUT_PULLDOWN, MUX_MODE6)
+ >;
+ };
+
clkout2_pin: pinmux_clkout2_pin {
pinctrl-single,pins = <
## -191,6 +199,13 ##
status = "okay";
};
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart4_pins>;
+
+ status = "okay";
+};
+
&usb0 {
dr_mode = "peripheral";
interrupts-extended = <&intc 18 &tps 0>;
diff --git a/orig/am33xx-l4.dtsi b/altered/am33xx-l4.dtsi
index c9629cb..637a1a7 100644
--- a/arch/arm/boot/dts/am33xx-l4.dtsi
+++ b/arch/arm/boot/dts/am33xx-l4.dtsi
## -1802,7 +1802,7 ##
clock-frequency = <48000000>;
reg = <0x0 0x1000>;
interrupts = <45>;
- status = "disabled";
+ status = "okay";
};
};
When I build my kernel, the resulting .dtb file reflects the changes, however when I try to boot off of the SD card, the beaglebone halts at
Starting kernel ...
If anyone can offer some help, I'd be greatful!
Regards
So, it would seem that the kernel doesn't really hang when enabling UART4.
For some reason, UART4 gets mapped to ttyS0 - which breaks the console output.
Setup:
Beaglebone Black - Yocto Kirkstone - Machine: beaglebone-yocto.
This is the relevant part from am335x-bone-common.dtsi:
uart0_pins: pinmux_uart0_pins {
pinctrl-single,pins = <
AM33XX_PADCONF(AM335X_PIN_UART0_RXD, PIN_INPUT_PULLUP, MUX_MODE0) /* Debug Header - UART0_RX */
AM33XX_PADCONF(AM335X_PIN_UART0_TXD, PIN_OUTPUT_PULLDOWN, MUX_MODE0) /* Debug Header - UART0_TX */
>;
};
uart1_pins: pinmux_uart1_pins {
pinctrl-single,pins = <
AM33XX_PADCONF(AM335X_PIN_UART1_RXD, PIN_INPUT_PULLUP, MUX_MODE0) /* P9-26 UART1_RX */
AM33XX_PADCONF(AM335X_PIN_UART1_TXD, PIN_OUTPUT_PULLDOWN, MUX_MODE0) /* P9-24 UART1_TX */
>;
};
uart2_pins: pinmux_uart2_pins {
pinctrl-single,pins = <
AM33XX_PADCONF(AM335X_PIN_SPI0_SCLK, PIN_INPUT_PULLUP, MUX_MODE1) /* P9-22 UART2_RX */
AM33XX_PADCONF(AM335X_PIN_SPI0_D0, PIN_OUTPUT_PULLDOWN, MUX_MODE1) /* P9-21 UART2_TX */
>;
};
uart4_pins: pinmux_uart4_pins {
pinctrl-single,pins = <
AM33XX_PADCONF(AM335X_PIN_GPMC_WAIT0, PIN_INPUT, MUX_MODE6) /* P9-11 UART4_RX */
AM33XX_PADCONF(AM335X_PIN_GPMC_WPN, PIN_OUTPUT_PULLDOWN, MUX_MODE6) /* P9-13 UART4_TX */
>;
};
Once the board boots - I can SSH into it from Ethernet. Here's the output from pinctrl and serial:
root#beaglebone-yocto:~# cat /sys/kernel/debug/pinctrl/pinctrl-maps
Pinctrl maps:
device 44e10800.pinmux
state default
type MUX_GROUP (2)
controlling device 44e10800.pinmux
group pinmux_clkout2_pin
function pinmux_clkout2_pin
device 48022000.serial
state default
type MUX_GROUP (2)
controlling device 44e10800.pinmux
group pinmux_uart1_pins
function pinmux_uart1_pins
device 48024000.serial
state default
type MUX_GROUP (2)
controlling device 44e10800.pinmux
group pinmux_uart2_pins
function pinmux_uart2_pins
device 4819c000.i2c
state default
type MUX_GROUP (2)
controlling device 44e10800.pinmux
group pinmux_i2c2_pins
function pinmux_i2c2_pins
device 481a8000.serial
state default
type MUX_GROUP (2)
controlling device 44e10800.pinmux
group pinmux_uart4_pins
function pinmux_uart4_pins
device 4a100000.switch
state default
type MUX_GROUP (2)
controlling device 44e10800.pinmux
group cpsw_default
function cpsw_default
device 4a100000.switch
state sleep
type MUX_GROUP (2)
controlling device 44e10800.pinmux
group cpsw_sleep
function cpsw_sleep
device 4a101000.mdio
state default
type MUX_GROUP (2)
controlling device 44e10800.pinmux
group davinci_mdio_default
function davinci_mdio_default
device 4a101000.mdio
state sleep
type MUX_GROUP (2)
controlling device 44e10800.pinmux
group davinci_mdio_sleep
function davinci_mdio_sleep
device 44e09000.serial
state default
type MUX_GROUP (2)
controlling device 44e10800.pinmux
group pinmux_uart0_pins
function pinmux_uart0_pins
device 44e0b000.i2c
state default
type MUX_GROUP (2)
controlling device 44e10800.pinmux
group pinmux_i2c0_pins
function pinmux_i2c0_pins
device 48060000.mmc
state default
type MUX_GROUP (2)
controlling device 44e10800.pinmux
group pinmux_mmc1_pins
function pinmux_mmc1_pins
device 481d8000.mmc
state default
type MUX_GROUP (2)
controlling device 44e10800.pinmux
group pinmux_emmc_pins
function pinmux_emmc_pins
root#beaglebone-yocto:~# cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:8250 mmio:0x481A8000 irq:35 tx:871 rx:0 RTS|CTS|DTR|DSR
1: uart:8250 mmio:0x48022000 irq:24 tx:0 rx:0 CTS|DSR|CD|RI
2: uart:8250 mmio:0x48024000 irq:25 tx:0 rx:0 CTS|DSR
3: uart:8250 mmio:0x44E09000 irq:18 tx:0 rx:0 CTS|D
As you can see, UART4 gets mapped to /dev/ttyS0 and UART0 gets mapped to /dev/ttyS3 after bootup.
I'm not sure why UART4 gets mapped to ttyS0 and not ttyS4.
I can't even see /dev/ttyS4 despite it being an alias in the am33xx.dtsi
root#beaglebone-yocto:~# ls -la /dev/ttyS*
crw--w---- 1 root tty 4, 64 Mar 9 12:45 /dev/ttyS0
crw-rw---- 1 root dialout 4, 65 Jan 1 2000 /dev/ttyS1
crw-rw---- 1 root dialout 4, 66 Jan 1 2000 /dev/ttyS2
crw-rw---- 1 root dialout 4, 67 Jan 1 2000 /dev/ttyS3
I'm working with a Q7 Module (x86) and try to configure our peripherals with ACPI SSDT Overlay on Linux. But I strugle with it. I think I missunderstand some of the core concept of ACPI.
Problem
CPU -> I2C -> PCA9575 GPIO Expander -> virtual,mdio-gpio -> Ethernet Phy
What works
DefinitionBlock ("abc.asl", "SSDT", 2, "test", "HAL", 2)
{
External (\_SB_.PCI0.D01D, DeviceObj)
Scope (\_SB.PCI0.D01D)
{
Device (ABC0)
{
Name (_HID, "PRP0001") // must be PRP0001 that linux searches for compatible driver
Name (_CRS, ResourceTemplate () {
I2cSerialBusV2 (
0x20, // SlaveAddress : I2C Address
ControllerInitiated, // SlaveMode : ControllerInitiated
100000, // ConnectionSpeed : max Bus Speed for this device
AddressingMode7Bit, // AddressingMode : Adress Mode
"\\_SB.PCI0.D01D", // ResourceSource : I2C host controller
0x00, // ResourceSourceIndex : must be 0
ResourceConsumer, // ResourceUsage : must be ResourceConsumer
, // DescriptorName : optional name for integer value which is an offset to a buffer field...
Exclusive // Shared : Shared or Exclusive
,) // VendorData : optional field
})
Name (_DSD, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package (2) { "compatible", "nxp,pca9575" },
Package () { "gpio-line-names", Package ()
{ "LED_Red",
"",
"MDC",
"MDIO",
}
},
},
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "led-red", "LED0" },
Package () { "mdc-gpios", "MDC0" },
Package () { "mdio-gpios", "MDIO" },
}
})
Name (LED0, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"gpio-hog", 1},
Package () {"gpios", Package () {0, 1}},
Package () {"output-low", 1},
}
})
... <placeholder for virtual,mdio-gpiocode here> ...
}
}
}
It recognises the PCA9575 GPIO expander and registering it as gpiochip in Linux. The LED is fixed to low and "hogged". It seems that this part is not totally wrong.
What not works
I inserted this code into the placeholder
Device (MD00)
{
Name (_HID, "PRP0001") // must be PRP0001 that linux searches for compatible driver
Name (_DSD, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package (2) { "compatible", "virtual,mdio-gpio" },
Package () {"gpios", Package () {^MDC0, 2, 0,
^MDIO, 3, 0,}},
}
})
}
But when I try to load this file via configfs I can see an error message in dmesg that the compatible field for the defined resource in _CRS field is missing. But I don't even defined a _CRS field.
I'm also not sure if my GPIO's are defined correctly. I'm not able to set the Pull-Modes with the Package () {"gpios", Package () {0, 1}}, command.
I question myself, shall the GPIO Expander Ports again defined as GgioIo Structures in the MDO Device?
Name (_CRS, ResourceTemplate () {
GpioIo (Exclusive, PullNone, 0, 0, IoRestrictionNone,
"\\_SB.PCI0.D01D.ABC0", 0, ResourceConsumer) {2}
GpioIo (Exclusive, PullNone, 0, 0, IoRestrictionNone,
"\\_SB.PCI0.D01D.ABC0", 0, ResourceConsumer) {3}
})
It doesn't seem to work either and I'm confused. I'm not sure if I use the GPIO PCA9575 driver correctly. Where could I configure the pull bias in ACPI? The driver load the config from of_ but I don't know where to define it in ACPI. I hope somebody here got an idea.
First of all let's see the main architecture of the design:
+-------------------+
| HOST | +------+
| MDIO <------>+ MDIO |
| Intf | | Phy |
| | +--^---+
| +------+ | | +-----+
| | I²C | | | | LED |
| | host | | | +--^--+
| +--^---+ | | |
| | | +--+---+ |
+-------------------+ | I²C | |
+----------------------> GPIO +------+
+------+
From this schematic we see how devices are related to each other. Now let's move to ACPI representation. At the beginning we need to define I²C GPIO expander. From the examples in meta-acpi project we can find how PCA9535 can be described. Assuming we found the I²C host controller device (\_SB_.PCI0.D01D as per your post) and the fact that you have expander without latching IRQ events, the following is the mix between original ASL excerpt and how to match it with proper configuration in the driver:
Device (ABC0)
{
Name (_HID, "PRP0001")
Name (_DDN, "NXP PCA9575 GPIO expander")
Name (RBUF, ResourceTemplate()
{
I2cSerialBusV2(0x0020, ControllerInitiated, 400000,
AddressingMode7Bit, "\\_SB.PCI0.D01D",
0x00, ResourceConsumer, , Exclusive, )
})
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"compatible", "nxp,pca9575"},
Package () {"gpio-line-names", Package () {
"LED_Red",
"",
"MDC",
"MDIO",
}},
}
})
Method (_CRS, 0, NotSerialized)
{
Return (RBUF)
}
Method (_STA, 0, NotSerialized)
{
Return (0x0F)
}
}
This excerpt provides us a new GPIO chip in the system, resources of which can be consumed by others.
For example, in your Virtual MDIO Phy case (see _DSD Device Properties Related to GPIO as well)
Device (MD00)
{
Name (_HID, "PRP0001")
Name (_CRS, ResourceTemplate () {
GpioIo (Exclusive, PullDown, 0, 0, IoRestrictionOutputOnly,
"\\_SB.PCI0.D01D.ABC0", 0, ResourceConsumer) {2} // pin 2
GpioIo (Exclusive, PullDown, 0, 0, IoRestrictionOutputOnly,
"\\_SB.PCI0.D01D.ABC0", 0, ResourceConsumer) {3} // pin 3
})
Name (_DSD, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "compatible", "virtual,mdio-gpio" },
Package () {
"gpios", Package () {
^MD00, 0, 0, 0, // index 0 in _CRS -> pin 2
^MD00, 1, 0, 0, // index 1 in _CRS -> pin 3
}
},
}
})
}
Now it is a time to look at the LED binding code. For the sake of clarification hogging is when you want a GPIO provider to consume a resource itself. And it is quite likely not your case. Better is to connect this with the LED GPIO driver:
Device (LEDS)
{
Name (_HID, "PRP0001")
Name (_DDN, "GPIO LEDs device")
Name (_CRS, ResourceTemplate () {
GpioIo (
Exclusive, // Not shared
PullUp, // Default off
0, // Debounce timeout
0, // Drive strength
IoRestrictionOutputOnly, // Only used as output
"\\_SB.PCI0.D01D.ABC0", // GPIO controller
0) // Must be 0
{
0, // LED_Red
}
})
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "compatible", Package() { "gpio-leds" } },
},
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "led-0", "LED0" },
}
})
/*
* For more information about these bindings see:
* Documentation/devicetree/bindings/leds/common.yaml,
* Documentation/devicetree/bindings/leds/leds-gpio.yaml and
* Documentation/firmware-guide/acpi/gpio-properties.rst.
*/
Name (LED0, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "label", "red" },
Package () { "default-state", "on" },
Package () { "gpios", Package () { ^LEDS, 0, 0, 1 } }, // active low
}
})
}
Also you may look into similar questions (starting from the given link and there are references to the rest) on StackOverflow site.
I'm trying to compile a library from this repo. Running make test in the root folder produces an executable file tests that depends on libpcreposix and libpcre. The linking line looks like this:
gfortran -std=f2008 -fall-intrinsics -ffree-line-length-none -Wall -Wextra -Wpedantic -Wno-target-lifetime -Wno-compare-reals -Jbuild.gnu.debug -g -Og -fcheck=bounds,do,mem,pointer,recursion -Isrc -Itests -DUSE_PCRE tests/tests.F90 build.gnu.debug/*.o -lpcreposix -lpcre -o build.gnu.debug/tests
As you can see, the required libraries are linked via -lpcreposix -lpcre and this line executes successfully, producing executable tests, which, however, crashes at runtime. I strongly suspect that this crash has something to do with these libraries, so I ran ldd tests, which showed the following output:
$ ldd build.gnu.debug/tests
linux-vdso.so.1 (0x00007ffe5b481000)
libgfortran.so.5 => /usr/lib/x86_64-linux-gnu/libgfortran.so.5 (0x00007fd307a59000)
libm.so.6 => /usr/lib/x86_64-linux-gnu/libm.so.6 (0x00007fd30790a000)
libgcc_s.so.1 => /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fd3078ef000)
libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007fd3078a5000)
libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007fd3076b3000)
/lib64/ld-linux-x86-64.so.2 (0x00007fd307e24000)
As you can see, libpcreposix and libpcre and not even on this list. The libraries were installed via sudo apt install libpcre3 libpcre3-dev and I can see them in /usr/lib/x86_64-linux-gnu/libpcreposix.so.3.13 and /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3. I have added this path to LD_LIBRARY_PATH (which did not even exist before that), but it did not change anything.
$ echo $LD_LIBRARY_PATH
/usr/lib/x86_64-linux-gnu
The executable tests definitely depends on these libraries, but just in case I have also tried to add -Wl,--no-as-needed to the linking line, which also did not change anything. I have tried the exact same sequence of actions on another machine and it worked without issues (and I was able to see the required libraries in the output of ldd), so it has to be related with the setup of my machine. The machine where I have issues is a recently created virtual machine (Ubuntu 20), so I might have forgotten to install of set up something here.
Edit:
Output of linking with -Wl,--verbose:
$ gfortran -std=f2008 -fall-intrinsics -ffree-line-length-none -Wall -Wextra -Wpedantic -Wno-target-lifetime -Wno-compare-reals -Jbuild.gnu.debug -g -Og -fcheck=bounds,do,mem,pointer,recursion -Isrc -Itests -DUSE_PCRE tests/tests.F90 build.gnu.debug/*.o -lpcreposix -lpcre -o build.gnu.debug/tests -Wl,--verbose
GNU ld (GNU Binutils for Ubuntu) 2.34
Supported emulations:
elf_x86_64
elf32_x86_64
elf_i386
elf_iamcu
elf_l1om
elf_k1om
i386pep
i386pe
using internal linker script:
==================================================
/* Script for -pie -z combreloc -z separate-code -z relro -z now */
/* Copyright (C) 2014-2020 Free Software Foundation, Inc.
Copying and distribution of this script, with or without modification,
are permitted in any medium without royalty provided the copyright
notice and this notice are preserved. */
OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64",
"elf64-x86-64")
OUTPUT_ARCH(i386:x86-64)
ENTRY(_start)
SEARCH_DIR("=/usr/local/lib/x86_64-linux-gnu"); SEARCH_DIR("=/lib/x86_64-linux-gnu"); SEARCH_DIR("=/usr/lib/x86_64-linux-gnu"); SEARCH_DIR("=/usr/lib/x86_64-linux-gnu64"); SEARCH_DIR("=/usr/local/lib64"); SEARCH_DIR("=/lib64"); SEARCH_DIR("=/usr/lib64"); SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib"); SEARCH_DIR("=/usr/x86_64-linux-gnu/lib64"); SEARCH_DIR("=/usr/x86_64-linux-gnu/lib");
SECTIONS
{
PROVIDE (__executable_start = SEGMENT_START("text-segment", 0)); . = SEGMENT_START("text-segment", 0) + SIZEOF_HEADERS;
.interp : { *(.interp) }
.note.gnu.build-id : { *(.note.gnu.build-id) }
.hash : { *(.hash) }
.gnu.hash : { *(.gnu.hash) }
.dynsym : { *(.dynsym) }
.dynstr : { *(.dynstr) }
.gnu.version : { *(.gnu.version) }
.gnu.version_d : { *(.gnu.version_d) }
.gnu.version_r : { *(.gnu.version_r) }
.rela.dyn :
{
*(.rela.init)
*(.rela.text .rela.text.* .rela.gnu.linkonce.t.*)
*(.rela.fini)
*(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*)
*(.rela.data .rela.data.* .rela.gnu.linkonce.d.*)
*(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*)
*(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*)
*(.rela.ctors)
*(.rela.dtors)
*(.rela.got)
*(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*)
*(.rela.ldata .rela.ldata.* .rela.gnu.linkonce.l.*)
*(.rela.lbss .rela.lbss.* .rela.gnu.linkonce.lb.*)
*(.rela.lrodata .rela.lrodata.* .rela.gnu.linkonce.lr.*)
*(.rela.ifunc)
}
.rela.plt :
{
*(.rela.plt)
*(.rela.iplt)
}
. = ALIGN(CONSTANT (MAXPAGESIZE));
.init :
{
KEEP (*(SORT_NONE(.init)))
}
.plt : { *(.plt) *(.iplt) }
.plt.got : { *(.plt.got) }
.plt.sec : { *(.plt.sec) }
.text :
{
*(.text.unlikely .text.*_unlikely .text.unlikely.*)
*(.text.exit .text.exit.*)
*(.text.startup .text.startup.*)
*(.text.hot .text.hot.*)
*(SORT(.text.sorted.*))
*(.text .stub .text.* .gnu.linkonce.t.*)
/* .gnu.warning sections are handled specially by elf.em. */
*(.gnu.warning)
}
.fini :
{
KEEP (*(SORT_NONE(.fini)))
}
PROVIDE (__etext = .);
PROVIDE (_etext = .);
PROVIDE (etext = .);
. = ALIGN(CONSTANT (MAXPAGESIZE));
/* Adjust the address for the rodata segment. We want to adjust up to
the same address within the page on the next page up. */
. = SEGMENT_START("rodata-segment", ALIGN(CONSTANT (MAXPAGESIZE)) + (. & (CONSTANT (MAXPAGESIZE) - 1)));
.rodata : { *(.rodata .rodata.* .gnu.linkonce.r.*) }
.rodata1 : { *(.rodata1) }
.eh_frame_hdr : { *(.eh_frame_hdr) *(.eh_frame_entry .eh_frame_entry.*) }
.eh_frame : ONLY_IF_RO { KEEP (*(.eh_frame)) *(.eh_frame.*) }
.gcc_except_table : ONLY_IF_RO { *(.gcc_except_table .gcc_except_table.*) }
.gnu_extab : ONLY_IF_RO { *(.gnu_extab*) }
/* These sections are generated by the Sun/Oracle C++ compiler. */
.exception_ranges : ONLY_IF_RO { *(.exception_ranges*) }
/* Adjust the address for the data segment. We want to adjust up to
the same address within the page on the next page up. */
. = DATA_SEGMENT_ALIGN (CONSTANT (MAXPAGESIZE), CONSTANT (COMMONPAGESIZE));
/* Exception handling */
.eh_frame : ONLY_IF_RW { KEEP (*(.eh_frame)) *(.eh_frame.*) }
.gnu_extab : ONLY_IF_RW { *(.gnu_extab) }
.gcc_except_table : ONLY_IF_RW { *(.gcc_except_table .gcc_except_table.*) }
.exception_ranges : ONLY_IF_RW { *(.exception_ranges*) }
/* Thread Local Storage sections */
.tdata :
{
PROVIDE_HIDDEN (__tdata_start = .);
*(.tdata .tdata.* .gnu.linkonce.td.*)
}
.tbss : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) }
.preinit_array :
{
PROVIDE_HIDDEN (__preinit_array_start = .);
KEEP (*(.preinit_array))
PROVIDE_HIDDEN (__preinit_array_end = .);
}
.init_array :
{
PROVIDE_HIDDEN (__init_array_start = .);
KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*) SORT_BY_INIT_PRIORITY(.ctors.*)))
KEEP (*(.init_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) .ctors))
PROVIDE_HIDDEN (__init_array_end = .);
}
.fini_array :
{
PROVIDE_HIDDEN (__fini_array_start = .);
KEEP (*(SORT_BY_INIT_PRIORITY(.fini_array.*) SORT_BY_INIT_PRIORITY(.dtors.*)))
KEEP (*(.fini_array EXCLUDE_FILE (*crtbegin.o *crtbegin?.o *crtend.o *crtend?.o ) .dtors))
PROVIDE_HIDDEN (__fini_array_end = .);
}
.ctors :
{
/* gcc uses crtbegin.o to find the start of
the constructors, so we make sure it is
first. Because this is a wildcard, it
doesn't matter if the user does not
actually link against crtbegin.o; the
linker won't look for a file to match a
wildcard. The wildcard also means that it
doesn't matter which directory crtbegin.o
is in. */
KEEP (*crtbegin.o(.ctors))
KEEP (*crtbegin?.o(.ctors))
/* We don't want to include the .ctor section from
the crtend.o file until after the sorted ctors.
The .ctor section from the crtend file contains the
end of ctors marker and it must be last */
KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))
KEEP (*(SORT(.ctors.*)))
KEEP (*(.ctors))
}
.dtors :
{
KEEP (*crtbegin.o(.dtors))
KEEP (*crtbegin?.o(.dtors))
KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors))
KEEP (*(SORT(.dtors.*)))
KEEP (*(.dtors))
}
.jcr : { KEEP (*(.jcr)) }
.data.rel.ro : { *(.data.rel.ro.local* .gnu.linkonce.d.rel.ro.local.*) *(.data.rel.ro .data.rel.ro.* .gnu.linkonce.d.rel.ro.*) }
.dynamic : { *(.dynamic) }
.got : { *(.got.plt) *(.igot.plt) *(.got) *(.igot) }
. = DATA_SEGMENT_RELRO_END (0, .);
.data :
{
*(.data .data.* .gnu.linkonce.d.*)
SORT(CONSTRUCTORS)
}
.data1 : { *(.data1) }
_edata = .; PROVIDE (edata = .);
. = .;
__bss_start = .;
.bss :
{
*(.dynbss)
*(.bss .bss.* .gnu.linkonce.b.*)
*(COMMON)
/* Align here to ensure that the .bss section occupies space up to
_end. Align after .bss to ensure correct alignment even if the
.bss section disappears because there are no input sections.
FIXME: Why do we need it? When there is no .bss section, we do not
pad the .data section. */
. = ALIGN(. != 0 ? 64 / 8 : 1);
}
.lbss :
{
*(.dynlbss)
*(.lbss .lbss.* .gnu.linkonce.lb.*)
*(LARGE_COMMON)
}
. = ALIGN(64 / 8);
. = SEGMENT_START("ldata-segment", .);
.lrodata ALIGN(CONSTANT (MAXPAGESIZE)) + (. & (CONSTANT (MAXPAGESIZE) - 1)) :
{
*(.lrodata .lrodata.* .gnu.linkonce.lr.*)
}
.ldata ALIGN(CONSTANT (MAXPAGESIZE)) + (. & (CONSTANT (MAXPAGESIZE) - 1)) :
{
*(.ldata .ldata.* .gnu.linkonce.l.*)
. = ALIGN(. != 0 ? 64 / 8 : 1);
}
. = ALIGN(64 / 8);
_end = .; PROVIDE (end = .);
. = DATA_SEGMENT_END (.);
/* Stabs debugging sections. */
.stab 0 : { *(.stab) }
.stabstr 0 : { *(.stabstr) }
.stab.excl 0 : { *(.stab.excl) }
.stab.exclstr 0 : { *(.stab.exclstr) }
.stab.index 0 : { *(.stab.index) }
.stab.indexstr 0 : { *(.stab.indexstr) }
.comment 0 : { *(.comment) }
.gnu.build.attributes : { *(.gnu.build.attributes .gnu.build.attributes.*) }
/* DWARF debug sections.
Symbols in the DWARF debugging sections are relative to the beginning
of the section so we begin them at 0. */
/* DWARF 1 */
.debug 0 : { *(.debug) }
.line 0 : { *(.line) }
/* GNU DWARF 1 extensions */
.debug_srcinfo 0 : { *(.debug_srcinfo) }
.debug_sfnames 0 : { *(.debug_sfnames) }
/* DWARF 1.1 and DWARF 2 */
.debug_aranges 0 : { *(.debug_aranges) }
.debug_pubnames 0 : { *(.debug_pubnames) }
/* DWARF 2 */
.debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) }
.debug_abbrev 0 : { *(.debug_abbrev) }
.debug_line 0 : { *(.debug_line .debug_line.* .debug_line_end) }
.debug_frame 0 : { *(.debug_frame) }
.debug_str 0 : { *(.debug_str) }
.debug_loc 0 : { *(.debug_loc) }
.debug_macinfo 0 : { *(.debug_macinfo) }
/* SGI/MIPS DWARF 2 extensions */
.debug_weaknames 0 : { *(.debug_weaknames) }
.debug_funcnames 0 : { *(.debug_funcnames) }
.debug_typenames 0 : { *(.debug_typenames) }
.debug_varnames 0 : { *(.debug_varnames) }
/* DWARF 3 */
.debug_pubtypes 0 : { *(.debug_pubtypes) }
.debug_ranges 0 : { *(.debug_ranges) }
/* DWARF Extension. */
.debug_macro 0 : { *(.debug_macro) }
.debug_addr 0 : { *(.debug_addr) }
.gnu.attributes 0 : { KEEP (*(.gnu.attributes)) }
/DISCARD/ : { *(.note.GNU-stack) *(.gnu_debuglink) *(.gnu.lto_*) }
}
==================================================
/usr/bin/ld: mode elf_x86_64
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o succeeded
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crti.o succeeded
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crti.o
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/crtbeginS.o succeeded
/usr/lib/gcc/x86_64-linux-gnu/9/crtbeginS.o
attempt to open /tmp/ccJNio1k.o succeeded
/tmp/ccJNio1k.o
attempt to open build.gnu.debug/Animals.o succeeded
build.gnu.debug/Animals.o
attempt to open build.gnu.debug/ftlAlgorithmsTests.o succeeded
build.gnu.debug/ftlAlgorithmsTests.o
attempt to open build.gnu.debug/ftlArrayIntAlgorithms.o succeeded
build.gnu.debug/ftlArrayIntAlgorithms.o
attempt to open build.gnu.debug/ftlArrayTests.o succeeded
build.gnu.debug/ftlArrayTests.o
attempt to open build.gnu.debug/ftlDynArrayIntAlgorithms.o succeeded
build.gnu.debug/ftlDynArrayIntAlgorithms.o
attempt to open build.gnu.debug/ftlDynArrayInt.o succeeded
build.gnu.debug/ftlDynArrayInt.o
attempt to open build.gnu.debug/ftlDynArrayLeaky.o succeeded
build.gnu.debug/ftlDynArrayLeaky.o
attempt to open build.gnu.debug/ftlDynArrayMovableLeaky.o succeeded
build.gnu.debug/ftlDynArrayMovableLeaky.o
attempt to open build.gnu.debug/ftlDynArrayPoint2DAlgorithms.o succeeded
build.gnu.debug/ftlDynArrayPoint2DAlgorithms.o
attempt to open build.gnu.debug/ftlDynArrayPoint2D.o succeeded
build.gnu.debug/ftlDynArrayPoint2D.o
attempt to open build.gnu.debug/ftlDynArrayString.o succeeded
build.gnu.debug/ftlDynArrayString.o
attempt to open build.gnu.debug/ftlDynArrayTests.o succeeded
build.gnu.debug/ftlDynArrayTests.o
attempt to open build.gnu.debug/ftlHashMapStringInt.o succeeded
build.gnu.debug/ftlHashMapStringInt.o
attempt to open build.gnu.debug/ftlHashMapStrInt.o succeeded
build.gnu.debug/ftlHashMapStrInt.o
attempt to open build.gnu.debug/ftlHashMapTests.o succeeded
build.gnu.debug/ftlHashMapTests.o
attempt to open build.gnu.debug/ftlHash.o succeeded
build.gnu.debug/ftlHash.o
attempt to open build.gnu.debug/ftlHashSetInt.o succeeded
build.gnu.debug/ftlHashSetInt.o
attempt to open build.gnu.debug/ftlHashSetString.o succeeded
build.gnu.debug/ftlHashSetString.o
attempt to open build.gnu.debug/ftlHashSetTests.o succeeded
build.gnu.debug/ftlHashSetTests.o
attempt to open build.gnu.debug/ftlKinds.o succeeded
build.gnu.debug/ftlKinds.o
attempt to open build.gnu.debug/ftlListIntAlgorithms.o succeeded
build.gnu.debug/ftlListIntAlgorithms.o
attempt to open build.gnu.debug/ftlListInt.o succeeded
build.gnu.debug/ftlListInt.o
attempt to open build.gnu.debug/ftlListLeaky.o succeeded
build.gnu.debug/ftlListLeaky.o
attempt to open build.gnu.debug/ftlListMovableLeaky.o succeeded
build.gnu.debug/ftlListMovableLeaky.o
attempt to open build.gnu.debug/ftlListTests.o succeeded
build.gnu.debug/ftlListTests.o
attempt to open build.gnu.debug/ftlRegex.o succeeded
build.gnu.debug/ftlRegex.o
attempt to open build.gnu.debug/ftlRegexTests.o succeeded
build.gnu.debug/ftlRegexTests.o
attempt to open build.gnu.debug/ftlSharedPtrInt.o succeeded
build.gnu.debug/ftlSharedPtrInt.o
attempt to open build.gnu.debug/ftlSharedPtrTests.o succeeded
build.gnu.debug/ftlSharedPtrTests.o
attempt to open build.gnu.debug/ftlStringAlgorithms.o succeeded
build.gnu.debug/ftlStringAlgorithms.o
attempt to open build.gnu.debug/ftlString.o succeeded
build.gnu.debug/ftlString.o
attempt to open build.gnu.debug/ftlStringTests.o succeeded
build.gnu.debug/ftlStringTests.o
attempt to open build.gnu.debug/ftlTestTools.o succeeded
build.gnu.debug/ftlTestTools.o
attempt to open build.gnu.debug/Leaky.o succeeded
build.gnu.debug/Leaky.o
attempt to open build.gnu.debug/Point2D.o succeeded
build.gnu.debug/Point2D.o
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libpcreposix.so failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libpcreposix.a failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libpcreposix.so succeeded
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libpcreposix.so
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libpcre.so failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libpcre.a failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libpcre.so succeeded
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libpcre.so
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libgfortran.so succeeded
/usr/lib/gcc/x86_64-linux-gnu/9/libgfortran.so
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libm.so failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libm.a failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libm.so succeeded
opened script file /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libm.so
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libm.so
opened script file /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libm.so
attempt to open /lib/x86_64-linux-gnu/libm.so.6 succeeded
/lib/x86_64-linux-gnu/libm.so.6
attempt to open /lib/x86_64-linux-gnu/libmvec.so.1 succeeded
/lib/x86_64-linux-gnu/libmvec.so.1
/lib/x86_64-linux-gnu/libmvec.so.1
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so succeeded
opened script file /usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so
/usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so
opened script file /usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so
attempt to open libgcc_s.so.1 failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so.1 failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libgcc_s.so.1 succeeded
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libgcc_s.so.1
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.so failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a succeeded
/usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.so failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a succeeded
/usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libquadmath.so succeeded
/usr/lib/gcc/x86_64-linux-gnu/9/libquadmath.so
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libm.so failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libm.a failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libm.so succeeded
opened script file /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libm.so
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libm.so
opened script file /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libm.so
attempt to open /lib/x86_64-linux-gnu/libm.so.6 succeeded
/lib/x86_64-linux-gnu/libm.so.6
attempt to open /lib/x86_64-linux-gnu/libmvec.so.1 succeeded
/lib/x86_64-linux-gnu/libmvec.so.1
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so succeeded
opened script file /usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so
/usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so
opened script file /usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so
attempt to open libgcc_s.so.1 failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so.1 failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libgcc_s.so.1 succeeded
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libgcc_s.so.1
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.so failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a succeeded
/usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.so failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a succeeded
/usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libc.so failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libc.a failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libc.so succeeded
opened script file /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libc.so
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libc.so
opened script file /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libc.so
attempt to open /lib/x86_64-linux-gnu/libc.so.6 succeeded
/lib/x86_64-linux-gnu/libc.so.6
attempt to open /usr/lib/x86_64-linux-gnu/libc_nonshared.a succeeded
/usr/lib/x86_64-linux-gnu/libc_nonshared.a
(/usr/lib/x86_64-linux-gnu/libc_nonshared.a)elf-init.oS
attempt to open /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 succeeded
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
/usr/lib/x86_64-linux-gnu/libc_nonshared.a
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so succeeded
opened script file /usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so
/usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so
opened script file /usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so
attempt to open libgcc_s.so.1 failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libgcc_s.so.1 failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libgcc_s.so.1 succeeded
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libgcc_s.so.1
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.so failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a succeeded
/usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.so failed
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a succeeded
/usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/crtendS.o succeeded
/usr/lib/gcc/x86_64-linux-gnu/9/crtendS.o
attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crtn.o succeeded
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crtn.o
libquadmath.so.0 needed by /usr/lib/gcc/x86_64-linux-gnu/9/libgfortran.so
found libquadmath.so at /usr/lib/gcc/x86_64-linux-gnu/9/libquadmath.so
libgcc_s.so.1 needed by /usr/lib/gcc/x86_64-linux-gnu/9/libgfortran.so
found libgcc_s.so.1 at /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libgcc_s.so.1
ld-linux-x86-64.so.2 needed by /usr/lib/gcc/x86_64-linux-gnu/9/libgfortran.so
found ld-linux-x86-64.so.2 at /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
I am running the example as root http://mythopoeic.org/BBB-PRU/pru-helloworld/example.c
and I receive the Error:
"prussdrv_open() failed with -1" during the execution
BBB has Debian 4.1
These are the commands used:
sudo cp EBB-PRU-Example‐00A0.dtbo /lib/firmware
echo EBB-PRU-Example > /sys/devices/platform/bone_capemgr/slots
cat /sys/devices/platform/bone_capemgr/slots
0: PF---- -1
1: PF---- -1
2: PF---- -1
3: PF---- -1
4: P-O-L- 0 Override Board Name,00A0,Override Manuf,EBB-PRU-Example
modprobe uio_pruss
dmesg
[ 195.985512] bone_capemgr bone_capemgr: part_number 'EBB-PRU-Example', version 'N/A'
[ 195.994182] bone_capemgr bone_capemgr: slot #4: override
[ 195.999703] bone_capemgr bone_capemgr: Using override eeprom data at slot 4
[ 196.006752] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,EBB-PRU-Example'
[ 196.039095] pruss_uio 4a300000.pruss: No children
[ 196.057144] gpio-of-helper ocp:gpio_helper: ready
[ 196.070956] bone_capemgr bone_capemgr: slot #4: dtbo 'EBB-PRU-Example-00A0.dtbo' loaded; overlay id #0
and
/boot/uEnv.txt has disabled the HDMI
EBB-PRU-Example.dts
/* Device Tree Overlay for enabling the pins that are used in Chapter 13
* This overlay is based on the BB-PRU-01 overlay
* Written by Derek Molloy for the book "Exploring BeagleBone: Tools and
* Techniques for Building with Embedded Linux" by John Wiley & Sons, 2014
* ISBN 9781118935125. Please see the file README.md in the repository root
* directory for copyright and GNU GPLv3 license information.
*/
/dts-v1/;
/plugin/;
/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";
part-number = "EBB-PRU-Example";
version = "00A0";
/* This overlay uses the following resources */
exclusive-use =
"P9.11", "P9.13", "P9.27", "P9.28", "pru0";
fragment#0 {
target = <&am33xx_pinmux>;
__overlay__ {
gpio_pins: pinmux_gpio_pins { // The GPIO pins
pinctrl-single,pins = <
0x070 0x07 // P9_11 MODE7 | OUTPUT | GPIO pull-down
0x074 0x27 // P9_13 MODE7 | INPUT | GPIO pull-down
>;
};
pru_pru_pins: pinmux_pru_pru_pins { // The PRU pin modes
pinctrl-single,pins = <
0x1a4 0x05 // P9_27 pr1_pru0_pru_r30_5, MODE5 | OUTPUT | PRU
0x19c 0x26 // P9_28 pr1_pru0_pru_r31_3, MODE6 | INPUT | PRU
>;
};
};
};
fragment#1 { // Enable the PRUSS
target = <&pruss>;
__overlay__ {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&pru_pru_pins>;
};
};
fragment#2 { // Enable the GPIOs
target = <&ocp>;
__overlay__ {
gpio_helper {
compatible = "gpio-of-helper";
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&gpio_pins>;
};
};
};
};
There are two pre compiled versions of the 4.1 kernel for the BBB in the repos: The "TI" version and the "Bone" version. The TI version uses a newer API for controlling the PRU and the Bone version has the same API as the 3.8 kernel and the prussdrv_open() function should work fine.
To install the 4.1 "bone" kernel, you can do:
cd /opt/scripts/tools
sudo ./update_kernel.sh --bone-rt-kernel --lts-4_1
More info: https://groups.google.com/forum/#!topic/beagleboard/cyM3f935wMA
Hmmm looks similar to a previous issue.. The problem was that the PRU was not enabled, and I quote :
echo BB-BONE-PRU-01 > /sys/devices/bone_capemgr.8/slots fixed it.
You could try to use the 4.1.5-ti-r10 version of the kernel. Apparently pruss_uio does not work for some 4.1.x kernels.
Moreover, the dts file you are using was not working for me either (don't know why). I used the following, and prussdrv_open does not fail:
/dts-v1/;
/plugin/;
/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";
/* identification */
part-number = "BB-ENABLE-PRU";
/* version */
version = "00A0";
fragment#1 { // Enable the PRUSS
target = <&pruss>;
__overlay__ {
status = "okay";
};
};
};
If found all this out on that thread: https://groups.google.com/forum/#!category-topic/beagleboard/VBNEoCbEHUQ