Coldfire 5235 I/D split cache

[Jate Sujjavanich]

I also posted most of this on uClinux-dev. I am using a 2.4.31-uc0
kernel.

I've been experimenting with enabling the split instruction and data
cache on the 5235. I get a good speedup - my boot time is reduced by 30%
to 27 seconds. However, I am occasionally getting problems with certain
programs starting up (perhaps a pthreads issue). Things have worked
perfectly when in i-cache only.

So does anyone have the split I/D cache working fine on 5235?

Also, the CPUSHL instruction documentation is vague. The CF Programmer's
Reference says one thing, and the MCF5235 ref says another. They seem to
suggest that the CPUSHL instruction address operand specifies the
address within the cache line instead of address of the memory being
cached. Anyone have more experience with this?


- Jate S.
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

[Greg Ungerer]

Hi Jate,

Jate Sujjavanich wrote:

> I also posted most of this on uClinux-dev. I am using a 2.4.31-uc0
> kernel.
>
> I've been experimenting with enabling the split instruction and data
> cache on the 5235. I get a good speedup - my boot time is reduced by 30%
> to 27 seconds. However, I am occasionally getting problems with certain
> programs starting up (perhaps a pthreads issue). Things have worked
> perfectly when in i-cache only.
>
> So does anyone have the split I/D cache working fine on 5235?

I looked at it a while back on the 5275. Though I didn't have
enough time to make it all work right.

The linux-2.4.x cache control code is a little "simplistic" for
the ColdFire's. You need to look at both:

  linux-2.4.x/include/asm-m68knommu/pgalloc.h
  linux-2.4.x/arch/m68knommu/mm/memory.c

The linux-2.6.x code is a little cleaner, though probably
doesn't work perfectly on split caches either. Concentrate on

  linux-2.6.x/include/asm-m68knommu/cachectl.h
  linux-2.6.x/include/asm-m68knommu/mcfcache.h

Regards
Greg

> Also, the CPUSHL instruction documentation is vague. The CF Programmer's
> Reference says one thing, and the MCF5235 ref says another. They seem to
> suggest that the CPUSHL instruction address operand specifies the
> address within the cache line instead of address of the memory being
> cached. Anyone have more experience with this?
>
>
> - Jate S.
> ---
> coldfire@...              Send a post to the list.
> coldfire-join@...        Join the list.
> coldfire-digest@...    Join the list in digest mode.
> coldfire-leave@...     Leave the list.
>
>

--
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@...
SnapGear, a McAfee Company                  PHONE:       [phone]
825 Stanley St,                             FAX:         [phone]
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.

[parnold]

Hi,

I've posted the following question on Freescales Coldfire forum but thought I'd post it here too in case some don't visit Freescale.

I need to regenerate some of the missing address lines on the MCF5208.
I see from the spec that during the first clock cycle the data bus is driven with the address so I assume this can somehow be used to obtain the missing address lines I want.
 
From the timing diagrams the data bus is driven with the address a max of 7ns after the rising edge of FB_CLK, this is the same time as /TS is driven.  This leaves 5ns before FB_CLK goes high again and /TS and the data bus are stopped being driven.
 
I obviously need to somehow use /TS but as it seems to be asserted and negated at the same time as the data bus I don't see how.
 
Can anyone on here help ?
 
Thanks
Paul

________________________________________________________________________
DISCLAIMER:

Information contained in this email or any attachment may be of a
confidential nature which should not be disclosed to, copied or used by
anyone other than the addressee. It may also be legally privileged.
If you receive this email in error, please delete the email from your computer and notify the sender immediately by return E-mail.

Security Warning: Please note that this email has been created in the knowledge that Internet email is not a 100% secure communications medium.  

Virus Warning:
This email has been scanned for all viruses by MessageLabs.
Although this email and any attachment are believed to be
free from viruses, it is the responsibility of the recipient to ensure that
they are virus free. No responsibility is accepted by Bell-Fruit Games Ltd
for any loss or damage arising in any way from their receipt, opening or
use.
---
coldfire@...              Send a post to the list.
coldfire-join@...        Join the list.
coldfire-digest@...    Join the list in digest mode.
coldfire-leave@...     Leave the list.