linux-2.4.18 & copy-back cache mode
Hi everybody
I tried to boot a FADS860T board with the 2.4.18 linux kernel, and experienced problems with cache set in Copy-Back mode.
The kernel configuration help states that you can say 'Y' to Copy-Back mode if 'you don't know what that is about', so that's what I did.
I then got a 'kernel access of bad area' just after the 'CPM UART driver version 0.03' message.
I traced the problem to rs_8xx_init, and found out that a write to .data was causing the crash.
After some more investigation I found that disabling Copy-Back mode (thus enabling Write-Through mode) fixed the problem.
The problem seems to have been solved in the linuxppc repository, so the purpose if this message is not to ask for help but rather to give help to people who will experience the same problem (no doubt there will be some, as the Copy-Back mode is advised by the kernel configurator).
Laurent Pinchart
PS: I posted a few patches based on the latest linuxppc tree (to fix some compilation warnings and a problem with xmon) about one week ago. I got no feedback. Have they got through to the list ?
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Quoted 2 lines · Laurent Pinchart
After some more investigation I found that disabling Copy-Back mode (thus enabling Write-Through mode) fixed the problem.
What version of silicon? Sounds like the "CPU6 errata" that affects anything less than a Rev. C part.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Quoted 8 lines
Quoted 5 lines
After some more investigation I found that disabling Copy-Back mode (thus enabling Write-Through mode) fixed the problem.
What version of silicon? Sounds like the "CPU6 errata" that affects anything less than a Rev. C part.
It's a Rev. D.3
Laurent Pinchart
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Quoted 1 line · Laurent Pinchart
It's a Rev. D.3
Hmmmm....I regularly use one of those for testing (maybe it's an 855T), and it seems OK for me. The first one I had didn't work well, but it was tracked down to a UPM/SDRAM timing problem. People keep talking about running > 50 MHz bus on these newer parts, is there something different about the memory controller that allows this and may cause compatibility problems? I have (fortunately :-) not looked at this level of detail in the newer parts.
When you disable copyback you also disable burst mode write from the CPU core.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Quoted 6 lines · In message <[email protected]> you wrote:
it was tracked down to a UPM/SDRAM timing problem. People keep talking about running > 50 MHz bus on these newer parts, is there something different about the memory controller that allows this and may cause compatibility problems? I have (fortunately :-) not looked at this level of detail in the newer parts.
There are no differences AFAIK. It's just a faster CPU that allows 66 or even 76 MHz with 1:1 CPU/bus clock mode.
We have a MPC823E system here that runs at 66 MHz, and I will have a MPC855T at 66MHz in 18 hours from now. So far I didn't encounter any problems - of course you have to adjust the UPM tables and what else you need to initialize the memory controller.
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: [email protected] The Wright Bothers weren't the first to fly. They were just the first not to crash.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Quoted 2 lines · Wolfgang Denk
There are no differences AFAIK. It's just a faster CPU that allows 66 or even 76 MHz with 1:1 CPU/bus clock mode.
Interesting. Faster than 50 MHz cores used to require the 2:1 bus clock division. I don't remember timing parameters that would exceed 50 MHz. Yes, the part will let you do that, but I thought that was outside of the part specification. I guess I'll have to take a look.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
serial console on 405GP
Dear, everyone!
I'm poring linux-2.4.18-pre7 (from penquinppc.org) on my customized board (with IBM 405GP)
My board has no keyboard, so I'm using serial console on UART0. I ported ppcboot, and it works well.
When I ported linux on my board, there happened some problem.
After init forks sash (standalone shell as you know),
I can see the prompt of the sash but the character sent wasn't delivered to sash. So what character I send to the sash. It never respond.
I watch for the serial source (driver/char/serial.c) and enabled DEBUG option and the character sent was received by kernel.
I don't know why the characters are disappeared.
Anyone know the reason?
Please, help me.
==============================================
Just for fun...
- Linus Torvalds
==============================================
Kwansuk Kim
Engineer, NeoWave Inc.
Tel +82-31-380-4927 Fax +82-31-380-4747
E-mail: [email protected]
==============================================
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Re: serial console on 405GP
Hi, Kim,Kwansuk!
It seams you have the same problem that I had just two weeks ago.
It is likely you have the serial port located below 0xc0000000.
If it is so, I suggest you to move the serial port above 0xc0000000.
If you want to know the reason, just find the mails, in this mailing list, titled "Re: execve system call question"
- Sangmoon Kim -
----- Original Message -----
From: "Kim, Kwansuk" <[email protected]>
To: <[email protected]>
Sent: Thursday, March 07, 2002 11:42 AM
Subject: serial console on 405GP
Quoted 23 lines
Dear, everyone!
I'm poring linux-2.4.18-pre7 (from penquinppc.org) on my customized board (with IBM 405GP)
My board has no keyboard, so I'm using serial console on UART0. I ported ppcboot, and it works well.
When I ported linux on my board, there happened some problem.
After init forks sash (standalone shell as you know),
I can see the prompt of the sash but the character sent wasn't delivered to sash. So what character I send to the sash. It never respond.I watch for the serial source (
driver/char/serial.c) and enabled DEBUG option and the character sent was received by kernel.I don't know why the characters are disappeared.
Anyone know the reason?
Please, help me.
Quoted 12 lines
==============================================
Just for fun...
- Linus Torvalds
==============================================
Kwansuk Kim
Engineer, NeoWave Inc.
Tel +82-31-380-4927 Fax +82-31-380-4747
E-mail: [email protected]
==============================================
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/