Re: [Emc-developers] hostmot2-firmware
On Mon, Jul 19, 2021 at 03:29:23PM -0400, Curtis Dutton wrote: > I see that hostmot2-firmware has been marked as unmaintained. > > I will still be be adding components to hostmot2. Next up is a harmonic > drive serial encoder interface for hostmot2. > > I'll be submitting the sigma 5 encoder driver code to linux cnc as soon as > I can, though I have been testing it for the last 6 months or so and it is > working. Just need to finish documentation. (If anyone needs this now let > me know and I'll get you some source code to try out) > > Will I just be making pull requests to linuxcnc.hostmot2 firmware anyhow? For the parts that go in the hostmot2 fpga firmare, you can work directly with Peter Wallace. The linuxcnc organization still maintains the hostmot2 driver in linuxcnc itself, as well as the mesaflash firmware uploader, both of which need updates when hostmot2 fpgas get new capabilities. Jeff ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] hostmot2-firmware build problem
On 28/02/13 02:25, Matt Shaver wrote: 1. I checked out hostmot2-firmware to try out the build. 2. I have ISE 10.1 Serice Pack 3 installed at /opt/Xilinx/. 3. I run 'make' and get quite a ways (an hour+), some bitfiles even built, and then it stops with: ./pin.py SV24_144 x20_1000 fw/3x20-1/SV24.PIN.tmp # tempdir /tmp/hm2fQc9g4 # ghdl -a -fexplicit '--ieee=synopsys' IDROMConst.vhd idrom_tools.vhd PIN_SV24_144.vhd x20_1000card.vhd pinmaker_SV24_144.vhd # exited with 127 make: *** [fw/3x20-1/SV24.PIN] Error 127 What am I doing wrong? Thanks, Matt -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers Matt, which dist or git repro are you using , i could update my copy and see if i can reproduce i presume you have ghdl installed ? dave -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] hostmot2-firmware build problem
On Thu, 28 Feb 2013, Matt Shaver wrote: Date: Thu, 28 Feb 2013 00:50:47 -0500 From: Matt Shaver m...@mattshaver.com Reply-To: EMC developers emc-developers@lists.sourceforge.net To: emc-developers@lists.sourceforge.net Subject: Re: [Emc-developers] hostmot2-firmware build problem On Wed, 27 Feb 2013 21:07:06 -0800 (PST) Peter C. Wallace p...@mesanet.com wrote: It should be noted that while ISE versions 9 and 10 may build Spartan 3 bitfiles, there is a fair chance that they will not work, so its best to use the lastest for Spartan 3 and I'm going to get through the whole build, then re-run with tighter version specs in build.py. I guess the Spartan2 files should be built with 10.1, and the rest with the latest version available? At least that's what I can try next :) Yes, Thats what I would do (though 12-14 seem fine for Spartan3) I would use 13 or for Spartan6 Thanks, Matt -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your ()_() signature to help him gain world domination. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] hostmot2-firmware build problem
Peter C. Wallace wrote: It should be noted that while ISE versions 9 and 10 may build Spartan 3 bitfiles, there is a fair chance that they will not work, so its best to use the lastest for Spartan 3 and Hm, interesting. I'm using ise 10.1 to build bitfiles for Stpartan 3A and 3AN devices, with no problem. Everything is the smallest device, though, the XC3S50A(N) part. I'm doing all development on Linux, now, maybe that makes a difference. Jon -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] hostmot2-firmware build problem
On Thu, 28 Feb 2013, Jon Elson wrote: Date: Thu, 28 Feb 2013 11:57:04 -0600 From: Jon Elson el...@pico-systems.com Reply-To: EMC developers emc-developers@lists.sourceforge.net To: EMC developers emc-developers@lists.sourceforge.net Subject: Re: [Emc-developers] hostmot2-firmware build problem Peter C. Wallace wrote: It should be noted that while ISE versions 9 and 10 may build Spartan 3 bitfiles, there is a fair chance that they will not work, so its best to use the lastest for Spartan 3 and Hm, interesting. I'm using ise 10.1 to build bitfiles for Stpartan 3A and 3AN devices, with no problem. Everything is the smallest device, though, the XC3S50A(N) part. I'm doing all development on Linux, now, maybe that makes a difference. Jon The problem is subtle and comes and goes. I have only seen the problem with compilcated designs (our resolver interface with embedded 32 bit DSP shows the problem) The actual bug makes small counters (say 3 - 10 bits) fail to count! Using ISE 12 or later makes the problem go away -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your ()_() signature to help him gain world domination. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] hostmot2-firmware build problem
A Note To The E-mail Admin: This is my third (fourth now!) try on this reply. I keep getting: emc-developers@lists.sourceforge.net: host mx.sourceforge.net[216.34.181.68] refused to talk to me: 421 sog-mx-4.v43.ch3.sourceforge.com: Too many concurrent SMTP connections; please try again later And now, on with the show... On Thu, 28 Feb 2013 10:33:29 + David Armstrong dave...@outlook.com wrote: On 28/02/13 02:25, Matt Shaver wrote: What am I doing wrong? Matt, which dist or git repro are you using , i could update my copy and see if i can reproduce git clone ssh://user@git.linuxcnc.org/git/hostmot2-firmware.git i presume you have ghdl installed ? Yep! I've got /opt/Xilinx/10.1 and /opt/Xilinx/14.4. I've also installed both device pack updates. one per version. Thanks, Matt -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] hostmot2-firmware build problem
On 02/27/2013 08:41 PM, Matt Shaver wrote:
On Wed, 27 Feb 2013 20:10:00 -0700
Sebastian Kuzminsky s...@highlab.com wrote:
The 3x20 uses an FPGA that's too fancy for version 10 of ISE, you
need version 13 or better.
OK, I also have 14.4 installed in /opt/Xilinx. I have edited the
table in build.py to add '14' like so:
card2ise = { # have to fill out the rest of this stupid table...
'i20': (10, 9),
'i65': (10, 9),
'x20_2000': (14, 13, 10),
'x20_1000': (14, 13, 10, 9),
'i22_1500': (14, 13, 10, 9),
'i22_1000': (14, 13, 10, 9),
'i23': (14, 13, 10, 9),
'i68': (14, 13, 10, 9),
'i43_400': (14, 13, 10, 9),
'i43_200': (14, 13, 10, 9)
}
This still didn't work, but I didn't install the
Xilinx_2012.4.1_Device_Pack update to 14.4 yet. I'll install that see
what happens.
Do I need to edit anything else to add version 14 to my list of build
tools?
No idea, that was all I know about hostmot2 firmware building!
--
Sebastian Kuzminsky
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] hostmot2-firmware build problem
On Wed, 27 Feb 2013 20:10:00 -0700
Sebastian Kuzminsky s...@highlab.com wrote:
On 02/27/2013 07:25 PM, Matt Shaver wrote:
What am I doing wrong?
The 3x20 uses an FPGA that's too fancy for version 10 of ISE, you
need version 13 or better.
OK, I also have 14.4 installed in /opt/Xilinx. I have edited the
table in build.py to add '14' like so:
card2ise = { # have to fill out the rest of this stupid table...
'i20': (10, 9),
'i65': (10, 9),
'x20_2000': (14, 13, 10),
'x20_1000': (14, 13, 10, 9),
'i22_1500': (14, 13, 10, 9),
'i22_1000': (14, 13, 10, 9),
'i23': (14, 13, 10, 9),
'i68': (14, 13, 10, 9),
'i43_400': (14, 13, 10, 9),
'i43_200': (14, 13, 10, 9)
}
This still didn't work, but I didn't install the
Xilinx_2012.4.1_Device_Pack update to 14.4 yet. I'll install that see
what happens.
Do I need to edit anything else to add version 14 to my list of build
tools?
Thanks,
Matt
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] hostmot2-firmware build problem
On Wed, 27 Feb 2013, Matt Shaver wrote:
Date: Wed, 27 Feb 2013 22:41:59 -0500
From: Matt Shaver m...@mattshaver.com
Reply-To: EMC developers emc-developers@lists.sourceforge.net
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] hostmot2-firmware build problem
On Wed, 27 Feb 2013 20:10:00 -0700
Sebastian Kuzminsky s...@highlab.com wrote:
On 02/27/2013 07:25 PM, Matt Shaver wrote:
What am I doing wrong?
The 3x20 uses an FPGA that's too fancy for version 10 of ISE, you
need version 13 or better.
OK, I also have 14.4 installed in /opt/Xilinx. I have edited the
table in build.py to add '14' like so:
card2ise = { # have to fill out the rest of this stupid table...
'i20': (10, 9),
'i65': (10, 9),
'x20_2000': (14, 13, 10),
'x20_1000': (14, 13, 10, 9),
'i22_1500': (14, 13, 10, 9),
'i22_1000': (14, 13, 10, 9),
'i23': (14, 13, 10, 9),
'i68': (14, 13, 10, 9),
'i43_400': (14, 13, 10, 9),
'i43_200': (14, 13, 10, 9)
}
This still didn't work, but I didn't install the
Xilinx_2012.4.1_Device_Pack update to 14.4 yet. I'll install that see
what happens.
Do I need to edit anything else to add version 14 to my list of build
tools?
Thanks,
Matt
It should be noted that while ISE versions 9 and 10 may build Spartan 3
bitfiles, there is a fair chance that they will not work, so its best to use
the lastest for Spartan 3 and
Peter Wallace
Mesa Electronics
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] hostmot2-firmware build problem
On Wed, 27 Feb 2013 21:07:06 -0800 (PST) Peter C. Wallace p...@mesanet.com wrote: It should be noted that while ISE versions 9 and 10 may build Spartan 3 bitfiles, there is a fair chance that they will not work, so its best to use the lastest for Spartan 3 and I'm going to get through the whole build, then re-run with tighter version specs in build.py. I guess the Spartan2 files should be built with 10.1, and the rest with the latest version available? At least that's what I can try next :) Thanks, Matt -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] hostmot2-firmware-all .deb doesn't install firmware?
This is a bug. I thought I'd fixed it once, but apparently I botched the fix. Look for it to be re-fixed in an upcoming hostmot2-firmware release. Jeff -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] hostmot2 firmware -all doesn't pull dependencies in
To who it may concern, I have a setup problem that I think should be a fairly common issue that I would like to bring up to the development team. I have a milling machine that uses open loop steppers to operate the screws, and scales to monitor table position. I want to use the scales to monitor the table position when the drives are disabled, and I am manually moving the machine. This will mitigate the need for an MPG. My problem is, I don't see a good way to integrate the direct reading scales into the HAL component 'axis'. I can't use motor-pos-fb, because the backlash is added to it to determine actual joint position. What I think needs to happen is joint-pos-fb needs to become an input. Then I can have the option of tying my scales to that. Machines without scales would use (motor-pos-fb+lashcomp) - joint-pos-fb. I suppose a separate following error pin could be calculated too, one for the servo loop, and another for the secondary feedback (scale). I think this fits nicely with the existing line of logic, and accurately describes the mechanics of a joint. Thoughts? Brian -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] hostmot2 firmware -all doesn't pull dependencies in
On Mon, Jul 05, 2010 at 04:34:09AM +, Chris Morley wrote: I just check off hostmot2 firmware -all in synaptic and it did not automatically pull in all the firmware. Thanks for noting this. I'll fix it for the next release of hostmot2-firmware. hostmto2 firmware is the way to go now right? not sure how I missed the switch.! IMO yes. Both are fully functional, and at this point they're basically identical, but emc2-firmware won't be updated anymore. New types of firmwares (for instance the TP family for three-phase PWM) will only be added in hostmot2-firmware. Jeff PS In the current hostmot2-firmware packages you'll find the firmware description xml files we talked about a few months ago. Let me know if the format fits pncconf's needs, because for now I will not mind modifying it for that purpose. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] hostmot2 firmware loading
Sebastian Kuzminsky wrote: I've been talking to people and thinking about firmware loading for the hostmot2 subsystem. This email presents the results of this inquiry and my plan for the future. The short version is i'll be sticking with bfload, and using libraries other than upci to supply the missing PCI access methods. Read below for all the details. (snip) Well researched and well written - I need more time to digest everything. But I do have some thoughts: Regarding the udev firmware loading mechanism - for me this has never been very attractive (it has been brought up before). It comes down to a philosophical difference, and perhaps I'm the only one who looks at it this way. I'm not sure if I can put my thoughts into words, but I'm gonna try. The kernel, udev, and all that stuff exist to perform one task - to make the hardware installed in a computer available to _all_ of the applications on that computer. There are many layers of abstraction involved - user programs don't access hard disks, they access filesystems, which access block devices, which eventually access disks. The same is true for network protocol stacks, etc. But regardless of the layers involved, the operating system is managing that hardware for the benefit of the _entire_ computer and _all_ of its applications. EMC is different, or at least I think it is. For machine control purposes, I think of the PC as a very powerful and fast embedded controller, with a really nice and convenient development system (called Linux) attached to it. The hardware that EMC is using is dedicated to that machine control task and is NOT shared with the operating system or the rest of the computer. For example, with parport stepper systems we need to make sure that Linux doesn't think there is a printer attached to the port. It would be very bad to send a file to the printer port in the middle of a part run. That is why I tend to avoid trying to stuff our code into the Linux device driver model - we are not driving Linux devices. We are driving dedicated machine control hardware - even if that hardware is simply a parallel port. RTAI works outside of (or underneath) Linux, in order to deliver the embedded controller performance we want. I think there is nothing wrong (and a lot right) about a driver model that works the same way. I am aware that others probably don't share this philosophy, and am willing to consider arguments against it. There are certainly weaknesses to the embedded controller approach, especially when people want to offload the realtime stuff to genuine embedded controllers in external hardware. It's sadly awkward to do in-kernel firmware loading from user's home directories (or any non-standard firmware directory), as needed by our RIP use case. Thus we cannot use udev, and we're stuck with bfload. bfload needs to be extended to have better PCI access (access to both PCI Config space and PCI device BARs). upci currently supports BAR access only. libpci supports Config space access only. libpciaccess supports both [2]. Can you clarify exactly what config space access is needed for? I recall you telling me very briefly one night on IRC, but I never understood the details, and others here don't have any of that information. The basic bfload task is load an FPGA configuration, and that _can_ be done using BAR access only. My understanding was that config space access is only needed to implement a workaround for a bug in some number of early production Mesa cards. I plan to support TRUNK by moving bfload from upci to libpciaccess. I wont mess with upci, pci_read, or pci_write in TRUNK. libpciaccess is packaged for Ubuntu starting with Gutsy, but it's not available for Dapper [3]. Now the problem: This means TRUNK wont work on Dapper unless the developer installs libpciaccess by hand. Hardy is here and it's time to move on. I'm not ready to move on yet ;-) One big difference between machine controls and typical computer applications is the much longer life cycles. I am nowhere near ready to consign Dapper to the scrapbin. I _might_ move my main computer to Hardy one of these days. I have absolutely no intention of changing the computer that runs my mill to Hardy. I can think of no reason to do so. From what I've seen, most of the gripes with Dapper have been of the nature of Dapper doesn't support my wireless card. I realize that there will come a time when we have to move on from Dapper, just as we have moved on from 2.4 kernels, etc. But I don't think we've reached that point yet. TRUNK currently builds not only on Dapper, but on Breezy and on the BDI-4.51. I haven't discussed this specific issue with the board, but I think we had a general consensus that the 2.3.x release series wouldn't have Breezy and BDI support as must have. But nobody has talked about
Re: [Emc-developers] hostmot2 firmware loading
On Tue July 1 2008 14:05:00 John Kasunich wrote: The kernel, udev, and all that stuff exist to perform one task - to make the hardware installed in a computer available to _all_ of the applications on that computer. Much of the kernel exists to facilitate sharing, true; but udev has a slightly different job: to make hardware automatically work as smoothly as possible. I understand and generally subscribe to your model of EMC as an embedded control application running under Linux, and thus not needing much of the resource management features of Linux. But as you say, EMC uses Linux as a development UI scaffold, and I think firmware loading might have fitted in in this way. Turns out some details prevented this from working smoothly, but i'd have been happy using it if it hadnt had that path restriction problem... It would be very bad to send a file to the printer port in the middle of a part run. LOL! bfload needs to be extended to have better PCI access (access to both PCI Config space and PCI device BARs). Can you clarify exactly what config space access is needed for? I recall you telling me very briefly one night on IRC, but I never understood the details, and others here don't have any of that information. The basic bfload task is load an FPGA configuration, and that _can_ be done using BAR access only. My understanding was that config space access is only needed to implement a workaround for a bug in some number of early production Mesa cards. It's a BIOS problem (I think), not a Mesa problem. There are users out there with motherboards that do not set up the Mesa boards PCI Config space properly. At offset 4 in the Config space there's a 16-bit register called Command, which contains a bunch of single-bit flags to enable and disable different features of the device. Some (older?) BIOSes for some reason set these bits to turn off both memory and I/O access to the device! When they're set this way you can't access any of the BARs at all. You can still access the Config space, and if you turn those bits back on you can access the BARs again. So i want bfload to be able to detect that problem and work around it by fixing up the Command register. Now the problem: This means TRUNK wont work on Dapper unless the developer installs libpciaccess by hand. Hardy is here and it's time to move on. I'm not ready to move on yet ;-) Sounds like emc2 2.2 is for you! :-P I have absolutely no intention of changing the computer that runs my mill to Hardy. And nobody is asking you to. But basically the same reasons that make you not want to upgrade your OS should make you not want to upgrade your machine control software. I'd expect emc2 2.2 to be supported on Dapper et al in bugfix mode for a long time to come, while development moves ahead in other branches, on newer versions of the operating system, dropping support for older distros as they age to unmaintainability. From what I've seen, most of the gripes with Dapper have been of the nature of Dapper doesn't support my wireless card. It also doesnt support libpciaccess ;-) I realize that there will come a time when we have to move on from Dapper, just as we have moved on from 2.4 kernels, etc. But I don't think we've reached that point yet. TRUNK currently builds not only on Dapper, but on Breezy and on the BDI-4.51. I haven't discussed this specific issue with the board, but I think we had a general consensus that the 2.3.x release series wouldn't have Breezy and BDI support as must have. But nobody has talked about dropping support for Dapper. I consider Dapper to be the mainstream, with Hardy as something for the early adopters to use. Ok, this is a good conversation to have. What distros are going to be supported by 2.3? What makes this worse is that the dependency on libpciaccess will make it a chore to compile EMC, even for people who have no mesa card and have no intention of _ever_ using bfload. Making all of EMC depend on an unpackaged library, to support one workaround for a one problem on a small subset of one brand of hardware device, seems a high price to pay. Only a chore on the older (pre-Gutsy) distros. Maybe we could add a --disable-bfload flag for configure. I plan to support the 2.2 branch by using both upci and libpci in bfload. I wont mess with upci, pci_read, or pci_write in 2.2. libpci is available for Ubuntu releases back to Dapper [4]. If it is possible to do this for 2.2, then why not do the same in trunk? Because it has bad smell. Two different PCI access libraries with overlapping yet incompatible functionality (bus enumeration, device representation etc). It's kind of a hokey setup... I'd rather move to a single pci library, and it helps that it's relatively widely used, and maintained by someone else. It's just cleaner. -- Sebastian
Re: [Emc-developers] hostmot2 firmware loading
On Tue July 1 2008 14:03:35 Jeff Epler wrote: 3. It would be nice if users couldn't accidentally re-program their FPGAs in mid-run, ie if firmware loading happened at the sole discretion of the driver rather than having multiple pieces of code twiddling the boards. If bfload can determine whether the device's pci regions are in use, it could avoid programming while another hardware driver is using the device. Is this possible with any of the pci interface libraries you're looking at? Good idea! It's not a feature of the pci libraries, but you can check if /sys/devices/pci*/$(DOMAIN):$(BUS):$(DEVICE).$(FUNCTION)/driver exists, indicating that a kernel driver has claimed the PCI device. For EPP, not so much... -- Sebastian Kuzminsky my brothers are protons / my sisters are neurons I stir it twice, it's instant family! -- Gogol Bordello - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] hostmot2 firmware loading
Sebastian Kuzminsky wrote: On Tue July 1 2008 14:03:35 Jeff Epler wrote: 3. It would be nice if users couldn't accidentally re-program their FPGAs in mid-run, ie if firmware loading happened at the sole discretion of the driver rather than having multiple pieces of code twiddling the boards. If bfload can determine whether the device's pci regions are in use, it could avoid programming while another hardware driver is using the device. Is this possible with any of the pci interface libraries you're looking at? Good idea! It's not a feature of the pci libraries, but you can check if /sys/devices/pci*/$(DOMAIN):$(BUS):$(DEVICE).$(FUNCTION)/driver exists, indicating that a kernel driver has claimed the PCI device. For EPP, not so much... I'd think that a scan of /proc/ioports correlated with detected (or command-line-supplied) card addresses would tell you which cards are in use. This should also work for the parallel port, if the driver correctly uses io_request_region(). - Steve - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] hostmot2 firmware loading
On Tue July 1 2008 16:03:48 Stephen Wille Padnos wrote: Sebastian Kuzminsky wrote: On Tue July 1 2008 14:03:35 Jeff Epler wrote: 3. It would be nice if users couldn't accidentally re-program their FPGAs in mid-run, ie if firmware loading happened at the sole discretion of the driver rather than having multiple pieces of code twiddling the boards. If bfload can determine whether the device's pci regions are in use, it could avoid programming while another hardware driver is using the device. Is this possible with any of the pci interface libraries you're looking at? Good idea! It's not a feature of the pci libraries, but you can check if /sys/devices/pci*/$(DOMAIN):$(BUS):$(DEVICE).$(FUNCTION)/driver exists, indicating that a kernel driver has claimed the PCI device. For EPP, not so much... I'd think that a scan of /proc/ioports correlated with detected (or command-line-supplied) card addresses would tell you which cards are in use. This should also work for the parallel port, if the driver correctly uses io_request_region(). Of course. I'll add these checks to bfload. -- Sebastian Kuzminsky my brothers are protons / my sisters are neurons I stir it twice, it's instant family! -- Gogol Bordello - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] hostmot2 firmware loading
On Tue July 1 2008 15:45:57 John Kasunich wrote: Sebastian Kuzminsky wrote: Now the problem: This means TRUNK wont work on Dapper unless the developer installs libpciaccess by hand. Hardy is here and it's time to move on. I'm not ready to move on yet ;-) Sounds like emc2 2.2 is for you! :-P I want new features that will be part of EMC 2.3.x and beyond. I don't see why I should have to update my entire operating system to get them. Sure, someday there will be some killer feature (or killer bug) that forces us to drop support for Dapper in TRUNK. But this doesn't qualify, IMO. I see your point. There's a judgement call here: accumulating cruft to support older platforms, or abandoning older platforms for a cleaner product. Me, I'm allergic to cruft and I dont mind upgrading to stay in sync with the rest of the open source community. And IMO, upci+libpci definately counts as cruft. I guess the board will decide? How does the emc2 project make decisions like this? I'd expect emc2 2.2 to be supported on Dapper et al in bugfix mode for a long time to come, while development moves ahead in other branches, on newer versions of the operating system, dropping support for older distros as they age to unmaintainability. I intend to have both an installed 2.2 and one or more CVS checkouts on my machine. I admit that a regular user won't need or want to do that, but any developer might. If all I'm doing is running parts, I'll probably use the installed version. If I'm doing development, or testing something new that someone else has developed, or simply running a part that _needs_ a new feature, I'll use the newer version RIP. And eventually I'll replace 2.2.x with 2.3.x. For example, this week I need to test low-ppr threading. I've written the basic code on my development box, but I want to actually cut threads to make sure it works. You'd force me to install Hardy (or manually download and install libpciaccess) before I can run CVS code on my machine. Or disable bfload and everything that depends on it. After someone adds configure --disable-bfload... I realize that there will come a time when we have to move on from Dapper, just as we have moved on from 2.4 kernels, etc. But I don't think we've reached that point yet. TRUNK currently builds not only on Dapper, but on Breezy and on the BDI-4.51. I haven't discussed this specific issue with the board, but I think we had a general consensus that the 2.3.x release series wouldn't have Breezy and BDI support as must have. But nobody has talked about dropping support for Dapper. I consider Dapper to be the mainstream, with Hardy as something for the early adopters to use. Ok, this is a good conversation to have. What distros are going to be supported by 2.3? I'd like to see: 1) Official support (including .debs) for Hardy with our RT kernel 2) Official support (including .debs) for Dapper with our RT kernel 3) Official support (.debs optional) for simulator mode on vanilla Hardy with the stock kernel 4) Official support (.debs optional) for simulator mode on vanilla Dapper with the stock kernal 5) Unofficial support (no .debs, but the code works if you compile it) for Breezy with our RT kernel 6) Unofficial support (no .debs, but the code works if you compile it) for BDI-4.51 (includes an RT kernel) 7) Unofficial support for simulator mode on generic Linux, with the understanding that ./configure is going to fail until people install missing dependencies. I agree that is a conversation we should be having. I dont want to support older distros. They hold us back. Dapper doesnt have firefox 3, or even firefox 2. It's stuck back on gcc 4.0.3, glibc 2.3.6, gnome 2.12, KDE 3.5.2, and python 2.4. It's still supported, but development has moved on. The 'portability to every insane system' disease causes insanity on *all* platforms. -- H. Peter Anvin I plan to support the 2.2 branch by using both upci and libpci in bfload. I wont mess with upci, pci_read, or pci_write in 2.2. libpci is available for Ubuntu releases back to Dapper [4]. If it is possible to do this for 2.2, then why not do the same in trunk? Because it has bad smell. Two different PCI access libraries with overlapping yet incompatible functionality (bus enumeration, device representation etc). It's kind of a hokey setup... Understood. But hokey or not, it still needs to be done for 2.2. Once it is done and works, why not just keep using it? Because then we'd keep smelling bad even on new distros! I thought we had talked about extending upci to provide config space access. I realize that might also be hokey, but it avoids a lot of the duplication duplication. We did talk about that, and I dont think it'd be hokey to do that. But in parallel with our conversation, I talked with the libpci folks. Martin Mares said
Re: [Emc-developers] hostmot2 firmware loading
From: [EMAIL PROTECTED] To: emc-developers@lists.sourceforge.net Date: Tue, 1 Jul 2008 16:31:20 -0600 Subject: Re: [Emc-developers] hostmot2 firmware loading On Tue July 1 2008 15:45:57 John Kasunich wrote: Sebastian Kuzminsky wrote: Now the problem: This means TRUNK wont work on Dapper unless the developer installs libpciaccess by hand. Hardy is here and it's time to move on. HI guys. I was reading this thread and one question comes to mind ( granted I may not know what I'm talking about!) Could linuxcnc.org maintain the libpciaccess binaries compiled for Dapper , so that anyone wanting to use 2.3 (or trunk in the mean time) could down load them? Just trying to think outside the box. As for myself I use Hardy on my laptop and development programing, But I use Dapper on my lathe that I am upgrading. For me, I have found that Hardy is not nearly as stable as Dapper. I wont upgrade my lathe till I feel it is stable or I have to for features that I want. _ If you like crossword puzzles, then you'll love Flexicon, a game which combines four overlapping crossword puzzles into one! http://g.msn.ca/ca55/208 - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] hostmot2 firmware loading
On Tue July 1 2008 17:01:53 Chris Morley wrote: I was reading this thread and one question comes to mind ( granted I may not know what I'm talking about!) Could linuxcnc.org maintain the libpciaccess binaries compiled for Dapper , so that anyone wanting to use 2.3 (or trunk in the mean time) could down load them? Just trying to think outside the box. Yes, that's a possibility. It's pretty similar to what I suggested in my most recent email in this thread, that we fork our own copy of libpciaccess. As for myself I use Hardy on my laptop and development programing, But I use Dapper on my lathe that I am upgrading. For me, I have found that Hardy is not nearly as stable as Dapper. I wont upgrade my lathe till I feel it is stable or I have to for features that I want. Did you use kubuntu with KDE 4 by any chance? I tried that and found it flaky as hell. I downgraded to KDE 3.5.9 (staying on Hardy/kubuntu) and i've been much happier. -- Sebastian Kuzminsky my brothers are protons / my sisters are neurons I stir it twice, it's instant family! -- Gogol Bordello - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] hostmot2 firmware loading
Did you use kubuntu with KDE 4 by any chance? I tried that and found it flaky as hell. I downgraded to KDE 3.5.9 (staying on Hardy/kubuntu) and i've been much happier. No I use Ubuntu and Gome. Lately the problem is when switching back from another user - clicking on buttons gives sometimes strange behavior eg right button click shows but is unselectable, Bookmarks wont show when clicked etc-Only reboot fixes it. When Is EMC 2.3 projected to come out? Hopefully Classicladder 7.124 will come out with it. I feel for you, its also hard for me not fix something properly or not make it better- Thats what we do! I wonder in the real world how many users (read that not developers) actually upgrade their working machines just because we come out with a different version? Judging by emails- quite a few don't as often the first way to fix their problem is to update to the highest bug-fix version. IMHO having to add a compiled binary to Dapper, to be able to use EMC 2.3 Is not too high a price to pay because: -It would be a one time deal good through all of 2.3 bug fixes -2.3 does not update automatically anyways, so the user could choose to upgrade, the required library, the OS, or staywith EMC 2.2.X -a developer most likely has the knowledge to even compile the needed library -Instructions for users would be posted to help them through the desicions and actions needed It's just a pain in the ass isn't it? or is it a lot more that I am missing? Chris Morley _ - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
