**** BEGIN LOGGING AT Thu Sep 14 02:59:56 2006
Sep 14 13:48:21 <prpplague> vmaster_: morning
Sep 14 13:52:25 <vmaster_> hey prpplague 
Sep 14 13:58:09 <prpplague> vmaster: just getting started on debugging this timeout issue
Sep 14 13:58:50 <vmaster> do you have usbmon compiled in your kernel? i found it helpful in debugging this issue
Sep 14 13:59:13 <prpplague> not on this specific desktop
Sep 14 13:59:23 <prpplague> i'll have to go to another one
Sep 14 13:59:40 <prpplague> vmaster: so you;ve run into this before?
Sep 14 14:00:04 <vmaster> several months ago there was a bug in the ftdi driver
Sep 14 14:00:26 <vmaster> there's a define in ft2232.c that makes the OpenOCD dump every byte sent to the chip
Sep 14 14:00:39 <prpplague> yea got that turned on
Sep 14 14:00:52 <vmaster> _DEBUG_USB_COMMS_
Sep 14 14:00:59 <prpplague> vmaster: yea
Sep 14 14:01:13 <vmaster> when does the timeout occur? on the first packets transmitted?
Sep 14 14:02:42 <prpplague> vmaster: full log - http://pastebin.ca/170277
Sep 14 14:05:48 <prpplague> vmaster: i'm not getting one of the leds turned on which leds me to believe the writes aren't occuring
Sep 14 14:10:32 <vmaster> maybe the wrong device gets opened?
Sep 14 14:10:57 <vmaster> try adding " A" after the ft2232_device_desc
Sep 14 14:14:27 <vmaster> ah, you might have to unbind the ftdi_sio driver
Sep 14 14:15:19 <prpplague> vmaster: it was the description
Sep 14 14:15:31 <prpplague> vmaster: i already got rid of ftdio_sio earlier
Sep 14 14:16:27 <vmaster> you can request a pid block from ftdi and run your devices under their pid, if you want
Sep 14 14:16:47 <vmaster> that way it's easier to identify the jtag dongle, and you wont interfere with the ftdi_sio
Sep 14 14:17:04 <prpplague> vmaster: naw this is ok, i just need to get familiar with the operations and write some notes
Sep 14 14:17:10 <prpplague> vmaster: new error - Error:   jtag.c:1148 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 3f
Sep 14 14:18:00 <vmaster> is the dongle connected to your target board and is the board powered?
Sep 14 14:18:11 <prpplague> yep
Sep 14 14:19:57 <prpplague> http://pastebin.ca/170302
Sep 14 14:19:59 <prpplague> current config
Sep 14 14:21:01 <prpplague> wonder if the enables for the buffer aren't getting set
Sep 14 14:21:04 * prpplague checks
Sep 14 14:24:08 <prpplague> yea looks like the enables for the buffers are high
Sep 14 14:27:33 <vmaster> ah, sorry
Sep 14 14:28:04 <prpplague> vmaster: i must be dense, but i can't seem to find a good datasheet that explains the usage for these values
Sep 14 14:28:30 <prpplague> vmaster: which ft2232 datasheet do you use to determine these values?
Sep 14 14:28:43 <vmaster> the mpsse application note
Sep 14 14:29:10 <prpplague> ahh
Sep 14 14:29:21 * prpplague grabs it
Sep 14 14:29:23 <vmaster> in m5960_init, low_output is 0xd8, but should be 0x18 (nOE1,2 low)
Sep 14 14:30:26 <prpplague> yea, looks good now
Sep 14 14:34:24 <prpplague> vmaster: what enables the banks and info commands?
Sep 14 14:42:24 <vmaster> you mean flash?
Sep 14 14:42:37 <vmaster> #flash bank <driver> <base> <size> <chip_width> <bus_width> [driver_options ...]
Sep 14 14:45:22 <prpplague> yea, i have that in my config, but when i try using the "info" command it tells give me an error "command info not found"
Sep 14 14:47:21 <vmaster> it's "flash info"
Sep 14 14:47:27 <vmaster> and "flash banks"
Sep 14 14:48:00 <prpplague> ahh
Sep 14 14:48:16 <prpplague> hehe did not get that from the help command
Sep 14 14:49:02 <vmaster> heh, yeah, the user interface could use some improvements, but other things are more fun to work on ;)
Sep 14 14:49:32 <prpplague> agreed
Sep 14 14:49:42 <prpplague> still getting some odd results 
Sep 14 14:49:50 <vmaster> like?
Sep 14 14:51:34 <vmaster> the cfi driver only understands Intel's commandset so far
Sep 14 15:10:08 * prpplague returns 
Sep 14 15:10:10 <prpplague> vmaster: ok so i'm making progess
Sep 14 15:10:25 <prpplague> vmaster: you mentioned a memory speed option yesterday 
Sep 14 15:22:45 <vmaster> "arm7_9 fast_memory_writes [enable|disable] tells the OpenOCD to write to memory without waiting for the core - that's safe as long as your core isn't running from a very low frequency
Sep 14 15:23:52 <vmaster> "arm7_9 dcc_downloads enable" tells the OpenOCD to use the debug communications channel to write to the target - this gives the best speed, but requires on-target memory as a working area (working_area target# address size)
Sep 14 15:23:58 <prpplague> vmaster: yea should be safe for 200mhz
Sep 14 15:24:03 <vmaster> heh, definitely
Sep 14 15:24:12 <prpplague> vmaster: but i need to make sure my processor clock is enabled correct?
Sep 14 15:24:37 <vmaster> well, anything above a few mhz should be enough
Sep 14 15:24:47 <vmaster> on the ep93xx, the crystal oscillator is enough
Sep 14 15:24:53 <prpplague> vmaster: i'm used to doing bit bang flash programing using the boundry scan
Sep 14 15:25:12 <vmaster> heh, well, this is going to be somewhat faster
Sep 14 15:25:17 <prpplague> vmaster: hehe
Sep 14 15:25:30 <vmaster> gotta take the dogs out... i'll be back in a few minutes
Sep 14 15:25:34 <prpplague> vmaster: ok 
Sep 14 15:41:11 <prpplague> ho ho hum
Sep 14 15:41:13 <prpplague> lots to learn
Sep 14 15:41:48 <vmaster> most/some commands are documented in the wiki at http://openfacts.berlios.de/index-en.phtml?title=Open_On-Chip_Debugger
Sep 14 15:42:07 * prpplague looks
Sep 14 15:42:24 <prpplague> vmaster: its more of the procedure for flashing that i'm gonna need to work out
Sep 14 15:42:37 <prpplague> vmaster: i'm still getting lots of problems with the cfi driver
Sep 14 15:43:37 <vmaster> what type of flash is it?
Sep 14 15:45:26 <prpplague> vmaster: intel TE28F128J3c
Sep 14 15:46:48 <prpplague> vmaster: the system should be configured on reset to work properly, it should be running at 12mhz, the bus width is set correctly
Sep 14 15:47:04 <prpplague> vmaster: so i'm not sure why i'm getting inconsistant results
Sep 14 15:47:29 <vmaster> what does the bank look like - one chip of 16 bit?
Sep 14 15:47:37 <prpplague> yea
Sep 14 15:47:58 <prpplague> vmaster: the probe identifies it properly
Sep 14 15:48:26 <vmaster> i'll try with my ep93xx board, it has the same chip in the same configuration
Sep 14 15:48:42 <vmaster> do you have the MMU/Caches enabled?
Sep 14 15:49:25 <prpplague> vmaster: the mmu/caches should be turned off on reset
Sep 14 15:50:03 <prpplague> vmaster: ( i checked to make sure)
Sep 14 15:50:16 <vmaster> the openocd should tell you whether the caches are on or off
Sep 14 15:53:41 <prpplague> vmaster: hmm, using the arm920t cache_info ?
Sep 14 15:54:33 <vmaster> poll
Sep 14 15:54:47 <vmaster> > Target 0 halted
Sep 14 15:54:47 <vmaster> target halted in ARM state due to debug request, current mode: Supervisor
Sep 14 15:54:47 <vmaster> cpsr: 0x200000d3 pc: 0x00010f8c
Sep 14 15:54:47 <vmaster> MMU: enabled, D-Cache: enabled, I-Cache: enabled
Sep 14 15:55:11 <vmaster> that's printed right after a halt, too
Sep 14 15:55:17 <prpplague> odd, when i issue the poll command i get no additional info for mmu and d-cache
Sep 14 15:56:05 <vmaster> did you configure your target as "target arm920t ..."?
Sep 14 15:56:30 <vmaster> "target arm9tdmi ..." is generic for all arm9tdmi based systems, without paying attention to caches etc.
Sep 14 15:56:50 <prpplague> ahh
Sep 14 15:56:54 <prpplague> changed 
Sep 14 15:57:00 <prpplague> now i'm getting the additional info
Sep 14 15:57:15 <prpplague> all disabled
Sep 14 15:57:31 <vmaster> okay, and what operations produce inconsistent results?
Sep 14 15:57:53 <vmaster> i haven't used the cfi stuff for a while, could be that regression causes it to fail
Sep 14 15:57:57 <prpplague> vmaster: flash erase 0 0 10
Sep 14 15:58:15 <vmaster> did you specify a "working_area"?
Sep 14 15:58:24 <prpplague> no
Sep 14 15:58:56 <vmaster> okay, i'm just dumping my current flash content and try after that
Sep 14 15:59:05 <prpplague> vmaster: whats the working area for?
Sep 14 16:00:40 <prpplague> Error:   cfi.c:214 cfi_intel_wait_status_busy(): status register: 0xff
Sep 14 16:00:41 <prpplague> Error:   cfi.c:216 cfi_intel_wait_status_busy(): Block Lock-Bit Detected, Operation Abort
Sep 14 16:00:41 <prpplague> Error:   cfi.c:218 cfi_intel_wait_status_busy(): Program suspended
Sep 14 16:00:41 <prpplague> Error:   cfi.c:220 cfi_intel_wait_status_busy(): Low Programming Voltage Detected, Operation Aborted
Sep 14 16:00:41 <prpplague> Error:   cfi.c:222 cfi_intel_wait_status_busy(): Program Error / Error in Setting Lock-Bit
Sep 14 16:00:41 <prpplague> Error:   cfi.c:224 cfi_intel_wait_status_busy(): Error in Block Erasure or Clear Lock-Bits
Sep 14 16:00:43 <prpplague> Error:   cfi.c:226 cfi_intel_wait_status_busy(): Block Erase Suspended
Sep 14 16:02:35 <vmaster> the working_area is used to speed things up: the DCC download feature puts a small assembler routine into target memory and executes it there, which accepts data from the DCC (faster than normal memory writes)
Sep 14 16:03:14 <vmaster> and the flash algorithms like cfi and str7x use it do download block flashing code, which is orders of magnitude faster than using memory accesses
Sep 14 16:03:19 <prpplague> vmaster: ahh, but that wouldn't be required for basic flash erase?
Sep 14 16:03:24 <vmaster> nope
Sep 14 16:04:27 <prpplague> hmm
Sep 14 16:08:00 <vmaster> sorry, gotta go for a bit... i'll look into this as soon as i get back
Sep 14 16:08:22 <prpplague> vmaster: np
Sep 14 16:08:24 <prpplague> vmaster: thanks
Sep 14 17:12:17 <vmaster> prpplague: okay, erasing and flashing both work reliably on my ep93xx with a te28f128j3
Sep 14 17:20:22 <prpplague> interesting
Sep 14 17:20:33 <prpplague> vmaster: wonder what the problem is
Sep 14 17:20:42 <prpplague> vmaster: do you have a script that you use?
Sep 14 17:21:13 <prpplague> vmaster: single chip width 2 bus 2?
Sep 14 17:21:23 <vmaster> nope, no script
Sep 14 17:21:38 <prpplague> vmaster: so you started up, did the following
Sep 14 17:21:40 <vmaster> single chip with 2, 2
Sep 14 17:21:43 <prpplague> flash probe 0
Sep 14 17:21:53 <prpplague> flash erase 0 0 127
Sep 14 17:22:06 <vmaster> first i write to the ebi to enable 16-bit memory
Sep 14 17:22:09 <prpplague> flash write 0 testapp.bin 0x00000000
Sep 14 17:22:39 <prpplague> vmaster: right, my board has that enabled on reset
Sep 14 17:23:19 <prpplague> hmm
Sep 14 17:23:25 <vmaster> then i probe, then i erase, then write, then dump to see if was written
Sep 14 17:23:48 <vmaster> could you run with -d -l <logfile> and send me the log via mail?
Sep 14 17:23:58 <prpplague> vmaster: can you pastebin what you got after doing a probe, issue the info command?
Sep 14 17:24:28 <prpplague> vmaster: yep will do
Sep 14 17:25:32 <prpplague> vmaster: i'm wondering if its getting some bogus values during the probe
Sep 14 17:25:43 <vmaster> http://pastebin.ca/170561
Sep 14 17:26:31 <vmaster> do you see other Warnings/Errors in the console output beside the cfi.c errors?
Sep 14 17:28:23 <prpplague> Error:   arm7_9_common.c:560 arm7_9_execute_sys_speed(): timeout waiting for SYSCOMP & DBGACK, last DBG_STATUS: 4
Sep 14 17:28:30 <prpplague> vmaster: my cfi data matches yours
Sep 14 17:29:49 <vmaster> ah, okay, this isn't good
Sep 14 17:30:22 <vmaster> try without "arm7_9 fast_memory_access enable"
Sep 14 17:30:39 <vmaster> mhh, looks like this was without it...
Sep 14 17:35:49 <vmaster> prpplague: what jtag_speed have you set?
Sep 14 17:36:20 <vmaster> prpplague: 0: 6MHz, 1: 3MHz, 2: 2MHz, 3: 1.5MHz - 0-2 shouldn't make a differene performance wise
Sep 14 17:36:34 <vmaster> but might improve stability
Sep 14 17:39:03 <vmaster> the timeout means that the core didn't resync to debug speed in at least 500ms - all it had to do was resync back to the memory clock, execute a LDM/STM, and resync back to DCLK
Sep 14 17:39:54 <vmaster> this is so simple that a communication problem is a likely cause - at 6mhz, jtag cable length, board traces and connectors might cause problems
Sep 14 17:47:03 <prpplague> vmaster: i have jtag_speed set to 1 
Sep 14 17:47:18 <prpplague> vmaster: and i've not been using it with fast_memory_access disabled
Sep 14 17:47:52 * prpplague tries with 2
Sep 14 17:55:03 <prpplague> vmaster: seems to be working better with 2
Sep 14 18:01:51 <vmaster> better as in good, or better as in doesn't fail as often?
Sep 14 18:05:21 <prpplague> doesn't fail as often
Sep 14 18:05:25 <prpplague> vmaster: still problematic
Sep 14 18:10:05 * prpplague test with a wiggler
Sep 14 18:12:35 <prpplague> vmaster: when doing flash procedures, why don't you display the current offset?
Sep 14 18:16:23 <vmaster> i wanted to implement an async "progress" indication, but never got to implement it
Sep 14 18:16:38 <vmaster> ideally, the flash interface doesn't know what a telnet interface is
Sep 14 18:18:01 <prpplague> ahh true enough
Sep 14 18:18:40 <prpplague> vmaster: well the wiggler seems to be working, just not the ft2232
Sep 14 18:18:56 <vmaster> you could try enabling the high output drive capability
Sep 14 18:19:15 <vmaster> that solved some stability issues for me
Sep 14 18:19:32 <prpplague> hmm
Sep 14 18:21:34 <vmaster> you'll have to write to the eeprom
Sep 14 18:21:44 <prpplague> lovely
Sep 14 18:21:55 <prpplague> vmaster: what kind of stability problems did you have?
Sep 14 18:22:16 <vmaster> sometimes bogus data when working with a FPGA board
Sep 14 18:22:25 <vmaster> ah
Sep 14 18:22:28 <vmaster> forget about it
Sep 14 18:22:39 <vmaster> your drivers take care of that for you
Sep 14 18:22:51 <vmaster> i had the plain dlp2232m
Sep 14 18:23:07 <prpplague> ahh ok
Sep 14 18:23:36 <vmaster> well, your problems strongly indicate a communication problem
Sep 14 18:23:43 <prpplague> yea sounds that way to me
Sep 14 18:24:07 <prpplague> just surprised that it works with the wiggler and not the ft2232
Sep 14 18:24:26 <prpplague> i'll test with a couple other boards to see what i get
Sep 14 18:25:08 <prpplague> vmaster: one more thing, the working_area
Sep 14 18:25:26 <vmaster> if your chip has SRAM you could use that
Sep 14 18:25:36 <prpplague> vmaster: ahh thats what i was about to ask
Sep 14 18:25:36 <vmaster> without offloading the flashing to the target performance is horrible
Sep 14 18:26:03 <prpplague> vmaster: the s3c2410 has 16k internal sram
Sep 14 18:26:20 <vmaster> ideal for this purpose
Sep 14 18:26:36 <vmaster> you can tell the openocd either to backup this area, or allow it to do whatever it wants
Sep 14 18:26:43 <vmaster> backup|nobackup
Sep 14 18:26:52 <prpplague> backup to where? 
Sep 14 18:27:15 <vmaster> read everything the first time it needs the working area, restore it before a resume
Sep 14 18:27:24 <prpplague> ahh 
Sep 14 18:27:26 <prpplague> gotcha
Sep 14 18:27:49 * prpplague checks on the base address for the sram
Sep 14 18:36:44 <prpplague> vmaster: when the system boots its only running with the base clock of 12mhz
Sep 14 18:37:10 <prpplague> vmaster: think it would make any difference if i setup the main clock to what the normal running speed is?
Sep 14 18:38:37 <vmaster> hmm... it's a hard macrocell, where ARM doesn't ask for synchronizers, so it shouldn't matter
Sep 14 18:39:21 <vmaster> but of course you could try - start up with jtag_speed 8 or so, then use 'mww' to enable the PLL
Sep 14 18:42:48 <prpplague> vmaster: i'm using jtag_speed 2 right now, i don't see much difference in performance from a wiggler
Sep 14 18:45:21 <vmaster> mhh, get yourself a 16kb file and upload it to SRAM (load_binary <filename> <address>)
Sep 14 18:45:29 <vmaster> that should tell you how fast it was
Sep 14 18:46:23 <vmaster> make sure you comment the working_area out
Sep 14 18:47:29 <prpplague> vmaster: gotcha
Sep 14 18:47:41 <prpplague> vmaster: for dcc_downloads you need a working area correct?
Sep 14 18:47:44 <vmaster> yes
Sep 14 18:47:55 <vmaster> but you'll see a huge difference even without
Sep 14 18:48:21 <vmaster> ah, debug output has a severe impact on speed
Sep 14 18:48:21 <prpplague> hmm
Sep 14 18:48:26 <prpplague> ahh
Sep 14 18:48:30 <vmaster> debug_level 2
Sep 14 18:48:44 <vmaster> 3 is DEBUG, 2 is INFO
Sep 14 18:49:06 <prpplague> Warning: jtag.c:1037 jtag_read_buffer(): value captured during scan didn't pass the requested check: captured: 00 check_value: 01 check_mask: 0f
Sep 14 18:49:09 <prpplague> i get alot of those
Sep 14 18:49:21 <[g2]> prpplague what are you running ?
Sep 14 18:49:33 * [g2] guesses openocd with some hw
Sep 14 18:49:34 <prpplague> [g2]: in circles
Sep 14 18:49:40 <prpplague> hehe
Sep 14 18:49:47 <[g2]> :)
Sep 14 18:49:56 <prpplague> new gee-wiz ft2232 dongle with some s3c2410 boards
Sep 14 18:50:05 <[g2]> ahh
Sep 14 18:50:29 <[g2]> prpplague you don't happen to have one of those olimex arm-usb-jtag dongles do you ?
Sep 14 18:51:18 <vmaster> prpplague: that's actually fatal
Sep 14 18:51:25 <vmaster> it means that communication is broken
Sep 14 18:51:40 <prpplague> vmaster: ahh
Sep 14 18:51:45 <vmaster> during Shift-IR, it should read b0001
Sep 14 18:51:55 <prpplague> [g2]: no the one i have is similiar
Sep 14 18:52:33 <vmaster> if it doesn't communication is out of sync
Sep 14 18:52:35 <prpplague> vmaster: hmm, noise?
Sep 14 18:52:58 <vmaster> how long is the cable from the dongle to the target board?
Sep 14 18:53:00 <prpplague> vmaster: wonder if its those buffers
Sep 14 18:53:13 <vmaster> i've checked the datasheets, they should be good for a lot more
Sep 14 18:53:16 <prpplague> vmaster: 6-8 inches
Sep 14 18:53:17 * [g2] wonders what chip(s) are inside
Sep 14 18:53:25 <vmaster> [g2]: a FT2232L
Sep 14 18:53:26 <prpplague> [g2]: ft2232
Sep 14 18:54:01 <[g2]> prpplague you don't have that sam7 running do you ?
Sep 14 18:54:04 <prpplague> vmaster: think i need shorter?
Sep 14 18:54:13 * [g2] wonders how fast it could bit bang
Sep 14 18:54:15 <prpplague> [g2]: naw, not yet
Sep 14 18:54:15 * vmaster gets a calculator out
Sep 14 18:54:34 <vmaster> hmm, 15cm should be fine
Sep 14 18:54:47 <prpplague> vmaster: thats what i thought
Sep 14 18:56:41 <prpplague> vmaster: with jtag_speed 8 no errors
Sep 14 18:56:43 <prpplague> hehe
Sep 14 19:01:10 <prpplague> vmaster: 6 is as low as i can go without errors
Sep 14 19:05:02 <vmaster> mhh, this is going to impact performance
Sep 14 19:05:34 <vmaster> are these your own boards? i.e. do you know if someone jtagged them at higher speeds?
Sep 14 19:06:13 <prpplague> vmaster: these are our boards
Sep 14 19:06:19 <prpplague> vmaster: we've always used wigglers
Sep 14 19:07:32 <prpplague> vmaster: i suspect that it is the traces
Sep 14 19:08:34 <prpplague> vmaster: i'm gonna experiment with running the system with the clocks and sdram enabled and see what the difference in performance is
Sep 14 19:09:49 <prpplague> vmaster: if i use the sdram and give it more working_area, would that improve performance?
Sep 14 19:11:59 <vmaster> iirc i'm using up to 32kb, but it shouldn't make much of a difference if it's 4 or 32
Sep 14 19:12:08 <vmaster> less than 1kb might negatively affect performance
Sep 14 19:13:01 <prpplague> okie dokie
Sep 14 19:16:10 <prpplague> holy cow
Sep 14 19:16:15 <prpplague> big big big difference
Sep 14 19:17:49 <vmaster> hmm?
Sep 14 19:18:26 <prpplague> yea seems to be running well after initing the clocks and sdram
Sep 14 19:18:39 <vmaster> even at higher jtag speeds?
Sep 14 19:19:34 <vmaster> strange, i could work with a at91rm9200 at 32khz with no problems (of course neither fast_memory_access nor dcc_downloads), but at 6mhz tck
Sep 14 19:19:56 <prpplague> vmaster: no still at jtag_speed 6
Sep 14 19:20:03 <vmaster> ah, ok
Sep 14 19:20:26 <prpplague> vmaster: but atleast at jtag_speed 6 it does a 64k flash in just a couple of seconds
Sep 14 19:20:51 <vmaster> heh, i flash my 256kb str7 in less than 5 ;)
Sep 14 19:21:32 <prpplague> vmaster: yea my target is erase 16mb flash, then flash a 4mb file 
Sep 14 19:21:42 <prpplague> s/target/goal
Sep 14 19:22:46 <prpplague> [g2]: you gonna get one of those olimex jtag dongles?
Sep 14 19:24:04 <[g2]> prpplague I would, but nobody is stocking them :( as olimex was on holiday
Sep 14 19:24:30 <[g2]> My SAM7 boards are delayed due to that (I'm a little bummed about it) :(
Sep 14 19:24:41 <prpplague> bummer
Sep 14 19:25:00 <prpplague> hehe, save you money, there is a cool new s3c2410 board out soon, hehe
Sep 14 19:44:12 * prpplague does 1mb timed test
Sep 14 19:44:50 <prpplague> 35 seconds
Sep 14 19:45:15 <vmaster> at jtag_speed 6?
Sep 14 19:45:19 <vmaster> not too bad
Sep 14 19:47:00 <prpplague> yea
Sep 14 19:47:11 <prpplague> vmaster: doing a 4mb test now
Sep 14 19:47:50 <[g2]> prpplague which board ?
Sep 14 19:47:57 <prpplague> vmaster: i got an error with "no enough working space"
Sep 14 19:48:06 <prpplague> [g2]: which arm board or which jtag dongle?
Sep 14 19:48:20 <[g2]> arm board
Sep 14 19:48:56 <prpplague> [g2]: the one i'm working with is the dev board for the M5900
Sep 14 19:49:04 <prpplague> [g2]: one sec, url
Sep 14 19:49:55 <prpplague> [g2]: http://www.elinux.org/wiki/M5900  and http://www.linuxdevices.com/articles/AT5552849613.html
Sep 14 19:50:35 <prpplague> vmaster: Warning: target.c:535 target_alloc_working_area(): not enough working area available
Sep 14 19:50:45 <vmaster> prpplague: that might mean i have a bug that the working area isn't marked as free again
Sep 14 19:50:54 <vmaster> the code keeps the algorithm, but frees the buffer
Sep 14 19:50:56 <vmaster> or at least it should
Sep 14 19:50:58 <vmaster> let me check
Sep 14 19:51:02 <prpplague> vmaster: the working area need to be bigger than the file you are transfering?
Sep 14 19:51:08 <vmaster> no
Sep 14 19:51:16 <vmaster> up to 32kb + a few byte for the algorithm
Sep 14 19:52:08 <prpplague> hmm ok, i allocated 128kb so that shouldn't be a problem
Sep 14 19:52:20 <prpplague> vmaster: 171 seconds for 4mb
Sep 14 19:52:34 <[g2]> prpplague that looks quite nice
Sep 14 19:52:52 <[g2]> I'd offer to do some work on those if you sent me a few :)
Sep 14 19:52:58 <prpplague> hehe
Sep 14 19:53:10 <prpplague> [g2]: well we have a hobby board coming out soon
Sep 14 19:53:37 <[g2]> when and how much ?
Sep 14 19:53:56 * [g2] starts digging in couch for $0.25
Sep 14 19:54:01 <prpplague> hehe
Sep 14 19:54:07 <prpplague> next 45 days
Sep 14 19:54:14 <[g2]> 45 days... that's forever
Sep 14 19:54:26 <prpplague> we'll have 10 freebies for devrs that will post to a wiki with projects and code
Sep 14 19:54:34 * [g2] may have a product designed and shipping in that time :)
Sep 14 19:54:56 <[g2]> s3c2410 based ?
Sep 14 19:54:59 <prpplague> yea
Sep 14 19:55:18 <prpplague> [g2]: see the sodim for the m5900 dev board on that elinux page?
Sep 14 19:55:53 <vmaster> prpplague: in cfi.c at line 688
Sep 14 19:55:54 <vmaster> +       target_free_working_area(target, source);
Sep 14 19:55:54 <vmaster> +
Sep 14 19:56:12 <prpplague> [g2]: picture that with 80-pin .1" headers
Sep 14 19:57:15 <prpplague> vmaster: right before the destroy_reg_parms ?
Sep 14 19:57:26 <vmaster> yeah
Sep 14 19:57:45 * prpplague re-tests
Sep 14 19:58:00 <vmaster> you'll have to re-test at least 4 times to have it fail
Sep 14 19:58:18 <vmaster> with a 128kb working area and 32kb+a bit per write operation
Sep 14 19:59:02 <prpplague> ahh
Sep 14 20:00:16 <prpplague> just wish i could get it to work at jtag_speed 2
Sep 14 20:00:34 <prpplague> right now i'm getting between 25-30kbps
Sep 14 20:02:09 <prpplague> oh shoot, forgot to enable fast_memory_access
Sep 14 20:05:11 <prpplague> still, getting apex on there in less than 5 seconds is great
Sep 14 20:08:54 <prpplague> vmaster: wonder if i put a shorter heavier shield cable connecting the board
Sep 14 20:11:00 <prpplague> vmaster: wow that one fix did nicely
Sep 14 20:11:11 <prpplague> vmaster: droped about 40 seconds off
Sep 14 20:12:23 <vmaster> shorter cable?
Sep 14 20:13:13 <prpplague> vmaster: no the free_working_area
Sep 14 20:14:38 <vmaster> fast_memory_access or free_working_area? not forgetting that it may reuse the on-target buffer shouldn't affect target
Sep 14 20:15:22 <vmaster> ... performance, not target
Sep 14 20:15:38 <prpplague> vmaster: btw, not that i'm complaining, for the flash erase, it might be nice to have a similiar results statement, i.e. "erased flash bank 0 at sectors 0 thru 60 in 27s 78665us"
Sep 14 20:15:59 <prpplague> vmaster: after adding the fix you suggested for the "target_free_working_area"
Sep 14 20:16:12 <prpplague> vmaster: i got a 40 second drop in transfer time
Sep 14 20:16:22 <vmaster> strange
Sep 14 20:16:34 <vmaster> well, i'm glad it got faster, i'm just not sure why, but hey :)
Sep 14 20:16:49 <vmaster> one doesn't need to know everything, i guess
Sep 14 20:17:17 <vmaster> ah, yeah, the result statement could be added
Sep 14 20:18:39 <prpplague> ok so 72 seconds to erase 16mb, and then 138 seconds to program 4mb
Sep 14 20:18:52 <prpplague> plus about 10 seconds of misc
Sep 14 20:20:10 <prpplague> vmaster: hmm, i keep wondering if those buffers on the jtag dongle are creating a problem
Sep 14 20:20:26 <prpplague> i've had bad luck with alot of buffers lately
Sep 14 20:21:48 <vmaster> the datasheet lists worst-case switching times of less than 3ns
Sep 14 20:22:00 <vmaster> but then i'm no ee
Sep 14 20:23:25 <prpplague> me either, i'm just a wannabie
Sep 14 20:23:44 <prpplague> or should i say, wannabi-ee
Sep 14 20:23:49 <vmaster> heh ;)
Sep 14 20:34:49 <prpplague> vmaster: yea consistantly at 138 seconds
Sep 14 20:34:55 <prpplague> lovely
Sep 14 20:35:03 <prpplague> now if i can trace down the speed issue
Sep 14 20:35:08 <prpplague> that would be great
Sep 14 20:36:05 <prpplague> vmaster: thanks for the help, heading home for the day
Sep 14 20:36:08 <prpplague> !! later
**** ENDING LOGGING AT Fri Sep 15 02:59:57 2006