Back
[01:27:58] <jmkasunich> dang, no seb
[02:19:04] <jmkasunich> seb_kuzminsky: the README for firmware loading describes a "sample" hotplug script
[02:19:18] <jmkasunich> but you wrote that there is actually a provided one, called firmware_helper
[02:19:49] <jmkasunich> what if we wanted one that does something different?
[02:20:24] <SWPadnos> you can write what you want - the kernel module gets the bytes your helper writes to that file
[02:20:55] <jmkasunich> for example, SWPadnos pointed out that we don't really want to put a bitfile parser in kernel space, so what if the parser was part of the "helper" and it sent the raw, unpacked bitstream to the sysfs entry?
[02:22:33] <jmkasunich> how does the kernel (or the hotplug system I guess) know what helper to invoke?
[02:23:16] <SWPadnos> I think that goes in the udev system somewhere
[02:25:50] <jmkasunich> darn - seb's computer is here, but he isn't
[02:26:16] <SWPadnos> heh
[02:26:24] <SWPadnos> at least he'll have scrollback
[02:26:51] <jmkasunich> poor substitute for a conversation
[02:27:36] <SWPadnos> yes
[02:27:59] <jmkasunich> dog wants to go for his walk (whining) - I bet seb shows up right after I leave
[02:28:15] <SWPadnos> heh - check back when you return
[02:28:26] <jmkasunich> I'll do that - back in 20-30 mins
[02:28:30] <SWPadnos> I'll probably be gone by then though (that may speed things up ;) )
[02:35:56] <jmkasunich> it started raining
[02:36:17] <SWPadnos> heh
[02:54:11] <jmkasunich> hmm
[02:54:28] <jmkasunich> he posted to the list, and then disconnected from here
[02:58:05] <jmkasunich> hi seb_kuzminsky (again)
[02:58:12] <seb_kuzminsky> hi again :-)
[02:58:16] <seb_kuzminsky> how's the dog?
[02:58:31] <jmkasunich> whining a bit - I'll walk him after the rain stops
[02:58:37] <jmkasunich> I just read your latest email
[02:58:52] <jmkasunich> and the docs on request_firmware
[02:59:42] <jmkasunich> the docs imply that hotplug can invoke a user space helper, but don't say how it decides which helper to invoke
[02:59:47] <seb_kuzminsky> it's a good solution to a very specific problem, which is very similar to our problem...
[03:00:06] <seb_kuzminsky> i described it in your scrollback buffer :-)
[03:00:30] <jmkasunich> huh?
[03:00:53] <jmkasunich> I didn't see a single word from you the first time you connected
[03:01:21] <seb_kuzminsky> strange, i typed like 10 lines around 20:51... hang on a sec
[03:01:46] <jmkasunich> timed out here, at 22:53
[03:01:53] <jmkasunich> I assume thats 20:53 where you are
[03:01:55] <SWPadnos> assuming it's ~21:02 for you right now, you were offline at the time
[03:02:19] <seb_kuzminsky> grrr my network is the suck
[03:02:36] <seb_kuzminsky> sorru, ok i'll cut-n-paste from *my* scrollback buffer
[03:02:42] <SWPadnos> heh
[03:02:53] <seb_kuzminsky> udev reads /etc/udev/rules.d to know what to do with different events from the kernel
[03:03:02] <seb_kuzminsky> on hardy, in 80-programs.rules there's a line that says:
[03:03:09] <seb_kuzminsky> 80-programs.rules:SUBSYSTEM=="firmware", ACTION=="add", RUN+="firmware_helper"
[03:03:16] <seb_kuzminsky> this means: when the kernel wants to add a firmware, run firmware_helper
[03:03:24] <seb_kuzminsky> firmware_helper is a ubuntu replacement for the standard udev firmware helper, which is called firmware.sh
[03:03:31] <seb_kuzminsky> firmware.sh is like the "sample" firmware hotplug script in the kernel doc directory
[03:03:39] <seb_kuzminsky> firmware_helper is reimplemented in C for *blinding* *fast* firmware loading, and more annoying search-path-changing
[03:03:43] <jmkasunich> I see - so there isn't a way to say "for driver X, run helper foo, for everybody else, run firmware_helper"
[03:03:48] <seb_kuzminsky> if we wanted a custom firmware helper, we'd just change the udev rules
[03:03:56] <seb_kuzminsky> i'm not sure a bitfile parser belongs there though - it'd break all those other drivers' firmwares
[03:04:03] <seb_kuzminsky> wifi cards often need firmware and they all get it via udev, look in /lib/firmware
[03:04:15] <seb_kuzminsky> ... ok, caught up
[03:04:25] <seb_kuzminsky> jmkasunich: i think there may be a way
[03:04:50] <seb_kuzminsky> i think we could add more restrictions to the event that must be matched, and if it all matches then run our helper
[03:05:23] <jmkasunich> if there was a non-ugly way to invoke our own helper, it could get the bitfile parsing out of kernel space, let us do some error checking on the firmware file, etc, _and_ make our own decisions about where to get the firmware from
[03:06:01] <SWPadnos> ... ideally while remaining compatible with "older" systems
[03:06:44] <jmkasunich> well, I think udev and the firmware API is "older" than libpciaccess - doesn't it date from 2.5.x?
[03:06:59] <jmkasunich> that means Dapper will have it, and the whole "why kill Dapper" issue is moot
[03:07:01] <SWPadnos> hmmm
[03:07:20] <seb_kuzminsky> it looks like we can be more restrictive and add a custom firmware loader for hostmot2:
[03:07:21] <SWPadnos> sysfs was there for a while, then udev replaced it. I'm not sure when that happened
[03:07:26] <seb_kuzminsky> http://reactivated.net/writing_udev_rules.html
[03:08:01] <seb_kuzminsky> SUBSYSTEM=="firmware", ACTION=="add", DRIVER="hostmot2", RUN+="hostmot2_firmware_helper"
[03:08:18] <seb_kuzminsky> s/DRIVER="/DRIVER=="/
[03:08:36] <seb_kuzminsky> the == means "match this" and the = means "do this"
[03:09:58] <jmkasunich> /etc/udev/80-program.rules _does_ exist in dapper
[03:10:22] <jmkasunich> I'm not sure at the moment how a RIP would modify it though
[03:11:06] <seb_kuzminsky> we can add files to /etc/udev/rules.d at will, udev will find them and read them
[03:11:27] <SWPadnos> I wonder in what context the helper program is run
[03:11:43] <seb_kuzminsky> it runs as a child of udevd
[03:11:46] <jmkasunich> yeah, but that implies a "make install" step for RIP - which by definition currently doesn't need installed and doesn't touch anything outside the source tree
[03:11:47] <SWPadnos> ie, does it get the environment from the shell that loaded the module?
[03:12:03] <jmkasunich> I doubt it
[03:12:03] <SWPadnos> hmmm
[03:12:24] <seb_kuzminsky> SWPadnos: no, it gets a sanitized env from udevd, including a bunch of variables telling it what it's supposed to do
[03:12:28] <SWPadnos> right
[03:12:31] <seb_kuzminsky> the firmware name requested by the driver, for example
[03:12:37] <jmkasunich> remember, in the normal Linux scenario, its not a shell that loaded the module and got the whole thing started
[03:12:56] <seb_kuzminsky> jmkasunich: yes, it does mean a "make install", which isnt so good
[03:13:17] <jmkasunich> plug in USB widget, hotplug system loads the driver, the driver requests firmware, hotplug system sends the fw, etc
[03:13:28] <seb_kuzminsky> the alternative to our own firmware helper is to symlink the RIP's firmware dir into /lib/firmware, which i think is fairly comparable
[03:13:57] <jmkasunich> comparable in that it also requires writing something outside the source tree
[03:14:02] <seb_kuzminsky> right
[03:14:17] <seb_kuzminsky> another "make install" step the fuzzes the notion of RIP
[03:14:45] <jmkasunich> maybe a bit worse actually, since if you were switching between one RIP and another (or between RIP and installed) you;d have to rewrite the symlinks
[03:15:07] <seb_kuzminsky> you might want to do that anyway, if the different RIPs had different firmware_helpers
[03:15:13] <jmkasunich> whereas it would probably be possible to have a helper that was smart enough to figure out where it should get the driver
[03:15:17] <jmkasunich> s/driver/fw
[03:15:32] <jmkasunich> yeah, its a "might" vs. "must"
[03:15:43] <SWPadnos> the emc script could probably make the symlinks if necessary
[03:15:50] <jmkasunich> eww
[03:15:57] <seb_kuzminsky> yea eww
[03:16:09] <SWPadnos> but the firmware helper would have to be smart enough to know whether it was running from a RIP or installed
[03:16:16] <seb_kuzminsky> this whole "write random crap outside the tree, outside the knowledge of the packaging system" makes me queasy
[03:16:21] <SWPadnos> yeah, it's ewww, but at least it would be semi-automatic
[03:16:23] <SWPadnos> yes
[03:16:35] <jmkasunich> seb_kuzminsky: you and me both
[03:16:36] <SWPadnos> and the packaging system doesn't know how to deal with RIP
[03:16:47] <SWPadnos> (and we don't want it to)
[03:17:08] <seb_kuzminsky> i think the only diff between the standard firmware_helper and "our" firmware_helper would be that ours accepts absolute paths
[03:17:11] <jmkasunich> I think we can agree on one thing: if we were only worried about installed (either make install or .deb) then udev is (as paul said) the "only way"
[03:17:31] <seb_kuzminsky> jmkasunich: yes, 100%
[03:17:47] <SWPadnos> hmmm. the driver has to request a hotplug event (for the most part), right?
[03:18:00] <seb_kuzminsky> SWPadnos: yes, request_firmware("filename")
[03:18:01] <SWPadnos> nevermind - I was about to say something stupid
[03:18:09] <seb_kuzminsky> hehe
[03:18:31] <jmkasunich> given the agreement about installed, the sticking point is RIP
[03:18:32] <SWPadnos> (RIP and "normal" could use different versions of the driver, but that's a PITA, plus the configs would be different)
[03:18:46] <seb_kuzminsky> paul hates RIP, but to me it's a natural and desirable thing
[03:18:55] <seb_kuzminsky> check out, hack, compile, test, repeat
[03:19:00] <jmkasunich> RIP does serve a purpose for us - how do other projects accomplish the same goals?
[03:19:04] <seb_kuzminsky> no installation step necessary
[03:19:13] <seb_kuzminsky> small projects do fine with just rip
[03:19:27] <seb_kuzminsky> big projects like maybe x and such dont do it, i think
[03:19:46] <seb_kuzminsky> beyond a certain level of complexity it's just too hairy, as we're finding out
[03:19:47] <SWPadnos> many programs will run with whatever PREFIX you want, it's just the packaging that needs to be tested by installing with the package manager
[03:19:49] <jmkasunich> so developers more or less have to dedicate a system to each branch they are working on
[03:20:03] <SWPadnos> wrong button :)
[03:20:07] <jmkasunich> man, his network does suck
[03:20:17] <SWPadnos> no, that was a client exit
[03:20:21] <seb_kuzminsky> oops sorry
[03:20:24] <jmkasunich> heh
[03:20:25] <SWPadnos> like I said, wrong button
[03:20:37] <seb_kuzminsky> ^W is "close window", not "delete word"...
[03:20:39] <jmkasunich> I was giving you the benefit of the doubt and blaming your network
[03:20:42] <seb_kuzminsky> hehe
[03:20:53] <seb_kuzminsky> oh yea that's what i meant, the network crapped out
[03:20:57] <SWPadnos> riiiiiight
[03:20:59] <SWPadnos> :)
[03:21:17] <jmkasunich> ok, back to RIP
[03:21:25] <seb_kuzminsky> uh so yea, the PREFIX thing works fine as long as you're not relying on other infrastructure that doesnt know your PREFIX
[03:21:47] <SWPadnos> most applications don't include kernel modules, so they aren't as much of a pain for the RIP thing
[03:21:55] <jmkasunich> that is the issue really - most "small" projects don't contain kernel modul.... what he said
[03:22:41] <seb_kuzminsky> even kernel modules are fine if you dont want to use uevent/udev
[03:22:53] <jmkasunich> the udev/hotplug system isn't designed to be invoked by "starting an application", they are designed to be invoked by plugging in a device
[03:22:57] <SWPadnos> Firefox doesn't include kernel moduels either, and I'm pretty sure you can compile and run in place
[03:23:15] <jmkasunich> right - thats why I said put "small" in quotes
[03:23:31] <seb_kuzminsky> jmkasunich: i'm not sure i agree with that description of udev
[03:23:38] <SWPadnos> no, kernel modules are a problem anyway, since they usually get loaded from /lib/modules-`uname -r`/
[03:23:47] <seb_kuzminsky> it does more than just traditional "hotplug" stuff
[03:23:57] <SWPadnos> we happen to use module-helper, which "fixes" that for us
[03:23:57] <seb_kuzminsky> it handles all the "coldplug" events at bootup, for example
[03:24:16] <jmkasunich> ok, but still not invoked by application startup
[03:24:28] <seb_kuzminsky> invoked by driver load, same as us
[03:24:29] <jmkasunich> linux drivers are normally associated with devices, not programs
[03:25:15] <jmkasunich> how many "programs" load drivers at startup and unload them when done?
[03:25:37] <jmkasunich> back in a minute'
[03:25:39] <seb_kuzminsky> prolly just emc2 :-)
[03:25:49] <SWPadnos> heh
[03:25:59] <SWPadnos> maybe some wireless manager thingie
[03:27:12] <jmkasunich> back
[03:27:38] <jmkasunich> thats what I was afraid of
[03:27:52] <jmkasunich> and the reason we're having problems bending udev/hotplug to meet our needs
[03:28:06] <seb_kuzminsky> but its not driver loading that's problematic, we do that just fine with insmod (via loadrt)
[03:28:36] <SWPadnos> it's firmware loading, silly :)
[03:28:46] <jmkasunich> yeah, but I wouldn't be surprised to see driver loading break someday too
[03:28:48] <seb_kuzminsky> what's problematic is the uevents (potentially) triggered by one of our drivers, that wants to use the normal firmware udev system
[03:28:57] <jmkasunich> I remember when insmod actually loaded the module
[03:29:07] <jmkasunich> now its a thin wrapper around something else
[03:29:17] <jmkasunich> and the mainstream uses modprobe, not insmod
[03:29:33] <seb_kuzminsky> sure, but insmod is nice because it lets you use absolute paths :-)
[03:29:37] <jmkasunich> heh
[03:30:03] <seb_kuzminsky> so i think RIP and firmware_helper are really not well suited for each other
[03:30:11] <seb_kuzminsky> it's sad, because each one in isolation is really cool
[03:30:32] <jmkasunich> yeah - we could probably come up with some hack that would work, for a while, but as you say, it would smell
[03:31:39] <jmkasunich> for hostmot1, our model was "load driver, driver loads firmware". the new model (mark 1) was going to be "load firmward (bfload), then load driver"
[03:32:02] <seb_kuzminsky> how did you get the firmware into the old hostmot1 driver?
[03:32:15] <SWPadnos> it was a binary array in a header file
[03:32:19] <seb_kuzminsky> yeah....
[03:32:20] <jmkasunich> bitfile -> some utility -> foo.h
[03:32:22] <SWPadnos> (well, written in hex)
[03:32:37] <seb_kuzminsky> that seems to be all the rage in our tree these days
[03:32:43] <seb_kuzminsky> pluto does it too
[03:32:49] <seb_kuzminsky> m7i43_hm2 does it too
[03:32:51] <seb_kuzminsky> ugh
[03:32:57] <jmkasunich> very messy when peter comes out with a new fw version, or when somebody wants to do their own fw
[03:32:59] <SWPadnos> yep - it's the easiest way to insure that the driver and the firmware match
[03:33:14] <jmkasunich> and we're all about easy (at least I am)
[03:33:32] <seb_kuzminsky> for a while i was thinking about a firmware registry loaded independently of any firmwares or device drivers
[03:33:39] <seb_kuzminsky> load the fw registry first
[03:33:57] <seb_kuzminsky> then load individual modules each containing a firmware image, they put their fw in the registry
[03:34:07] <seb_kuzminsky> then load the device drivers, and tell them which firmware to pull out of the registry
[03:34:13] <seb_kuzminsky> abandonded as being too heavy
[03:35:02] <jmkasunich> I think we all agree that embedding the fw in the driver is bad
[03:35:29] <jmkasunich> that leaves loading the fw before loading the driver, or allowing the driver to request the fw (thru a mechanism that may or may not be request_firmware)
[03:36:08] <seb_kuzminsky> the firwmare registry idea is like request_firmware in that the firmware is not compiled into the driver, and the driver gets to choose at load-time what firmware to use
[03:36:42] <jmkasunich> that is an implementation of the "driver requests fw" approach
[03:36:44] <seb_kuzminsky> it's like putting /lib/firmware in the kernel!
[03:36:52] <jmkasunich> yeah
[03:37:26] <jmkasunich> whats worse than embedding the fw in the driver? putting ALL the fw versions in kernel space
[03:37:30] <jmkasunich> ;-)
[03:37:40] <jmkasunich> what about the model emc2 uses for kins?
[03:37:56] <seb_kuzminsky> well... except with this you dont have to recompile the drive to change firmware
[03:38:02] <seb_kuzminsky> how's kins done?
[03:38:23] <jmkasunich> insmod the-firmware.ko (which contains a big array and exports one symbol), then insmod the-driver.ko, which uses that symbol
[03:38:57] <jmkasunich> (kins is done by "insmod the-kins.ko, then emc-motion-controller.ko"
[03:39:25] <seb_kuzminsky> i see... if there was only ever one board, that would work for firmwares too
[03:39:40] <jmkasunich> oops, forgot about the multi-board problem
[03:39:41] <seb_kuzminsky> with multiple boards, you want a registry so you can put different firmwares on different boards
[03:40:03] <seb_kuzminsky> you only have to *load* the firmwares you're actually going to use, of course
[03:40:35] <jmkasunich> this is getting complicated tho
[03:40:53] <jmkasunich> load a module that implements the registry, then load one or more fw modules, then load the driver?
[03:42:23] <jmkasunich> I want to back up a bit
[03:42:55] <jmkasunich> I was talking about two basic approaches: 1) load fw (bfload or similar), then load driver, vs. 2) load driver, and it request fw (udev, registry, whatever)
[03:43:32] <jmkasunich> I used to like the simplicty of 1, but it does have a problem in that the driver doesn't know what fw is loaded, and may or may not match the fw
[03:43:57] <jmkasunich> that limitation led to the stuff I was doing with ram blocks in the fpga to pass info to the driver, etc
[03:44:14] <jmkasunich> which basically got too complicated and I never finished it
[03:44:41] <jmkasunich> are there any arguements in favor of approach 1, load fw before loading driver?
[03:45:59] <jmkasunich> hmm, talking to myself again....
[03:46:24] <jmkasunich> lol
[03:46:37] <seb_on_neighbors> grumble
[03:46:44] <seb_on_neighbors> sorry
[03:46:55] <seb_on_neighbors> last i saw was me saying "you only have to *load*..."
[03:47:23] <jmkasunich> I had a bit of a monolog after - I'll paste
[03:47:35] <jmkasunich> this is getting complicated tho
[03:47:42] <jmkasunich> load a module that implements the registry, then load one or more fw modules, then load the driver?
[03:47:50] <jmkasunich> I want to back up a bit
[03:47:59] <jmkasunich> I was talking about two basic approaches: 1) load fw (bfload or similar), then load driver, vs. 2) load driver, and it request fw (udev, registry, whatever)
[03:48:06] <jmkasunich> I used to like the simplicty of 1, but it does have a problem in that the driver doesn't know what fw is loaded, and may or may not match the fw
[03:48:12] <jmkasunich> that limitation led to the stuff I was doing with ram blocks in the fpga to pass info to the driver, etc
[03:48:19] <jmkasunich> which basically got too complicated and I never finished it
[03:48:29] <jmkasunich> are there any arguements in favor of approach 1, load fw before loading driver?
[03:48:39] <jmkasunich> done pasting
[03:49:31] <jmkasunich> still there?
[03:49:34] <seb_on_neighbors> ok, i'm caught up
[03:49:40] <SWPadnos> it seems easy enough, and we have the tools to do that already :)
[03:50:05] <jmkasunich> except we don't, for those people who's bios doesn't set up the card right
[03:50:09] <jmkasunich> whose
[03:50:09] <SWPadnos> it allows complete flexibility in loading any firmware into any or all cards in a system
[03:50:22] <SWPadnos> ok, but that's a pretty simple thing to fix isn't it?
[03:50:32] <jmkasunich> well, thats how all this started
[03:50:42] <SWPadnos> wasn't the maintainer of one of those libraries happy to get the config access added?
[03:50:46] <seb_on_neighbors> maybe i'm making mountains of the mole hills
[03:50:47] <SWPadnos> (was that the one that isn't on Dpper?)
[03:50:50] <SWPadnos> Dapper
[03:51:00] <seb_on_neighbors> dapper has libpci but not libpciaccess
[03:51:06] <seb_on_neighbors> libpci does config acces but not bar
[03:51:15] <jmkasunich> libpci is the one that would accept a bar access patch
[03:51:27] <jmkasunich> but that only helps people who get the patched libpci
[03:51:36] <seb_on_neighbors> jmkasunich: right
[03:51:55] <jmkasunich> so we'd still have to distribute our own version of libpci until the new one propogates
[03:51:59] <seb_on_neighbors> so no matter what, if we want to support older distros (and you've convinced me we do), we have to carry a pci access library with us
[03:52:12] <seb_on_neighbors> ... or do it in the kernel
[03:52:22] <jmkasunich> libpciaccess already has the capabilities we need, but we'd have to distribute it for Dapper users
[03:52:46] <seb_on_neighbors> libpciaccess, i just noticed today, doesnt allow access to io bars! @!!#!
[03:52:56] <seb_on_neighbors> they said they'd accept a patch to add it though!
[03:53:14] <seb_on_neighbors> fucked no matter what we do
[03:53:15] <seb_on_neighbors> it sucks
[03:53:31] <jmkasunich> so, basically, if we want to do the "load fw, then load driver", we can, but we have to distribute the pci libs
[03:53:53] <seb_on_neighbors> i'm about ready to throw up my hands and just use upci for bar access and libpci for config access and never mind the cruft
[03:53:58] <jmkasunich> if we want to do the "load driver, let it request fw", then we can use the kernel methods, but we break RIP (or need to do krufty things)
[03:54:18] <seb_on_neighbors> jmkasunich: yes
[03:54:23] <jmkasunich> heh - and you almost have me convinced that it is better to have the driver request the fw
[03:54:26] <seb_on_neighbors> kruft on the left of me, kruft on the right
[03:54:40] <seb_on_neighbors> * seb_on_neighbors explodes
[03:54:51] <jmkasunich> mostly because of the issue of the driver and fw needing to match, and the "load fw first" method leaves that unresolved
[03:55:04] <seb_on_neighbors> i'm not sure how much of an issue that is
[03:55:17] <seb_on_neighbors> no matter what the mechanism, it's the user that chooses the firmware to load
[03:55:31] <seb_on_neighbors> they mess up, the driver balks at the board, the load fails
[03:55:50] <jmkasunich> true - but the mechanism for "driver balks" is undefined
[03:55:50] <seb_on_neighbors> (that's assuming reasonably self-describing firmwares, like hostmot2)
[03:55:54] <seb_on_neighbors> right
[03:56:01] <jmkasunich> to you put a tag in the FPGA somewhere?
[03:56:21] <jmkasunich> I'm unfamiliar with the guts of hostmot2, there is a descripter of some sort?
[03:56:31] <seb_on_neighbors> hm2 has a large, expressive header describing what modules are available and where in the io space they are
[03:56:57] <seb_on_neighbors> something like "4 pwmgenerators (version 3) at 0x1000"
[03:57:09] <jmkasunich> where is that header? it actually appears in the fpga after being loaded, and can be read by the driver?
[03:57:43] <seb_on_neighbors> it's at a well-defined register address on the fpga, the driver reads it at load time to know what the fpga has to offer
[03:57:50] <jmkasunich> ok, cool
[03:58:06] <seb_on_neighbors> yeah, it's one of the things about hostmot2 that makes me wet
[03:58:20] <jmkasunich> so even someone (like me) who wants to do custom fpga work, can use the same register
[03:59:10] <seb_on_neighbors> if you want to make a hm2 firmware image with 5 pwmgens and 11 stepgens, you can effectively change #define NUM_STEPGENS and NUM_PWMGENS in the vhdl and recompile, and the driver will work
[03:59:19] <jmkasunich> nice
[03:59:42] <seb_on_neighbors> if you want to change how the stepgen behaves, or add some kind of new behavior, you need to write the vhdl and the driver module for it
[04:00:03] <seb_on_neighbors> the current driver will just skip over it, but still work with all the modules it knows how to drive
[04:00:09] <jmkasunich> it sounds like hostmot 2 is an actual working implementation of what I tried and failed to do
[04:00:38] <seb_on_neighbors> i'm not totally sure about what you were working on, but hm2 seems just about fully flexible to me
[04:00:47] <jmkasunich> and the more you tell me about it, the more I think I'll be doing my future fpga work in that framework
[04:01:00] <seb_on_neighbors> it's self-describing, and the language for self-description is nicely extensible
[04:01:27] <seb_on_neighbors> i have no idea how the vhdl is (i know nothing about fpga programming)
[04:01:47] <jmkasunich> peter wallace and I talked a lot about what I was trying to do, and he helped me with some of the vhdl stuff (like how to have a block of ram in an fpga)
[04:01:59] <seb_on_neighbors> peter's a good guy
[04:02:26] <jmkasunich> yep
[04:02:40] <seb_on_neighbors> i dont want hostmot2 to suck because my driver sucks
[04:02:45] <seb_on_neighbors> i want my driver to be good
[04:02:47] <jmkasunich> I dunno if our conversations had anything to do with hostmot2 or not
[04:02:48] <seb_on_neighbors> including firmware loading
[04:02:54] <jmkasunich> agreed
[04:03:00] <seb_on_neighbors> i meant "emc2's support for hostmot2"
[04:03:22] <jmkasunich> (even more so, now that I think I'll be using hostmot2+extensions myself)
[04:03:27] <seb_on_neighbors> hehe
[04:03:42] <jmkasunich> so - load fw, then driver, or load driver and let it request fw
[04:03:56] <jmkasunich> the former means one less piece of into to pass to the driver
[04:04:12] <jmkasunich> ideally you load the fw you want, and the driver "just works" - exports the HAL pins for whatever the fw provices
[04:04:15] <jmkasunich> provides
[04:04:15] <seb_on_neighbors> i think of the dichotomy as "load it frmo userspace" vs "load it from the kernel driver", but i think we're saying the same thing
[04:04:43] <jmkasunich> they are effectively the same, although user/kernel is an implemnetation distinction
[04:04:50] <seb_on_neighbors> yes
[04:05:07] <jmkasunich> for example, I could do insmod the-fw.ko, then insmod the-driver.ko
[04:05:22] <jmkasunich> where "the-fw" contains the fw as a big array, and the loader code
[04:05:36] <seb_on_neighbors> except its "insmod the-driver.ko firmware=the-fw"
[04:05:50] <jmkasunich> the interesting thing about that idea is that you can rmmod the-fw.ko after it loads the board
[04:06:18] <seb_on_neighbors> yeah, it's very similar to request_firmware() in that respect
[04:06:32] <jmkasunich> no, I'm specifically talking about the "load fw _first_ , then load driver" approach
[04:06:58] <jmkasunich> the-fw.ko would be functionally equivalent to bfload
[04:07:15] <seb_on_neighbors> all the options we're discussing have the feature that the firmware image does not stay resident in the kernel after the FPGA has been programmed
[04:07:40] <seb_on_neighbors> the-driver knows how to talk to the board, the-fw is just an array representation of a bitfile, right?
[04:08:34] <jmkasunich> more like: insmod fw1.ko board=5i20:0; rmmdo fw1 ; insmod fw2.ko board=5i22:0 ; rmmod fw2 ; insmod fw1.ko board=5i20:2 ; rmmod fw1 ; insmod driver.ko
[04:08:56] <jmkasunich> no, the-fw.ko contains both the bitfile and the loader code
[04:09:06] <seb_on_neighbors> i dont like that
[04:09:24] <seb_on_neighbors> the loader code would duplicate much code from the low-level driver
[04:09:44] <jmkasunich> why does the driver have loader code in it?
[04:10:05] <jmkasunich> or am I missing issues related to the parport connected versions?
[04:10:23] <seb_on_neighbors> loading the firmware and talking to the firmware are quite similar, for both pci and epp
[04:10:33] <seb_on_neighbors> in both cases you need to find the device and talk to it
[04:10:49] <seb_on_neighbors> waht you say and how you say it are different, but the overlap is quite large i think
[04:10:56] <jmkasunich> hmm
[04:18:09] <jmkasunich> shit
[04:18:09] <SWPadnos> uh-oh
[04:18:10] <SWPadnos> hmmm - the logger too
[04:18:10] <seb_kuzminsky> criminy
[04:18:11] <seb_kuzminsky> my whole laptop crashed, first time that's happened
[04:18:16] <jmkasunich> tom1: I guess the images aren't on linuxcnc.org, but it is here:
http://jmkasunich.com/pics/gcode-ref-back.pdf
[04:30:16] <seb_kuzminsky> i dont understand
[04:30:16] <SWPadnos> ie, does show comp show more than one hostmot2 driver?
[04:30:16] <SWPadnos> I hooe it doesn't
[04:30:16] <SWPadnos> hope
[04:30:16] <seb_kuzminsky> one hostmot2 driver, and one driver for each kind of board (7i43, 5i20, etc)
[04:30:16] <seb_kuzminsky> i may squish the pci boards all into one driver, not sure yet
[04:30:16] <jmkasunich> are your low level and generic hm2 drivers two different kernel modules?
[04:30:16] <seb_kuzminsky> yes
[04:30:16] <seb_kuzminsky> hold on...
[04:30:16] <SWPadnos> hmmm
[04:30:51] <jmkasunich> ok, that has potential
[04:30:55] <seb_kuzminsky> http://pastebin.ca/1061047
[04:31:03] <seb_kuzminsky> this is the hal file i use for my testing
[04:31:10] <SWPadnos> could you make a hostmot2 sample config?
[04:31:10] <jmkasunich> insmod lowlevel, then insmod (and rmmod) one or more fw modules, the insmod the generic driver
[04:31:25] <seb_kuzminsky> it gets the board type (5i20 or 7i43) from the environment, and the firmware file to bfload too
[04:31:44] <seb_kuzminsky> i should commit it to emc2, i know... sry
[04:32:11] <seb_kuzminsky> for now you need to load the high-level firmware driver (hostmot2) first
[04:32:17] <seb_kuzminsky> it exports a hm2_register() function
[04:32:23] <seb_kuzminsky> but doesnt touch hal
[04:32:33] <seb_kuzminsky> then you send the firmware you want to the boards you want with bfload
[04:32:42] <seb_kuzminsky> then you load the low-level drivers that know how to talk to the boards
[04:32:54] <seb_kuzminsky> they find their boards (but dont talk to the firmware), and pass the boards to hm2_register()
[04:33:21] <seb_kuzminsky> hm2_register() uses the low-level drivers to peek & poke the firmware, validate it, find out what it can do
[04:33:26] <jmkasunich> if you have one pci board (5i20, etc) and one parport board (7i43) what loads the fw into the parport one?
[04:33:37] <seb_kuzminsky> hm2_register() creates hal objects on behalf of the low-level driver's board
[04:33:51] <seb_kuzminsky> hm2_register returns to the low-level driver, which registers the next board
[04:34:13] <seb_kuzminsky> when the boards are all registerd, the low-level driver calls hal_ready()
[04:34:35] <seb_kuzminsky> jmkasunich: bfload loads into both 5i20 and 7i43, as shown in the hal file i pastebinned
[04:34:53] <seb_kuzminsky> line 25
[04:35:03] <jmkasunich> I only see one invocation of bfload
[04:35:06] <SWPadnos> that's only showing how to use one at a time
[04:35:14] <seb_kuzminsky> the hal file only does one hm2 board
[04:35:21] <seb_kuzminsky> hold on for the 2-board version...
[04:35:32] <jmkasunich> but your version of bfload can access either pci or parport boards.... that was what I was wondering
[04:35:32] <SWPadnos> sample configs ...
[04:36:03] <jmkasunich> I'm rereading what you just posted
[04:36:04] <seb_kuzminsky> http://pastebin.ca/1061049
[04:36:17] <jmkasunich> the usage of "high level" and "low level" is confusing me
[04:36:45] <seb_kuzminsky> jmkasunich: yes, bfload in trunk (and i think in 2.2 too) handles 5i20 and 7i43 (and maybe 5i22, tho i havent tested that)
[04:36:51] <jmkasunich> ok
[04:36:55] <seb_kuzminsky> low-level == talks to the board
[04:37:09] <seb_kuzminsky> high-level == talks to the firmware on the board, via a low-level driver that talks to the board
[04:37:19] <jmkasunich> heh, that is what confuses me
[04:37:39] <jmkasunich> once the FW is loaded, I consider "the board" and "the firmware" to be one and the same
[04:38:06] <seb_kuzminsky> think of the firmware as an application, and the board communication peculiarities as a network stack
[04:38:37] <jmkasunich> low-level provides channel independent read and write functions, and high-level invokes them to read various registers, etc, depending on the functional blocks, like encoder, pwm, step, etc?
[04:38:38] <seb_kuzminsky> talking to hostmot2 about its header and pwmgens etc is the same whether it's over epp or pci or some other transport
[04:38:45] <seb_kuzminsky> jmkasunich: exactly
[04:39:04] <seb_kuzminsky> low-level abstracts the channel into read and write
[04:39:17] <seb_kuzminsky> high-level uses read and write to talk to the firmware, no matter what the channel is
[04:39:29] <jmkasunich> how do you deal with the fact that PCI is 32 bit and epp is 8?
[04:39:47] <seb_kuzminsky> the firmware is 32-bit, i use epp in 32-bit ("wide") mode
[04:39:52] <jmkasunich> ok
[04:40:03] <seb_kuzminsky> well, it's got 32-bit registers and 16-bit addresses
[04:40:07] <jmkasunich> now, is hostmot2 the low level or the high level
[04:40:12] <seb_kuzminsky> high
[04:40:16] <seb_kuzminsky> 7i43 and 5i20 are low
[04:40:21] <jmkasunich> ok, thats the part that hurts my head
[04:40:27] <seb_kuzminsky> how do you see it?
[04:40:33] <jmkasunich> how can the high level driver do anything without the low level driver?
[04:40:39] <seb_kuzminsky> it cant
[04:40:45] <jmkasunich> but you load it first
[04:40:51] <seb_kuzminsky> yes, but it doesnt do anything
[04:41:00] <seb_kuzminsky> all it does is make available a function called hm2_register()
[04:41:01] <SWPadnos> ah
[04:41:12] <seb_kuzminsky> then you load low-level drivers, they find their boards and register them
[04:41:43] <jmkasunich> how many low level drivers are there?
[04:41:51] <SWPadnos> one for each board type
[04:41:52] <jmkasunich> one for PCI and one for EPP?
[04:41:58] <SWPadnos> I would think
[04:41:59] <seb_kuzminsky> check this out:
[04:42:04] <seb_kuzminsky> http://bazaar.launchpad.net/~seb-highlab/emc/hostmot2/annotate/449?file_id=hostmot2lowlevel.h-20080422035433-pcw4ryff4kcw7v5m-1
[04:42:12] <jmkasunich> or one for 5i20, one for 5i22, one for 7i43, etc?
[04:42:25] <seb_kuzminsky> that's the header that describes the low-level abstraction
[04:42:52] <jmkasunich> it seems kind of backwards to me
[04:43:01] <seb_kuzminsky> currently there's a low-level for 7i43 and one for 5i20, that's all i've written so far
[04:43:22] <SWPadnos> I thought you had a 5i22 (-1.0) version at some point?
[04:43:26] <jmkasunich> I think in terms of loading the low level support first, to provide a channel, then the high level driver can do what it needs to do without callbacks, etc
[04:43:55] <seb_kuzminsky> as i add support for the other pci boards, i may put them in their own low-level drivers or merge them with the 5i20 driver into an "anyio_pci" driver that handles them all
[04:43:56] <seb_kuzminsky> we'll see
[04:44:03] <SWPadnos> this scheme makes it so the high level doesn't need to know about new types of board, for example
[04:44:14] <seb_kuzminsky> i *have* a 5i22-1.0 board, but i havent plugged it in and written the driver for it yet
[04:44:22] <seb_kuzminsky> got caught up in pci access libs :-(
[04:44:28] <jmkasunich> highlevel needs to know about things like :"encoder", "stepgen", etc, right?
[04:44:51] <SWPadnos> the only reason the high level driver has to be loaded first is so the low level code can call the register function (which should be in the high level driver, since that's what talks to HAL)
[04:44:59] <seb_kuzminsky> jmkasunich: exactly, it knows how to think about the firmware
[04:45:17] <seb_kuzminsky> the low-level drivers dont know anything about hostmot2
[04:45:23] <seb_kuzminsky> except they know to call hm2_register()
[04:45:45] <seb_kuzminsky> a better abstraction layer might support multiple firmwares, not just hm2, with the same ll drivers
[04:45:51] <seb_kuzminsky> babysteps :-)
[04:46:00] <jmkasunich> what happens if you have more than one of the same board? it looks like you are loading the low level driver once per board, linux doesn't allow a module to be loaded twice
[04:46:26] <seb_kuzminsky> the ll drivers *should* be written to find all the boards they can drive, and register them one by one
[04:46:38] <seb_kuzminsky> i dont have duplicates of any boards, so i cant test it
[04:46:44] <seb_kuzminsky> but i think the 5i20 driver works that way
[04:47:15] <seb_kuzminsky> here's the 5i20 driver:
[04:47:18] <seb_kuzminsky> http://bazaar.launchpad.net/~seb-highlab/emc/hostmot2/annotate/449?file_id=hm2_5i20.c-20080327152746-a3ixr7afabkauzjl-1
[04:48:03] <seb_kuzminsky> it's got an array of hm2_5i20_board_t, populated by the kernel-internal hotplug system as it discovers/scans for matching PCI devices
[04:48:34] <seb_kuzminsky> each board found gets registered in hm2_5i20_probe(), on line 131
[04:48:55] <SWPadnos> the 5i20 driver does do that, but it also can't load different configs into different boards
[04:49:08] <SWPadnos> (it doesn't support different configs, so that's not a problem)
[04:49:36] <seb_kuzminsky> rtapi_app_main, on line 181, registers all the boards (line 189) then calls hm2_ready()
[04:49:44] <seb_kuzminsky> i mean hal_ready()
[04:50:31] <jmkasunich> so from a hal perspective, there is a driver for each class of boards, but not for each board
[04:50:38] <jmkasunich> lol
[04:50:46] <seb_kuzminsky> crap!
[04:50:51] <jmkasunich> ^w again?
[04:50:53] <seb_kuzminsky> i gotta turn off ^W
[04:51:00] <jmkasunich> so from a hal perspective, there is a driver for each class of boards, but not for each board
[04:51:09] <seb_kuzminsky> yes
[04:51:23] <jmkasunich> the drivers are the low level ones, and they own the hal pins
[04:51:39] <jmkasunich> why not have the high level driver own the pins
[04:51:41] <seb_kuzminsky> yes, each ll driver has its own comp id, which gets passed to the high-level hostmot2 driver
[04:51:53] <seb_kuzminsky> this way you can unload the 7i43 and the 5i20's keep working
[04:51:59] <jmkasunich> oh, never mind, it wouldn't know when to call hal_ready
[04:52:05] <seb_kuzminsky> also, this way you can call hal_ready()... right
[04:52:39] <seb_kuzminsky> i wish that hal object creation (and destruction) was more dynamic
[04:52:44] <jmkasunich> so do I
[04:52:48] <seb_kuzminsky> but that's a conversation for another night i think :-)
[04:52:58] <jmkasunich> we've talked about that for a couple of years
[04:53:02] <seb_kuzminsky> heh
[04:54:14] <jmkasunich> right now none of your driver modules know anything about programming fpgas, right? bfload does that
[04:54:33] <seb_kuzminsky> yep
[04:54:47] <seb_kuzminsky> and i think that's how its going to stay for now
[04:54:48] <SWPadnos> done! :)
[04:54:52] <jmkasunich> and bfload has to duplicate the channel independent read/write stuff (or at least, it has to have code to programm each device thru the relevant channel)
[04:54:59] <seb_kuzminsky> yep
[04:55:12] <seb_kuzminsky> and the channel accesses are pretty gross from userspace
[04:55:16] <seb_kuzminsky> i mean...
[04:55:23] <seb_kuzminsky> 3 pci access libraries
[04:55:27] <seb_kuzminsky> and none of them work
[04:55:31] <seb_kuzminsky> * seb_kuzminsky boggles
[04:55:39] <jmkasunich> what if "anyio.ko" contained the channel stuff, _and_ the board programming stuff
[04:55:45] <jmkasunich> insmod anyio.ko first
[04:56:03] <SWPadnos> um, there is the kernel device driver for the anyio boards, from that guhy at UTwente in the Netherlands
[04:56:23] <jmkasunich> so we name it something else
[04:56:23] <seb_kuzminsky> utwente's code has some problems
[04:56:24] <SWPadnos> which provides a file node which firmware can be cat'ed into
[04:56:30] <seb_kuzminsky> hehe
[04:56:42] <SWPadnos> it's for the mesa boards
[04:57:15] <jmkasunich> what does that have to do with any of the schemes we've been discussing?
[04:57:17] <SWPadnos> they also did some stuff we probably don't want, like having userspace access to I/O (though that isn't necessarily a bad thing)
[04:57:41] <seb_kuzminsky> it's a way to get firmware to the driver so it can program the fpga
[04:57:56] <jmkasunich> thru a file node?
[04:57:58] <SWPadnos> well, it's an already implemented version of an "anythingio.ko" module, which hides the specifics of communicating with different hardware
[04:58:01] <seb_kuzminsky> some kernel guys i talked to suggested something very similar (but using /sys instead of /dev)
[04:58:02] <SWPadnos> yes
[04:58:17] <SWPadnos> cat firmware > /proc/anythingio/board0/firmware
[04:58:20] <SWPadnos> or similar
[04:58:30] <seb_kuzminsky> but then some other kernel guys beat them up and said to just use request_firmware()
[04:58:56] <SWPadnos> except we know that request_firmware has issues for our RIP use case
[04:59:06] <jmkasunich> well, I think we have established that because of our RIP requirement, our needs aren't the same as the kernel guys
[04:59:14] <seb_kuzminsky> yes
[04:59:59] <jmkasunich> thats why I keep going back to wanting to estabilsh the _order_ of the various steps, before diving into the mechanism of the steps
[05:00:45] <seb_kuzminsky> the ll drivers can (but dont currently) help program the boards, if they can get their hands on a firmware image
[05:00:46] <jmkasunich> for example, in the "cat to proc/anythingio/board/fw" case, when would the HAL pins be exported?
[05:01:12] <seb_kuzminsky> after the firmware is programmed, and after the board is registered with the high-level driver that knows what pins the firmware has
[05:01:47] <SWPadnos> ok - step 1 is enumeration of boards - something needs to map what the user requests to the hardware that's present
[05:02:00] <SWPadnos> step 2 is loading firmware
[05:02:14] <jmkasunich> step 3 is hal pins
[05:02:16] <SWPadnos> step 3 is making the HAL interface for the loaded firmware
[05:02:24] <SWPadnos> and that should be all
[05:02:27] <jmkasunich> right
[05:02:28] <seb_kuzminsky> it's like there's two of you here
[05:02:33] <SWPadnos> echo
[05:02:41] <jmkasunich> suppose that the ll driver gets loaded first
[05:03:07] <jmkasunich> it uses either its insmod params (for parport boards) or pci scanning (for pci boards) to do the board enumeration
[05:03:25] <seb_kuzminsky> step 3 is: hand the channel-abstracted board to a high-level firmware driver that can peek & poke & figure out what hal objects are needed
[05:03:39] <jmkasunich> right
[05:04:02] <jmkasunich> step 1: load ll driver, it searches for boards, and makes a proc (or sys, or whatever) entry for each board
[05:04:26] <jmkasunich> step 2: cat the fw to the proc entries - that causes code in the ll driver to execute, which programs the FPGA
[05:04:56] <jmkasunich> step 3: load the high level driver, which asks the ll driver what boards are present, and exports the HAL stuff for them
[05:05:08] <seb_kuzminsky> 3 is a bit problematic
[05:05:14] <jmkasunich> (using the read and write calls provided by the ll driver
[05:05:17] <jmkasunich> what part of it?
[05:05:35] <seb_kuzminsky> how would the high-level driver find all the low-level drivers?
[05:05:43] <SWPadnos> with the exception of the 7i43, I think that the UTwente driver does all that (unless it's buggy)
[05:05:47] <jmkasunich> there is nly one ll driver
[05:05:51] <SWPadnos> there's only one low - right
[05:06:03] <seb_kuzminsky> that does both pci and epp?
[05:06:07] <jmkasunich> yep
[05:06:10] <seb_kuzminsky> my brain just went sproing
[05:06:22] <SWPadnos> which exports a function (or data member) that the high level driver queries
[05:06:29] <seb_kuzminsky> sure
[05:06:29] <jmkasunich> I thought the goal of a ll driver was to provide a unified interface to the boards
[05:06:35] <seb_kuzminsky> it is
[05:06:56] <SWPadnos> the low level stuff can be separated into two levels if it makes more sense that way
[05:06:59] <jmkasunich> so , it exports read(board_num, address) and write(board_num, address, data)
[05:07:34] <jmkasunich> internally the read and write functions invoke different code based on the type of board
[05:07:37] <SWPadnos> level 1 is the group of drivers that actually talk to hardware. level 2 is what they all register with, so the higher level driver has only one known place to look for info
[05:08:03] <SWPadnos> and block_read / block_write
[05:08:30] <seb_kuzminsky> that would work, but it feels strange to put all the lls in one driver
[05:09:00] <SWPadnos> you can separate them - load one "manager" which has functions that the low level and the high level both call
[05:09:00] <seb_kuzminsky> it would work either way
[05:09:05] <jmkasunich> heh - to me it seem strange to separate them
[05:09:21] <SWPadnos> it makes sense to separate them when they communicate over completely separate buses
[05:09:31] <seb_kuzminsky> keep the lls separate, and after fpga programming, register with the high-level driver just like now
[05:09:36] <seb_kuzminsky> SWPadnos: i agree
[05:09:37] <SWPadnos> no
[05:10:11] <SWPadnos> the low level drivers only export a function (with a well-known name) or call a function (also well-known) in a middle-layer module
[05:10:36] <SWPadnos> the high level drivers ask the middle level (or the low level, if it's a single module) what's there, and export accordingly
[05:10:37] <jmkasunich> if there is more than one ll driver, they can't export functions with well known names
[05:10:42] <jmkasunich> the names will collide
[05:10:47] <SWPadnos> low level provides an interface, high level uses it however it wants
[05:10:59] <SWPadnos> that's why you'd have a middle layer driver
[05:11:07] <seb_kuzminsky> adding an abstraction layer in the middle is certainly the most flexible solution
[05:11:14] <seb_kuzminsky> but it's a bunch of extra code to write
[05:11:24] <seb_kuzminsky> the ll's would register boards with the middleware
[05:11:30] <seb_kuzminsky> the hl's would allocate boards
[05:11:43] <SWPadnos> it should be a little more than a single driver, and less than several low level drivers
[05:11:58] <seb_kuzminsky> there'd be a tool or a little language or something to tell the hl's what boards to use
[05:12:23] <seb_kuzminsky> SWPadnos: one for the 7i43 and one or two or so for the pci boards (there are two different pci chipsets in use)
[05:12:35] <SWPadnos> actually, the low level drivers could just create proc entries. the high level driver can look at those
[05:12:41] <jmkasunich> I think the decision between multiple ll drivers with a middleware layer vs one unified ll driver is an implementation detail maybe
[05:12:47] <SWPadnos> yep
[05:13:07] <seb_kuzminsky> i've been trying to avoid having to write that middle layer by decreeing that there is only one hl driver and it's hm2
[05:13:19] <seb_kuzminsky> makes it easy to find, totally bysteps this issue
[05:13:26] <seb_kuzminsky> babysteps :-)
[05:13:34] <SWPadnos> the number of access methods is determined by how many variants Mesa makes, not by which module the code is put into
[05:14:16] <seb_kuzminsky> where were we, oh yeah the three-step plan
[05:14:19] <jmkasunich> seb_kuzminsky: you just said something about making the high level driver easier to find
[05:14:44] <jmkasunich> in the proposal I thought we were discussing, nobody ever has to find the high level driver - it is loaded last
[05:15:21] <seb_kuzminsky> oh yeah, and i was complaining about that because it's opposite of what i've been thinking about and it shoehorns all the ll drivers into one module (namespace)
[05:15:28] <SWPadnos> heh
[05:15:49] <seb_kuzminsky> but it would work either way
[05:15:55] <seb_kuzminsky> step 0: load hl driver
[05:16:10] <seb_kuzminsky> step 1: load ll drivers (one for each channel more or less)
[05:16:29] <seb_kuzminsky> step 2: lls find all their boards and make files in /sys or /proc or something to accept firmware
[05:16:34] <SWPadnos> it would work that way, if it weren't for the neddling HAL
[05:16:39] <SWPadnos> meddling
[05:16:46] <jmkasunich> let him finish
[05:16:47] <seb_kuzminsky> step 3: firmware arrives from userspace, boards get programmed
[05:17:08] <seb_kuzminsky> step 4: ll driver registers board with hl driver, which creates HAL objects for ll
[05:17:23] <jmkasunich> finished?
[05:17:23] <seb_kuzminsky> step 5: when all the ll's boards are registers, ll calls hal_ready()
[05:17:25] <seb_kuzminsky> done
[05:17:36] <seb_kuzminsky> just like now, except adding 3
[05:17:40] <SWPadnos> I see several level inversions there :)
[05:18:06] <seb_kuzminsky> you mean low calling into high?
[05:18:10] <seb_kuzminsky> <shrug>
[05:18:13] <SWPadnos> sort of, yes
[05:18:19] <jmkasunich> having the LL driver "register" a board with the HL driver seems odd
[05:18:34] <SWPadnos> 1, high level driver load should be the last thing to happen - if you need the high level code loaded before the low level code, there's a problem
[05:18:45] <jmkasunich> it is the HL driver's job to connect to hal and export pins
[05:18:56] <jmkasunich> the register thing seems like another way to say you are doing a callback
[05:19:07] <SWPadnos> yes, which is fundamentally separate from finding or programming the boards
[05:19:09] <jmkasunich> and the only reason you need a callback is because you are loading the HL driver first
[05:19:21] <jmkasunich> step 1: load ll driver(s)
[05:19:31] <jmkasunich> step 2: ll driver(s) find board(s) and make proc entries
[05:19:42] <jmkasunich> step 3: cat the fw to the proc entries
[05:19:53] <jmkasunich> step 4: load HL driver, which exports all the hal pins
[05:20:24] <SWPadnos> (step 3.999: HL driver looks at /proc entries to see what boards are present and useful)
[05:20:50] <jmkasunich> the HL driver needs to be able to call "read(board_id, address)" and "write(board_id, address, data)"
[05:21:03] <seb_kuzminsky> the way i've been doing it lets me put the ll drivers in different modules easily, that gets harder with the new scheme
[05:21:13] <seb_kuzminsky> read and write are in one particular ll driver
[05:21:19] <jmkasunich> dispatching read and write calls to the LL driver(s) is just switch(board_id) or similar
[05:21:21] <SWPadnos> the low level driver shouldn't need to know that HAL exists - if someone wanted to make a 5i20 classicladder processor without HAL, the driver should let them do that
[05:21:35] <SWPadnos> (not that we necessarily care about that, but still, it seems like better design)
[05:21:43] <seb_kuzminsky> SWPadnos: i agree, and that's how it is now too
[05:21:45] <jmkasunich> agreed
[05:21:54] <seb_kuzminsky> except for hal_ready...
[05:22:00] <SWPadnos> no, if the low leveel driver calls hal_ready, then it isn't separate from HAL
[05:22:02] <SWPadnos> right :)
[05:22:06] <jmkasunich> I just don't like the idea that the ll driver calls the hl one
[05:22:27] <SWPadnos> callbacks are pretty straightforward, but I don't think they're really needed here
[05:22:29] <jmkasunich> hl should be loaded last, and call LL to find out what boards exsist, and to access them
[05:22:30] <seb_kuzminsky> so in this scheme, tell me again how the hl driver finds all the ll ones? once that's done, the ll drivers can export an array of boards or something no prob
[05:22:47] <SWPadnos> ls /proc/mesa_cards/
[05:22:50] <jmkasunich> well, my solution to that was to put all the ll drivers in the same module ;-)
[05:23:03] <seb_kuzminsky> SWPadnos: that doesnt work, you need function pointers and such
[05:23:06] <jmkasunich> SWPadnos: I don't think drivers can do ls :-)
[05:23:08] <SWPadnos> heh
[05:23:26] <SWPadnos> hmmm
[05:23:37] <jmkasunich> the /proc API may have "does this file aready exist" as a function
[05:23:55] <seb_kuzminsky> i think it's pretty straightforward to walk /proc and /sys, but i dont think that helps
[05:24:29] <jmkasunich> so your goal is to have the 5i20 LL and the 7i43 LL in seperate modules
[05:24:37] <seb_kuzminsky> it seems cleaner
[05:24:43] <SWPadnos> with one ll driver, or with a middleman module, there would be a single function call to retrieve a structure describing available boards
[05:24:50] <seb_kuzminsky> SWPadnos: yes
[05:25:19] <seb_kuzminsky> i guess i prefer the middleman module of those options
[05:25:20] <SWPadnos> the middleman uses a callback scheme, but it would remove all HAL-specific code from the low level drivers
[05:25:35] <jmkasunich> I assume that if you only want to load the 7i43 LL driver if you have a 7i43 board....
[05:25:43] <seb_kuzminsky> but hah! the lls would have to call the middle-level "register a board" function! layer violation!
[05:25:46] <jmkasunich> oops, that is unclear
[05:26:06] <SWPadnos> no, you load the "manager", then the drivers, then the applications ;)
[05:26:13] <seb_kuzminsky> bah :-)
[05:26:26] <seb_kuzminsky> who calls hal_ready and when?
[05:26:31] <SWPadnos> the application
[05:26:32] <jmkasunich> the high level driver
[05:26:36] <SWPadnos> (right)
[05:26:52] <jmkasunich> that is loaded last (in this scheme) regardless of how the low/middle part is done
[05:26:58] <seb_kuzminsky> sure
[05:27:13] <seb_kuzminsky> by the time you load the hl, all the boards are found, programmed, and ready to go
[05:27:19] <jmkasunich> yep
[05:27:38] <SWPadnos> and there's one function to call to find out what cards are present
[05:27:44] <jmkasunich> present and loaded
[05:27:45] <SWPadnos> (same as with a single LL driver)
[05:27:48] <SWPadnos> yes
[05:29:09] <seb_kuzminsky> 1. load anyio_manager
[05:29:23] <seb_kuzminsky> 2. load anyio_{7i43,5i20,etc}
[05:29:46] <seb_kuzminsky> 3. lls find their boards, make files in /proc or /sys to accept firmware
[05:30:00] <seb_kuzminsky> 4. userspace cats the right firmware to the right board
[05:30:14] <seb_kuzminsky> 5. ll receives fw, programs board, registers it with anyio_manager
[05:30:55] <seb_kuzminsky> 6. load hl driver
[05:31:07] <seb_kuzminsky> 7. it connects to anyio_manager and lists all the boards
[05:31:17] <seb_kuzminsky> 8. hl makes HAL objects for each board
[05:31:24] <seb_kuzminsky> 9. hl calls hal_ready
[05:31:31] <seb_kuzminsky> 10. PROFIT!!
[05:31:40] <SWPadnos> right!
[05:31:40] <jmkasunich> yeah
[05:31:43] <seb_kuzminsky> yeah, looks pretty good
[05:32:08] <jmkasunich> personally I'd combine the mananger and ll drivers, but that is just because I'm lazy
[05:32:16] <SWPadnos> wuss
[05:32:54] <SWPadnos> bedtime!
[05:33:05] <seb_kuzminsky> it could be logically separate but linked into the same .ko
[05:33:21] <seb_kuzminsky> makes for a lot of modparams
[05:33:26] <seb_kuzminsky> ah that reminds me
[05:33:49] <jmkasunich> the PCI ll driver doesn't need modparams, does it?
[05:34:00] <seb_kuzminsky> currently each ll takes a config string modparam for each board that lets the user tweak what firmware modules are enabled
[05:34:02] <jmkasunich> the parport one needs a port address, what else?
[05:34:04] <SWPadnos> to enable/disable functions
[05:34:09] <seb_kuzminsky> SWPadnos has it
[05:34:20] <SWPadnos> you should have params as well, so you can use some but not all matching boards
[05:34:31] <jmkasunich> thats not really a LL driver function
[05:34:37] <seb_kuzminsky> SWPadnos: that's crazy talk
[05:34:45] <SWPadnos> I'm a crazy talker
[05:34:52] <seb_kuzminsky> jmkasunich: agree, but it's a really convenient place to put that info
[05:34:58] <jmkasunich> for "which boards to use", you determine that by which /proc files you cat to
[05:35:10] <seb_kuzminsky> the alternative is to tell the hl driver what to do with each board it finds in the mgr somehow
[05:35:21] <SWPadnos> hmmm
[05:35:25] <jmkasunich> for the functions, it makes more sense to pass that to the HL driver - I like swp's idea that the HL driver doesn't even have to be HAL
[05:35:31] <SWPadnos> I think that 10-step plan will need to change a little
[05:35:47] <seb_kuzminsky> yeah to accomodate multiple hls
[05:36:01] <seb_kuzminsky> the current scheme is very much limited to just hostmot2
[05:36:09] <SWPadnos> the firmware has to be programmed before the ll drivers can be loaded, since the ll drivers need to be told which functions to enable/disable
[05:36:18] <seb_kuzminsky> no
[05:36:30] <jmkasunich> no
[05:36:33] <SWPadnos> I don't think we'll want to have the drivers sitting around waiting for firmware to load
[05:36:35] <seb_kuzminsky> the hl needs to be told what to enable/disable, the lls dont know & dont care
[05:36:38] <jmkasunich> the LL drivers don't know anything about the firmware
[05:36:41] <SWPadnos> heh
[05:36:55] <SWPadnos> ok, so they're just the access and programming interface
[05:36:59] <seb_kuzminsky> yep
[05:37:06] <SWPadnos> ok, then I'm really going to bed
[05:37:08] <SWPadnos> :)
[05:37:11] <jmkasunich> at load time the ll driver just finds the boards, creates the /proc entries, and returns
[05:37:29] <seb_kuzminsky> one nice thing with request_firmware()/udev is that there's this machinery sitting there ready to leap into action and fetch the firmware when the driver wants it
[05:37:39] <seb_kuzminsky> we need our own sync scheme for this to work
[05:37:39] <jmkasunich> when you cat to the /proc entry, that wakes up the driver, and it registers the board with the manager, providing the read and write calls for the HL driver
[05:37:56] <seb_kuzminsky> but if you insmod and cat before the driver's found the board and made the proc file?
[05:38:17] <SWPadnos> insmod shouldnt' return until the module has loaded
[05:38:21] <jmkasunich> right
[05:38:29] <SWPadnos> the proc entry will be there at that point
[05:38:55] <seb_kuzminsky> is that true? insmod wont return until the __init functions return?
[05:39:08] <jmkasunich> I'm almost certain
[05:39:22] <seb_kuzminsky> seems to make sense
[05:39:50] <seb_kuzminsky> it's bedtime here too
[05:39:51] <seb_kuzminsky> open issues:
[05:39:53] <SWPadnos> yes, I'm pretty sure that's the case
[05:39:54] <seb_kuzminsky> config strings
[05:40:00] <seb_kuzminsky> multiple hls
[05:40:02] <jmkasunich> and I think if init_module returns non-zero, insmod returns failure
[05:41:13] <seb_kuzminsky> thanks guys
[05:41:14] <jmkasunich> multiple HLs is a non-issue if each HL can recognize "this is my firmware, I'll use this board" vs. "oops, I dunno what this is, skip it"
[05:41:33] <seb_kuzminsky> zzzzz......
[05:41:44] <jmkasunich> heck, its not even late where you are
[05:41:50] <SWPadnos> wuss
[05:41:59] <jmkasunich> one last thought - regarding config
[05:42:04] <seb_kuzminsky> shoot
[05:42:26] <jmkasunich> suppose in additon to /proc/anyio/board/firmware we also have /proc/anyio/board/configstring
[05:42:50] <seb_kuzminsky> yes
[05:42:51] <jmkasunich> and we provide a middleware API like "read_config_string(board)" for the HL driver to call
[05:42:56] <jmkasunich> no insmod params that way
[05:43:18] <seb_kuzminsky> or just hang the config string on the board struct in the manager
[05:43:23] <jmkasunich> yeah
[05:43:35] <seb_kuzminsky> i like it
[05:43:54] <jmkasunich> btw, I imagine the actual "set up the /proc entry" code would exist in the manager module, and be called by the LL drivers - they wouldn't do that stuff themselves
[05:44:03] <seb_kuzminsky> it's not late here, but my son wakes up with the sun at like 5:30
[05:44:11] <jmkasunich> ouch
[05:44:16] <SWPLinux> ewww
[05:44:50] <jmkasunich> goodnight guys
[05:44:52] <seb_kuzminsky> yes as much as possible should be abstracted and reused, and the mgr seems like a good place for it
[05:44:57] <seb_kuzminsky> bitfile parsing too probably
[05:45:06] <seb_kuzminsky> ok, must stop talking now!
[05:45:12] <seb_kuzminsky> good night, ttyl
[05:45:40] <jmkasunich> I hope the logger got all the important bits - mostly the last half hour
[05:45:52] <seb_kuzminsky> i got it if not
[05:46:17] <seb_kuzminsky> i'll have to mull this over for a bit, i'll post something to the list tomorrow or over the weekend or something
[05:46:21] <SWPadnos> it only missed about 5 minutes at 00:23-00:29
[05:46:40] <seb_kuzminsky> night
[08:21:12] <alex_joni> my head spins :/
[12:08:42] <CIA-34> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/gui/axis.lyx: Clear up external editor discription in axis.lyx
[12:14:55] <CIA-34> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gui/axis.lyx: Clear up external editor description in axis.lyx
[12:19:07] <jepler> alex_joni: enjoyed your vacation photos
[12:19:30] <jepler> alex_joni: I like
http://dsplabs.cs.utt.ro/~juve/blog/index.cgi-files/photography/01215079593/corfu_07.jpg and
http://dsplabs.cs.utt.ro/~juve/blog/index.cgi-files/photography/01215079593/corfu_52.jpg best
[12:54:51] <alex_joni> jepler: thanks
[12:55:02] <alex_joni> I didn't have the nerve to put more of them up
[12:55:10] <alex_joni> I have roughly 1k3 from that week :)
[13:19:10] <cradek> BigJohnT: thanks for clearing up the EDITOR stuff
[13:19:38] <jepler> BigJohnT: by the way, you don't have to say in the commit message what file(s) you changed
[13:20:57] <alex_joni> unless it's a cross reference
[13:21:33] <alex_joni> like something changed in file foo.ext ..
[13:25:01] <jepler> [696510.921951] rtai_hal: disagrees about version of symbol struct_module
[13:25:12] <jepler> * jepler wonders why rtai won't load on his system again
[13:25:49] <jepler> I must have done something wrong when building or installing the new kernel / rtai 3.6.1
[13:25:59] <alex_joni> is it the module from the last kernel?
[13:26:08] <jepler> I'm not sure
[13:26:25] <alex_joni> modinfo might say
[13:26:31] <jepler> I thought it went with the kernel I'm now running (2.6.24-16.30.linuxcnc.4) but maybe I'm mistaken
[13:27:03] <SWPadnos> apparently that kind of problem is not limited to rtai:
http://ubuntuforums.org/showthread.php?t=285668
[13:31:13] <SWPadnos> I need more coffee
[13:34:00] <jepler> I rebuilt rtai and now the problem is fixed; I must have built against wrong headers
[13:34:24] <jepler> (not installed new linux-headers after building the new kernel?)
[13:34:38] <jepler> (but these kernels were supposed to be the same abi, so hmm)
[13:34:47] <BigJohnT> ok jepler didn't know that
[13:36:33] <BigJohnT> cradek: I plan on adding it to the [DISPLAY] section of the integrators manual. I assume it only works with AXIS?
[13:36:52] <jepler> BigJohnT: yes, I believe that's true
[13:37:01] <BigJohnT> ok jepler thanks
[13:37:32] <cradek> I think all of the other guis except keystick have an editor built in, so you don't get/have to choose an editor.
[13:38:34] <SWPadnos> I had a chance to watch people using a high end control, and it was interesting to see the features they had available
[13:38:46] <SWPadnos> and some of the hoops they had to jump through to do certain things
[13:39:31] <cradek> for example?
[13:39:42] <SWPadnos> well, I've mentioned multi-line MDI before
[13:39:48] <BigJohnT> I see the same thing with HMI's what is perfectly clear to me is ... perfectly clear to me as the programmer
[13:40:15] <SWPadnos> they had G-code macros (ie, G100 was a macro that did some stuff to set the power supply parameters)
[13:40:24] <BigJohnT> some times the users do things you never expect when pushing buttons
[13:40:44] <SWPadnos> the way stored programs were used (you could assign a G-code to run a macro, which is how the G100 was done)
[13:42:07] <SWPadnos> the GUI was interesting - it showed why a reconfigurable UI is important
[13:42:53] <SWPadnos> this was a ram EDM machine. there was of course no need for a 3D preview, but there were current and voltage graphs instead
[13:43:13] <SWPadnos> loads of buttons/indicators for various subsystems (pyvcp stuff)
[13:44:15] <SWPadnos> messages and errors were handled nicely - a couple of small text buffers held those (separately)
[13:44:46] <SWPadnos> with buttons above that changed color to indicate alarms or messages
[13:46:02] <cradek> I think AXIS could handle those messages better than the dialogs it currently uses... but I don't have a coherent design to suggest.
[13:47:25] <SWPadnos> one ineteresting thing is that the GUI never loses focus, the messages just go to their little corners
[13:47:54] <cradek> yeah.
[13:47:57] <SWPadnos> oh, and there was a physical edit/run mode switch, which caused the screen to change completely
[13:48:34] <SWPadnos> I didn't see whether that was locked out when running code, or if it would abort a run
[13:56:51] <BigJohnT> I've seen where the messages are in the bar at the bottom and flash red background when it is important
[13:57:35] <SWPadnos> well, it may be time to make something like pyvcp for nml - the dreaded configurable UI
[13:57:41] <SWPadnos> not that I'm volunteering :)
[13:59:06] <cradek> I'm trying to understand how/why you got from "it had some interesting gui features, like the way it presented error messages and locked out edits" to "a reconfigurable UI is important"
[14:00:29] <SWPadnos> well, this was a CNC machine, though it didn't do path following like we normally think of for CNC
[14:00:50] <SWPadnos> wait - let me back up
[14:01:19] <SWPadnos> I don't think that a single UI is good for all users or all uses
[14:01:47] <cradek> I'm sure that's true
[14:01:59] <SWPadnos> I know we have several to choose from, but they're all geared toward mill or lathe use
[14:02:17] <jepler> nml bindings in one compiled and two interpreted languages = configurable UI
[14:02:20] <cradek> lots of emc is geared toward mill (or as an afterthought, lathe)
[14:02:29] <SWPadnos> XYZ (ABC...) readouts, maybe a preview or backplot, G-code listing, a few buttons that hook to EMC (/NML) functions
[14:02:53] <jepler> you configure it by writing a few hundred or thousand lines of source code
[14:03:07] <SWPadnos> sure, that's one way to look at it
[14:03:08] <cradek> there are tasks for which (parts of?) emc would be useful but that would require a totally different gui (or no gui)
[14:03:26] <alex_joni> I did some work with parts of emc once
[14:03:31] <alex_joni> actually it was more HAL stuff
[14:03:37] <alex_joni> and I ended up with a custom GUI
[14:03:45] <jepler> if you're an integrator looking to roll out an expensive machine with EMC as the control, hire a (contract?) programmer to make your GUI.
[14:04:58] <cradek> making a gui that's configurable to be appropriate for applications that are unknown to us (and unlike mills/lathes) is not an attractive task and may even be an impossible one.
[14:05:04] <SWPadnos> heh
[14:05:14] <cradek> well I'm actually serious
[14:05:21] <SWPadnos> I understand :)
[14:06:20] <SWPadnos> the problem space is restricted by what EMC does, so I think it's not impossible to make something that could be used (or relatively easily extended) to control EMC
[14:08:22] <cradek> the problem space of a gui is restricted only by what the user wants to do with EMC.
[14:08:32] <cradek> a gui interacts both with the user and EMC.
[14:09:20] <SWPadnos> true
[14:09:22] <cradek> say I use EMC to control motors that run dampers for my HVAC system. My gui would have HVAC terminology on it.
[14:09:50] <cradek> my gui will have almost nothing in common with a mill or lathe.
[14:10:09] <SWPadnos> sure, though decorations are a relatively simple thing (text strings, images ...)
[14:10:35] <SWPadnos> it's the things that interface the user with EMC that are limited inscope, and also most desirable IMO
[14:10:50] <cradek> brb
[14:11:07] <SWPadnos> I may just be thinking of something like pyvcp, like an emcvcp
[14:11:22] <SWPadnos> maybe embeddable in AXIS like pyvcp, maybe standalone
[14:12:04] <SWPadnos> but it might have things like a message window or start/stop buttons
[14:12:28] <SWPadnos> (obviously, most things that are done with NML aren't needed in an embedded panel, since AXIS already does them)
[15:08:42] <micges> cradek, jepler, SWPadnos:
http://imagebin.org/21912
[15:09:09] <SWPadnos> STOP AWARYJNY! :)
[15:09:11] <SWPadnos> cool
[15:09:36] <SWPadnos> (clear warnings, or something like that, right?)
[15:09:42] <BigJohnT> I like MASZYNA NIEZBAZOWANA
[15:10:17] <micges> yes much more clear messages about machine state
[15:10:31] <SWPadnos> if you know what niezbazowana means :)
[15:10:55] <SWPadnos> that is much of what I was talking about
[15:11:14] <BigJohnT> not a clue :)
[15:11:58] <SWPadnos> google translate also doesn't know :)
[15:12:09] <BigJohnT> but I do like the red message in a message area
[15:12:55] <micges> red message is the first I've added to axis about 2 years ago :)
[15:12:59] <SWPadnos> hmmm. I wonder if that creaking door means my spork has arrived
[15:13:25] <micges> machine not homed it means :)
[15:13:38] <micges> stop awaryjny -> estop
[15:16:11] <BigJohnT> a different way to program PLC's
http://pastebin.ca/1061375
[15:16:41] <SWPadnos> pascal-ish
[15:17:48] <BigJohnT> structured text as it is called
[15:18:01] <SWPadnos> yep
[15:18:05] <BigJohnT> pretty cool to work with
[15:18:12] <SWPadnos> I think CL can use that, or something similar
[15:18:17] <micges> another:
http://imagebin.org/21913
[15:18:34] <SWPadnos> I think it supports a few of the standard PLC "languages"
[15:18:36] <BigJohnT> hmmm, I didn't know that
[15:20:03] <SWPadnos> oh hmm - it supports "sequential" (also known as grafcet)
[15:21:19] <SWPadnos> I thought it supported some ISO6xxx or something, but oh well
[15:23:07] <SWPadnos> micges, are those the coordinate sytems listed in the listbox? (for editing all the offsets)
[15:24:11] <BigJohnT> I don't like Sequential Function as well as Structured Text for PLC's
[15:26:06] <micges> no, those are machine settings
[15:26:32] <micges> different speeds, high, and so on settable by one click
[15:28:18] <micges> second pic are vectored velocity correction (mentioned few months ago) and height correction based on the same idea
[15:28:46] <micges> 4 diffeerent directions
[15:29:50] <SWPadnos> oh, ok
[15:30:12] <SWPadnos> I was looking at the list that says punkt, punkty, punktow ...
[15:30:43] <SWPadnos> I know the "y" suffix usually means plural, what's "ow"?
[15:30:49] <SWPadnos> (at least I think I know that :) )
[15:30:59] <micges> names of settings (width in points of laser row width)
[15:31:31] <SWPadnos> ok, 1-8 points, got it
[15:31:40] <micges> in 5,6,7,8,9 there are "ow"
[15:31:50] <micges> in 2,3,4 there is "y"
[15:32:00] <SWPadnos> ok, like 1st, 2nd, 3rd, 4th-9th
[15:32:30] <micges> yes
[15:32:39] <SWPadnos> I guess I should go back one day - I'm forgetting the little I learned :)
[15:33:09] <micges> go back ?
[15:33:13] <SWPadnos> to Poland
[15:33:52] <micges> kielce, right ?
[15:33:56] <SWPadnos> yep
[15:33:56] <micges> or sth like that
[15:34:02] <SWPadnos> and Krakow
[15:34:11] <SWPadnos> the salt mine is pretty amazing
[15:34:21] <micges> yes it is
[15:34:59] <SWPadnos> I mentioned to the Nikon folks that they should take some photographs there to show off the low-light performance of the D300 and D3 cameras
[15:35:04] <SWPadnos> maybe they'll take me along :)
[15:35:34] <micges> hehe :)
[15:38:32] <micges> You must visit me
[15:38:46] <SWPadnos> sounds good to me. where are you again?
[15:38:54] <micges> Torun
[15:39:07] <micges> 300km north from Krakow
[15:39:27] <SWPadnos> ok, so same latitude as Kielce (roughly :) )
[15:39:48] <micges> you will see all goods made with EMC ;)
[15:40:25] <micges> (and good beer from Poland ;)
[15:40:36] <SWPadnos> hmmm. is there more than one Torun, or are you a little north of warsaw?
[15:40:46] <SWPadnos> heh - if I liked beer, that would be great ;)
[15:41:06] <SWPadnos> I still haven't opened the vodka I was given last time (the buffalo grass stuff)
[15:41:19] <micges> little north west
[15:41:33] <micges> (not so little 200km)
[15:41:45] <SWPadnos> heh, ok - it's the same one
[15:41:53] <micges> you drink rarely ?
[15:41:59] <SWPadnos> very rarely
[15:42:24] <SWPadnos> I almost never drink while I'm at home, sometimes on an airplane or while traveling
[15:42:39] <SWPadnos> probably 2 or 3 times a year, if that
[15:42:47] <micges> ok then You will like Polish food :)
[15:42:54] <SWPadnos> I do, I do
[15:43:47] <micges> :)
[15:44:26] <SWPadnos> my grandparents were from Russia, Belarus, and Romania, so I had some cooking from those regions when I was a kid
[15:44:49] <SWPadnos> still like it (plus I like food in general ;) )
[15:49:26] <micges> me too
[19:31:59] <alex_joni> dobry wieczór
[19:32:56] <micges> dobry wieczór
[19:33:57] <micges> alex_joni: you are on long trip now ?
[20:07:40] <alex_joni> no, actually home for a couple of days :D
[20:07:54] <alex_joni> but the weekend is overbooked :(
[20:13:16] <micges> cool
[20:13:16] <skunkworks_> has anyone gone over the directions here?
http://www.pendrivelinux.com/2008/05/08/usb-ubuntu-804-persistent-install-via-the-live-cd/
[20:13:54] <micges> we are ending big machine project...
[20:14:02] <micges> 3 weeks left
[20:14:16] <micges> and I have very little time to rest
[20:14:36] <micges> but after that I will have vacations :)
[20:14:41] <micges> finally :P
[20:18:25] <BigJohnT> micges: we are wrapping up 3 identical machines this week
[20:18:38] <BigJohnT> This is one
http://imagebin.ca/view/QuJWVyOg.html
[20:18:42] <skunkworks_> is the 2 wgets going to screw up the emc live cd?
[20:19:43] <BigJohnT> http://imagebin.ca/view/4LKmSIG6.html
[20:22:14] <micges> cool what is it for ?
[20:25:00] <BigJohnT> it tests several things on a running engine and removes the brake clip
[20:25:07] <BigJohnT> for lawnmower engines
[20:26:46] <micges> very interesting
[20:26:47] <BigJohnT> we test the starter switch, the stop switch, the stop time, the brake function, the static governor setting, the RPM all in less than 5 seconds
[20:27:18] <BigJohnT> even more interesting now that they are working well :)
[20:27:33] <micges> btw: where are you working ?
[20:27:42] <micges> what are you do ?
[20:28:03] <BigJohnT> I am a partner in an automation business
[20:28:26] <BigJohnT> I own 1/2 and still build machines and sweep floors sometimes :)
[20:31:11] <micges> what is lawnmower engine ?
[20:31:16] <micges> cant translate it
[20:31:45] <cradek> lawnmower = spinning blade you push to cut the grass/lawn
[20:32:30] <micges> cradek: thanks
[20:32:57] <BigJohnT> yes Briggs & Stratton engines
[20:33:17] <BigJohnT> there is one sitting on the pallet
[20:34:45] <micges> I see
[20:38:07] <alex_joni> skunkworks_: yes it will break it
[20:38:31] <alex_joni> but you can find syslinux.cfg and initrd.gz on the CD somewhere I think
[20:41:03] <micges> our machine 2 weeks ago:
http://imagebin.org/21925
[20:41:30] <micges> huge flat+rotation laser
[20:41:45] <BigJohnT> lots of work to go?
[20:42:27] <micges> indeed
[20:43:26] <micges> but all electronic + software are finished
[20:43:53] <micges> soft is now testing
[20:44:26] <BigJohnT> cool
[20:45:07] <micges> only put it together
[20:46:14] <micges> our another rotation only laser:
[20:46:50] <micges> http://imagebin.org/21926
[20:46:51] <BigJohnT> I'm doing final programming before delivery next monday
[20:47:11] <BigJohnT> cool, for pipe
[20:47:21] <micges> this is my sweet test machine :)
[20:47:34] <skunkworks_> rotory dieboards ?
[20:47:43] <micges> yes
[20:47:47] <BigJohnT> for printing press
[20:47:49] <skunkworks_> cool
[20:47:50] <BigJohnT> ?
[20:48:05] <BigJohnT> or rule dies
[20:48:13] <skunkworks_> yes - steel rule dies
[20:48:46] <skunkworks_> we don
[20:48:55] <skunkworks_> we don't do rotory.. seen them done though
http://www.empirescreen.com/adiemaking.html
[20:49:01] <micges> for dieboards for fast and not high precision box machines
[20:49:40] <BigJohnT> ok, I know what they are...
[20:50:41] <micges> BigJohnT: sorry ;)
[20:51:25] <micges> skunkworks_: still have this nice website :)
[20:51:37] <skunkworks_> heh - I don't do web...
[20:51:38] <BigJohnT> I used to buy boxes by the container load and would visit the plants where they were made then I filled them with nails that I made...
[20:55:48] <micges> bad idea with keyboard:
http://imagebin.org/21927
[20:56:25] <BigJohnT> that has to hurt using that
[20:57:04] <micges> we will fix it ;)
[20:57:35] <micges> only I have patience to operate that machine more than hour :)
[21:04:31] <BigJohnT> see you guys later it is beer time...
[21:05:12] <BigJohnT> the other John can be the boss today he bought the beer
[21:06:01] <micges> :)
[21:06:40] <BigJohnT> we take turns being boss
[21:28:54] <skunkworks_> hmm - how come sudo gedit isn't working..
[21:29:07] <SWPadnos> in an icon or from a terminal?
[21:29:22] <skunkworks_> terminal
[21:29:34] <skunkworks_> trying to edit a read-only file.
[21:29:36] <SWPadnos> do you already have a gedit window open?
[21:29:49] <skunkworks_> no
[21:29:53] <SWPadnos> oh, well that would also be a problem (though it usually just tells you you can't save it)
[21:30:18] <skunkworks_> heh
[21:35:11] <micges> skunkworks_: 6.6 or 8.4 ?
[21:40:18] <skunkworks_> 8.4
[21:40:25] <skunkworks_> I think I have it.. maybe
[21:40:42] <skunkworks_> I just changed the file from read-only to read-write.. seemed to work
[21:41:17] <skunkworks_> * skunkworks_ knows just enough to be dangerous
[21:41:30] <SWPadnos> it might have been better to use less instead of gedit :)
[21:43:17] <skunkworks_> less is an gui editor?
[21:45:21] <SWPadnos> less is a text file viewer that runs in the terminal
[21:45:34] <SWPadnos> if you're looking at a RO file, then a viewer is all you need ...
[22:43:20] <seb_kuzminsky> jmkasunich, SWPadnos: you guys around?
[22:43:48] <SWPadnos> mostly
[22:44:13] <seb_kuzminsky> i think we missed something stupid last night
[22:44:32] <seb_kuzminsky> i think we can do RIP and request_firmware()
[22:44:47] <seb_kuzminsky> by requesting "../../home/seb/sandbox/firmware.bit"
[22:44:59] <seb_kuzminsky> udev will prepend "/lib/firmware" and everything will work out
[22:45:16] <seb_kuzminsky> it's ugly, but not as ugly as reimplementing request_firmware()
[22:45:49] <seb_kuzminsky> the rest of the solution we sketched out stays the same
[22:47:25] <seb_kuzminsky> just wanted to mention that... i'm gonna look into it deeper and report back next week or so
[22:48:12] <SWPadnos> I'd be surprised if that hole is left open
[22:48:24] <SWPadnos> but then again they may be thinking of people exactly like us :)
[23:00:14] <jepler> I don't see in firmware_helper where this is specifically forbidden
[23:00:26] <jepler> seems like it is probably unintended and I'd be reluctant to depend on it
[23:02:59] <seb_kuzminsky> more or less reluctant than re-implementing request_firmware()? which is the current baseline option...
[23:03:28] <SWPadnos> no, the current baseline option is to continue to use bfload
[23:03:44] <SWPadnos> or "an EMC-specific firmware loader
[23:03:45] <SWPadnos> ""
[23:04:23] <seb_kuzminsky> last night we baselined adding a file in /proc to cat the firmware into - pretty close to reimplementing request_firmware()
[23:04:50] <jepler> while it's a bit silly to imagine userspace trying to protect an adversary running kernel code, I can see those who would "fix" a request_firmware(../../etc/passwd) bug as a security hole.
[23:05:00] <jepler> er, protect against an adversary
[23:05:27] <jepler> in fact I'm tempted to go file that bug right now :-P
[23:05:30] <SWPadnos> heh
[23:05:31] <seb_kuzminsky> it could go away, it is true
[23:05:33] <seb_kuzminsky> heh
[23:05:42] <seb_kuzminsky> sigh
[23:05:46] <seb_kuzminsky> this is so annoying
[23:06:04] <seb_kuzminsky> ah well, ttyl
[23:06:12] <SWPadnos> see you later. have a ...
[23:07:16] <jepler> I didn't mean to drive him away
[23:07:59] <SWPadnos> I guess it's pretty frustrating trying to support so many options
[23:08:16] <SWPadnos> then again, maybe dinner was ready ;)
[23:20:01] <CIA-34> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/config/ini_config.lyx: Added to DISPLAY section of Integrator manual and removed missing link.
[23:21:22] <CIA-34> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/config/ini_config.lyx: Added to DISPLAY section of Integrator manual and removed missing link.
[23:21:51] <BigJohnT_> time to chill talk to you guys later
