| 01:37.36 | [g2] | beewoolie-afk around ? |
| 01:37.45 | beewoolie-afk | Yep |
| 01:37.54 | beewoolie-afk | Back to squashing bugs |
| 01:38.00 | [g2] | you mentioned something about the CF/IDE ? |
| 01:38.06 | beewoolie-afk | Oh, yeah. |
| 01:38.06 | [g2] | bug squashing is good |
| 01:38.19 | beewoolie-afk | I am pretty convinced that the driver is in error. |
| 01:38.28 | beewoolie-afk | It looks a lot like my driver. :-) |
| 01:38.36 | [g2] | heh |
| 01:38.50 | beewoolie-afk | For one thing, it has the same error that my driver used to have. |
| 01:39.05 | beewoolie-afk | There was something wrong with the handling of the register indices. |
| 01:39.13 | beewoolie-afk | The ALTSTATUS message comes from that problem. |
| 01:39.24 | beewoolie-afk | I only just fixed it when I was looking for another problem recently. |
| 01:39.42 | beewoolie-afk | This is about the CF driver source that you send me some time ago. |
| 01:39.51 | [g2] | yeah I'm with you |
| 01:39.53 | beewoolie-afk | IIRC, it was a big-ending/little-ending oddity. |
| 01:39.58 | [g2] | the odd thing is the BE works |
| 01:40.12 | [g2] | right but the LE didn't |
| 01:40.32 | 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. |
| 01:40.44 | beewoolie-afk | My driver has some special code for this. |
| 01:40.58 | beewoolie-afk | Do you get the ALTSTATUS message in BE mode? |
| 01:41.18 | [g2] | lemme check |
| 01:41.24 | [g2] | it's a different message iiirc |
| 01:45.38 | *** join/#openjtag [g2-lap] (n=g2@cpe-066-057-008-035.nc.res.rr.com) |
| 01:46.19 | [g2-lap] | ide: Gateworks Avila IDE/CF driver v1.3 |
| 01:46.19 | [g2-lap] | hda: probing with STATUS(0x50) instead of ALTSTATUS(0x0a) |
| 01:46.19 | [g2-lap] | hda: HMS360402D5CF00, CFA DISK drive |
| 01:46.33 | beewoolie-afk | Yeah, that's the one. |
| 01:46.33 | [g2-lap] | I think it's returning the 0x50 instead of 0x0 |
| 01:46.46 | [g2-lap] | that's the working one on BE |
| 01:46.53 | beewoolie-afk | The important part is that it is having problems finding the status registers. |
| 01:47.07 | beewoolie-afk | The fix, for me, was to initialize correctly. |
| 01:47.23 | [g2-lap] | ah |
| 01:47.31 | [g2-lap] | so you are saying this is limping along |
| 01:47.36 | beewoolie-afk | The thing is that the driver can work without it. |
| 01:47.40 | [g2-lap] | and LE is just busted |
| 01:47.41 | beewoolie-afk | Mine did. |
| 01:48.51 | beewoolie-afk | the IDE_CONTROL_OFFSET must point to the control register. I my case, I'm using an offset of 0x206 |
| 01:49.13 | beewoolie-afk | No. |
| 01:49.28 | beewoolie-afk | I'm using 0xe, the location of the alt status register. |
| 01:50.45 | beewoolie-afk | I'm looking for the code you sent me... |
| 01:51.10 | [g2-lap] | I can e-mail you the latest |
| 01:51.42 | beewoolie-afk | I've still got a copy. |
| 01:52.12 | beewoolie-afk | Your driver uses 0x1e which *could* be right, but I doubt it based on the message from the kernel. |
| 01:52.23 | beewoolie-afk | Actually, there is more to this story. |
| 01:53.59 | beewoolie-afk | The other place where this comes into play is the use of the SELECT register. |
| 01:54.16 | beewoolie-afk | It isn't possible to write a byte in our configurations. |
| 01:54.30 | beewoolie-afk | So, writing a byte to the select register is a serious problem. |
| 01:54.37 | beewoolie-afk | I hacked the IDE code to work around this. |
| 01:54.58 | beewoolie-afk | I changed the SELECT_DRIVE call. |
| 01:55.43 | [g2] | I sent you the latest which probably just has 4 swabs in it |
| 02:01.34 | beewoolie-afk | You shouldn't need to do that. The external bus doesn't change when you go be to le. |
| 02:01.44 | beewoolie-afk | It's only the order of multiple reads. |
| 02:02.11 | [g2] | well it doesn't work otherwise |
| 02:02.24 | beewoolie-afk | So, are you saying that it's fixed? |
| 02:02.43 | [g2] | I'm saying the I'm running BE fine with that code |
| 02:02.50 | beewoolie-afk | The one thing that I hadn't considered is whether or not you have an 8 bit external bus. |
| 02:03.08 | [g2] | they switch between 8 and 16 |
| 02:03.20 | beewoolie-afk | Huh? The change the memory controller on the fly? |
| 02:03.26 | [g2] | ypu |
| 02:03.28 | [g2] | yup |
| 02:03.28 | beewoolie-afk | s/The/They/ |
| 02:03.40 | beewoolie-afk | Oh. That's one solution. |
| 02:04.03 | [g2] | now I don't think they are locking out I/O which is probably a _bad_ idea |
| 02:04.16 | beewoolie-afk | They're better off leaving it in 8 bit mode. It should make the code simpler. |
| 02:04.37 | [g2] | yeah but performance is already miserable |
| 02:04.50 | [g2] | to the CF/IDE intf |
| 02:04.55 | [g2] | i'ts like 800KB |
| 02:05.09 | beewoolie-afk | That's what it does. |
| 02:05.17 | [g2] | versus 15MB+ to the USB |
| 02:05.39 | [g2] | well that's what it currently does |
| 02:05.41 | 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. |
| 02:05.49 | beewoolie-afk | It won't ever be fast. |
| 02:05.53 | [g2] | I haven't cranked up the chip select timing |
| 02:05.55 | beewoolie-afk | But it would be nice if it were reliable. |
| 02:06.20 | [g2] | it's pretty reliable |
| 02:06.51 | beewoolie-afk | Not in le. |
| 02:07.13 | [g2] | well having never worked is called not working in LE :) |
| 02:07.26 | beewoolie-afk | :=) |
| 02:07.33 | [g2] | as opposed to worked sometimes in LE |
| 02:07.44 | *** join/#openjtag ByronT (n=byron-po@nslu2-linux/ByronT) |
| 02:07.44 | [g2] | it's binary right now |
| 02:07.50 | [g2] | BE == works |
| 02:07.53 | [g2] | LE == broke |
| 02:08.02 | beewoolie-afk | A car that never runs is often called unreliable. |
| 02:08.11 | beewoolie-afk | Just ask my cousin. |
| 02:08.14 | [g2] | only by the salesman |
| 02:12.55 | [g2] | Ok we may be fine on the CS |
| 02:13.33 | 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. |
| 02:13.43 | beewoolie-afk | You can do this in the inb/outb sorts of macros. |
| 02:14.25 | [g2] | Ok I think we are fine on the CS |
| 02:14.32 | [g2] | as we are using CS1 |
| 02:14.45 | [g2] | so it's all local to this driver |
| 02:23.43 | [g2] | beewoolie-afk are the IDE regs all 1 Byte big ? |
| 02:23.54 | beewoolie-afk | Sort of. |
| 02:24.07 | beewoolie-afk | the spec is that there are 16 bytes of registers. |
| 02:24.17 | beewoolie-afk | Some can be read as a pair, as a word. |
| 02:24.31 | beewoolie-afk | They assume that we have byte IO capability, tho. |
| 02:25.13 | [g2] | are the reg defs around somewhere ? |
| 02:26.06 | beewoolie-afk | I have a printed copy of the spec. Let me see if I can find a reference. |
| 02:26.17 | [g2] | cause I'd think the IDE_CONTROL offset woud be at 0xe not 1e |
| 02:26.29 | beewoolie-afk | That's usually the case. |
| 02:26.32 | [g2] | unless that added regs |
| 02:26.36 | beewoolie-afk | It depends on how things are wired. |
| 02:26.43 | beewoolie-afk | They may be aliases. |
| 02:26.51 | [g2] | right |
| 02:27.11 | [g2] | and me be the issue |
| 02:27.26 | [g2] | s/me/may/ |
| 02:28.15 | [g2] | maybe this is why LE isn't working |
| 02:28.33 | [g2] | the data is going out the EXP bus swapped |
| 02:29.24 | beewoolie-afk | That would be odd, I think. |
| 02:29.33 | beewoolie-afk | The be/le thing isn't supposed to matter that way. |
| 02:29.39 | beewoolie-afk | You can tell by reading the registers. |
| 02:29.47 | beewoolie-afk | I just dump the whole bank and look at them. |
| 02:29.52 | beewoolie-afk | It should be obvious. |
| 02:30.04 | [g2] | well that's exactly what i was thinking |
| 02:30.30 | [g2] | I shoud be able to mmap the area and dump it in both cases |
| 02:30.41 | beewoolie-afk | yep |
| 02:43.56 | [g2-lap] | interesting link http://hem.passagen.se/communication/ide.html |
| 02:56.42 | [g2-lap] | beewoolie-afk you and lennert will turn me into a real hacker yet! |
| 02:56.49 | [g2-lap] | http://pastebin.ca/42015 |
| 02:57.19 | beewoolie-afk | Let me get my docs... |
| 02:58.15 | beewoolie-afk | The other question is what you get when you read shorts from this region of memory. |
| 02:58.30 | [g2] | these are all byte reads |
| 02:59.57 | beewoolie-afk | So, these reads are OK. |
| 03:00.16 | beewoolie-afk | Notice that 0x1e is a mirror of 0x0e |
| 03:00.26 | beewoolie-afk | Now, what do you get with byte reads. |
| 03:01.35 | beewoolie-afk | You can see that the card is *ready*. |
| 03:02.24 | [g2] | these are byte reads |
| 03:11.16 | [g2-lap] | Ok here are the 16s |
| 03:11.21 | [g2-lap] | http://pastebin.ca/42016 |
| 03:13.30 | beewoolie-afk | So, the problem looks like 16 it reads are in BE order. Not what I'd expect. |
| 03:13.42 | beewoolie-afk | Every 16 bit read will have to be byte swapper. |
| 03:14.09 | beewoolie-afk | 'd. |
| 03:14.24 | [g2] | which is what the latest code does |
| 03:14.50 | beewoolie-afk | The next step is to add printk's to the inw/outw routines and watch what it does. |
| 03:15.14 | beewoolie-afk | Also, you can write some commands youself and verify that the device is working. |
| 03:15.19 | beewoolie-afk | I use apex for that. |
| 03:19.07 | *** join/#openjtag andrew_redfern (n=aredfern@c-24-23-138-75.hsd1.ca.comcast.net) |
| 04:19.52 | *** join/#openjtag ChadP (n=cpage@netblock-68-183-40-134.dslextreme.com) |
| 05:48.23 | *** join/#openjtag dyoung-away (n=dyoung@nslu2-linux/dyoung) |
| 06:09.55 | *** join/#openjtag andrew_redfern (n=aredfern@c-24-23-138-75.hsd1.ca.comcast.net) |
| 07:49.00 | *** join/#openjtag _AchiestDragon (n=dave@whipy.demon.co.uk) |
| 09:31.26 | *** join/#openjtag velinp (n=velinp@c88-163.cable.netissat.bg) |
| 10:18.38 | *** join/#openjtag velinp (n=velinp@c88-163.cable.netissat.bg) |