This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: S3C4510: invalidate cache


Yes, make sure that the value for KS32C_CACHE_SETx_ADDR are correct for your
processor.  These are defined in plf_io.h.

//--------------------------------------------------------------------------
---
// Cache
#if defined(CYG_HAL_CPUTYPE_KS32C5000A)	// Now known as the S3C4500
#define KS32C_CACHE_SET0_ADDR       0x14000000
#define KS32C_CACHE_SET1_ADDR       0x14800000
#define KS32C_CACHE_TAG_ADDR        0x15000000
#else  // S3C4510[AB]=KS32C50100[AB], S3C4530=KS32C50300
#define KS32C_CACHE_SET0_ADDR       0x10000000
#define KS32C_CACHE_SET1_ADDR       0x10800000
#define KS32C_CACHE_TAG_ADDR        0x11000000
#endif

Yes, the only difference between these two is the non-cachable address bit.
The User Manual for the S3C4510B indicates the addresses to use.  The cache
tag line address space is not part of the cachable/non-cachable address
space.  I didn't have access to the manual for the S3C4500, so I just
defined the correct values for the S3C4510B and left the existing code
unchanged.  You may be right in that the values are wrong for all variants.

I've also had some problems with the Write Buffer Enable bit in the SYSCFG
register.  Still waiting for the FAE to clarify it's function.  I also
experienced problems with the cache with the S3C4510B processor.  Here's a
copy of the related dialogue.

It turns out that this was the cause of the problem I was having.  My
processor (Samsung S3C4510B) is using the unified cache definitions from
flash.h.  The comment in the header file (flash.h) states that the ucache
code has not been tested yet on any target.

The HAL_FLASH_CACHES_OFF() macro for the unified cache model is not correct
for the Samsung processor (probably for any processor).  The problem is that
it invalidates the cache tag lines BEFORE disabling the cache, which creates
a race condition that can (and did in my case) lead to a cache coherency
problem.  The symptom was that the eCos scheduler would just stop running
certain tasks.

My fix was to override the HAL_FLASH_CACHES_OFF() macro in my platform
hal_cache.h file, and reverse the two lines that invalidate the cache lines
and disable the cache.  If the flash driver had indeed disabled the
interrupts as the comments in flash.h state, this race condition would not
have happened either.  By changing my HAL_FLASH_CACHES_OFF() macro, I can
solve the problem without having to disable interrupts (always preferable),
or changing the public code (there are dire warnings about changing anything
in flash.h).

Jay

-----Original Message-----
From: Jonathan Larmour [mailto:jifl@eCosCentric.com]
Sent: Tuesday, July 01, 2003 9:36 PM
To: Jay Foster
Cc: 'ecos-discuss@sources.redhat.com'; 'Jay Foster'
Subject: Re: [ECOS] HAL_FLASH_CACHES_XXX


Jay Foster wrote:
> The comments for the HAL_FLASH_CACHES_ON and HAL_FLASH_CACHES_OFF macros
in
> flash.h state that these macros must be called with interrupts disabled.
> This seems to make sense.  However, code inspection reveals that they are
> called with interrupts enabled.  I see no interrupt disabling in
> flash_dev_query(), flash_erase(), flash_program(), flash_lock() and
> flash_unlock() or in the functions that call these.  Am I missing
something
> here?  It seems unlikely that if this were a real problem that it would
have
> gone unoticed for very long.

Only in as much as that the caller should disable interrupts if needed.

The comment in flash.h is slightly exaggerating - it's generally true in 
most cases people use it, but it's possible to use this safely with 
interrupts enabled if you are running out of RAM or somewhere that isn't 
flash anyway (such that an interrupt can't touch flash, although also that 
it won't go and re-enable the cache either!). Saying you "can't" is safer, 
but actually forcing ints off is unfriendly.

The flash layer was originally only written to be used with RedBoot, not 
ecos, and this is a throwback to then, and something that will have to be 
solved properly throughout the package, not just here. And then we could 
also document the API properly too :-).

Jay

-----Original Message-----
From: Roland Caßebohm [mailto:roland.cassebohm@visionsystems.de]
Sent: Tuesday, November 04, 2003 7:30 AM
To: ecos-discuss@sources.redhat.com
Subject: [ECOS] S3C4510: invalidate cache


Hi,

I had several problems using fash driver with our new platform
using the Samsung S3C4510B ARM7TDMI processor. Our hal is based
on the SNDS100 hal. While flash accessing the cache will be
disabled and invalidated using HAL_UCACHE_INVALIDATE_ALL().

For example in flash_dev_query():
After the flash driver reenables the cache, it verifies the read
id's of the flash device, which are save in the variable id[2]
in stack. But the S3C4510B seems to read the invalide cache.

The macro HAL_UCACHE_INVALIDATE_ALL() of the SNDS100 hal uses
the strategy which is discriped in the S3C4510B manual. Only 
one thing is different, the SNDS100 hal sets the "non-cacheable"
bit (0x4000000) while deleting tag-ram. But right this seems to 
make the problems. I have changed this back to don't use this
bit and now it works.

The E7T hal also use this tag-addresses, should I make a patch
for both platforms, SNDS100 and E7T?

Regards,
Roland

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]