Looking for some assistance on finding an image that has a working pinmux driver set.

[Drew Viersen]

Having the hardest time with my beaglebone blue. first and foremost, i followed the instructions after firing the unit up the first time, and flashed the latest image. Since then, all i can attribute that to is lack of knowledge on my part.I purchased this board because it had the built in functionality of pwms, motor drivers, servo drivers and 2s Lipo charging etc. 

At this point i am looking for a stable, functional image that will work with Python, and if possible node red. I have no history or knowledge of javascript or C++, so i am trying to work my way up starting here, and teach my kids the fun tht can be had. As I am finding though, there isn't an overlay set up for the Blue, most of the pins aren't exported, and as such, rcpy doesn't want to work correctly. Even running the basic included functions yields issues like this:

can't open: /sys/devices/platform/ocp/ocp:H18_pinmux/state

Pinmux: No such file or directory

can't open: /sys/devices/platform/ocp/ocp:C18_pinmux/state

Pinmux: No such file or directory

can't open: /sys/devices/platform/ocp/ocp:P9_22_pinmux/state

Pinmux: No such file or directory

can't open: /sys/devices/platform/ocp/ocp:P9_21_pinmux/state

Pinmux: No such file or directory

can't open: /sys/devices/platform/ocp/ocp:P9_26_pinmux/state

Pinmux: No such file or directory

can't open: /sys/devices/platform/ocp/ocp:P9_24_pinmux/state

Pinmux: No such file or directory

can't open: /sys/devices/platform/ocp/ocp:P9_30_pinmux/state

Pinmux: No such file or directory

can't open: /sys/devices/platform/ocp/ocp:P9_29_pinmux/state

Pinmux: No such file or directory

can't open: /sys/devices/platform/ocp/ocp:P9_31_pinmux/state

Pinmux: No such file or directory

WARNING: missing PINMUX driver

You probbaly just need a newer kernel

ERROR: export failed for hrpwm1 channel A

ERROR: failed to initialize hrpwm1

WARNING: Failed to initialize motors

ERROR: pru-rproc driver missing

this of course persists across all of the included examples. and as such, i can't even get the motors to operate. Blinking the LED's is only useful to a point.

i'm running the 4.9 kernel that came with the 2018-03-05 image. If there's a functioning image i should be using that's up to date enough i'd be happy to reflash. at this point, i'm looking for something that just works and allows all of the functions and pins the board has to work correctly. I've been advised i can manually set pins with sudo and and use other libraries. 

If i'm expecting too much, and there are some good resources i should look at to make this work correctly i'd be happy to delve deeper. im not afraid to learn, but i am afraid i wasted $80 on a board that did work 12 months ago, and got left behind as the rest of the world updated.

Any pointers, educational resources, or even projects would be appreciated, as my children may find these interesting as well.

[evilwulfie]

universal-io should be installed on that image by default.

you can configure all pins the way you want like this

    echo 2 > /sys/class/gpio/export
    echo out > /sys/class/gpio/gpio2/direction

read up on it on this github

https://github.com/cdsteinkuehler/beaglebone-universal-io

I dont have a blue but i would assume there is a premade overlay for that board that should configure
everything for you if the above does not work out for you

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/9090a559-91d6-4dd1-9485-b109c8eff734%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Drew Viersen]

Thanks for responding! 

It is indeed installed, but there is no overlay for the Blue i was able to find in the list of overlays. the github you linked goes heavily into the 3.x kernels which don't apply to the device tree changes in the 4.9.x and above kernels. i was hoping an overlay would exist that would fix the fact that the /sys/devices/platform/ocp/ directory only has 8 pinmux entries, which is why none of the robotics cape functions actually work.

i tried the export method below, but i doesn't add anything to the OCP directory listed above that the examples all need. this is even after i modified the uEnv.txt file to include even the cape-universalh-dtbo.

The lack of an overlay, my lack of understanding how to correctly make one, is inhibiting this. i found out that for some reason the push buttons on it are hard coded into the libroboticscape library, which is written in C, and even the rcpy library doesn't work correctly, all because of the missing entires in the /ocr/ directory. 

any additional inside is appreciated.

[Drew Viersen]

i'll clarify what i am looking for.

The newest images available that everything says to update to, doesn't appear to export the pins to the /ocp directory. As such, even the example code supplied doesn't work. config-pin doesn't work because it looks in the /ocr directory for *pinmux folders so it can do things. these don't exist in the 9.x versions. all of the information on making capes refers to a device tree/cape-manager that doesn't appear to exist as a result of updates going down the line. i've tried various overlays loading them, and yet, nothing appears in the /ocr directory. using the RoboticsCape-00A0.dtbo as an overlay actually breaks the OS and makes it unable to load at all. it literally get's stuck with all 4 of the user lights being stuck on. 

Since adafruit_bbio, libroboticscape rcpy etc all rely on them to be there, and since they aren't, nothing works with the updated images. i've google searched my eyes out, and all of the guides, information, etc, all appear to be non-functional due to kernel upgrades and changes in how everything is handled with regards to capes, slots, and overlays. I am hoping for a solution that would allow me to use the fixes in code or updated python libraries i'm more comfortable with than having to look instead to learning to write in another programming language and then rewriting/correcting the issues with the existing example code to simply make it work.

This isn't meant to be a slight to anyone, as i appreciate the project and the authors. I'm just frustrated to find that for the most part, this board feels like it's been left left in the dust as the rest of the beaglebone product line moves forward despite it's amazing capabilities. Given it's a Black with the capabilties of the robotics cape integrated into it, I figured it would have been easier than this. As i said before, that may be my fault for expecting the ease of use i've come to know with the Raspberry Pi and similiar other single board computers.

[evilwulfie]

Till things catch up just flash an old working version.
sometimes upgrading things is not a good idea till you get everything working.

pinmux will work on new kernels just fine i use it on 4.14
it should be loading in /boot/uEnv.txt you can go look there to see

grab the overlay source

git clone https://github.com/beagleboard/bb.org-overlays

and take a look at the source of the overlay for your board

something might stand out

I use blacks and greens - so i dont have one here to play with

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/1addc958-f3a8-4f17-9a31-fabaa96df91d%40googlegroups.com.

[Drew Viersen]

therein lies part of the issue. There isn't an overlay for the board itself from what i can tell. none of the overlay's indicate they are for beaglebone blue by name itself, and none of them list "ti,beaglebone-blue" as compatible. the closest would be the roboticscape-00a0, except loading that actually stops the board from booting period.

[evilwulfie]

send a copy of your /boot/uEnv.txt to see whats loading

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/cf78a63c-023f-44ec-8192-6c05f4c05948%40googlegroups.com.

[Drew Viersen]

debian@beaglebone:/opt/scripts$ sudo /opt/scripts/tools/version.sh

[sudo] password for debian:

git:/opt/scripts/:[e307a944e0be0610ff5296e0abe4ad31a6e70daa]

eeprom:[A335BNLTBLA21722EL001255]

model:[TI_AM335x_BeagleBone_Blue]

dogtag:[BeagleBoard.org Debian Image 2018-03-05]

bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2018.01-00002-ge9ff418fb8]:[location: dd MBR]

kernel:[4.14.25-bone13]

nodejs:[v6.13.1]

uboot_overlay_options:[enable_uboot_overlays=1]

uboot_overlay_options:[enable_uboot_cape_universal=1]

pkg:[bb-cape-overlays]:[4.4.20180307.0-0rcnee0~stretch+20180307]

pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee2~stretch+20180104]

pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~stretch+20170830]

groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep admin spi tisdk weston-launch xenomai]

cmdline:[console=ttyO0,115200n8 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet]

dmesg | grep pinctrl-single

[    0.849752] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568

dmesg | grep gpio-of-helper

[aallm...@gmail.com]

Hi Drew,

Have you had any luck with this so far?  I've hit the same point (which is how I came across this post).

If it's not possible to get the robotics cape, rcpy/pyctrl, node-roboticscape, etc. working with the "current" image, I'm happy running an older image.  It might be helpful to have a warning in any Blue-specific documentation that the newer images should be avoided until things are better.

Any recommendations for an older image where things like the EduMIP robot examples will work?

Thanks!

Andy

[Drew Viersen]

Hi Andy!

Short answer. Only the 3/2017 image works correctly for Libroboticscape, RCPY, Jhonny5, and node-robotics cape. And even then with the node red, most of it doesn't work at all. RCPY is just conversion of the libroboticscape, but most of the functions aren't there from the libroboticscape. Newer 4.x kernels simply won't work.

Long answer. 

The folks who designed the board use it for a class in a class at a university. As such, Robert C Nelson has disabled overlays for the Blue board. He also as of this point hasn't updated the code to pull out all of the pinmuxes in newer boards despite protests from several of us so far. again because he doesn't want top break the code the school uses if the board is accidently updated. The BBBLue also pulls out some pinmuxes that aren't standard on a normal beaglebone, and assigns them under a different nomenclature than a normal Beaglebone. This is important later.

The libroboticscape library uses some older coding and very specific coding to perform some back end wizardry to handle the 4th encoder & the servos. this eliminates the ability to use them without the library. the Analog pins are also handled via mmap, which means you can't get to them from python. This library is also called for the battery checker. RCPY is another university class grade piece of code, and largely unmaintained as you'll find. unfortunately, to use everything and use it easily/correctly, this library is required. In python especially, there is no way to use the Analog pins, or even read from them. using the "State" in RCPY and in any of even the "C" examples is blocking, meaning that you can't run two instances with it, it'll close the first so the second. with some kajigery i was able to get some things out of it, right or not. it's working for me so far.

Adafruit BBIO uses a certain nomenclature when setting pinmuxes. this is in the format of "P8_8", and it's hard coded. This is because the underlying software for setting the pinmuxes to do things is also hard coded for this style that the Adafruit BBIO uses under everything. the non-standard nomenclature of some of the pinmuxes means you can't access them via this python library. 

The node-roboticscape is based on an even earlier piece of code that's no longer supported by node-red. as such, most of it's corresponding functions aren't even available. Johnny5 looks for things exported to /sys/class/gpio, which aren't there because the overlays pinmux things instead. You can export pins in this directly, but all PWM is handled via pinmuxing and the PRUs. 

Between the 3/2017 and the newer versions of the kernal, the pru driver changed. so newer kernel functions for PRUs doesn't work correctly. This includes encoder #4, and all servo pins.

Now, with all of the depressing things out of the way that inhibit the use of it on newer kernels, there is a newer version of libroboticscape in the works. how it will function is beyond me and the developer isn't responding to inquiries so far after over a month. it does appear Robert C nelson is helping them at least.

I myself am not willing to give up on this thing just yet. I'm on the 3/2017 kernel.none of the others work, or provide complete functionality, including the debian and ROS images. i'm not fluent in C and i bought this thing to do some fun things with my daughter, which means python for me. i've done some things to get the functionality i want and use a variety silly things to get it, but i can at least get some of the things needed to make it all work. if any of it is of interest to let me know, and i'd be happy to share what i've done to get it going. there are likely easier ways, mostly tied to learning how to create a better, more complete version of RCPY, but it's all well outside of what i know how to do on such a large scale.

Thanks!

Drew

--

For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/GHeMjrAM5AE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/9bdd6e4b-6ea3-44e9-a4d6-3300a5bfdae6%40googlegroups.com.

[aallm...@gmail.com]

Thanks for the quick response!

I saw that there's a new branch on the Strawson library that's being actively worked on, so that's very encouraging.

I'm new to linux, so when I first starting playing with the BBB last year, it was quite a learning curve.  What made things especially difficult was that many good resources (i.e. Derek Molloy's book & website) were based on older images and many examples didn't work.  Although it was a frustrating experience, I definitely learned a lot and was able to successfully use the BBB for a couple of projects around the house (replaced the commercial sprinkler system controller, monitor/control garage door, etc).

My target for the blue is definitely robotics.  I was a mentor for a couple of FIRST FLL (lego robotics) teams and some of these kids have expressed an interest in getting into "real" robotics & programming.  The BB blue seems like a great platform for that especially if some of the low-level details can be abstracted away through these libraries.  Most of the kids have been exposed to javascript & python in school.

I'll try the image from 3/2017 and see how it goes.

[Robert Nelson]

Hi Drew,

What was the "last" v4.4.x-ti based kernel (uname -r) that fully
worked for you guys?

Regards,

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

[Drew Viersen]

The last one that fully worked is 

4.4.52-ti-r91.

but it only worked with RCPY and the default Libroboticscape C library. 

Not to rehash our previous conversations, but none of the versions including this version fully works with Adafruit bbio because it relies on config-pin to call pinsetting, and that's hardcoded for the nomenclature of "Px_x" in the /sys/devices/platform/ocp directory. While the overlay does bring a few of them out(P9_11, P9_21-31) that can be used, config-pin can't handle the "special"  ones like C18, D13, H17-18, J15, or U16 because of the special nomenclature. Nothing anyone can do here with those. Add to that overlays were disabled for the blue due to the libroboticscape handling assignments, which hasn't been updated to 0.4.0 yet so all of the other pins can't be addressed. DTB-rebuilder is an option, but I don't feel safe playing with it.

The prevailing concern for me and the the others who private messaged me asking if this was ever solved, is the ability to use python and the newer kernels. The websites still state the first thing that should be done is to update the kernels, and all of the newer kernels state compatibility for the blue. It's the first thing we do. again, not much you can do about the python situation. It's just Python unfriendly/incomplete.

[Robert Nelson]

On Fri, Apr 6, 2018 at 11:19 AM, Drew Viersen <96a...@gmail.com> wrote:
> The last one that fully worked is
>
> 4.4.52-ti-r91.
>
> but it only worked with RCPY and the default Libroboticscape C library.

Thanks! I'll start with that version and get it working on the main
v4.4.x tree again.

> Not to rehash our previous conversations, but none of the versions including
> this version fully works with Adafruit bbio because it relies on config-pin
> to call pinsetting, and that's hardcoded for the nomenclature of "Px_x" in
> the /sys/devices/platform/ocp directory. While the overlay does bring a few
> of them out(P9_11, P9_21-31) that can be used, config-pin can't handle the
> "special" ones like C18, D13, H17-18, J15, or U16 because of the special
> nomenclature. Nothing anyone can do here with those. Add to that overlays
> were disabled for the blue due to the libroboticscape handling assignments,
> which hasn't been updated to 0.4.0 yet so all of the other pins can't be
> addressed. DTB-rebuilder is an option, but I don't feel safe playing with
> it.

Let's work with Drew on that, (he's the maintainer of the python library)..

Do we have a list of which pins are we are trying to access thru that library?

(it annoys we chose the P8/P9 syntax for the blue)

If you look at the python the library, the PocketBeagle turned out much cleaner.

I'd really like to just re-do the blue pin labels...

> The prevailing concern for me and the the others who private messaged me
> asking if this was ever solved, is the ability to use python and the newer
> kernels. The websites still state the first thing that should be done is to
> update the kernels, and all of the newer kernels state compatibility for the
> blue. It's the first thing we do. again, not much you can do about the
> python situation. It's just Python unfriendly/incomplete.

Lack of testing really broke things. Personally i was just running
rc_balance and assumed that was enough to verify things worked.

Being swamped at day job hasn't helped either.

[Robert Nelson]

On Fri, Apr 6, 2018 at 11:31 AM, Robert Nelson <robert...@gmail.com> wrote:
> On Fri, Apr 6, 2018 at 11:19 AM, Drew Viersen <96a...@gmail.com> wrote:
>> The last one that fully worked is
>>
>> 4.4.52-ti-r91.
>>
>> but it only worked with RCPY and the default Libroboticscape C library.
>
> Thanks! I'll start with that version and get it working on the main
> v4.4.x tree again.

Okay first pass:

https://github.com/RobertCNelson/dtb-rebuilder/commit/8a3a03cb905fdc1f280ab7dc3cb3591d54be89f1

for anyone that is running v4.4.x-ti on a blue, simply do:

:~$ cd /opt/source/dtb-4.4-ti/
:/opt/source/dtb-4.4-ti$ git pull
:/opt/source/dtb-4.4-ti$ make
:/opt/source/dtb-4.4-ti$ sudo make install

then in /boot/uEnv.txt

change:

=dtb= to:

dtb=am335x-boneblue-mmap.dtb

reboot and please re-test the Libroboticscape C library.

[Drew Viersen]

Side note, it appears Thalaviar made mention of his way to correct the 4.14-ti kernel issues. his method was to :

git clone https://github.com/RobertCNelson/dtb-rebuilder.git

git checkout 4.14-ti

git checkout origin/4.9-ti -- src/arm/am335x-boneblue.dts

git checkout origin/4.9-ti -- src/arm/am335x-bone-common-universal-pins.dtsi

make src/arm/am335x-boneblue.dtb

This corrected the pruout/pruin pins that were set as GPIOs. one of the files was missing to rebuild it straight(if memory serves me, it was am335x-boneblue.dts). Not sure if this helps.

The adafruit bbio library allows access to any of the pins, but does it with the defacto config-pin in jessie and stretch. meaning :

https://github.com/beagleboard/beaglebone-blue/blob/master/BeagleBone_Blue_Pin_Table.csv

any of them COULD be accessed by knowing the header/pin number. In an ideal world, that'd be the pin list, with the references to the BB, BBBL "pin" and the actual ball on the SOC. for instance, as it stands right now, any of the Analog Ins, isn't accessable at all. Being limited to check AIN5 and AIN6 only via a C program is a pain. RCPY doesn't bring out the AINs at all. Show-pins shows nothing for them. they just don't exist. It can only be done in C, and with Libroboticscape. The rest of the pins on that list that are tied to a function in libroboticscape show up in showpins with a few bizare caveats(like motor 2 direction pin B), but have no way of accessing them because they aren't in any of the overlays. Libroboticsape does everything with them, setting them, and using them in low level programming. In a perfect world, the overlay would allow them to be brought out so we could use them with things other than LibRoboticsCape.

The caveat to this is your prior fears would be well founded though if a universal fix for them would break the use of libroboticscape(and the battery monitor that relies on it and it's analog pin mmap-ing).

While we can't expect you to test everything, I can give you a few very specific examples where it completely breaks down using adafruit's BBIO library in either tyhe 4.14 or 4.4 kernels. Give the ADC or PWM sample code in the read me a try.

[Robert Nelson]

last i looked at 0.4.0 i think the battery/adc has been moved to iio..
that's why the adc was disabled by default for us. now that u-boot
overlays work for the blue, the adc can be turned on..

> While we can't expect you to test everything, I can give you a few very
> specific examples where it completely breaks down using adafruit's BBIO
> library in either tyhe 4.14 or 4.4 kernels. Give the ADC or PWM sample code
> in the read me a try.

ADC and PWM are the fun one right now..

For the ADC, as long as you have a recent u-boot (v2018+)

sudo /opt/scripts/tools/version.sh

The adc can be turned off and on via an overlay:

enable_uboot_overlays=1

#enables adc
#disable_uboot_overlay_adc=1

#disables adc
disable_uboot_overlay_adc=1

the pru options are also available on the blue:

https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_PRU_Options

PWM:

lib_robotics assumes the old non-udev-rule-able location.. i need to
fix that.. (it's just a different directory).. This is what breaks
v4.11.x+ (a few v4.9.x kernels when i backported the pwm rule)

https://github.com/RobertCNelson/ti-linux-kernel-dev/commit/7cc72b902fc64deab5a54f58414cb65a595ef1d3

[Drew Viersen]

Rebooted, library still works. I ran down all of the functions just in case one at a time.

[Drew Viersen]

>ADC and PWM are the fun one right now.. 
>
>For the ADC, as long as you have a recent u-boot (v2018+) 
>
>sudo /opt/scripts/tools/version.sh 

Bootloader is 2018.03+

The adc can be turned off and on via an overlay:

enable_uboot_overlays=1

#enables adc
#disable_uboot_overlay_adc=1

#disables adc
disable_uboot_overlay_adc=1

With the Blue MMAP dtb mentioned previously still in uEnv.txt

The above doesn't seem to work with the python examples from adafruit.

with uboot overlays enabled, disabling it or enabling it still returns:

RuntimeError: Unable to setup ADC system. Possible causes are: 

  - A cape with a conflicting pin mapping is loaded 

  - A device tree object is loaded that uses the same name for a fragment: helper

ADC Enabled or disabled, rc_test_adc still works.

[Drew Viersen]

This may help make things clearer:

#show-pins | sort

P8.03 / eMMC d6                    6 fast rx  up  1 mmc 1 d6         mmc@481d8000 (pinmux_emmc_pins)

P8.04 / eMMC d7                    7 fast rx  up  1 mmc 1 d7         mmc@481d8000 (pinmux_emmc_pins)

P8.05 / eMMC d2                    2 fast rx  up  1 mmc 1 d2         mmc@481d8000 (pinmux_emmc_pins)

P8.06 / eMMC d3                    3 fast rx  up  1 mmc 1 d3         mmc@481d8000 (pinmux_emmc_pins)

P8.07                             36 fast         7 gpio 2.02 lo >>  leds (pinmux_led_pins)

P8.08                             37 fast         7 gpio 2.03 lo >>  leds (pinmux_led_pins)

P8.09                             39 fast rx  up  7 gpio 2.05 << hi  sysfs (pins)

P8.10                             38 fast rx  up  7 gpio 2.04 << hi  sysfs (pins)

P8.11                             13 fast rx  up  4 qep 2 in B       ocp/helper (pins)

P8.12                             12 fast rx  up  4 qep 2 in A       ocp/helper (pins)

P8.13                              9 fast    down 4 pwm 2 out B      ocp/helper (pins)

P8.14                             10 fast         7 gpio 0.26 lo >>  leds (pinmux_led_pins)

P8.15                             15 fast rx  up  6 pru 0 in 15      ocp/helper (pins)

P8.16                             14 fast rx  up  6 pru 0 in 14      ocp/helper (pins)

P8.17                             11 fast         7 gpio 0.27 lo >>  leds (pinmux_led_pins)

P8.18                             35 fast         7 gpio 2.01        ocp/helper (pins)

P8.19                              8 fast    down 4 pwm 2 out A      ocp/helper (pins)

P8.20 / eMMC cmd                  33 fast rx  up  2 mmc 1 cmd        mmc@481d8000 (pinmux_emmc_pins)

P8.21 / eMMC clk                  32 fast rx  up  2 mmc 1 clk        mmc@481d8000 (pinmux_emmc_pins)

P8.22 / eMMC d5                    5 fast rx  up  1 mmc 1 d5         mmc@481d8000 (pinmux_emmc_pins)

P8.23 / eMMC d4                    4 fast rx  up  1 mmc 1 d4         mmc@481d8000 (pinmux_emmc_pins)

P8.24 / eMMC d1                    1 fast rx  up  1 mmc 1 d1         mmc@481d8000 (pinmux_emmc_pins)

P8.25 / eMMC d0                    0 fast rx  up  1 mmc 1 d0         mmc@481d8000 (pinmux_emmc_pins)

P8.26                             31 fast         7 gpio 1.29 lo >>  leds (pinmux_led_pins)

P8.27 / hdmi                      56 fast    down 5 pru 1 out 8      ocp/helper (pins)

P8.28 / hdmi                      58 fast    down 5 pru 1 out 10     ocp/helper (pins)

P8.29 / hdmi                      57 fast    down 5 pru 1 out 9      ocp/helper (pins)

P8.30 / hdmi                      59 fast    down 5 pru 1 out 11     ocp/helper (pins)

P8.31 / hdmi / sysboot 14         54 fast         7 gpio 0.10 lo >>  sysfs (pins)

P8.32 / hdmi / sysboot 15         55 fast         7 gpio 0.11 lo >>  leds (pinmux_led_pins)

P8.33 / hdmi / sysboot 13         53 fast rx  up  2 qep 1 in B       ocp/helper (pins)

P8.34 / hdmi / sysboot 11         51 fast rx      7 gpio 2.17       

P8.35 / hdmi / sysboot 12         52 fast rx  up  2 qep 1 in A       ocp/helper (pins)

P8.36 / hdmi / sysboot 10         50 fast         7 gpio 2.16 lo >>  sysfs (pins)

P8.37 / hdmi / sysboot 8          48 fast         4 uart 5 txd       ocp/helper (pins)

P8.38 / hdmi / sysboot 9          49 fast rx      4 uart 5 rxd       ocp/helper (pins)

P8.39 / hdmi / sysboot 6          46 fast    down 5 pru 1 out 6      ocp/helper (pins)

P8.40 / hdmi / sysboot 7          47 fast    down 5 pru 1 out 7      ocp/helper (pins)

P8.41 / hdmi / sysboot 4          44 fast    down 5 pru 1 out 4      ocp/helper (pins)

P8.42 / hdmi / sysboot 5          45 fast    down 5 pru 1 out 5      ocp/helper (pins)

P8.43 / hdmi / sysboot 2          42 fast         7 gpio 2.08 lo >>  sysfs (pins)

P8.44 / hdmi / sysboot 3          43 fast         7 gpio 2.09 lo >>  sysfs (pins)

P8.45 / hdmi / sysboot 0          40 fast         7 gpio 2.06 lo >>  sysfs (pins)

P8.46 / hdmi / sysboot 1          41 fast         7 gpio 2.07 lo >>  sysfs (pins)

P9.11                             28 fast rx  up  6 uart 4 rxd       ocp/P9_11_pinmux (pinmux_P9_11_uart_pin)

P9.12                             30 fast         7 gpio 1.28        ocp/helper (pins)

P9.13                             29 fast         7 gpio 0.31 lo >>  sysfs (pins)

P9.14                             18 fast    down 6 pwm 1 out A      ocp/helper (pins)

P9.15                             16 fast         7 gpio 1.16 lo >>  sysfs (pins)

P9.15                             34 fast         7 gpio 2.00 lo >>  sysfs (pins)

P9.16                             19 fast    down 6 pwm 1 out B      ocp/helper (pins)

P9.17 / spi boot cs               87 fast rx  up  2 i²c 1 scl        ocp/helper (pins)

P9.18 / spi boot out              86 fast rx  up  2 i²c 1 sda        ocp/helper (pins)

P9.19 / cape i²c scl              95 slow rx  up  3 i²c 2 scl        ocp/helper (pins)

P9.20 / cape i²c sda              94 slow rx  up  3 i²c 2 sda        ocp/helper (pins)

P9.21 / spi boot in               85 fast rx  up  1 uart 2 txd       ocp/P9_21_pinmux (pinmux_P9_21_uart_pin)

P9.22 / spi boot clk              84 fast rx  up  1 uart 2 rxd       ocp/P9_22_pinmux (pinmux_P9_22_uart_pin)

P9.23                             17 fast rx  up  7 gpio 1.17        ocp/P9_23_pinmux (pinmux_P9_23_gpio_pu_pin)

P9.24                             97 fast rx  up  0 uart 1 txd       ocp/P9_24_pinmux (pinmux_P9_24_uart_pin)

P9.25 / audio osc                107 fast rx  up  7 gpio 3.21 << lo  sysfs (pins)

P9.26                             96 fast rx  up  0 uart 1 rxd       ocp/P9_26_pinmux (pinmux_P9_26_uart_pin)

P9.27                            105 fast rx  up  1 qep 0 in B       ocp/helper (pins)

P9.28 / hdmi audio data          103 fast rx  up  7 gpio 3.17 << hi  sysfs (pinmux_P9_28_gpio_pu_pin)

P9.29 / hdmi audio fs            101 fast rx down 3 spi 1 d0 miso    ocp/P9_29_pinmux (pinmux_P9_29_spi_pin)

P9.30                            102 fast rx down 3 spi 1 d1 mosi    ocp/P9_30_pinmux (pinmux_P9_30_spi_pin)

P9.31 / hdmi audio clk           100 fast rx down 3 spi 1 clk        ocp/P9_31_pinmux (pinmux_P9_31_spi_pin)

P9.41                            106 fast rx  up  7 gpio 3.20        ocp/D13_pinmux (pinmux_D13_gpio_pu_pin)

P9.41 / jtag emu3                109 fast         7 gpio 0.20 lo >>  sysfs (pins)

P9.42                            104 fast rx  up  1 qep 0 in A       ocp/helper (pins)

P9.42                             89 fast         2 spi 1 cs 1       ocp/C18_pinmux (pinmux_C18_spi_pin) 

Instead of:

ocp/helper (pins) or sysfs (pins)

it's expecting something akin to:

 ocp/P8_45_pinmux (pinmux_P8_45_xxxxx)

[Matt Brauer]

Hello all,

Has anyone found a solution to this problem? I'm in the same boat, except that since my BBBlue appears to have a faulty eMMC I'm returning it. I'm wondering if I should just downgrade to the BBBlack with the robotics cape rather than struggle with the unsupported Blue.

Grateful for any advice,

-Matt

On Friday, March 9, 2018 at 6:27:23 PM UTC-8, Drew Viersen wrote:

Having the hardest time with my beaglebone blue. first and foremost, i followed the instructions after firing the unit up the first time, and flashed the latest image. Since then, all i can attribute that to is lack of knowledge on my part.I purchased this board because it had the built in functionality of pwms, motor drivers, servo drivers and 2s Lipo charging etc. 

<snip> 

[Robert Nelson]

On Sun, May 27, 2018 at 12:12 AM, Matt Brauer <matt...@gene.com> wrote:
> Hello all,
>
> Has anyone found a solution to this problem? I'm in the same boat, except
> that since my BBBlue appears to have a faulty eMMC I'm returning it. I'm
> wondering if I should just downgrade to the BBBlack with the robotics cape
> rather than struggle with the unsupported Blue.

Test this image:

https://rcn-ee.net/rootfs/bb.org/testing/2018-05-20/stretch-iot/bone-debian-9.4-iot-armhf-2018-05-20-4gb.img.xz

Blue should be in good shape again..

[Drew Viersen]

Robert,

It's been a while, and i noticed that the robotics cape lib was updated as well. is there a way to load this kernel without reflashing the entire device? i'd like to keep what i have stored on it thus far if at all possible.

Thanks!

Drew

[matt...@gene.com]

Hi Robert,

That did the trick! Thank you!

-Matt

[Kim]

Were you able to find a solution for this problem without reflashing the emmc?