**** BEGIN LOGGING AT Wed Jan 25 02:59:57 2006
Jan 25 09:48:51 <[g2]> any GUI / XML users in here ?
Jan 25 10:46:32 <velinp> ~seen ka6sox
Jan 25 10:46:42 <purl> ka6sox <n=ka6sox@nslu2-linux/ka6sox> was last seen on IRC in channel #openjtag, 11h 13m 15s ago, saying: 'nite beewoolie :)'.
Jan 25 10:47:33 <velinp> ~seen lennert
Jan 25 10:47:35 <purl> lennert is currently on #openjtag (12h 10m 35s). Has said a total of 1 messages. Is idling for 10h 33m 38s, last said: 'beewoolie: hi and bye :)'.
Jan 25 11:22:18 <lennert> i'm here
Jan 25 12:04:57 <beewoolie-afk> I built ep1220's board yesterday.
Jan 25 12:05:10 <beewoolie-afk> Plugged it in, a.k.a 'the smoke test'.
Jan 25 12:05:22 <beewoolie-afk> Bus 002 Device 004: ID 0403:6010 Future Technology Devices International, Ltd 
Jan 25 12:05:27 <beewoolie-afk> That's a good sign :-)
Jan 25 12:07:10 <beewoolie-afk> Unfortunately, I forgot to buy headers for making ribbon cables.
Jan 25 13:56:30 <ka6sox-office> beewoolie-afk, w00hoo
Jan 25 13:56:38 <beewoolie-afk> ka6sox-office: hey.
Jan 25 13:56:49 <ka6sox-office> ya
Jan 25 13:57:03 <beewoolie-afk> I've given up on te arm7 stuff for a while.  It looks like there may be something fishy with the scan chains on the chips I have.
Jan 25 13:57:14 <ka6sox-office> ah...
Jan 25 13:57:22 <beewoolie-afk> I'm starting on the Xscale tomorrow.
Jan 25 13:57:28 <ka6sox-office> AchiestDragon finished a pretty good S3 board design...
Jan 25 13:57:39 <beewoolie-afk> I soldered up another slug with a jtag port.  It gets easier every time.
Jan 25 13:57:46 <ka6sox-office> a few are looking it over and then we will finalize it.
Jan 25 13:57:50 <beewoolie-afk> w00t
Jan 25 13:58:46 <vmaster> beewoolie-afk: what arm7s did you try?
Jan 25 13:59:02 <beewoolie-afk> vmaster: I only have the Sharp parts, lh79520 lh79524.
Jan 25 13:59:13 <beewoolie-afk> What's wierd is the scan chain 1 is only 33 bits long.
Jan 25 13:59:18 <vmaster> yeah
Jan 25 13:59:23 <beewoolie-afk> Their BSDL files are really borked, too.
Jan 25 13:59:40 <vmaster> scan-chain 1 is supposed to be 33 bits on a arm7
Jan 25 13:59:43 <beewoolie-afk> It says that the instructions are only three bits long, but I can show that the register is 4 bits long.
Jan 25 13:59:52 <beewoolie-afk> vmaster: ...hang on...
Jan 25 14:00:13 <beewoolie-afk> Oh, right.  That wasn't what didn't work.  The CP15 register was shorted than expected.
Jan 25 14:00:24 <beewoolie-afk> It is documented as being 32+4 bits, IIRC. 
Jan 25 14:00:30 <beewoolie-afk> It is reading out as 33 bits long.
Jan 25 14:00:39 <vmaster> yeah, 33 bits is correct
Jan 25 14:00:59 <vmaster> 32-bits data/instruction plus one bit that says if it's D or I
Jan 25 14:01:00 <beewoolie-afk> Really?  Not according to the 720T datasheet I was reading...
Jan 25 14:01:11 <beewoolie-afk> For the CP15 register?
Jan 25 14:01:13 <vmaster> yes
Jan 25 14:01:57 <vmaster> regarding the instruction register size: there's usually a difference between bsdl mode and jtag mode
Jan 25 14:01:57 <[g2]> when you guys get a minute I'd like to ask the brain trust a question
Jan 25 14:02:13 <beewoolie-afk> Page 9-25 of the arm ddI0229a says 37 bits.
Jan 25 14:02:43 <beewoolie-afk> Scan chain 15 has a read/write bit, instruction encoding bits 3:0 and data bust bits 31:0
Jan 25 14:03:03 <beewoolie-afk> vmaster: I'm looking at the JTAG scan chain documentation.
Jan 25 14:03:18 <vmaster> the LH's are hard-core, not -S
Jan 25 14:03:27 <beewoolie-afk> Yeah.
Jan 25 14:03:39 <vmaster> ddi0229a is for the revision 4, using the -s core
Jan 25 14:03:44 <beewoolie-afk> Hmm.
Jan 25 14:04:08 <beewoolie-afk> How can you tell from the document?
Jan 25 14:04:32 <vmaster> 1.1 About the ARM720t processor
Jan 25 14:04:33 <beewoolie-afk> Oh, there it is.
Jan 25 14:05:00 <beewoolie-afk> Unfortunately, Sharp doesn't point to the correct data sheet for their processor.
Jan 25 14:05:08 <beewoolie-afk> I have to hunt until I find one that works.
Jan 25 14:05:17 <vmaster> DDI0192A
Jan 25 14:05:19 <beewoolie-afk> In fact, I'm guessing that they don't use the -S core.
Jan 25 14:06:48 <beewoolie-afk> vmaster: thanks.
Jan 25 14:07:54 <vmaster> np
Jan 25 14:09:42 <beewoolie-afk> Hey look at that.  All of the numbers match up now.  :-o
Jan 25 14:09:46 <vmaster> ah, the lh79520 tec datasheet explicitly mentions that it has a arm720t rev3 core
Jan 25 14:10:23 <beewoolie-afk> Of course, I assumed that rev 4 was just rev 3 but better.
Jan 25 14:10:35 <beewoolie-afk> It was working for the arm9 docs, for the most part.
Jan 25 14:11:09 <beewoolie-afk> I think that once I found that their BSDL file was bogus, I assumed that everything was suspect.
Jan 25 14:11:35 <beewoolie-afk> Even their published IDCODE is wrong. 
Jan 25 14:11:56 <vmaster> mhh, for the atmel parts, the bsdl doesn't describe the debug port at all - a pin decides on startup if the jtag port comes up as bsdl (bsdl file matches) or debug
Jan 25 14:12:30 <ka6sox-office> vmaster: is this information in a wiki somewhere?
Jan 25 14:12:34 <beewoolie-afk> [g2]: do you still have a Q?
Jan 25 14:12:40 <[g2]> beewoolie-afk I do
Jan 25 14:12:52 <[g2]> this is for all
Jan 25 14:13:35 <[g2]> I'm curious if you guys are interested in some high-level form of the processor specific information
Jan 25 14:13:57 <[g2]> example, I'd like to start playing with the IXP42x memory controller for the CS0/CS1
Jan 25 14:14:06 <[g2]> or pull all the CP 15 registers out
Jan 25 14:15:12 <[g2]> getting a dump in a text/script friendly way (like the VxWorks ICE tool) or having a GUI makes sense to me for manipulating these values
Jan 25 14:15:21 <[g2]> GPIO values are another example
Jan 25 14:15:28 <[g2]> Thoughts ?
Jan 25 14:16:18 <ka6sox-office> I'm just used to the way that the BDI2000 does it 
Jan 25 14:16:33 <ka6sox-office> its a telnet session.
Jan 25 14:16:41 <ka6sox-office> so a gui would be nice.
Jan 25 14:19:23 <[g2]> ka6sox-office you could use a sript within the telnet session
Jan 25 14:19:47 <ka6sox-office> yep
Jan 25 14:20:34 <beewoolie> Scripting telnet is dicey
Jan 25 14:20:41 <beewoolie> The interfaces change and the code no longer works.
Jan 25 14:21:01 <[g2]> I'd like to start pulling out all the CP15 info which includes Endianness and cache setup
Jan 25 14:21:02 <beewoolie> Are you talking about a UBE solution, or something to make the final products work well?
Jan 25 14:21:11 <beewoolie> For what purpose?
Jan 25 14:21:34 <[g2]> beewoolie to me there's one big abstraction
Jan 25 14:21:41 <[g2]> it's just a IXP425 part
Jan 25 14:21:51 <[g2]> with a given rev level
Jan 25 14:21:52 <beewoolie> And your only connection to it is JTAG?
Jan 25 14:22:09 <[g2]> no JTAG is just one view
Jan 25 14:22:23 <beewoolie> Then I don't follow.
Jan 25 14:22:42 <beewoolie> From what I've seen so far, I don't see why you couldn't use a spreadsheet.
Jan 25 14:23:38 <[g2]> you can cut and paste spread sheet in scripts
Jan 25 14:23:51 <[g2]> beewoolie are you familiar with WinView at all ?
Jan 25 14:24:01 <beewoolie> Nope.
Jan 25 14:24:18 <[g2]> They've got a scripting capability
Jan 25 14:24:36 <[g2]> so basically you can attach the JTAG connector and run the script
Jan 25 14:24:45 <[g2]> the script does stuff like
Jan 25 14:25:01 <[g2]> proc.cp15.foo=0x....
Jan 25 14:25:15 <[g2]> proc.memctrl.cs0=0x....
Jan 25 14:25:29 <[g2]> and all the names and values can be aliased
Jan 25 14:25:45 <[g2]> it can also dump the values out
Jan 25 14:26:15 <[g2]> so you can set them up and play with them in the GUI then save the snapshot of the proper values
Jan 25 14:26:34 <[g2]> does that make any sense ?
Jan 25 14:27:22 <[g2]> maybe the tools named WindICE
Jan 25 14:27:35 <beewoolie> So, the idea would be to allow any serial text interface to control a remote JTAG box...or whatever.
Jan 25 14:27:51 <beewoolie> It makes a little sense, though I don't see where you are going.
Jan 25 14:28:12 <beewoolie> You could write this particular tool to use a BDI2000 for the time being.  It's just a front-end on Expect.
Jan 25 14:28:22 <beewoolie> perhaps with a little regex parsing built in.
Jan 25 14:28:48 <[g2]> well the backend could be JTAG for board bring up
Jan 25 14:28:55 <[g2]> or live SW on a running board
Jan 25 14:29:10 <[g2]> just mmap the structures and pull / push values
Jan 25 14:29:15 <beewoolie> These sorts of solutions are prone to failure given that the UI designers don't care to keep their output consistent.
Jan 25 14:29:32 <beewoolie> Sure.  That is a reasonable way to use the JTAG hardwar.
Jan 25 14:29:50 <[g2]> well the UI should be driven by the meta language and the understanding of the part
Jan 25 14:29:51 <beewoolie> It would make more sense to regularize the access methods so that there is on-going backward compatibility.
Jan 25 14:30:02 <beewoolie> Easier said than done.
Jan 25 14:30:43 <beewoolie> Breakage at this level is very frustrating to users who live in the M$ dialog boxes and scroll-bar universe.
Jan 25 14:30:54 <beewoolie> All they see is that their wookey is broken.
Jan 25 14:31:10 <[g2]> this is all part specific
Jan 25 14:31:18 <beewoolie> They don't understand regex's and they eschew knowledge of command lines.
Jan 25 14:31:36 <beewoolie> Actually, it's specific to the way that the information is gathered.
Jan 25 14:31:57 <beewoolie> If you are engineering both the UI and the JTAG port, then there is no problem.  In fact, a text parser isn't really the right solution.
Jan 25 14:32:19 <beewoolie> If you control the backend, it is more efficient and reliable to compose a simple protocol.
Jan 25 14:32:28 <beewoolie> SNMP is one such protocol, though I am not recommending it.
Jan 25 14:32:34 <beewoolie> key=value.
Jan 25 14:32:46 <beewoolie> key? returns the value.
Jan 25 14:33:02 <beewoolie> Then it's a matter of defining a key space as well as value encodings.
Jan 25 14:33:22 <[g2]> I'm quite familair with SNMP and that's totally the wrong place to go
Jan 25 14:33:46 <[g2]> key=value is the same this as proc.mm.cs0=foo
Jan 25 14:35:05 <beewoolie> Right.  But you were talking about JTAG being only one backend.
Jan 25 14:35:15 <ka6sox-office> BDM
Jan 25 14:35:20 <ka6sox-office> used on PPC
Jan 25 14:35:31 <vmaster> okay, then name the backend "debugger"
Jan 25 14:35:37 <beewoolie> I guess I don't understand what the question is.
Jan 25 14:35:40 <ka6sox-office> ya
Jan 25 14:35:43 <vmaster> whatever the low-end connection is
Jan 25 14:36:04 <ka6sox-office> JTAG/BDM/BDI whatever they want to call it.
Jan 25 14:36:54 <beewoolie> Once you start with attempting to support these other devices, you run afoul with compatibility.
Jan 25 14:36:55 <vmaster> is there another use of this, aside from debugging?
Jan 25 14:38:13 <ka6sox-office> for BDM/BDI not really
Jan 25 14:38:19 <ka6sox-office> JTAG of course
Jan 25 14:38:34 <vmaster> mhh, no, "this" was refering to g2's idea
Jan 25 14:38:42 <ka6sox-office> oh.
Jan 25 14:38:57 <vmaster> an abstract notation of target "registers"
Jan 25 14:39:02 <ka6sox-office> verification of a manufactured board.
Jan 25 14:40:00 <vmaster> okay, but that again would be in the context of debugging - you somehow halt the target, put it into a debug mode, and ask it about the content of these registers, or set some of them
Jan 25 14:40:45 <[g2]> vmaster you could do some of this live
Jan 25 14:41:02 <ka6sox-office> with BDM/BDI the target is running
Jan 25 14:41:04 <vmaster> heh, yeah, you could, but is it also something you would do
Jan 25 14:41:11 <vmaster> okay, leave it running
Jan 25 14:41:20 <vmaster> but it's outside of the normal use of the target
Jan 25 14:41:21 <[g2]> also for automated vector generation intimate knowledge of the parts/layout is required
Jan 25 14:42:14 <[g2]> vmaster in a PPC environment it's quite common to have the BDM/JTAG cable _always_ connected to the target
Jan 25 14:43:10 <[g2]> at one company we put OS abstractions of the C++ kernel into the debugger
Jan 25 14:43:28 <[g2]> allowing the debugger to understand the OS processes and runtime
Jan 25 14:43:51 <vmaster> ah, lauterbach offers something like that, right?
Jan 25 14:44:04 <[g2]> dunno, this was in-house
Jan 25 14:44:29 * [g2] wonders why he has a tendancy towards scratch :)
Jan 25 14:44:45 <[g2]> s/scratch/from scratch/
Jan 25 14:45:14 <[g2]> hmm I guess purl couldn't handle that one
Jan 25 14:45:27 <ka6sox-office> doesnt' seem like it
Jan 25 14:47:37 <[g2-lap]> he's a little peek at what I was talking about http://www.windriver.com/products/development_tools/debuggers_emulators/visionclick/visionCLICK_DS.pdf
Jan 25 14:47:57 <[g2]> note to comment about the "record and playback"
Jan 25 14:48:09 <[g2]> and different pictures of the internal views
Jan 25 15:06:46 * beewoolie still doesn't understand the question.
Jan 25 16:53:00 <[g2]> beewoolie ping
Jan 25 16:53:09 <beewoolie> [g2]: yo
Jan 25 16:53:25 <[g2]> you were playing with IDE drivers a little while ago right ?
Jan 25 16:53:43 <beewoolie> I've written a few
Jan 25 16:53:46 <[g2]> s/playing/wrote/
Jan 25 16:53:46 <purl> [g2] meant: you were wrote with IDE drivers a little while ago right ?
Jan 25 16:54:16 <[g2]> I've got an interesting situation with the CF/IDE driver for the Loft
Jan 25 16:54:37 <beewoolie> In the Linux kernel?
Jan 25 16:54:43 <[g2]> yeah
Jan 25 16:54:48 <[g2]> there's a little patch
Jan 25 16:54:59 <[g2]> but my problem now is in the kernel
Jan 25 16:55:18 <beewoolie> How do you know you have a problem?
Jan 25 16:55:27 <[g2]> here's now
Jan 25 16:55:31 <[g2]> here's how
Jan 25 16:56:02 <[g2]> For BE it works fine with the IDE probe but the data was byte swapped
Jan 25 16:56:28 <[g2]> so a simple byte swapping of the 16Byte data fixes the problem for BE and all is well
Jan 25 16:56:40 <[g2]> I can boot to the device, mount it all is happy
Jan 25 16:57:03 <[g2]> However, in LE the device gets an error on the IDE probe
Jan 25 16:57:13 <[g2]> same hardware, same kernel, just LE
Jan 25 16:57:19 <[g2]> same sw
Jan 25 16:57:22 <beewoolie> Sounds like the 'patch' is broken.
Jan 25 16:57:41 <[g2]> this is in the generic part of the kernel
Jan 25 16:57:55 <[g2]> there's no patch there
Jan 25 16:57:59 <beewoolie> All IDE drivers go through a low-level portion that is target specific.
Jan 25 16:58:10 <[g2]> right
Jan 25 16:58:22 <[g2]> the functions are setup by the init
Jan 25 16:58:37 <beewoolie> Is this all on 2.6.15?
Jan 25 16:58:41 <[g2]> yep
Jan 25 16:59:13 <beewoolie> What is the defconfig?
Jan 25 16:59:33 <[g2]> I can e-mail or pastebin
Jan 25 16:59:41 <beewoolie> Pastebin is OK.
Jan 25 17:02:41 <[g2-lap]> http://pastebin.ca/38619
Jan 25 17:04:15 <[g2]> AH...
Jan 25 17:09:31 <beewoolie> I don't see how this can work on the loft.  There is no setup for your target.
Jan 25 17:09:57 <[g2]> MACH_LOFT
Jan 25 17:10:08 <beewoolie> drivers/ide/Kconfig
Jan 25 17:10:12 <beewoolie> drivers/ide/arm/Kconfig
Jan 25 17:10:26 <[g2]> I've got a patch
Jan 25 17:10:43 <beewoolie> So it isn't in the kernel tree.
Jan 25 17:11:14 <[g2]> the code that has the issue is in the kernel tree
Jan 25 17:11:21 <[g2]> the patch is against 2.6.15
Jan 25 17:11:29 <beewoolie> Yeah, but the IDE code works.  The problem is in the patch.
Jan 25 17:11:54 <[g2]> very true, but it works BE and doesn't LE
Jan 25 17:12:13 <beewoolie> and the patch probably makes a BE assumption.
Jan 25 17:12:14 <[g2]> I'm trying to understand why/how this is happening
Jan 25 17:12:25 <beewoolie> The IDE interface is really dumb.
Jan 25 17:12:31 <[g2]> I know
Jan 25 17:12:41 <beewoolie> It has all sorts of goofy bits that make drivers difficult to write.
Jan 25 17:13:03 <beewoolie> It swaps bytes, it has 8 bit registers even when someone needs to read/write 8 bits.
Jan 25 17:13:25 <beewoolie> It's got several methods for accessing the same status info as well as the data being read/written.
Jan 25 17:13:29 <beewoolie> It's hokey.
Jan 25 17:13:46 <beewoolie> Moreover, it's very vulnerable to differences in the bus access modes.
Jan 25 17:14:18 <beewoolie> so, just because the driver gives an error in the IDE code, doesn't mean that the problem didn't originate in the access routines.
Jan 25 17:14:46 <[g2]> right I'm just trying to understand where the error is occurring
Jan 25 17:15:09 <[g2]> I know an end failure point as it's probing the drive
Jan 25 17:15:11 <[g2]> and it fails
Jan 25 17:15:31 <[g2]> but it could be bad all the way from the first access (and probably is)
Jan 25 17:15:33 <beewoolie> So, it's probably reading the status incorrectly.
Jan 25 17:16:12 <beewoolie> It's not too hard to verify this from APEX, for example, because you can read the registers and check that the right bits are coming out.
Jan 25 17:16:32 <[g2]> well it's LE
Jan 25 17:16:38 <beewoolie> APEX builds LE.
Jan 25 17:16:40 <[g2]> so Reboot is BE
Jan 25 17:17:04 <[g2]> we don't have a IXP425 Loft port for APEX yet
Jan 25 17:17:13 <beewoolie> :-)
Jan 25 17:17:23 <beewoolie> edboot can read the registers, too.
Jan 25 17:17:29 <beewoolie> How are you booting this thing?
Jan 25 17:17:37 <[g2]> I've got a Redboot
Jan 25 17:17:47 <beewoolie> There are commands to read from memory.
Jan 25 17:17:55 <[g2]> I'd actually love to put APEX on there in LE
Jan 25 17:18:11 <beewoolie> One test to perform is to read out the registers and look for the appropriate status values.
Jan 25 17:19:35 <[g2]> does APEX support IDE ?
Jan 25 17:19:50 <beewoolie> Sure does.
Jan 25 17:19:59 <beewoolie> There is a CF driver.
Jan 25 17:20:11 <[g2]> you run in PIO mode ?
Jan 25 17:20:13 <beewoolie> It may need some tweaking on the ixp target.
Jan 25 17:20:20 <beewoolie> Yeah.  I have no interrupt/DMA capabilities.
Jan 25 17:20:35 <[g2]> this has int capability
Jan 25 17:20:41 <[g2]> but no DMA
Jan 25 17:21:01 <beewoolie> Sure.  APEX supports interrupts now, but I don't have much reason to use it.  I think I implemented a timer interrupt for grins.
Jan 25 17:22:42 <[g2]> Hmmmm this plot really thickens
Jan 25 17:22:58 <[g2]> To APEX or not to APEX
Jan 25 17:23:15 <beewoolie> One thing at a time.
Jan 25 17:23:18 <beewoolie> Let's look at the patch.
Jan 25 17:31:30 <[g2]> beewoolie I was going to send you the patch for the LE verison
Jan 25 17:31:58 <[g2]> since I added the byteswap to the BE version and that works, I was going to build the LE version with the same patch
Jan 25 17:32:12 <[g2]> and see if I get the identical failure
Jan 25 17:46:24 <[g2]> ok same deal
Jan 25 17:48:16 <[g2]> beewoolie e-mail you the patch
Jan 25 17:48:47 <[g2-lap]> same failure
Jan 25 17:48:50 <[g2-lap]> hda: probing with STATUS(0x00) instead of ALTSTATUS(0x0a)
Jan 25 17:48:50 <[g2-lap]> hda: probing with STATUS(0xa1) instead of ALTSTATUS(0x0a)
Jan 25 17:49:56 <[g2-lap]> which is the line in drivers/ide/ide-probe.c
Jan 25 18:01:13 <beewoolie> [g2-lap]: that message isn't an error
Jan 25 18:01:20 <beewoolie> It's normal for CF ide.
Jan 25 18:02:05 <beewoolie> IIRC, that message occurs because the CF interface cannot perform byte reads.
Jan 25 18:02:42 <[g2]> beewoolie I don't get the message on BE and it works
Jan 25 18:03:04 <beewoolie> I get that message on all of the Sharp targets and they work fine.
Jan 25 18:03:10 <beewoolie> That may be a red herring.
Jan 25 18:04:37 <[g2]> well the probe fails and no IRQ is assigned
Jan 25 18:05:09 <ka6sox-office> [g2] I've seen that on something else that had CF only.
Jan 25 18:05:50 <beewoolie> [g2]: Just because the door-bell rings and you drop a glass on the floor doesn't mean that the doorbell breaks glasses.  :-)
Jan 25 18:06:52 <[g2-lap]> hda: probing with STATUS(0x00) instead of ALTSTATUS(0x0a)
Jan 25 18:06:55 <[g2-lap]> hda: probing with STATUS(0xa1) instead of ALTSTATUS(0x0a)
Jan 25 18:06:55 <[g2-lap]> hda: no response (status = 0xa1), resetting drive
Jan 25 18:06:55 <beewoolie> [g2]: I need to spend a little more time with this to make sure of what I might proclaim.
Jan 25 18:06:59 <[g2]> that's the next line
Jan 25 18:07:05 <beewoolie> BTW, who wrote the patch?
Jan 25 18:07:50 <[g2]> it's an adapted patch by th GW kernel guy
Jan 25 18:08:40 <beewoolie> OK.  I'll keep my mouth shut until I can read it.
Jan 25 18:20:52 <[g2]> beewoolie are the latest APEX changes for IXP42x up on your site ?
Jan 25 18:29:35 <beewoolie> [g2]: Yeah.  The last code changes have been posted.
Jan 25 18:34:40 <[g2]> cool
Jan 25 18:35:33 <[g2]> beewoolie I'll take a shot at modifying it to support the Loft/Intel/Avila boards
Jan 25 18:35:52 <beewoolie> Excellent.
Jan 25 18:36:16 <[g2]> I'll leave the CF/IDE out to start
Jan 25 18:36:46 <[g2]> and IAL/CSR/OSAL networking of course
Jan 25 18:37:52 <[g2]> so it should be pretty straight forward
Jan 25 18:42:37 <beewoolie> [g2]: The CF driver isn't really that hard.
Jan 25 18:42:44 <beewoolie> It's only got a couple of parameters.
Jan 25 18:43:15 <[g2]> beewoolie so it'll be really easy to add then :)
Jan 25 18:43:34 <beewoolie> Yeah.  There is a header to be defined in the mach-directory.
Jan 25 18:43:43 <beewoolie> It may need some hacking to get it right for the target.
Jan 25 18:44:00 <beewoolie> For example, there is nothing having to do endian-ness right now.
Jan 26 00:18:06 <ka6sox> lennert: ping
Jan 26 00:18:19 <ka6sox> email failed to send to you...(big files)
**** ENDING LOGGING AT Thu Jan 26 02:59:57 2006