On Fri, Mar 23, 2012 at 10:13:19AM +0100, Jeroen Peelaerts wrote: > But when probing for the flash memory, I get the following output (filtered > the output a bit) > > Debug: 9935 163572 command.c:145 script_debug(): command - ocd_command > ocd_command type ocd_flash probe 0 > Debug: 9936 163572 command.c:145 script_debug(): command - ocd_flash > ocd_flash probe 0 > > Debug: 9943 163578 mips_m4k.c:844 mips_m4k_write_memory(): address: > 0x9fc00aaa, size: 0x00000002, count: 0x00000001 > Debug: 9972 163658 mips_m4k.c:844 mips_m4k_write_memory(): address: > 0x9fc00554, size: 0x00000002, count: 0x00000001 > Debug: 10001 163738 mips_m4k.c:844 mips_m4k_write_memory(): address: > 0x9fc00aaa, size: 0x00000002, count: 0x00000001 > Debug: 10030 163818 mips_m4k.c:785 mips_m4k_read_memory(): address: > 0x9fc00000, size: 0x00000002, count: 0x00000001 > Debug: 10060 163898 mips_m4k.c:785 mips_m4k_read_memory(): address: > 0x9fc00002, size: 0x00000002, count: 0x00000001 > Info : 10090 163978 cfi.c:2619 cfi_probe(): Flash Manufacturer/Device: 0xffff > 0xffff > Debug: 10091 163978 mips_m4k.c:844 mips_m4k_write_memory(): address: > 0x9fc00000, size: 0x00000002, count: 0x00000001 > Debug: 10121 164058 mips_m4k.c:844 mips_m4k_write_memory(): address: > 0x9fc00000, size: 0x00000002, count: 0x00000001 > Debug: 10150 164138 mips_m4k.c:844 mips_m4k_write_memory(): address: > 0x9fc000aa, size: 0x00000002, count: 0x00000001 > Debug: 10179 164218 mips_m4k.c:785 mips_m4k_read_memory(): address: > 0x9fc00020, size: 0x00000002, count: 0x00000001 > Debug: 10209 164298 mips_m4k.c:785 mips_m4k_read_memory(): address: > 0x9fc00022, size: 0x00000002, count: 0x00000001 > Debug: 10239 164378 mips_m4k.c:785 mips_m4k_read_memory(): address: > 0x9fc00024, size: 0x00000002, count: 0x00000001 > Debug: 10269 164458 cfi.c:2531 cfi_query_string(): CFI qry returned: 0xff > 0xff 0xff > Debug: 10270 164458 mips_m4k.c:844 mips_m4k_write_memory(): address: > 0x9fc00000, size: 0x00000002, count: 0x00000001 > Debug: 10299 164538 mips_m4k.c:844 mips_m4k_write_memory(): address: > 0x9fc00000, size: 0x00000002, count: 0x00000001 > Error: 10329 164618 cfi.c:2537 cfi_query_string(): Could not probe bank: no > QRY > User : 10330 164618 cfi.c:2648 cfi_probe(): Try workaround w/0x555 instead of > 0x55 to get QRY. > Debug: 10331 164618 mips_m4k.c:844 mips_m4k_write_memory(): address: > 0x9fc00aaa, size: 0x00000002, count: 0x00000001 > Debug: 10360 164698 mips_m4k.c:785 mips_m4k_read_memory(): address: > 0x9fc00020, size: 0x00000002, count: 0x0000000 > > It seems that I get 0xff for every value I read out on the flash starting > address (0x9fc00000). This was the same when I tried to dump a firmware image > using dump_image, except for three occasional b's in the file. > > Is this declaration correct for MIPS32 with 16bit sdram interface? > > flash bank cfi 0x9fc00000 0x200000 2 2 > > The CPU uses 32bit instructions and the sdram is 16 bit wide according to the > specs. The flash chip uses Up to One Hundred-Twenty-Seven 32 > Kword Blocks, so I suppose the chip width and bus width are correct here?
Okay, so it seems you have control over the CPU core (which is the hard part). The SDRAM width is not relevant for flash access (unless they share the same bus and settings, which is rare nowadays). You need to find out - the type and number of flash chips - the *used* bus width of the flash chips. Note: 16-bit chips can be connected by using only 8 bits - you need to tell OpenOCD if this is the case, because the address bits (0x5555/0xAAAA during ID read) need to be shifted accordingly, also when two or more flash chips are used in parallel to make up the required data bus width. flash bank cfi 0x9fc00000 0x200000 2 2 means you have a single 16-bit flash that is connected to a 16-bit data bus. - the required configuration of the local bus controller where the flash chips are connected. On most SOCs, this is configurable in some way - bus width, read only/write enabled etc.. Bus width will probably be correct (otherwise, booting from flash would be impossible), but the chip select might come up as write-protected, which means even the ID probing of the flash would fail. Now, if the device boots from flash, the local bus controller should come up with a configuration that allows reading the flash contents after reset, so a dump of the flash address area should show the flash contents without requiring any special setup. Do you know the flash is not empty? cu Michael ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
