**** BEGIN LOGGING AT Wed Jan 18 03:00:03 2006 Jan 18 09:19:51 hiho+ Jan 18 09:35:45 hola Jan 18 09:46:51 hi; ka6sox: I just missed you twice; wanted to tell you about nslu2-linux #10838, as I don't know if you read the logs :). hope all is ok with your boy Jan 18 09:47:05 velinp, thanks he is much better now. Jan 18 09:47:14 I did read it and find it fascinating :) Jan 18 09:47:28 we have just missed each other in the last couple of days. Jan 18 09:48:02 ka6sox, thanks; one of my twin daughters has a similar operation years ago (strabism); she's ok now. Jan 18 09:48:41 glad to hear that too. I just have the one 4yr old. Jan 18 09:49:30 ka6sox, about the SDRAM, I contacted apex's author; he said apex's memory-test could be modified for my strange hardware setup; Jan 18 09:50:51 ka6sox, my friend has not done the hardware modification yet, so I can't play :( Jan 18 09:52:55 the APEX bootloader very nice Jan 18 09:54:03 it has started raining early here and I need to get things off the patio befor they get soaked. Jan 18 09:54:46 bbiaf Jan 18 10:06:32 back... Jan 18 10:08:11 ka6sox, wet, wet, wet :); I was reading the specs of the 32Mx16bit from icsc; they talk about A11 instead of A10 in the refresh page; know anything about it? Jan 18 10:10:58 I was looking at the Micron equiv. what is the url for the icsc part? Jan 18 10:11:28 It's at work; trying to find it (at home) Jan 18 10:12:14 okay you can send it to me when you get to work ;) Jan 18 10:13:22 a few minutes? Jan 18 10:14:33 http://www.icsi.com.tw/english/products/products-frame.asp?Title=Datasheet-DRAM&URL=http%3A//web.icsi.com.tw/English/Datasheets/DYNAMICRAM.html, SDRAM, near end of page Jan 18 10:15:27 better, http://web.icsi.com.tw/domino/packinfo.nsf/959F32AE7222A7A748256F320003C488/$FILE/42s16160new.pdf Jan 18 10:17:11 no irc at work, comany policy :(; I am looking at the PDF, page 19, Address Bits of Bank-Select and Precharge, second table; Jan 18 10:18:36 on page 21, where they explain precharge, they speak about A10; later in the timing specs, they use A10; i am confused Jan 18 10:21:15 this is confusing...since this is equivilent to the Micron part we should look at that. Jan 18 10:23:16 I have micron pdf (at work :(), didn't notice such thing; I believe it's a typo, because ~30 pages of timing diagrams all use A10 Jan 18 10:24:25 http://www.micron.com/products/dram/sdram/part.aspx?part=MT48LC16M16A2P-75 Jan 18 10:24:49 I think its a error in the ICSC part docs. Jan 18 10:24:52 it should be A10 Jan 18 10:25:46 what you say is such a relief to me :), thanks Jan 18 10:26:20 * GyrosGeier enjoys having found three bugs in Atmel's AT91RM9200 example source code Jan 18 10:26:48 (two of which are in crt0.S, which has the amazing number of 15 assemblers instructions) Jan 18 10:28:21 only 15 ASM instructions :( Jan 18 10:29:07 btw, I tried to compile APEX-1.3.13 natively, and got gcc diags about glibc/crt0 hard FP, and ...o soft FP; any help? Jan 18 10:29:58 I only know the arm5t stuff...best to ask beewoolie Jan 18 10:30:27 yeah, all it does is load the stack pointer, copy the data area from behind the code to its final place and clear the bss. Only that it writes whatever is in r0 at its invocation to an area as big as the bss area located behind the data area because it does neither init r0 nor the pointer to the bss area Jan 18 10:30:48 velinp: mostly thats due to some arguments for crosscompiling Jan 18 10:30:49 velinp, bootstrapping is a real bitch these days Jan 18 10:31:38 velinp, the problem is that you need a glibc that is either a multilib or built with the same flags as your project Jan 18 10:32:32 thanks; i did not insist compiling, because hardware must come first :) Jan 18 10:32:41 however, to build gcc you need crti.o these days, which comes from libc, which needs gcc to build Jan 18 10:33:02 ah....circular references mmmmmmm Jan 18 10:33:52 if you only need static linking, you can invoke gcc's "all-host" target, which will compile enough of gcc to build a libc Jan 18 10:33:53 yes, I have the openslug-2.7 (with gcc) on a flash disk; expect to be able to compile apex, but am a complete newbie Jan 18 10:34:45 so if you want dynamic libs, you first compile a gcc that can do C with full multilibs but static libs only, then build libc multilibs and then rebuild gcc completely. Jan 18 10:34:56 if you need gcc4 you have to build Xwindows Jan 18 10:37:17 so I am in apex-1.3.13 dir on a slug; make complains about /usr/lib/libc_nonshared.a being hard FP; gcc is debian 3.3.5 Jan 18 10:38:02 velinp: why are you wanting to build it natively? Jan 18 10:38:20 thought it was safer Jan 18 10:38:48 might try to cross-compile and come back later Jan 18 10:39:06 velinp: apex makefiles are really designed for cross-compiling Jan 18 10:39:34 velinp: in my 9 years of working with arm devices, i have never native compiled an application Jan 18 10:40:18 ok, I have a cross compiler (from monotone, before openslug-3); will try it Jan 18 10:41:15 <[g2-lap]> Hey guys you may want to take a look at this http://www.giantshoulderinc.com/projects/openjtag/openjtag.pdf Jan 18 10:41:38 * prpplague looks Jan 18 10:41:44 thanks, guys; I got more support that I can handle currently :); going into read-only :) Jan 18 10:42:02 s/that/than/ Jan 18 10:42:03 velinp meant: thanks, guys; I got more support than I can handle currently :); going into read-only :) Jan 18 10:42:03 [g2-lap]: hmm, is that klingon? Jan 18 10:42:12 prpplague, I think so Jan 18 10:42:22 <[g2-lap]> klingon ? Jan 18 10:42:32 <[g2-lap]> hey ka6sox Jan 18 10:42:39 [g2-lap]: bad joke referencing star trek Jan 18 10:42:41 its all blocks Jan 18 10:42:47 (encoding seems off) Jan 18 10:43:17 <[g2-lap]> hmm... it seems to read fine with kpdf Jan 18 10:43:30 * prpplague tries acroread Jan 18 10:44:23 readable with acroread but not xpdf Jan 18 10:44:42 xpdf works fine for me Jan 18 10:45:04 <[g2-lap]> GyrosGeier you may not like this document :( Jan 18 10:46:01 [g2-lap], not readable on a Mac with Preview Jan 18 10:46:10 trying acroread Jan 18 10:49:22 (of course I have to get acroread first :P Jan 18 10:49:33 hi [g2-lap] Jan 18 10:49:54 ka6sox: i used pdftops and then used gs to read it Jan 18 10:50:02 lol Jan 18 10:50:16 [g2-lap], well, I can live with it Jan 18 10:50:23 i couldn't find a pdf viewer at my system that didn't display it Jan 18 10:51:02 yea, somethings not right about the encoding Jan 18 10:51:13 I agree but can't put my finger on it. Jan 18 10:51:32 <[g2-lap]> I just saved as pdf with abiword Jan 18 10:51:39 [g2-lap], actually it might be a wise idea to show it to the "we don't need to support Linux, there is no market there" people so they might get an idea that having gdb stubs for our device would perhaps rule Jan 18 10:51:42 <[g2-lap]> I'm open to suggestions Jan 18 10:52:26 [g2-lap]: what was the default font you used? Jan 18 10:52:39 prpplague, this BSD machine doesn't have pdftops ;( Jan 18 10:53:16 ka6sox ahhh Jan 18 10:53:29 ka6sox might check if they did it as pdf2ps Jan 18 10:53:52 <[g2-lap]> Bitstream Vera for the heading and Times New Roman for the text Jan 18 10:54:05 weird Jan 18 10:54:06 odd those should be fine Jan 18 10:54:08 truetype fonts Jan 18 10:54:28 * [g2-lap] is new to publishing Jan 18 10:55:15 [g2-lap]: just for giggles try changing all the fonts to just plain courier Jan 18 10:55:26 [g2-lap]: then resaving it as a pdf Jan 18 10:55:37 <[g2-lap]> prpplague I can save it as a txt file Jan 18 10:55:48 hehe that would work as well Jan 18 10:56:46 <[g2-lap]> well off to lunch bbl Jan 18 10:57:33 interesting Jan 18 10:58:57 pxa270 isn't bad. Jan 18 11:00:18 <[g2-lap]> ka6sox glad you could read it Jan 18 11:01:00 acroread was able to. Jan 18 11:02:39 i hate to sound ignorant, but what is "Loft" Jan 18 11:05:22 looooooooool Jan 18 11:05:23 i know about the ballon but i've not heard of loft Jan 18 11:05:32 honestly? Jan 18 11:05:35 * prpplague googles Jan 18 11:05:45 it's the board g2 is producing Jan 18 11:05:55 he's been talking about it since i first came to this channel Jan 18 11:06:12 oh Jan 18 11:06:17 i didn't realize it had a name Jan 18 11:06:32 http://www.giantshoulderinc.com/hardware.html Jan 18 11:07:41 [g2-lap], there isn't any mention of the V3 boards. Jan 18 11:07:55 so I assume that its because they are Alpha? Jan 18 11:08:00 [g2-lap]: ok well i'm still a little confused on the direction of this Jan 18 11:08:33 [g2-lap], look at last night's logs here too,. Jan 18 11:08:59 [g2-lap]: are you wanting a board to do initial testing with? Jan 18 11:12:32 [g2-lap]: so as i understand it, you are gonna work with the info on the ballon to generate the first run of the application? Jan 18 11:45:18 time to go to the 'office' Jan 18 12:05:51 <[g2-lap]> ka6sox-office what do you mean now mention of the V3 board ? Jan 18 12:06:20 <[g2-lap]> right they won't be done until end of Q1 or early Q2 Jan 18 12:06:29 <[g2-lap]> it's wookey__ project Jan 18 12:06:42 <[g2-lap]> or he's involved significantly with it Jan 18 12:07:44 <[g2-lap]> prpplague there are two pieces Jan 18 12:07:55 <[g2-lap]> 1) a high-speed JTAG device Jan 18 12:08:36 <[g2-lap]> 2) Stuff to generate test vectors and testing for BSDL testing Jan 18 12:08:59 <[g2-lap]> You can do #2 with a low speed device it just takes forever Jan 18 12:09:06 right i got that part, just unsure what all the discusion was about an xscale arm device Jan 18 12:10:06 <[g2-lap]> I think focusing on XScale we can test both the Balloon V3 and the Loft Jan 18 12:10:46 [g2-lap]: ahh so you want to use the ballon and loft as targets for the initial development Jan 18 12:10:53 <[g2-lap]> but I think the Balloon V3 (and initally possbily V2 for the test vector generation) makes a super objective Jan 18 12:11:33 <[g2-lap]> the Loft doesn't really need it and it's not really a fully open platform from the hardware manufacturing standpoint Jan 18 12:12:08 but you need something that you can get netlist and schematics from so that you can generate the initial vector testing Jan 18 12:12:49 <[g2-lap]> right. I think we can get access to that stuff for the Balloon. Certain the V2 stuff and probably the V3. Jan 18 12:13:08 [g2-lap]: hehe, no offense, i just had a little bit of trouble following your text, but then english isn't your primary language so i would say you did a darn good job, hehe Jan 18 12:13:39 <[g2-lap]> unfortunately english is my primary language :( Jan 18 12:13:41 [g2-lap]: well its not xscale, but you could do this for the lnode80 (sharp LH79520 arm720t) Jan 18 12:13:55 [g2-lap]: oops Jan 18 12:14:00 * prpplague removes foot from mouth Jan 18 12:14:08 <[g2-lap]> it's OK Jan 18 12:14:17 <[g2-lap]> my writing _does_ need improvement Jan 18 12:14:48 [g2-lap]: i'm sure that my employer would provide some lnode80's as well as some of the other boards we have based on the s3c2410 Jan 18 12:15:06 <[g2-lap]> excellent Jan 18 12:15:46 <[g2-lap]> I think there are and will be many more companies that need this kinda capability Jan 18 12:15:59 we will be shipping a generic HG style jtag dongle with our products, however we are still looking for a high speed solution Jan 18 12:16:35 <[g2-lap]> the s3c2410 is ARM9T based right ? Jan 18 12:16:52 <[g2-lap]> I know bewoolie's all of that stuff Jan 18 12:17:42 [g2-lap]: yea arm920t Jan 18 12:17:59 yea beewoolie is mainly supporting the sharp products right now Jan 18 12:18:09 but he's pretty familiar with the range of arm stuff Jan 18 12:18:10 <[g2-lap]> that's from the sw side Jan 18 12:18:28 http://www.whipy.demon.co.uk/JTAG.PS < block diagram of last nights desussion of the pc104 high speed dongle for use with a ts7200 Jan 18 12:18:32 [g2-lap]: hehe yea, just used to dealing with software folks Jan 18 12:19:35 hi prpplague Jan 18 12:19:49 [g2-lap]: i'm trying to talk the boss into selling our first prototype development board because they are so darn "cute" Jan 18 12:20:15 AchiestDragon: greetings associate from ##mirocontrollers Jan 18 12:22:16 <[g2-lap]> AchiestDragon are you using the ts7200 ? Jan 18 12:22:23 yes Jan 18 12:22:33 <[g2-lap]> Linux, Freebsd, or other ? Jan 18 12:22:40 debian Jan 18 12:22:50 <[g2-lap]> that'd be Linux :) Jan 18 12:23:15 <[g2-lap]> are you running the 2.4 or 2.6.8.1 or other kernel ? Jan 18 12:23:23 2.4 Jan 18 12:23:34 <[g2-lap]> beewoolie-afk welcome Jan 18 12:24:06 <[g2-lap]> beewoolie-afk see http://www.giantshoulderinc.com/projects/openjtag/openjtag.pdf Jan 18 12:24:08 hey Jan 18 12:24:39 <[g2-lap]> AchiestDragon I'm also working on some toolchains/kernel stuff for the ep93xx Jan 18 12:25:01 k kool Jan 18 12:25:03 did you read the logs from yesterday? ka6sox was talking about using an arm9 board, pc104, to drive the JTAG chains Jan 18 12:25:56 beewoolie: http://www.whipy.demon.co.uk/JTAG.PS < block diagram of the pc104 high speed dongle for use with a ts7200 Jan 18 12:25:59 <[g2-lap]> actually i haven't but I think AchiestDragon pointed me to the design Jan 18 12:26:41 I made a little more progress yesterday. I'm not able to read memory on an ARMv4 target. Jan 18 12:26:47 <[g2-lap]> 1) problem with the ts7200 is that it's closed platform from the FPGA and loading process Jan 18 12:27:01 <[g2-lap]> 2) it doesn't scale Jan 18 12:27:04 it was a genaral post here for others, i just finished the block diagram Jan 18 12:27:17 <[g2-lap]> meaning lets say you want 16 or 32 devices Jan 18 12:27:34 <[g2-lap]> you have to get 16 or 32 tsboards and adapters Jan 18 12:27:57 <[g2-lap]> where if you've got a USB 2.0 to FPGA, just plug them into a hub Jan 18 12:28:29 <[g2-lap]> So a Loft with 2 4-port hubs could support 8 devices out of the box Jan 18 12:28:32 the pc104 board is to be desinged so that it will work with any pc104 sbc , the ts7100 just has the i/o needed and fits nicely in the cost equasion Jan 18 12:28:42 how much is the ts7200? Jan 18 12:29:03 <[g2-lap]> they were like $150 last year Jan 18 12:29:52 still arround the $140 range dependent on the options you get Jan 18 12:30:00 <[g2-lap]> for this market really anything below < $1K is cheap for the customer Jan 18 12:30:26 <[g2-lap]> you guys are probably not all ready to go spending a couple K for test devices though Jan 18 12:30:37 [g2-lap]: Let me see if I get your point. You want the JTAG accelerator, the FPGA, to be on a USB chain so that we can get more of them on a JTAG workhorse? Jan 18 12:31:09 <[g2-lap]> beewoolie it doesn't have to be, but scaling is important longer term Jan 18 12:31:10 The only problem I see with using USB as the network is that its slow. Jan 18 12:31:28 we seem to have set a $250 target cost for the h/w Jan 18 12:31:55 <[g2-lap]> beewoolie I don't call 30-40MBs slow Jan 18 12:32:13 [g2-lap]: The protocol is inefficient WRT round-trip times. Jan 18 12:32:28 Moreover, you won't get that much throughput when you start linking lots of them together. Jan 18 12:32:45 <[g2-lap]> beewoolie nod, but the question is how much RTT messages will there be ? Jan 18 12:32:56 that depends on how you partition the problem Jan 18 12:33:00 <[g2-lap]> beewoolie I think the traffic is really bursty Jan 18 12:33:07 There are some operations where RTTs will help alot in solving the problem well. Jan 18 12:33:31 The only person here who has done this (as far as I can tell) is vmaster. Jan 18 12:33:50 <[g2-lap]> well Gateworks tests there boards :) Jan 18 12:33:57 <[g2-lap]> s/there/their/ Jan 18 12:33:58 [g2-lap] meant: well Gateworks tests their boards :) Jan 18 12:34:18 <[g2-lap]> wookey__ has probably done it with other tools on V2 Jan 18 12:34:20 In looking at what I've got so far, yeah, it's mostly bursty. But once you start doing lots of testing, you're going to need to do more round-trip exchanges. Jan 18 12:34:57 For your target market, what is wrong with a PC104 stack? Jan 18 12:35:26 <[g2-lap]> My issues with PC104 are the following: Jan 18 12:35:36 <[g2-lap]> 1) The form factor is more expensive Jan 18 12:35:51 [g2-lap]: Or, we could just as well design this ts7200 so that it is the smallest piece of the system. You always get one of them with the FPGA. Scaling is over ethernet. Jan 18 12:35:58 <[g2-lap]> 2) I there isn't an open platform Jan 18 12:35:59 with the pc104 design it should be able to burst read or write upto 32mbytes of data to from the jtag at 40Mhz Jan 18 12:36:31 <[g2-lap]> Scaling with ethernet is less than scaling with USB 2.0 Jan 18 12:37:44 <[g2-lap]> Some of the Maxtor One touch drives have the CY068 USB 2.0 chip in there. My drive does 28MBs on my P4 system Jan 18 12:37:55 <[g2-lap]> that's sustained Jan 18 12:38:40 not shown on the block , but there is a posiblilaty that the fpga could be used to drive a vga monitor and display logic states or a scope style display in a logic analizer mode so latancy there is not high Jan 18 12:38:40 does anyone know how large a typical pcb test vector set is? Jan 18 12:39:22 <[g2-lap]> AchiestDragon now you are potentially talking Jan 18 12:39:34 <[g2-lap]> lennert has driven a Pong program for the FPGA Jan 18 12:40:35 <[g2-lap]> AchiestDragon I like the idea but unless we put a hard-core on the FPGA and run it locally (like the Blackdog) we may not want to do that Jan 18 12:40:42 the fpga will have no prolbems driving a vga , the problem is if the data can be translated to the video ram in the time needed Jan 18 12:41:01 [g2-lap]: I think you overestimate the bandwidth of USB. It's shared. Jan 18 12:41:08 Ethernet has switches which are not shared. Jan 18 12:41:32 <[g2-lap]> beewoolie it's measured BW Jan 18 12:41:34 If you load-up the USB, you won't see that kind of throughput on every node. You'll see an aggregate bandwaidth. Jan 18 12:41:43 For one device. Jan 18 12:41:59 with one host, ethernet bandwidth is shared, too Jan 18 12:42:14 <[g2-lap]> fully agrees, but I think that the problem of testing is bursty Jan 18 12:42:37 <[g2-lap]> Load a megabyte or two and test for 5-10 mintues or longer Jan 18 12:42:46 <[g2-lap]> ship the results back Jan 18 12:42:53 USB will only allow one host. Ethernet allows many hosts. Jan 18 12:43:38 Yeah, but you're only putting an FPGA on this thing. I don't see where the smarts are going to be to do 5minutes of testing. Jan 18 12:43:59 <[g2-lap]> a big state machine Jan 18 12:44:00 ethernet at t100 has a bigger bandwith so should (if a point to point net with no other devices ) its going to be faster than usb Jan 18 12:44:27 <[g2-lap]> AchiestDragon maxes out at 11MBs Jan 18 12:44:42 I'd have to see what you are talking about. My understanding of the boundary scan is that tests are meant to be fast, If you want to do a lot of work, you'll have to have a very complex FPGA. Jan 18 12:45:09 <[g2-lap]> well it's a complex and costly problem Jan 18 12:45:23 <[g2-lap]> that's why the current solutions are $10-20K Jan 18 12:46:01 <[g2-lap]> besides when doing a 10K production run that's only $1 per board Jan 18 12:46:02 there has to be a compramise at some point , over the 10 to 20k solutions Jan 18 12:46:38 <[g2-lap]> AchiestDragon I don't think there is any fundamental limit here Jan 18 12:47:26 [g2-lap]: but a solution with a CPU core and an FPGA accelerator is much easier for us to program. Jan 18 12:47:53 From a design standpoint, the FPGA design is far costlier Jan 18 12:47:54 for example the pc104 design could opperate in a logic analizer mode , that would allow for coninus sample rate = the ram data rate , or a burst sample rate to that of the fpga thats arround 200mhz Jan 18 12:48:33 I've designed a protocol we can use on the FPGA that allows high throughput and is flexible enough to allow for any scan design. Jan 18 12:48:47 beewoolie: i'm updating my s3c2410 patch against the latest apex, should get you a new version friday Jan 18 12:48:58 An FPGA that can run tests is much more complex. it has to make decisions and guide the test. Jan 18 12:49:06 prpplague: excellent. Jan 18 12:49:36 but with a $20k budget it could use something like a vertex pro , using the rocket i/o up to 1Ghz data rates are be posible for the same function Jan 18 12:49:50 but cost is the issue Jan 18 12:50:09 beewoolie: the first version will have just the basic s3c2410 support, then two additional patches will follow adding machine specific support for the M7200 and LN2410SBC Jan 18 12:50:30 beewoolie: do you have your protocol documented somewhere? Jan 18 12:51:24 I've discussed it with ka6sox, but I haven't codified it yet. I'll let you know when I do. Should be soon. I've been writing the JTAG code so that I was sure that I was on a reasonable track. Jan 18 12:52:00 vmaster: One thing I want to do is read the ftdi protocol documentation. I think they do things very differently from what I'm thinking about. Jan 18 12:53:22 the ftdi "protocol" just specifies the direction of the scan (in, out, inout), the type (tms, tdi) and the number of bits/bytes Jan 18 12:53:37 Is it documented? Jan 18 12:53:54 yeah, hold on Jan 18 12:53:59 Excellent. Jan 18 12:54:40 [g2-lap]: How much do you want these USB dongles to cost? Jan 18 12:54:53 http://ftdichip.com/Documents/AppNotes/AN2232C-01_MPSSE_Cmnd.pdf Jan 18 12:55:17 <[g2-lap]> beewoolie I think I can get a prototype run produced for < $100 a piece Jan 18 12:55:55 i've started defining a more capable protocol here: http://openocd.berlios.de/web/?page_id=22 Jan 18 12:55:59 <[g2-lap]> the real question is whether they are enough and whether there enough JTAG expertise to utilize them Jan 18 12:56:04 OK. I'll read that, too. Jan 18 12:57:03 The protocol I've been working on is core agnostic. Jan 18 12:57:15 it's really just about running the JTAG chain. Jan 18 12:57:29 and that the FPGA needs to do. Jan 18 12:57:39 My aversion to core specific protocol elements is that it will require updating for new cores. Jan 18 12:57:51 that's my plan, too Jan 18 12:58:16 But if we don't have a CPU on this dongle and we want it do be able to do some autonomous testing, it's going to need more umph. Jan 18 12:58:25 <[g2-lap]> well I think the problem domain breaks into generic JTAG and core specific JTAG Jan 18 12:58:52 vmaster: The document on berlios talks about ICE and debug registers. I interpret that to be core specific, but then I haven't read all of it. Jan 18 12:59:08 that's an example about how it maps to arm7/9 debugging Jan 18 12:59:16 which is what i know about Jan 18 12:59:17 Oh. Macros. Jan 18 12:59:20 <[g2-lap]> vmaster do you have to log into get access to that document ? Jan 18 12:59:34 no Jan 18 12:59:59 it's more like a command-interpreter Jan 18 13:00:07 <[g2-lap]> vmaster ahh... worked on the refresh Jan 18 13:00:58 my idea is that the latency critical stuff is waiting for a scan to match a test pattern Jan 18 13:01:19 With the FPGA design and the ts7200, there is no need for any of that complexity since the FPGA can read commands from the CPU SDRAM. Jan 18 13:01:56 my major concern here is that the design is still in "alpha" for the pxa board and we can't get hardware. Jan 18 13:02:01 Once we go to remote scan operation, the complexity goes way up. Jan 18 13:02:28 ...compares, loops... Jan 18 13:03:03 I'll review what I've got and get back to you all. Jan 18 13:03:22 i've been away the last 6 hrs.. anything important happened? Jan 18 13:03:34 <[g2-lap]> hey lennert Jan 18 13:03:39 more than in the last 5 months combined Jan 18 13:03:48 <[g2-lap]> heh Jan 18 13:04:31 [g2-lap], its true...between what you have done and what others are working on its true. Jan 18 13:04:49 <[g2-lap]> lennert take a look at this http://www.giantshoulderinc.com/projects/openjtag/openjtag.pdf Jan 18 13:05:12 <[g2-lap]> ka6sox-office this is all a work-in-progress Jan 18 13:05:24 <[g2-lap]> it's great to see so much excitement and envolvement Jan 18 13:05:34 ya Jan 18 13:06:00 <[g2-lap]> I think having focused problem domains and goals will help Jan 18 13:06:42 <[g2-lap]> we may all agree on a common domain and platform, or we may have a dozen with some or no overlap Jan 18 13:07:00 back in 30 minutes Jan 18 13:07:03 (meeting) Jan 18 13:09:27 some compare functions can be implimented in a soft ip core , like image verification , or repeated scanning for state changes , the ip core for that sort of test is not overly complex Jan 18 13:10:45 and with a 40mhz jtag clock there should be problem with speed delays doing that Jan 18 13:17:49 <[g2-lap]> AchiestDragon my uninformed understand of the problem space this: Jan 18 13:17:49 <[g2-lap]> It's the scan long scan chains that need the high clock rate Jan 18 13:17:49 <[g2-lap]> example the IXP42x scan chain is 498 bits long Jan 18 13:18:08 <[g2-lap]> so the compare only need to happen at a relatively long interval relative to the TCLK Jan 18 13:19:24 <[g2-lap]> if TCLK was running a 49.8Mhz, compares would only need to happend at 100K Hertz rate for once every scanchain operation Jan 18 13:19:28 <[g2-lap]> correct ? Jan 18 13:19:54 using the fpga method it should be possible to scan upto a 32mbyte chain , and triger an event if one perticular specified bit of that has changed since the last Jan 18 13:20:21 or is at a perticular state Jan 18 13:20:56 with the hosting micro only needing to process an interupt on the event detection Jan 18 13:21:31 <[g2-lap]> I don't understand why you wouldn't want that state machine on the FPGA Jan 18 13:22:05 it can be implimented on the fpga Jan 18 13:22:36 <[g2-lap]> ok, I think we are saying the same thing then Jan 18 13:23:00 okay, as i understand it, svf is designed for this kind of application Jan 18 13:23:33 <[g2-lap]> the XJTAG tool uses svf Jan 18 13:23:47 <[g2-lap]> so you are probably correct :) Jan 18 13:23:49 and svf only allows you to specify a pattern that's scanned into the device, and an optional check value/mask that compares what has been shifted out Jan 18 13:24:21 <[g2-lap]> is there an SVF link somewhere ? Jan 18 13:24:37 http://www.asset-intertech.com/support/svf.html Jan 18 13:24:41 <[g2-lap]> THX Jan 18 13:26:22 <[g2-lap]> vmaster looks like a good link Jan 18 13:27:04 remember that trying to perform a run time pin state analizer on a running jtag device theres the problem that the number of cycles to read the information say 498 bits only allows for 1 sample per ( jtag_data_rate_MHz / 498) in MHZ Jan 18 13:28:10 AchiestDragon: i believe this is fine for the desired application Jan 18 13:28:12 so althugh it may show the pin data changing stat it only is any real use to ensure a perticular pin is opperating correctly and is not pulled high or low Jan 18 13:28:58 the macraigor videos for their j-scan show nicely what such an analyzer is supposed to do Jan 18 13:30:16 the other thing that i have been looking at , is with the fpga method , it should allow us to use it in a diferent mode Jan 18 13:30:53 with an alternate set of buffers , and some switching it could operate as a 16 bit logic analizer Jan 18 13:32:26 that could read 16 bits worth of signal info (from a diferent cable to the board ) at up to the max write rate of the sdram Jan 18 13:32:54 its easy to impliment as a soft ip core Jan 18 13:33:15 if provision for it has been included in the buffers Jan 18 13:34:10 so a 40Mhz 16bit logic analizer on the same platform also for a couple of extra buffers Jan 18 13:34:25 * lennert reads the backlog Jan 18 13:36:39 that should help hobby users in solving problems of miss timeing that the jtag pin state display could not Jan 18 13:39:48 hopes theres not a confilct in interests here , but if your going to build a device then when other uses of it are so easy to inclued that are so usefull for associated work then may as well include support Jan 18 13:40:17 <[g2-lap]> looks interesting :) http://www.intellitech.com/products/ultratestaccessport.asp Jan 18 13:43:27 heh, and at least as expensive as interesting Jan 18 13:44:02 opensluggers ??: can I use the cross-tools from openslug-2.7 to cross-build APEX-1.3.13 for an NSLU2 or should I go to monotone head? Jan 18 13:47:21 <[g2-lap]> http://www.acculogic.com/index.php?content=product&category=bs&id=scanmaster#_self Jan 18 13:47:53 <[g2-lap]> http://www.acculogic.com/index.php?content=product&category=bs&id=scanmaster#_self Jan 18 13:48:11 interesting Jan 18 13:48:18 home much is that? Jan 18 13:53:45 <[g2-lap]> http://www.acculogic.com/index.php?content=product&category=bs Jan 18 14:41:33 the ftdi protocol looks sane enough Jan 18 14:41:37 from a cursory glance Jan 18 14:44:43 yeah, there's nothing wrong with it, but it's limited Jan 18 14:46:00 does it need anything else? Jan 18 14:46:24 i only see the case for a more complicated protocol if pc<->jtag latency is high Jan 18 14:46:30 but if it is, you've got other problems anyway Jan 18 14:46:35 latency is high Jan 18 14:46:44 1-2ms Jan 18 14:46:50 well, yeah, on the ftdi Jan 18 14:46:57 but we can very well take the protocol and use it elsewhere Jan 18 14:47:06 i just meant the protocol itself looks okay (iff latency is okay) Jan 18 14:47:35 it comes down to partioning the problem - where you want to do what Jan 18 14:47:38 +t Jan 18 14:47:48 +i Jan 18 14:48:17 indeed Jan 18 14:48:28 and doing more than the ftdi protocol does in hardware is just too complex, imho Jan 18 14:48:34 unless you want to make stuff target-specific Jan 18 14:48:48 or is there one step beyond ftdi that isn't too complex? Jan 18 14:48:59 i don't see what other functionality you can add without going 'all the way' Jan 18 14:49:23 that's what i'm trying to find out Jan 18 14:49:42 ok.. how are you trying to find that out? Jan 18 14:49:55 http://openocd.berlios.de/web/?page_id=22 is what i'd like a jtag protocol to do Jan 18 14:50:39 this could be implemented easily on a small uC with a fast serial interface Jan 18 14:51:07 or on a fpga with a soft-core Jan 18 14:51:53 <[g2]> or on a fpga with a hard-core Jan 18 14:52:14 or directly on the h/w ;-) (/me wrote half of a vt100 emulator in h/w) Jan 18 14:52:36 * [g2] hugs lennert Jan 18 14:52:38 heh, even better if you can do that in h/w Jan 18 14:53:13 <[g2]> at my last startup the did IP proessing in the FPGAs Jan 18 14:53:24 <[g2]> Internet Protocol V4 Jan 18 14:53:39 <[g2]> it's possible, just quite costly Jan 18 14:54:02 <[g2]> I was the token Network Processor guy Jan 18 14:55:13 <[g2]> 18 months into the project they looked at NPUs a little differently than the beginning :) Jan 18 14:55:37 well, NPUs are like asics but with a shorter turnaround time.. Jan 18 14:55:42 and slightly easier to code for, but not much Jan 18 14:55:58 <[g2]> way easier Jan 18 14:56:03 <[g2]> and debug too Jan 18 14:56:16 the ixp2000 is not so easy to code for ;) Jan 18 14:56:27 in fact, packet rx/tx on the xupv2p board is way easier than on the ixp2000 Jan 18 14:56:36 maybe npus have changed a lot though Jan 18 14:56:49 <[g2]> are you running packets on the xupv2p ? Jan 18 14:56:57 ya Jan 18 14:57:02 <[g2]> Gigabit ? Jan 18 14:57:10 100Mb Jan 18 14:57:56 <[g2]> lennert you're probably not interested in 100Mb packet filtering with netfilter/iptables much Jan 18 14:58:22 for 100Mb you don't need an fpga Jan 18 14:58:32 but it's still easier to code for than on the ixp2000.. :) Jan 18 14:58:37 <[g2]> no I've got a Loft :) Jan 18 14:59:16 <[g2]> Are you planning on putting GigE on there ? Jan 18 15:00:34 <[g2]> will that support GigE ? Jan 18 15:03:30 <[g2]> lennert are there hard-cores on that board ? Jan 18 15:04:01 v2p has the ppc405 Jan 18 15:04:19 <[g2]> vmaster I think some have up to 4 Jan 18 15:04:36 <[g2]> Ah.... 2 PPC cores Jan 18 15:07:19 yeah, two ppcs Jan 18 15:07:37 405's are no slouch Jan 18 15:07:45 <[g2]> but no floating point :( Jan 18 15:08:14 <[g2-lap]> I like this http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/13010F4A79FC026C87256DFA004D30D0#4 Jan 18 15:08:40 i kind of got one of the ppcs to work, at least, i got it to fetch instructions. but i didn't try further. Jan 18 15:09:01 i'm stubborn and don't want to use xilinx ip, so that makes it a lot more work to get it running Jan 18 15:09:37 <[g2]> bare-metal lennert :) Jan 18 15:11:03 "needs 5x more time than other people to understand stuff" lennert Jan 18 15:11:47 <[g2]> yeah but you understand stuff 20x better so it works out as a 4x advantage Jan 18 15:12:12 uhm... is cfi (common flash interface) little or big endian? i've read the jedec standard, but there's no mention of the order of multi-byte data members Jan 18 15:12:42 <[g2]> well both in 8-bit mode :) Jan 18 15:12:58 <[g2]> it's just 16 and 32-bit that are in question :) Jan 18 15:13:08 mhh, no, that question is valid for 8-bit mode, too Jan 18 15:13:32 data is always returned in the least significant byte Jan 18 15:13:40 d0-d7 Jan 18 15:13:53 but there are fields in the query structures that are two or four bytes long Jan 18 15:17:25 <[g2]> vmaster that doesn't make sense to me as the data path is only 8-bits wide it takes multiple reads to get the data Jan 18 15:18:01 it takes multiple reads on a x16 or x32 device, too Jan 18 15:18:46 <[g2]> right but there is an endianness queston on the data arriveing on d15-d8 and d7-d0 Jan 18 15:19:10 <[g2]> Does it arrive 0xAA 0xBB or 0xBB 0xAA Jan 18 15:19:21 there's no data arriving at d15-d8 Jan 18 15:19:52 cfi queries return 0x0 on d15-d8 Jan 18 15:19:54 <[g2]> I an tell you the Flash on the IXP42x is programmed for 16-bit wide access Jan 18 15:20:09 ah, i'm talking specifically about the cfi queries Jan 18 15:20:10 <[g2]> Redboot is byte swapped before programming Jan 18 15:20:45 <[g2]> well I'd think the CFI would match up with the data Jan 18 15:21:38 <[g2]> meaning I could possibly have the bus in the wrong order and reorder the commands and it'd all work out Jan 18 15:21:59 <[g2]> like jbowler byte swapping the kernel command line and booting into LE Jan 18 15:22:20 vmaster: okay, so it's like some kind of macro functionality (advanced jtag thingo) Jan 18 15:22:35 yeah, a kind of interpreter Jan 18 15:22:51 with sub-routines Jan 18 15:22:55 or macros, if you want Jan 18 15:23:13 that's just to reduce the bandwith needs Jan 18 15:23:17 yeah Jan 18 15:23:20 but it won't help with latency Jan 18 15:23:59 it would help in all cases where you're polling for a scan to match Jan 18 15:24:09 right Jan 18 15:24:36 and i believe these are the latency-critical parts Jan 18 15:24:55 at least i couldn't come up with anything else yet Jan 18 15:25:56 this would also support some "trigger" functionality, like AchiestDragon (iirc) suggested yesterday or so Jan 18 15:26:30 when doing boundary-scan analysing you set a trigger on "pin reads high" and continue capturing at that point Jan 18 15:26:58 when doing flash writes you wait for the nBusy line going high Jan 18 15:27:22 though flash writing might not really be timing critical Jan 18 15:27:31 so you probably wont be checking the busy bit Jan 18 15:27:32 * beewoolie-afk reading logs... Jan 18 15:27:59 <[g2]> vmaster I think for flashing it might be better to do that from within the processor in may cases Jan 18 15:28:20 <[g2]> iirc loading the i-caches is only 40bits Jan 18 15:28:31 <[g2]> for a 32-bit word Jan 18 15:29:17 <[g2]> So on the IXP42x and probably XScale it'd be faster to load up stuff in the CPU Core and have it do it Jan 18 15:29:38 yeah, sure, same goes for arm7/9 Jan 18 15:29:46 <[g2]> The exception would be when you want to externally verfiy the flash Jan 18 15:29:57 or where you have a yet unsupported target Jan 18 15:30:06 that's the fine thing about the jtag-0.5.1 stuff Jan 18 15:30:16 all you need is a bsdl file Jan 18 15:31:10 <[g2]> I'd be interested in knowing how the arm7/9 differ among chips Jan 18 15:32:05 <[g2]> meaning is there much difference between the Cirrus 93xx, the Sharp chips and the Samsung Jan 18 15:32:24 [g2]: The cores all have the same embedded ice HW. Jan 18 15:32:26 arm7 and arm9 are somewhat different as one has a combined instruction/data bus where the other has separate busses, one has 3 pipeline stages and one 5 Jan 18 15:32:43 Small timing differences. Jan 18 15:33:07 <[g2]> beewoolie-afk that makes a lot of sense Jan 18 15:33:09 I was under the impression that the arm7 was a harvard architecture as well. Jan 18 15:33:38 <[g2]> The Cirrus can boot from the serial port, can the Sharp and Samsung do that trick too ? Jan 18 15:33:52 Using the BSDL file to manipulate memory is inherently more tricky since you don't know how the CPU views the devices. Jan 18 15:34:15 That's reflected in the fact that openwince's jtag SW has to swap data before writing to flash. Jan 18 15:34:24 When we use the CPU, that isn't (as much) of a consideration. Jan 18 15:35:04 The Xscale has a mini-I cache for loading debug code. Very helpful. ARMv4 doesn't, but it has a nice method for injecting instructions. Jan 18 15:35:05 <[g2]> It'd be interesting to run the jtag sw on MAC Jan 18 15:35:14 vmaster: I'm coming around to your way of thinking. Jan 18 15:35:25 I need to muse a bit more about what we think we can do. Jan 18 15:35:26 <[g2]> I don't know if it recognizes it's own endianness or just always swaps Jan 18 15:36:05 I can [kinda-of] guarantee that a simpler protocol will be feature complete. this interpreter method is more difficult for achivieving provable-completeness. Jan 18 15:36:21 [g2] It doesn't exactly matte.r Jan 18 15:36:36 When you use the CPU to access memory, it access memory the way it *always* access memory. Jan 18 15:36:38 <[g2-lap]> According to this we're gonna be very limited on clock rates unless we've got a very short cable right ? Jan 18 15:36:43 <[g2-lap]> http://www.acculogic.com/index.php?content=product&category=bsinfo&id=sol#_self Jan 18 15:36:45 beewoolie-afk: the arm7 is von-neumann Jan 18 15:36:50 I've been told that. Jan 18 15:37:59 [g2-lap]: yeah Jan 18 15:38:41 Arm's realview ice uses lvds to overcome this problem Jan 18 15:40:32 <[g2]> vmaster I'd imagine the traces on the board factor into the signal propagation delay (as does the connector) Jan 18 15:40:51 ah, yeah, acculogic addresses a different problem Jan 18 15:40:58 So, to be clear, my objection to the avenue that you've been discussing, a relatively complex interpreter in the FPGA, is that is it more complex than a simple JTAG accelerator. Jan 18 15:41:37 yeah, i agree on that Jan 18 15:41:56 [g2]: in the ixp2800 datasheet, they mention how many mils of wire there is between the silicon die and the package pads, so that you can do static LVDS phase alignment Jan 18 15:41:57 <[g2]> yeah me to, but latency kills Jan 18 15:42:08 but i'm not sure if there's a simpler solution Jan 18 15:42:29 well, there is, if you're going the ka6sox/AchiestDragon way Jan 18 15:42:53 but that means shifting all of the target-logic into the "dongle" Jan 18 15:44:18 <[g2]> Ok can we call the ka6sox / AchiestDragon the 104 solution ? Jan 18 15:45:41 I'll post a protocol document tonight...as long as dollface doesn't object. Jan 18 15:45:44 <[g2]> In the 104 solution, the FPGA might as well be a CPLD Jan 18 15:46:13 a cpld will not allow for reconfiguration on the fly Jan 18 15:46:14 <[g2]> because it just acts like a big parallel to serial shift register right ? Jan 18 15:46:51 you can bitbang the cpld's jtag port from the uC if you want Jan 18 15:46:53 <[g2]> and what rereconfiguration will be done ? Jan 18 15:48:10 <[g2]> dinner Jan 18 15:48:14 whatever you want , so it cann allow you to configure a mor complex spft ip core for some tasks if needed Jan 18 15:49:11 cann = can , mor=more spft= soft Jan 18 15:50:48 reconfiguring the FPGA "on the fly" will still require the FPGA to be offline during programming. Jan 18 15:51:07 and the FPGA will be Tri-Stated at that point. Jan 18 15:51:50 yes Jan 18 15:52:42 but that won't crash anything. Jan 18 15:53:25 the TS7200 has 1.8V (which I think is the Core voltage of the S3) Jan 18 15:53:37 * ka6sox-office might be confusing series though Jan 18 15:53:59 i guess g2's point was that for the purpose of jtagging, a cpld would be enough Jan 18 15:54:13 ka6sox-office: s3 core is 1.2V Jan 18 15:54:24 ka6sox-office: IOs are 1.2V to 3.3V, and Vaux is 2.5V Jan 18 15:55:33 lennert: thanks. Jan 18 15:55:38 vmaster: probably Jan 18 15:55:49 the 1.8v is the core voltage for the cpld that is used for address decode on the ts7200, the pc104 bus has 5v power that is avalable for us to use Jan 18 15:55:57 but that isn't the total aim of the project..it includes debugging as well. Jan 18 15:56:12 yes Jan 18 15:56:30 and maybe some Logic Analysis. Jan 18 15:57:12 (having used LA's to debug busses and Kernel issues I know the value) Jan 18 15:57:28 and when debugging we may need a few diferent ip cores depending on the task , that would be not as flexible with a cpld Jan 18 15:58:40 heh, we need a glossary so everyone uses the same terms Jan 18 16:00:35 vmaster: we have a wiki :) Jan 18 16:00:37 it can go there. Jan 18 16:02:00 heh, yeah, i'm just trying to figure out how to create a new page ;) Jan 18 16:02:43 do i want Glossary.Glossary, Glossary.HomePage or Main.Glossary? Jan 18 16:04:25 lemme ask somebody...brb Jan 18 16:05:12 put it in Main.Glossary and we can move it. Jan 18 16:08:13 in FPGA's they use different terms for the same thing (different manufacturers) Jan 18 16:29:17 bbiaf Jan 18 16:41:06 http://www.openjtag.net/wiki/Main/Glossary Jan 18 16:44:02 i'm off - n8 everyone Jan 18 16:44:12 later. Jan 18 17:00:43 vmaster, thanks! Jan 18 17:01:00 I found one goofy thing in the ftdi protocol. Jan 18 17:01:09 oh? Jan 18 17:01:18 only 1? Jan 18 17:01:23 It's the sort of thing that makes this not such an attractive style of handle the transfer. Jan 18 17:01:26 1 so far. Jan 18 17:01:58 When writing data to a register, the last bit should be written with TMS=1 so that the TAP leave the SHIFT state. Jan 18 17:02:30 The way that the ftdi handles this is they leave off the last bit and use another command to shift that last bit while also holding TMS high. Jan 18 17:02:39 weird Jan 18 17:03:10 I can see why they did it that way, but it betrays the underlying sorts of problem we'll see when putting lots of logic in the FPGA. Jan 18 17:03:51 So here's the essence of the trade off. Jan 18 17:04:06 The idea I'd been playing with was to use a byte per clock transition. Jan 18 17:04:25 That means that a scan for 600 cells in a scan chain would be about 610 bytes. Jan 18 17:04:34 Not a big deal when we are in the same address space. Jan 18 17:05:00 The same operation using an ftdi protocol is about 80 bytes. Jan 18 17:05:23 I'm going to spec both and see what people think. Jan 18 17:05:31 sounds good. Jan 18 17:05:34 We *can* support both without much grief. Jan 18 17:16:58 beewoolie-afk: what i proposed to ka6sox earlier was a 'scan finished' bit (when you scan to tdi) which would toggle tms on the last clock to leave shift-{dr,ir} state Jan 18 17:17:26 I don't know what you mean. Jan 18 17:18:14 I'm going to code for a IO opcode that has a bit which, when set, will latch TMS=1 on the last data bit. Jan 18 17:23:09 ka6sox-office: How much RAM is in one of these FPGAs? Assuming that I want it to store some data locally. Jan 18 17:24:42 the XC3S400-4TQ144C has about 200k bits Jan 18 17:25:23 25KiB. Jan 18 17:26:41 actualy 36Kbytes 288kbits Jan 18 17:29:18 lennert: Actually, we can do one better. We can *always* transition out of the shift state after an IO operation and then reenter it if we need to. Jan 18 17:31:28 beewoolie-afk: sure, that sounds sane.. when scanning to tdi, always set tms=1 on the last bit Jan 18 17:31:47 Doesn't matter, TDI or TDO. Jan 18 17:31:57 It's safe for either. Jan 18 17:32:08 beewoolie-afk: you could have an extra bit for 'leave scan-{dr,ir} when i am done' but you could also just do it anyway, indeed Jan 18 17:32:10 The ftdi protocol is generalized for more than just JTAG. Jan 18 17:32:14 well, TDI/TDO i regard as one case Jan 18 17:32:25 i mean, inward scans go either to tms or tdi Jan 18 17:32:28 I had a bit at first, but I think now it is saner to do it this way. Jan 18 17:33:13 Yeah, though TMS scanning isn't necessary because I'm using a SeekState command to put the TAP into the next desired state. Jan 18 17:33:33 beewoolie-afk: document your protocol and i'll read it Jan 18 17:33:38 There is only one place where it may be useful to use TMS scanning. Jan 18 17:33:45 * beewoolie-afk is working at it. Jan 18 17:33:54 At least, I've only seen one. Jan 18 17:33:56 okay Jan 18 17:36:18 beewoolie-afk, we also can put a 32MB SDRAM on the board too. Jan 18 17:36:57 Interesting idea. If the transactions are of differing lengths, is the FPGA going to be able to keep lists of them efficiently? Jan 18 17:40:01 it should could have a bit counter so it sould know how many bits to send and how much to/has recived Jan 18 17:40:28 AchiestDragon: For you, I'll put in three. That'll give us two spares. :-) Jan 18 17:45:38 I'm including ways to manipulate the reset signals. Do we need to have ways to operate some extra GPIO lines? Jan 18 17:48:13 ka6sox-office: I know that the ep1220 board has some GPIO lines connected to the JTAG socket. Are any of these things we're going to need to manipulate? Jan 18 17:49:22 hi Jan 18 17:49:32 wb Jan 18 17:51:06 beewoolie-afk, probably Jan 18 17:51:15