[Emc-users] the saga of gene vs pi's continues

[Gene Heskett]

Greetings all;

For lack of anything better to do this after noon I set out to cut and
assemble the 50 pin jumpers to hook up my purty, all stacked up
stairstep style, 7i42TA's. But when I plugged it in, it crowbared the
psu. And I'm standing there contemplating my sins when I realize the
7i42TA is bass ackwards, and that I have pin 1 of the 7i90 connected to
pin 50 on the 7i42TA's. Duh, so I spent the rest of the day turning the
7i42TA's around, finding there's no way to stack them facing the other
way that isn't about an inch and a half too high. So I did stack the
firt 2, but set the third on off the end of the 7i90, with the ribbon
running under the card to get at the far edge, then brought up over the
far end to arrive at the socket on the 7i42TA. There went all my plans
to keep the noise on the right end of the 7i90 and beyond, many inches
from the pi. Now I have to bring in lots of noise and connect it right
on top of the pi. I can't win. It would have been buckets cleaner if
the 7i42TA was mirrored so the pin 1's faced each other.

Now, it appears they are being fed not only from the power plugs, but via
the 50 pin cables, from the 7i90 also, and I see a jumper that might
have an effect on that in the 7i42TA's, so which is the preferred power
source giving best performance, Peter? I am thinking I should unplug the
power plugs from the 7i42TAs as thats a potential ground loop.

I have identified the clock pin on the bottom of the pi, (it's mounted
upside down to put the 40 pin adjacent to the 7i90 so that the pin ones
mate w/o needing spaghetti knots in the cable, and I've found a 15 pf
capacitor I'll stick on it tomorrow for S&G's. Progress?
DamnedifIknow.

But if it works 100% with the cap installed, I'll then verify the 7i90 is
a good one and not one I've already blown with the noise, its box will
be assembled and ready to bolt (with electrical insulation to destroy
ground loops) to the outside face of the motor driver boxes door by
tomorrow night. Then its trace everything and hook it back up again.

And howinhell do I lock a kernel version, dpkg, in getting rid of a
dependency for a doc file, just ripped out all the realtime stuff and
reinstalled the latest raspian 4.9.26 something non realtime kernel. I
hope I don't wind up starting all over on this card. dpkg is so slow on
this pi things that it will be well past midnight local before I can
reboot to a good kernel again. Thats 1h:15minutes elapsed time.

And people wonder why I run plumb out of patience. 2 steps fwd, slip and
6 steps back. Sigh... I see the light at the end of the tunnel and it
runs me over.

Cheers, Gene Heskett

[Todd Zuercher]

----- Original Message -----

Post by Gene Heskett
And people wonder why I run plumb out of patience. 2 steps fwd, slip
and
6 steps back. Sigh... I see the light at the end of the tunnel and
it
runs me over.
Cheers, Gene Heskett
--

You've the patience of Job. I'd have pitched that Pi in the rubbish bin a long time ago and bought something like this to throw at it.
https://www.neweggbusiness.com/product/product.aspx?item=9b-13-157-729

[Gene Heskett]

Post by Todd Zuercher
----- Original Message -----

Post by Gene Heskett
And people wonder why I run plumb out of patience. 2 steps fwd, slip
and
6 steps back. Sigh... I see the light at the end of the tunnel and
it
runs me over.
Cheers, Gene Heskett
--

You've the patience of Job. I'd have pitched that Pi in the rubbish
bin a long time ago and bought something like this to throw at it.
https://www.neweggbusiness.com/product/product.aspx?item=9b-13-157-729

Unforch, with that in the box, I'd have to buy another box to put the
7i90 and 7i42TA's in. And eventually I am out of space behind the lathe.
Not to mention the board might be $65, but memory for it, and a psu that
might fit in this nice new box, and I'm north of an additional $200 to
switch back to a wintel system and a fight to get it installed with the
UEFI bios. I thought of that when I bought an "up" board with a quad
core atom on it, no bigger than the pi. But it comes with a UEFI bios
enabled so you can only install windows 10 on it, and if you turn off
the UEFI, you've bricked the SOB, and I am not about to throw another
$350 in a jtag programmer and 50 more for the flashrom clipon just to
rescue a 100 dollar board. UEFI is something microsoft shoved down our
throats in another attempt to create a captive customer. Why the
industry as a whole, didn't sue them out of existence is beyond me. They
promised it could be turned off if you wanted to install something else,
but they by damn didn't tell American Megatrends it had to work if it
was turned off.

Just one of the reasons there are only glass windows in this house.

I'll stop before the air gets even bluer.

Cheers, Gene Heskett

[Mark]

Post by Gene Heskett
Unforch, with that in the box, I'd have to buy another box to put the
7i90 and 7i42TA's in. And eventually I am out of space behind the lathe.
Not to mention the board might be $65, but memory for it, and a psu that
might fit in this nice new box, and I'm north of an additional $200 to
switch back to a wintel system and a fight to get it installed with the
UEFI bios. I thought of that when I bought an "up" board with a quad
core atom on it, no bigger than the pi. But it comes with a UEFI bios
enabled so you can only install windows 10 on it, and if you turn off
the UEFI, you've bricked the SOB, and I am not about to throw another
$350 in a jtag programmer and 50 more for the flashrom clipon just to
rescue a 100 dollar board. UEFI is something microsoft shoved down our
throats in another attempt to create a captive customer. Why the
industry as a whole, didn't sue them out of existence is beyond me. They
promised it could be turned off if you wanted to install something else,
but they by damn didn't tell American Megatrends it had to work if it
was turned off.
Just one of the reasons there are only glass windows in this house.
I'll stop before the air gets even bluer.
Cheers, Gene Heskett

Never had any issues installing Linux of various flavors on a desktop or
server with UEFI. Course I dealt mainly with Dell and HP servers and
desktops. This was at work at the Lab. And this HP laptop I'm typing
this email on has UEFI. Not sure why you need to disable the UEFI to
attempt to install Linux. Methinks these injuries are mainly
self-inflicted for no apparent reason.

Mark

[Gene Heskett]

Post by Mark

Post by Gene Heskett
Unforch, with that in the box, I'd have to buy another box to put
the 7i90 and 7i42TA's in. And eventually I am out of space behind
the lathe. Not to mention the board might be $65, but memory for it,
and a psu that might fit in this nice new box, and I'm north of an
additional $200 to switch back to a wintel system and a fight to get
it installed with the UEFI bios. I thought of that when I bought an
"up" board with a quad core atom on it, no bigger than the pi. But
it comes with a UEFI bios enabled so you can only install windows 10
on it, and if you turn off the UEFI, you've bricked the SOB, and I
am not about to throw another $350 in a jtag programmer and 50 more
for the flashrom clipon just to rescue a 100 dollar board. UEFI is
something microsoft shoved down our throats in another attempt to
create a captive customer. Why the industry as a whole, didn't sue
them out of existence is beyond me. They promised it could be turned
off if you wanted to install something else, but they by damn didn't
tell American Megatrends it had to work if it was turned off.
Just one of the reasons there are only glass windows in this house.
I'll stop before the air gets even bluer.
Cheers, Gene Heskett

Never had any issues installing Linux of various flavors on a desktop
or server with UEFI. Course I dealt mainly with Dell and HP servers
and desktops. This was at work at the Lab. And this HP laptop I'm
typing this email on has UEFI. Not sure why you need to disable the
UEFI to attempt to install Linux. Methinks these injuries are mainly
self-inflicted for no apparent reason.
Mark

I fixed a usb disk intended for a backup usage, up with the debian 8
installer. It would not even admit the disk was plugged in. It looked at
it, as evidenced by a couple flickers of the access light on the disk
housing, but wouldn't touch it with a 20 foot pole. I did the same
thing with a 32Gb u-sd card, didn't recognize it. I finally found the
bios access key (no docs to be had, in the box or online that I could
find, tried to join their forum, three times, never received the
confirmation message) The forum messages I did read were mostly people
bitching about the lack of support.

Wandering thru the bios looking for the UEFI disabler, which I never
found in so many words, the only thing related was an option to disable
the TCP chip, so I did. Bricked it. A jtag programmer is the only way
to recover. $400 to reboot a $100 computer? Screwem, and the camel that
rode in on them.

If I could find another quad core atom powered board, no bigger than the
pi, and whose forum showed some support in the form of answered
questions, I might take another stab at it, but I've probably thrown a
thousand or more at this pi scene and had it working very well, but a
firmware update applied by rpi-update has made me start from scratch
several times since the 2nd of May. That fixed the piss-poor keyboard
response problems. Now if I can fix the spi clocking problems, and
figure out a way to make dpkg understand the kernel version is pinned, I
should be good to go again. I think I'd do as a previous install did,
name the kernel and kernel7 images with unique names, and specify, in
boot/config.txt, the kernel its supposed to boot. Then apt, apt-get, and
dpkg can shovel shit around in the /boot tree to their hearts content
and my realtime kernel will still be there.

Each one of these experiences is a learning event. The problem is as much
my poor short term memory as anything else. But as soon as I put
something in Dee's tummy for breakfast, that unique kernel name will be
put into effect. The next thing in this recovery is to install an even
newer rt kernel that fixes the keyboard problems. That renaming may be
the best way to pin it.

Cheers Mark, Gene Heskett

[Bertho Stultiens]

On 05/28/2017 04:20 PM, Gene Heskett wrote:
[snip]

Post by Gene Heskett
I think I'd do as a previous install did,
name the kernel and kernel7 images with unique names, and specify, in
boot/config.txt, the kernel its supposed to boot. Then apt, apt-get, and
dpkg can shovel shit around in the /boot tree to their hearts content
and my realtime kernel will still be there.
Each one of these experiences is a learning event. The problem is as much
my poor short term memory as anything else. But as soon as I put
something in Dee's tummy for breakfast, that unique kernel name will be
put into effect. The next thing in this recovery is to install an even
newer rt kernel that fixes the keyboard problems. That renaming may be
the best way to pin it.

On these systems you are supposed to have auto-update disabled and be
conservative (easy to say, hard to do). Afaik, doing an "apt-get
upgrade" will not upgrade the kernel. You normally have to do
"dist-upgrade" for kernel updates.

For the Pi, I always make a card image on my local host of the latest
running version using:

# dd if=/dev/sdX bs=4M | gzip > piimg-XYZ-$(date '+%Y%m%d%H%M%S').img.gz

(I usually add some more identifying stuff to the filename part XYZ to
keep track what is in the image)

That way I do not have to start from scratch each time something bad
happens (or the SD card dies). BTW, I have an sshfs running where the
sources are. That way I'm not trashing the SD card too soon.

Fwiw, Gene, I've got a Pi3 running:
$ uname -a
Linux picnc 4.9.30-rt20-v7+ #1 SMP PREEMPT RT Sun May 28 09:40:46 CEST
2017 armv7l GNU/Linux

And, boy is the Pi3 a heat-generator. Several crashes with the
environment here (today) at 27 degrees C and doing linuxcnc compiles.
Finally added a heatsink.

Now, if I can get linuxcnc to play nice... It is not happy about my
setup. Doing deb-package creation is too much of a pain.

[Gene Heskett]

Post by Bertho Stultiens
[snip]

Post by Gene Heskett
I think I'd do as a previous install did,
name the kernel and kernel7 images with unique names, and specify,
in boot/config.txt, the kernel its supposed to boot. Then apt,
apt-get, and dpkg can shovel shit around in the /boot tree to their
hearts content and my realtime kernel will still be there.
Each one of these experiences is a learning event. The problem is as
much my poor short term memory as anything else. But as soon as I
put something in Dee's tummy for breakfast, that unique kernel name
will be put into effect. The next thing in this recovery is to
install an even newer rt kernel that fixes the keyboard problems.
That renaming may be the best way to pin it.

On these systems you are supposed to have auto-update disabled and be
conservative (easy to say, hard to do). Afaik, doing an "apt-get
upgrade" will not upgrade the kernel. You normally have to do
"dist-upgrade" for kernel updates.
For the Pi, I always make a card image on my local host of the latest
# dd if=/dev/sdX bs=4M | gzip > piimg-XYZ-$(date
'+%Y%m%d%H%M%S').img.gz

I take it you have a rotating media attached?

Post by Bertho Stultiens
(I usually add some more identifying stuff to the filename part XYZ to
keep track what is in the image)
That way I do not have to start from scratch each time something bad
happens (or the SD card dies). BTW, I have an sshfs running where the
sources are. That way I'm not trashing the SD card too soon.
$ uname -a
Linux picnc 4.9.30-rt20-v7+ #1 SMP PREEMPT RT Sun May 28 09:40:46 CEST
2017 armv7l GNU/Linux

If you could put a deb of that kernel in my inbox, I'd be delighted!

Post by Bertho Stultiens
And, boy is the Pi3 a heat-generator. Several crashes with the
environment here (today) at 27 degrees C and doing linuxcnc compiles.
Finally added a heatsink.

Always had the small ones, no such problems, but I have not tried to
overclock it either. And it does the 100hz thread that all my dials on
the apron can do in close enough to realtime that I can't see any lags
even following perfectly if I spin the dial above the motors max speed.
I've repeatedly done so, then brought the dial back to zero, and look up
to find the onscreen dro is also on zero, so I'm a bit proud of that.

If and when I make it run again, I'll split that code out of my hal & put
it up on my web page so anybody can snarf it, if they want. I/O
assignments will have to be edited in on the users end of course.

Post by Bertho Stultiens
Now, if I can get linuxcnc to play nice... It is not happy about my
setup. Doing deb-package creation is too much of a pain.

Something I've never tried, the newer kernel I'll put in today, is a
tarball, with nothing but the /boot changes, and the /lib stuff. So dpkg
knows nothing about it. I'd love to make a deb from the tarball so dpkg
was aware of it. In the meantime I'll rename stuff to hide it from dpkg.

Cheers, Gene Heskett

[Bertho Stultiens]

Post by Gene Heskett

Post by Bertho Stultiens
For the Pi, I always make a card image on my local host of the latest
# dd if=/dev/sdX bs=4M | gzip > piimg-XYZ-$(date
'+%Y%m%d%H%M%S').img.gz

I take it you have a rotating media attached?

Well, I take the SD card and put it in my normal machine and do the
copy. And, yes, it has a spinning disk.

Post by Gene Heskett

Post by Bertho Stultiens
$ uname -a
Linux picnc 4.9.30-rt20-v7+ #1 SMP PREEMPT RT Sun May 28 09:40:46 CEST
2017 armv7l GNU/Linux

If you could put a deb of that kernel in my inbox, I'd be delighted!

Tarball contains /boot and /lib/modules/4.9.30-rt20-v7+ directories
(without leading /) and is about 32M in size:
http://media.vagrearg.org/rpi3-lcnc/rpi3-kernel-4.9.30-rt20-v7+.tar.gz

This is a direct copy from the SD card, so you should be able to put it
right on there. Though, you might want to make a backup first...

[Gene Heskett]

On Sunday 28 May 2017 13:20:18 Bertho Stultiens wrote:

[...]

Post by Bertho Stultiens

Post by Gene Heskett
If you could put a deb of that kernel in my inbox, I'd be delighted!

Tarball contains /boot and /lib/modules/4.9.30-rt20-v7+ directories
http://media.vagrearg.org/rpi3-lcnc/rpi3-kernel-4.9.30-rt20-v7+.tar.gz
This is a direct copy from the SD card, so you should be able to put
it right on there. Though, you might want to make a backup first...

Thanks, Bertho, I'll make a backup and give it a shot.

Boots right up, x still busted, plugged in the HD and while it didn't
mount anything, it id'd /dev/sda1 2 & 3, which are empty, with one
as /boot, 2 as / and 3 as swap.

But linuxcnc won't run, claims it only runs on a raspberrypi 1,2,3 when
it tries to load hm2_rpspi. Strange error to me. Idea(s)?

When over-writing in the /boot of the card, I did not copy config.txt
because I have some stuff to make it recognize the monitor set and the
audio disabled, its attached, and I didn't over-write cmdline.txt, also
attached.

uname -a reports:
Linux pionsheldon 4.9.30-rt20-v7+ #1 SMP PREEMPT RT Sun May 28 09:40:46
CEST 2017 armv7l GNU/Linux

Call me puzzled.

Cheers, Gene Heskett

[Bertho Stultiens]

Post by Gene Heskett
Boots right up, x still busted, plugged in the HD and while it didn't
mount anything, it id'd /dev/sda1 2 & 3, which are empty, with one
as /boot, 2 as / and 3 as swap.

That should be about right, except... I'm using a filesystem-file as
swap. But that is just a minor detail.

Post by Gene Heskett
But linuxcnc won't run, claims it only runs on a raspberrypi 1,2,3 when
it tries to load hm2_rpspi. Strange error to me. Idea(s)?
When over-writing in the /boot of the card, I did not copy config.txt
because I have some stuff to make it recognize the monitor set and the
audio disabled, its attached, and I didn't over-write cmdline.txt, also
attached.

There is one parameter that needs to be added to cmdline.txt:
sdhci_bcm2708.enable_llm=0

I took the instructions from Machinekit docs :-) See:
https://github.com/koppi/mk/blob/master/Machinekit-RT-Preempt-RPI.md


Well, I'n now in the position that I can report the following:
...
Starting LinuxCNC...
Starting LinuxCNC server program: linuxcncsvr
Loading Real Time OS, RTAPI, and HAL_LIB modules
Starting LinuxCNC IO program: io
Found file(REL): ./hm2-7i90-stepper.hal
Note: Using POSIX realtime
hm2: loading Mesa HostMot2 driver version 0.15
Invalid cookie
Read: 00000000 00000000 00000000 00000000
hm2_rpspi: rtapi_app_main: No such device (-19)
...

YES! I can the module to fail. Now I'll be hooking up a scope to see
what is going on (this may take a day longer, dayjob and all that, bummer).

[Bertho Stultiens]

Post by Bertho Stultiens
...
Starting LinuxCNC...
Starting LinuxCNC server program: linuxcncsvr
Loading Real Time OS, RTAPI, and HAL_LIB modules
Starting LinuxCNC IO program: io
Found file(REL): ./hm2-7i90-stepper.hal
Note: Using POSIX realtime
hm2: loading Mesa HostMot2 driver version 0.15
Invalid cookie
Read: 00000000 00000000 00000000 00000000
hm2_rpspi: rtapi_app_main: No such device (-19)
...

I can also confirm that the SPI interface is running at 50MHz and not
32MHz. This means I can, apparently, reproduce the problem.

In my preliminary tests, I think I've seen a 32MHz clock, but that might
have been an error in measurement.

The attached images are CS (yellow) CLK (blue) and MOSI (purple)(*). The
interface sends 32-bit in 4 discrete 8-bit blocks with a 30ns pause in
between. Each 32-bit word is spaced by ~800ns.

Now I can start hacking code and see if it can be fixed in some way.


(*) all the noise is due to long wires and such. There is no load on the
I/O pins, just the scope (Tektronix DPO2024B, 200MHz BW/1GS/s and
matched 1:10 probes).

[Gene Heskett]

Post by Bertho Stultiens

Post by Bertho Stultiens
...
Starting LinuxCNC...
Starting LinuxCNC server program: linuxcncsvr
Loading Real Time OS, RTAPI, and HAL_LIB modules
Starting LinuxCNC IO program: io
Found file(REL): ./hm2-7i90-stepper.hal
Note: Using POSIX realtime
hm2: loading Mesa HostMot2 driver version 0.15
Invalid cookie
Read: 00000000 00000000 00000000 00000000
hm2_rpspi: rtapi_app_main: No such device (-19)
...

I can also confirm that the SPI interface is running at 50MHz and not
32MHz. This means I can, apparently, reproduce the problem.
In my preliminary tests, I think I've seen a 32MHz clock, but that
might have been an error in measurement.
The attached images are CS (yellow) CLK (blue) and MOSI (purple)(*).
The interface sends 32-bit in 4 discrete 8-bit blocks with a 30ns
pause in between. Each 32-bit word is spaced by ~800ns.
Now I can start hacking code and see if it can be fixed in some way.
(*) all the noise is due to long wires and such. There is no load on
the I/O pins, just the scope (Tektronix DPO2024B, 200MHz BW/1GS/s and
matched 1:10 probes).

Ground loop because the scope is also grounded by its power cord?

Something sure funkity. I cleaned a lot of that up by plugging it into a
US 3 to 2 adapter, isolating the static ground.

I'll have to see if mine can save a screenshot to a fat32 usb key.

Thanks Bertho.

Cheers, Gene Heskett

[Bertho Stultiens]

Post by Bertho Stultiens
I can also confirm that the SPI interface is running at 50MHz and not
32MHz. This means I can, apparently, reproduce the problem.

This makes no sense at all. I just added a one-liner in probe_board(),
reading the cookie twice after each other.

int err = check_cookie(board);
replaced with:
check_cookie(board);
int err = check_cookie(board);

Test: the clock is at 32MHz in _both_ instances. Remove that line and
the clock is 50MHz again. Argggh... Maybe the compiler is doing funny
stuff. Could be a missing volatile.

It is too late to dig into this now. I have to sleep on this one.

[Gene Heskett]

Post by Bertho Stultiens

Post by Gene Heskett
Boots right up, x still busted, plugged in the HD and while it
didn't mount anything, it id'd /dev/sda1 2 & 3, which are empty,
with one as /boot, 2 as / and 3 as swap.

That should be about right, except... I'm using a filesystem-file as
swap. But that is just a minor detail.

Post by Gene Heskett
But linuxcnc won't run, claims it only runs on a raspberrypi 1,2,3
when it tries to load hm2_rpspi. Strange error to me. Idea(s)?
When over-writing in the /boot of the card, I did not copy
config.txt because I have some stuff to make it recognize the
monitor set and the audio disabled, its attached, and I didn't
over-write cmdline.txt, also attached.

sdhci_bcm2708.enable_llm=0

Put that in the middle of the line, rebooted, but don't see any diff in
the error so here's the whole thing:

***@pionsheldon:~ $ linuxcnc -l
LINUXCNC - 2.8.0-pre1-2771-gdc2ff49
Machine configuration directory
is '/home/pi/linuxcnc/configs/sheldon-lathe'
Machine configuration file is '7i90-axis.ini'
Starting LinuxCNC...
Found file(REL): ./hm2-7i90-stepper.hal
Note: Using POSIX realtime
hm2: loading Mesa HostMot2 driver version 0.15
HAL_hm2_rpspi: ERROR: Unsupported Platform, only Raspberry1/2/3
supported...
rtapi_app: caught signal 11 - dumping core
./hm2-7i90-stepper.hal:32: waitpid failed /usr/bin/rtapi_app hm2_rpspi

./hm2-7i90-stepper.hal:32: /usr/bin/rtapi_app exited without becoming
ready
./hm2-7i90-stepper.hal:32: insmod for hm2_rpspi failed, returned -1
Shutting down and cleaning up LinuxCNC...
Waited 3 seconds for master. giving up.
Note: Using POSIX realtime
hm2_rpspi: not loaded
<commandline>:0: exit value: 255
<commandline>:0: rmmod failed, returned -1
Note: Using POSIX realtime
hostmot2: not loaded
<commandline>:0: exit value: 255
<commandline>:0: rmmod failed, returned -1
Note: Using POSIX realtime
threads: not loaded
<commandline>:0: exit value: 255
<commandline>:0: rmmod failed, returned -1
Note: Using POSIX realtime
motmod: not loaded
<commandline>:0: exit value: 255
<commandline>:0: rmmod failed, returned -1
Note: Using POSIX realtime
trivkins: not loaded
<commandline>:0: exit value: 255
<commandline>:0: rmmod failed, returned -1
<commandline>:0: unloadrt failed
Note: Using POSIX realtime
LinuxCNC terminated with an error. You can find more information in the
log:

That faint scratching sound? Me, scratching head. :)

However, if it makes any diff, this is linuxcnc-uspace I am trying to
run. And with the buildbot down, I've no access to the rt version. :(

Post by Bertho Stultiens
https://github.com/koppi/mk/blob/master/Machinekit-RT-Preempt-RPI.md
...
Starting LinuxCNC...
Starting LinuxCNC server program: linuxcncsvr
Loading Real Time OS, RTAPI, and HAL_LIB modules
Starting LinuxCNC IO program: io
Found file(REL): ./hm2-7i90-stepper.hal
Note: Using POSIX realtime
hm2: loading Mesa HostMot2 driver version 0.15
Invalid cookie
Read: 00000000 00000000 00000000 00000000
hm2_rpspi: rtapi_app_main: No such device (-19)
...

Absolutely beautiful, expected when no 7i90 is present and hooked up.

Post by Bertho Stultiens
YES! I can the module to fail. Now I'll be hooking up a scope to see
what is going on (this may take a day longer, dayjob and all that, bummer).

Yup, until SS kicks in because you haven't kicked the bucket yet, there
is always that. And it can be a bummer.

Cheers, Gene Heskett

[Bertho Stultiens]

Post by Gene Heskett
LINUXCNC - 2.8.0-pre1-2771-gdc2ff49
Machine configuration directory
is '/home/pi/linuxcnc/configs/sheldon-lathe'
Machine configuration file is '7i90-axis.ini'
Starting LinuxCNC...
Found file(REL): ./hm2-7i90-stepper.hal
Note: Using POSIX realtime
hm2: loading Mesa HostMot2 driver version 0.15
HAL_hm2_rpspi: ERROR: Unsupported Platform, only Raspberry1/2/3
supported...
rtapi_app: caught signal 11 - dumping core
./hm2-7i90-stepper.hal:32: waitpid failed /usr/bin/rtapi_app hm2_rpspi

[snip]

Post by Gene Heskett
That faint scratching sound? Me, scratching head. :)
However, if it makes any diff, this is linuxcnc-uspace I am trying to
run. And with the buildbot down, I've no access to the rt version. :(

I guess there are some hard dependencies failing.

I'll build a clean SD card with all on it once I get it all debugged,
and hopefully fixed.

[Gene Heskett]

Post by Bertho Stultiens

Post by Gene Heskett
LINUXCNC - 2.8.0-pre1-2771-gdc2ff49
Machine configuration directory
is '/home/pi/linuxcnc/configs/sheldon-lathe'
Machine configuration file is '7i90-axis.ini'
Starting LinuxCNC...
Found file(REL): ./hm2-7i90-stepper.hal
Note: Using POSIX realtime
hm2: loading Mesa HostMot2 driver version 0.15
HAL_hm2_rpspi: ERROR: Unsupported Platform, only Raspberry1/2/3
supported...
rtapi_app: caught signal 11 - dumping core
./hm2-7i90-stepper.hal:32: waitpid failed /usr/bin/rtapi_app
hm2_rpspi

[snip]

Post by Gene Heskett
That faint scratching sound? Me, scratching head. :)
However, if it makes any diff, this is linuxcnc-uspace I am trying
to run. And with the buildbot down, I've no access to the rt
version. :(

I guess there are some hard dependencies failing.
I'll build a clean SD card with all on it once I get it all debugged,
and hopefully fixed.

It is crashed ATM, I have plugged in the HD, and trying to make a backup
image, I have now made 2 passes at copying /usr to it, getting to
something around 500 megs of the 3.6Gigs of /usr twice before it, or mc
has upchucked. mc shows a broken pipe, the 2 logins via ssh are dead,
broken pipe, no route to host, yadda yadda. Going out to it, red pwr led
only, monitor powered down from lack of drive, and pulling the power for
a couple seconds and it boots right back up. I can then fsck the HD, and
its clean, so I remounted it "mount -t ext4 /dev/sda3 /media/slash".
I'll do that then see how far I can get using rsync. But its 6:30 am
here, and I don't have one eye open simultainiously yet, needs massive
coffee input.

Probably more zz's too.

If you've a deb of the rt linux, I could try that since all I have is the
uspace version.

From the other pi:
***@raspi:~ $ ls -l /var/cache/apt/archives|grep linuxcnc
-rw-r--r-- 1 root root 12782074 Dec 18 04:02
linuxcnc-doc-en_1%3a2.8.0~pre1.2771.gdc2ff49_all.deb
-rw-r--r-- 1 root root 3705802 Dec 18 04:03
linuxcnc-uspace_1%3a2.8.0~pre1.2771.gdc2ff49_armhf.deb
-rw-r--r-- 1 root root 670600 Dec 18 04:02
linuxcnc-uspace-dev_1%3a2.8.0~pre1.2771.gdc2ff49_armhf.deb

I'm not 100% sure that is whats installed on the newer setup, but will
arrange to do that before the day is waning.

Cheers, Gene Heskett

[Gene Heskett]

Post by Bertho Stultiens

Post by Gene Heskett
LINUXCNC - 2.8.0-pre1-2771-gdc2ff49
Machine configuration directory
is '/home/pi/linuxcnc/configs/sheldon-lathe'
Machine configuration file is '7i90-axis.ini'
Starting LinuxCNC...
Found file(REL): ./hm2-7i90-stepper.hal
Note: Using POSIX realtime
hm2: loading Mesa HostMot2 driver version 0.15
HAL_hm2_rpspi: ERROR: Unsupported Platform, only Raspberry1/2/3
supported...
rtapi_app: caught signal 11 - dumping core
./hm2-7i90-stepper.hal:32: waitpid failed /usr/bin/rtapi_app
hm2_rpspi

[snip]

Post by Gene Heskett
That faint scratching sound? Me, scratching head. :)
However, if it makes any diff, this is linuxcnc-uspace I am trying
to run. And with the buildbot down, I've no access to the rt
version. :(

I guess there are some hard dependencies failing.
I'll build a clean SD card with all on it once I get it all debugged,
and hopefully fixed.

One comment, this one is failing with the newest kernel, 4.9.30-rt20-v7+.

The other pi, which works with the scope probe on the pi side of the
spiclk, is running 4.4.9-rt17-v7+, so I am going to brute force that
back in with a root session of mc. I'll bet it at least works long
enough to identify the spiclk on the scope as I know it will actually
run when I hit the right pin on the back of the pi.

A session of rsync finished making the backup to rotating media once I
started hitting it with an air hose every couple minutes. Theres plenty
of room under it for the fan.

Now, a fat32 file system (/boot) has no concept of making a file
immutable that I know of, so how can I protect the kernel.img and
kernel7.img's from being replaced by non-realtime crap from raspian?
Likewise the overlays directory. Even linux style permissions don't
translate that I know of or I'd make it all read-only. And it appears I
have done that, with no clue how to undo it, so I brought the card in
here where I could mount the partition individually, then I over-wrote
everything that was in the tarball of 4.4.9-rt17-v7+ that I had. Taking
it back out, it booted right up to 4.4.9-rt17-v7+, and linuxcnc got as
far as getting the wrong name from the card, then backed out and quit
gracefully. So its something in the rpi3-kernel-4.9.30-rt20-v7+.tar.gz
thats aglay.

Now, following along in man apt_preferences, I've written a pin file and
placed it in /etc/apt/preferences.d as "kernel.list" that reads like
this:

Package: linux-kernel
Pin: version 4.4.9-rt17-v7+
Pin-Priority: 1001

Package: linux-headers
Pin: version 4.4.9-rt17-v7+
Pin-Priority: 1001

Maybe dpkg will obey? Apt and apt-get should.

Now, to go and see if this single 15 or 17 pf cap I've got will fix it
when pasted on the back of the pi. But first:

And I am building legs for a new fan stolen from an nvidia video card
repair kit, to hold it under the pi, blowing on the heat sinks. That
should extend the uptime when it gets busy. Runs nice and quiet on 5
volts despite the 12 volt label on it.

It would be nice if all these detours didn't get in the way. :)

Cheers, Gene Heskett

[Bertho Stultiens]

Post by Gene Heskett

Post by Bertho Stultiens
I'll build a clean SD card with all on it once I get it all debugged,
and hopefully fixed.

One comment, this one is failing with the newest kernel, 4.9.30-rt20-v7+.

I think it is because lcnc was compiled with another kernel in mind. I
compiled mine with (in src dir):
$ ./configure --with-realtime=uspace
--with-kernel-headers=/home/bertho/marvin/kernel-rt-preempt/linux-rpi-4.9.y/include
--enable-non-distributable

And above was with the 4.9.30-rt20-v7+ kernel source-tree.

Your system may have a problem with the API of the newer kernel version.

[snip]

I may have a fix to the SPI problem. There seems to be a problem in
clock-setting, which me apparently have been seeing. The attached patch
is very simple and works correct and so all the time.

The second change in that patch is a temporary stack-buffer allocation
that the compiler is complaining about (too large). This should be fixed
more permanently. However, the current change is sufficient for now and
works with some headroom left:
$ cat /proc/cpuinfo |wc -c
1136

[Bertho Stultiens]

Post by Bertho Stultiens
I may have a fix to the SPI problem. There seems to be a problem in
clock-setting, which me apparently have been seeing. The attached patch
is very simple and works correct and so all the time.

And some images how it looks now :-)

I did see some more optimizations that can be applied. The transfers can
almost be halved in time if the code does write/read operations from/to
the SPI registers in a smarter way. If speed becomes an issue, send me a
request for fixing it ;-)

[Gene Heskett]

Post by Bertho Stultiens

Post by Bertho Stultiens
I may have a fix to the SPI problem. There seems to be a problem in
clock-setting, which me apparently have been seeing. The attached
patch is very simple and works correct and so all the time.

And some images how it looks now :-)

That does look better. What sort of probes are you useing on that tek
sampler?

Post by Bertho Stultiens
I did see some more optimizations that can be applied. The transfers
can almost be halved in time if the code does write/read operations
from/to the SPI registers in a smarter way. If speed becomes an issue,
send me a request for fixing it ;-)

That sounds like a heck of a deal, and s/b committed. Better transfer
speeds=lower ferrors in linuxcnc.

Now if Sebastian would get us a buildbot built for armhf again, hint,
hint. :) 3-30 pf trimmer caps s/b be here around the 5th, and if what I
found works, I can get on with the build in a day or so. I had to stop
and fix us a big bag of beef stir-fry for dinner, so I haven't been out
to complete the fan installation yet. Gel type superglue curing and all
that. Headed out to do that in a few. Dishes are rinsed and in the
sink, where they can wait.

Cheers, Gene Heskett

[Bertho Stultiens]

Post by Gene Heskett

Post by Bertho Stultiens

Post by Bertho Stultiens
I may have a fix to the SPI problem. There seems to be a problem in
clock-setting, which me apparently have been seeing. The attached
patch is very simple and works correct and so all the time.

And some images how it looks now :-)

That does look better. What sort of probes are you useing on that tek
sampler?

The probes that came with the scope:
Tektronix TPP0200 (300V CAT II)
1:10 probe, 10 MOhm, <12 pF

It is ringing a lot because of long (jumper-) wires attached to the pi's
extension-header. But I don't care for testing purposes.

Post by Gene Heskett

Post by Bertho Stultiens
I did see some more optimizations that can be applied. The transfers
can almost be halved in time if the code does write/read operations
from/to the SPI registers in a smarter way. If speed becomes an issue,
send me a request for fixing it ;-)

That sounds like a heck of a deal, and s/b committed. Better transfer
speeds=lower ferrors in linuxcnc.

Yes, that is a big deal. The question would then be if the FPGA can keep
up on the larger request packets. That I cannot tell.

At the moment, the code sends 4 bytes and then reads 4 bytes. The code
actually stalls until those bytes are sent/read before the next 4 bytes
are processed. The BCM2835 has a 16-word fifo, which could be used
asynchronously to speed up transfers.

Post by Gene Heskett
Now if Sebastian would get us a buildbot built for armhf again, hint,
hint. :) 3-30 pf trimmer caps s/b be here around the 5th, and if what I
found works, I can get on with the build in a day or so.

I'm building an SD card right now that should contain my entire setup.
I'll put it on the net as soon as I get it ready so you can test it
(with new kernel and patched lcnc).

[Gene Heskett]

Post by Bertho Stultiens

Post by Gene Heskett

Post by Bertho Stultiens

Post by Bertho Stultiens
I may have a fix to the SPI problem. There seems to be a problem
in clock-setting, which me apparently have been seeing. The
attached patch is very simple and works correct and so all the
time.

And some images how it looks now :-)

That does look better. What sort of probes are you useing on that
tek sampler?

Tektronix TPP0200 (300V CAT II)
1:10 probe, 10 MOhm, <12 pF
It is ringing a lot because of long (jumper-) wires attached to the
pi's extension-header. But I don't care for testing purposes.

Post by Gene Heskett

Post by Bertho Stultiens
I did see some more optimizations that can be applied. The
transfers can almost be halved in time if the code does write/read
operations from/to the SPI registers in a smarter way. If speed
becomes an issue, send me a request for fixing it ;-)

That sounds like a heck of a deal, and s/b committed. Better
transfer speeds=lower ferrors in linuxcnc.

Yes, that is a big deal. The question would then be if the FPGA can
keep up on the larger request packets. That I cannot tell.
At the moment, the code sends 4 bytes and then reads 4 bytes. The code
actually stalls until those bytes are sent/read before the next 4
bytes are processed. The BCM2835 has a 16-word fifo, which could be
used asynchronously to speed up transfers.

Post by Gene Heskett
Now if Sebastian would get us a buildbot built for armhf again,
hint, hint. :) 3-30 pf trimmer caps s/b be here around the 5th, and
if what I found works, I can get on with the build in a day or so.

I'm building an SD card right now that should contain my entire setup.
I'll put it on the net as soon as I get it ready so you can test it
(with new kernel and patched lcnc).

Sounds good. From this end I can report that it appears to be working
when a cap marked 10, that measures 13 pf or so, has been pasted on the
bottom of the pi, between one of the grounds at pin 25, and the spi0clk
at pin 23. A quick check to see if z jogs looks good on the scope.

I also found the calibrate signal on this fawncy scope, while more than
adequate to adjust the probes comp trimmers, actually has a very
leasurely rise and fall time in the 500ns area. BBLB crap obviously, so
one cannot assess the true hf response using its own test signal. I've
got a function generator that can beat that like a white mouthed mule!

A 1950's model kay megasweep would be handy as he!! about now.

Thanks Bertho, a lot.

Cheers, Gene Heskett

[Erik Christiansen]

Post by Gene Heskett
Now, a fat32 file system (/boot) has no concept of making a file
immutable that I know of, so how can I protect the kernel.img and
kernel7.img's from being replaced by non-realtime crap from raspian?

If you don't format fat32 for any reason other than giving the media away,
then there is no fat problem. Even if /boot is on the SD card, that's
not a great reason to use a crippled file format in a *nix environment.
For USB sticks & SD cards, I'm using:

Plug it in, and wait for automounting to complete, then:
# mount # To see what /dev/s??? it is.
# umount # So we can format it.
# mkfs.ext3 /dev/s???

If there's a better treatment for fat32, then I haven't yet heard of it,
except perhaps for going to ext4. (Haven't tried that yet.)

...

Post by Gene Heskett
Now, following along in man apt_preferences, I've written a pin file and
placed it in /etc/apt/preferences.d as "kernel.list" that reads like
Package: linux-kernel
Pin: version 4.4.9-rt17-v7+
Pin-Priority: 1001
Package: linux-headers
Pin: version 4.4.9-rt17-v7+
Pin-Priority: 1001
Maybe dpkg will obey? Apt and apt-get should.

Now that's hopefully a gremlin-proof fence. (But watch out for Murphy's
pigs.) ;-) As apt-get is quite convenient for installs/updates, it's
probably worth cultivating the habit of using that.

...

Post by Gene Heskett
It would be nice if all these detours didn't get in the way. :)

Yebbut, now you're a pinning guru. (I've just taken a quick look at
"man apt_preferences", and it suggests that /etc/apt/preferences is
'where you could specify "pinning"'. It seems to use the same syntax as
you have, though. If I can avoid having to discover what e.g.
"kernel.list" filename to use, then the apparently simpler single file
approach suits me, lower on that learning curve)

Erik

[Gene Heskett]

Post by Erik Christiansen

Post by Gene Heskett
Now, a fat32 file system (/boot) has no concept of making a file
immutable that I know of, so how can I protect the kernel.img and
kernel7.img's from being replaced by non-realtime crap from raspian?

If you don't format fat32 for any reason other than giving the media
away, then there is no fat problem. Even if /boot is on the SD card,
that's not a great reason to use a crippled file format in a *nix
# mount # To see what /dev/s??? it is.
# umount # So we can format it.
# mkfs.ext3 /dev/s???
If there's a better treatment for fat32, then I haven't yet heard of
it, except perhaps for going to ext4. (Haven't tried that yet.)
...

Post by Gene Heskett
Now, following along in man apt_preferences, I've written a pin file
and placed it in /etc/apt/preferences.d as "kernel.list" that reads
Package: linux-kernel
Pin: version 4.4.9-rt17-v7+
Pin-Priority: 1001
Package: linux-headers
Pin: version 4.4.9-rt17-v7+
Pin-Priority: 1001
Maybe dpkg will obey? Apt and apt-get should.

Now that's hopefully a gremlin-proof fence. (But watch out for
Murphy's pigs.) ;-) As apt-get is quite convenient for
installs/updates, it's probably worth cultivating the habit of using
that.
...

Post by Gene Heskett
It would be nice if all these detours didn't get in the way. :)

Yebbut, now you're a pinning guru. (I've just taken a quick look at
"man apt_preferences", and it suggests that /etc/apt/preferences is
'where you could specify "pinning"'. It seems to use the same syntax
as you have, though. If I can avoid having to discover what e.g.
"kernel.list" filename to use, then the apparently simpler single file
approach suits me, lower on that learning curve)
Erik

Well, apt just told me I named the file wrong. For a change its not
a .list, its either no extension or .pref. No complaints after I mv'd it
to "kernel.pref" That little tidbit of info is in the man page, but
about 2 paragraphs up from the examples. I had to actually read the
thing, horrors. Its one of those man pages that almost fits the TL;DR
category. One other tidbit is that they are read alphabetically, and
last one governs. So I'm wondering if I should mv the file to
zzzzz.prefs. ;-)

My bigger problem is that I may now be a pinning guru, but by this time
next week, I may have forgotten it. Short term memory is getting worse
all the time. I can recall something from the 1940's easier than what
if anything, I had for breakfast this morning. Upsetting to put it in
mixed company language...

Cheers, Gene Heskett

[John Thornton]

I hear you Gene, while I can't remember anything from 1940 for obvious
reasons I can remember things from late 50's like sledding down a road
with a rather large rock at the sharp turn a the bottom... again with
the obvious results. The one thing that Dad hated the most was loosing
his memory and I feel the same way. It's frustrating to get up from your
chair and walk from the machine shop to the garage and forget why you did...

JT

Post by Gene Heskett
Short term memory is getting worse
all the time. I can recall something from the 1940's easier than what
if anything, I had for breakfast this morning. Upsetting to put it in
mixed company language...

[Gene Heskett]

Post by John Thornton
I hear you Gene, while I can't remember anything from 1940 for obvious
reasons I can remember things from late 50's like sledding down a road
with a rather large rock at the sharp turn a the bottom... again with
the obvious results. The one thing that Dad hated the most was loosing
his memory and I feel the same way. It's frustrating to get up from
your chair and walk from the machine shop to the garage and forget why
you did...
JT

Thats called worrying about the hereafter John, you get there, and then
you can't remember what you came here after. :(

Seems like its happening more and more as the years fly by. When I was
65, & beginning to think about retiring, which it took me another 21
months to do, I had no expectation of still being here 17+ years later
and in fairly good mental health. (I think) But not so good physically,
scoliosis has crept up on me, combined with collapsing disks, so I'm
about 5 to 6" shorter than I was at 25. But we've found a pill that
helps with the sciatic pain, so I can keep on keep'in on most of the
time. I'm ok, as long as I can do it at "my" speed. :)

Post by John Thornton

Post by Gene Heskett
Short term memory is getting worse
all the time. I can recall something from the 1940's easier than
what if anything, I had for breakfast this morning. Upsetting to
put it in mixed company language...

----------------------------------------------------------------------
-------- Check out the vibrant tech community on one of the world's
most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

Cheers, Gene Heskett

[Bertho Stultiens]

Post by Gene Heskett
Boots right up, x still busted

I'm not running X on my pi. I wanted to keep it as simple as possible.
It already took ages to get all required dev-packages installed. And no,
I didn't install tex for building docs. That would've made testing a
planned event for next century.


I discovered that I sent the previous message without reading what I had
been writing. It read like "all bases are belong to us". Ah well, too
happy to get things running, non-native language, late in the evening,
etc... all good excuses ;-)

[Gene Heskett]

Post by Bertho Stultiens

Post by Gene Heskett
Boots right up, x still busted

I'm not running X on my pi. I wanted to keep it as simple as possible.
It already took ages to get all required dev-packages installed. And
no, I didn't install tex for building docs. That would've made testing
a planned event for next century.

I noticed that, theres a heck of a lot of tex. I must have watched its
bits and pieces go by for a good share of the afternoon.

Post by Bertho Stultiens
I discovered that I sent the previous message without reading what I
had been writing. It read like "all bases are belong to us". Ah well,
too happy to get things running, non-native language, late in the
evening, etc... all good excuses ;-)

I hadn't noticed. I do fairly well with most language differences as long
as its english, but I had not reached any such conclusion.

Good excuses?, yes. Its about time I construct some dinner for us as its
16:40 local time anyway.

Cheers, Gene Heskett

[Erik Christiansen]

Post by Gene Heskett
And howinhell do I lock a kernel version,

The one thing for version pinning that I have on record is:

sudo apt-get install linuxcnc=1:2.6.0~pre~joints.axes3~6a281a6

(Substitute your package name and version, naturally.)

I think I'd alias that to a short command I could use without cerebral
effort, and tweak the details for each machine, so it sorts itself out
when you move from one to another.

AFAIR, dpkg and apt-get use the same back end, but apt-get is easier to
deal with - except for one or two simple bits, like local install of a
package already downloaded, which dpkg handles easier.

Erik