Advanced Search

What is SCFFIFO error ?

From memory, there is another kernel setting for something like embedded system that needs to be enbled on the pi's menu-config to build preempt_rt, I have not seen it for a long time as the option is always there now. its ARM specific
 

Another option is to let the RPi5 go through the boot process, check your DHCP for any entries that may be the said Pi and try to ssh into it.

First of all this is the first time I can recall this issue emerging.
I & many others I have used the image mentioned by the OP with no issues.

The screen going black isn't an indication that the Pi is bricked, there is a setting config.txt that controls whether you get the "rainbow" screen or not.

Generally there are issues which using the Rpi imager to write the image. If using windows Balena etcher is recommended, on Linux balena etcher can be used, dd is another alternative or whatever image writer that comes with your system.

To be pendantic, the bootloader is contained on the RPi board. As you have not mentioned any messages about of an out of date bootloader I doubt this is an issue.

One thing you could try, as you say you just recently bought a RPi5, is insert a blank SD card, connect an ethernet cable and boot. If you have the most recent bootloader the RPi5 should attempt to load an OS to the SD card via the internet.

pimylifeup.com/raspberry-pi-network-install/

One point to note, you get far far better bang for buck using a second hand corporate PC that a RPi5.

Thanks for that explanation, I was wondering the same thing.

Here are the working gmoccapy files.

   

That's the function of Rod's fork of the rpi image builder. To be honest it is not required to used by a run of the mill Linuxcnc user. In Nov\Dec of 2023 it was working and working very well, as far as I know it was just Rod working on it and occasionally he'd bounce a few off me and I'd run the script as well, make a few changes here and there. At the end of the day it was Rod's baby, and did the job required. Apart from Rod there have been only contributions from 3 other people, with Rod doing the bulk of the work.
As for unified, I don't know if that applies, as it would seem this is the only project addressing this task. Whilst some users have started with RPi OS as a base that because they wanted to do things their way for whatever reason, and was never an option that rpi-img-builder was going to address.
There is a similar utility for the PC platform, that rarely gets a mention on the forum, for building PC images. For those that want an easy and hassle free entry it does the job. For those that want to use a different distro, ie not debian, they usually do their own thing.
I guess how tight Linuxcnc & Debian are is unusual for Linux, one would admit that Linuxcnc is not your usual run of the mill app. Actually it is more a complete suite that integrates with hardware that most other projects don't. Another good point with Debian is that they really try to stick with the OSS ethos, which would be the reason there are many distros that Debian based.
That is not to say that Linuxcnc will not run on other distros. I've used Mint, Slackware and Linux from Scratch project to build systems for Linuxcnc. It can be done but can take a fair bit of time and in reality I can't say if its better or worse.
As for kernel versions, well that's a personal choice, whether the most recent kernel or one that is a year or so old as long as it works, as most do, it's probably academic.

In conclusion I would suggest that there is a unified image creation utility, it would seem the kernel is the driving force. I don't many would care what kernel version is used as long as it works, it's only really when someone is aware of a new release that they start thinking about it and suggest can we use kernel x.x.x, which would seem reasonable with a user coming from the windows world with the focus on updates.

I'm trying to build a CNC controller based on a PI5. I have a half dozen Pi's around the house as music servers, DNS agents, and process monitoring, so this shouldn't be this hard.

These are 4GB PI's with 32GB SD cards. They loaded base Bookworm, written from the Pi Imager, and I ran them that way for a bit, and then I attempted to install rpi-5-debian-bookworm-6.1.61-rt15-arm64-ext4-2023-11-17-1520 on them. When I attempt to run the os, the screen goes black and the LED flashes, then stays constant green. On the first one, I thought it was something I did, so I bought a second one and had the same issue occur. 

At this point they won't even run the standard boot loader. I expect the screen to go green on boot, but it goes black instead. Documentation says that the Pi's are fried, and I'd hate to see this happen to others.

Can anyone suggest what I can do to figure this out?
 

The ip change did not affect the error.

Host ip=10.10.10.100
hal:
loadrt hm2_eth board_ip="10.10.10.10, 10.10.10.11" config="num_encoders=6 num_pwmgens=1 num_stepgens=5, num_encoders=2 num_pwmgens=2 num_stepgens=10 sserial_port_0=0xxxxxxx"

log:
hm2_eth: loading Mesa AnyIO HostMot2 ethernet driver version 0.2
hm2_eth: 10.10.10.10: INFO: Hardware address (MAC): 06:2e:1b:12:00:38
hm2_eth: ERROR: can't connect: Network is unreachable

Hi. I am just learning LinuxCNC. I followed all the instructions, but encountered the following problem: after entering `PYTHONPATH=. bin/rio-setup riocore/configs/Tangoboard/config.json`, I get the message "ACCESS DENIED". When I add `sudo` before the command, I get the message "COMMAND NOT FOUND". What should I do? I installed the latest version of LinuxCNC today, and there were no errors in the previous steps.

P.S. I apologize, I am not very good at English and I am using a translator.

Yes I can @cornholio.

It takes a certain set of steps to go from sources to executables ("sysgen" it has been called). If those steps end up in a script that anyone can run, starting with perhaps a fresh Ubuntu install (or pick any distribution), then the sysgen script would take it from there to completion (a running LinuxCNC that any of its users could work with).

"make" was supposed to handle this job but has not, I believe, given all the patching and version number matching that has been required to get running systems.

Am I close to what the current situation is?

Tom

To be perfectly honest I can't recall any instability or kernel crashed in the last 10 years. If I have had any it would be down to myself doing something silly to cause it. In using Linux, specifically Mint, as a daily driver I haven't seen any stability issues. I use Linux exclusively, except for the rare occasions I need to use my Needham Eeprom programmer then I pull out an old Thin client running Win98.

To be fair I'm not one that has to be "on the bleeding edge", so I don't try and push the envelope. Up until 3 years so ago my file server\media server was running Slackware 14.2. I changed to Ubuntu as it doesn't take a whole day to build packages to install something like gitlab on Ubuntu.

Once again you've been a true gent and really patient during this discussion, and after sometime you showed me the way. Even tho I was wrong I feel more educated on the subject.

Cheers
Rob

TomAlborough wrote:

Perhaps a unified test platform for the "sysgen" aspect would help.

Tom
 

Tom would you like to elaborate on what you mean ?

Also the thing that sticks out is that the step-gen is also removed, as this is done on the weeny card, but cannot see anything that is needed to enable that (and the homing works ok)

I will post the working gmocappy that worked originally

That is sort of what I tried. Unfortunately the new configs can only be made for a parallel port or a Mesa card.

Since this is a raspberry pi the parallel port won't run. I do have another working CNC that is running a Mesa, but that is operational and in use at the moment.

What I attempted here was to use the sample config I had to get a working gmoccapy, which worked fine, including jogging.

I then ran the wizard with the par_port option and qtPlasmac as the front end to create a default plasmac config.

I then replaced the par_port and associated hal nets, mainly just the joints and limits with the ones from the working gmoccapy config.

Unsure if there is a better way to achieve this.