Hi Pete right now i'm fighting one of broadcom SOCs. But it seems like yours is other kind. Can you please tell which EJTAG version is it?
Any way. About endians you can check CP0 Status and Config registers by using this commands: mips32 cp0 12 0 mips32 cp0 15 0 At least it should display what endian configuration it is using. Changing it Status register, should not affect ejtag and in Config register it is readonly. But who knows... You will need to find EJTAG documentation according your version. All after version 2.5 should be available in internet. Now to your flash. I see that you set 16bit bus mode and 16 bit flash mode. But manually you tests 0x1fc00020 which according to your flash doc should be 8bit mode. Till now i never seen that manufacture decided to reduce flash size to performance. I mean if you use 16bit mode, you will get half size for same price ;) Try some thing like this: flash bank $_FLASHNAME cfi 0x1fc00000 0x00400000 1 1 $_TARGETNAME x16_as_x8 may be you'll need different address: 0xbe000000 Am 30.06.2013 02:37, schrieb Pete Batard: > Well, since I'm here, and never got around to report the following: > > I've been using OpenOCD 7.0 in order to access a Broadcom BCM6338 (MIPS > big endian) based board that also sports 4 MiB of Spansion > S29GL032A90TFIR4 flash. > Eventually, what I'd like to do is be able to use the OpenOCD CFI > implementation to write to the flash. > > Things seem to be working OK, as far as the CPU is concerned and I can > also dump the flash through the dump_image command (in the expected > endian format). However 16-bit CFI access on that big endian MIPS target > doesn't seem to be to OpenOCD's liking. > > First of all, here's the outcome from flash probe (using the config file > attached): > > ------------------------------------------------------------------------ > Open On-Chip Debugger >> scan_chain > TapName Enabled IdCode Expected IrLen IrCap > IrMask > -- ------------------- -------- ---------- ---------- ----- ----- ------ > 0 bcm6338.cpu Y 0x0633817f 0x0633817f 5 0x01 0x1f >> bcm_halt > Halting CPU... > target state: halted > target halted in MIPS32 mode due to debug-request, pc: 0x00000000 > Disabling watchdog... >> flash probe 0 > Flash Manufacturer/Device: 0x227e 0x0001 > Could not probe bank: no QRY > Try workaround w/0x555 instead of 0x55 to get QRY. > Could not probe bank: no QRY > auto_probe failed > in procedure 'flash' > ------------------------------------------------------------------------ > > 0x227e/0x0001 is the expected ID for the Spansion flash, so the base > address should be fine. Furthermore, the debug output reveals some > interesting data with regards to the output of the first QRY attempt. > > ------------------------------------------------------------------------ > Debug: 304 51828 command.c:145 script_debug(): command - ocd_command > ocd_command type ocd_flash probe 0 > Debug: 305 51841 command.c:145 script_debug(): command - ocd_flash > ocd_flash probe 0 > Debug: 307 51854 mips_m4k.c:974 mips_m4k_write_memory(): address: > 0x1fc00aaa, size: 0x00000002, count: 0x00000001 > Debug: 308 51870 mips_m4k.c:974 mips_m4k_write_memory(): address: > 0x1fc00554, size: 0x00000002, count: 0x00000001 > Debug: 309 51885 mips_m4k.c:974 mips_m4k_write_memory(): address: > 0x1fc00aaa, size: 0x00000002, count: 0x00000001 > Debug: 310 51899 mips_m4k.c:915 mips_m4k_read_memory(): address: > 0x1fc00000, size: 0x00000002, count: 0x00000001 > Debug: 311 51914 mips_m4k.c:915 mips_m4k_read_memory(): address: > 0x1fc00002, size: 0x00000002, count: 0x00000001 > Info : 312 51928 cfi.c:2579 cfi_probe(): Flash Manufacturer/Device: > 0x227e 0x0001 > Debug: 313 51936 mips_m4k.c:974 mips_m4k_write_memory(): address: > 0x1fc00000, size: 0x00000002, count: 0x00000001 > Debug: 314 51951 mips_m4k.c:974 mips_m4k_write_memory(): address: > 0x1fc00000, size: 0x00000002, count: 0x00000001 > Debug: 315 51967 mips_m4k.c:974 mips_m4k_write_memory(): address: > 0x1fc000aa, size: 0x00000002, count: 0x00000001 > Debug: 316 51982 mips_m4k.c:915 mips_m4k_read_memory(): address: > 0x1fc00020, size: 0x00000002, count: 0x00000001 > Debug: 317 51997 mips_m4k.c:915 mips_m4k_read_memory(): address: > 0x1fc00022, size: 0x00000002, count: 0x00000001 > Debug: 318 52011 mips_m4k.c:915 mips_m4k_read_memory(): address: > 0x1fc00024, size: 0x00000002, count: 0x00000001 > Debug: 319 52025 cfi.c:2491 cfi_query_string(): CFI qry returned: 0x52 > 0x51 0x02 > (...) > ------------------------------------------------------------------------ > > 0x52 0x51 is 'R' 'Q'. And indeed, performing a manual query reveals that > we actually have the expected data, only in mixed order: > > ------------------------------------------------------------------------ >> mwh 0x1fc000aa 0x0098 >> mdh 0x1fc00020 4 > 0x1fc00020: 0052 0051 0002 0059 => 'R' 'Q' \02 'Y' > > mdb 0x1fc00020 8 > 0x1fc00020: 52 00 51 00 02 00 59 00 => same, with half words now LE > > mdw 0x1fc00020 2 > 0x1fc00020: 00510052 00590002 => 'Q' 'R' 'Y' \02 > ------------------------------------------------------------------------ > > A little search indicates that this is a similar issue as the one that > was referenced in this thread [1]. However the workaround provided then > [2] (switching a CPU flag to set it to big endian mode) is not something > I have been able to figure out how to do on this CPU so far. > > I have tried setting the target to little endian in the config file, but > got the same results for the md[b|h|w] data (however, in LE, "flash > probe 0" fails to read the chip ID) and I know the default for that > board's firmware should be big endian. > > Could/should this reordering of data, needed to access the flash in CFI > mode, be a problem that should be handled on the OpenOCD side? > > > Or is this a case of, despite the config file indicating big endian, as > well as the MIPS target running in big endian prior to halt, the halt > command resetting accesses to little endian? > > Any insight on that issue would be appreciated. > > Regards, > > /Pete > > [1] > http://lists.berlios.de/pipermail/openocd-development/2007-September/000333.html > > [2] > http://lists.berlios.de/pipermail/openocd-development/2007-September/000334.html > > > > > > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > > > > _______________________________________________ > OpenOCD-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openocd-devel > -- Regards, Oleksij ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
