[Bug 1001606] Enable the cache on Kinetis in RAM startup mode

[bugzilla-daemon at bugs dot ecos dot sourceware dot org]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001606

--- Comment #15 from Jonathan Larmour <jifl@ecoscentric.com> 2012-06-26 21:53:57 BST ---
Hi Ilija,

(In reply to comment #14)
> (In reply to comment #11)
> > So what we should be doing is saying that the standard behaviour for Kinetis
> > ports is for all code to run at addresses from 0x0 - 0x1fffffff in order to go
> > via the PC bus; and all data is accessed from 0x20000000 - 0xffffffff to go via
> > the PS bus. Then we can say that HAL_ICACHE macros correspond to the code
> > addresses, and HAL_DCACHE macros correspond to the data.
> 
> Then I would consider the following:
> 
> 1. Separate cacheing is only applicable to mlt_*sram2s* memory layouts. I'd
> expect the majority of users to be happier with mlt_*unisram*, especially on
> devices with smaller SRAM.

Admittedly I have only been looking at the K70 so maybe things are different
elsewhere, but SRAM isn't cacheable anyway (as per 3.5.4.1 Local memory
controller region assignment, page 126 of the K70 Ref manual) - presumably
because SRAM is as fast as cache. So we can ignore SRAM when it comes to
caching.

For the other regions, they are available mirrored, e.g. with one DRAM alias
writethrough at 0x08000000 - 0x0FFFFFFF, which is in the PC range and clearly
aimed at code, and DRAM higher up in the PS range which can also be writeback
mode, and is clearly aimed at data.

So I don't see the need to do things different with the cache, though it's
still reasonable to have the two layouts because of the difficulty in spreading
memory between regions - this could be solved with a little more linker
intelligence, so I've now submitted this for the future, not that it helps us
now: <http://sourceware.org/bugzilla/show_bug.cgi?id=14299>).

> 2. The internal FLASH is only accessible at base address 0x0 i.e. from PC bus.
> This implies that .rodata has to be relocated in either SRAM_U or external RAM
> (for systems that have external RAM).

It doesn't have to really. Being read-only means you don't have to worry about
the data changing though, so I don't believe it makes any difference to my
suggestion on the memory layout and therefore caches. It's true the flash
driver would have to invalidate both caches, but then that's standard practice
for any flash driver.

We could theoretically relocate it as an option as SRAM is slightly faster than
flash (which has to go via the crossbar switch). But I'm not sure this is much
of a priority as I expect people would consider it much more important to save
the memory.

> Probably for external RAM it is not a big problem (although we probably need to
> do some profiling).
> For systems with only internal SRAM we it's a trade-off between limited SRAM
> resource and benefits of separated caches (as we still need caches for the
> FLASH). AFAICT, with the application of .noncache for bus master shared memory,
> we won't have much need for cache invalidations, and even if we have
> invalidations they are related to loader and/or debugger, therefore
> invalidation of both caches won't be a big penalty.

Anything which uses DMA is a concern.

[snip stuff which doesn't need reply]

> May we introduce another input section, something like .2sram? I would keep
> .2ram as is, it would be useful for large program sections that can't fit in
> SRAM. I can imagine applications that may make use of both.

Although it would be harmless to do so, there's already a .sram section
supported in the Cortex-M arch HAL's cortexm.ld, which would do the same thing,
so there isn't a need at the moment. Arguably it's better to just document one
standard one across all Cortex-M.

> What about adding a command "(in)visible" to cdl_option and cdl_component?

I think it's better doing it from the other end - the configuration tool should
have an option, essentially a filter, which could be used to show/hide
calculated packages/components/options, or inactive ones, or interfaces. I
don't think CDL should be getting involved in display semantics, just content.
Anyway this is a side-issue.

> (In reply to comment #8)
[snip, CYGPKG_HAL_KINETIS_CACHE]
> Probably it might be "calculated CYGINT_HAL_CACHE". I'll reconsider.

That would be fine too, the effect is the same since it's inactive if
!CYGINT_HAL_CACHE.


[more snip good stuff]

> > >     - What would be appropriate setting for DCACHE_SIZE / ICACHE_SIZE and
> > > DCACHE_WAYS / ICACHE_WAYS (Each Kinetis cache size is 8KiB with 2 ways)?
> > > 
> > > Current setting is:
> > > #define    DCACHE_SIZE (2*8192)
> > > #define    DCACHE_WAYS (2*2)
> > > 
> > > #define    ICACHE_SIZE (2*8192)
> > > #define    ICACHE_WAYS (2*2)
> > 
> > Based on my suggestion above, we would treat each cache independently then, so:
> > #define    DCACHE_SIZE (8192)
> > #define    DCACHE_WAYS (2)
> > 
> > #define    ICACHE_SIZE (8192)
> > #define    ICACHE_WAYS (2)
> 
> What would be your suggestion if we treat(ed) them as unified?

As above, I still don't think there's a need for them to be unified. But if I'm
wrong about that, then your first suggestion above looks correct.

Jifl

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.