| 00:21.57 | *** join/#openjtag ByronT (n=byron-po@nslu2-linux/ByronT) |
| 03:05.27 | ka6sox-office | 4am in Europe...sleeping people. |
| 04:45.21 | key2 | 5:47 u mean :) |
| 04:46.02 | ka6sox-office | ah..20:47 here |
| 04:47.39 | key2 | where are you ? Cali ? |
| 04:50.56 | ka6sox-office | ya |
| 04:51.18 | key2 | where about ? |
| 04:51.30 | ka6sox-office | Santa Barbara |
| 06:53.44 | *** join/#openjtag ep1220 (n=NN@gate.epatec.at) |
| 07:45.40 | *** join/#openjtag odoc (i=odoc@is.borntobooze.de) |
| 07:58.12 | *** join/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 10:20.42 | *** join/#openjtag vmaster_ (i=vmaster@p549B7D78.dip.t-dialin.net) |
| 11:57.16 | *** join/#openjtag Tiersten (i=tman@nslu2-linux/Tiersten) |
| 13:07.42 | vmaster | hmm... avnet has a spartan-3e devkit for 69$ - but with 26 weeks lead time :( |
| 13:08.06 | ep1220 | that one is not yet released |
| 13:08.26 | ep1220 | tough xilinx said Q4/2005 |
| 13:10.50 | ep1220 | just checked, they now say: The Spartan-3E Starter Kit target availability is December, 2005. but cost there is 149$ + shipping |
| 13:11.58 | vmaster | yeah, the avnet kit comes with a S100E and now RAM |
| 13:12.09 | vmaster | *no |
| 13:12.28 | vmaster | xilinx is probably a better deal |
| 13:12.47 | ep1220 | yep |
| 13:13.22 | ep1220 | on import they will also add german VAT |
| 13:13.53 | vmaster | mhh, yeah, but that's less than $ <-> EUR :) |
| 13:16.16 | ep1220 | if you need to start faster You can buy a Spartan-3 Kit + USB IF at digilentinc.com this then also is approx. 150$ |
| 13:18.56 | vmaster | mhh, i already have my virtex2 kit with usb, this should be enough for testing |
| 13:19.40 | ep1220 | Spatan 3 kit uses a Cypress USB controller. |
| 13:19.48 | ep1220 | this controller does EPP |
| 13:20.20 | ep1220 | You include an EPP interface in your FPGA design to commuicate over USB |
| 13:20.30 | ep1220 | does the virtex operate the same way ? |
| 13:20.48 | vmaster | epp? |
| 13:20.52 | vmaster | like parallel-port? |
| 13:20.55 | ep1220 | yes |
| 13:21.30 | ep1220 | though i do not know if it is fully EPP compliant |
| 13:21.32 | vmaster | it uses a FT245BM |
| 13:21.38 | vmaster | so it's a parallel interface |
| 13:21.40 | vmaster | 8-bit |
| 13:21.44 | vmaster | not sure about the strobe lines |
| 13:22.13 | ep1220 | then i guess it is different. |
| 13:24.45 | ep1220 | With the 3E board You do not get the Cypress Code not specs of the USB protocol |
| 13:24.54 | ep1220 | All you get is a windows DLL |
| 13:27.38 | ep1220 | well, ie. with the Spartan 3 board - i juts think they use the same for the 3E |
| 13:43.22 | vmaster | well, worst case would be to write the cypress code ourself |
| 13:44.41 | ep1220 | some extra work, and You can not debug with the module digilentinc sells |
| 13:45.59 | ep1220 | no serial IF accessible |
| 16:26.16 | *** join/#openjtag ByronT (n=byron-po@nslu2-linux/ByronT) |
| 16:53.11 | *** part/#openjtag odoc (i=odoc@is.borntobooze.de) |
| 17:19.53 | *** join/#openjtag key2 (n=key2@gob75-2-81-56-64-17.fbx.proxad.net) |
| 17:19.55 | key2 | hi |
| 17:20.05 | vmaster | hey |
| 17:20.13 | key2 | anyone has some experiances with verilog ? |
| 17:20.55 | vmaster | mhh, not sure, lennert possibly |
| 17:21.08 | key2 | lennert ? |
| 17:21.23 | key2 | there are no channels on vhdl and verilog out here |
| 17:21.51 | vmaster | what do you want to know? |
| 17:24.22 | key2 | I basically wanted to know why that doesn't work: always @(posedge htread or posedge rd) rdone <= ~rdone; |
| 17:26.32 | vmaster | do you get a syntax error? or does it fail to synthesize? |
| 17:28.16 | key2 | ERROR:Xst:899 - "ejtag.v" line 57: The logic for <rdone> does not match a known FF or Latch template. |
| 17:28.24 | vmaster | yeah, synthesize failur |
| 17:28.32 | vmaster | split it into two statements |
| 17:28.46 | key2 | like what ? |
| 17:29.05 | vmaster | always @(posedge hthread) rdone <= ~rdone; |
| 17:29.20 | vmaster | well, actually, you have to rethink all of it |
| 17:29.31 | key2 | yeah but then I can't do a always @(posedgle rd) rdone <= ~rdone |
| 17:29.38 | vmaster | there has to be a way to map this to a flip-flop |
| 17:29.42 | key2 | because I would be setting rdone at two different places |
| 17:30.04 | key2 | how would u do it in vhdl ? |
| 17:30.29 | key2 | I basically want to do a JTAG controller in verilog |
| 17:30.40 | vmaster | make a process sensitive to clk, act on the rising edge of clk, and use htread and rd as clock enables |
| 17:31.26 | vmaster | in hdl, everything should be synchronous - otherwise you'll get stuck in a nightmare of timing issues |
| 17:32.30 | key2 | assign ce = (clk & rd)| (clk & htread) |
| 17:32.50 | key2 | then always @(posedge ce) rdone <= ~rdone ? |
| 17:35.07 | vmaster | check the xst docs - there should be examples of verliog-templates for all kind of constructs |
| 17:35.38 | key2 | that seams to work |
| 17:40.12 | key2 | if I have that kind of statement: always @(a) for(i = 0; i < 10; i ++) test = ~test; |
| 17:40.24 | key2 | is it everytime a changes state that i <= i++ ? |
| 17:40.52 | vmaster | always @(posedge C) begin if (CE) Q <= D; end <- that's what xilinx recommends for a flip-flop with clock enable |
| 17:41.27 | vmaster | the if could be "rd | htread" in your case |
| 17:43.06 | key2 | yeah but what if one of the signal comes from outside the FPGA, like an input |
| 17:43.18 | vmaster | then you have to synchronize it before |
| 17:43.25 | key2 | with the clk ? |
| 17:43.28 | vmaster | yep |
| 17:43.32 | key2 | ok |
| 17:43.36 | vmaster | you have to use one clock throughout your design |
| 17:44.01 | key2 | you are familiar to vhdl ? |
| 17:44.02 | vmaster | whenever you cross a clock domain (outside -> inside, faster-clock -> slower-clock) you have to synchronize the signals |
| 17:44.14 | vmaster | more than with verilog |
| 17:44.27 | vmaster | i started a jtag controller design myself a few weeks ago |
| 17:44.37 | key2 | ah really ? |
| 17:44.42 | key2 | basically what is yours gonna do ? |
| 17:44.56 | vmaster | shift data to TMS or TDI, and capture TDO |
| 17:45.07 | key2 | ok |
| 17:45.12 | key2 | for a read/write/readwrite |
| 17:45.13 | key2 | ? |
| 17:45.37 | vmaster | yeah, it would do that every time, but the host could decide not to care about the read data |
| 17:46.15 | key2 | ok I wanted to design something that could handle EJTAG |
| 17:46.30 | vmaster | yeah, i saw your conversation in my backlog |
| 17:46.44 | key2 | do you think it's easy to do ? |
| 17:47.06 | vmaster | i had a brief look at the mips docs - ejtag is basically JTAG + the target specific stuff, right? |
| 17:47.13 | key2 | yeah |
| 17:47.30 | vmaster | the jtag-shifting is trivial, i believe i got that right |
| 17:47.38 | key2 | yeah |
| 17:47.40 | vmaster | my design had a serious flaw in the host-connection |
| 17:48.14 | vmaster | what's going to be harder it the target specific stuff - do you want to implement that in hardware? |
| 17:48.18 | key2 | basically EJTAG_DMA_READ === few 2 instructions and 2 ReadWrite with a flag control between |
| 17:48.34 | key2 | well I wanted to put it on a fpga yeah |
| 17:48.48 | key2 | basically I want to use a FTDI chip to be able to read and write fast from USB |
| 17:49.51 | key2 | what simulator do you use ? Modelsim ? |
| 17:49.57 | vmaster | yeah |
| 17:50.19 | key2 | you have a nice tutorial ? |
| 17:50.27 | key2 | how did you learn ? |
| 17:50.37 | vmaster | unfortunately not - all learning-by-doing |
| 17:51.17 | vmaster | mhh, and the documentation that came with modelsim |
| 17:51.32 | key2 | I used a 75Mips microcontroller first to do some ejtag reading/writing |
| 17:51.34 | *** join/#openjtag GCMOTTA (n=t7DS@200.237.66.12) |
| 17:51.38 | key2 | it's just 2x faster than the // port of the PC |
| 17:51.43 | key2 | so it's not that interesting |
| 17:52.05 | vmaster | hmm... philips lpc parts are capable of bit-banging at ~15mhz |
| 17:52.20 | key2 | are there expensive ? |
| 17:52.34 | vmaster | you can buy dev boards from olimex for ~80 euros |
| 17:52.49 | vmaster | there's a wide variety, some including usb ports or even ethernet ports |
| 17:52.50 | key2 | where are you from :) talkin in euros ? |
| 17:52.55 | vmaster | .de |
| 17:53.05 | vmaster | and you're from france |
| 17:53.10 | vmaster | right? |
| 17:53.12 | GCMOTTA | I have erased the bootloader from my trendnet 411brp+ router and now i need the file to reflash via jtag, where can I get a new cfe file? |
| 17:53.14 | vmaster | at least your hostname is |
| 17:54.45 | key2 | yeah |
| 17:54.46 | key2 | http://www.olimex.com/dev/index.html |
| 17:54.51 | key2 | is that the one you're talkin about ? |
| 17:55.02 | Tiersten | GCMOTTA: Either try downloading a firmware update from the manufacturer and seeing if it is part of the binary OR find a site that specialises in producing third party firmware for that router. |
| 17:55.41 | vmaster | key2: yeah |
| 17:55.54 | key2 | where do you see the prices ? |
| 17:57.09 | GCMOTTA | <Tiersten> The file from trendnet is just the firmware.trx, there is a source code too in the site. |
| 17:57.26 | vmaster | mhh, there was a posting of a olimex representative to some mailing-lists |
| 17:57.53 | Tiersten | GCMOTTA: You'll have to find somebody with the same router and have them dump a copy of the bootloader if so |
| 17:58.08 | key2 | ok |
| 17:58.23 | key2 | if this module costs 80euros, how much costs just the chip ? |
| 17:58.25 | key2 | 40Eur ? |
| 17:58.41 | vmaster | heh, more like 2-5 in quantities |
| 17:59.03 | vmaster | looks like they're even cheaper |
| 17:59.29 | vmaster | a german distributor charges 66 euros for a lpc2148 proto board |
| 17:59.30 | key2 | ok |
| 17:59.46 | ka6sox-zzzz | key2: url? |
| 17:59.57 | key2 | so you say I could output bits at up to 15Mhz ? |
| 18:00.07 | key2 | by the way, is it a 32bit controller ? |
| 18:00.10 | GCMOTTA | Hummm that is what I suspected. The linksys wrt54gs 1.0 version uses the SAME hardware from my router, is the a way to use the linksys one? |
| 18:00.24 | key2 | GCMOTTA: YEAH |
| 18:00.30 | key2 | and stop bothering with your dead modem |
| 18:00.32 | vmaster | you can toggle bits at up to 15 mhz, and yes, it's a 32-bit arm7tdmi-s |
| 18:00.37 | Tiersten | Are you sure it is the same though? |
| 18:00.55 | Tiersten | It might use the same chips but it is still up to the manufacturer to specify GPIO routing etc... |
| 18:01.19 | key2 | Tiersten: hope that the CFE is not dead |
| 18:01.34 | key2 | then open it, locate the RX, TX and then use a MAX232 to get the prompt to reflash it |
| 18:01.54 | key2 | vmaster: what compiler do you use and how do you program it ? |
| 18:02.07 | Tiersten | GCMOTTA said previously that the bootloader has been erased so no, that wouldn't work. |
| 18:02.37 | Tiersten | GCMOTTA: Anyway, your best hope is to find somebody with the same router and get them to dump it. If not then you could try a Linksys WRT54G one which are floating around. |
| 18:02.39 | vmaster | ARM is fully supported by the gnu toolchain, and all lpc2xxx devices include a bootloader that supports in-system programming using a serial port |
| 18:02.40 | GCMOTTA | <Tiersten> Yes the hardware is the same, I think only GPIO dis different |
| 18:03.32 | vmaster | but you could get a much higher performance by combining the uC with a cpld that does the serializing in hardware |
| 18:04.35 | GCMOTTA | <vmaster> So i need a serial to reprogram a new bootloader? |
| 18:04.49 | vmaster | GCMOTTA: sorry, that was for key2 |
| 18:04.54 | Tiersten | GCMOTTA: No. Different conversation there |
| 18:05.16 | GCMOTTA | ok |
| 18:06.08 | key2 | vmaster: do you have one ? |
| 18:06.43 | vmaster | i have one with a lpc2294, but i use it only as a target for the ARM debugger i'm working on |
| 18:06.48 | GCMOTTA | I will try to find the same router, Thank you guys. |
| 18:06.58 | Tiersten | np |
| 18:09.21 | key2 | ok |
| 18:09.31 | key2 | so you get the toolchain and you compile for it ? |
| 18:09.36 | key2 | with a gcc ? |
| 18:10.07 | vmaster | yep |
| 18:10.16 | ka6sox-zzzz | GCMOTTA, np ;) |
| 18:11.16 | key2 | vmaster: so I guess there is a PLL |
| 18:11.26 | key2 | that you put at the max for going up to 60Mhz |
| 18:11.28 | key2 | right ? |
| 18:13.20 | vmaster | yeah, it has an on-chip pll |
| 18:13.56 | vmaster | and you toggle bits by writing to a pair of Set/Reset registers, that allow you to toggle individual bits |
| 18:14.45 | key2 | vmaster: so you can tell for example that the pin0 of port A is input and the pin1 of portA is output ? |
| 18:14.54 | key2 | or the whole port A has to be input or output |
| 18:15.55 | vmaster | " Direction control of individual bits " Separate control of output set and clear " All I/O default to inputs after reset |
| 18:16.21 | key2 | alright |
| 18:16.35 | vmaster | of course, the 15mhz is a best-case maximum |
| 18:17.16 | key2 | so If I do a while(1) Pin0 = ~Pin0; I should be able to see Pin0 oscilate at 15Mhz? |
| 18:20.25 | key2 | LPC2106 16/32 bit ARM7TDMI |
| 18:20.30 | key2 | why do they say 16/32 ? |
| 18:21.06 | vmaster | ARM supports two instruction sets: the original "ARM" instructions of 32-bit size, and a compressed "Thumb" set with 16-bit instructions |
| 18:21.15 | vmaster | but Thumb still operates on 32-bit data |
| 18:21.20 | key2 | ok |
| 18:21.22 | vmaster | with a 32-bit PC, 32-bit registers |
| 18:21.40 | key2 | and for example, what's the difference between a 8bit 75Mips microcontroller |
| 18:21.58 | key2 | and that |
| 18:22.23 | key2 | because I tryed to read from JTAG with a 8bit Microcontroller at 75Mips and it's quiet slow |
| 18:22.53 | key2 | So I wonder why it would go faster with this one |
| 18:23.09 | vmaster | you can't compare MIPS between multiple architectures |
| 18:23.47 | key2 | MIPS ? |
| 18:24.10 | Tiersten | The ARM spec supports more than two instruction sets now. Jazelle for one |
| 18:24.12 | vmaster | million instructions per second - that's what your "75Mips" was refering to? |
| 18:24.24 | key2 | yeah |
| 18:24.34 | vmaster | Tiersten: heh, yeah, Jazelle, Thumb2 and whatnot - but not on ARM7TDMI's |
| 18:24.41 | Tiersten | Ah. Nope :) |
| 18:25.21 | Tiersten | key2: Comparing MIPS is pointless because the manufacturer will always state the value for the quickest instruction and that might be NOP... |
| 18:25.41 | key2 | yeah but I looked at the instruction table |
| 18:25.47 | key2 | most of them take one cycle |
| 18:25.56 | key2 | just few of them takes 2 or 3 cycles |
| 18:26.08 | key2 | but for doing a for() loop, it takes lot of instruction |
| 18:26.15 | key2 | while the ARM might only take few |
| 18:26.53 | vmaster | key2: what makes the lpc considerably fast at bit-banging is its ability to toggle individual GPIO lines very fast |
| 18:27.20 | key2 | I could try |
| 18:27.30 | key2 | but I dunno if it would be faster than the // port of the PC :) |
| 18:27.32 | vmaster | anyway, as i said before: i wouldn't use bit-banging |
| 18:28.46 | vmaster | on the other hand, i wouldn't try implementing all of EJTAG in hardware, either |
| 18:28.51 | key2 | what would be the main difference between using the LPT port of the pc for the JTAG and using this ARM with its port connected to the jtag ? |
| 18:29.20 | vmaster | you have to use outb/inb instructions on the pc, and those take at least 1us |
| 18:29.28 | Tiersten | the PC parallel port isn't particularly fast |
| 18:29.37 | key2 | ok |
| 18:29.38 | vmaster | that gives you a maximum frequency of <500kHz |
| 18:30.00 | key2 | so if here I set for once 3 pins for output (tms tdi tck) and 1 for input (tdo) |
| 18:30.12 | key2 | can I read really faster than a PC with 3.2Ghz proc ? |
| 18:30.28 | vmaster | yes, but i don't know by how much |
| 18:30.48 | vmaster | if it's really important to you i can create a small test program and run it on my lpc |
| 18:31.22 | key2 | yeah :) |
| 18:31.26 | key2 | i would love to |
| 18:31.38 | key2 | but it would take you time to connect to the JTAG port of something wouldn't it ? |
| 18:32.09 | Tiersten | The PC might have a fast CPU but it can't talk to the parallel port particularly fast for the reasons vmaster has mentioned |
| 18:34.41 | vmaster | key2: i was thinking about toggling 3 bit in an endless loop, and watching those bit using a logic analyzer - that should give you an idea about how fast this could go |
| 18:35.06 | key2 | yeah |
| 18:35.11 | key2 | would it take you time to do that ? |
| 18:35.12 | Tiersten | Using JTAG Tools, a PC parallel port and a IXP420 as a target you can reprogram 128KB in 20 minutes |
| 18:35.42 | ka6sox | ^^^ has experience with same |
| 18:35.49 | Tiersten | And this is on a 3.2GHz P4. So no, it's not particularly fast and the PC pretty much grinds to a halt when you're doing this since you're bitbanging the parallel port like crazy |
| 18:36.10 | ka6sox | hahahaha |
| 18:36.28 | key2 | Tiersten: what do you call Bitbang it ? doing Input output input output ? |
| 18:36.29 | ka6sox | bitbanging a LPT port and killing a P4 |
| 18:36.32 | key2 | or just sending data ? |
| 18:36.56 | Tiersten | Bitbang = Twiddling the I/O port manually |
| 18:37.07 | Tiersten | Like a bit banged serial port would be you implementing the UART in software |
| 18:37.33 | Tiersten | It basically means you have to be careful with timing because you're doing it all in software and if your app isn't paying attention to the port all the time then you might lose data |
| 18:38.12 | key2 | well Jtag is synchronous |
| 18:38.15 | key2 | you have a tck |
| 18:38.36 | key2 | so you don't need to pay attention of what's going on as long as you now when you expect data to come |
| 18:39.28 | Tiersten | You still can't make the parallel port go that fast |
| 18:39.48 | Tiersten | A fast EPP parallel port can do about 2MB/s |
| 18:39.54 | Tiersten | But that's with all 8 data pins |
| 18:40.05 | Tiersten | So divide that by 8 to get what each pin is toggling at |
| 18:40.42 | key2 | would be the same |
| 18:40.48 | key2 | because you write 8 per 8 |
| 18:40.59 | key2 | yo don't write bit per bit |
| 18:41.05 | Tiersten | Yes but your uC can do it faster |
| 18:41.23 | key2 | well |
| 18:41.47 | key2 | It takes me 16s to read 64KB from my BCM with the // port of my pc |
| 18:42.02 | key2 | and it takes me about 10s to do the same from my SX 75Mips microcontroller |
| 18:42.24 | key2 | so I wonder if it would be faster with a 32bit arm |
| 18:44.18 | Tiersten | What scenix is it? |
| 18:45.12 | key2 | microcontroller 75 Mips really inexpensive |
| 18:45.21 | key2 | http://www.parallax.com/detail.asp?product_id=SX48BD |
| 18:54.04 | lennert | key2, vmaster: no, no experience with verilog |
| 18:54.34 | lennert | you simply cannot toggle on two clock edges |
| 18:54.49 | lennert | that wouldn't work in vhdl either (xilinx tools will say "bad synchronous description" or something like that) |
| 19:17.23 | vmaster | heh, yeah, seen that more than once :) |
| 19:34.45 | vmaster | okay, i got a clock-period of about 70ns, which is roughly 15MHz |
| 19:40.44 | vmaster | key2: setting or clearing seems to take 2 cycles - for jtag, you have to change tdi on the falling edge of TCK, that gives you three writes per TCK cycle, or 6 processor cycles per TCK cycle -> up to 10 mhz, excluding the time necessary for loop handling, reading, data processing |
| 19:48.45 | lennert | three write cycles per tck cycle? |
| 19:55.47 | vmaster | he told me that his 8-bit scenix microcontroller was only little faster than a pc's parallel port |
| 19:56.19 | vmaster | I remembered reading that philips LPC2xxx arm7s can bitbang gpio's at up to 15mhz |
| 19:57.15 | vmaster | i tried that on a LPC2294 i have lying around here, and measured a clock-period of ~70ns |
| 19:57.33 | lennert | my pc parallel port can do 867308 writes per second |
| 19:57.39 | lennert | and i need 2 writes per TCK cycle |
| 19:57.44 | vmaster | that was for one write to the GPIO set-register, and one to the GPIO-clear register |
| 19:57.45 | lennert | so that's ~430kHz |
| 19:59.04 | lennert | right, that sucks |
| 19:59.24 | lennert | the limiting factor in the pc is just the distance from the cpu to the southbridge |
| 19:59.28 | vmaster | yep |
| 19:59.50 | vmaster | well, that, and the ioport architecture of the parallel port |
| 20:00.08 | vmaster | if it was a memory mapped device, i could imagine it would be faster |
| 20:00.58 | lennert | vmaster: doesn't matter all that much |
| 20:03.45 | vmaster | mhh, on all X86s, io port access take 1us - no matter if there's a device or not |
| 20:03.49 | vmaster | *accesses |
| 20:05.32 | lennert | uncached memory mapped accesses aren't blazing fast either |
| 20:05.48 | lennert | reading the status word from my e1000 NIC over the pci bus easily takes 4000 cycles |
| 20:06.03 | lennert | the pc architecture just sucks |
| 20:06.21 | lennert | (2.4GHz cpu, so that's 1.6us) |
| 20:06.37 | Tiersten | The parallel port is a ye olde legacy device on the ISA "bus" in a PC |
| 20:06.51 | lennert | Tiersten: anything on the southbridge is slow.. |
| 20:07.27 | lennert | Tiersten: heck, anything that's not L1/L2 is slow :) |
| 20:07.31 | Tiersten | heh |
| 20:07.44 | Tiersten | Next you'll be complaining that anything not in a register is too slow... |
| 20:07.50 | lennert | yup ;) |
| 20:08.06 | lennert | well, me, robert and jamal have been trying to increase linux routing performance |
| 20:08.20 | lennert | it turns out that a p3 900mhz easily out-routes my xeon 2.4ghz because the p3 has MUCH lower i/o latency |
| 20:08.34 | Tiersten | That's because the NetBurst architecture sucks |
| 20:08.36 | lennert | my xeon gets stuck at 1Mpps, the p3 easily goes to 1.4Mpps and beyond |
| 20:08.56 | vmaster | heh, yeah, NetBurst was probably Intel's single worst failure during the last years |
| 20:08.58 | Tiersten | You get high clockspeed and crap performance per clock |
| 20:09.03 | key2 | vmaster: so did you analyse to see if we could get really faster ? |
| 20:09.07 | lennert | Tiersten: mwah, uncached accesses aren't _that_ slow on netburst, it's more that the chipset is really crap |
| 20:09.23 | Tiersten | Oh? E7501? |
| 20:09.30 | lennert | anything E75 |
| 20:09.37 | lennert | i have an E7505 which is pretty bad |
| 20:09.50 | lennert | but the serverworks chipsets are really kick-ass |
| 20:09.55 | Tiersten | Get a P-M board? |
| 20:10.05 | vmaster | key2: see above - yes, you could go faster than a parallel port, best case is 10mhz jtag tck - that's without reading, loop handing, data processing |
| 20:10.44 | lennert | Tiersten: i'm overall pretty happy with the dual xeon, but if i ever get something else, i'll go for opteron |
| 20:11.11 | Tiersten | :) |
| 20:11.24 | vmaster | mhh, you'd have to get a radiator during the winter months, without that dual xeon ;) |
| 20:11.25 | lennert | Tiersten: blows the pants off anything intel for routing and firewalling due to the integrated memory controller and consistently faster L2 misses (in terms of ~100 cycles each) |
| 20:11.39 | lennert | vmaster: true :D |
| 20:12.00 | lennert | my heating has been broken for three years or so anyway |
| 20:24.54 | key2 | vmaster: so let's say you need to read 32bit from JTAG, with a for() loop and shifting bits, at what frequency do you think it would be possible to do that ? |
| 20:29.10 | vmaster | mhh, you could calculate that, i guess |
| 20:29.40 | vmaster | do some loop unrolling, for 1-8 bit at a time |
| 20:30.06 | vmaster | shifting is cheap on arms |
| 20:30.43 | vmaster | certainly several mhz |
| 20:31.46 | vmaster | but i gotta go now... cya |
| 20:36.01 | key2 | just before you leave |
| 20:36.08 | key2 | would you tell me which toolchain you use for the LPC2106 |
| 20:48.51 | vmaster | i'm using the toolchain from www.denx.de (site is down today...), but you can also use one from gnuarm.com or http://www.codesourcery.com/gnu_toolchains/arm/ |
| 20:50.06 | key2 | ok |
| 20:50.10 | key2 | there are examples in it ? |
| 20:50.19 | key2 | like how to set the PLL |
| 20:50.25 | key2 | how to input output port ? |
| 20:50.52 | vmaster | no - the toolchain is generic for all ARM's |
| 20:51.08 | vmaster | the olimex site has some examples, iirc |
| 20:51.23 | key2 | yeah but now with gcc |
| 20:51.28 | key2 | with IAR and some other compiler |
| 20:51.59 | vmaster | you just write to various memory locations |
| 20:52.09 | key2 | using pointer ? |
| 20:52.14 | vmaster | the details are described in the philips datasheets |
| 20:52.16 | vmaster | yes |
| 20:52.20 | key2 | ok |
| 20:52.24 | key2 | sounds good |
| 20:52.32 | key2 | and then once you got your a.out |
| 20:52.37 | key2 | you have to upload it to the ARM using jtag ? |
| 20:52.59 | vmaster | you can, but there's also a philips utility which does that using the onchip bootloader |
| 20:53.04 | Tiersten | Read the docs... |
| 20:53.15 | key2 | ok |
| 20:53.30 | key2 | don't need any other specific files ? |
| 20:54.18 | vmaster | well, you could see if you find some headers with definitions for the various lpc2xxx peripherals |
| 20:54.31 | key2 | that's what you do ? |
| 20:55.12 | vmaster | i wrote some assembler lines, no C |
| 20:55.26 | key2 | and what do they do ? |
| 20:55.42 | vmaster | load registers, store register, branch |
| 20:55.50 | key2 | :) |
| 20:55.56 | key2 | that makes it faster ? |
| 20:56.10 | vmaster | it gives you closer control |
| 20:56.59 | key2 | PLLCFG=0x23; |
| 20:57.06 | key2 | I guess I have to find the address of PLLCFG |
| 20:57.11 | key2 | in the datasheet |
| 20:57.13 | vmaster | yep |
| 20:57.21 | vmaster | either that, or you dig out some header files |
| 20:57.28 | key2 | that you find where :) |
| 20:57.39 | vmaster | heh, i would search on philip's site |
| 20:58.08 | vmaster | as i said, i've only used the lpc as a target for my own debugger, the only own code i've ever run on it was the bit-bang test i did for you |
| 20:58.55 | key2 | ahha |
| 20:59.01 | key2 | you've never used it for anything else ? |
| 21:04.56 | vmaster | no |
| 21:05.30 | vmaster | i just needed another target to test with - it's a arm7tdmi-s, my other targets are 720t and 920t |
| 21:05.53 | vmaster | anyway, i'm half an hour late, cya |
| 21:17.13 | key2 | I just compiled a very little file and it is 124Kb |
| 21:17.21 | key2 | dunno how this thing works :) |
| 21:22.23 | key2 | Tiersten: is there a way to make the file become a .hex ? |
| 22:23.45 | [g2] | lennert any clue on the latency across PCI-E ? |
| 22:37.47 | vmaster | key2: you can use objcopy to convert files |
| 22:53.01 | lennert | [g2]: no idea. it's better in theory, but in practise, it doesn't matter that much cause pci-e devices do overlapping transfers |
| 22:53.23 | lennert | [g2]: pci-e e1000 does overlapping tx/rx descriptor fetches which makes performance much better |
| 23:11.41 | [g2] | lennert pipelining often helps performance |
| 23:48.17 | key2 | vmaster: you use objcopy to convert the .out into .hex ? don't you need the entry point ? |
| 23:50.04 | lennert | key2: entry point of a .hex file is always the first word, i think |