Flash erase OpenOCD (resolved)

Hello People,

I have got OpenOCD working on a debian 4.0 platform.

I have a KS8695px development board from http://www.micrel.com/

I am using an ARM-USB-TINY jtag connector from Olimex. http://www.olimex.com/

The chipset is ARM922T

I am new to hardware development so this may well be a result of me not knowing exactly what to do, or to mis-interpreting what exactly I am needing to do.

I am able to telnet into the board via OpenOCD, and am able to issue the commands such as flash erase etc, but am getting sector number invalid if I try:

flash erase 0 0 0 or 0 0 1

If I try:

flash write 0x00000000 /home/test/system/release/KS8695P/u-boot.bin 0x0002FFFF binary

I get the following messages:

failed writing /home/test/system/release/KS8695P/u-boot.bin to flash bank 0 at offset 0x0002ffff

unknown error

wrote 113696 byte from file /home/test/system/release/KS8695P/u-boot.bin to flash bank 0 at offset 0x0002ffff in 0s 286us (388221.153846 KB/S)

After that if I do:

flash info 0

I get:

#1: cfi at 0x00000000, size 0x00400000, buswidth 2, chipwidth 2

cfi flash bank not yet probed

then I try:

flash probe 0 with the following result:

probing failed for flash bank 0 at 0x00000000

then I try flash info and get the results:

#1: cfi at 0x00000000, size 0x00400000, buswidth 2, chipwidth 2

cfi information:

mfr: 0x7070, id 0x7070

qry ‘ppp’ pri_id: 0x0000, pri_addr: 0x0000 , alt_id: 0x0000 alt_addr: 0x0000

Vcc min: 0.0 , Vcc max: 0.0, Vpp min: 0.0, Vpp max: 0.0,

typ. word write timeout: 1,

there is more and can provide it if neccessarry.

my config file for OpenOCD is:

#daemon configuration

telnet_port 4444

gdb_port 3333

#interface

interface ft2232

ft2232_device_desc “Olimex OpenOCD JTAG TINY”

ft2232_layout “olimex-jtag”

ft2232_vid_pid 0x15ba 0x0004

jtag_speed 1

#use combined on interfaces or targets that can’t set TRST/SRST separately

reset_config trst_and_srst

#jtag scan chain

#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)

jtag_device 4 0x1 0xf 0xe

#target configuration

daemon_startup reset

#target

target arm9tdmi little reset_halt 0 arm920t

#working_area 0 0x200000 0x4000 backup

run_and_halt_time 0 5000

#flash configuration

#flash bank <chip_width> <bus_width> [driver_options …]

flash bank cfi 0x00000000 0x00400000 2 2 0

I know the working area is commented out, I have tryed with it enabled as well.

this board supports both the Intel and AMD flash utilities.

From part of the documentation for this particular board it has this:

Upon power up, the KS8695PX memory map is configured as shown below.

Total Address Space 64 Mbytes System Config. Regs.

64 kbytes

-------------------------------- 0x03FF0000

RESERVED

--------------------------------- 0x01FFFFFF

Flash Memory Bank 0

32 Mbytes

0x00000000

The default bas address for the KS8695PX system configuration registers is 0x03ff0000. After power up, the user is free to remap the memory for his/her specific application.

Now from editing the source code from arm it has this (I am using the source provided by Micrel for this board):

#define FLASH_BASE 0x02800000

FLASH_DEV_WIDTH 0x8

FLASH_DEV_PARALLEL 0x1

FLASH_STRING “AMD29L033C”

What I would like to know is, what exactly am I missing here?

I got the information for installing this on linux from:

http://www.openhardware.net/Embedded_ARM/OpenOCD_JTAG/

There is not an option to have the jtag from Olimex already configured in the examples. The difference between his configuration and mine is he is using ARM7 and I had to modify the arm9_ft2232.cfg file.

I am unsure what else I need to provide to get some pointers.

Regards,

Christopher.

You first have to ‘probe’ your flash. If that fails there’s no use in trying the other flash related commands.

Once the flash was probed successfully, you can dump information about it with the ‘info’ command, or use the erase and write commands.

You have to make sure that the flash is accessible read-/writeable at the base address specified in the “flash bank …” line. That might require some chip select lines to be configured, or an external bus to be enabled - how this is achieved depends on your target.

Searching for “AMD29L033C” on the internet turned up zero results - you should verify the flash part number and make sure it’s CFI compatible.

Regards,

Dominic

The closest part number to the one the poster gave that I know of is the AM29LV033C, and I think that one is CFI compatible.

Cheers,

–David Carne

This is the log file from OpenOCD. I really need to know what I am doing wrong here. I need to know the correct cfi string. I have searched for hours on how to get this working. I have run out of ideas and options on this.

Debug: jtag.c:1390 jtag_init(): -

Debug: ft2232.c:1420 ft2232_init_libftdi(): ‘ft2232’ interface using libftdi with ‘olimex-jtag’ layout (15ba:0004)

Debug: ft2232.c:1462 ft2232_init_libftdi(): current latency timer: 2

Debug: ft2232.c:1729 olimex_jtag_init(): 80 08 1b

Debug: ft2232.c:1772 olimex_jtag_init(): 82 09 0f

Debug: ft2232.c:252 ft2232_speed(): 86 01 00

Debug: jtag.c:279 jtag_call_event_callbacks(): jtag event: TRST asserted

Debug: jtag.c:1180 jtag_reset_callback(): -

Debug: jtag.c:279 jtag_call_event_callbacks(): jtag event: TRST asserted

Debug: jtag.c:1180 jtag_reset_callback(): -

Debug: jtag.c:1274 jtag_examine_chain(): JTAG device found: 0x00922f0f (Manufacturer: 0x787, Part: 0x0922, Version: 0x0

Debug: jtag.c:279 jtag_call_event_callbacks(): jtag event: TRST asserted

Debug: jtag.c:1180 jtag_reset_callback(): -

Debug: openocd.c:104 main(): jtag init complete

Debug: embeddedice.c:228 embeddedice_read_reg_w_check(): 4

Debug: jtag.c:279 jtag_call_event_callbacks(): jtag event: TRST released

Debug: jtag.c:1180 jtag_reset_callback(): -

Debug: embeddedice.c:329 embeddedice_write_reg(): 2: 0x00000001

Debug: arm7_9_common.c:657 arm7_9_assert_reset(): target->state: unknown

Debug: jtag.c:279 jtag_call_event_callbacks(): jtag event: SRST asserted

Debug: jtag.c:1180 jtag_reset_callback(): -

Debug: jtag.c:279 jtag_call_event_callbacks(): jtag event: TRST asserted

Debug: jtag.c:1180 jtag_reset_callback(): -

Debug: jtag.c:279 jtag_call_event_callbacks(): jtag event: SRST asserted

Debug: jtag.c:1180 jtag_reset_callback(): -

Debug: ft2232.c:990 olimex_jtag_reset(): trst: 1, srst: 1, high_output: 0x02, high_direction: 0x0f

Debug: ft2232.c:990 olimex_jtag_reset(): trst: 0, srst: 1, high_output: 0x03, high_direction: 0x0f

Debug: arm7_9_common.c:872 arm7_9_halt(): target->state: reset

Debug: arm7_9_common.c:723 arm7_9_deassert_reset(): target->state: reset

Debug: jtag.c:279 jtag_call_event_callbacks(): jtag event: SRST released

Debug: jtag.c:1180 jtag_reset_callback(): -

Debug: ft2232.c:990 olimex_jtag_reset(): trst: 0, srst: 0, high_output: 0x09, high_direction: 0x0f

Debug: openocd.c:108 main(): target init complete

Debug: openocd.c:112 main(): flash init complete

Debug: openocd.c:116 main(): NAND init complete

Debug: openocd.c:120 main(): pld init complete

Debug: gdb_server.c:1347 gdb_init(): gdb service for target arm9tdmi at port 3333

Debug: embeddedice.c:228 embeddedice_read_reg_w_check(): 1

Debug: jtag.c:279 jtag_call_event_callbacks(): jtag event: TRST released

Debug: jtag.c:1180 jtag_reset_callback(): -

Debug: embeddedice.c:228 embeddedice_read_reg_w_check(): 1

Debug: embeddedice.c:228 embeddedice_read_reg_w_check(): 1

Debug: embeddedice.c:228 embeddedice_read_reg_w_check(): 1

<snip - you don’t need to post the same message a billion times>

Debug: embeddedice.c:228 embeddedice_read_reg_w_check(): 1

Debug: embeddedice.c:228 embeddedice_read_reg_w_check(): 1

Debug:

Try changing your config file from

#target <type> <endianess> <reset mode> 
target arm9tdmi little reset_halt 0 arm920t

to

target arm920t little reset_run 0

to allow the OpenOCD to manage your target’s MMU and caches. Make sure both the MMU and Cache are off when working with the flash, unless there’s a pagetable that maps the flash to a known address NCNB.

Your target also seems to have a problem with the “reset_halt” startup. The new config file tells the OpenOCD to just reset the target and let it run afterwards. Connect via telnet to localhost port 4444, verify the target is really running with the ‘poll’ command, and issue a “reset halt”. If that doesn’t work, check the reset circuitry on your board - for debug out of reset, the debugger must be able to separately assert the two reset lines nSRST and nTRST.

If reset out of reset isn’t possible use the “arm920t cp15” command to manually disable mmu and caches.

Look into your target’s datasheet to learn how to configure the external bus interface - it’s often necessary to program some chipselect registers to be able to access the whole flash with read/write permissions.

If everything’s setup correctly, try the “flash probe 0” command again.

Regards,

Dominic

Thanks for the reply.

The initaial poll command via telnet showed the target as running.

I have made the suggested change and have issued the reset halt command via telnet. Poll shows:

target state: halted

target halted in ARM state due to debug request current mode, Supervisor

cpsr: 0x00000d3 pc: 0x00000000

MMU: disabled , D-cache disabled, I-cache disabled

If I change the cfi line to 0x02800000 0x00400000

I get memory read caused data abort errors.

If I leave the base address as all 0’s there are no data aborts.

via telnet the probe flash 0 still comes up with an error.

Here is the listing of the log file:

Debug: target.c:1422 handle_reset_command(): -

Debug: embeddedice.c:329 embeddedice_write_reg(): 2: 0x00000001

Debug: arm7_9_common.c:657 arm7_9_assert_reset(): target->state: running

Debug: jtag.c:279 jtag_call_event_callbacks(): jtag event: SRST asserted

Debug: jtag.c:1180 jtag_reset_callback(): -

Debug: ft2232.c:990 olimex_jtag_reset(): trst: 0, srst: 1, high_output: 0x0b, high_direction: 0x0f

Debug: arm7_9_common.c:872 arm7_9_halt(): target->state: reset

Debug: arm7_9_common.c:723 arm7_9_deassert_reset(): target->state: reset

Debug: jtag.c:279 jtag_call_event_callbacks(): jtag event: SRST released

Debug: jtag.c:1180 jtag_reset_callback(): -

Debug: ft2232.c:990 olimex_jtag_reset(): trst: 0, srst: 0, high_output: 0x01, high_direction: 0x0f

Debug: embeddedice.c:228 embeddedice_read_reg_w_check(): 1

Debug: arm7_9_common.c:621 arm7_9_poll(): DBGACK set, dbg_state->value: 0xd

Debug: embeddedice.c:329 embeddedice_write_reg(): 0: 0x00000005

Debug: embeddedice.c:329 embeddedice_write_reg(): 0: 0x00000005

Debug: arm7_9_common.c:990 arm7_9_debug_entry(): target entered debug from ARM state

Debug: arm7_9_common.c:1022 arm7_9_debug_entry(): target entered debug state in Supervisor mode

Debug: arm7_9_common.c:1051 arm7_9_debug_entry(): r0: 0x00451efc

Debug: arm7_9_common.c:1051 arm7_9_debug_entry(): r1: 0x00000001

Debug: arm7_9_common.c:1051 arm7_9_debug_entry(): r2: 0x00000000

Debug: arm7_9_common.c:1051 arm7_9_debug_entry(): r3: 0x00599999

Debug: arm7_9_common.c:1051 arm7_9_debug_entry(): r4: 0x00000001

Debug: arm7_9_common.c:1051 arm7_9_debug_entry(): r5: 0x002ddc37

Debug: arm7_9_common.c:1051 arm7_9_debug_entry(): r6: 0x00409128

Debug: arm7_9_common.c:1051 arm7_9_debug_entry(): r7: 0x00000001

Debug: arm7_9_common.c:1051 arm7_9_debug_entry(): r8: 0xe1a00000

Debug: arm7_9_common.c:1051 arm7_9_debug_entry(): r9: 0x00409128

Debug: arm7_9_common.c:1051 arm7_9_debug_entry(): r10: 0xe1a00000

Debug: arm7_9_common.c:1051 arm7_9_debug_entry(): r11: 0x00000000

Debug: arm7_9_common.c:1051 arm7_9_debug_entry(): r12: 0x00000000

Debug: arm7_9_common.c:1051 arm7_9_debug_entry(): r13: 0x01fff800

Debug: arm7_9_common.c:1051 arm7_9_debug_entry(): r14: 0xc007a0a0

Debug: arm7_9_common.c:1051 arm7_9_debug_entry(): r15: 0x00000000

Debug: arm7_9_common.c:1057 arm7_9_debug_entry(): entered debug state at PC 0x0

Debug: arm920t.c:438 arm920t_post_debug_entry(): cp15_control_reg: 00000078

Debug: embeddedice.c:228 embeddedice_read_reg_w_check(): 1

Debug: embeddedice.c:228 embeddedice_read_reg_w_check(): 1

Debug: embeddedice.c:228 embeddedice_read_reg_w_check(): 1

Debug: embeddedice.c:228 embeddedice_read_reg_w_check(): 1

Debug: arm920t.c:460 arm920t_post_debug_entry(): D FSR: 0x00000018, D FAR: 0x02000001, I FSR: 0x00000007, I FAR: 0xffff000c

Debug: target.c:465 target_call_event_callbacks(): target event 0

Debug: arm7_9_common.c:1868 arm7_9_write_memory(): address: 0x00000000, size: 0x00000000, count: 0x00000001

Debug: arm7_9_common.c:1868 arm7_9_write_memory(): address: 0x00000000, size: 0x00000000, count: 0x00000001

Debug: arm7_9_common.c:1868 arm7_9_write_memory(): address: 0x00000000, size: 0x00000000, count: 0x00000001

Debug: arm7_9_common.c:1722 arm7_9_read_memory(): address: 0x00000000, size: 0x00000001, count: 0x00000001

Debug: embeddedice.c:228 embeddedice_read_reg_w_check(): 1

Debug: target.c:795 target_read_u8(): address: 0x00000000, value: 0xd7

Debug: arm7_9_common.c:1722 arm7_9_read_memory(): address: 0x00000001, size: 0x00000001, count: 0x00000001

Debug: embeddedice.c:228 embeddedice_read_reg_w_check(): 1

Debug: target.c:795 target_read_u8(): address: 0x00000001, value: 0xf0

Debug: arm7_9_common.c:1868 arm7_9_write_memory(): address: 0x00000000, size: 0x00000000, count: 0x00000001

Debug: arm7_9_common.c:1868 arm7_9_write_memory(): address: 0x00000000, size: 0x00000000, count: 0x00000001

Debug: arm7_9_common.c:1868 arm7_9_write_memory(): address: 0x00000000, size: 0x00000000, count: 0x00000001

Debug: arm7_9_common.c:1722 arm7_9_read_memory(): address: 0x00000000, size: 0x00000000, count: 0x00000001

Debug: arm7_9_common.c:1722 arm7_9_read_memory(): address: 0x00000000, size: 0x00000000, count: 0x00000001

Debug: arm7_9_common.c:1722 arm7_9_read_memory(): address: 0x00000000, size: 0x00000000, count: 0x00000001

Debug: cfi.c:1702 cfi_probe(): CFI qry returned: 0xffffffc0 0xffffffc0 0xffffffc0

Debug: arm7_9_common.c:1868 arm7_9_write_memory(): address: 0x00000000, size: 0x00000000, count: 0x00000001

Debug: arm7_9_common.c:1868 arm7_9_write_memory(): address: 0x00000000, size: 0x00000000, count: 0x00000001

I have made the suggested change and have issued the reset halt command via telnet. Poll shows:

target state: halted

target halted in ARM state due to debug request current mode, Supervisor

cpsr: 0x00000d3 pc: 0x00000000

MMU: disabled , D-cache disabled, I-cache disabled

That’s good, it means you were able to halt your target right out of reset. This allows you to work with a clearly defined state, where no (possibly bogus) code executed before.

If I change the cfi line to 0x02800000 0x00400000

I get memory read caused data abort errors.

Arbitrarily changing the flash base address isn't going to help.

According to the 50 page datasheet I found on micrel’s website the target should come with flash bank 0 mapped to address 0x0. Unfortunately the PDF fails to give further information about the state, like default memory width or whether writes are enabled. If you have the “detailed Register Description document” mentioned in the datasheet you might find further information on configuring your target.

To be able to identify your flash the OpenOCD needs to be able to read and write the flash with byte wide accesses (as you have a x8 flash).

Regards,

Dominic

Thanks again for the pointers.

It seems that the board comes with the SDRAM disabled by default.

The following is one of the application notes for the configuration of the board, provided by Micrel.

It is long and I do not know if it will all be able to be posted here, but I am trying it.

I have read documentation and used the information provided in the files mentioned in the programming guide to set the base flash address etc, but I think I may well be mis-enterpreting the information, or as you have said other things may well need to be added, which I really have no idea as to what I need to provide OpenOCD with in order for it to be able to read/write/erase the flash. If it requires another script to be called then this also may be a major issue as I have not written any such script, just calling openocd with the file name of the configuration script.

I have used pdftotext to convert this document.

Application Note 125

BSP Flash Memory and SDRAM Support

KS8695P/PX

  1. Memory Layout

The KS8695P/PX supports two banks of flash memory and two banks of SDRAM. Each bank can be populated

with one, two, or four memory chips. When two or four chips populate a bank, the chips are said to be in parallel

and their memory cells are interleaved to form a contiguously addressable block of memory (see examples

below, where M + 0, M + 1, etc. denote byte addresses). Each bank is assigned a separate chip select (CS)

signal.

Examples of 8 bit chip(s) within a single bank:

· One 8 bit chip

Bank data width: 8 bit

Chip 0

M+0

M+1

|

CS

· Two 8 bit chips in parallel

Bank data width: 16 bit

Chip 0 Chip 1

M+0 M+1

M+2 M+3

|

CS

· Four 8 bit chips in parallel

Bank data width: 32 bit

Chip 0 Chip 1 Chip 2 Chip 3

M+0 M+1 M+2 M+3

M+4 M+5 M+6 M+7

|

CS

Examples of 16 bit chip(s) within a single bank:

· One 16 bit chip

Bank data width: 16 bit

Chip 0

M+0 M+1

M+2 M+3

|

CS

October 2004 M9999-101504

1

Micrel Application Note 125

· Two 16 bit chips in parallel

Bank data width: 32 bit

Chip 0 Chip 1

M+0 M+1 M+2 M+3

M+4 M+5 M+6 M+7

|

CS

Example of 32 bit chip within a single bank:

· One 32 bit chip

Bank data width: 32 bit

Chip 0

M+0 M+1 M+2 M+3

M+4 M+5 M+6 M+7

|

CS

  1. BSP

The KS8695P/PX Evaluation Kit provides you with an evaluation board populated with one bank of flash

memory and two banks of SDRAM. Also provided is board support program (BSP) software that is factory

configured to interface to these memories. When the evaluation board is booted, the BSP programs the

KS8695P/PX with the flash memory and SDRAM configuration. After this is completed, the KS8695P/PX can

read and write both flash memory and SDRAM.

If you elect to change the flash memory and/or SDRAM configuration, the BSP must be re-configured

accordingly. The BSP package provides a convenient way to do this. You simply select appropriate settings for

constant and macro definitions in the BSP source code files described below.

  1. File Soho/loader/include/KS8695.S

This file contains all of the constant definitions used by the bootloader and all of the hardware related constants

and macros.

Flash memory and SDRAM configuration information is defined in this file.

3.1 Flash Memory

The KS8695.S constant, listed below, defines the flash bank data width and chip access time. The evaluation

board uses an 8 bit data width and 72ns access time.

#define ROM_GENERAL_SETTING 0x00000001

Note: This value is written to register External I/O and ROM/SRAM/FLASH General Register (ERGCON Offset

0x4020) during BSP initialization.

3.1.1 Flash Memory Data Width

Modify bits 0-1 of the ROM_GENERAL_SETTING constant to use the following value denoting the appropriate

flash bank data width:

October 2004 M9999-101504

2

Micrel Application Note 125

· 00b denotes the bank is disabled

· 01b denotes 8 bit data width

· 10b denotes 16 bit data width

· 11b denotes 32 bit data width

If you also put one or more flash chips into the second bank, then modify bits 2-3 to use an appropriate value

from the list above. On the demo board, the second bank of flash memory is disabled. If you use the second

bank of flash memory, you will need to write your own code to support this bank. The existing code that supports

the first bank of flash memory can be used as a template for writing your own code.

3.1.2 Flash Memory Access Time

Modify bits 28-29 of the ROM_GENERAL_SETTING constant to define the flash chip access time value

TMULT. The formula for selecting a TMULT value is:

(TMULT*8 + 9)*8 > flash chip access time

In the formula, flash chip access time is the access time of the flash chip you have selected.

Some examples:

· If your flash chip has an access time of 70ns, then TMULT should be set to 0 so that (0*8 + 9)*8 = 72ns

70ns.

· If your flash chip has an access time of 90ns, then TMULT should be set to be 1 so that (1*8 + 9)*8 =

136ns > 90ns.

If you do not set the access time to be greater than the access time of your flash chip, your system will not

operate.

3.1.3 Flash Memory Examples

The following are some ROM_GENERAL_SETTNG examples:

· For one 8 bit flash chip with a 70ns access time, ROM_GENERAL_SETTNG = 0x00000001.

· For one 16 bit flash chip with a 110ns access time, ROM_GENERAL_SETTNG = 0x10000002.

· For two 16 bit flash chips in two banks with a 110ns access times, ROM_GENERAL_SETTNG =

0x1000000A.

· For two 16 bit flash chips in parallel to form a 32 bit data width bank with a 120ns access time,

ROM_GENERAL_SETTNG = 0x10000003.

3.2 SDRAM

The KS8695.S macros listed below define the SDRAM bank data width, number of banks, and number of

column address bits. The demo board uses a 32 bit data width, 4 banks, and 8 column address bits.

#define TMP_SDRAM_REG0 (((SDRAM_BANK_0+SDRAM_BANK0_SIZE-

1)>>16)<<22)|((SDRAM_BANK_0>>16)<<12)|SDRAM_UNM_BANKS4| \

SDRAM_BANK_COLAB8|SDRAM_BANKS_DBW32

#define TMP_SDRAM_REG1 (((SDRAM_BANK_1+SDRAM_BANK1_SIZE-

1)>>16)<<22)|((SDRAM_BANK_1>>16)<<12) | SDRAM_BANK_COLAB8 |

SDRAM_UNM_BANKS4|SDRAM_BANKS_DBW32

October 2004 M9999-101504

3

Micrel Application Note 125

#define SDRAM_REG1 (((SDRAM_BANK_1+SDRAM_BANK1_SIZE-

1)>>16)<<22)|((SDRAM_BANK_1>>16)<<12)|SDRAM_UNM_BANKS4|\

SDRAM_BANK_COLAB8|SDRAM_BANKS_DBW32

#define REM_SDRAM_REG1 (((REMAPPED_SDRAM_BANK_1+SDRAM_BANK1_SIZE-

1)>>16)<<22)|((REMAPPED_SDRAM_BANK_1>>16)<<12)|\

SDRAM_BANK_COLAB8 |SDRAM_UNM_BANKS4|SDRAM_BANKS_DBW32

#define SDRAM_REG0 (((SDRAM_BANK_0+SDRAM_BANK0_SIZE-

1)>>16)<<22)|((SDRAM_BANK_0>>16)<<12)|SDRAM_UNM_BANKS4|\

SDRAM_BANK_COLAB8|SDRAM_BANKS_DBW32

#define REM_SDRAM_REG0 (((REMAPPED_SDRAM_BANK_0+SDRAM_BANK0_SIZE-

1)>>16)<<22)|((REMAPPED_SDRAM_BANK_0>>16)<<12)| \

SDRAM_BANK_COLAB8|SDRAM_UNM_BANKS4|SDRAM_BANKS_DBW32

Note: These values are written to registers SDRAM Control Register 0 (SDCON0 Offset 0x4030) and SDRAM

Control Register 1 (SDCON1 Offset 0x4034).

3.2.1 SDRAM Data Width

Modify the macros above to use the constant below denoting the appropriate SDRAM bank data width:

· SDRAM_BANKS_DBW8 denotes 8 bit data width

· SDRAM_BANKS_DBW16 denotes 16 bit data width

· SDRAM_BANKS_DBW32 denotes 32 bit data width

If you use two SDRAM in parallel (meaning both SDRAM chips share the same chip select), then note the

following:

· If you use two 8 bit SDRAM in parallel, then use SDRAM_BANKS_DBW16.

· If you use two 16 bit SDRAM in parallel, then use SDRAM_BANKS_DBW32.

3.2.2 SDRAM Banks

Modify the macros above to use the constant below denoting the appropriate SDRAM number of banks:

· SDRAM_UNM_BANKS2 denotes SDRAM with 2 banks

· SDRAM_UNM_BANKS4 denotes SDRAM with 4 banks

3.2.3 SDRAM Column Address Bits

Modify the macros above to use the constant below denoting the appropriate number of column address bits:

· SDRAM_BANK_COLAB8 denotes 8 column address bits

· SDRAM_BANK_COLAB9 denotes 9 column address bits

· SDRAM_BANK_COLAB10 denotes 10 column address bits

· SDRAM_BANK_COLAB11 denotes 11 column address bits

  1. File Linux/include/asm-arm/arch-ks8695/platform.h

This file contains many constant and macro definitions used by Linux.

Flash memory configuration information is defined in this file.

October 2004 M9999-101504

4

Micrel Application Note 125

4.1 Flash Memory

The platform.h constants and macros listed below define the flash chip size, bank data width, and interleave.

The demo board uses a 4MB size, 8 bit data width, and no interleave.

#define KS8695_FLASH_SIZE 0x00400000

#define CFI_DEVICETYPE CFI_DEVICETYPE_X8

#define CFI_INTERLEAVE 1

#cfi_buswidth_is _1( ) (1)

#cfi_buswidth_is _2( ) (0)

#cfi_buswidth_is _4( ) (0)

#cfi_interleave_is_1() (1)

#cfi_interleave_is_2() (0)

#cfi_interleave_is_4() (0)

4.1.1 Flash Memory Size

Modify the KS8695_FLASH_SIZE constant to use the value below denoting the appropriate flash chip size:

· 0x00400000 denotes 4MB

· 0x00800000 denotes 8MB

Note: A 2MB flash chip size is not a supported option because the BSP requires more than 2MB of flash

memory.

4.1.2 Flash Memory Data Width

Modify the CFI_DEVICETYPE constant to use the constant below denoting the appropriate flash bank data

width:

· CFI_DEVICETYPE_X8 denotes 8 bit data width

· CFI_DEVICETYPE_X16 denotes 16 bit data width

· CFI_DEVICETYPE_X32 denotes 32 bit data width

Modify the cfi_buswidth_is _1, cfi_buswidth_is _2, and cfi_buswidth_is _4 macros to use the values below

denoting the appropriate flash bank data width:

· For an 8 bit data width set the macros as follows:

#cfi_buswidth_is _1( ) (1)

#cfi_buswidth_is _2( ) (0)

#cfi_buswidth_is _4( ) (0)

October 2004 M9999-101504

5

Micrel Application Note 125

· For a 16 bit data width set the macros as follows:

#cfi_buswidth_is _1( ) (0)

#cfi_buswidth_is _2( ) (1)

#cfi_buswidth_is _4( ) (0)

· For a 32 bit data width set the macros as follows:

#cfi_buswidth_is _1( ) (0)

#cfi_buswidth_is _2( ) (0)

#cfi_buswidth_is _4( ) (1)

4.1.3 Flash Memory Interleave

Modify the CFI_INTERLEAVE constant to use the value below denoting the appropriate flash chip interleave:

· 1 denotes one flash chip is used

· 2 denotes two flash chips are used in parallel

· 4 denotes four flash chips are used in parallel

Modify the cfi_interleave_is_1, cfi_interleave_is_2, and cfi_interleave_is_4 macros to use the values below

denoting the appropriate flash chip interleave:

· For one flash chip, set the macros as follows:

#cfi_interleave_is_1() (1)

#cfi_interleave_is_2() (0)

#cfi_interleave_is_4() (0)

· For two flash chips used in parallel, set the macros as follows:

#cfi_interleave_is_1() (0)

#cfi_interleave_is_2() (1)

#cfi_interleave_is_4() (0)

· For four flash chips used in parallel, set the macros as follows:

#cfi_interleave_is_1() (0)

#cfi_interleave_is_2() (0)

#cfi_interleave_is_4() (1)

October 2004 M9999-101504

6

Micrel Application Note 125

  1. File Soho/loader/include/flashMap.h

Flash memory configuration information is defined in this file.

5.1 Flash Memory

The flashMap.h constants listed below define the flash bank data width, interleave, and name. The demo board

uses an 8 bit data width, no interleave, and “AMD29LV033C”.

#define FLASH_DEV_WIDTH 0x8

#define FLASH_DEV_PARALLEL 0x1

#define FLASH_STRING “AMD29LV033C”

5.1.1 Flash Memory Data Width

Modify the FLASH_DEV_WIDTH constant to use the value below denoting the appropriate flash bank data

width:

· 0x8 denotes 8 bit data width

· 0x10 denotes 16 bit data width

· 0x20 denotes 32 bit data width

5.1.2 Flash Memory Interleave

Modify the FLASH_DEV_PARALLEL constant to use the value below denoting the appropriate flash chip

interleave:

· 1 denotes one flash chip is used

· 2 denotes two flash chips are used in parallel

· 4 denotes four flash chips are used in parallel

5.1.3 Flash Memory Name

Modify the FLASH_STRING constant to use the string denoting the appropriate flash chip name.

An example:

· “AMD29LV033C”

  1. File Soho/loader/linuxloader/Makefile

SDRAM configuration information is defined in this file.

6.1 SDRAM

The Makefile constants listed below define the SDRAM size. The demo board uses a 16MB SDRAM in both

banks.

SDRAM_SIZE_BANK0 = 0x01000000

SDRAM_SIZE_BANK1 = 0x01000000

October 2004 M9999-101504

7

Micrel Application Note 125

6.1.1 SDRAM Size

Modify the SDRAM_SIZE_BANK0 and SDRAM_SIZE_BANK1 constants to use the values below denoting the

appropriate SDRAM size:

· 0x00000000 denotes the bank is disabled

· 0x01000000 denotes 16MB

· 0x02000000 denotes 32MB

Some examples:

· For a 16MB SDRAM in both banks, set the constants as follows:

SDRAM_SIZE_BANK0 = 0x01000000 (16MB)

SDRAM_SIZE_BANK1 = 0x01000000 (16MB)

· For a 32MB SDRAM in one bank (i.e. one chip select), set the constants as follows:

SDRAM_SIZE_BANK0 = 0x02000000 (32MB)

SDRAM_SIZE_BANK1 = 0x00000000 (disabled)

Note: An 8MB SDRAM size is not a supported option because the BSP requires more than 8MB of SDRAM.

  1. Verifying New BSP Configuration

After the appropriate changes have been made to the files described above, rebuild and test the BSP to verify

proper flash memory and SDRAM operation.

Regards,

Christopher.

Something else that came to my mind: which version of the OpenOCD do you use? Please make sure you’re using the latest version available from SVN, and upload a log to pastebin.ca.

Please don’t post complete logs in this forum without being asked to, and don’t post complete datasheets - this thread is getting increasingly difficult to read.

Regards,

Dominic

Sorry about that, just wanted to provide as much information as possible.

I have re-downloaded from svn recompiled and re-installed. I had only installed OpenOCD a couple of weeks ago from svn, but just wanted to make sure.

I have posted a full log at:

http://pastebin.ca/564028

regards,

Christopher.

Ok, that was with 0x02800000 as the flash base address, but the datasheet says flash should be mapped at 0x0 after a reset, and the log doesn’t show any attempts to remap the flash.

Could you post another log with flash base 0x0?

Regards,

Dominic

Changed the base address to 0x0 and posted updated log:

http://pastebin.ca/564097

regards,

Christopher.

Okay, one more thing to test:

  • start the OpenOCD

  • open telnet

  • use the reset halt command

  • dump the first few words from 0x0: “mdw 0x0 16”

Post the telet output here, it’s only a few lines.

Regards,

Dominic

Here are the results:

0x00000000: e321f0d7 e3a0d402 e321f0db e59fd258 e321f0d1 e59fd254 e321f0d2 e59fd250

0x00000020: e321f0d3 e59fd24c e321f0df e59fd248 e59f4248 e3a05901 e0855004 e59f8240

Regards,

Christopher.

Erm,

Where to from here?

Regards,

Christopher.

Back to thinking…

The values returned while probing for the JEDEC ID are the flash content at those addresses, while the value returned during the CFI probe apparently isn’t anywhere near those addresses.

It seems that this flash type uses a non-standard 4-cycle autoselect command sequence. I’ll look into writing a short patch to test this.

Regards,

Dominic

Hello Dominic,

Thanks for the assistance with this. Not sure if you already have it, but I have located a spec sheet for this flash at:

http://www.alldatasheet.net/datasheet-p … 3C-70.html

Not sure if it will be any assistance with regards to any patch that you may have to write.

It seems that Micrel may well have their own way of addressing this flash as in their code they use the flash string AMD29LV033C, which is no help until I am actually able to put the images onto the board to start with. It also explains why you were unable to find that flash on google when you searched. If you need it I can upload parts of the C source code that reference this board to the web hosting company that I host my domain on and give you access via ftp to retrive it.

I am just not sure how much of it you would need, if indeed any of it. Just let me know.

Regards,

Christopher.

Sorry, I got that wrong. Your devices uses the standard autoselect sequence, but apparently doesn’t enter autoselect mode, but rather remains in read array mode (that is IF we’re actually talking to the flash, and not some other memory).

I don’t think there’s anything we can do unless you have access to the “Detailed Register Description” mentioned in the datasheet. The chip comes out of reset with “Flash Bank 0” mapped at 0x0 and the System Configuration Register Space mapped at 0x03ff00000.

At the moment it looks as if the writes to the flash chip fail, while reading works. It isn’t uncommon for a uC to have the external chipselect used for booting configured as read-only. You’d have to change that to read/write to be able to program the flash.

Maybe there’s something in the C source you have that shows how to program the SCRs, but having the “detailed register description” would be a lot easier.

Regards,

Dominic

Hello Dominic,

I have uploaded the detailed register to:

http://register.pc-tech-support.com/ks8 … gister.pdf

I am unsure of exactly what I am meant to look for in it. This is 140 pages, but it does list flash etc in it.

Thanks again for your input.

Regards,

Christopher.

Hi Christopher,

I grabbed the document, but you should take that down again. Apparently Micrel doesn’t want this document avilable publicly, so it’s better not to risk anything by having it online.

I’ll have a look later today.

Regards,

Dominic