Basic support for memory-mapped IO on Raspberry Pi SBCs

[liampwll]

This PR adds initial support for using memory-mapped IO on Raspberry Pi SBCs rather than relying on syscalls, as well as cntvct_el0 as a timer source and CPU pinning. On a Pi 4 a consistent benchmark result of 8100k with 3 steppers active is achievable, making this faster than any MCU on the list.

To achieve this result, isolcpus on an upstream kernel must be used as the Raspberry Pi kernel delivers some interrupts to isolated cores. Below are instructions to get this working on a Pi 4 running OpenSUSE Tumbleweed (https://en.opensuse.org/HCL:Raspberry_Pi4):

• Run systemctl disable irqbalance
• Run yast2, navigate to boot loader > kernel parameters, and append the following: nohz=on nohz_full=3 rcu_nocbs=3 isolcpus=nohz,domain,managed_irq,3 rcu_nocb_poll iomem=relaxed
• Add the following to /boot/efi/extraconfig.txt:

  arm_boost=0
  force_turbo=1
  gpu_mem=16

• Run zypper up and reboot
• Run echo -1 > /proc/sys/kernel/sched_rt_runtime_us
• Assuming the Klipper repo located at /root/klipper, run the following commands to set up Klipper:

  zypper in python3-virtualenv python3 python3-devel libffi8 libffi-devel libncurses6 ncurses-devel gcc make
  virtualenv -p python3 /root/klippy-env
  /root/klippy-env/bin/pip install -r /root/klipper/scripts/klippy-requirements.txt

• Build and run the Klipper MCU as per usual and run the following commands in the Klipper console:

  allocate_oids count=3
  config_stepper oid=0 step_pin=2 dir_pin=3 invert_step=0 step_pulse_ticks=5
  config_stepper oid=1 step_pin=4 dir_pin=5 invert_step=0 step_pulse_ticks=5
  config_stepper oid=2 step_pin=6 dir_pin=17 invert_step=0 step_pulse_ticks=5
  finalize_config crc=0
  SET start_clock {clock+freq}
  SET ticks 20
  reset_step_clock oid=0 clock={start_clock}
  set_next_step_dir oid=0 dir=0
  queue_step oid=0 interval={ticks} count=60000 add=0
  set_next_step_dir oid=0 dir=1
  queue_step oid=0 interval=3000 count=1 add=0
  reset_step_clock oid=1 clock={start_clock}
  set_next_step_dir oid=1 dir=0
  queue_step oid=1 interval={ticks} count=60000 add=0
  set_next_step_dir oid=1 dir=1
  queue_step oid=1 interval=3000 count=1 add=0
  reset_step_clock oid=2 clock={start_clock}
  set_next_step_dir oid=2 dir=0
  queue_step oid=2 interval={ticks} count=60000 add=0
  set_next_step_dir oid=2 dir=1
  queue_step oid=2 interval=3000 count=1 add=0

[thijstriemstra]

On a Pi 4 a consistent benchmark result of 8100k with 3 steppers active is achievable, making this faster than any MCU on the list.

Nice! Any more stats, before/after?

[github-actions[bot]]

Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html

There are some steps that you can take now:

1. Perform a self-review of your Pull Request by following the steps at: https://www.klipper3d.org/CONTRIBUTING.html#what-to-expect-in-a-review If you have completed a self-review, be sure to state the results of that self-review explicitly in the Pull Request comments. A reviewer is more likely to participate if the bulk of a review has already been completed.
2. Consider opening a topic on the Klipper Discourse server to discuss this work. The Discourse server is a good place to discuss development ideas and to engage users interested in testing. Reviewers are more likely to prioritize Pull Requests with an active community of users.
3. Consider helping out reviewers by reviewing other Klipper Pull Requests. Taking the time to perform a careful and detailed review of others work is appreciated. Regular contributors are more likely to prioritize the contributions of other regular contributors.

Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then it is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards, ~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[KevinOConnor]

Thanks. Seems interesting. I have some high-level feedback:

1. This PR would need to pass the regression test cases before we could merge.
2. The PR would need to include a signed-off-by line ( see https://www.klipper3d.org/CONTRIBUTING.html ).
3. If there are external files to be added (like ringbuf.c) they should be added to the lib/ directory (and a note added to lib/README).
4. Is there a reason why the mcu/host "console" message system was changed? Is there something not working well with the existing "pipe" system?
5. Would it be possible to add this new feature to the existing src/linux/ directory (with an option of some kind in Kconfig enabling it)? It would seem beneficial to avoid duplicating the code in src/linux/.

Cheers, -Kevin

[liampwll]

Is there a reason why the mcu/host "console" message system was changed? Is there something not working well with the existing "pipe" system?

Most of the time it will work fine, however Linux may sometimes decide that a read needs to be a full syscall rather than happening in userspace, which can introduce a large amount of jitter (other syscalls present the same issue, which is why this only does GPIO).

On the other issues: I don't have too much time to work on this right now, but someone else is welcome to take over and get this in a state where it can be merged.

[KevinOConnor]

Most of the time it will work fine, however Linux may sometimes decide that a read needs to be a full syscall rather than happening in userspace, which can introduce a large amount of jitter

Interesting. It sounds like it could benefit all "Linux mcu" instances.

-Kevin