On Saturday 27 May 2017 04:49:51 Bertho Stultiens wrote: > On 05/27/2017 05:46 AM, Gene Heskett wrote: > [snip] > > > This is the exact same response from the 7i90 at the initial 50 MHz > > clocking: > > > > 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 > > Unknown board: HOST???? <------ same exact but wrong response > > [snip] > > This is printed at line 314 in > src/hal/drivers/mesa-hostmot2/hm2_rpspi.c in the probe_board() > function. > > [snip] > > > With the demise of the armhf build machine, where do I find the srcs > > for this driver? > > Isn't this at: > https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/drivers/mesa- >hostmot2/hm2_rpspi.c > > > It makes sense to me to fix the driver rather than trying > > to hack up a capacitor...[snip] > > Yes, indeed, fixing the driver would be the correct way. > > I just had a look at the code (from above link) and it does not make > much sense that the first access to the card is at 50 MHz and > subsequently 32 MHz. > > The SPI interface is configured once in setup_gpio() and then the > hardware config is used as is from then on. Therefore, once the > hardware registers are set, it should work the same way every time. > > The behavior reminds me of one possible problem, caching. If that is > the problem, then loading the module a second time should not give you > the 50 MHz initial board-probe, but the 32 MHz as set before.
> If loading the module twice give you the same result, then it may be > possible that the hardware will only change setup once activated > (maybe through CS cycling). Therefore, the board-probe may be (partly) > at high speed, then the hardware discovers it has a new setup and > subsequently uses the correct hardware register setup. > > You can verify the hypothesis by looking at the scope. There are > actually two commands sent: read cookie and read board ident (you > should see two assertions of CS in that process). If the first 16 > bytes are read at 50 MHz and the next 8 bytes at 32 MHz, then the > hardware is switching speed after the first transfer. > I would tend to think that the theory was if it works at 50 MHz, then it ought to be rock solid at 32 MHz. The switch to 32 MHz then assures it works well within its limits. Its been quite a while since I kicked any tires in C, but I've copied the file, and see if I can see a way to lag the clock by a few nanoseconds since it seems to work well with the 10x scope probe attached. The scope doesn't have to be on, just attached. > If so, then there may be a simple work-around for the problem. Alter > the code to do a dummy read in probe_board() (calling > check_cookie()/read_ident(), see lines 292 and 296) and discarding the > result in the first go. Then the second iteration is used as the > actual probe, where the hardware should be running at the correct > speed. > > The thing is, one peculiarity speaks against the hypothesis. You do > not see an error message "Invalid Cookie", which is emitted when > reading the cookie fails. This is the first transfer, which, under my > hypothesis, should fail at the 50 MHz speed. > I have seen the bad cookie message too but its much rarer. Easy to get though, just move the probe to the 7i90 side of the termination resistor. That loading shows a reduced swing of the clock, just enough I'd guess the 7i90 never sees a logic 0. In that event the cookie is printed as: 00000000 00000000 00000000 00000000 It never gets below .95 volts, nor above 2.75 volts. These are the probes that came with the scope. I am tempted to replace them with the 200MHz rated probes from mpja.com. Hmmm, I may already have them, on the Hitachi v1065. > Anyhow, it might be worth a try. If I can rebuild just this module on the pi itself, that is TBD. build-essential is on it. But it reminds me that: [snip] build-essential is already the newest version. You might want to run 'apt-get -f install' to correct these: The following packages have unmet dependencies: libraspberrypi-doc : Depends: libraspberrypi0 (= 1.20170427-1) but it is not going to be installed E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution). pi@pionsheldon:~ $ sudo apt-get -f install Reading package lists... Done Building dependency tree Reading state information... Done Correcting dependencies... Done The following extra packages will be installed: libraspberrypi0 raspberrypi-bootloader The following NEW packages will be installed: libraspberrypi0 raspberrypi-bootloader 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. 22 not fully installed or removed. Need to get 0 B/4,147 kB of archives. After this operation, 16.3 MB of additional disk space will be used. Do you want to continue? [Y/n] Which I have not done because rpi-update has been run, which updates the firmware, and the second package (raspberrypi-bootloader) above will brick it by re-installing the older firmware. BTDT, had to start a new sd card build from square one, which takes about 4 hours to a bootable card, and another 6 or more to install enough utils that one can actually do something. Then a couple days sorting dependencies while trying to install the linuxcnc deb's I lifted from the other pi that first showed me that error I've posted a dozen times now, and found it worked reliably with the scope probe attached. > > I also have some sort of a lightdm or related problem. Both pi's > > have the latest firmware update in them now, and both now boot to a > > medium grey blank screen, BUT I do have a movable mouse pointer, > > and a right click on the mouse brings up a menu, from which I can > > call up a terminal session, and gfx stuff, run from the cli, works > > just as if I had a full blown x-server, so thats head scratcher #2 > > ATM. > > Ah, the beautiful headaches X can give you (sorry about the sarcasm). > It seems here that your X session is not started properly. My traceing and poking about seems to indicate a dbus problem, but reinstalling everything dbus related has no effect. The limited color pallate of the 16 bit framebuffer is a bit of a problem, so I ran, as root, fbset --depth 24, and nothing restores it, with reboots still showing the 16 bit depth, so its not sticky. fbset doesn't return an error either. But since I can run linuxcnc without it, its not a total show stopper. > > What should I do next? > > Try and try again? > > ;-) Thats not the smiley I'd use. 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 <http://geneslinuxbox.net:6309/gene> ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
