BeagleBone on Debian 11.7, searching testers

General Discussion
1

Basic Information:

Printer Model: Custom Rostock Delta
MCU / Printerboard: BeagleBone Black + CRAMPS

Describe your issue:

Hi, for long time I was sitting on Machinekit + velocity extrusion, but unfortunately seems Machinekit is dead for 3D printers, so I went to Klipper with hope that I will try something better :rofl:

If you did try it with BeagleBone, then most probably you did find out that it`s unusable in current state. At least I was unable to make it work.
Images are outdated, required packages long ago vent to archive, new images have new Kernel which is not supported, etc …

So, i fetch almost latest Debian 11.7 Bullseye image (2023-09-02) and start working on klipper to bring back BeagleBone support for klipper.

What was done:
Updated PRU libraries
Updated PRU code
Resolved issues with Linker
Resolved issues with Kernel 5.10 requirements
Resolved issue with klipper_pru startup before PRU is ready
Resolved issue with conflicts with AVR packages (did workaround)
Updated Documentation for BeagleBone deployment.

And finally, now i have working Klipper on BeagleBone black with CRAMPS board on latest image :slight_smile:

Now I want to push this to Klipper, but before that I’m searching volunteers who can try it out, give some feedback, errors, etc…

So, if you are interested and want to participate - just clone it from here: GitHub - Ga-Ol-St/klipper: Klipper is a 3d-printer firmware and follow deployment steps from docs/Beaglebone.md

Thanks.

1 Like
2

Hello! First of all, I want to thank you for the work you’re doing on CRAMPS!
I followed your guide but, when running the command

./klipper/scripts/install-beaglebone.sh

I’m getting an error regarding the AVR libraries…You write about a solution, but I can’t find it…could you help me?
Thanks

3

Hi, sure
my first dirty solution was just comment it out in ./klipper/scripts/install-debian.sh script
there is a line with list of AVR packages - just comment it out.

my second solution which I did in that branch - I let them to install, but removing them before installing “gnu-pru” in ./klipper/scripts/install-beaglebone.sh

4

Thanks, finally it’s work!!!
Now I have to configure printer.cfg: I notice there is not /dev/rpmsg_pru30, so I put in mpu section “/dev/remoteproc/pruss-core0”, while in octoprint, under connection, I use /tmp/printer (that is a symbolic link for /dev/pts/1… I’m not sure it is correct…

5

No - that is not correct.
In Linux 5.10 /dev/rpmsg_pru30 will appear only after PRU cores will start and firmware establish “rpmsg” channel with a kernel, by default PRU cores are in offline state. So if you don’t see /dev/rpmsg_pru30 - this means your PRU did not start and klipper PRU firmware is not loaded, or something is wrong with PRU firmware.

Do full system check:

  1. Before doing any check do full system shutdown, including removing power (important). Then just plugin power and login to BeagleBone and wait 1 minute (important)

  2. check state of “klipper_pru” service sudo service klipper_pru status, it should be Active and running

  3. check firmware files ls -la /lib/firmware/am335x-pru*, there should be 2 links and 2 real files, files should have “fresh” date

  4. check PRU cores states, commands: for PRU0: cat /dev/remoteproc/pruss-core0/state and for PRU1: cat /dev/remoteproc/pruss-core1/state, they both should be in “running” state

  5. check dmesg, we are interested in last 15 lines, command dmesg, they should look like this:

[ 73.364618] remoteproc remoteproc1: 4a334000.pru is available
[ 73.518987] remoteproc remoteproc2: 4a338000.pru is available
[ 75.680367] remoteproc remoteproc1: powering up 4a334000.pru
[ 75.783870] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, size 97236
[ 75.789879] remoteproc1#vdev0buffer: registered virtio0 (type 7)
[ 75.789906] remoteproc remoteproc1: remote processor 4a334000.pru is now up
[ 75.790391] remoteproc remoteproc2: powering up 4a338000.pru
[ 75.818240] remoteproc remoteproc2: Booting fw image am335x-pru1-fw, size 188600
[ 75.818276] remoteproc remoteproc2: header-less resource table
[ 75.835993] remoteproc remoteproc2: header-less resource table
[ 75.859114] remoteproc remoteproc2: remote processor 4a338000.pru is now up
[ 75.910747] virtio_rpmsg_bus virtio0: creating channel rpmsg-pru addr 0x1e
[ 75.911289] virtio_rpmsg_bus virtio0: msg received with no recipient
[ 75.916318] virtio_rpmsg_bus virtio0: rpmsg host is online
[ 76.020092] rpmsg_pru virtio0.rpmsg-pru.-1.30: new rpmsg_pru device: /dev/rpmsg_pru30

if something is not as I did describe - send me all outputs of every check and include all output from “dmesg” not just last 15 lines.

6

Mmmm…the 2 PRU are availabes, but they are offline!

am335-pru.txt (376 Bytes)
dmesg.txt (35.0 KB)
klipperpru.txt (1.3 KB)
pruss-core0.txt (8 Bytes)
pruss-core0.txt (8 Bytes)

7

Yea, seems something wrong with autostart.
you can try to start them manually, execute following commands:

sudo service klipper_pru stop
sudo service klipper_pru start

after that check dmesg you should see missing parts about starting up, if dmesg will not show that /dev/rpmsg_pru30 was created - send me it’s output again.

additionaly please send me content of the following file: /etc/udev/rules.d/pru.rules
part of that file is responsible for autostart of “klipper_pru” service after PRU cores become ready to accept comands.

8

Service klipper_pru doesn’t start well:

startklipperpru
startklipperpru740Ă—891 261 KB

and this is dmesg
dmesg2.txt (39.8 KB)

9

Ok, seems something is wrong with firmware
as i can see in you dmesg output cores did try to start

[ 150.260639] watchdog: watchdog0: watchdog did not stop!
[ 173.942074] remoteproc remoteproc1: powering up 4a334000.pru
[ 173.953095] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, size 102680
[ 173.953343] remoteproc remoteproc1: unsupported resource 5
[ 173.953822] pru-rproc 4a334000.pru: Allocated carveout doesn’t fit device address request
[ 173.953888] pru-rproc 4a334000.pru: Allocated carveout doesn’t fit device address request
[ 173.960584] remoteproc1#vdev0buffer: registered virtio0 (type 7)
[ 173.960612] remoteproc remoteproc1: remote processor 4a334000.pru is now up
[ 173.961075] remoteproc remoteproc2: powering up 4a338000.pru
[ 173.990910] remoteproc remoteproc2: Booting fw image am335x-pru1-fw, size 193512
[ 173.991076] remoteproc remoteproc2: remote processor 4a338000.pru is now up
[ 174.241331] 8<— cut here —
[ 174.264347] Unable to handle kernel NULL pointer dereference at virtual address 00000000

but when PRU0 is starting we get error: Allocated carveout doesn’t fit device address request
and when PRU1 started you get kernel error.

Weird part is following:
your firmwares have different sizes than mine
yours:

[ 173.953095] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, size 102680
[ 173.990910] remoteproc remoteproc2: Booting fw image am335x-pru1-fw, size 193512

Mine:

[ 75.783870] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, size 97236
[ 75.818240] remoteproc remoteproc2: Booting fw image am335x-pru1-fw, size 188600

also I don’t see this 2 messages from kernel when PRU1 was starting up:

[ 75.818276] remoteproc remoteproc2: header-less resource table
[ 75.835993] remoteproc remoteproc2: header-less resource table

Question: did you disable all additional options for “BeagleBone PRU” when executing make menuconfig during install sequence ?

Let’s try to rebuild firmware again, do following actions:

cd ~/klipper
make clean
make menuconfig

you will get "Klipper Firmware Configuration " window
enter into “Micro-controller Architecture” and chose “BeagleBone PRU”
next enter into “Optional features (to reduce code size)” and make sure both options have removed checkboxes, they are called “Support GPIO Bit-banging devices” and “Support LCD devices”
Next exit from that tool by pressing “ESC” button, when it will ask to save changes - answer YES
then execute following commands:

sudo service klipper stop
make flash

all these steps are the same as during installation sequence.

now check dmesg again and collect output from “make flash” command and from “dmesg”.
there could be 3 outcomes:

outcome 1. you will see that firmware sizes did change but Kernel most probably is unstable because of previous error, so do proper shutdown of BeagleBone sudo halt -p wait for it to properly shutdown, then remove power and start again. After boot, wait 1 minute and check dmesg

outcome 2. you will see that firmware sizes are same as previously, - then send me output from previously executed “make flash” and latest output from “dmesg”

outcome 3. your system will just die and stop responding - this means your kernel did finally die and board is rebooting - in this case repeat all the steps for rebuilding firmware again and after command “make flash” immediately initiate reboot, command sudo reboot, after proper reboot wait 1 min and analyze dmesg output

10

Perhaps there is something of wrong: Support GPIO Bit-banging devices and Support LCD devices are removed… I have selected also “Enable extra low level configuration option” and then disabled this option, but after “attempting PRU restarting” system is paused (I have to press ctrl+z to stop it).
As this is a Beaglebone wireless, I tried also with a classic ethernet one, but nothing changed.
So I think it’ better if tomorrow I’ll reinstall all :crossed_fingers:

11

I did this upgrade of firmware and all testing on “BeagleBone Black” you have “BeagleBone Wireless” so we have differences in hardware, before you leave send me output from this command “sudo beagle-version”
I will try to analyze the differences in hardware and maybe I will find something additional.
I will post here if I will find something new.

13

Ok seems I identify your issue.

I went and fetch another SD-Card, burn that image and start going step-by-step following documentation in docs/BeagleBone.md from my sources.

During install I did hit only 1 issue - there was not enough free space on 4Gb SD Card, so I made a record about that, remove some “Demo” resources and continue going thru installation.

Everything went cleanly and I didn’t need to reboot, Everything started correctly.
Then I did full reboot and again everything started automatically in correct order.
Then it strike me - you did have issue with AVR libraries - I didn’t see that issue !

This means only 1 thing - when you did go thru Installation you did clone original clipper sources not mine. You did it because in docs/BeagleBone.md there is a step where you are cloning sources but that command was referencing original sources not mine. I did think it’s an obvious thing to reference my sources because I did state that in initial message “just clone it from here”.
Sorry about that.

I added additional steps to documentation how to free-up some space and changed reference to my sources, so nobody will fall to that trap again.

I recommend you to do full installation again by following steps from docs/BeagleBone.md located in my sources (link to my source is in first message). If you did download my sources and looking at them locally - download them again, if you are using them directly from github - good, you will see latest version.

14

Carlom180: Sorry but I can’t send you my disk image. It is a very dirty, custom kernel, runs other software, and has some privacy things. I certainly understand your frustrations. Especially since the last working image of BBB/Klipper was 9.9. Unfortunately there are quite a few bugs that have floated around for years in the BBB environment that make it even more difficult and annoying. My original instructions and patch files don’t align 100% with the new klipper scripts, which makes it even more confusing…
You may want to try this guide Klipper/Fluidd on Beaglebone Black with Replicape – Robotronics

Gaulst: I’ve been struggling myself to get Klipper to install on 11.7. Mainly having PRU issues, in fact, once it was the same NULL pointer dereference Carlom had. I’ll try yours and see what happens.

15

You did have that issues because PRU code is outdated and it’s not compatible with Kernel 5.10 - there was many changes related to REMOTEPROC, and that kind of error can be present because of many things, and worse part of it - if you get that kind of error - your Kernel and Remoteproc can become unstable and you need to reboot for next attempt.

About trying mine - please do try it, strictly follow documentation and get working system (i hope :slight_smile: ), when you have confirmation that it works - then do any tweaks you like because you will know that it was working and it’s your tweak to blame.
Please leave some feedback about you hardware (BeagleBone model, Cape, etc …), and did you succeed or not. If you get in trouble and want to fight with it - I will try to help.

Thanks.

16

Yes, you are right … I did a “past and copy” (without reading the text :flushed:), so I cloned the official klipper source instead your one!
Now, using also the new version of your doc, all it is correct.
I confirm that your Beaglebone-Klipper distribution works well, and on the Beaglebone Wireless too!
Thank you very much, finally CRAMPS is usable.

17

Glad to hear that !
Thanks for your participation.
Happy Printing :slight_smile:

So we have first confirmation on “BeagleBone Black” and “BeagleBone wireless” with CRAMPS board.

18

don’t worry, and thanks for all your work!

19

I’m afraid I spoke too soon! I finally reassembled my print with the CRAMPS by wiring motor, sensors, etc…
-After connecting to Octoprint, I can read the temperatures of the hotend and the bed… good.

image
image1920Ă—1080 155 KB

-in Terminal, typing “HELP” it shows:
Send: HELP
Recv: // Available extended commands:
Recv: // ACTIVATE_EXTRUDER: Change the active extruder
Recv: // FIRMWARE_RESTART: Restart firmware, host, and reload config
Recv: // GET_POSITION: Return information on the current location of the toolhead
Recv: // HELP : Report the list of available extended G-Code commands
Recv: // MANUAL_PROBE: Start manual probe helper script
Recv: // PID_CALIBRATE: Run PID calibration test
Recv: // QUERY_ADC : Report the last value of an analog pin
Recv: // QUERY_ENDSTOPS: Report on the status of each endstop
Recv: // RESTART : Reload config file and restart host software
Recv: // RESTORE_GCODE_STATE: Restore a previously saved G-Code state
Recv: // SAVE_CONFIG: Overwrite config file and restart
Recv: // SAVE_GCODE_STATE: Save G-Code coordinate state
Recv: // SET_EXTRUDER_ROTATION_DISTANCE: Set extruder rotation distance
Recv: // SET_EXTRUDER_STEP_DISTANCE: Set extruder step distance
Recv: // SET_GCODE_OFFSET: Set a virtual offset to g-code positions
Recv: // SET_HEATER_TEMPERATURE: Sets a heater temperature
Recv: // SET_IDLE_TIMEOUT: Set the idle timeout in seconds
Recv: // SET_PIN : Set the value of an output pin
Recv: // SET_PRESSURE_ADVANCE: Set pressure advance parameters
Recv: // SET_STEPPER_ENABLE: Enable/disable individual stepper by name
Recv: // SET_VELOCITY_LIMIT: Set printer velocity limits
Recv: // STATUS : Report the printer status
Recv: // STEPPER_BUZZ: Oscillate a given stepper to help id it
Recv: // SYNC_EXTRUDER_MOTION: Set extruder stepper motion queue
Recv: // SYNC_STEPPER_TO_EXTRUDER: Set extruder stepper
Recv: // TEMPERATURE_WAIT: Wait for a temperature on a sensor
Recv: // TUNING_TOWER: Tool to adjust a parameter at each Z height
Recv: // TURN_OFF_HEATERS: Turn off all heaters
Recv: // Z_ENDSTOP_CALIBRATE: Calibrate a Z endstop
Recv: // Z_OFFSET_APPLY_ENDSTOP: Adjust the z endstop_position
Recv: ok

and typing “STATUS”:

Recv: // Klipper state: Ready
Recv: ok

But, when I try to set temp, fan velocity or move axes, nothing happens! It seems like the part that handles the analog pins (MCU host?) is working fine, but not the PRU (although I’ve performed the checks you suggested and everything seems okay).

In “printer.cfg” I use:
[mcu]
serial: /dev/rpmsg_30

P.S.: I say “PRU” because I think it manages steppers, pwm, hotend… but perhaps it is not correct!

20

Hi, Most probably it’s E-STOP signal is blocking your motors and heaters. CRAMPS have hardware and software E-STOP signals.
Send me your klippy.log I will check it.

21

As a quick try-out you can add these setting in your config, provided configuration of pins will put CRAMPS in Active (Enabled) state, if CRAMPS led “ESTOP” is red - check you hardware ESTOP connection - it should be in closed state.

[output_pin machine_enable]
#Description: Controls Machine-Enable state and power-switch
pin: gpio1_17
#pin: host:gpiochip1/gpio17
value: 1
shutdown_value: 0

[output_pin ESTOP_INPUT_STATE]
#Description: In current setup it Control how "E-STOP" LED reflects E-STOP state (show or not)
#but if we query it - should reflect E-STOP state on Cramps.
pin: gpio0_27
#pin: host:gpiochip0/gpio27
value: 1
shutdown_value: 0

[output_pin ESTOP_OUTPUT]
#Description: CRAMPS board is checking this pin, if it's high- E-STOP will engage
pin: gpio1_29
#pin: host:gpiochip1/gpio29
value: 0
shutdown_value: 1

[output_pin LED_STATUS_OUTPUT]
#Description: Control "Status" LED on CRAMPS Board
pin: gpio3_21
#pin: host:gpiochip3/gpio21
value: 1
shutdown_value: 0