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

[Gene Heskett]

On Tuesday 30 May 2017 14:05:15 John Thornton wrote:

> 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. :)

> On 5/30/2017 1:56 AM, Gene Heskett wrote:
> > 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
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

[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

On 5/30/2017 1:56 AM, Gene Heskett wrote:

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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

[Gene Heskett]

On Tuesday 30 May 2017 02:06:38 Erik Christiansen wrote:

> On 29.05.17 16:58, Gene Heskett wrote:
> > 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.)
>
> ...
>
> > 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 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.
>
> ...
>
> > 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 
z.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
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

[Erik Christiansen]

On 29.05.17 16:58, Gene Heskett wrote:
> 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.)

...
> 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 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.

...
> 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

--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

[Gene Heskett]

On Monday 29 May 2017 18:57:00 Bertho Stultiens wrote:

> On 05/30/2017 12:39 AM, Gene Heskett wrote:
> >>> 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.
>
> >> 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.
>
> > 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
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

[Bertho Stultiens]

On 05/30/2017 12:39 AM, Gene Heskett wrote:
>>> 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.


>> 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.


> 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).


-- 
Greetings Bertho

(disclaimers are disclaimed)

--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

[Gene Heskett]

On Monday 29 May 2017 17:21:58 Bertho Stultiens wrote:

> On 05/29/2017 11:13 PM, Bertho Stultiens wrote:
> > 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?
>
> 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
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

[Bertho Stultiens]

On 05/29/2017 11:13 PM, Bertho Stultiens wrote:
> 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 ;-)

-- 
Greetings Bertho

(disclaimers are disclaimed)
--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

[Bertho Stultiens]

On 05/29/2017 10:58 PM, Gene Heskett wrote:
>> 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


-- 
Greetings Bertho

(disclaimers are disclaimed)
diff --git a/src/hal/drivers/mesa-hostmot2/hm2_rpspi.c b/src/hal/drivers/mesa-hostmot2/hm2_rpspi.c
index a6a8b5c..72b14f2 100644
--- a/src/hal/drivers/mesa-hostmot2/hm2_rpspi.c
+++ b/src/hal/drivers/mesa-hostmot2/hm2_rpspi.c
@@ -473,6 +473,7 @@ static void setup_gpio(uint16_t spiclkdiv) {
 	BCM2835_GPFSEL1 = x;
 
 	/* set up SPI */
+	BCM2835_SPICLK = 0;	// Do it twice with different values, otherwise it will not be set properly
 	BCM2835_SPICLK = (1 << spiclkdiv);
 
 	BCM2835_SPICS = 0;
@@ -505,7 +506,7 @@ static void restore_gpio() {
 static platform_t check_platform(void)
 {
 	FILE *fp;
-	char buf[8192];
+	char buf[2048];	// FIXME: This is bad, large buffer on the stack and may never be enough
 	size_t fsize;
 
 	fp = fopen("/proc/cpuinfo", "r");
--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

[Gene Heskett]

On Monday 29 May 2017 01:04:09 Bertho Stultiens wrote:

> On 05/28/2017 10:32 PM, Gene Heskett wrote:
> > pi@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
>
> [snip]
>
> > 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
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

[Gene Heskett]

On Monday 29 May 2017 01:04:09 Bertho Stultiens wrote:

> On 05/28/2017 10:32 PM, Gene Heskett wrote:
> > pi@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
>
> [snip]
>
> > 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:
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
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

[Bertho Stultiens]

On 05/28/2017 10:32 PM, Gene Heskett wrote:
> pi@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
[snip]
> 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.


-- 
Greetings Bertho

(disclaimers are disclaimed)

--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

[Bertho Stultiens]

On 05/28/2017 10:09 PM, Bertho Stultiens wrote:
> 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.


-- 
Greetings Bertho

(disclaimers are disclaimed)

--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

[Gene Heskett]

On Sunday 28 May 2017 16:09:07 Bertho Stultiens wrote:

> On 05/28/2017 09:20 PM, Bertho Stultiens wrote:
> > 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:    
> > 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
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

[Gene Heskett]

On Sunday 28 May 2017 15:29:57 Bertho Stultiens wrote:

> On 05/28/2017 09:00 PM, Gene Heskett wrote:
> > 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.
>
> 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
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

[Bertho Stultiens]

On 05/28/2017 09:20 PM, Bertho Stultiens wrote:
> 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:    
> 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).

-- 
Greetings Bertho

(disclaimers are disclaimed)
--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

[Bertho Stultiens]

On 05/28/2017 09:00 PM, Gene Heskett wrote:
> 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 ;-)


-- 
Greetings Bertho

(disclaimers are disclaimed)

--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

[Bertho Stultiens]

On 05/28/2017 09:00 PM, Gene Heskett wrote:
> 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.


> 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:    
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).


-- 
Greetings Bertho

(disclaimers are disclaimed)

--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

[Gene Heskett]

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

[...]

> > 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...

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
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline 
fsck.repair=yes rootwait dwc_otg.fiq_fsm_enable=0 dwt_otg.fiq_enable=0 
dwc_otg.nak_holdoff=0 usbhid.mousepoll=0
# For more options and information see
# http://rpf.io/configtxtreadme
# Some settings may impact device functionality. See link above for details
 
[all] 
dtoverlay=pi3-disable-bt
dtoverlay=navio-rgb

dtparam=spi=on
dtoverlay=spi0-2cs
dtoverlay=spi1-1cs,cs0_pin=16,cs0_spidev=disabled
dtoverlay=rcio
dtoverlay=navio-rgb

dtparam=i2c1=on
dtparam=i2c1_baudrate=100

#dtdebug=1
# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
framebuffer_width=1366
framebuffer_height=768

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
#dtparam=audio=on
start_x=1
gpu_mem=128
--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

[Bertho Stultiens]

On 05/28/2017 06:41 PM, Gene Heskett wrote:
>> 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 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.


>> 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
> 
> 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...


-- 
Greetings Bertho

(disclaimers are disclaimed)

--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

[Gene Heskett]

On Sunday 28 May 2017 10:44:46 Bertho Stultiens wrote:

> On 05/28/2017 04:20 PM, Gene Heskett wrote:
> [snip]
>
> > 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 take it you have a rotating media attached?

> (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

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

> 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.

> 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
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

[Bertho Stultiens]

On 05/28/2017 04:20 PM, Gene Heskett wrote:
[snip]
> 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.


-- 
Greetings Bertho

(disclaimers are disclaimed)

--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

[Gene Heskett]

On Sunday 28 May 2017 07:53:32 Mark wrote:

> On 05/28/2017 01:00 AM, Gene Heskett wrote:
> > 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
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

[Mark]

On 05/28/2017 01:00 AM, Gene Heskett wrote:


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



--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

[Gene Heskett]

On Saturday 27 May 2017 23:42:17 Todd Zuercher wrote:

> - Original Message -
>
> > 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
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

[Erik Christiansen]

On 27.05.17 22:50, Gene Heskett wrote:
> 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

--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

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

[Todd Zuercher]

- Original Message -

> 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
 

--
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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users