This is the mail archive of the
mailing list for the eCos project.
[Bug 1001606] Enable the cache on Kinetis in RAM startup mode
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: ecos-bugs at ecos dot sourceware dot org
- Date: Tue, 4 Sep 2012 22:19:21 +0100
- Subject: [Bug 1001606] Enable the cache on Kinetis in RAM startup mode
- Auto-submitted: auto-generated
- References: <email@example.com/>
Please do not reply to this email. Use the web interface provided at:
--- Comment #17 from Ilija Kocho <firstname.lastname@example.org> 2012-09-04 22:19:19 BST ---
It's been a long time... Finally I got some time to revisit this bug.
(In reply to comment #15)
I did some experiments regarding Unified/Separate caching issue. Here are the
results and my observations. Other discussions are snipped off but not
> 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 22.214.171.124 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
I don't recall in what context I wrote the above?! Pse disregard.
> 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.
I tried to utilize this mirror memory in hope that caching code and data in
different caches will boost the Harvard. In Attachment #1929 the region
"program" placed at 0x08000000 is supposed to contain /code/ sections while
/data/ sections reside in "ram" region. The system crashes/resets when it comes
to initialization of .bss section. I was able to single-step but when I try to
run with full speed it doesn't work. My suspect is the collision between two
cache units over RAM, it looks like Harvard is trying to simultaneous
instruction fetch and data access.
> 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.
Considering above, I think that we could conclude that for both RAM and FLASH
it is hard (or not possible) to effectively enforce caching of instructions and
data in separate caches. If you agree I would keep unified caches and look
after your other remarks.
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.