This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
FLASH woes continue
- From: "Krishna Ganugapati" <krishnag at marakicorp dot com>
- To: "eCos Discussion" <ecos-discuss at ecos dot sourceware dot org>
- Date: Mon, 27 Sep 2004 10:57:33 -0700
- Subject: [ECOS] FLASH woes continue
My flash woes still continue..
1) I've started my board with ICACHE on and DCACHE disabled. - board works
beautifully, for some reason whenever I execute the mcr instruction to
enable the dcache (bit 2 in the cache control registers). However when I
skip that one instruction it works beautifully well. I don't see this as a
problem yet, the mmu is on and the dcache is off and this is a valid
configuration
2) When the flash has to be initialized for the first time, the
flash_hwr_init calls the flash_dev_query function, which then calls
flash_query -> the function which probes the flash for its configuration
(num blocks, size of a block, sizeof of the write buffer and so on). Because
we're probing the flash, this function needs to be copied into memory and
then executed. This is the purpose of the attribute
section(".2ram.flash_query") causes the hal initialization to do the copy.
Now because we're switching from executing in flash to executing in RAM, the
flash_dev_query function executes the following:
HAL_CACHES_OFF(_d_, _i)
HAL_CACHES_OFF(_d_, _i_) does the following:
HAL_DCACHE_IS_ENABLED(_d_)
HAL_DCACHE_SYNC();
HAL_DCACHE_INVALIDATE_ALL()
HAL_DCACHE_DISABLE();
HAL_ICACHE_INVALIDATE_ALL();
Now because I've disabled my dcache to start with, I replaced this macro
with HAL_ICACHE_INVALIDATE_ALL()
3) Now the strangest thing happens - we successfully transfer to the
flash_query function in RAM
00089ac <flash_query>:
89ac: e3a02098 mov r2, #152 ; 0x98
89b0: e3a01205 mov r1, #1342177280 ; 0x50000000
89b4: e3a03bc3 mov r3, #199680 ; 0x30c00
89b8: e1c120b0 strh r2, [r1]
89bc: e3a02034 mov r2, #52 ; 0x34
89c0: e2833d05 add r3, r3, #320 ; 0x140
89c4: e2433001 sub r3, r3, #1 ; 0x1
89c8: e3530000 cmp r3, #0 ; 0x0
89cc: cafffffc bgt 89c4 <flash_query+0x18>
89d0: e3520000 cmp r2, #0 ; 0x0
89d4: da000004 ble 89ec <flash_query+0x40>
89d8: e0d130b2 ldrh r3, [r1], #2
89dc: e2422001 sub r2, r2, #1 ; 0x1
89e0: e3520000 cmp r2, #0 ; 0x0
89e4: e4c03001 strb r3, [r0], #1
89e8: cafffffa bgt 89d8 <flash_query+0x2c>
89ec: e3a030ff mov r3, #255 ; 0xff
89f0: e1c130b0 strh r3, [r1]
89f4: e3a00000 mov r0, #0 ; 0x0
89f8: e12fff1e bx lr
The first three instructions or more never execute - so I never get my mov
r1, 0x50000000 executed. I'd thought that because prior to switching from
flash to RAM, given that I've invalidated the cache, I'm assured that I will
force the code to be loaded from memory but almost invariably I will never
get 0x50000000 (which is the location of my FLASH into register r2 similarly
I never get 0x30c00 loaded into r3 (this is the cnt value to create a 20
msec delay once the Flash_ReadQuery opcode is written to 0x50000000 to
switch mode from ReadArray to ReadQuery - Following this everything is
downhill, I never seem to be able to return the StrataFlash ReadQuery
information..
Any thoughts on what I'm doing wrong here?
Krishna
-------------------------------------------------
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss