LinuxCNC + Orange Pi (allwincnc)

sorry i didnt see reply till now. i will go thru old setup, re-create to confirm notes and post asap. hope by new year ( dec 8 already ! ) thx bari
I assume magic means undocumented. i am sure i didnt invent anything and followed some recipe i found but will stop and get on to rebuilding and documenting. thx again tomp. het i check the damn reply notification checkbox. oh well get to it!

OK I can recreate the working OPiPlus2E CNC32 OrangeCNC image using these instructions
(its LOOOOONG but i made 3 working images with this recipe )
There is a bad .dtb file supplied, i give a link to the good file and how ot use it )
here's my recipe:

---

1) Get a good uSD card, many are bad, many are fake, many have wrong size
class 10
I used Kimgston 32G and SandDisk Ultra 32G. Kingstone is better imo/in my experience
Test it with F3

2) Format the SD card
This is to insure the armbian image ( or anything ) can be written to the uSD card
SD card readers are often junk
I use an old Fujix camera that has a format function,
I use an sd card adapter for the uSD card
I also used my android cell phone and the 'files' app supplied
I also used a chromebook with an SD card slot,
this required an SD card adapter.
I had no luck using usb card readers (2) on my normal linux desktop tower,
not on any of 6 bootable distros.
ymmv

using onwe of these 4 methods should get you a formatted sd card ( fat32 )
that can have an image burned onto it.

3) get an image:
for the OrangePiPlus2e,
I went to
mirrors.tuna.tsinghua.edu.cn/armbian-rel...ngepiplus2e/archive/
and got Armbian_20.11.3_Orangepiplus2e_buster_current_5.9.14.img.xz
That image is very new (today is 20dec2020) there are newer blleding edge images

The next lines are only for those following the instructions
using a Chromebook's System Recovery Utility,
you may well use dd or Etcher or Rufus )

---

I extracted the .img file and because of the way I burned it,
I converted the .img to a .zip
Then I uploaded the .zip to Google Drive ( my drive )
ready for Chromebook's SystemRecoveryUtility

---

4) burn the image:
what I did: ( using a chromebook):
I saw my sd card burning problems lay in the adapters ( uSD to SD to usb dongle )
and I used the chromebook to burm the image on the uSD card
because this eliminated one hardware interface.

The chromebook has a System Recovery Utility
that creates an iso FROM the live system and
can restore that image to an SD card.

But I used the restore function with a trick
that tells the utility to use any image that I want
So i can burn uSD cards for loads of small computers (RPi BPi OPi Cubie etc)
The utility wants
the image to burn
and
the device to burn it on.

The image can be on local storage
or even on Google Drive ( that's my choice to avoid using local disk space )
A gotcha is : the file on Google Drive should be .zip or .bin
( I had troubles with .bin so I zipped the .img extracted from the .xz )

After uploading the .zip to MyDrive, and formatting the SD card,
insert the now empty uSD card into a SD sleeve
and insert that sleeve into the Chromebook SD slot.

Open the System Recovery Utiltiy
( drill down into the apps list of the Chromeook )
Goto the top right of the app and click the Gear.
Choose 'Local File'
navigate to Google Drive and select the .zip image file
the select the device ( I only had 1 in the list, a 32G card listed as 29.5G )
click continue
get a warning that th uSD card will be erased
click on continue again
now wait....
you SHOULD get a forammted uSD card when its done

5) if here, you have a bootable uSD card
put the uSD card into OPi
add a usb Keyboard and mouse
power up the monitor
( HDMI needs to be ready before the microcontroller imo )
after the monitor complains there is no signal,
power up the OPI with at least 3 amp power supply.
you should see a green led right away
WAIT
eventually you will see text scrolling
the uSD card will get expanded to use all room available
WAIT some more
until it asks you for a new root password
enter a good one
then pick a user name and password

6) armbian-config
You will need networking before configuring the system
I used wifI and as normal user, did
nmtui-connect
and picked out my wifi from all the neighbors
then entered the password for the router ( wifI password )
I was immediately 'on' the net

then do
sudo armbian-config
note the info shown
like the min and max cpu freq and the cpu governor that is in effect now
like the relase version
enter you new user password
then from the menu system select
SSH (if you want to, I did) and select the defaults ( as I did ) then SAVE then BACK
Update & Upgrade ( needed to build stuff later like linuxCNC and RT_PREEMPT and Arisc and GPIO )
Timezone
Locale
Kernel Headers and Kernel Source
note this will get you 5.9.14 hdrs & src and will be DOWNGRADED later, dont worry )
This is plenty enough changes to a new system, so lets make sure its really operational

sudo shutdown -h now
wait for led off, then power off, count to 20, then power on

7) you just rebooted
This time login as user with user password

After login
Check that you can ssh in ( use sudo ifconfig to see IP addr )

8) install a minimal desktop:
sudo apt-get -y install xorg lightdm xfce4 tango-icon-theme gnome-icon-theme

when done
sudo reboot

9) you see a new gui login
and see that the mouse works
type in the username and pwd

see 'welcome to the desktop'
I chose default setup

open a terminal
sudo shutdown -h now
do a 'cold boot' this time, just to insure all is right

10) you just rebooted into XFCE4
log in
open a terminal
and just incase...
sudo apt-get update
sudo apt-get upgrade

then get the wonderful package from mx-master of cnc-ru orangecnc
git clone gitlab.com/orangecnc/installer

after the clone is done...

11) run the shell script:

cd installer
./install.sh

DO NOT REBOOT YET
WE HAVE TO CHANGE 1 FILE

12) you need to overwrite one file BEFORE powering down

the existing uSD filesystem has >ONE< bad file that will defeat the mouse and keyboard and wifi
that file is
/boot/dtb-5.4.35-sunxi/sun8i-h3-orangepi-plus2e.dtb

we will overwrite it with a slightly smaller version from my Google Drive
drive.google.com/file/d/1yTYge38gLG6LDD2...8uG/view?usp=sharing

this old small version works, the new large file will hang with no kbd no mouse no wifi

fetch that file using the above url, download where you know you can find it

then copy it to the uSD card in /boot/dtb-5.0.14-sunxi

so cd the where you stored it
then
sudo cp ./sun8i-h3-orangepi-plus2e.dtb /boot/dtb-5/9/14-sunxi

13) now reboot into RT-PREMPT LINUXCNC ORANGECNC

sudo reboot
login
you will see many desktop icons for the many opi+2e configs
from mx-master of cnc32 orangecnc

These items 'work'
but
will initially complain they are untrusted ( say ok )
and
will say they need to be marked executable ( mark them )

I used 3A-arisc for my test.
Axis opened fine...
the path window was slow to fill in
but once the gcode path was displayed,
scaling and rotating and moving the path was smooth and fast.

I did F1 F2 , X home Y home Z home
and could jog at 12000mm/min w/o errors.

I loaded 3Dchips into an editor and remarked the tool call
meaning I put parens around that line turning it into a comment
then saved it as my3Dchips.ngc in my user directory.

I opened my3Dchips using Axis' file selector
and ran the entire path in 101 seconds!
There was no hardware connected but this is NOT a sim.

You will see 12000mm/min velocity on the 1st and last straight runs.

14) anybody know how to get the source code from a .dtb or dtbo ?
I really need that becasue simply overwriting the dtb ,
esp for a different kernel is a nono

hope this helped
TomP

other changes I did ...
add MC, Firefox-esr Synaptic
add desktop icons
add manualtoolchange stanzas at ends of .hal files

ambitions:
use Framebuffer for graphics
investigate the lost steps reported on forum
add arduino based router rpm control using arduino PID and hall feedback

other benefits:
sound works well
fullscreen video is good for me, 1920x1080@60hz not 4K but I cant really see the diff

bad news:
I did see one real time error
I suspect it will show again but it sure isnt common

re .dtb file reconstruction
you can view the .dtb file contents with tool fdtdump
fdtdump filename.dtb > filenameTextDump.txt
and the dtc toolkit promises to create real source .dts
sudo apt-get install device-tree-compiler
then
dtc -I dtb -O dts -o a.dts a.dt
untested, amd will need diff to compare new (broken) and old (woring ) .dts files

re: dtb file sorces
I could find the .dts files for
sun8i-h3-orangepi-plus2e.dtb
IF i knew the version

at elixir.bootlin.com/linux/latest/source/a...ngepi-zero-plus2.dts
there is .dts source ( highly nested #includes)
and the .dts are listed by _version_

Does anyone know how to determine the version of a .dtb?

i read that user faradaygv saw lost steps and attributed the error to timing relations. I examined the arisc_stepgen.c and .h code and saw there was no use of dir_setp or dir_change times. faradaygv said he had no errors using the gpio pins with stepgen. I checked and saw it was a standard stepgen, it justwas hal connected to gpio pins. So the lost steps are in the arisc stepgen and the arisc step gen doesnt respect the preconditions of the dir_setup and doesnt respect the postcondition of dir_hold. The code just looks like C so I will have a go at it. The install scripts do compile the code so edits should have an effect. Any comments?

Many people await someone who will add a support of dir_setup & dir_hold to arisc driver. I hope you are the chosen one! Please don't stop.

Sounds good. Maybe respecting the preconditions of the dir_setup and the postcondition of dir_hold is why the stepgen actually works in other examples vs ignoring this and having it almost work as it does in this example.

Happy 2021. I am studying the stepgen codes. Both JMKasunich's original ( because it repects the pre and post step timing rules for DIR changes,
And studying the arisc-stepgen because it can reside in the arisc side of the opi's brain.
Right now i'm working on the "DDS" methods used to determine when changes can occur. Its a bit complex for me. Theres some clever & tricky code in here.

Hello, I have not gotten a new stepgen for arisc. BUT i looked at the gpio driver and ran some tests. I ran latency-histogram --base nnnn --servo 1000000, meaning I played with the base thread. This is on a OPi+2e booted with isolcpus=1,2,3 idle=poll and the speed forced to max. I found Unexpected RealTime errors at 20 25 30 40 50 60 80 and 90 uS base thread. I ran with 100uS base and got none. I ran for 2 days and got none ( No teasing the bears with glxgears youtube file transfers, no teasing at all ). Then i did some calculations, i figured I could get 75 mm per sec ( my 1.5mmpitch screws are .0075mm per step full step ) I needed doublestep ( and the orange cnc gpio dirver has this. The stepgen used is the standard linuxcnc stepgen ( not arisc ). I made a set of files with base 1000000 servo 1000000 and max vel 75mm/sec, scale 133.3333. The acc and max_acc were quite hig(i am running tests right now and wont tease the bears to look atthe .ini or .hal). BUT I have run a special 3DChips modified to loop 100times and to print out the counter as it decrements each iter. I have been running this ... today is 3rd day without any UXRTdelys, fullscreen, no teasing. Vel hits 4500mm/min on the straightaways. Summary, The OPI+2e can run pretty well with caveats. With single 3DChips the Axis display is quickly scaled and rotated. With the 100x loop Axis is sluggish and the toll jumps between video updaes. So dont throw away your OrangePi's. HTH tjtr33

We had Xenomai on the Allwinners 6 years ago (Cubieboards) at 40,000nS worst case latency jitter while playing videos. This was before the open mali driver and before the ARISC was used or even mentioned in any specs.

Doing this the right way means finding and building a kernel version that is stable and has low latency with preempt_rt or Xenomai. The Armbian and Raspbian devs don't seem to care about low latency.

U-boot should also be properly built for low latency and not even support options that raise latency. It is lots of work and time to do so and unfortunately we don't have the time to work on this here.

Thanks again for catching the problems with the device tree blob.