#linuxcnc-devel Logs

Feb 14 2020

09:20 AM skunkworks: been running axis overnight.. 50khz base thread - no realtime delays
10:14 AM skunkworks: can't open a browser though.. ;)
11:02 AM skunkworks: what was the BDI emc based on? (os)
11:09 AM jthornton: I have a BDI disk around here somewhere
11:39 AM jepler: my memory claims BDI 2 was based on Red Hat Linux and BDI4 (5?) was based on Knoppix, which in turn was based on Debian. emc2 was based on Ubuntu and later on it (or linuxcnc) was based on debian.
11:45 AM pcw_home: Was BDI RTAI based? (I guess the original EMC was run on Windows NT )
12:00 PM -!- #linuxcnc-devel mode set to +v by ChanServ
12:01 PM cradek: IIRC there were rtlinux (?) and RTAI BDIs
12:17 PM cerna: When we are talking about history, was the '.comp' pre-compiler present from the start?
12:18 PM cradek: no, that was a later addition to HAL. HAL wasn't even present from the start.
12:23 PM pcw_home: Hard to imagine LinuxCNC without HAL
12:58 PM skunkworks: thanks
12:58 PM skunkworks: i actually found references to readhat
01:49 PM linuxcnc-build: build #3038 of 1530.rip-jessie-rtpreempt-amd64 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1530.rip-jessie-rtpreempt-amd64/builds/3038 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
01:49 PM linuxcnc-build: build #6429 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/6429 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
03:50 PM skunkworks: I think when I started you guys had just created the first ubuntu livecd. 6.04?
03:56 PM cradek: 5.10 is the first ubuntu we used. I don't remember whether it was live though
04:13 PM JT-Shop: 6.04 IIRC was the first one I got to work
04:39 PM jthornton: my BDI disk says BDI EMC ver 2.20
04:41 PM jthornton: the READ-ME-NOW file contents https://paste.ubuntu.com/p/ZnmMwQQPNf/
04:47 PM andypugh: Sounds like whats-his-name
04:47 PM jepler: Paul Corner
04:47 PM andypugh: Aye, that’s the name
04:48 PM andypugh: I wonder if it’s time to call an IRC meeting to discuss where we are going with 2.8?
04:48 PM andypugh: We may need a new release manager.
04:49 PM andypugh: Ie, one who will release
04:51 PM andypugh: I tried to make practice packages, but without the signing keys and repository scripts it isn’t possible to make packages as we are going to need some local backports.
04:52 PM andypugh: (swap any technical terms that I have miss-used for the correct ones)
04:53 PM andypugh: It looks like we can do 64-bit RTAI and preempt-rt on Buster.
04:54 PM andypugh: Quite how we communicate that folk should use preempt-rt first then try RTAI if it is hopeless is something to be discused too.
04:56 PM andypugh: Note that I don’t balme mozmck for not releasing, I know how things can get in the way. I have been pretty much dormant since September due to work trips and the holiday season. I am currenlty looking at a 9 page forum backlog and emails to get round to in my inbox from September.
05:14 PM jthornton: don't know how much help I can be but I'll do what I can to help
05:17 PM cerna: Is there some discussion on why the PCI(e) FPGA cards (MESA hostmot2 mostly) were not built to use DMA?
05:17 PM andypugh: You mean pull rather than push?
05:18 PM andypugh: If so, then I suspect to guarantee data freshness,
05:18 PM cerna: I mean direct access to the memory outside CPU.
05:19 PM skunkworks: isn't that what it does?
05:19 PM cerna: I am asking because I am currently looking into the AMBA AXI protocols.
05:19 PM andypugh: I think it is so that the FPGA gets sent the new data, rather than pulling potentially stale data.
05:20 PM andypugh: I think that the current implementation makes more sense in the context of an RTOS>
05:20 PM andypugh: (though I didn’t write the low-level parts of the driver)
05:22 PM andypugh: There is a layer in the driver where the FPGA is fed a contiguous memory block and then does address-to-register translation internally (the TRAM layer) but it isn’t actually used as performance is fine without it)
05:24 PM cerna: Yeah, it would require hard support inside the FPGA core.
05:24 PM andypugh: The Hostmot2 FPGA side of TRAM is there.
05:24 PM skunkworks: I think the machinekit fork did irq'ing with mesa..
05:25 PM andypugh: seb_kuzminsky: might know wht TRAM is all there, but not used?
05:30 PM cerna: I don't suppose you know from the-top-of-the-head in which file the TRAM stuff is defined?
05:33 PM andypugh: Yes. src/hal/drivers/mesa_hostmot2/tram.c
05:33 PM andypugh: https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/drivers/mesa-hostmot2/tram.c
05:34 PM cerna: Thanks. I was looking for it in the *_pci.c.
07:06 PM andypugh_ is now known as andypugh
09:18 PM burklefoo: TRAM was originally included to make eventual DMA support easier, but it turns out that with the small amount of data needed DMA was not a big win vs simple synchronous I/O
09:24 PM Tom_itx is now known as Tom_L
09:26 PM jepler: I'm trying to remember if we use it on EPP to reduce bus cycles, or if it wasn't even needed there
10:09 PM burklefoo: I thought it might be used there but I have not looked at anything EPP for quite a while