[U-Boot-Users] icache/dcache not working on PPC440
Hi
Our HW engineers discovered that the U-Boot commands icache/dcache do not work on PPC440x boards (at least yosemite and sequoia).
In my opinion icache/dcache work only on PPC40x processors where one can alter the ICCR/DCCR registert. For the PPC440x register one should tinker with the corresponding SA_I bit in the TLB.
Has somebody already solved this problem and would be willing to share his patch?
If not I am willing to work on patch along the following lines:
a) add some C-callable routines to cpu/ppc4xx/start.S to use the TLB Search Instruction and b) to modify/setup a TLB from C c) add in cpu/ppc4xx/cpu.c d/icache_dis/enable procedure Any objections/comments?
Best regards
Niklaus Giger
Hi Niklaus,
On Friday 02 March 2007 16:51, Niklaus Giger wrote:
Our HW engineers discovered that the U-Boot commands icache/dcache do not work on PPC440x boards (at least yosemite and sequoia).
Correct. On all 44x U-Boot platform cache in SDRAM is disabled right now. The main reason for this is the the 4xx EMAC driver needs it's buffer descriptors in uncached memory, or it must be changed to work with cached buffers too (invalidate & flush...).
In my opinion icache/dcache work only on PPC40x processors where one can alter the ICCR/DCCR registert. For the PPC440x register one should tinker with the corresponding SA_I bit in the TLB.
Right.
Has somebody already solved this problem and would be willing to share his patch?
From my point of view it doesn't make sense to support the icache/dcache commands for the 44x platforms. No real gain here. What makes real sense is to enable cache support in SDRAM. I have started working on an 440 port with caches enabled in SDRAM but other, more important stuff came in-between.
As mentioned above the main problem is the EMAC driver. It has either to be changed to support cache handling (invalidating/flushing) of the buffer descriptors. Or we must setup one small area in the SDRAM that is uncached and the driver uses this memory area for the buffer descriptors.
If not I am willing to work on patch along the following lines:
a) add some C-callable routines to cpu/ppc4xx/start.S to use the TLB Search Instruction and b) to modify/setup a TLB from C c) add in cpu/ppc4xx/cpu.c d/icache_dis/enable procedure Any objections/comments?
As mentioned above, I see no real gain here. If you really want to start on this issue, then please rework the EMAC driver as mentioned above and we can enable the caches in SDRAM. This would really bring a performance boost to the 44x platforms (image uncompressing, ECC generation, FPGA programming...).
But I have to admit the EMAC driver is total mess of #ifdef's (again)! :-(
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany =====================================================================
In message 200703021749.03000.sr@denx.de you wrote:
As mentioned above the main problem is the EMAC driver. It has either to be changed to support cache handling (invalidating/flushing) of the buffer descriptors. Or we must setup one small area in the SDRAM that is uncached and the driver uses this memory area for the buffer descriptors.
Other drivers may make similar assumptions. You will have to run a pretty extensive set of regression testing (including other network drivers, USB, ...) when attempting to perform such a change.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Friday 02 March 2007 17:54, Wolfgang Denk wrote:
In message 200703021749.03000.sr@denx.de you wrote:
As mentioned above the main problem is the EMAC driver. It has either to be changed to support cache handling (invalidating/flushing) of the buffer descriptors. Or we must setup one small area in the SDRAM that is uncached and the driver uses this memory area for the buffer descriptors.
Other drivers may make similar assumptions.
For 44x, I don't think so.
You will have to run a pretty extensive set of regression testing (including other network drivers, USB, ...) when attempting to perform such a change.
Sure. This would be a major change and would need to be enabled in the board config file. And extensive testing of course.
Viele Grüße, Stefan
===================================================================== DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany =====================================================================
I have an 8541 board with a number of I2C chips and am having trouble understanding the use of inm & inw. I can iprobe, but when I try to write the first byte to zero, I get an error. The chip at address 70 is a Philips PCA9538 with four registers and I am trying to write the first register at offset zero to the value zero.
Can someone help me understand the error of my ways.
Charles
sff=> iprobe Valid chip addresses: 2A 2D 37 57 58 59 68 70 sff=> help imd imd chip address[.0, .1, .2] [# of objects] - i2c memory display sff=> imd 70 0.1 4 0000: 7f 7f 7f 7f .... sff=> inm.b 70 0 00000000: 7f ? 0 Error writing the chip. 00000000: 7f ? . sff=>
In message es9h6q$2gp$1@sea.gmane.org you wrote:
Our HW engineers discovered that the U-Boot commands icache/dcache do not work on PPC440x boards (at least yosemite and sequoia).
Please make sure to read the REAME and understand why you cannot arbitrarily enable or disable caches in the system.
Has somebody already solved this problem and would be willing to share his patch?
It's not a problem, it's a design issue.
Best regards,
Wolfgang Denk
participants (4)
-
Charles Krinke -
Niklaus Giger -
Stefan Roese -
Wolfgang Denk