| 00:13.46 | beewoolie | key2: best current method is jtag. |
| 00:14.13 | beewoolie | It does, in effect, what you say by applying signals to the system busses. |
| 00:29.16 | AchiestDragon | most systems use eather jtag or some other form of isp to do that , for production reasons there programmed after the board is assembled |
| 00:29.43 | AchiestDragon | and can be reprogrammed the same way |
| 00:30.51 | AchiestDragon | although jtag is often used , some do not stick to the standard jtag header pinouts |
| 00:37.12 | *** join/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 00:37.20 | AchiestDragon | wb |
| 01:17.53 | *** join/#openjtag vmaster_ (i=vmaster@p549B780A.dip.t-dialin.net) |
| 03:30.07 | *** join/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 03:41.53 | beewoolie | ka6sox: yo |
| 03:42.36 | beewoolie | ka6sox: rilly close to being able to write flash |
| 03:42.43 | ka6sox | sweet! |
| 03:43.06 | beewoolie | For some reason, I'm unable to read from the bus. |
| 04:31.19 | AchiestDragon | :) |
| 04:31.24 | beewoolie | AchiestDragon: Hey. |
| 04:31.34 | AchiestDragon | hi |
| 04:31.52 | ka6sox | so if we use a combination of both a uC and FPGA then we can solve the problems of HID and speed. |
| 04:32.44 | AchiestDragon | plus posible stand alone use of the unit |
| 04:32.49 | ka6sox | FPGA for handling the JTAG (at up to 40mhz) |
| 04:32.50 | beewoolie | yeah. |
| 04:33.10 | ka6sox | and something like an ARM(X) to handle the HID and high level stuffs. |
| 04:33.12 | beewoolie | CPU with OS for the comfortable chair. |
| 04:33.29 | beewoolie | Plus it can be a wireless router! |
| 04:33.31 | ka6sox | okay I would say that most here are more comfortable with Linux |
| 04:33.33 | AchiestDragon | debian arm |
| 04:33.39 | beewoolie | And it can play movies and MP3's! |
| 04:33.45 | ka6sox | debian arm works. |
| 04:33.54 | ka6sox | so arm7 or arm9 |
| 04:34.12 | beewoolie | I think that an arm7 would be sufficient. |
| 04:34.25 | beewoolie | However, the cost difference at this level should be negligible. |
| 04:34.36 | beewoolie | We aren't doing a pixster. |
| 04:34.40 | ka6sox | best to use a standard bus for the interface between the FPGA and the main board. |
| 04:34.50 | ka6sox | like PC104 or something like that. |
| 04:35.30 | ka6sox | we have discussed the TS7200 before and it has the power/price/interfaced |
| 04:36.33 | ka6sox | ARM9/8MB Flash/32MB RAM/CF |
| 04:36.48 | ka6sox | and PC104 |
| 04:37.03 | ka6sox | also USB as well as 10/100 Ethernet |
| 04:37.34 | ka6sox | so building a sufficiently powerful yet relatively inexpensive box is doable with that configuration. |
| 04:37.34 | beewoolie | Does the tsXXXX have USB client? so we can plug into a notebook that way? |
| 04:37.48 | ka6sox | I think its host only |
| 04:37.57 | AchiestDragon | 2* rs232 a lcd and keypad ports |
| 04:38.06 | beewoolie | doesn't look like it. |
| 04:38.21 | beewoolie | No lcd. |
| 04:38.27 | ka6sox | lcd connector |
| 04:38.29 | AchiestDragon | it is host but i know that there are cables that let you use usb host to host |
| 04:38.38 | ka6sox | and DIO as well |
| 04:38.46 | beewoolie | I don'tsee LCD on the spec page. |
| 04:38.50 | ka6sox | (which could be used as Keypad. |
| 04:39.09 | beewoolie | Of couse there are lots of PC104 options. |
| 04:39.10 | ka6sox | click on image detail |
| 04:39.22 | ka6sox | and look 6PM on board |
| 04:39.51 | AchiestDragon | it suppots the interface for the small lcd modules based on the hitachi chipset , from 1 line 8 charicters to 4 lins 40 charicters |
| 04:40.10 | beewoolie | It isn't metioned on the data sheet. |
| 04:40.31 | beewoolie | Oh. I see what you're talking about. That's usually just I2C. |
| 04:40.33 | AchiestDragon | it is in the manual |
| 04:40.51 | beewoolie | A real TFT LCDpanel needs more pins. |
| 04:40.57 | ka6sox | http://www.embeddedarm.com/Manuals/TS-7200_Rev1.4.htm#LCDHeader |
| 04:41.11 | ka6sox | its just enough for a Standalone solution. |
| 04:41.46 | beewoolie | OK. I'm not sure how usefulthat will be except to display the clock speed and some blinken lights. |
| 04:41.56 | ka6sox | These DIO pins have 100 KW bias resistors biasing these inputs to a logic ?1? |
| 04:42.23 | ka6sox | let me stand away from these Resistors if they have 100 kiloWatts on them. |
| 04:42.35 | beewoolie | good thinking |
| 04:42.40 | AchiestDragon | lol |
| 04:44.35 | ka6sox | with a S3/Cyclone 2 part on the FPGA board there will be enough room for the Chain Control/Chain Scan/SDRAM control/PC104 Control/and maybe even VGA :) |
| 04:45.16 | AchiestDragon | the pullups and use is documented in the manual they allow a keypad swich matrix to be connected directly without external components while not interfearing with alternate use of the port if you wish |
| 04:45.30 | ka6sox | :) |
| 04:45.31 | beewoolie | What would be kinda cool is if we could do some sort of logic-analyzer setup with it. |
| 04:45.43 | ka6sox | okay so this is what we are looking for. |
| 04:45.51 | ka6sox | its reasonable in cost too. |
| 04:46.22 | beewoolie | BBIAW. Gotta take care of something... |
| 04:46.30 | ka6sox | k |
| 04:47.00 | ka6sox | the TS-7200-32 is only $149 (minus the CF card) |
| 04:47.24 | ka6sox | so tftp and telnet should be a given |
| 04:48.48 | AchiestDragon | yes , telnet , and tftp are pre installed in the onboard flash |
| 04:48.53 | beewoolie | That's really cheap. DOH, I'm really going... |
| 04:49.07 | beewoolie | ...soon apex, too... |
| 04:51.11 | ka6sox | nite beewoolie |
| 04:52.06 | ka6sox | if we had to we could use the RTlinux kernel. |
| 04:52.33 | ka6sox | then we would be assured high performance on the JTAG> |
| 04:53.58 | ka6sox | I would think that the CF would mostly be used for holding images and captures from using somthing like gdb |
| 04:54.44 | ka6sox | AchiestDragon, is the toolchain the CrossTool one from Dan Kegel? |
| 04:56.05 | AchiestDragon | yes , although the one supplied has the correct patches for the ts7200 |
| 04:57.08 | AchiestDragon | the 256mb cf image that you can download from embbeded arm has a full debian arm distro with all the tools |
| 04:58.01 | ka6sox | sweet |
| 04:58.07 | AchiestDragon | that image can be installed on a cf card , usb memory stick or usb hdd , and boot from any is posible |
| 04:58.23 | ka6sox | so is there a native toolchain too? |
| 04:59.27 | AchiestDragon | although i find for development a usb hdd is best as you can set up a swap partition that helps with memory hungry apps like apt-get and python |
| 04:59.49 | AchiestDragon | where 32mb ram is not enough |
| 05:00.06 | ka6sox | I've got 2 Xscale armeb buildd boxes running and they swap too darned much with only 32MB |
| 05:00.54 | ka6sox | especially with cc1plus |
| 05:01.22 | AchiestDragon | i compile everything for the ts7200 on it , as i get problems on my linux box if i install the cross tools |
| 05:01.31 | ka6sox | okay |
| 05:01.49 | *** join/#openjtag bullet (n=bullet@142.23.79.83.cust.bluewin.ch) |
| 05:01.50 | ka6sox | so we could just host the toolchain natively on the TS |
| 05:01.57 | AchiestDragon | yes |
| 05:01.57 | ka6sox | that would work too. |
| 05:02.16 | ka6sox | I have been using CF's as main HD's for about 3 years with no ill effects. |
| 05:02.31 | ka6sox | (I use LOTS of RAM to overcome the lack of swap. |
| 05:02.42 | ka6sox | but when I first started we only had 128MB. |
| 05:03.09 | ka6sox | with mini-ITX form factor. |
| 05:03.27 | ka6sox | the TS7200 should be able to do what we need. |
| 05:03.31 | AchiestDragon | the only down side for the ts7200 is ram , its not easy to expand it |
| 05:03.56 | ka6sox | for this app it should be plenty |
| 05:04.07 | ka6sox | (development is another story :)) |
| 05:04.55 | AchiestDragon | the pc/104 only has a 1mb address space , so the sdram on the fpga will need pageing but not a big problem |
| 05:05.51 | ka6sox | :) |
| 05:05.58 | ka6sox | we could get 128KB |
| 05:07.01 | ka6sox | okay that driver will be the biggest PITA. |
| 05:07.04 | AchiestDragon | remembers stacking 4114 ram chips and wireing the ce inputs seperate to dubble memory capacaty also |
| 05:07.25 | ka6sox | we did that with 2114's also |
| 05:07.47 | ka6sox | much before Surface Mount :) |
| 05:07.54 | AchiestDragon | yes |
| 05:09.34 | ka6sox | this gives me much to chew on (and might just cause a little insomnia :)) |
| 05:10.24 | AchiestDragon | lol its 5:10 am here bed time for me soon been up all night |
| 05:11.23 | ka6sox | sorry to keep you up! |
| 05:11.26 | ka6sox | :) |
| 05:12.07 | ka6sox | sounds like we both need sleep. |
| 05:12.20 | ka6sox | I've been up way too early the last 2 days. |
| 05:18.15 | ka6sox | sleep well |
| 05:18.37 | AchiestDragon | night |
| 05:35.43 | beewoolie | ka6sox: I don't see any reason to do development on the target. |
| 05:36.22 | beewoolie | The cross development tools are excellent. With an NFSmount, everything we care about can be done on a fast X86 host except for running the jtag software. |
| 05:37.09 | beewoolie | in fact, I've never seen the allure of developing on these small targets. |
| 05:37.36 | beewoolie | Oncethe system is booted, we will see thay 32MiB is really quite fat for running our application. |
| 07:18.42 | vmaster_ | beewoolie: okay, i'm listening |
| 07:18.59 | beewoolie | hey |
| 07:19.16 | beewoolie | hang on |
| 07:23.34 | beewoolie | OK. Still there? |
| 07:23.46 | vmaster | yeah |
| 07:24.11 | beewoolie | I'm mastering the arcane magic of ARM9 JTAG. |
| 07:24.31 | beewoolie | I want to read from the bus. |
| 07:24.44 | beewoolie | But I only get zeroes. |
| 07:25.10 | vmaster | mhh... how did you enter debug state? |
| 07:25.16 | beewoolie | What documentation did you work from when you worked out the details of ARM JTAG? |
| 07:25.30 | beewoolie | Yeah. I've stopped the core with a debug RQvia EmbeddedICE. |
| 07:25.58 | beewoolie | And I can tell that I am restarting the code and then getting control back by watching for the SYSCOMP bit. |
| 07:26.39 | vmaster | i used the arm datasheets (all of them, not a single one is remotely complete) |
| 07:26.44 | vmaster | and a lot of trial-and-error |
| 07:27.28 | beewoolie | I've been working from the 922 datasheet. |
| 07:27.52 | vmaster | "read from the bus" means you want to read fro memory? |
| 07:28.00 | beewoolie | I'll look at some others. I've been under the impression that the arm7's and arm9's are either compatible or very close to the same. |
| 07:28.00 | vmaster | or a mmapped peripheral? |
| 07:28.08 | beewoolie | Both. |
| 07:28.13 | vmaster | yeah |
| 07:28.27 | beewoolie | I want to be able to write flash. And I want to read from the CPU internal registers. |
| 07:29.13 | beewoolie | The CPU has SRAM and I cannot even read from that. |
| 07:29.23 | beewoolie | But, I've only used sysspeed instructions. |
| 07:30.23 | vmaster | okay, you've scanned a LDM into the core with sysspeed low, followed by a NOP with sysspeed high? |
| 07:31.12 | beewoolie | Right. |
| 07:31.25 | beewoolie | After each one, I go to the Idle state to clock the CPU. |
| 07:32.00 | vmaster | okay, make sure you're spending exactly one cycle in r-t-i |
| 07:32.01 | beewoolie | Then, I load a restart instruction, go back to Idle and wait for the EmbeddedICE status to go SYSCOMP. |
| 07:32.15 | beewoolie | Yeah, that's true, too. |
| 07:32.32 | vmaster | okay, i guess syscomp is immediately high again? |
| 07:32.35 | beewoolie | What happens if I am passing through Idle once the system goes back to running. |
| 07:32.43 | beewoolie | I haven't timed it. |
| 07:33.04 | beewoolie | I'm using a parallel port adapter, so I cannot get that close to the speed of the system. |
| 07:33.15 | beewoolie | I know that if I forget the syspeed bit, it doesn't come back. |
| 07:33.29 | vmaster | yeah, that's what i mean - by the time you read it, it's already high |
| 07:33.35 | vmaster | dbgack too? |
| 07:33.41 | beewoolie | Which reminds me...the documentation on scanchain 1 is really poor. |
| 07:34.01 | beewoolie | Yeah. I check for both, but the docs make it clear that DBGACK should stay high. |
| 07:34.18 | beewoolie | ...in order to allow for proper cycle accounting. |
| 07:34.52 | beewoolie | The docs for scanchain 1 make it seem like the DD fieldis in the MSB bits, but it isn't. |
| 07:35.15 | beewoolie | Is there something in the text that explains this, or is this just one of those anomolies? |
| 07:36.07 | vmaster | one of the arm9 datasheets explains it |
| 07:36.07 | beewoolie | BTW, I can tell that the LDM instruction is working because it increments the index register. |
| 07:36.12 | vmaster | ah, okay |
| 07:36.17 | beewoolie | I'm going to look for one of them. |
| 07:36.21 | beewoolie | Like the 926? |
| 07:36.30 | vmaster | 9E-S |
| 07:36.36 | beewoolie | K. |
| 07:36.36 | vmaster | the 926 only refers to the 9E-S |
| 07:38.16 | vmaster | okay, getting some breakfast, later |
| 07:38.30 | beewoolie | OK. TTFN |
| 07:57.36 | beewoolie | vmaster: That was the ticket. Thanks. The 9e-s docs are much more clear about the debug details than the older datasheets. |
| 07:58.03 | vmaster | okay, your system-speed accesses work now? |
| 07:58.14 | beewoolie | that debug scan chain is really wonky. I just don't get why they numbered it so strangely. |
| 07:58.42 | beewoolie | vmaster: Yeah. I had a couple of things wrong. Once I had the docs in hand, I knew to fix one and the rest were just garbage that I'd added to help me figure things out. |
| 07:59.01 | beewoolie | Next stop, the flashing zone. |
| 08:11.00 | beewoolie | vmaster: do you read the logs? There was some interesting chatter about building the openjtag adapter. |
| 08:14.24 | vmaster | mhh, not yet |
| 08:26.28 | vmaster | okay, gotta go, cya |
| 08:35.55 | beewoolie | later. |
| 13:04.22 | *** join/#openjtag prpplague (n=billybob@72.22.141.137) |
| 13:55.46 | *** join/#openjtag GyrosGeier (n=richter@p54997AF5.dip.t-dialin.net) |
| 15:19.01 | *** join/#openjtag ByronT-Away (n=byron-po@nslu2-linux/ByronT) |
| 16:02.54 | *** join/#openjtag velinp (n=velinp@c88-163.cable.netissat.bg) |
| 16:18.20 | *** join/#openjtag ulf_k (n=ulf_kypk@p54BDBD0A.dip0.t-ipconnect.de) |
| 16:20.14 | ulf_k | hiho+ |
| 16:36.07 | ka6sox | hola |
| 16:47.13 | velinp | 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 |
| 16:47.27 | ka6sox | velinp, thanks he is much better now. |
| 16:47.36 | ka6sox | I did read it and find it fascinating :) |
| 16:47.50 | ka6sox | we have just missed each other in the last couple of days. |
| 16:48.23 | velinp | ka6sox, thanks; one of my twin daughters has a similar operation years ago (strabism); she's ok now. |
| 16:49.03 | ka6sox | glad to hear that too. I just have the one 4yr old. |
| 16:49.52 | velinp | ka6sox, about the SDRAM, I contacted apex's author; he said apex's memory-test could be modified for my strange hardware setup; |
| 16:51.13 | velinp | ka6sox, my friend has not done the hardware modification yet, so I can't play :( |
| 16:53.17 | ka6sox | the APEX bootloader very nice |
| 16:54.25 | ka6sox | it has started raining early here and I need to get things off the patio befor they get soaked. |
| 16:55.08 | ka6sox | bbiaf |
| 17:06.54 | ka6sox | back... |
| 17:08.33 | velinp | 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? |
| 17:11.20 | ka6sox | I was looking at the Micron equiv. what is the url for the icsc part? |
| 17:11.50 | velinp | It's at work; trying to find it (at home) |
| 17:12.36 | ka6sox | okay you can send it to me when you get to work ;) |
| 17:13.44 | velinp | a few minutes? |
| 17:14.55 | velinp | 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 |
| 17:15.49 | velinp | better, http://web.icsi.com.tw/domino/packinfo.nsf/959F32AE7222A7A748256F320003C488/$FILE/42s16160new.pdf |
| 17:17.32 | velinp | no irc at work, comany policy :(; I am looking at the PDF, page 19, Address Bits of Bank-Select and Precharge, second table; |
| 17:18.58 | velinp | on page 21, where they explain precharge, they speak about A10; later in the timing specs, they use A10; i am confused |
| 17:21.36 | ka6sox | this is confusing...since this is equivilent to the Micron part we should look at that. |
| 17:23.38 | velinp | 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 |
| 17:24.47 | ka6sox | http://www.micron.com/products/dram/sdram/part.aspx?part=MT48LC16M16A2P-75 |
| 17:25.11 | ka6sox | I think its a error in the ICSC part docs. |
| 17:25.14 | ka6sox | it should be A10 |
| 17:26.08 | velinp | what you say is such a relief to me :), thanks |
| 17:27.10 | GyrosGeier | (two of which are in crt0.S, which has the amazing number of 15 assemblers instructions) |
| 17:28.43 | ka6sox | only 15 ASM instructions :( |
| 17:29.29 | velinp | 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? |
| 17:30.20 | ka6sox | I only know the arm5t stuff...best to ask beewoolie |
| 17:30.49 | GyrosGeier | 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 |
| 17:31.10 | prpplague | velinp: mostly thats due to some arguments for crosscompiling |
| 17:31.11 | GyrosGeier | velinp, bootstrapping is a real bitch these days |
| 17:32.00 | GyrosGeier | velinp, the problem is that you need a glibc that is either a multilib or built with the same flags as your project |
| 17:32.54 | velinp | thanks; i did not insist compiling, because hardware must come first :) |
| 17:33.03 | GyrosGeier | however, to build gcc you need crti.o these days, which comes from libc, which needs gcc to build |
| 17:33.24 | ka6sox | ah....circular references mmmmmmm |
| 17:34.14 | velinp | 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 |
| 17:34.14 | GyrosGeier | if you only need static linking, you can invoke gcc's "all-host" target, which will compile enough of gcc to build a libc |
| 17:35.08 | GyrosGeier | 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. |
| 17:35.18 | ka6sox | if you need gcc4 you have to build Xwindows |
| 17:37.39 | velinp | 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 |
| 17:38.24 | prpplague | velinp: why are you wanting to build it natively? |
| 17:38.42 | velinp | thought it was safer |
| 17:39.11 | velinp | might try to cross-compile and come back later |
| 17:39.28 | prpplague | velinp: apex makefiles are really designed for cross-compiling |
| 17:39.56 | prpplague | velinp: in my 9 years of working with arm devices, i have never native compiled an application |
| 17:40.40 | velinp | ok, I have a cross compiler (from monotone, before openslug-3); will try it |
| 17:41.23 | *** join/#openjtag [g2-lap] (n=g2@cpe-066-057-008-035.nc.res.rr.com) |
| 17:41.37 | [g2-lap] | Hey guys you may want to take a look at this http://www.giantshoulderinc.com/projects/openjtag/openjtag.pdf |
| 17:42.06 | velinp | thanks, guys; I got more support that I can handle currently :); going into read-only :) |
| 17:42.24 | velinp | s/that/than/ |
| 17:42.24 | prpplague | [g2-lap]: hmm, is that klingon? |
| 17:42.35 | ka6sox | prpplague, I think so |
| 17:42.44 | [g2-lap] | klingon ? |
| 17:42.54 | [g2-lap] | hey ka6sox |
| 17:43.01 | prpplague | [g2-lap]: bad joke referencing star trek |
| 17:43.03 | ka6sox | its all blocks |
| 17:43.09 | ka6sox | (encoding seems off) |
| 17:44.11 | [g2-lap] | hmm... it seems to read fine with kpdf |
| 17:44.45 | prpplague | readable with acroread but not xpdf |
| 17:45.04 | GyrosGeier | xpdf works fine for me |
| 17:45.26 | [g2-lap] | GyrosGeier you may not like this document :( |
| 17:46.23 | ka6sox | [g2-lap], not readable on a Mac with Preview |
| 17:46.32 | ka6sox | trying acroread |
| 17:49.44 | ka6sox | (of course I have to get acroread first :P |
| 17:49.54 | ka6sox | hi [g2-lap] |
| 17:50.16 | prpplague | ka6sox: i used pdftops and then used gs to read it |
| 17:50.24 | vmaster | lol |
| 17:50.38 | GyrosGeier | [g2-lap], well, I can live with it |
| 17:50.45 | vmaster | i couldn't find a pdf viewer at my system that didn't display it |
| 17:51.23 | prpplague | yea, somethings not right about the encoding |
| 17:51.35 | ka6sox | I agree but can't put my finger on it. |
| 17:51.54 | [g2-lap] | I just saved as pdf with abiword |
| 17:52.01 | GyrosGeier | [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 |
| 17:52.04 | [g2-lap] | I'm open to suggestions |
| 17:52.48 | prpplague | [g2-lap]: what was the default font you used? |
| 17:53.01 | ka6sox | prpplague, this BSD machine doesn't have pdftops ;( |
| 17:53.39 | prpplague | ka6sox ahhh |
| 17:53.51 | prpplague | ka6sox might check if they did it as pdf2ps |
| 17:54.14 | [g2-lap] | Bitstream Vera for the heading and Times New Roman for the text |
| 17:54.27 | ka6sox | weird |
| 17:54.28 | prpplague | odd those should be fine |
| 17:54.30 | vmaster | truetype fonts |
| 17:55.37 | prpplague | [g2-lap]: just for giggles try changing all the fonts to just plain courier |
| 17:55.48 | prpplague | [g2-lap]: then resaving it as a pdf |
| 17:55.59 | [g2-lap] | prpplague I can save it as a txt file |
| 17:56.10 | prpplague | hehe that would work as well |
| 17:57.07 | [g2-lap] | well off to lunch bbl |
| 17:57.55 | ka6sox | interesting |
| 17:59.19 | ka6sox | pxa270 isn't bad. |
| 18:00.40 | [g2-lap] | ka6sox glad you could read it |
| 18:01.22 | ka6sox | acroread was able to. |
| 18:03.01 | prpplague | i hate to sound ignorant, but what is "Loft" |
| 18:05.44 | vmaster | looooooooool |
| 18:05.45 | prpplague | i know about the ballon but i've not heard of loft |
| 18:05.54 | vmaster | honestly? |
| 18:06.07 | vmaster | it's the board g2 is producing |
| 18:06.17 | vmaster | he's been talking about it since i first came to this channel |
| 18:06.34 | prpplague | oh |
| 18:06.39 | prpplague | i didn't realize it had a name |
| 18:06.54 | vmaster | http://www.giantshoulderinc.com/hardware.html |
| 18:08.03 | ka6sox | [g2-lap], there isn't any mention of the V3 boards. |
| 18:08.17 | ka6sox | so I assume that its because they are Alpha? |
| 18:08.22 | prpplague | [g2-lap]: ok well i'm still a little confused on the direction of this |
| 18:08.55 | ka6sox | [g2-lap], look at last night's logs here too,. |
| 18:09.21 | prpplague | [g2-lap]: are you wanting a board to do initial testing with? |
| 18:12.54 | prpplague | [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? |
| 18:45.40 | ka6sox | time to go to the 'office' |
| 19:06.13 | [g2-lap] | ka6sox-office what do you mean now mention of the V3 board ? |
| 19:06.42 | [g2-lap] | right they won't be done until end of Q1 or early Q2 |
| 19:06.51 | [g2-lap] | it's wookey__ project |
| 19:07.04 | [g2-lap] | or he's involved significantly with it |
| 19:08.05 | [g2-lap] | prpplague there are two pieces |
| 19:08.17 | [g2-lap] | 1) a high-speed JTAG device |
| 19:08.58 | [g2-lap] | 2) Stuff to generate test vectors and testing for BSDL testing |
| 19:09.21 | [g2-lap] | You can do #2 with a low speed device it just takes forever |
| 19:09.27 | prpplague | right i got that part, just unsure what all the discusion was about an xscale arm device |
| 19:10.28 | [g2-lap] | I think focusing on XScale we can test both the Balloon V3 and the Loft |
| 19:11.08 | prpplague | [g2-lap]: ahh so you want to use the ballon and loft as targets for the initial development |
| 19:11.15 | [g2-lap] | but I think the Balloon V3 (and initally possbily V2 for the test vector generation) makes a super objective |
| 19:11.55 | [g2-lap] | the Loft doesn't really need it and it's not really a fully open platform from the hardware manufacturing standpoint |
| 19:12.30 | prpplague | but you need something that you can get netlist and schematics from so that you can generate the initial vector testing |
| 19:13.11 | [g2-lap] | right. I think we can get access to that stuff for the Balloon. Certain the V2 stuff and probably the V3. |
| 19:13.30 | prpplague | [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 |
| 19:14.01 | [g2-lap] | unfortunately english is my primary language :( |
| 19:14.03 | prpplague | [g2-lap]: well its not xscale, but you could do this for the lnode80 (sharp LH79520 arm720t) |
| 19:14.17 | prpplague | [g2-lap]: oops |
| 19:14.30 | [g2-lap] | it's OK |
| 19:14.40 | [g2-lap] | my writing _does_ need improvement |
| 19:15.10 | prpplague | [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 |
| 19:15.28 | [g2-lap] | excellent |
| 19:16.08 | [g2-lap] | I think there are and will be many more companies that need this kinda capability |
| 19:16.21 | prpplague | we will be shipping a generic HG style jtag dongle with our products, however we are still looking for a high speed solution |
| 19:16.57 | [g2-lap] | the s3c2410 is ARM9T based right ? |
| 19:17.14 | [g2-lap] | I know bewoolie's all of that stuff |
| 19:18.04 | prpplague | [g2-lap]: yea arm920t |
| 19:18.21 | prpplague | yea beewoolie is mainly supporting the sharp products right now |
| 19:18.31 | prpplague | but he's pretty familiar with the range of arm stuff |
| 19:18.32 | [g2-lap] | that's from the sw side |
| 19:18.50 | AchiestDragon | 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 |
| 19:18.54 | prpplague | [g2-lap]: hehe yea, just used to dealing with software folks |
| 19:19.57 | AchiestDragon | hi prpplague |
| 19:20.11 | prpplague | [g2-lap]: i'm trying to talk the boss into selling our first prototype development board because they are so darn "cute" |
| 19:20.38 | prpplague | AchiestDragon: greetings associate from ##mirocontrollers |
| 19:22.37 | [g2-lap] | AchiestDragon are you using the ts7200 ? |
| 19:22.45 | AchiestDragon | yes |
| 19:22.55 | [g2-lap] | Linux, Freebsd, or other ? |
| 19:23.02 | AchiestDragon | debian |
| 19:23.12 | [g2-lap] | that'd be Linux :) |
| 19:23.37 | [g2-lap] | are you running the 2.4 or 2.6.8.1 or other kernel ? |
| 19:23.45 | AchiestDragon | 2.4 |
| 19:23.48 | *** join/#openjtag beewoolie-afk (n=beewooli@206.124.142.26) |
| 19:23.56 | [g2-lap] | beewoolie-afk welcome |
| 19:24.28 | [g2-lap] | beewoolie-afk see http://www.giantshoulderinc.com/projects/openjtag/openjtag.pdf |
| 19:24.30 | beewoolie | hey |
| 19:25.01 | [g2-lap] | AchiestDragon I'm also working on some toolchains/kernel stuff for the ep93xx |
| 19:25.24 | AchiestDragon | k kool |
| 19:25.25 | beewoolie | did you read the logs from yesterday? ka6sox was talking about using an arm9 board, pc104, to drive the JTAG chains |
| 19:26.18 | AchiestDragon | beewoolie: http://www.whipy.demon.co.uk/JTAG.PS < block diagram of the pc104 high speed dongle for use with a ts7200 |
| 19:26.21 | [g2-lap] | actually i haven't but I think AchiestDragon pointed me to the design |
| 19:27.03 | beewoolie | I made a little more progress yesterday. I'm not able to read memory on an ARMv4 target. |
| 19:27.09 | [g2-lap] | 1) problem with the ts7200 is that it's closed platform from the FPGA and loading process |
| 19:27.23 | [g2-lap] | 2) it doesn't scale |
| 19:27.27 | AchiestDragon | it was a genaral post here for others, i just finished the block diagram |
| 19:27.39 | [g2-lap] | meaning lets say you want 16 or 32 devices |
| 19:27.56 | [g2-lap] | you have to get 16 or 32 tsboards and adapters |
| 19:28.19 | [g2-lap] | where if you've got a USB 2.0 to FPGA, just plug them into a hub |
| 19:28.51 | [g2-lap] | So a Loft with 2 4-port hubs could support 8 devices out of the box |
| 19:28.54 | AchiestDragon | 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 |
| 19:29.05 | vmaster | how much is the ts7200? |
| 19:29.25 | [g2-lap] | they were like $150 last year |
| 19:30.14 | AchiestDragon | still arround the $140 range dependent on the options you get |
| 19:30.22 | [g2-lap] | for this market really anything below < $1K is cheap for the customer |
| 19:30.48 | [g2-lap] | you guys are probably not all ready to go spending a couple K for test devices though |
| 19:30.59 | beewoolie | [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? |
| 19:31.30 | [g2-lap] | beewoolie it doesn't have to be, but scaling is important longer term |
| 19:31.32 | beewoolie | The only problem I see with using USB as the network is that its slow. |
| 19:31.50 | AchiestDragon | we seem to have set a $250 target cost for the h/w |
| 19:32.17 | [g2-lap] | beewoolie I don't call 30-40MBs slow |
| 19:32.35 | beewoolie | [g2-lap]: The protocol is inefficient WRT round-trip times. |
| 19:32.49 | beewoolie | Moreover, you won't get that much throughput when you start linking lots of them together. |
| 19:33.07 | [g2-lap] | beewoolie nod, but the question is how much RTT messages will there be ? |
| 19:33.13 | *** join/#openjtag Tiersten (n=tman@nslu2-linux/Tiersten) |
| 19:33.18 | vmaster | that depends on how you partition the problem |
| 19:33.22 | [g2-lap] | beewoolie I think the traffic is really bursty |
| 19:33.28 | beewoolie | There are some operations where RTTs will help alot in solving the problem well. |
| 19:33.52 | beewoolie | The only person here who has done this (as far as I can tell) is vmaster. |
| 19:34.12 | [g2-lap] | well Gateworks tests there boards :) |
| 19:34.19 | [g2-lap] | s/there/their/ |
| 19:34.40 | [g2-lap] | wookey__ has probably done it with other tools on V2 |
| 19:34.42 | beewoolie | 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. |
| 19:35.19 | beewoolie | For your target market, what is wrong with a PC104 stack? |
| 19:35.48 | [g2-lap] | My issues with PC104 are the following: |
| 19:35.58 | [g2-lap] | 1) The form factor is more expensive |
| 19:36.13 | beewoolie | [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. |
| 19:36.19 | [g2-lap] | 2) I there isn't an open platform |
| 19:36.21 | AchiestDragon | with the pc104 design it should be able to burst read or write upto 32mbytes of data to from the jtag at 40Mhz |
| 19:36.53 | [g2-lap] | Scaling with ethernet is less than scaling with USB 2.0 |
| 19:38.06 | [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 |
| 19:38.17 | [g2-lap] | that's sustained |
| 19:39.01 | vmaster | does anyone know how large a typical pcb test vector set is? |
| 19:39.01 | AchiestDragon | 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 |
| 19:39.44 | [g2-lap] | AchiestDragon now you are potentially talking |
| 19:39.56 | [g2-lap] | lennert has driven a Pong program for the FPGA |
| 19:40.57 | [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 |
| 19:41.04 | AchiestDragon | 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 |
| 19:41.23 | beewoolie | [g2-lap]: I think you overestimate the bandwidth of USB. It's shared. |
| 19:41.30 | beewoolie | Ethernet has switches which are not shared. |
| 19:41.54 | [g2-lap] | beewoolie it's measured BW |
| 19:41.56 | beewoolie | If you load-up the USB, you won't see that kind of throughput on every node. You'll see an aggregate bandwaidth. |
| 19:42.05 | beewoolie | For one device. |
| 19:42.21 | vmaster | with one host, ethernet bandwidth is shared, too |
| 19:42.37 | [g2-lap] | fully agrees, but I think that the problem of testing is bursty |
| 19:42.58 | [g2-lap] | Load a megabyte or two and test for 5-10 mintues or longer |
| 19:43.08 | [g2-lap] | ship the results back |
| 19:43.15 | beewoolie | USB will only allow one host. Ethernet allows many hosts. |
| 19:44.00 | beewoolie | 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. |
| 19:44.18 | [g2-lap] | a big state machine |
| 19:44.24 | AchiestDragon | 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 |
| 19:44.49 | [g2-lap] | AchiestDragon maxes out at 11MBs |
| 19:45.04 | beewoolie | 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. |
| 19:45.31 | [g2-lap] | well it's a complex and costly problem |
| 19:45.45 | [g2-lap] | that's why the current solutions are $10-20K |
| 19:46.23 | [g2-lap] | besides when doing a 10K production run that's only $1 per board |
| 19:46.24 | AchiestDragon | there has to be a compramise at some point , over the 10 to 20k solutions |
| 19:47.00 | [g2-lap] | AchiestDragon I don't think there is any fundamental limit here |
| 19:47.48 | beewoolie | [g2-lap]: but a solution with a CPU core and an FPGA accelerator is much easier for us to program. |
| 19:48.14 | beewoolie | From a design standpoint, the FPGA design is far costlier |
| 19:48.16 | AchiestDragon | 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 |
| 19:48.55 | beewoolie | 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. |
| 19:49.09 | prpplague | beewoolie: i'm updating my s3c2410 patch against the latest apex, should get you a new version friday |
| 19:49.20 | beewoolie | An FPGA that can run tests is much more complex. it has to make decisions and guide the test. |
| 19:49.28 | beewoolie | prpplague: excellent. |
| 19:49.58 | AchiestDragon | 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 |
| 19:50.13 | AchiestDragon | but cost is the issue |
| 19:50.31 | prpplague | 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 |
| 19:50.52 | vmaster | beewoolie: do you have your protocol documented somewhere? |
| 19:51.46 | beewoolie | 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. |
| 19:52.22 | beewoolie | 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. |
| 19:53.44 | vmaster | the ftdi "protocol" just specifies the direction of the scan (in, out, inout), the type (tms, tdi) and the number of bits/bytes |
| 19:53.59 | beewoolie | Is it documented? |
| 19:54.16 | vmaster | yeah, hold on |
| 19:54.21 | beewoolie | Excellent. |
| 19:55.02 | beewoolie | [g2-lap]: How much do you want these USB dongles to cost? |
| 19:55.15 | vmaster | http://ftdichip.com/Documents/AppNotes/AN2232C-01_MPSSE_Cmnd.pdf |
| 19:55.38 | [g2-lap] | beewoolie I think I can get a prototype run produced for < $100 a piece |
| 19:56.16 | vmaster | i've started defining a more capable protocol here: http://openocd.berlios.de/web/?page_id=22 |
| 19:56.21 | [g2-lap] | the real question is whether they are enough and whether there enough JTAG expertise to utilize them |
| 19:56.26 | beewoolie | OK. I'll read that, too. |
| 19:57.25 | beewoolie | The protocol I've been working on is core agnostic. |
| 19:57.37 | beewoolie | it's really just about running the JTAG chain. |
| 19:57.51 | ka6sox-office | and that the FPGA needs to do. |
| 19:58.01 | beewoolie | My aversion to core specific protocol elements is that it will require updating for new cores. |
| 19:58.13 | vmaster | that's my plan, too |
| 19:58.37 | beewoolie | 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. |
| 19:58.47 | [g2-lap] | well I think the problem domain breaks into generic JTAG and core specific JTAG |
| 19:59.13 | beewoolie | 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. |
| 19:59.30 | vmaster | that's an example about how it maps to arm7/9 debugging |
| 19:59.38 | vmaster | which is what i know about |
| 19:59.39 | beewoolie | Oh. Macros. |
| 19:59.42 | [g2-lap] | vmaster do you have to log into get access to that document ? |
| 19:59.55 | vmaster | no |
| 20:00.21 | vmaster | it's more like a command-interpreter |
| 20:00.29 | [g2-lap] | vmaster ahh... worked on the refresh |
| 20:01.20 | vmaster | my idea is that the latency critical stuff is waiting for a scan to match a test pattern |
| 20:01.41 | beewoolie | 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. |
| 20:02.18 | ka6sox-office | my major concern here is that the design is still in "alpha" for the pxa board and we can't get hardware. |
| 20:02.23 | beewoolie | Once we go to remote scan operation, the complexity goes way up. |
| 20:02.50 | beewoolie | ...compares, loops... |
| 20:03.25 | beewoolie | I'll review what I've got and get back to you all. |
| 20:03.44 | lennert | i've been away the last 6 hrs.. anything important happened? |
| 20:03.56 | [g2-lap] | hey lennert |
| 20:04.01 | ka6sox-office | more than in the last 5 months combined |
| 20:04.09 | [g2-lap] | heh |
| 20:04.53 | ka6sox-office | [g2-lap], its true...between what you have done and what others are working on its true. |
| 20:05.11 | [g2-lap] | lennert take a look at this http://www.giantshoulderinc.com/projects/openjtag/openjtag.pdf |
| 20:05.34 | [g2-lap] | ka6sox-office this is all a work-in-progress |
| 20:05.46 | [g2-lap] | it's great to see so much excitement and envolvement |
| 20:05.56 | ka6sox-office | ya |
| 20:06.22 | [g2-lap] | I think having focused problem domains and goals will help |
| 20:07.04 | [g2-lap] | we may all agree on a common domain and platform, or we may have a dozen with some or no overlap |
| 20:07.21 | ka6sox-office | back in 30 minutes |
| 20:07.25 | ka6sox-office | (meeting) |
| 20:09.50 | AchiestDragon | 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 |
| 20:11.07 | AchiestDragon | and with a 40mhz jtag clock there should be problem with speed delays doing that |
| 20:16.47 | [g2-lap] | AchiestDragon my uninformed understand of the problem space this: |
| 20:17.10 | [g2-lap] | It's the scan long scan chains that need the high clock rate |
| 20:17.34 | [g2-lap] | example the IXP42x scan chain is 498 bits long |
| 20:18.30 | [g2-lap] | so the compare only need to happen at a relatively long interval relative to the TCLK |
| 20:19.46 | [g2-lap] | if TCLK was running a 49.8Mhz, compares would only need to happend at 100K Hertz rate for once every scanchain operation |
| 20:19.50 | [g2-lap] | correct ? |
| 20:20.16 | AchiestDragon | 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 |
| 20:20.44 | AchiestDragon | or is at a perticular state |
| 20:21.18 | AchiestDragon | with the hosting micro only needing to process an interupt on the event detection |
| 20:21.53 | [g2-lap] | I don't understand why you wouldn't want that state machine on the FPGA |
| 20:22.28 | AchiestDragon | it can be implimented on the fpga |
| 20:22.58 | [g2-lap] | ok, I think we are saying the same thing then |
| 20:23.22 | vmaster | okay, as i understand it, svf is designed for this kind of application |
| 20:23.55 | [g2-lap] | the XJTAG tool uses svf |
| 20:24.09 | [g2-lap] | so you are probably correct :) |
| 20:24.11 | vmaster | 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 |
| 20:24.43 | [g2-lap] | is there an SVF link somewhere ? |
| 20:24.58 | vmaster | http://www.asset-intertech.com/support/svf.html |
| 20:25.03 | [g2-lap] | THX |
| 20:26.44 | [g2-lap] | vmaster looks like a good link |
| 20:27.27 | AchiestDragon | 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 |
| 20:28.32 | vmaster | AchiestDragon: i believe this is fine for the desired application |
| 20:28.35 | AchiestDragon | 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 |
| 20:29.19 | vmaster | the macraigor videos for their j-scan show nicely what such an analyzer is supposed to do |
| 20:30.38 | AchiestDragon | 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 |
| 20:31.16 | AchiestDragon | with an alternate set of buffers , and some switching it could operate as a 16 bit logic analizer |
| 20:32.48 | AchiestDragon | 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 |
| 20:33.17 | AchiestDragon | its easy to impliment as a soft ip core |
| 20:33.37 | AchiestDragon | if provision for it has been included in the buffers |
| 20:34.33 | AchiestDragon | so a 40Mhz 16bit logic analizer on the same platform also for a couple of extra buffers |
| 20:37.01 | AchiestDragon | that should help hobby users in solving problems of miss timeing that the jtag pin state display could not |
| 20:40.10 | AchiestDragon | 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 |
| 20:40.39 | [g2-lap] | looks interesting :) http://www.intellitech.com/products/ultratestaccessport.asp |
| 20:43.49 | vmaster | heh, and at least as expensive as interesting |
| 20:44.24 | velinp | 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? |
| 20:47.43 | [g2-lap] | http://www.acculogic.com/index.php?content=product&category=bs&id=scanmaster#_self |
| 20:48.15 | [g2-lap] | http://www.acculogic.com/index.php?content=product&category=bs&id=scanmaster#_self |
| 20:48.32 | prpplague | interesting |
| 20:48.40 | prpplague | home much is that? |
| 20:54.07 | [g2-lap] | http://www.acculogic.com/index.php?content=product&category=bs |
| 21:41.54 | lennert | the ftdi protocol looks sane enough |
| 21:41.59 | lennert | from a cursory glance |
| 21:45.04 | vmaster | yeah, there's nothing wrong with it, but it's limited |
| 21:46.22 | lennert | does it need anything else? |
| 21:46.46 | lennert | i only see the case for a more complicated protocol if pc<->jtag latency is high |
| 21:46.52 | lennert | but if it is, you've got other problems anyway |
| 21:46.57 | vmaster | latency is high |
| 21:47.06 | vmaster | 1-2ms |
| 21:47.12 | lennert | well, yeah, on the ftdi |
| 21:47.19 | lennert | but we can very well take the protocol and use it elsewhere |
| 21:47.28 | lennert | i just meant the protocol itself looks okay (iff latency is okay) |
| 21:47.57 | vmaster | it comes down to partioning the problem - where you want to do what |
| 21:48.00 | vmaster | +t |
| 21:48.10 | vmaster | +i |
| 21:48.39 | lennert | indeed |
| 21:48.50 | lennert | and doing more than the ftdi protocol does in hardware is just too complex, imho |
| 21:48.55 | lennert | unless you want to make stuff target-specific |
| 21:49.10 | lennert | or is there one step beyond ftdi that isn't too complex? |
| 21:49.21 | lennert | i don't see what other functionality you can add without going 'all the way' |
| 21:49.45 | vmaster | that's what i'm trying to find out |
| 21:50.04 | lennert | ok.. how are you trying to find that out? |
| 21:50.17 | vmaster | http://openocd.berlios.de/web/?page_id=22 is what i'd like a jtag protocol to do |
| 21:51.01 | vmaster | this could be implemented easily on a small uC with a fast serial interface |
| 21:51.29 | vmaster | or on a fpga with a soft-core |
| 21:52.15 | [g2] | or on a fpga with a hard-core |
| 21:52.37 | lennert | or directly on the h/w ;-) (/me wrote half of a vt100 emulator in h/w) |
| 21:53.00 | vmaster | heh, even better if you can do that in h/w |
| 21:53.35 | [g2] | at my last startup the did IP proessing in the FPGAs |
| 21:53.46 | [g2] | Internet Protocol V4 |
| 21:54.01 | [g2] | it's possible, just quite costly |
| 21:54.24 | [g2] | I was the token Network Processor guy |
| 21:55.35 | [g2] | 18 months into the project they looked at NPUs a little differently than the beginning :) |
| 21:55.58 | lennert | well, NPUs are like asics but with a shorter turnaround time.. |
| 21:56.04 | lennert | and slightly easier to code for, but not much |
| 21:56.19 | [g2] | way easier |
| 21:56.25 | [g2] | and debug too |
| 21:56.38 | lennert | the ixp2000 is not so easy to code for ;) |
| 21:56.49 | lennert | in fact, packet rx/tx on the xupv2p board is way easier than on the ixp2000 |
| 21:56.58 | lennert | maybe npus have changed a lot though |
| 21:57.11 | [g2] | are you running packets on the xupv2p ? |
| 21:57.19 | lennert | ya |
| 21:57.24 | [g2] | Gigabit ? |
| 21:57.31 | lennert | 100Mb |
| 21:58.18 | [g2] | lennert you're probably not interested in 100Mb packet filtering with netfilter/iptables much |
| 21:58.44 | lennert | for 100Mb you don't need an fpga |
| 21:58.54 | lennert | but it's still easier to code for than on the ixp2000.. :) |
| 21:58.58 | [g2] | no I've got a Loft :) |
| 21:59.38 | [g2] | Are you planning on putting GigE on there ? |
| 22:00.56 | [g2] | will that support GigE ? |
| 22:03.51 | [g2] | lennert are there hard-cores on that board ? |
| 22:04.23 | vmaster | v2p has the ppc405 |
| 22:04.41 | [g2] | vmaster I think some have up to 4 |
| 22:04.58 | [g2] | Ah.... 2 PPC cores |
| 22:07.41 | lennert | yeah, two ppcs |
| 22:07.59 | ka6sox-office | 405's are no slouch |
| 22:08.06 | [g2] | but no floating point :( |
| 22:08.35 | [g2-lap] | I like this http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/13010F4A79FC026C87256DFA004D30D0#4 |
| 22:09.02 | lennert | i kind of got one of the ppcs to work, at least, i got it to fetch instructions. but i didn't try further. |
| 22:09.23 | lennert | i'm stubborn and don't want to use xilinx ip, so that makes it a lot more work to get it running |
| 22:09.59 | [g2] | bare-metal lennert :) |
| 22:11.25 | lennert | "needs 5x more time than other people to understand stuff" lennert |
| 22:12.09 | [g2] | yeah but you understand stuff 20x better so it works out as a 4x advantage |
| 22:12.34 | vmaster | 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 |
| 22:13.04 | [g2] | well both in 8-bit mode :) |
| 22:13.20 | [g2] | it's just 16 and 32-bit that are in question :) |
| 22:13.30 | vmaster | mhh, no, that question is valid for 8-bit mode, too |
| 22:13.54 | vmaster | data is always returned in the least significant byte |
| 22:14.02 | vmaster | d0-d7 |
| 22:14.15 | vmaster | but there are fields in the query structures that are two or four bytes long |
| 22:16.47 | *** part/#openjtag velinp (n=velinp@c88-163.cable.netissat.bg) |
| 22:17.47 | [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 |
| 22:18.23 | vmaster | it takes multiple reads on a x16 or x32 device, too |
| 22:19.08 | [g2] | right but there is an endianness queston on the data arriveing on d15-d8 and d7-d0 |
| 22:19.32 | [g2] | Does it arrive 0xAA 0xBB or 0xBB 0xAA |
| 22:19.42 | vmaster | there's no data arriving at d15-d8 |
| 22:20.14 | vmaster | cfi queries return 0x0 on d15-d8 |
| 22:20.16 | [g2] | I an tell you the Flash on the IXP42x is programmed for 16-bit wide access |
| 22:20.31 | vmaster | ah, i'm talking specifically about the cfi queries |
| 22:20.31 | [g2] | Redboot is byte swapped before programming |
| 22:21.07 | [g2] | well I'd think the CFI would match up with the data |
| 22:22.00 | [g2] | meaning I could possibly have the bus in the wrong order and reorder the commands and it'd all work out |
| 22:22.21 | [g2] | like jbowler byte swapping the kernel command line and booting into LE |
| 22:22.42 | lennert | vmaster: okay, so it's like some kind of macro functionality (advanced jtag thingo) |
| 22:22.57 | vmaster | yeah, a kind of interpreter |
| 22:23.13 | vmaster | with sub-routines |
| 22:23.17 | vmaster | or macros, if you want |
| 22:23.35 | vmaster | that's just to reduce the bandwith needs |
| 22:23.39 | lennert | yeah |
| 22:23.42 | lennert | but it won't help with latency |
| 22:24.20 | vmaster | it would help in all cases where you're polling for a scan to match |
| 22:24.31 | lennert | right |
| 22:24.58 | vmaster | and i believe these are the latency-critical parts |
| 22:25.17 | vmaster | at least i couldn't come up with anything else yet |
| 22:26.18 | vmaster | this would also support some "trigger" functionality, like AchiestDragon (iirc) suggested yesterday or so |
| 22:26.52 | vmaster | when doing boundary-scan analysing you set a trigger on "pin reads high" and continue capturing at that point |
| 22:27.20 | vmaster | when doing flash writes you wait for the nBusy line going high |
| 22:27.44 | vmaster | though flash writing might not really be timing critical |
| 22:27.53 | vmaster | so you probably wont be checking the busy bit |
| 22:28.21 | [g2] | vmaster I think for flashing it might be better to do that from within the processor in may cases |
| 22:28.41 | [g2] | iirc loading the i-caches is only 40bits |
| 22:28.53 | [g2] | for a 32-bit word |
| 22:29.39 | [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 |
| 22:29.59 | vmaster | yeah, sure, same goes for arm7/9 |
| 22:30.07 | [g2] | The exception would be when you want to externally verfiy the flash |
| 22:30.19 | vmaster | or where you have a yet unsupported target |
| 22:30.28 | vmaster | that's the fine thing about the jtag-0.5.1 stuff |
| 22:30.38 | vmaster | all you need is a bsdl file |
| 22:31.32 | [g2] | I'd be interested in knowing how the arm7/9 differ among chips |
| 22:32.27 | [g2] | meaning is there much difference between the Cirrus 93xx, the Sharp chips and the Samsung |
| 22:32.46 | beewoolie-afk | [g2]: The cores all have the same embedded ice HW. |
| 22:32.48 | vmaster | 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 |
| 22:33.05 | beewoolie-afk | Small timing differences. |
| 22:33.29 | [g2] | beewoolie-afk that makes a lot of sense |
| 22:33.30 | beewoolie-afk | I was under the impression that the arm7 was a harvard architecture as well. |
| 22:34.00 | [g2] | The Cirrus can boot from the serial port, can the Sharp and Samsung do that trick too ? |
| 22:34.14 | beewoolie-afk | Using the BSDL file to manipulate memory is inherently more tricky since you don't know how the CPU views the devices. |
| 22:34.37 | beewoolie-afk | That's reflected in the fact that openwince's jtag SW has to swap data before writing to flash. |
| 22:34.46 | beewoolie-afk | When we use the CPU, that isn't (as much) of a consideration. |
| 22:35.26 | beewoolie-afk | 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. |
| 22:35.27 | [g2] | It'd be interesting to run the jtag sw on MAC |
| 22:35.36 | beewoolie-afk | vmaster: I'm coming around to your way of thinking. |
| 22:35.47 | beewoolie-afk | I need to muse a bit more about what we think we can do. |
| 22:35.48 | [g2] | I don't know if it recognizes it's own endianness or just always swaps |
| 22:36.27 | beewoolie-afk | I can [kinda-of] guarantee that a simpler protocol will be feature complete. this interpreter method is more difficult for achivieving provable-completeness. |
| 22:36.43 | beewoolie-afk | [g2] It doesn't exactly matte.r |
| 22:36.58 | beewoolie-afk | When you use the CPU to access memory, it access memory the way it *always* access memory. |
| 22:37.00 | [g2-lap] | According to this we're gonna be very limited on clock rates unless we've got a very short cable right ? |
| 22:37.04 | [g2-lap] | http://www.acculogic.com/index.php?content=product&category=bsinfo&id=sol#_self |
| 22:37.07 | vmaster | beewoolie-afk: the arm7 is von-neumann |
| 22:37.12 | beewoolie-afk | I've been told that. |
| 22:38.21 | vmaster | [g2-lap]: yeah |
| 22:39.03 | vmaster | Arm's realview ice uses lvds to overcome this problem |
| 22:40.54 | [g2] | vmaster I'd imagine the traces on the board factor into the signal propagation delay (as does the connector) |
| 22:41.13 | vmaster | ah, yeah, acculogic addresses a different problem |
| 22:41.19 | beewoolie-afk | 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. |
| 22:41.59 | vmaster | yeah, i agree on that |
| 22:42.17 | lennert | [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 |
| 22:42.19 | [g2] | yeah me to, but latency kills |
| 22:42.30 | vmaster | but i'm not sure if there's a simpler solution |
| 22:42.51 | vmaster | well, there is, if you're going the ka6sox/AchiestDragon way |
| 22:43.14 | vmaster | but that means shifting all of the target-logic into the "dongle" |
| 22:44.40 | [g2] | Ok can we call the ka6sox / AchiestDragon the 104 solution ? |
| 22:46.03 | beewoolie-afk | I'll post a protocol document tonight...as long as dollface doesn't object. |
| 22:46.05 | [g2] | In the 104 solution, the FPGA might as well be a CPLD |
| 22:46.35 | [g2] | because it just acts like a big parallel to serial shift register right ? |
| 22:46.36 | AchiestDragon | a cpld will not allow for reconfiguration on the fly |
| 22:47.12 | vmaster | you can bitbang the cpld's jtag port from the uC if you want |
| 22:47.15 | [g2] | and what rereconfiguration will be done ? |
| 22:48.32 | [g2] | dinner |
| 22:48.36 | AchiestDragon | whatever you want , so it cann allow you to configure a mor complex spft ip core for some tasks if needed |
| 22:49.33 | AchiestDragon | cann = can , mor=more spft= soft |
| 22:51.10 | ka6sox-office | reconfiguring the FPGA "on the fly" will still require the FPGA to be offline during programming. |
| 22:51.29 | ka6sox-office | and the FPGA will be Tri-Stated at that point. |
| 22:52.12 | AchiestDragon | yes |
| 22:53.04 | ka6sox-office | but that won't crash anything. |
| 22:53.47 | ka6sox-office | the TS7200 has 1.8V (which I think is the Core voltage of the S3) |
| 22:54.21 | vmaster | i guess g2's point was that for the purpose of jtagging, a cpld would be enough |
| 22:54.35 | lennert | ka6sox-office: s3 core is 1.2V |
| 22:54.45 | lennert | ka6sox-office: IOs are 1.2V to 3.3V, and Vaux is 2.5V |
| 22:55.55 | ka6sox-office | lennert: thanks. |
| 22:56.00 | ka6sox-office | vmaster: probably |
| 22:56.11 | AchiestDragon | 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 |
| 22:56.19 | ka6sox-office | but that isn't the total aim of the project..it includes debugging as well. |
| 22:56.34 | AchiestDragon | yes |
| 22:56.52 | ka6sox-office | and maybe some Logic Analysis. |
| 22:57.34 | ka6sox-office | (having used LA's to debug busses and Kernel issues I know the value) |
| 22:57.50 | AchiestDragon | and when debugging we may need a few diferent ip cores depending on the task , that would be not as flexible with a cpld |
| 22:59.02 | vmaster | heh, we need a glossary so everyone uses the same terms |
| 23:00.56 | ka6sox-office | vmaster: we have a wiki :) |
| 23:00.59 | ka6sox-office | it can go there. |
| 23:02.22 | vmaster | heh, yeah, i'm just trying to figure out how to create a new page ;) |
| 23:03.05 | vmaster | do i want Glossary.Glossary, Glossary.HomePage or Main.Glossary? |
| 23:04.47 | ka6sox-office | lemme ask somebody...brb |
| 23:05.34 | ka6sox-office | put it in Main.Glossary and we can move it. |
| 23:08.34 | ka6sox-office | in FPGA's they use different terms for the same thing (different manufacturers) |
| 23:19.04 | *** join/#openjtag ByronT_ (i=byron-po@nslu2-linux/ByronT) |
| 23:29.39 | ka6sox-office | bbiaf |
| 23:41.28 | vmaster | http://www.openjtag.net/wiki/Main/Glossary |
| 23:44.23 | vmaster | i'm off - n8 everyone |
| 23:44.33 | beewoolie-afk | later. |