Back
[00:00:15] <cradek> well I'm off to see if I melted anything
[00:00:34] <jmkasunich> I'm off to walk the dog
[00:00:35] <cradek> I'll know pretty quick I bet
[00:00:43] <cradek> that sounds safer, trade?
[00:36:52] <Guest565> Guest565 is now known as skunkworks
[19:36:05] <SWPLinux> so, I'm finally getting to bfload for the 5i22
[19:37:17] <SWPLinux> a couple of questions come up, like how should cards be enumerated - if you have 4 cards, a 5i20, then a 5i22, then 5i20, then 5i22, what card numbers should they get?
[19:37:40] <jmkasunich> good question
[19:38:32] <jmkasunich> I don't recall if the hal pin names will be 5i20.N.blah, or 5i2x.blah
[19:38:33] <SWPLinux> also, I think the "right way" to deal with different cards is to make a table of the relevant magic numbers (PCI IDs, control byte offsets, programming function, etc)
[19:38:48] <SWPLinux> that's step 2 (or later) :)
[19:38:55] <jmkasunich> if its 5i20, then you should have 5i20.0, 5i20.1, 5i22.0 and 5i22,1
[19:39:04] <SWPLinux> gotta get some blinkenlights before I worry about HAL drivers
[19:39:16] <SWPLinux> that makes sense
[19:39:36] <jmkasunich> if its 5i2x, then they'd be 0,1,2,3
[19:39:55] <jmkasunich> I think the drivers use 5i2x
[19:40:06] <SWPLinux> ok
[19:40:13] <jmkasunich> since that lets the driver code for "encoder" export pins without knowing what board you have
[19:40:32] <SWPLinux> the 5i20 driver would have one name, and the 5i2x driver would have another name, possibly for the same card
[19:40:48] <SWPLinux> not that anyone should use both the 5i20 and the 5i2x driver, but ...
[19:41:01] <jmkasunich> by "5i20 driver" do you mean the old driver?
[19:41:03] <SWPLinux> yes
[19:41:31] <jmkasunich> they probably can't coexist, at least not unless you are very carefull
[19:41:39] <SWPLinux> heh - I was thinking that
[19:41:55] <jmkasunich> the new driver expects there to be a ram block telling it what the FPGA contains, the old driver expects a single config without the ram
[19:42:07] <jmkasunich> the new driver will abort if the ram block isn't there
[19:42:18] <SWPLinux> ok - this is step 2 though. I'm working on bfload for the moment
[19:42:19] <jmkasunich> I have no clue what the old one will do if there is a new config loaded
[19:42:51] <SWPLinux> the method of programming the 5i22 (or 5i21) is different from that for the 5i20
[19:43:29] <SWPLinux> I wonder if it makes sense to use bfload to wite a card ID to the RAM block, and have the driver pick that up
[19:43:34] <jmkasunich> I didn't even know ther was a 5i21
[19:43:51] <SWPLinux> that's the 24-channel RS422 card, I think
[19:43:58] <SWPLinux> or something like that
[19:44:41] <SWPLinux> it usees the same bridge chip (PLX9054 instead of PLX9030), and has a Spartan III instead of the spartan II on the 5i20
[19:45:01] <SWPLinux> err - the 5i21 and 5i22 have the same PCI bridge
[19:45:25] <jmkasunich> is the 5i21 something that would be suitable for use with HAL? or is this info just a bit of trivia?
[19:45:40] <SWPLinux> unfortunately, I don't know how to tell which card is which if you have several in the same PC
[19:45:54] <SWPLinux> it's unrelated to EMC, but related since that's the programming code I have
[19:46:00] <jmkasunich> ah
[19:46:05] <SWPLinux> there isn't a config loader for the 5i22 yet
[19:46:10] <jmkasunich> ok
[19:46:24] <jmkasunich> I'm looking at bfload.c now
[19:46:25] <SWPLinux> petew said the one for the 5i21 should be the same though
[19:46:28] <SWPLinux> ok
[19:46:49] <SWPLinux> so ther PCI Ids change, and all those status bit locations (and there are only 2 bits used in the status register)
[19:46:50] <jmkasunich> do you see the big comment block at the beginning, with info about how the board is wired?
[19:46:53] <SWPLinux> yes
[19:47:15] <jmkasunich> step #0 IMO is to try to deduce as much of that info for the 5i22 as possible
[19:47:25] <jmkasunich> start a new section in that comment block and fill it in
[19:47:31] <SWPLinux> how did you get that info in the first place?
[19:47:39] <jmkasunich> deduction
[19:47:41] <SWPLinux> ok
[19:47:46] <jmkasunich> reading the 5i20 manual, for example
[19:47:52] <jmkasunich> and looking at the programming software
[19:48:12] <SWPLinux> ok. the 5i22 manual is pretty sketchy on that. it mentions the two bits in the control register, and that's about it
[19:48:20] <jmkasunich> I think I even buzzed a few pins out with an ohmeter
[19:48:28] <SWPLinux> I have the 5i21 software, which should be the same
[19:48:30] <jmkasunich> oh, and I had the 9030 datasheet
[19:48:42] <jmkasunich> the software is probaby the least usefull source of info
[19:48:47] <SWPLinux> ah. I thought I had registered on PLXs website, but I can't find the reg info no
[19:48:49] <SWPLinux> now
[19:48:58] <SWPLinux> I suppose I should do that and get the 9054 datasheet
[19:49:10] <jmkasunich> they're one of those, eh
[19:49:12] <jmkasunich> bastards
[19:49:15] <SWPLinux> yes
[19:52:01] <jmkasunich> oh, I just remembered another source of info - the constraints file(s) from mesa
[19:52:30] <jmkasunich> I edited them extensively to make them more reader friendly
[19:53:44] <jmkasunich> iopr24.ucf is a start
[19:57:30] <jmkasunich> looking at the 5i22 datasheet, things are very different
[19:57:38] <SWPLinux> yes
[19:57:48] <SWPLinux> I have some pin files as well
[19:58:15] <jmkasunich> differet region numbers for example - the 5i20 uses region 5 for the main memory block, and the 5i22 uses region 3
[19:58:16] <SWPLinux> I'm not so worried about getting a programming routine done (though the code for hte 5i21 isn't all that easy to follow)
[19:58:31] <SWPLinux> thatll be aproblem later, I'm sure :)
[19:59:21] <jmkasunich> ok, exactly where are we?
[19:59:33] <jmkasunich> step 0 - gather info about the 5i22
[19:59:41] <SWPLinux> I guess what I'm wondering about is how bfload should be organized to support different boards
[19:59:43] <jmkasunich> step 1 - figure out how to talk to the bridge chip on it
[19:59:52] <jmkasunich> step 2 - figure out how to load a config
[19:59:59] <jmkasunich> step 3 - figure out the driver
[20:00:18] <SWPLinux> step 2.5 - make a test config for the 5i22
[20:00:26] <jmkasunich> yeah
[20:00:50] <SWPLinux> step 2.6 make sure we can differentiate between configs for the spartan2 vs. the spartan3
[20:01:15] <jmkasunich> more precisely, between configs for 5i20 and 5i22
[20:01:16] <SWPLinux> step 2.6.5 figure out how to tell if the 5i22 has the 1MGate or the 1,5MGate chip ...
[20:01:25] <jmkasunich> oh, there are two chips?
[20:01:35] <SWPLinux> yep
[20:01:37] <jmkasunich> joy
[20:01:43] <SWPLinux> two flavors of the card
[20:01:45] <SWPLinux> yep
[20:02:16] <jmkasunich> is the spartan 2/3 thing a 1M/1.5M thing, or a 5i20/5i22 thing?
[20:02:20] <SWPLinux> there's got to be some way of ID'ing an FPGA through the programming port
[20:02:24] <SWPLinux> no
[20:02:34] <SWPLinux> the 5i22 has two chip options
[20:02:53] <SWPLinux> I don't know if any of the PCI IDs change between them (Ionly have boards with the 15.MGate chip)
[20:03:24] <jmkasunich> do the two chips differ only in size (1.0 vs 1.5), or is one a spartan2 and one a spartan3?
[20:03:34] <SWPLinux> both spartan3 on the 5i22
[20:03:45] <SWPLinux> same package, just different gate counts
[20:03:47] <jmkasunich> ok
[20:05:05] <jmkasunich> do you know the device and vendor ID's, and the subsystem device and vendor IDs, for the board you have?
[20:06:11] <SWPLinux> yes
[20:06:40] <SWPLinux> in fact, the only difference is that the PLX9054 is PCI device ID 9054 instead of 9030
[20:06:50] <jmkasunich> you're kidding
[20:06:57] <jmkasunich> the subsystem codes are exactly the same?
[20:07:04] <SWPLinux> but I don't know if the subsystem ID will change for the 1MGate chip
[20:07:07] <jmkasunich> WTF was he thinking?
[20:07:07] <SWPLinux> yes
[20:07:12] <SWPLinux> dunno
[20:07:33] <SWPLinux> it can be changed if you program the 9054 config EEPROM though
[20:07:50] <jmkasunich> if he used the same subsystem device ID for the 5i20 and the 5i22 1.5M, he'll probably use it for the 5i22 1.0M too
[20:08:02] <jmkasunich> stupid stupid stu[id
[20:08:24] <SWPLinux> well, you can tell the 9054 from the 9030, but you can't tell the two flavors of 9054 apart unless the subsystem changes
[20:08:33] <jmkasunich> exactly
[20:08:42] <SWPLinux> so he didn't need to change the subsystem ID (though it would have been nice)
[20:09:05] <jmkasunich> the primary vendor code tells you the bridge is PLX, the primary device tells you which PLX (9030 or 9054)
[20:09:29] <jmkasunich> the subsystem vendor should tell you "Mesa" and the subsystem device should tell you which card
[20:10:09] <SWPLinux> right, though the SS vendor tells you "I didn't bother changing it from PLX"
[20:10:15] <jmkasunich> right
[20:10:18] <jmkasunich> dumbass
[20:10:28] <jmkasunich> s/dumbass/lazy
[20:10:43] <jmkasunich> * jmkasunich <-- crotchety
[20:10:52] <SWPLinux> and/or cheap. you have to join the PCI consortium and pay fees to get an ID assigned
[20:11:01] <jmkasunich> even a subsystem ID?
[20:11:13] <SWPLinux> and it's not cheap - I think the consortium fee is like $2k/year
[20:11:15] <SWPLinux> I think so
[20:11:25] <jmkasunich> (I don't blame him for a second for not joining the consortium
[20:12:16] <SWPLinux> anyway - I have code that isn't in a good format for bfload, but I can change it
[20:12:43] <SWPLinux> the real question is, how should bfload be organized to support multiple chips?
[20:12:51] <SWPLinux> I can make a "bfload22"
[20:12:55] <jmkasunich> no!
[20:13:07] <SWPLinux> I can put the constants into a table, and make everything as generic as possible
[20:13:08] <SWPLinux> heh
[20:13:32] <jmkasunich> the command to invoke bfload is baslclly "bfload <source-file> <destination-board>"
[20:13:39] <SWPLinux> I can just add #defines for all the 5i22 stuff, and have a case statement that calls the right programming function based on the discovered ID
[20:13:41] <SWPLinux> ...
[20:13:48] <jmkasunich> right now, <destination-board> is an integer - maybe that's simply wrong
[20:14:03] <SWPLinux> that's where the enumeration question came in
[20:14:27] <SWPLinux> the destination should probably allow for a PCI bus:device.ID spec
[20:14:27] <jmkasunich> bfload doesn't currently enumerate the boards that exist
[20:14:43] <jmkasunich> it sets five items that identify the board it wants
[20:14:46] <SWPLinux> it needs to internally, so it can choose board #2, for instance
[20:15:09] <jmkasunich> bfload doesn't even do that (in its own code)
[20:15:18] <SWPLinux> oh
[20:15:18] <jmkasunich> the upci library does
[20:15:45] <SWPLinux> so upci returns a list of matching cards (given the vendor/subsystem constants to look for)?
[20:15:45] <jmkasunich> do you have a copy of bfload that you haven't hacked on (so I can give you line numbers)?
[20:15:50] <SWPLinux> sure
[20:15:56] <SWPLinux> I think so anyway
[20:16:14] <SWPLinux> ok, yes
[20:16:18] <jmkasunich> line 154 tells upci "scan the bus and identify all devices"
[20:16:34] <jmkasunich> line 164 says "gimme the info for a specified device"
[20:17:23] <SWPLinux> ok, simple enough
[20:17:29] <jmkasunich> where "specified" means "the Nth board with four ID codes that match my criteria"
[20:17:54] <SWPLinux> yep - info.instnce
[20:17:55] <SWPLinux> instance
[20:18:13] <jmkasunich> going back to what I said earlier about invoking bfload
[20:18:24] <jmkasunich> <destination-board> should probably be more than an integer
[20:18:38] <SWPLinux> yeah - you need a type as well
[20:18:55] <jmkasunich> "5i20-N" "5i22-N"
[20:19:08] <jmkasunich> and probably with a distinction between the 1.0 and 1.5 M ones as well
[20:19:23] <jmkasunich> although I bet we can't tell them apart from PCI ID data
[20:19:34] <SWPLinux> probably so
[20:20:00] <SWPLinux> I don't know where they'd fail either - if you get to the 1M+1 location and progrmming fails
[20:20:08] <SWPLinux> or if some ID doesn't match ...
[20:20:13] <jmkasunich> lets not worry about that yet
[20:20:16] <SWPLinux> nope
[20:20:52] <SWPLinux> though it's definitely worrisome - a config for a 1M part would fit in a 1.5M part, but wouldn't work
[20:20:57] <jmkasunich> going back to the bfload command line - we need to decide what is the right thing to do at that level first, _then_ figure out how to implement it
[20:21:08] <jmkasunich> it wouldn't load
[20:21:16] <SWPLinux> why not?
[20:21:30] <jmkasunich> the device has lines that change state to indicate that it has received the proper amount of data
[20:21:41] <jmkasunich> and that checksums match, etc
[20:22:00] <SWPLinux> I think there are exactly two IO lines used for programming on the 5i22
[20:22:11] <SWPLinux> /PROGRAM and DONE
[20:22:21] <jmkasunich> no /INIT?
[20:22:51] <SWPLinux> don't see one
[20:23:00] <jmkasunich> read the text starting at line 58 of bfload.c
[20:23:20] <jmkasunich> the 5i22 might be a little different, but its gotta be able to convey the same info somehow
[20:23:25] <SWPLinux> yep
[20:23:43] <SWPLinux> if you download the 5i22 software zip file, we'll both have all the info :)
[20:23:47] <SWPLinux> err - 5i21
[20:25:09] <jmkasunich> according to the 5i22 manual there is a program sc5i22.exe, and the source is available
[20:25:20] <SWPLinux> yep, that's what the manual says
[20:25:23] <jmkasunich> why do you keep referring to the 5i21? is the manual lying?
[20:25:39] <SWPLinux> it should also say "this manual contains forward-looking statements"
[20:25:44] <jmkasunich> heh
[20:25:45] <SWPLinux> yes, the manual lies at the moment
[20:26:04] <jmkasunich> what FPGA chip is used on the 5i22
[20:26:07] <SWPLinux> unless he's made the code now - he said he'd try to get to it this past week
[20:26:45] <jmkasunich> I really don't care about what code he's made - I'd be happier starting with a xilinx manual, a PLX manual, and a board schematic
[20:26:49] <SWPLinux> nope. July 13, 22k
[20:26:55] <SWPLinux> uh, 52k
[20:28:37] <SWPLinux> well, the PLX manual can be had for a registration annoyance, the Xilinx manual is readily available, and the board schematic ain't gonna happe,n I think
[20:28:45] <jmkasunich> right
[20:29:13] <SWPLinux> though the pin files are available, and might have enough info to go on
[20:29:18] <jmkasunich> for the 5i20, I got the xilinx, did the annoyance and got the 9030 manual, and figured out the subset of the schematic that I needed
[20:29:23] <jmkasunich> really only a few pins
[20:29:54] <jmkasunich> the info at line 38 of bfload.c is my "schematic" for the 5i20
[20:30:12] <jmkasunich> deduced from manuals and a bit of ohming
[20:30:13] <SWPLinux> yep - I saw that
[20:30:27] <jmkasunich> we need the same info (more or less) for the 22
[20:31:12] <SWPLinux> the FPGA on the 5i22 is a BGA, so there won't be a whole lot of probing going on
[20:31:21] <jmkasunich> true
[20:31:41] <jmkasunich> downloading the spartan3 manual now - I want to read the official description of the loading process
[20:32:00] <SWPLinux> ah yes - I can take a look at that also
[20:32:04] <jmkasunich> peter should be willing to tell us a few traces worth
[20:32:09] <jmkasunich> once we know the pins we care about
[20:32:23] <jmkasunich> the s3 equivalents of DONE, /INIT, etc
[20:33:25] <SWPLinux> I'll see if I can find my PLX login. I have the 9030 datasheet, so I must have done it once before
[20:33:36] <jmkasunich> I did it too
[20:33:41] <jmkasunich> I probably used a fake name
[20:34:03] <SWPadnos> I don't usually do that, but I couldn't find any email from plx telling me my login info
[20:36:29] <jmkasunich> I do it as a matter of principle - I despise people who think that datasheets are a commodity that I need to purchase by giving them my private data
[20:37:27] <jmkasunich> btw:
http://www.xilinx.com/bvdocs/userguides/ug332.pdf <-- a manual specifically focused on config loading
[20:39:07] <SWPadnos> cool
[20:39:17] <SWPadnos> the spartan3 datasheet does show an init pin
[20:40:02] <jmkasunich> have you done much editing on bfload.c?
[20:40:10] <SWPadnos> not really
[20:40:25] <jmkasunich> I'm tempted to start on those comment sections here then
[20:40:28] <SWPadnos> I added the 5i22 subsystem ID
[20:40:46] <jmkasunich> just a few lines?
[20:40:56] <SWPadnos> that's OK by me. I'll read a bit and see if I can get the 5i21 loader hacked in
[20:41:20] <SWPadnos> one line, except that there should be a new section with all the defines, and then there should be a table of chip definitions, and then ....
[20:41:24] <jmkasunich> hacked into where?
[20:41:43] <SWPadnos> into bfload - but it's trivial to change it later
[20:41:57] <SWPadnos> it's just the PLX device ID 0x9054
[20:42:10] <SWPadnos> I haven't done any real work on it
[20:42:15] <SWPadnos> (sadly)
[20:42:36] <jmkasunich> it looks like we're gonna want to change "programfpga()" to "program5i20fpga()", and add "program5i22fpga()"
[20:42:44] <SWPadnos> yeah.
[20:43:06] <SWPadnos> I was thinking of making a table with the config register offset, PCI Ids, and a function pointer for the program function
[20:43:37] <jmkasunich> there are a lot of things that will be board specific, not just those
[20:43:55] <jmkasunich> things like "GPIO_3_MASK" and "DONE_MASK", etc
[20:44:03] <jmkasunich> let's not get ahead of ourselves
[20:44:09] <SWPadnos> those are known by the separate programming functions
[20:44:26] <jmkasunich> I guess they'll just need renamed
[20:44:30] <SWPadnos> yep
[20:44:35] <jmkasunich> 5i22_DONE_MASK, 5i20_DONE_MASK, etc
[20:45:02] <SWPadnos> the master struct can also have a void pointer to a different struct with the info needed for a specific programming method
[20:45:19] <jmkasunich> I would _not_ be surprized to find that the spartan2 and spartan3 config loading sequences are the same
[20:45:34] <jmkasunich> and only the masks need to be changed
[20:45:40] <SWPadnos> I can guarantee that they're not as implemented on these cards
[20:45:53] <jmkasunich> how can you tell?
[20:45:56] <SWPadnos> because the 5i20 has more bits connected to the FPGA than the 5i22 does
[20:46:10] <SWPadnos> there are only two bits - /PROGRAM and DONE
[20:46:33] <SWPadnos> I don't know how init is done, the 5i21 manual says something about it though
[20:46:37] <jmkasunich> how do you know that? reading the 5i21 loader?
[20:46:51] <SWPadnos> yes, I think so :)
[20:47:24] <SWPadnos> damn. what was that website that let you do the fake IDs for website registrations?
[20:47:41] <jmkasunich> hang on a sec, lemme see if my fake is still working
[20:51:52] <SWPadnos> I was all set to enter my real data, then I noticed a message at the top of the form:
[20:52:06] <SWPadnos> "DO NOT RE-USE A SENSITIVE PASSWORD ON THIS SITE. We do not encrypt our transmissions of your data or try to shield your password from you."
[20:52:18] <SWPadnos> so I figured I wouldn't bother with that
[20:52:53] <jmkasunich> my old subscription works
[20:53:10] <SWPadnos> excellent
[20:53:21] <jmkasunich> 9054 right?
[20:53:27] <SWPadnos> yep
[20:53:58] <jmkasunich> 3.something meg, downloading now
[20:54:20] <jmkasunich> sending to you will be slow (my upload is slower than my down)
[20:54:28] <SWPadnos> I'm getting it from "elsewhere" at the moment
[20:54:29] <jmkasunich> won
[20:54:35] <jmkasunich> oops
[20:55:14] <SWPadnos> hmm. only ~2M though
[20:55:36] <jmkasunich> do you know what rev chip is on the board?
[20:55:46] <jmkasunich> (wondering if I should download the erratas)
[20:56:02] <SWPadnos> one sec - it's under the RoHS sticker
[20:56:30] <SWPadnos> hmm. dunno how to tell
[20:56:46] <jmkasunich> AB or AC in the part number?
[20:57:01] <SWPadnos> AC50PI F
[20:57:11] <jmkasunich> ok, thats probably the latest
[20:57:24] <jmkasunich> there is a databook addendum for that rev, downloaded it
[20:57:28] <SWPadnos> ok
[20:57:49] <SWPadnos> what are the download URLs? it's possible their login isn't so secure ...
[20:58:15] <jmkasunich> http://www1.plxtech.com/TEMP/103266/9054db-21.pdf
[20:58:25] <jmkasunich> see if that works
[20:58:29] <SWPadnos> bingo
[20:58:33] <jmkasunich> heh
[20:58:44] <jmkasunich> http://www1.plxtech.com/TEMP/103266/PCI_9054_Data_Book_Addendum_r2.4_24Mar06.pdf
[20:58:52] <SWPadnos> after the disclaimer about plaintext passwords, I figured that might work :)
[20:59:00] <jmkasunich> http://www.plxtech.com/download/PCI9000/9054/design_notes/9054_DesignNotes_r1.8A.pdf
[20:59:15] <jmkasunich> oops, that last one won't work
[20:59:36] <jmkasunich> http://www1.plxtech.com/TEMP/103266/9054_DesignNotes_r1.8A.pdf
[20:59:51] <jmkasunich> http://www1.plxtech.com/TEMP/103266/9054AC_Errata_r1.7.pdf
[21:00:39] <SWPadnos> OK. got tehm, thanks
[21:02:30] <jmkasunich> where is the source for the 5i21 loader?
[21:03:34] <SWPadnos> mesasnet - the 5i21 software.zip file
[21:03:57] <SWPadnos> http://www.mesanet.com/software/parallel/5i21.zip
[21:05:10] <jmkasunich> my screen floweth over
[21:05:15] <SWPadnos> heh
[21:05:58] <jmkasunich> that is such a readable file
[21:06:11] <SWPadnos> oh yes, bvery
[21:06:23] <SWPadnos> I've been considering hooking up the high res monitors just so I could see more of it
[21:06:32] <jmkasunich> grrr, I forgot how butt ugly 5i20 loader was
[21:06:39] <SWPadnos> heh
[21:06:51] <SWPadnos> you see why I'd rather discuss the ideal structure of bfload
[21:07:15] <jmkasunich> getting back to that
[21:07:20] <jmkasunich> what should be on the command line
[21:07:29] <jmkasunich> obviously the source file
[21:07:47] <jmkasunich> then what? board number as an integer? board type and number?
[21:08:05] <SWPadnos> if there's an option to take a PCI bus:function spec, that covers everything
[21:08:11] <jmkasunich> actually, the program could determine the target board type by reading the file header
[21:08:21] <jmkasunich> I disagree
[21:08:37] <jmkasunich> you don't want somebody to specify an arbitrary PCI device
[21:08:52] <SWPadnos> the program has to check that it's got valid IDs
[21:08:58] <jmkasunich> "bfload the-bitfile my-disk-controller"
[21:09:20] <SWPadnos> sure, and when my-disk-controller isn't a 1083:9054, bbfload barfs
[21:09:38] <SWPadnos> (or whatever that PLX code was)
[21:09:45] <jmkasunich> well, if you really want that, feel free to re-write or extend upci.c
[21:10:02] <jmkasunich> I wrote upci.c to find things for you, specifically so you don't have to mess with such crap
[21:10:18] <jmkasunich> "give me the Nth board that matches these ID codes"
[21:10:30] <SWPadnos> sure. but then you need to specify the ID codes somehow
[21:10:42] <jmkasunich> thats based on the board
[21:10:42] <SWPadnos> it can be with -tTYPE
[21:10:46] <jmkasunich> not needed
[21:10:51] <SWPadnos> like -t 5i22
[21:10:56] <jmkasunich> we digressed, but a moment ago I said:
[21:11:01] <jmkasunich> actually, the program could determine the target board type by reading the file header
[21:11:11] <SWPadnos> ok
[21:11:13] <jmkasunich> one of the chunks in the bitfile is the target FPGA device
[21:11:21] <SWPadnos> ok, that's valid
[21:11:36] <jmkasunich> we could read the header, get the device, and set the board type that way
[21:11:41] <SWPadnos> hopefully there won't be different boards that use the same device type
[21:12:12] <SWPadnos> (like the 5i21 nad the 5i22, for example)
[21:12:43] <jmkasunich> for our own bitfiles, we could add a target board ID chunk to the bitfile
[21:13:06] <SWPadnos> actually, they don't use the same chip - they're just programmed the same way. the 5i21 has a 400k gate chip
[21:13:08] <jmkasunich> if the target board chunk is present, use it, if not deduce the board type from the target chip chunk
[21:13:17] <jmkasunich> good
[21:13:31] <jmkasunich> lets keep it simple - target chip type is a standard xilinx chunk
[21:13:36] <jmkasunich> I'll tell you which chunk in a sec
[21:13:48] <SWPadnos> not important for the present discussion
[21:13:59] <jmkasunich> true
[21:14:24] <SWPadnos> so if you specify a config file and a board number, the only potential issue is that PCI enumeration isn't guaranteed to be the same from kernel to kernel
[21:14:39] <SWPadnos> (this is a problem with PCI bus:func specs as well)
[21:14:59] <SWPadnos> so I'm not sure we can do anything about it
[21:15:00] <jmkasunich> yeah, there is no iron-clad way to match up physical boards to addresses
[21:15:21] <jmkasunich> however on any given machine (and OS/kernel install) it will be repeatable
[21:15:32] <SWPadnos> should be, barring BIOS updates ;)
[21:16:01] <jmkasunich> IOW, once it works, don't screw with it
[21:16:06] <SWPadnos> yep
[21:16:32] <jmkasunich> chunk 'b' is the target device
[21:17:18] <jmkasunich> bitfile.c line 374, fwiw
[21:17:29] <SWPadnos> ok - I'll need that later :)
[21:18:02] <jmkasunich> oops, I see a comment error in bitfile.h
[21:19:34] <jmkasunich> do you have a valid 5i22 bitfile to play with?
[21:19:52] <SWPadnos> sort of
[21:20:06] <SWPadnos> I have some trivial bitfiles (like generic I/O) for it
[21:20:13] <SWPadnos> something that does blinkenlights is step 2 for me
[21:21:01] <SWPadnos> I have a 5i22 in a computer, with a 7i31 attached, so some counter -> LED outptus thing should be pretty easy (and may exist already)
[21:22:04] <jmkasunich> I just want a file that has the appropriate header info, so anything will do
[21:22:34] <SWPadnos> ok. I can email you the zip file pete sent me
[21:22:46] <jmkasunich> ok
[21:24:41] <SWPadnos> I just sent the hostmot2 zip file he sent, plus his reply to me asking for a 5i22 loader program
[21:25:39] <jmkasunich> ok - I'm writing a quicky program that prints the bitfile chunks, then I'll modify bfload to check the chunk and set the board type accordingly
[21:25:47] <SWPadnos> cool
[21:26:24] <SWPadnos> maybe I'll concentrate on getting a kernel for this machine while you're doing that
[21:26:33] <jmkasunich> ok
[21:34:45] <jmkasunich> I need to switch machines - this one doesn't have RT, and sim doesn't build bfload
[21:35:06] <SWPadnos> ok. I'll be around - you know - forever
[21:38:42] <skunkworks_> heh
[21:38:53] <jmkasunich> interesting - the hostmot2.bit in the zipfile you sent is built for the 1M gate part
[21:39:21] <jmkasunich> jmkasunich@mahan:~/emcdev/emc2head$ bin/bfload ~/hostmot2.bit Reading '/home/jmkasunich/hostmot2.bit'...
[21:39:21] <jmkasunich> Design name: HostMot2.ncd
[21:39:21] <jmkasunich> Part ID: 3s1000fg320
[21:39:21] <jmkasunich> Design date: 2007/08/15
[21:39:21] <jmkasunich> Design time: 15:54:50
[21:39:21] <jmkasunich> Bitstream size: 402936
[21:39:23] <jmkasunich> Searching for 5i20 board...
[21:39:26] <jmkasunich> ERROR in main(): 5i20 board 0 not found
[21:39:28] <jmkasunich> jmkasunich@mahan:~/emcdev/emc2head$
[21:39:37] <SWPadnos> ok. I hadn't checked that
[21:39:45] <jmkasunich> thats OK
[21:39:51] <jmkasunich> I just needed to see the string format
[21:39:52] <SWPadnos> I figured I'd build my own anyway
[21:40:02] <jmkasunich> I'll put code in to detect all three parts
[21:40:20] <jmkasunich> 3s1000fg320, 3s1500fg320, and 2s200pq208
[21:40:29] <SWPadnos> yep
[21:42:17] <jmkasunich> how should we code the board type? enum I guess
[21:42:54] <SWPadnos> I think I'd make a struct with the string chip type, the PCI Ids for the board, and a programing function pointer
[21:43:03] <jmkasunich> no
[21:43:09] <SWPadnos> heh
[21:43:21] <SWPadnos> no that wasn't the wuestion or no that's a stupid idea?
[21:43:26] <SWPadnos> question
[21:43:29] <jmkasunich> all we want to do at the moment (this is in main()) is decide what board we are looking for
[21:43:52] <jmkasunich> if ( chip == 2s200... ) then boardtype = 5i20, etc
[21:44:10] <jmkasunich> boardtype can be a string, but that would be messy to use later, I vote enum
[21:44:20] <SWPadnos> ok, and boardtype is then used to find out some PCI IDs and how to program it ...
[21:44:24] <jmkasunich> right
[21:44:51] <jmkasunich> an instance of that enum might wind up in a struct later
[21:44:59] <SWPadnos> so you make a lookup function that takes the chip string, compares it to the string field in the struct, and returns the struct array index if it finds a match
[21:45:10] <SWPadnos> the index becomes the enum, for the most part
[21:45:20] <SWPadnos> and that also lets the rest of the program look up the IDs to look for
[21:45:22] <jmkasunich> oh, you want a constant table of structs
[21:45:26] <SWPadnos> yes
[21:45:53] <SWPadnos> {"3s1000fg320", PCI_ID_5i22, ..., program_5i22}
[21:46:05] <jmkasunich> ok
[21:46:12] <SWPadnos> that's better than no :)
[21:47:04] <SWPadnos> that kind of construct allows for addition of other board types without changing any code, except for possibly adding a function for a new programming algorithm
[21:47:14] <jmkasunich> yeah
[21:47:36] <jmkasunich> I just need to work out the type declarations and such, and cp to a box where I can compile it
[21:48:34] <jmkasunich2_> like this one
[22:25:21] <fenn> ~[6~2123[5~[5~[6~[6~[6~
[22:28:42] <skunkworks_> fenn: this was what you posted before you quit <fenn> ~[6~2123[5~[5~[6~[6~[6~
[22:29:21] <jmkasunich2_> there were 0x1B's in there
[22:29:24] <SWPadnos> it was excaped for me: "~0x1b[6~0x1b20x1b10x1b20x1b30x1b[5~0x1b[5~0x1b[6~0x1b[6~0x1b[6~"
[22:29:27] <SWPadnos> escaped
[22:29:28] <jmkasunich2_> IIRC that is esc
[22:29:41] <skunkworks_> do you have a cat? ;)
[22:29:47] <SWPadnos> strange. not all the square brackets pasted correctly
[22:30:09] <jmkasunich2_> SWPadnos: what are the ID codes for the 5i22?
[22:30:20] <SWPadnos> lspci :)
[22:30:37] <jmkasunich2_> that would be handy if I had a 5i22
[22:31:03] <SWPLinux> heh - I can get you one on Tuesday if you like
[22:31:06] <jmkasunich2_> guessing 10b5 9054 10B5 3131
[22:31:07] <SWPLinux> or I can paste in the IDs
[22:31:13] <SWPLinux> yep - one sec
[22:31:23] <SWPLinux> steve@steve-xpc:/Project/emc2/src/hal/drivers/mesa_5i2x/firmware$ sudo lspci -vvn -s 1:5
[22:31:26] <SWPLinux> Password:
[22:31:28] <SWPLinux> 0000:01:05.0 0680: 10b5:9054
[22:31:28] <SWPLinux> Subsystem: 10b5:3131
[22:31:31] <SWPLinux> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
[22:31:32] <SWPLinux> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
[22:31:34] <SWPLinux> Latency: 0, Cache Line Size: 0x10 (64 bytes)
[22:31:36] <SWPLinux> Interrupt: pin A routed to IRQ 5
[22:31:38] <SWPLinux> Region 0: Memory at fdcff000 (32-bit, non-prefetchable) [size=256]
[22:31:39] <SWPLinux> Region 1: I/O ports at da00 [size=256]
[22:31:40] <SWPLinux> Region 2: I/O ports at dc00 [size=256]
[22:31:43] <SWPLinux> Region 3: Memory at fdce0000 (32-bit, non-prefetchable) [size=64K]
[22:31:43] <SWPLinux> Expansion ROM at fdd00000 [disabled] [size=64K]
[22:31:46] <SWPLinux> Capabilities: [40] Power Management version 1
[22:31:47] <SWPLinux> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
[22:31:49] <SWPLinux> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
[22:31:49] <SWPLinux> Capabilities: [48] #06 [0080]
[22:31:51] <SWPLinux> Capabilities: [4c] Vital Product Data
[22:31:56] <jmkasunich2_> a simple yes would have sufficed ;-)
[22:32:01] <SWPLinux> heh
[22:32:10] <jmkasunich2_> typedef struct {
[22:32:10] <jmkasunich2_> char *board_type;
[22:32:10] <jmkasunich2_> char *chip_type;
[22:32:10] <jmkasunich2_> unsigned short vendor_id;
[22:32:10] <jmkasunich2_> unsigned short device id;
[22:32:09] <jmkasunich2_> unsigned short ssvendor_id;
[22:32:11] <jmkasunich2_> unsigned short ssdevice_id;
[22:32:14] <jmkasunich2_> } board_info_t;
[22:32:16] <jmkasunich2_> const board_info_t board_data[] =
[22:32:18] <jmkasunich2_> { { "5i20", "2s200pq208", 0x10B5, 0x9030, 0x10B5, 0x3131 },
[22:32:19] <jmkasunich2_> { "5i22-1M", "3s1000fg320", 0x10B5, 0x9054, 0x10B5, 0x3131 },
[22:32:21] <jmkasunich2_> { "5i22-1.5M", "3s1500fg320", 0x10B5, 0x9054, 0x10B5, 0x3131 },
[22:32:23] <jmkasunich2_> { "END" } };
[22:32:38] <jmkasunich2_> and I have code that finds the proper entry, or prints an error
[22:32:41] <SWPLinux> you had pointed out the different memory map before, so I thought I'd include the full lspci output
[22:32:42] <SWPLinux> cool
[22:32:53] <jmkasunich2_> we can add more fields as needed
[22:33:14] <SWPLinux> you could change the "END" to NULL and check for a null pointer - it may be easier
[22:33:52] <fenn> i was just scrolling up when irssi crashed.. dunno
[22:34:38] <jmkasunich2_> duh, yeah
[22:34:45] <jmkasunich2_> python has rotted my brain
[22:34:50] <SWPLinux> two additional fields would do it, which I'll add if need be. first a function pointer, and second a void pointer for a data struct containing any information needed for the programming function
[22:34:52] <SWPLinux> heh
[22:36:38] <SWPLinux> so the prototype for a programming function is int programfunc(bit_data *the_config, void *other_info)
[22:36:52] <SWPLinux> and other_info gets cast to the correct struct type in the function
[22:37:27] <jmkasunich2_> static int programfpga(int devnum, struct bitfile_chunk *ch);
[22:37:32] <jmkasunich2_> thats what it is now
[22:37:36] <jmkasunich2_> I want to change as little as needed
[22:38:09] <SWPadnos> ok. I'd just add a struct opinter for a struct that would contain all those other defines: BUSY_BIT, DONE_BIT ...
[22:38:11] <SWPadnos> pointer
[22:38:37] <SWPadnos> those change depending on the programming method, which is why the pointer needs to be void
[22:39:05] <SWPadnos> the control register is at a different offset in the 5i22 than it is in the 5i20
[22:39:15] <jmkasunich2_> patience
[22:39:26] <jmkasunich2_> you are getting ahead of me, I'm still doing PCI detection
[22:39:28] <SWPadnos> I'm patient (and thankful you're working on this right now :) )
[22:39:32] <SWPadnos> oops - sorry
[22:39:37] <SWPadnos> I'll go configure RTAI now
[22:40:09] <SWPLinux> I foolishly stuck a SATA drive in this PC, and it seems the cradek SMP kernel doesn't have SATA support in it (or it's something else)
[22:40:21] <jmkasunich2_> hmm
[22:40:26] <jmkasunich2_> might be something else
[22:40:52] <jmkasunich2_> I think I used that kernel on this machine, which has (only) a SATA drive
[22:40:56] <SWPLinux> well, I had that kernel booting on this PC with a different hard drive, so that was the first thing that sprang to mind
[22:41:00] <SWPLinux> ok
[22:41:06] <jmkasunich2_> I _think_
[22:41:18] <jmkasunich2_> I might have been testing that kernel on my other, older SMP box
[22:41:26] <jmkasunich2_> this was before the workshop, I don't recall the details now
[22:41:32] <jmkasunich2_> but I thought it was the core2
[22:41:41] <SWPLinux> you did try it on the core2
[22:41:44] <jmkasunich2_> remember my "load up one core" experiemnts
[22:41:45] <SWPLinux> yes
[22:41:49] <SWPLinux> same here
[22:42:53] <SWPLinux> I have a theory (probably a bad one) as to why that works. I think it prevents the other core from filling the cache with junk
[22:43:17] <SWPLinux> I believe the core 2 duo uses a unified L2 (or L3) cache
[22:43:31] <SWPLinux> hmmm. maybe not, come to think of it
[22:53:34] <jmkasunich2_> looks like detection works (at least it can't find a 5i22 and it can find a 5i20)
[22:53:47] <SWPLinux> ok. I can try it here if you like
[22:54:02] <jmkasunich2_> got a few more steps before I want to commit
[22:54:08] <SWPLinux> ok
[22:55:45] <SWPLinux> yep - no SATA Support in this config
[22:56:01] <SWPLinux> which is weird, because I do remember you testing on your core2 machine
[22:56:19] <jmkasunich2_> has cradek rebuilt it since then?
[22:56:48] <SWPLinux> could be. this is kernel 2.6.20, not 2.6.17
[23:22:51] <jmkasunich2_> SWPLinux: for now at least, I'm not putting a data pointer into the struct
[23:23:08] <jmkasunich2_> it can't really be a void pointer if we want to initialise it at compile time anyway
[23:23:56] <jmkasunich2_> the two "program_fpga" functions will be different and use different data values anyway, so they can continue to use #defined values for now
[23:24:33] <jmkasunich2_> I _am_ passing the address of the main board_info struct to the program_fpga function
[23:44:05] <jmkasunich2_> SWPLinux: have fun
[23:44:12] <jmkasunich2_> I'
[23:44:20] <jmkasunich2_> I'm off to get some groceries, back in a bit
[23:55:58] <SWPadnos> ok - thanks (sorry - got sidetracked into a conversation with the wife)