**** BEGIN LOGGING AT Sat Aug 27 02:59:57 2005
Aug 27 17:00:42 <[g2]> hi ulf___ 
Aug 27 17:00:57 <ulf___> my  client crashed
Aug 27 17:01:11 <rwhitby> ulf___: [g2] is your man wrt jtag :-)
Aug 27 17:01:12 <ulf___> very bad day today ;)
Aug 27 17:01:32 <[g2]> ulf___, have you seen http://www.nslu2-linux.org/wiki/HowTo/RecoverFromABadFlashUsingJTAG ?
Aug 27 17:02:03 <ulf___> yes
Aug 27 17:02:20 <ulf___> but look my flash chip is different
Aug 27 17:02:23 <ulf___>                 Region 0:
Aug 27 17:02:24 <ulf___>                         Erase Block Size: 8192 B (8 KiB)
Aug 27 17:02:26 <ulf___>                         Number of Erase Blocks: 8
Aug 27 17:02:28 <ulf___>                 Region 1:
Aug 27 17:02:29 <ulf___>                         Erase Block Size: 65536 B (64 KiB)
Aug 27 17:02:31 <ulf___>                         Number of Erase Blocks: 63
Aug 27 17:02:37 <ulf___> it is a 29lv320 
Aug 27 17:03:11 <ulf___> and the jtag tools  are only support the 160 and 640 version
Aug 27 17:06:28 <[g2]> ulf___, you can probably copy a program to memory like redboot and then start executing it
Aug 27 17:06:48 <ulf___> aha ok 
Aug 27 17:07:05 <ulf___> so then i do not use flashmem?
Aug 27 17:07:44 <[g2]> or you might be able to extend jtag to support your chip
Aug 27 17:07:53 <[g2]> it's probably not too difficult
Aug 27 17:07:58 <ulf___> hmm
Aug 27 17:08:19 <ulf___> i tried to read through the source of jtagtools
Aug 27 17:08:22 <[g2]> jtag as in the jtag tool from wince
Aug 27 17:08:27 <ka6sox> which chip?
Aug 27 17:08:36 <[g2]> you've got a 29lv320 right 
Aug 27 17:08:43 <ulf___> am29lv320db
Aug 27 17:08:48 <ka6sox> ah
Aug 27 17:10:05 <ulf___> thanks for all your patient, but i am a newbie in this jtag stuff
Aug 27 17:10:17 <[g2]> we're all learning 
Aug 27 17:10:39 <ulf___> how can i upload the redboot loader in to the ram?
Aug 27 17:10:57 <ulf___> i can only say readmem
Aug 27 17:19:14 <[g2]> hmmm.... no writemem in jtag tools ?
Aug 27 17:20:38 <ulf___> no
Aug 27 17:21:15 <[g2]> I'd probably enhance jtag to understand the part and then be able to reflash it
Aug 27 17:22:05 <[g2]> the other choice is to enable the memory and and serial and load a program
Aug 27 17:22:59 <ulf___> ok like the manual from that link the addr. is 0x50000000 then i use this it is writing, but when i start at 0x00000000 it starts with erasing and gives an error at block9
Aug 27 17:23:31 <ulf___> why this address 0x5000000
Aug 27 17:24:18 <ulf___> what kind of flash is in the slug a topboot or bottomboot chip?
Aug 27 17:24:26 <[g2]> it's setup something like this http://www.nslu2-linux.org/wiki/Info/MemoryMap
Aug 27 17:25:37 <[g2]> so once the chip is setup, the expansion bus and flash live at 0x5....
Aug 27 17:25:41 <ulf___> aha so the adress 0x somethins i not only the flash its all the stuff an the board=
Aug 27 17:25:52 <ulf___> ahha 
Aug 27 17:25:54 <[g2]> no
Aug 27 17:26:14 <[g2]> when the chip boots the expansion bus is mapped to 0x0
Aug 27 17:26:21 <[g2]> but default
Aug 27 17:26:37 <[g2]> or as part of the pull up configuration
Aug 27 17:26:47 <ulf___> hmm 
Aug 27 17:27:13 <ulf___> so first i have to check the address space
Aug 27 17:27:14 <[g2]> there's a config register and the flash can actually stay mapped at 0x0
Aug 27 17:27:50 <[g2]> memory could start at 0x10000000
Aug 27 17:28:13 <ulf___> the memory or flash?
Aug 27 17:28:21 <[g2]> RAM memory
Aug 27 17:28:25 <ulf___> ok
Aug 27 17:28:35 <[g2]> but I'm sure it starts at 0x0 after initialization
Aug 27 17:28:46 <[g2]> well I've got a very strong guess :)
Aug 27 17:29:20 <[g2]> the problem I think you are seeing is that the jtag tools expect the entire flash to be the same sector size
Aug 27 17:29:29 <[g2]> and in you case it isn't
Aug 27 17:29:46 <[g2]> the first 8 blocks are 8K and the next 63 are 64K
Aug 27 17:29:55 <[g2]> for a total of 64 64K block
Aug 27 17:30:48 <ulf___> yes tow parts, i tried blind some eraseflash and flashmem the hole day maybe i killed the device already
Aug 27 17:31:08 <[g2]> I doubt it
Aug 27 17:31:32 <[g2]> I'm not saying it's impossible but unlikely
Aug 27 17:33:08 <ulf___> hmm for example the command flashmem 0x00000000  redboot.bin stops after the first 8 blocks with an error:
Aug 27 17:33:30 <ulf___> block 8 unlocked
Aug 27 17:33:32 <ulf___> flash_erase_block 0x00010000
Aug 27 17:33:33 <ulf___> ..................................flash_erase_block 0x00010000 DONE
Aug 27 17:33:35 <ulf___> erasing block 8: 0
Aug 27 17:33:37 <ulf___> flash_unlock_block 0x00020000 IGNORE
Aug 27 17:33:49 <ulf___> block 9 unlocked
Aug 27 17:33:51 <ulf___> flash_erase_block 0x00020000
Aug 27 17:33:53 <ulf___> ........................flash_erase_block 0x00020000 DONE
Aug 27 17:33:55 <ulf___> erasing block 9: 0
Aug 27 17:33:56 <ulf___> addr: 0x0002CCE20
Aug 27 17:34:20 <ulf___> verify:
Aug 27 17:34:22 <ulf___> addr: 0x00000106
Aug 27 17:34:24 <ulf___> verify error:
Aug 27 17:34:25 <ulf___> readed: 0x0000FFFF
Aug 27 17:34:27 <ulf___> expected: 0x00000810
Aug 27 17:34:43 <[g2]> that's correct it's erased
Aug 27 17:34:57 <[g2]> FFFF is all erased an it's 16 bits wide
Aug 27 17:35:05 <[g2]> and it's
Aug 27 17:37:41 <ulf___> so block 9 is the first block of the second part which is 64k not 8k
Aug 27 17:38:56 <ulf___> now: jtag> flashmem 0x50000000 /home/ulf/slug/redboot.bin
Aug 27 17:38:58 <ulf___> Note: Supported configuration is 2 x 16 bit or 1 x 16 bit only
Aug 27 17:39:00 <ulf___> buswidth: 16
Aug 27 17:39:02 <ulf___> CFI query: 000000aa,       98
Aug 27 17:39:03 <ulf___> Chip: AMD Flash
Aug 27 17:39:05 <ulf___>         Manufacturer: AMD
Aug 27 17:39:07 <ulf___>         Chip: Unknown (ID 0x22f9)
Aug 27 17:39:09 <ulf___>         Protected: 0000
Aug 27 17:39:10 <ulf___> program:
Aug 27 17:39:11 <ulf___> ....................................................................................................
Aug 27 17:39:13 <ulf___> flash error
Aug 27 17:39:41 <[g2]> I'd look at the data sheet for the part
Aug 27 17:40:00 <[g2]> often parts have a set of small sectors for configuration information
Aug 27 17:40:13 <[g2]> you don't want to be wasting 64K for each config block
Aug 27 17:40:28 <[g2]> so they partition the chip in to a couple sections (often two)
Aug 27 17:40:34 <[g2]> with different block sizes
Aug 27 17:40:47 <[g2]> I think it's one chip with two regions
Aug 27 17:41:10 <[g2]> there's a special programming algo that's run from the base address of the blcok
Aug 27 17:41:22 <[g2]> block
Aug 27 17:41:56 <ulf___> yes it has two sections one small 8k one bin 64k
Aug 27 17:42:11 <[g2]> ulf___ I've got to head out for a bit, but I'm in very often
Aug 27 17:42:49 <ulf___> ok
Aug 27 17:43:04 <[g2]> I'd like to enhance jtag to be ixp4xx aware
Aug 27 17:43:23 <[g2]> we should setup canned scripts to enable the memory controller/serial etc...
Aug 27 17:43:58 <[g2]> then we'd be able to x/y/zmodem programs down or load them directly to memory
Aug 27 17:44:18 <[g2]> the board i'm having built is an ixp422 and has a jtag connector on it
Aug 27 17:44:25 <ulf___> yes that would be wonderfull
Aug 27 17:44:25 <[g2]> I should arrive next weeks
Aug 27 17:44:26 <[g2]> I should arrive next week
Aug 27 17:44:29 <ulf___> :)
Aug 27 17:44:42 <[g2]> then I may be in a similar situation
Aug 27 17:44:55 <[g2]> I hope to see you around
Aug 27 17:44:58 <[g2]> I'll be back later
Aug 27 17:44:59 <[g2]> cheers
Aug 27 20:55:58 <ka6sox> there is a big fire near jbowler....
**** ENDING LOGGING AT Sun Aug 28 02:59:56 2005