Michael,
Thanks for your reply. I'm sure that the flash is not empty, it contains the
original firmware of the device which boots up correctly. So in this case it
should not be write protected as it reads contents from the flash during the
boot proceess? Or maybe it is locked again after the boot process is complete.
Maybe I can try to reset and halt it directly to make a dump of the flash
memory?
The flash chip is a single Intel TE28F160 chip which has the Advanced Bootblock
flash functionality, which is described in the openOCD
documentation. I can try to issue a flash protect 0 on the flash before
querying it. (documentation states that this type of flash memory probably
needs to have this command issued)
ALso it seems from the remark of Vlacav that the flash query addresses in the
log files I attached in my last mail were not correct (AAA, 554, AAA instead of
AAA, 555, AAA). This makes me think that I need to try the 8bit bus width for
the flash instead.
> 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
Thanks,
>
> 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
