Broken CRAMPS.bbio

[charles...@gmail.com]

The CRAMPS.bbio file has a line commented out that drives a test led on the CRAMPS board.

When this line is enabled by removing the # and run it provokes a series of error messages starting with P9_25 pinmux file not found!

NOT GOOD!!

I'm presently running the latest RCN release --    bone-debian-9.9-machinekit-ARMhf-2019-06-30-4gb

There is no doubt that all my troubles as noted in my post yesterday are related to a broken pinmux definition.

Would anyone care to point to a known good release?

Thanks,

Chuck

[charles...@gmail.com]

I suppose I should also ask, where's the source?

[Robert Nelson]

P9_25 is hdmi audio...

Disable it in /boot/uEnv.txt

https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Disable_on-board_devices

Regards,

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

[charles...@gmail.com]

On a BBB with a CRAMPS V1.0 board I re-flashed the onboard flash memory with the latest release bone-debian-9.9-machinekit-armhf-2019-08-25-4gb.

I then edited the /boot/uEnv.txt file to the following taking the measure to remove the useless commented out lines for clarity

#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=4.19.59-bone-rt-r36
enable_uboot_overlays=1
uboot_overlay_addr0=/lib/firmware/cape-universal-00A0.dtbo
disable_uboot_overlay_audio=1
disable_uboot_overlay_wireless=1
uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
enable_uboot_cape_universal=1
cmdline=coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet

then rebooted and called machinekit from the command line

AXIS comes up fine but NOBODY is home, nothing moves it's as though the CRAMPS board is not even there.

Is the uEnv.txt file correct? Any other suggestions as to resolving the absence of functionality?

On another note, the getting started notes at machinekit.io suggest that one should start with an older Jessie distribution, however the link does not have the recommended file, where can one find the older releases?

[Charles Steinkuehler]

On 8/26/2019 11:07 PM, c.gl...@cox.net wrote:
<snip>

> AXIS comes up fine but NOBODY is home, nothing moves it's as though the
> CRAMPS board is not even there.
>
> Is the uEnv.txt file correct? Any other suggestions as to resolving the
> absence of functionality?

Usually the "totally dead" symptom results from not having one of the
CRAMPS power rails connected. In addition to the 5V coming from the
BeagleBone, you need to have some/all of the following power rails
connected:

P201: Motor power (for the Pololu stepper drivers)
P401: Bed power (for the heated bed output: P403)
P402: Ext power (for the extruder outputs: E0-E2)
P404: Aux power V+ (for low-power outputs: FET5-FET6)

Also check your ESTOP chain and the status of the LEDs:

BB ON : Should always be on
STATUS: Application dependent (driven by GPIO pin)
ACTIVE: Should be on when machine power is active (F2)
ESTOP : Should be on until the machine is out of ESTOP (F1)

--
Charles Steinkuehler
cha...@steinkuehler.net

[Robert Nelson]

On Mon, Aug 26, 2019 at 11:07 PM c.gl...@cox.net
<charles...@gmail.com> wrote:
>
> On a BBB with a CRAMPS V1.0 board I re-flashed the onboard flash memory with the latest release bone-debian-9.9-machinekit-armhf-2019-08-25-4gb.
>
> I then edited the /boot/uEnv.txt file to the following taking the measure to remove the useless commented out lines for clarity
>
> #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
>
> uname_r=4.19.59-bone-rt-r36
> enable_uboot_overlays=1

> uboot_overlay_addr0=/lib/firmware/cape-universal-00A0.dtbo

^ don't do that, you just broke things..

> disable_uboot_overlay_audio=1
> disable_uboot_overlay_wireless=1
> uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo

> enable_uboot_cape_universal=1

^ this already enabled correctly, what you tried to do above..

[charles...@gmail.com]

Commenting out

uboot_overlay_addr0=/lib/firmware/cape-universal-00A0.dtbo

Then

machinekit@beaglebone:~$ machinekit

MACHINEKIT - 0.1
Machine configuration directory is '/home/machinekit/machinekit/configs/ARM.BeagleBone.CRAMPS'
Machine configuration file is 'CRAMPS.ini'
Starting Machinekit...
rtapi_msgd command:  /usr/libexec/linuxcnc/rtapi_msgd --instance=0 --rtmsglevel=1 --usrmsglevel=1 --halsize=524288
rtapi_app command:  /usr/libexec/linuxcnc/rtapi_app_rt-preempt --instance=0
io started
halcmd loadusr io started
Waiting for /sys/class/uio/uio0 ...................................................................................................

since CRAMPS.bbio has in the first few lines

overlay cape-universal
overlay cape-bone-iio

However there is no cape-bone-io in /lib/firmware, further removing the reference to it in CRAMPS.hal will again produce

halcmd loadusr io started
Waiting for /sys/class/uio/uio0 ...................................................................................................

Whats even more confusing is that this thread

https://groups.google.com/forum/#!topic/machinekit/XSxIKD_mi-s

suggest exactly the opposite of RCN suggestion

It appears that I'm dammed if I do, and Dammed if I don't.

I really don't want to spend several days tearing down a system and replacing the cramps board so I can run a few panel mount temperature control modules.

It would be far simpler just to drop back a few years to old code that worked. Trouble is... it's doesn't seem to be available.

[Charles Steinkuehler]

On 8/28/2019 12:40 AM, c.gl...@cox.net wrote:
>
> since CRAMPS.bbio has in the first few lines
>
> overlay cape-universal
> overlay cape-bone-iio
>
> However there is no cape-bone-io in /lib/firmware, further removing the
> reference to it in CRAMPS.hal will again produce
>
> halcmd loadusr io started
> Waiting for /sys/class/uio/uio0

These are all legacy tests from when there were actual device tree
overlays that could be dynamically loaded at run-time and it could
take a few seconds for the device nodes to show up.

If the system is waiting for /sys/class/uio/uio0 it means you don't
have the PRUs properly enabled. Make sure you have the PRU UIO device
(*NOT* remoteproc) enabled via u-boot. It's the last entry here:

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

--
Charles Steinkuehler
cha...@steinkuehler.net

[Robert Nelson]

On Wed, Aug 28, 2019 at 12:40 AM c.gl...@cox.net
<charles...@gmail.com> wrote:
>
> Commenting out
>
> uboot_overlay_addr0=/lib/firmware/cape-universal-00A0.dtbo
>
> Then
>
> machinekit@beaglebone:~$ machinekit
>
> MACHINEKIT - 0.1
> Machine configuration directory is '/home/machinekit/machinekit/configs/ARM.BeagleBone.CRAMPS'
> Machine configuration file is 'CRAMPS.ini'
> Starting Machinekit...
> rtapi_msgd command: /usr/libexec/linuxcnc/rtapi_msgd --instance=0 --rtmsglevel=1 --usrmsglevel=1 --halsize=524288
> rtapi_app command: /usr/libexec/linuxcnc/rtapi_app_rt-preempt --instance=0
> io started
> halcmd loadusr io started
> Waiting for /sys/class/uio/uio0 ...................................................................................................
>
> since CRAMPS.bbio has in the first few lines
>
> overlay cape-universal
> overlay cape-bone-iio

Comment these out, they are loaded by u-boot by default....

ps, run:

sudo /opt/scripts/tools/version.sh

It'll give more hints of what's loading..

[charles...@gmail.com]

Over the years I've learned that when someone is enthusiastic regarding their suggestions it's a very good indicator that "It's working for them" and that the problem is between my ears. OK I'll keep trying to sort it out. However, I have observed one thing that requires some comment.

The code than is within Machinekit and especially as it applies to the CRAMPS board, depends upon files that are not to be found in the Machinekit code base. /boot/uEnv.txt and all the dtbs that are to be found in /lib/firmware for instance. So, if I someone were to come up with some code tweek, that applied directly to a file that normally resides outside the code base of Machinekit. Where would you put it?

The first few lines of CRAMPS.bbio for instance. Specifically,

> overlay cape-universal
> overlay cape-bone-iio

Other than a small handful of guys, who would know? And if the code isn't needed, why is it still there? Those few lines of code might as well be land mines buried along my path, primed and ready to blow my time and life away.

Even more frustrating is that two years ago my cramps board was working just fine. Loaded it up and shabam. Worked right out of the box. Actually, that's not completely true as as recall, it was fundamentally a LinuxCNC project and not Machinekit. And then I thought to upgrade my system. If I had only known.... dammit.

running

sudo /opt/scripts/tools/version.sh

produced

git:/opt/scripts/:[5b2e16aa1e5c0f627f1d48a6dd1c13b446b9f53b]
eeprom:[A335BNLT00A54079BBBK2600]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[Machinekit Debian Image 2019-08-25]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2019.04-00002-gbb4af0f50f]:[location: dd MBR]
kernel:[4.19.59-bone-rt-r36]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr0=/lib/firmware/cape-universal-00A0.dtbo]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[disable_uboot_overlay_wireless=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade <pkg>]
pkg:[bb-cape-overlays]:[4.4.20190812.0-0rcnee0~stretch+20190812]
pkg:[bb-wl18xx-firmware]:[1.20190227.1-0rcnee0~stretch+20190227]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
WARNING:pkg:[librobotcontrol]:[NOT_INSTALLED]
pkg:[firmware-ti-connectivity]:[20180825+dfsg-1rcnee1~stretch+20181217]
groups:[machinekit : machinekit adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal i2c bluetooth netdev gpio pwm eqep remoteproc admin spi tisdk weston-launch xenomai cloud9ide]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet]
dmesg | grep remote
[    1.180967] remoteproc remoteproc0: wkup_m3 is available
[    1.518683] remoteproc remoteproc0: powering up wkup_m3
[    1.518702] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217168
[    1.520798] remoteproc remoteproc0: remote processor wkup_m3 is now up
dmesg | grep pru
dmesg | grep pinctrl-single
[    0.746436] pinctrl-single 44e10800.pinmux: 142 pins, size 568
dmesg | grep gpio-of-helper
[    0.757592] gpio-of-helper ocp:cape-universal: ready
lsusb
Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 003: ID 045e:009d Microsoft Corp. Wireless Optical Desktop 3.0
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END

Looks like I've got a little work to do.

On Sunday, August 25, 2019 at 4:01:29 PM UTC-7, c.gl...@cox.net wrote:

[Robert Nelson]

On Wed, Aug 28, 2019 at 11:26 PM c.gl...@cox.net
<charles...@gmail.com> wrote:
>
>
> Over the years I've learned that when someone is enthusiastic regarding their suggestions it's a very good indicator that "It's working for them" and that the problem is between my ears. OK I'll keep trying to sort it out. However, I have observed one thing that requires some comment.
>
> The code than is within Machinekit and especially as it applies to the CRAMPS board, depends upon files that are not to be found in the Machinekit code base. /boot/uEnv.txt and all the dtbs that are to be found in /lib/firmware for instance. So, if I someone were to come up with some code tweek, that applied directly to a file that normally resides outside the code base of Machinekit. Where would you put it?
>
> The first few lines of CRAMPS.bbio for instance. Specifically,
>
> > overlay cape-universal
> > overlay cape-bone-iio

They are needed for the old 3.8.x based kernel.. Rip those lines out
for anything newer.. (which is everything)

>
> Other than a small handful of guys, who would know? And if the code isn't needed, why is it still there? Those few lines of code might as well be land mines buried along my path, primed and ready to blow my time and life away.
>
> Even more frustrating is that two years ago my cramps board was working just fine. Loaded it up and shabam. Worked right out of the box. Actually, that's not completely true as as recall, it was fundamentally a LinuxCNC project and not Machinekit. And then I thought to upgrade my system. If I had only known.... dammit.
>
> running
> sudo /opt/scripts/tools/version.sh
> produced
>
> git:/opt/scripts/:[5b2e16aa1e5c0f627f1d48a6dd1c13b446b9f53b]
> eeprom:[A335BNLT00A54079BBBK2600]
> model:[TI_AM335x_BeagleBone_Black]
> dogtag:[Machinekit Debian Image 2019-08-25]
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2019.04-00002-gbb4af0f50f]:[location: dd MBR]
> kernel:[4.19.59-bone-rt-r36]
> uboot_overlay_options:[enable_uboot_overlays=1]
> uboot_overlay_options:[uboot_overlay_addr0=/lib/firmware/cape-universal-00A0.dtbo]

You still have this ^ enabled in /boot/uEnv.txt git rid of this line:

uboot_overlay_addr0=/lib/firmware/cape-universal-00A0.dtbo

It's BREAKING the later enablement:

enable_uboot_cape_universal=1

[charles...@gmail.com]

I remember the first time I loaded Linux. It was a Slackware 0.95 release. I must have loaded it a dozen times before I got the hang of it.

I find myself doing the same thing again, this time with various releases for the BBB and Machinekit.  Bone-debian-9.9-machinekit-armhf-2019-08-25-4gb seems to be almost correct for my particular problem. Except ...

Today I used config-pin and the results matched up with the CRAMPS.bbio file. I'm even able to yank on a few pins and see the effect. Slow progress. In earlier version from a few years ago I was able to use the led (P9_25) for signaling. No more.

It's very clear that at some fairly recent time a decision was made to muck with P9_25. Why?

Further, calling up other configurations will break because /sys/devices/platform/ocp/ocp:P9_25_pinmux no longer exists. That isn't very nice. For some reason, that for me at least is completely obscure, this pin was disabled. Will someone, anyone with a knowledge of the events around this pin please comment. I would really like to know when so I can load up the release just before that happened.

cg

[Robert Nelson]

P9.25 is hdmi audio..

[Charles Steinkuehler]

On 9/2/2019 2:11 PM, Robert Nelson wrote:
> On Sat, Aug 31, 2019 at 9:52 PM c.gl...@cox.net
> <charles...@gmail.com> wrote:
>>
>> It's very clear that at some fairly recent time a decision was made to muck with P9_25. Why?
>

> P9.25 is hdmi audio..

Disable HDMI audio per the BBB U-Boot overlay instructions:

https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Disable_on-board_devices

--
Charles Steinkuehler
cha...@steinkuehler.net