Jetson Nano as LinuxCNC driver

Hi andypugh,
Success, fantastic, it is working with the sim axis.
many thx

hobbyno1,

parport module is using outb and inb from sys/io.h header and this ABI is not defined for aarch64. It is circumvented in the LinuxCNC code by defining these functions as a 0 on both armhf and arm64 architectures so the modules compile. So the actual parport module on ARMv8 is actually a dummy. For example, Machinekit doesn't even compile these modules for aarch64. (None of these solutions are that good in light of ARM boards with PCIe support, because the Hostmot2 uses the same approach, I think.)

All in all, it is probably going to be a minefield experience, because the code is not completely prepared for this. But in the end it should run fine.

Some info on the installation. The first time I tried dpkg -i it seemed to remove all the :armhf packages. It then returned an error message re unmet dependencies. Then I did sudo --fix -broken install, this still gave an error message at the end of a long list of fixes, so I tried dpkg -i again and it installed.

Yeah, the dpkg is not that great as user interface. You can try directly apt install absolute-path-to-the-deb, it should resolve the dependencies automatically from set up Debian/Ubuntu/whatever repositories.

The physical pins respond to the linux o/s and halrun and halcmd seem to work fine. What I seem to need is to rewrite the file hal_pi_gpio.so for the nano. Can you give me any guidance on this or how I might start it.
thx

hobbyno1 wrote:

The physical pins respond to the linux o/s and halrun and halcmd seem to work fine. What I seem to need is to rewrite the file hal_pi_gpio.so for the nano. Can you give me any guidance on this or how I might start it.
thx

I presume you want real-time control of the I/O pins, right? Well, there are several ways how to approach this issue. We will talk only about the RT_Preempt flavour, OK? As that is what is used on the RPi and what was discussed in this thread. So you can go around it with creating a kernel space module or a user space one. Kernel space one would provide the best overall access control times, but would not be that easy to develop.

In line of the current RPi HAL module/driver, you would be best served with mmapping the /dev/mem into RTAPI application space (which will require sole access, but I don't presume you want to control the I/O from multiple processes at one time and the crash will mean crash without tidying up). There is even HOWTO tutorial for Jetson Nano which you can take a knife to and gut it for goodies: Jetson-gpio-example and Jetson-nano-gpio-example .

Look mainly at the memory offset numbers and how the write/read flow is done.

The RPi module is done little differently because RPi kernel allows little more combed access to GPIO memory - which as far as I know is not possible on the Nano, but you will have to read the manuals to know for sure. However, it is not that different to be impossible to take the advantage of existing code. Still, you are in for a quite adventure!

Yes, I'm looking at rt-preempt and sole access. thanks for your reply.

I'm also looking at using the Jetson Nano to run LinuxCNC. Thanks for all the advice so far.

I'm using L4T version 32.4.4 and have applied the PREEMPT-RT patches. I have also installed the linuxcnc package provided by Cerna.

I have some questions:

1) What is the correct way to stop "apt upgrade" from overwriting my RT kernel with a non-RT one?

2) How exactly did Cerna create that linuxcnc package for Ubuntu Bionic?

3) Has anybody made any progress with the HAL GPIO interface?