Justin,
I seen in a previous e-mail that you are using a 4xx proccessor. I'm assuming
that this processor only has 16 bytes cache lines. When you went through the
code I sent you, did you change it to only zero out 16 bytes instead of 32?
Also, Make sure in your CPU book that dcbz is the only instruction that
can't be done when data cache is disabled.
You also may want to check arch/ppc/kernel/align.c to make sure it still
simply "returns" from an alignment excepetion caused by a dcbz. My
tree (base line 2.4.4) has it. Otherwise, you may want to grep your
code (in the arch/ppc/*, and in include/asm/*) for any other occurences
of dcbz. Any at bootup time must be replaced with assembly instructions
to zero out the memory locations, but ones that will happen during runtime
should be OK if your alignment handler ignores them.
Again, be sure to check your CPU manual. Maybe the 4xx CPU handles
the data cache instructions differently from the 7410.
Also.. Make absolutely sure you made the right changes in the
arch/ppc/mm/init.c file as well.
SInce its crapping out uncompressing the ramdisk, I am assuming
that the copy_pages or copy_tofrom_user stuff isn't working right
(Maybe you still have it zero'ing out 32 bytes instead of 16?)
Paul W.
At 05:16 AM 6/29/2001 -0400, Justin (Gus) Hurwitz wrote:
On Thu, 28 Jun 2001, Paul White wrote:
quoted
Justin,
I was able to get Data cache disabled today, after playing around with it
for a while.
There were several things I had to do. Now, I don't recall what CPU you
are using, so I'll just tell you what I found with mine.
First off, I'm using the 7410, which has 32 byte cache lines. Note that
the
quoted
8xx and such have 16 byte cache lines. In my manual, under "Enabling
and Disabling Data Cache", it states that the dcbz instruction will
cause an
quoted
alignment exception, and that all others are nop'd. So the first thing
I did,
quoted
was search for dcbz throughout my code, and I found two files that had
several matches:
I went through and made the same set of changes that you did- I am on a
603e, so I would expect the L1 cache behaviour to be about the same.
Indeed, the kernel does boot properly, up until id decompresses the
ramdisk. I am getting a crc error decompressing the ramdisk, however-
presumably because of a problem with the caches. I'd like to set the MMU
to caching inhibited to tighten up the processor's load and store
ordering. I think that I only need to set this in the pte entries- the
errors are only occuring after the MMU has been brought up. Irony of
ironies, I know how to do this with the BATs, but not in the PTEs. It
looks like there is a field in the PTE struct (in asm/mmu.h), but I can't
find where that structure is initialised. It looks like, from my
meandering through the kernel's memory management code that this might wee
be a good step towards allowing chunks of non cachable memory to be
allocated.
Thoughts?
--Gus
-------------------------------------------------------------
Network Robots, Inc. /--\ Paul H. White
/ ____ \
4695 Chabot Dr. #200 / ( oo ) \ Software Developer
Pleasanton, CA 94588 / ---- \ Engineering
(925) 924-8600 \ ---- / (925) 580-4883
\ V--V /
\ /
\--/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
All true- except that I'm on a 603e :) It was someone else that was on the
4xx. I'm fairly sure that the 603e has 32 byte lines.
I think that I've hunted down all of the dcbz instructions, but I should
go and check align.c. I've not had a chance to look through the book to
see if there are other non-usable functions- I want to say that everything
else is a nop on the 603e, but I'll double check when I get the chance.
Fingers crossed,
--Gus
On Fri, 29 Jun 2001, Paul White wrote:
Justin,
I seen in a previous e-mail that you are using a 4xx proccessor. I'm assuming
that this processor only has 16 bytes cache lines. When you went through the
code I sent you, did you change it to only zero out 16 bytes instead of 32?
Also, Make sure in your CPU book that dcbz is the only instruction that
can't be done when data cache is disabled.
You also may want to check arch/ppc/kernel/align.c to make sure it still
simply "returns" from an alignment excepetion caused by a dcbz. My
tree (base line 2.4.4) has it. Otherwise, you may want to grep your
code (in the arch/ppc/*, and in include/asm/*) for any other occurences
of dcbz. Any at bootup time must be replaced with assembly instructions
to zero out the memory locations, but ones that will happen during runtime
should be OK if your alignment handler ignores them.
Again, be sure to check your CPU manual. Maybe the 4xx CPU handles
the data cache instructions differently from the 7410.
Also.. Make absolutely sure you made the right changes in the
arch/ppc/mm/init.c file as well.
SInce its crapping out uncompressing the ramdisk, I am assuming
that the copy_pages or copy_tofrom_user stuff isn't working right
(Maybe you still have it zero'ing out 32 bytes instead of 16?)
Paul W.
At 05:16 AM 6/29/2001 -0400, Justin (Gus) Hurwitz wrote:
quoted
On Thu, 28 Jun 2001, Paul White wrote:
quoted
Justin,
I was able to get Data cache disabled today, after playing around with it
for a while.
There were several things I had to do. Now, I don't recall what CPU you
are using, so I'll just tell you what I found with mine.
First off, I'm using the 7410, which has 32 byte cache lines. Note that
the
quoted
quoted
8xx and such have 16 byte cache lines. In my manual, under "Enabling
and Disabling Data Cache", it states that the dcbz instruction will
cause an
quoted
quoted
alignment exception, and that all others are nop'd. So the first thing
I did,
quoted
quoted
was search for dcbz throughout my code, and I found two files that had
several matches:
I went through and made the same set of changes that you did- I am on a
603e, so I would expect the L1 cache behaviour to be about the same.
Indeed, the kernel does boot properly, up until id decompresses the
ramdisk. I am getting a crc error decompressing the ramdisk, however-
presumably because of a problem with the caches. I'd like to set the MMU
to caching inhibited to tighten up the processor's load and store
ordering. I think that I only need to set this in the pte entries- the
errors are only occuring after the MMU has been brought up. Irony of
ironies, I know how to do this with the BATs, but not in the PTEs. It
looks like there is a field in the PTE struct (in asm/mmu.h), but I can't
find where that structure is initialised. It looks like, from my
meandering through the kernel's memory management code that this might wee
be a good step towards allowing chunks of non cachable memory to be
allocated.
Thoughts?
--Gus
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
"Justin (Gus) Hurwitz" wrote:
I think that I've hunted down all of the dcbz instructions, but I should
go and check align.c.
There is no reason to do this. The behavior of these instruction on the
603e aren't any different than other processors. If you know you are
operating on I/O space, use the memset_io/memcpy_fromio()/memcpy_toio()
and not the usual memory copy/set functions.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/