Advanced Search

I doubt very much whether this would be an issue related to the hm2_spix driver. I would suggest you start another topic related to the qtdragon issue.

With qtdragon I have blank toolpath screen, but it only appearing when exit prompt appear.
I tried with fkms,kms -pi5 etc but without results, regular axis display working correctly.

We don't use it but I have in the past.. Debian do offer an image for the pi
raspi.debian.net//
Its very minimal (command line only), You can build it up to run linuxcnc. Its interesting to read their FAQ page for reasons why they don't include configuration packages and why they don't include a build for the Pi5

Our approach to compile the Pi kernel instead of using Debian's solves some issues but we follow their minimalisitc approach. be thankful we provide menu-config

I concur with Rod, and will also state again that the linuxcnc images are not meant to be daily drivers.
The partition managers and such are not required to run a cnc machine.
Forget about the Raspberry Pi utils, this is a Debian installation, apart from the kernel and overlays.
I’d stay away from anything KDE, there will be libraries and other stuff installed that will be basically only for that particular application. GTK apps will be far lighter weight.
The Linuxcnc images are purely for running a cnc machine, if you need want other programs you are free to install what you want but don’t hope them to be included in the supplied image.

No. The linuxcnc image uses Debian so it uses the Debian repository for all packages.
You can find what is available in APT by checking with the Debian Package Seatch.
packages.debian.org/index
If you want to run PI OS, burn another image from the official  Pi images
None of what you mention is required for a Linuxcnc installation

The image is deliberately minimal because of the limited resources of these single board computers.
 

Many of the choices I made during this bumpy configuration journey were driven by reliance on general Linux configuration information sources as I tried to figure out what problem I was actually having at any given moment.

Since I have an inventory of additional uSD & NVME cards I assumed that as my Linux understanding crept up from the near-zero mark I would be starting over at least once reevaluating those choices targeting a less 'chaotic hackers playground' configuration.

Examples of this were installing both GDebi / Synaptic package managers as well as GParted / KDE Partition managers.

I had no idea in either case which would work best or what I would like to choose in the long term, but when I'm in the early learning phase I always know that there will be outright mistakes and sub-optimal choices to say the least.

BTW, I do get your point about the RPi config tools not being necessary for those who know where to go in the Linux config hierarchy to achieve possibly better optimized results but the installation of those tools could always be rolled up in a script as I suspect their inclusion into the XFce application menu for those at their first rodeo.

Now one last actual question:

Even in the situation where someone was going to take a pass on installing the GUI config tools wouldn't it still be valid for all Raspberry builds to have updated APT sources and PGP / keyrings signatures to enable archive.raspberrypi.com (and maybe archive.raspbian.org).

Please correct me if I'm off the mark but wouldn't that be the appropriate 'deb' sources for things other than GUI config tools. Guessing out loud: firmware, eeprom (etc) and possibly purpose built Pi kernels or OS components.

Just wondering.

On the topic of 'daily driver'...

I switched to a pure linux environment for CAD, CAM and obviously LinuxCNC for g-Code execution. Being rusty on Linux I stumbled onto Unbuntu for my desktop and the ISO from LinuxCNC for my Pi 5 leaving Xcfe in place assuming its reputation for being light.

Plenty of upside on being Linux across the board but being new on top of very different environments depending on where my chair is pointed is a little bit disorienting. LOL

I can never remember where I installed what! LOL

Sorry forgot to clarify, from sd card to archive image.

[begin_off_topic_rant]
I can't stand wearing jeans or any long pants, why they insist we wear long sleeve shirts and long pants is the Aussie summer is beyond me, then they have a big song & dance about heat stress and keeping liquids up.

Funny thing the shunters on the rail said long pants were a safety issue and dont have to.
And don't get me started on having a ruptured disc diagnosed as a pulled muscle.
[end_off_topic_rant]

Well after finally working out my chinese dev board was dead, second one that has failed, I loaded a Numato Mimas Spartan 6 board with 7c81 firmware modded to suit and can confirm RPi5 communicates. To make things more fun the CE0 line on my Pi is not playing so had to swap over to CE1.

So after 12 months of bitching & carrying on I'm a happy camper.

Now time to design & build some interface boards. Yay!

Quick update, the Chinese dev board is not at fault, it was the usb-blaster programmer I was using (was constantly incorrectly identifying the flash chip and programming the sram had issues as well), switching to a FT2232 based programmer allowed resuming of programming the above mentioned board. No need to design interface boards.

With regards to the "firmware=hm2/7c81/G540X2.BIT" this is not required as the 7c8* & 7i* boards have the firmware programmed into flash that retains the firmware during power off. The firmware is programmed once and only reprogrammed when you require a new configuration.

Our image on the downloads page is already pre-shrunk, just like a well fitting pair of jeans
It does make a big difference in the image size

Remember the Linuxcnc RPi images are not meant to be the same as the Official RPi images. They are not to be used as a "daily driver OS", they are solely implemented to drive a cnc machine, and if you are inclined to do some Linuxcnc development.

menu-config will do most of the same stuff as the RPi utils except for setting up the various hardware related stuff. Enabling the various hardware overlays is done by config.txt, which is really really simple as it is very well documented within the file.

There really should be a "sticky" concerning the configuring of these images, without the need to add any RPi tools. And reminding users that the images are NOT related to other RPi OS's/images and such.

I guess there's a lot of people that don't use Linux as a daily driver.

dd works fine on Linux for writing the images, or if you like the GUI route Ubuntu based distro have USB image writer which works fine every time.

Another thing I've noticed, which boils down to understanding things. The Linuxcnc images for the RPi are not related to the Official Raspberry Pi images and are not meant to be used as a "daily driver" OS, they are solely for running a CNC machine and maybe for those that want or need to building Linuxcnc.

So to use these images without any issues, don't assume that they have or need the same tools that the images from the Raspberry Pi foundation.

For reference this is the tool I've used for archiving images (one caveat I'm not a windows or mac user, I'm soley a Linux user):
github.com/Drewsif/PiShrink

meister wrote:

Many thanks Zayoo !

i have add the code to the dev branch for testing.

if you want to use it, you can add

"rpi5": true,

to your json config

like this:


[code]{
"name": "IceShield",
"description": "RIO-IceShield on Raspberry PI5",
"boardcfg": "IceShield",
"protocol": "SPI",
"rpi5": true,
....

[/code]

I have tested it on dev. It works good with 2 changes:
I needed to set my spi speed at 1mhz due to my clock speed (I think), instead of 1.5mhz. I think we may need a way to configure this, as well as which spi dev to use. If we can configure which spi dev to use, it would be easier to use this on other systems as well. But for the main branch, I think we just need to support setting the spi speed.

Also, in toolchain.py, {cmd_cp} and {cmd_rm} were not evaluating correctly:I was able to make it work by changing the make by hand to cp -v. Probably not related to the rpi5 changes.

spiflash.sh doesn't work for an iceshield board, but that's to be expected I think. I'll look into that a little later. It's about not being able to set the board into reset mode via gpio25 I think, so flashrom can't read the rom size. I think there's an rpi4/5 compatible python gpio library out there, I'll see about writing a simple python helper for that instead of hitting the dev tree directly.

A few message ago I mentioned a size related error as I tried to install the ISO from Rod's Google drive.

It was suggested that I use Balencia to burn it but that actually didn't work but with searched and finally found a tool that would install it. Then I moved past that I finally wound up with the combination that I wanted to my Pi 5 install. This included all kinds of tools (including those from Raspberry) and even edited the Xfce applications menus for super convenience.

But a word of caution about 'figuring out' your way around an error instead of understanding and fixing it right - once I was done installing and configuring and wanted to make a backup of my uSD card before I moved everything to my NVME I discovered that restoring the backup to a new uSD card failed with a 'too large' error no matter what I did.

I finally used a partition tool to shrink the ROOT partition and was able to both make/restore backups and move everything to my NVME, but it would have been a lot less anxiety had I just waited until ROB posted a version without that quirk.

Zayoo wrote:

I'm trying to get the gowin toolchain up and running on rpi5. It gives me an error when execute making all.

cnc@raspberrypi:~/riocore/Output/TangNano9K_spi_rpi5/Gateware$ make clean
rm -rf rio.fs rio.json rio_pnr.json rio.tcl abc.history impl
cnc@raspberrypi:~/riocore/Output/TangNano9K_spi_rpi5/Gateware$ make all
gw_sh rio.tcl
/opt/gowin/IDE/bin/gw_sh: 2: Syntax error: Unterminated quoted string
make: *** [Makefile:34: impl/pnr/project.fs] Error 2
cnc@raspberrypi:~/riocore/Output/TangNano9K_spi_rpi5/Gateware$ 

I see you've already mentioned this error. I downloaded and cloned the dev version and it still doesn't work. Any tips...

I see there is another option 'generic_spi'. I will test that on rpi5 too just to get that toolchain working. I don't want to take the TN9 out of the device and program on windows anymore.

 

I found the gowin toolchain a major problem to get running on a few systems like a current LTS release of Ubuntu, so I built a docker container for the oss-cad-suite. Meister added one for the gowin toolchain, and one for oss-cad-suite on the pi. I think the pi one should work fine on the pi5 too.

I was able to flash directly using the oss-cad-suite one with a T9 on a pi4, but it's been a while. At the very least, the Dockerfiles have the details on getting the toolchain working.

Give this a try, it's the oss-cad-suite instead of gowin but it supports the T9 IIRC.
github.com/multigcs/riocore/blob/main/do...ile.debian12-run-rpi
github.com/multigcs/riocore/blob/main/DOCKER.md