**** BEGIN LOGGING AT Tue Oct 31 02:59:57 2006
Oct 31 10:27:06 <vmaster> nbd: http://mmd.ath.cx/openocd/OpenOCD.XScale_branch.r108-1.diff
Oct 31 10:27:54 <vmaster> there are additional opcodes that get loaded into the mini-Icache which are dynamically generated by the OpenOCD, this patch fixes them, too (still needs the debug_handler_be.bin changed)
Oct 31 10:28:01 <nbd> thanks. will try it now
Oct 31 10:30:05 <nbd> same result
Oct 31 10:30:21 <nbd> should i try to restart the board?
Oct 31 10:31:10 <nbd> or do you want another logfile?
Oct 31 10:31:21 <vmaster> another logfile would be nice
Oct 31 10:31:30 <nbd> no problem
Oct 31 10:32:06 <vmaster> do you have any way of seeing whether the board is running?
Oct 31 10:32:30 <vmaster> i.e. executing the original bootloader code
Oct 31 10:33:27 <nbd> i can hook up the serial console
Oct 31 10:36:32 <nbd> i restarted the board, made sure the boot loader was running
Oct 31 10:36:33 <vmaster> doh, sorry
Oct 31 10:36:36 <nbd> then fired up openocd
Oct 31 10:36:41 <nbd> and it wrote a single . on the console
Oct 31 10:36:43 <nbd> and locked up
Oct 31 10:37:05 <vmaster> in the config file i gave you
Oct 31 10:37:17 <vmaster> change the little to big
Oct 31 10:37:32 <nbd> oh :)
Oct 31 10:37:56 <vmaster> but the console output is good, it shows us that the reset handling is working
Oct 31 10:38:23 <nbd> still loops. i'll make another logfile
Oct 31 10:40:00 <nbd> sent
Oct 31 10:44:07 <vmaster> ok, handling different endiannesses is a mess in the current xscale code
Oct 31 10:44:20 <vmaster> i'll have to clean this up a bit, before further tests make any sense
Oct 31 10:44:27 <nbd> ok
Oct 31 10:44:39 <nbd> no problem, just let me know when you have something new :)
Oct 31 10:47:42 <vmaster> yeah, i'll ping you
Oct 31 11:08:30 <vmaster> hum, guess noone ever used the openocd with a big-endian target... after evaluating the target line, endianness is hardcoded to little
Oct 31 11:10:27 <vmaster> nbd: in target/target.c, remove line 910 (*last_target_p->endiannes = ...)
Oct 31 11:10:51 <nbd> ok
Oct 31 11:12:34 <nbd> loops again. making another logfile
Oct 31 11:14:15 <nbd> sent
Oct 31 11:14:26 <vmaster> okay, thanks
Oct 31 11:21:49 <[g2]> vmaster which version of RedBoot are you running ?
Oct 31 11:22:26 <[g2]> s/vmaster/nbd/
Oct 31 11:22:26 <purl> [g2] meant: nbd which version of RedBoot are you running ?
Oct 31 11:22:27 <[g2]> :)
Oct 31 11:22:39 <nbd> none, currently
Oct 31 11:22:54 <nbd> still have rgloader on that thing
Oct 31 11:22:59 <[g2]> heh.. Oh yeah that's the reason for this exercise :)
Oct 31 11:23:29 <nbd> btw. nice bot that you have here :)
Oct 31 11:23:39 <[g2]> it's riker's
Oct 31 11:24:10 <[g2]> I think he logs this, #openslug and #nslu2-linux
Oct 31 11:24:20 <[g2]> and like 40 other channels :)
Oct 31 11:24:24 <nbd> :)
Oct 31 11:25:19 <[g2]> nbd the other option is to code up the 3 line shim that puts the box in LE mode, and then loop forever
Oct 31 11:25:28 <[g2]> then the box would be in LE mode :)
Oct 31 11:26:13 <[g2]> nbd btw I booted a BE kernel last nige
Oct 31 11:26:22 <[g2]> s/nige/night/
Oct 31 11:26:23 <purl> [g2] meant: nbd btw I booted a BE kernel last night
Oct 31 11:26:57 * [g2] note to self ping dwery about the microcode loader
Oct 31 11:32:44 <vmaster> nbd: was there an output on the serial console?
Oct 31 11:32:51 <nbd> just the .
Oct 31 11:33:35 <vmaster> would be nice if you could step through xscale_deassert_reset, and monitor the serial console
Oct 31 11:34:01 <nbd> with gdb?
Oct 31 11:34:04 <vmaster> yeah
Oct 31 11:34:14 <nbd> ok, need to figure out how to do that
Oct 31 11:34:22 <nbd> i never used a debugger for anything :)
Oct 31 11:34:36 <vmaster> configure with: CFLAGS="-O0 -g -Wall" ./configure --enable-parport
Oct 31 11:34:49 <vmaster> then compile again
Oct 31 11:34:51 <nbd> k
Oct 31 11:35:29 <vmaster> then (sudo) gdb ./openocd
Oct 31 11:35:35 <vmaster> in src/
Oct 31 11:35:45 <vmaster> break xscale_deassert_reset
Oct 31 11:35:48 <[g2]> nbd is a real man, printk's/printf's and an ocilliscope
Oct 31 11:36:34 <vmaster> run -f ixp425_lat.cfg -d
Oct 31 11:36:54 <vmaster> hehe
Oct 31 11:37:41 <nbd> i always do printk debugging when porting kernels to a board :)
Oct 31 11:38:42 <nbd> got the breakpoint
Oct 31 11:38:52 <vmaster> anything up to this point on the console?
Oct 31 11:39:03 <nbd> the . is already there
Oct 31 11:39:06 <nbd> boot loader is still running
Oct 31 11:39:13 <vmaster> it is running atm?
Oct 31 11:39:20 <nbd> yes
Oct 31 11:39:35 <vmaster> can you measure nSRST?
Oct 31 11:40:04 <nbd> ok, just need to look for the pinout of the jtag port
Oct 31 11:40:24 <vmaster> is it a 20-pin header?
Oct 31 11:40:30 <nbd> yes
Oct 31 11:42:02 <vmaster> pin 15
Oct 31 11:42:38 <nbd> 2.2V
Oct 31 11:43:09 <vmaster> hum, it is /supposed/ to be low at this point
Oct 31 11:43:21 <vmaster> but guess 2.2v qualifies as a high...?
Oct 31 11:43:27 <nbd> some other pins are 3.3
Oct 31 11:44:00 <nbd> so 2.2 might be low
Oct 31 11:44:35 <vmaster> can you measure pin3, too? (nTRST)
Oct 31 11:46:00 <[g2]> nbd the truth is that for 99% of the cases printk's are fine
Oct 31 11:46:26 <[g2]> it's really only bootloader and tricky device issue where a debugger comes in handy
Oct 31 11:46:36 <[g2]> and some threaded apps
Oct 31 11:47:36 * [g2] does love hw breakpoint and single stepping through bootloader when available
Oct 31 11:48:19 <[g2]> or an oscope on the memory bus :)
Oct 31 11:48:34 <[g2]> but it's been like a decade since that
Oct 31 11:48:59 <vmaster> heh, you'll have a hard time with your oscope on a bga ddr2 chip
Oct 31 11:49:23 <[g2]> that's what mictor connectors are for :)
Oct 31 11:49:32 <nbd> interesting, the trst pin is almost at 0
Oct 31 11:49:54 <vmaster> there's definitely a problem with the reset line
Oct 31 11:49:59 <vmaster> the target MUST be in reset at this point
Oct 31 11:50:12 <vmaster> i'll get myself something for lunch, bbiab
Oct 31 11:50:20 <[g2]> vmaster have a great lunch
Oct 31 11:50:21 <nbd> so it's a problem with my cable?
Oct 31 11:50:29 <vmaster> when you comment the target line, you can work low-level with the jtag
Oct 31 11:50:42 <vmaster> jtag_reset allows you to toggle the lines
Oct 31 11:51:02 <vmaster> nbd: probably
Oct 31 11:51:08 <nbd> ok, i'll check my cable
Oct 31 12:20:47 <nbd> vmaster: ok. i checked. it's not a problem with my cable, because openwince can set that pin to high
Oct 31 12:23:24 <vmaster> ok, can you show me how you're setting that pin in in openwince? guess you've used the current cvs code?
Oct 31 12:24:24 <nbd> i used some fork of it
Oct 31 12:24:37 <nbd> probably based on the current cvs
Oct 31 12:24:43 <nbd> i'll check the code
Oct 31 12:25:46 <nbd> the lattice_set_trst function simply does this:
Oct 31 12:25:46 <nbd>         return parport_set_data( cable->port, trst << TRST );
Oct 31 12:25:55 <nbd> and TRST is defined to 4
Oct 31 12:27:04 <vmaster> okay, but we're talking about SRST
Oct 31 12:27:37 <nbd> the last one you told me to measure was trst
Oct 31 12:28:50 <vmaster> ok, sorry, let's start over again:
Oct 31 12:29:21 <vmaster> there are two reset inputs, nTRST (keeps the JTAG state machine and debug stuff in reset), and nSRST (keeps the processor in reset, but lets you work with the debug facilities)
Oct 31 12:30:52 <nbd> you're right, srst does seem to be broken
Oct 31 12:30:55 * vmaster checks his reset lines at the beginning of xscale_deassert_reset
Oct 31 12:31:15 <nbd> the 2.2V came from the board
Oct 31 12:33:17 <vmaster> hum, okay
Oct 31 12:33:25 <vmaster> the wrv54g is based on some other board, right?
Oct 31 12:33:34 <nbd> i don't know
Oct 31 12:34:44 <vmaster> uhm, hope i didn't mix this up - what board do you have? a wrv54g?
Oct 31 12:35:30 <nbd> wrv54g compatible, gemtek
Oct 31 12:35:44 <nbd> it's not being sold anywhere, so i don't know the real model
Oct 31 12:36:24 <vmaster> linux kconfig talks about gemtek wx5715
Oct 31 12:36:35 <vmaster> as the board being used inside the wrv54g
Oct 31 12:37:43 <vmaster> ok, to debug an xscale core, we need to be able to toggle both reset lines individually
Oct 31 12:38:09 <vmaster> first, both lines are asserted (low), then ntrst gets lifted, and we start downloading code into the mini icache
Oct 31 12:39:04 <vmaster> uh, actually, ntrst gets lifted, then we write some jtag register so nsrst is left asserted internally, lift nsrst, and then download the code
Oct 31 12:39:58 <vmaster> with the lattice cable, the openocd writes D3=0 for a low level on nSRST, and D3=1 for a high level
Oct 31 12:41:40 <vmaster> if this doesn't work, all further steps are bound to fail
Oct 31 12:41:40 <nbd> hmm... i just checked with the datasheet of the hex buffer chip in the jtag cable
Oct 31 12:41:50 <vmaster> is it something home-made?
Oct 31 12:41:54 <nbd> no
Oct 31 12:42:05 <nbd> it does look like it's wired up correctly
Oct 31 12:42:26 <vmaster> ok, try commenting out the target line in the .cfg
Oct 31 12:42:35 <vmaster> then telnet to port localhost port 4444
Oct 31 12:42:41 <vmaster> well, run the openocd, then telnet
Oct 31 12:44:59 <nbd> on the other hand, i mean shouldn't the cable pull down the srst line if it's disabled?
Oct 31 12:45:16 <nbd> i mean it isn't supposed to be on 2.2V, right?
Oct 31 12:47:08 <vmaster> it's supposed to be 0V at the beginning of xscale_deassert_reset
Oct 31 12:47:16 <vmaster> i measured 0.1 on my PXA250 board
Oct 31 12:47:54 <vmaster> how's nSRST routed on your cable, through the hex buffer?
Oct 31 12:48:20 <nbd> yes
Oct 31 12:48:49 <nbd> do you think i should try to bypass the hex buffer for this pin?
Oct 31 12:49:03 <nbd> i could solder a wire on there
Oct 31 12:49:13 <vmaster> no, nSRST is supposed to be open-drain
Oct 31 12:49:39 <vmaster> but directly driving it high/low should work, too
Oct 31 12:50:15 <nbd> so what should i try?
Oct 31 12:51:29 <nbd> if i disconnect the srst line and measure it against ground, i get 0V
Oct 31 12:51:36 <vmaster> on the board?
Oct 31 12:51:40 <vmaster> or on the cable?
Oct 31 12:51:43 <nbd> on the cable
Oct 31 12:51:46 <nbd> on the board it's 2.2V
Oct 31 12:52:03 <vmaster> 2.2v with the cable disconnected?
Oct 31 12:52:06 <nbd> yes
Oct 31 12:55:40 <vmaster> i'll see what my board looks like, hold on
Oct 31 13:03:27 <vmaster> it's plain 3.3v while the board is running
Oct 31 13:03:34 <vmaster> with nothing connected
Oct 31 13:04:01 <vmaster> you don't happen to know if there's a power/reset supervisor on that board?
Oct 31 13:04:07 <vmaster> or rather which one there is
Oct 31 13:04:25 <nbd> now mine is also 3.3V
Oct 31 13:04:42 <nbd> i don't know
Oct 31 13:05:24 <vmaster> is there a series resistor on the srst line of your cable? after the hex-buffer?
Oct 31 13:05:56 <nbd> yes
Oct 31 13:06:38 <nbd> there's a resistor after every output of the hex-buffer
Oct 31 13:11:23 <nbd> i need to go and grab some food now
Oct 31 13:11:26 <nbd> will be back soon
Oct 31 13:49:00 <vmaster> nbd: when you're back, lets try driving the reset signals manually
Oct 31 13:53:57 <nbd> ok, i'm back
Oct 31 13:54:29 <vmaster> ok, comment out the target line in the .cfg, connect the interface, and launch the openocd
Oct 31 13:55:09 <nbd> ok
Oct 31 13:55:15 <nbd> Warning: gdb_server.c:1326 gdb_init(): no gdb ports allocated as no target has been specified
Oct 31 13:56:05 <vmaster> yeah, that's fine
Oct 31 13:56:11 <vmaster> now telnet to localhost port 4444
Oct 31 13:56:24 <nbd> ok
Oct 31 13:56:28 <vmaster> endstate rti
Oct 31 13:56:35 <vmaster> irscan 0 0x7e
Oct 31 13:56:37 <vmaster> var id 32
Oct 31 13:56:40 <vmaster> drscan 0 id
Oct 31 13:56:42 <vmaster> var id
Oct 31 13:57:09 <nbd> id (1 fields):
Oct 31 13:57:09 <nbd> 0x9277013 (/32)
Oct 31 13:57:40 <vmaster> ok, that's the ixp425's JTAG ID
Oct 31 13:57:59 <vmaster> jtag_reset 1 0
Oct 31 13:58:20 <vmaster> and then measure pin 3 (ntrst)
Oct 31 13:58:26 <vmaster> should be close to 0v
Oct 31 13:58:43 <nbd> but it says trst: 1 and srst: 0
Oct 31 13:58:43 <vmaster> pin 15 (nsrst) /should/ be 3.3v
Oct 31 13:59:04 <vmaster> yeah, the 1 means "asserted"
Oct 31 13:59:09 <nbd> ok
Oct 31 13:59:11 <nbd> measuring
Oct 31 13:59:13 <vmaster> it's a bit misleading
Oct 31 13:59:41 <nbd> yep. trst is close to 0 and srst is close to 3.3
Oct 31 13:59:49 <vmaster> jtag_reset 0 0
Oct 31 13:59:53 <vmaster> both should be 3.3
Oct 31 14:00:26 <nbd> yep
Oct 31 14:00:30 <vmaster> jtag_reset 0 1
Oct 31 14:00:44 <vmaster> what do you measure on pin 15?
Oct 31 14:00:58 <nbd> 2.2
Oct 31 14:01:12 <vmaster> is the board running?
Oct 31 14:01:15 <vmaster> bootloader?
Oct 31 14:01:30 <nbd> need to try again because it crashed while trying to boot the image
Oct 31 14:02:11 <nbd> restarted it. should i only run the last jtag_reset command again?
Oct 31 14:02:20 <vmaster> yeah
Oct 31 14:02:32 <nbd> boot loader is still running
Oct 31 14:03:34 <vmaster> ok, you can quit the openocd
Oct 31 14:05:24 <nbd> so srst is not working?
Oct 31 14:05:35 <vmaster> nope...
Oct 31 14:05:47 <nbd> could it be that they moved it somewhere else on this board?
Oct 31 14:06:15 <vmaster> i'm not an electronics guy, but connecting an 100ohms resistor between nSRST and GND should pull the line low while preventing a short circuit, right?
Oct 31 14:06:41 <nbd> i'm also not an electronics guy, but i think that'd to the trick
Oct 31 14:06:50 <nbd> but i just tried that and it didn't stop the boot loader
Oct 31 14:07:13 <lennert> i'd use a resistor in the kohm range, but yes
Oct 31 14:08:13 <vmaster> is there a reset button on the board?
Oct 31 14:08:13 <lennert> 100 ohm at 5V will make 50 mA flow
Oct 31 14:08:20 <nbd> yes, there is a button
Oct 31 14:08:59 <nbd> but i think it's just gpio
Oct 31 14:09:03 <nbd> doesn't do anything when i press it
Oct 31 14:10:39 <vmaster> ok
Oct 31 14:10:58 <vmaster> brb
Oct 31 14:21:09 <vmaster> ok, i guess the board is using a reset supervisor with totem-pole outputs, but they have the jtag nsrst directly connected to the RST_N
Oct 31 14:21:40 <nbd> there's a place on the board where a resistor could fit in that is connected to the reset on one side and gnd on the other
Oct 31 14:21:52 <nbd> does that mean anything?
Oct 31 14:22:41 <vmaster> does your board look similar to this: http://bilder.fliegl.de/misc/2004-03-05-wlan/p403050915.jpg ?
Oct 31 14:23:18 <nbd> a few components are different, but the board layout is the same
Oct 31 14:24:02 <vmaster> ok, so you're talking about R134 or R137?
Oct 31 14:24:42 <nbd> 137
Oct 31 14:26:57 <vmaster> i think they followed the IXDP425 reference design
Oct 31 14:27:18 <vmaster> they have several resistors not fitted to allow the jtag signals to be pulled up or down
Oct 31 14:28:35 <vmaster> but that wouldn't affect your problem
Oct 31 14:56:40 <vmaster> nbd: maybe if you could identify the reset supervisor used on the board we could work around this problem
Oct 31 14:57:59 <nbd> how?
Oct 31 15:03:49 <vmaster> ok, on my board, there's a reset supervisor with totem-pole output, too, but they have a reset input connected to the input of the supervisor
Oct 31 15:08:47 <nbd> can it be the 74lv320?
Oct 31 15:09:02 <nbd> (philips)
Oct 31 15:10:35 <nbd> oh, 32D, not 320
Oct 31 15:11:12 <nbd> description says quad 2-input OR gate
Oct 31 15:12:26 <vmaster> is that chip somehow connected to nSRST?
Oct 31 15:13:15 <nbd> yes, but it's not the only one
Oct 31 15:13:19 <nbd> let me check the other one
Oct 31 15:14:07 <nbd> the other one's a 74LVD8D
Oct 31 15:14:42 <nbd> btw. SRST is connected to an output of the or gate that i mentioned first
Oct 31 15:15:15 <nbd> hmm... DBD, not D8D - this stuff is hard to read
Oct 31 15:15:35 <nbd> or is it 8? i don't know
Oct 31 15:15:46 <nbd> anyway, that's the other chip. let me check if there are more
Oct 31 15:16:50 <nbd> there are lots of chips that look like that 
Oct 31 15:16:58 <nbd> and some of the other ones seem to be connected too
Oct 31 15:18:36 <nbd> could it be that this or gate is pulling the reset up?
Oct 31 15:19:31 <vmaster> yeah, i think so
Oct 31 15:19:41 <vmaster> that could explain the 2.2v
Oct 31 15:19:47 <nbd> do you want me to follow the or gate to see where it gets its input from?
Oct 31 15:20:19 <vmaster> there are two inputs for that output, would be nice if you could track them dow
Oct 31 15:20:24 <vmaster> s/dow/down/
Oct 31 15:20:24 <purl> vmaster meant: there are two inputs for that output, would be nice if you could track them down
Oct 31 15:20:43 <nbd> ok
Oct 31 15:22:17 <nbd> pretty hard to track
Oct 31 15:25:29 <nbd> one input is connected to the output
Oct 31 15:25:41 <nbd> does that make sense?
Oct 31 15:26:17 * vmaster not an electronics guy
Oct 31 15:26:22 <vmaster> but i'd say no...
Oct 31 15:26:54 <vmaster> are you using a multimeter that beeps on a connection?
Oct 31 15:27:27 <vmaster> mhh, an input of the same or, or of another or?
Oct 31 15:27:40 <vmaster> there are 4 two-input ors in that chip
Oct 31 15:30:59 <nbd> yes, i'm using a beeping multimeter
Oct 31 15:31:07 <nbd> i haven't identified the other chip yet
Oct 31 15:31:20 <vmaster> it's a AND gate
Oct 31 15:31:21 <nbd> but as far as i can trace the lines, the input of the first one goes somewhere near the cpu
Oct 31 15:31:26 <vmaster> 74LV08D
Oct 31 15:31:32 <nbd> ah
Oct 31 15:32:06 <nbd> i'll check if it goes to an input or an output
Oct 31 15:32:18 <vmaster> a few centimeters away from those two chips
Oct 31 15:32:27 <vmaster> Q2 and Q10
Oct 31 15:32:31 <vmaster> can you identify those?
Oct 31 15:32:51 <vmaster> can't read the markings on the picture
Oct 31 15:32:54 <nbd> it's an input (on the and chip)
Oct 31 15:33:16 <nbd> where are q2 and q10?
Oct 31 15:33:25 <vmaster> on the opposite side of the large voltage regulator
Oct 31 15:33:53 <nbd> ah, there
Oct 31 15:33:58 <vmaster> one of them is a philips, too
Oct 31 15:34:38 <nbd> q2 is RT9202
Oct 31 15:34:43 <nbd> CS5KGOH
Oct 31 15:35:07 <nbd> q10 is PHKD6N2
Oct 31 15:35:19 <nbd> D3076
Oct 31 15:35:30 <lennert> CS5KGOH sounds like some C2H5OH variant
Oct 31 15:35:50 <vmaster> q2 is a DC-DC converter, not what we're looking for
Oct 31 15:38:07 <nbd> btw. the line that i traced from the or seems to disappear under the flash chip and then go to the cpu
Oct 31 15:38:14 <nbd> because there are no resistors or anything, i can't verify that
Oct 31 15:40:55 <vmaster> there are two small chips below the flash chip
Oct 31 15:43:52 <nbd> no match there
Oct 31 15:44:27 <nbd> btw. are you going to be at the 23c3?
Oct 31 15:45:27 <vmaster> no, never been to a ccc
Oct 31 15:45:34 <vmaster> and i don't think I'll make it this year
Oct 31 15:49:28 <lennert> fosdem 2007?
Oct 31 15:50:24 <vmaster> i'd like to, but i'm not sure if my university is going to sponsor me again
Oct 31 16:09:11 <lennert> fosdem don't sponsor speakers?
Oct 31 16:09:21 <lennert> what does it cost you to get there?
Oct 31 16:16:13 <vmaster> guess around 300 euro
Oct 31 16:30:35 <vmaster> heh, going by plane would be only half that money
Oct 31 17:50:20 <prpplague> vmaster: ??
Oct 31 17:51:33 <vmaster> 17:31 < lennert> what does it cost you to get there?
Oct 31 17:51:33 <vmaster> 17:38 < vmaster> guess around 300 euro
Oct 31 17:51:33 <vmaster> 17:47 -!- prpplague [n=billybob@69.73.233.40] has joined #openjtag
Oct 31 17:51:55 <vmaster> if that's what you're refering to
Oct 31 17:52:44 <prpplague> ahh
Oct 31 17:53:26 <prpplague> vmaster: thought maybe you were refering to my impending move to the states
Oct 31 17:53:47 <vmaster> heh, no, guess i wouldn't want to know how much something like this costs
Oct 31 18:51:43 <nbd> vmaster: btw. is there anything else i could check on this xscale board or should i give up for now?
Nov 01 00:03:53 <vmaster> nbd: i don't think that the or gate is the only reset circuit on the board
Nov 01 00:04:39 <vmaster> the nslu2 for example has an EM6325
Nov 01 00:05:17 <vmaster> my board has a ti tlc7733
Nov 01 00:05:29 <vmaster> there should be something similar on the wrv54g, too
Nov 01 00:06:21 <nbd> is there any way to recognize it other than trying to trace all the lines again?
Nov 01 00:07:24 <vmaster> try to identify all chips in 8-pin packages
Nov 01 00:07:34 <vmaster> this might also be a power supervisor chip
Nov 01 00:08:41 <vmaster> the rt9202 was a dc-dc converter, but i haven't found the other one
Nov 01 00:08:42 <vmaster> 16:57 < nbd> q10 is PHKD6N2
Nov 01 00:08:42 <vmaster> 16:57 < nbd> D3076
Nov 01 00:10:09 <vmaster> knowing where the two inputs to the nor go would help, too, but it'll be tricky tracking them down
Nov 01 00:10:14 <vmaster> s/nor/or/
Nov 01 00:10:15 <purl> vmaster meant: knowing where the two inputs to the or go would help, too, but it'll be tricky tracking them down
Nov 01 00:12:19 <vmaster> i'm going to bed, night
Nov 01 00:17:22 <nbd> good night
**** ENDING LOGGING AT Wed Nov 01 02:59:57 2006