**** BEGIN LOGGING AT Fri Feb 17 10:59:56 2006
Feb 17 13:50:39 <AchiestDragon> quote request sent off for AzTag pcb 
Feb 17 14:28:29 <vmaster> this is ridiculous - i have a pxa250 board with a "built-in wiggler" - dsub25 with buffers for 5v - but it lacks the system reset
Feb 17 14:28:58 <prpplague> cute
Feb 17 16:18:21 <beewoolie-afk> vmaster: ping
Feb 17 16:18:41 <vmaster> beewoolie-afk: pong
Feb 17 16:18:50 <beewoolie-afk> Hey.
Feb 17 16:19:12 <beewoolie-afk> I'm been evaluating performance of the FTDI2232.
Feb 17 16:19:29 <beewoolie-afk> The latency is far greater than I expected.
Feb 17 16:19:39 <vmaster> what did you expect?
Feb 17 16:19:40 <beewoolie-afk> If I send a read_low command.
Feb 17 16:19:55 <beewoolie-afk> ...it takes about a second for the result to come back.
Feb 17 16:20:07 <vmaster> huh?
Feb 17 16:20:08 <beewoolie-afk> I could read the signals with a voltmeter faster.
Feb 17 16:20:14 * ByronT_ is back after 3h49m: home!
Feb 17 16:20:28 <beewoolie-afk> Ah.  so that isn't what you've experienced.
Feb 17 16:20:42 <beewoolie-afk> Yeah.  It's really mysterious.
Feb 17 16:20:57 <vmaster> well, not sure if i ever used a read_low command
Feb 17 16:21:01 <beewoolie-afk> Have done this test?
Feb 17 16:21:04 <beewoolie-afk> Ah.
Feb 17 16:21:27 <vmaster> but latency for packets of several hundred bytes with both read and writes is usually 1-2ms
Feb 17 16:21:37 <beewoolie-afk> OK.  I have code that can perform the same startup and query on several cores.
Feb 17 16:21:51 <beewoolie-afk> It is much slower with the FTDI2232 than with the parallel port adapters.
Feb 17 16:22:19 <beewoolie-afk> I wonder if it has to do with the device's method for handling smaller transactions.
Feb 17 16:22:37 <beewoolie-afk> Or, and this is why I ask, is there some sort of latency setting other than the 'latency timer'.
Feb 17 16:23:06 <vmaster> my oberservations are that the latency timer has little or zero effect
Feb 17 16:23:16 <beewoolie-afk> That's what I saw as well.
Feb 17 16:23:35 <vmaster> heh, you
Feb 17 16:23:37 <vmaster> 're a day late
Feb 17 16:23:43 <vmaster> i could have asked ftdi yesterday
Feb 17 16:23:48 <beewoolie-afk> Doh!
Feb 17 16:24:04 <vmaster> they were at the emb. world in nuremberg
Feb 17 16:24:05 <beewoolie-afk> I had a job interview yesterday, so there wasn't anything I could do.
Feb 17 16:24:35 <vmaster> well, how small are your transactions?
Feb 17 16:24:41 <prpplague> beewoolie-afk: job interview?
Feb 17 16:24:55 <beewoolie-afk>  0x80 0xd0 0xdb  something like that.
Feb 17 16:25:02 <beewoolie-afk> prpplague: Yesterday.
Feb 17 16:25:12 <vmaster> that kills performance, because of usb
Feb 17 16:25:21 <vmaster> this is transmitted as it's own packet
Feb 17 16:25:23 <prpplague> beewoolie-afk: thought you were an independent contractor
Feb 17 16:25:36 <beewoolie-afk> prpplague: baby needs new shoes.
Feb 17 16:25:53 <beewoolie-afk> vmaster: that's what the latency is about.
Feb 17 16:26:05 <beewoolie-afk> But I don't get why a single packet round trip takes so long.
Feb 17 16:26:27 <vmaster> i'll see what this takes on my system
Feb 17 16:26:33 <beewoolie-afk> I appreciate that.
Feb 17 16:26:37 <prpplague> beewoolie-afk: ahh
Feb 17 16:26:47 <beewoolie-afk> I just want to make sure that I'm doing things correctly.
Feb 17 16:27:11 <beewoolie-afk> vmaster: The place where this comes up most clearly is when I wait for the CPU to halt.
Feb 17 16:27:34 <beewoolie-afk> I have to poll the embeddedice register until I get the response that it's halted.
Feb 17 16:27:48 <beewoolie-afk> There isn't much I can do if the latency is this high.
Feb 17 16:28:09 <beewoolie-afk> That is, there isn't much I can to do improve performance with this kind of latency.
Feb 17 16:39:11 <beewoolie-afk> prpplague: I've been looking for work since the beginning of the year.  Just because I'm interviewing doesn't mean I'll give up on consulting.
Feb 17 16:39:20 <prpplague> beewoolie-afk: ahh
Feb 17 16:40:15 <vmaster> beewoolie-afk: writing one "set low
Feb 17 16:40:26 <vmaster> " and reading back "get low" takes 4 ms
Feb 17 16:40:36 <beewoolie-afk> Hmm.
Feb 17 16:40:46 <beewoolie-afk> Is that on Linux?
Feb 17 16:40:48 <vmaster> yeah
Feb 17 16:40:54 <vmaster> using libftdi
Feb 17 16:41:03 <beewoolie-afk> Yeah.  I used that library as well.
Feb 17 16:41:22 <vmaster> i usually use libftd2xx - gives much better performance
Feb 17 16:41:32 <beewoolie-afk> do you know why?
Feb 17 16:41:53 <vmaster> libftd2xx uses an extra thread to do concurrent reads
Feb 17 16:42:13 <vmaster> i.e. it issues a write, and already reads data back while the write blocks
Feb 17 16:42:49 <vmaster> but that only matters when you're pushing to the limits of the chips, with writes of > 700 or so bytes
Feb 17 16:43:27 <beewoolie-afk> I've been mulling over that sort of stuff.
Feb 17 16:43:39 <beewoolie-afk> It seems like a pair of threads would do the job.
Feb 17 16:45:04 <vmaster> http://mmd.ath.cx/usbjtag.c - my test bed code, the last pair of write-read is the set/get low byte commands
Feb 17 16:47:02 <beewoolie-afk> Let me see how it performs for me.
Feb 17 16:48:09 <beewoolie-afk> Hmm.  You have a different product.
Feb 17 16:48:26 <vmaster> yeah, it's the pid of amontec's jtagkey
Feb 17 16:48:32 <vmaster> just change it back to the default
Feb 17 16:49:27 <beewoolie-afk> runs fine.  Let me do some investigation.
Feb 17 16:49:53 <beewoolie-afk> ...I wonder if it is my divisor....
Feb 17 16:53:48 <beewoolie-afk> Nope.
Feb 17 17:53:59 <beewoolie-afk> Good grief.  I'm a total bonehead.
Feb 17 17:55:27 <ka6sox> beewoolie-afk, you can't be...that title is reserved for me!
Feb 17 17:55:37 <beewoolie-afk> You'll have to share.
Feb 17 17:55:56 <beewoolie-afk> I don't know exactly when, but I must have fixed a real problem some time ago.
Feb 17 17:56:07 <beewoolie-afk> I had a delay in my test routine which is...1 second.
Feb 17 17:56:14 <beewoolie-afk> DOH
Feb 17 17:56:27 <ka6sox> that would do it!
Feb 17 17:56:37 <ka6sox> been there, done that, got the T-Shirt.
Feb 17 17:56:47 <beewoolie-afk> I was having latency problems originally, but I think I must have solved that issue some time ago.
Feb 17 18:11:54 <vmaster> hehehe
Feb 17 20:32:52 <[g2]> hey beewoolie-afk 
Feb 17 20:32:58 <beewoolie-afk> [g2]: hey
Feb 17 20:33:07 <[g2]> I was gonna call GW
Feb 17 20:33:37 <[g2]> Are you around of a couple minuts ?
Feb 17 20:33:44 <beewoolie-afk> Yeah.
Feb 17 20:33:54 <beewoolie-afk> I'm on the telephone but should be done soon.
Feb 17 20:33:57 <[g2]> ok I'll try and get an update
Feb 18 01:35:45 <[g2]> beewoolie-afk around ?
Feb 18 01:35:54 <beewoolie-afk> Yep
Feb 18 01:36:03 <beewoolie-afk> Back to squashing bugs
Feb 18 01:36:09 <[g2]> you mentioned something about the CF/IDE ?
Feb 18 01:36:15 <beewoolie-afk> Oh, yeah.
Feb 18 01:36:15 <[g2]> bug squashing is good
Feb 18 01:36:28 <beewoolie-afk> I am pretty convinced that the driver is in error.
Feb 18 01:36:37 <beewoolie-afk> It looks a lot like my driver.  :-)
Feb 18 01:36:45 <[g2]> heh
Feb 18 01:36:59 <beewoolie-afk> For one thing, it has the same error that my driver used to have.
Feb 18 01:37:15 <beewoolie-afk> There was something wrong with the handling of the register indices.
Feb 18 01:37:23 <beewoolie-afk> The ALTSTATUS message comes from that problem.
Feb 18 01:37:33 <beewoolie-afk> I only just fixed it when I was looking for another problem recently.
Feb 18 01:37:51 <beewoolie-afk> This is about the CF driver source that you send me some time ago.
Feb 18 01:38:00 <[g2]> yeah I'm with you
Feb 18 01:38:02 <beewoolie-afk> IIRC, it was a big-ending/little-ending oddity.
Feb 18 01:38:07 <[g2]> the odd thing is the BE works
Feb 18 01:38:21 <[g2]> right but the LE didn't
Feb 18 01:38:42 <beewoolie-afk> So, one of the important things to get right is the fact that we cannot access the command register when using the normal status register for status.
Feb 18 01:38:54 <beewoolie-afk> My driver has some special code for this.
Feb 18 01:39:08 <beewoolie-afk> Do you get the ALTSTATUS message in BE mode?
Feb 18 01:39:27 <[g2]> lemme check
Feb 18 01:39:34 <[g2]> it's a different message iiirc
Feb 18 01:39:42 * beewoolie-afk wonders
Feb 18 01:44:28 <[g2-lap]> ide: Gateworks Avila IDE/CF driver v1.3
Feb 18 01:44:28 <[g2-lap]> hda: probing with STATUS(0x50) instead of ALTSTATUS(0x0a)
Feb 18 01:44:28 <[g2-lap]> hda: HMS360402D5CF00, CFA DISK drive
Feb 18 01:44:42 <beewoolie-afk> Yeah, that's the one.
Feb 18 01:44:43 <[g2-lap]> I think it's returning the 0x50 instead of 0x0
Feb 18 01:44:55 <[g2-lap]> that's the working one on BE
Feb 18 01:45:02 <beewoolie-afk> The important part is that it is having problems finding the status registers.
Feb 18 01:45:17 <beewoolie-afk> The fix, for me, was to initialize correctly.
Feb 18 01:45:32 <[g2-lap]> ah
Feb 18 01:45:41 <[g2-lap]> so you are saying this is limping along
Feb 18 01:45:46 <beewoolie-afk> The thing is that the driver can work without it.
Feb 18 01:45:49 <[g2-lap]> and LE is just busted
Feb 18 01:45:51 <beewoolie-afk> Mine did.
Feb 18 01:47:01 <beewoolie-afk> the IDE_CONTROL_OFFSET must point to the control register.  I my case, I'm using an offset of 0x206
Feb 18 01:47:22 <beewoolie-afk> No.
Feb 18 01:47:38 <beewoolie-afk> I'm using 0xe, the location of the alt status register.
Feb 18 01:48:55 <beewoolie-afk> I'm looking for the code you sent me...
Feb 18 01:49:19 <[g2-lap]> I can e-mail you the latest
Feb 18 01:49:51 <beewoolie-afk> I've still got a copy.
Feb 18 01:50:21 <beewoolie-afk> Your driver uses 0x1e which *could* be right, but I doubt it based on the message from the kernel.
Feb 18 01:50:33 <beewoolie-afk> Actually, there is more to this story.
Feb 18 01:52:08 <beewoolie-afk> The other place where this comes into play is the use of the SELECT register.
Feb 18 01:52:25 <beewoolie-afk> It isn't possible to write a byte in our configurations.
Feb 18 01:52:39 <beewoolie-afk> So, writing a byte to the select register is a serious problem.
Feb 18 01:52:46 <beewoolie-afk> I hacked the IDE code to work around this.
Feb 18 01:53:07 <beewoolie-afk> I changed the SELECT_DRIVE call.
Feb 18 01:53:52 <[g2]> I sent you the latest which probably just has 4 swabs in it
Feb 18 01:59:43 <beewoolie-afk> You shouldn't need to do that.  The external bus doesn't change when you go be to le.
Feb 18 01:59:53 <beewoolie-afk> It's only the order of multiple reads.
Feb 18 02:00:20 <[g2]> well it doesn't work otherwise
Feb 18 02:00:33 <beewoolie-afk> So, are you saying that it's fixed?
Feb 18 02:00:52 <[g2]> I'm saying the I'm running BE fine with that code
Feb 18 02:00:59 <beewoolie-afk> The one thing that I hadn't considered is whether or not you have an 8 bit external bus.
Feb 18 02:01:17 <[g2]> they switch between 8 and 16
Feb 18 02:01:29 <beewoolie-afk> Huh?  The change the memory controller on the fly?
Feb 18 02:01:36 <[g2]> ypu
Feb 18 02:01:37 <[g2]> yup
Feb 18 02:01:37 <beewoolie-afk> s/The/They/
Feb 18 02:01:38 <purl> beewoolie-afk meant: Huh?  They change the memory controller on the fly?
Feb 18 02:01:48 <beewoolie-afk> Oh.  That's one solution.
Feb 18 02:02:12 <[g2]> now I don't think they are locking out I/O which is probably a _bad_ idea
Feb 18 02:02:25 <beewoolie-afk> They're better off leaving it in 8 bit mode.  It should make the code simpler.
Feb 18 02:02:47 <[g2]> yeah but performance is already miserable
Feb 18 02:02:59 <[g2]> to the CF/IDE intf
Feb 18 02:03:04 <[g2]> i'ts like 800KB
Feb 18 02:03:18 <beewoolie-afk> That's what it does.
Feb 18 02:03:27 <[g2]> versus 15MB+ to the USB 
Feb 18 02:03:49 <[g2]> well that's what it currently does
Feb 18 02:03:50 <beewoolie-afk> At least you don't have to interleave every IO operation to the CF with an operation to another chip select...as I do.
Feb 18 02:03:58 <beewoolie-afk> It won't ever be fast.
Feb 18 02:04:02 <[g2]> I haven't cranked up the chip select timing
Feb 18 02:04:04 <beewoolie-afk> But it would be nice if it were reliable.
Feb 18 02:04:29 <[g2]> it's pretty reliable
Feb 18 02:05:00 <beewoolie-afk> Not in le.
Feb 18 02:05:22 <[g2]> well having never worked is called not working in LE :)
Feb 18 02:05:35 <beewoolie-afk> :=)
Feb 18 02:05:42 <[g2]> as opposed to worked sometimes in LE
Feb 18 02:05:53 <[g2]> it's binary right now
Feb 18 02:05:59 <[g2]> BE == works
Feb 18 02:06:02 <[g2]> LE == broke
Feb 18 02:06:11 <beewoolie-afk> A car that never runs is often called unreliable.
Feb 18 02:06:21 <beewoolie-afk> Just ask my cousin.
Feb 18 02:06:23 <[g2]> only by the salesman
Feb 18 02:11:04 <[g2]> Ok we may be fine on the CS
Feb 18 02:11:43 <beewoolie-afk> The way I've debugged this sort of thing has been to insert lots of printk's in the driver and examine all of the IO.
Feb 18 02:11:52 <beewoolie-afk> You can do this in the inb/outb sorts of macros.
Feb 18 02:12:34 <[g2]> Ok I think we are fine on the CS
Feb 18 02:12:41 <[g2]> as we are using CS1
Feb 18 02:12:54 <[g2]> so it's all local to this driver
Feb 18 02:21:53 <[g2]> beewoolie-afk are the IDE regs all 1 Byte big ?
Feb 18 02:22:03 <beewoolie-afk> Sort of.
Feb 18 02:22:16 <beewoolie-afk> the spec is that there are 16 bytes of registers.
Feb 18 02:22:26 <beewoolie-afk> Some can be read as a pair, as a word.
Feb 18 02:22:40 <beewoolie-afk> They assume that we have byte IO capability, tho.
Feb 18 02:23:22 <[g2]> are the reg defs around somewhere ?
Feb 18 02:24:15 <beewoolie-afk> I have a printed copy of the spec.  Let me see if I can find a reference.
Feb 18 02:24:27 <[g2]> cause I'd think the IDE_CONTROL offset woud be at 0xe not 1e
Feb 18 02:24:38 <beewoolie-afk> That's usually the case.
Feb 18 02:24:41 <[g2]> unless that added regs
Feb 18 02:24:45 <beewoolie-afk> It depends on how things are wired.
Feb 18 02:24:52 <beewoolie-afk> They may be aliases.
Feb 18 02:25:00 <[g2]> right 
Feb 18 02:25:20 <[g2]> and me be the issue
Feb 18 02:25:35 <[g2]> s/me/may/
Feb 18 02:25:35 <purl> [g2] meant: and may be the issue
Feb 18 02:26:24 <[g2]> maybe this is why LE isn't working
Feb 18 02:26:42 <[g2]> the data is going out the EXP bus swapped
Feb 18 02:27:33 <beewoolie-afk> That would be odd, I think.
Feb 18 02:27:42 <beewoolie-afk> The be/le thing isn't supposed to matter that way.
Feb 18 02:27:48 <beewoolie-afk> You can tell by reading the registers.
Feb 18 02:27:56 <beewoolie-afk> I just dump the whole bank and look at them.
Feb 18 02:28:01 <beewoolie-afk> It should be obvious.
Feb 18 02:28:13 <[g2]> well that's exactly what i was thinking
Feb 18 02:28:39 <[g2]> I shoud be able to mmap the area and dump it in both cases
Feb 18 02:28:50 <beewoolie-afk> yep
Feb 18 02:42:05 <[g2-lap]> interesting link http://hem.passagen.se/communication/ide.html
Feb 18 02:54:51 <[g2-lap]> beewoolie-afk you and lennert will turn me into a real hacker yet!
Feb 18 02:54:58 <[g2-lap]> http://pastebin.ca/42015
Feb 18 02:55:28 <beewoolie-afk> Let me get my docs...
Feb 18 02:56:24 <beewoolie-afk> The other question is what you get when you read shorts from this region of memory.
Feb 18 02:56:39 <[g2]> these are all byte reads
Feb 18 02:58:06 <beewoolie-afk> So, these reads are OK.
Feb 18 02:58:25 <beewoolie-afk> Notice that 0x1e is a mirror of 0x0e
Feb 18 02:58:34 <beewoolie-afk> Now, what do you get with byte reads.
Feb 18 02:59:44 <beewoolie-afk> You can see that the card is *ready*.
Feb 18 03:00:33 <[g2]> these are byte reads
Feb 18 03:09:25 <[g2-lap]> Ok here are the 16s
Feb 18 03:09:30 <[g2-lap]> http://pastebin.ca/42016
Feb 18 03:09:34 * [g2-lap] finally get a clue
Feb 18 03:11:38 <beewoolie-afk> So, the problem looks like 16 it reads are in BE order.  Not what I'd expect.
Feb 18 03:11:51 <beewoolie-afk> Every 16 bit read will have to be byte swapper.
Feb 18 03:12:18 <beewoolie-afk> 'd.
Feb 18 03:12:33 <[g2]> which is what the latest code does
Feb 18 03:12:59 <beewoolie-afk> The next step is to add printk's to the inw/outw routines and watch what it does.
Feb 18 03:13:23 <beewoolie-afk> Also, you can write some commands youself and verify that the device is working.
Feb 18 03:13:28 <beewoolie-afk> I use apex for that.
**** ENDING LOGGING AT Sat Feb 18 10:59:56 2006