[U-Boot] DRAM test problem
Hi all,
I've made ports of u-boot for two powerpc processors, MPC8343 and MPC8541.
The boards has 128MB of DDR2. So I enabled CFG_DRAM_TEST in 127MB of those memories, and I got two scenarios:
MPC8343(ddr_clk = 264 MHz): test tooks 1min 35sec
MPC8541(ddr_clk = 333 MHz): test tooks 5 sec
Note: memories get ddr_clk / 2
Make sense? Is this cause MPC85xx family has L2 cache? Or cause ddr_clk? Or my port has problems in DDR configuration?
Im using Micron DDR2 memory, MT47H32M16HR-3:F, with CL = 3 for both ports.
Thanks in advance,
-- Alemao
On Mon, Jul 06, 2009 at 02:39:26PM -0300, Alemao wrote:
Hi all,
I've made ports of u-boot for two powerpc processors, MPC8343 and MPC8541.
The boards has 128MB of DDR2. So I enabled CFG_DRAM_TEST in 127MB of those memories, and I got two scenarios:
MPC8343(ddr_clk = 264 MHz): test tooks 1min 35sec
MPC8541(ddr_clk = 333 MHz): test tooks 5 sec
Note: memories get ddr_clk / 2
Make sense? Is this cause MPC85xx family has L2 cache? Or cause ddr_clk? Or my port has problems in DDR configuration?
Im using Micron DDR2 memory, MT47H32M16HR-3:F, with CL = 3 for both ports.
I believe data cache is disabled on 83xx in u-boot.
-Scott
On Mon, Jul 6, 2009 at 3:45 PM, Scott Woodscottwood@freescale.com wrote:
On Mon, Jul 06, 2009 at 02:39:26PM -0300, Alemao wrote:
Hi all,
I've made ports of u-boot for two powerpc processors, MPC8343 and MPC8541.
The boards has 128MB of DDR2. So I enabled CFG_DRAM_TEST in 127MB of those memories, and I got two scenarios:
MPC8343(ddr_clk = 264 MHz): test tooks 1min 35sec
MPC8541(ddr_clk = 333 MHz): test tooks 5 sec
Note: memories get ddr_clk / 2
Make sense? Is this cause MPC85xx family has L2 cache? Or cause ddr_clk? Or my port has problems in DDR configuration?
Im using Micron DDR2 memory, MT47H32M16HR-3:F, with CL = 3 for both ports.
I believe data cache is disabled on 83xx in u-boot.
-Scott
So the time for MPC8343 makes sense??? It tooks that long?
Data cache/instruction cache is inside e300c1 core, u-boot still have to enable/support it?
Any hint how could I do it in 83xx family?
Im loosing a lot of performance and all boards needs to pass this test before goes out...
Cheers,
-- Alemao
On Mon, Jul 6, 2009 at 7:07 PM, Alemaoxcarandiru@gmail.com wrote:
On Mon, Jul 6, 2009 at 3:45 PM, Scott Woodscottwood@freescale.com wrote:
On Mon, Jul 06, 2009 at 02:39:26PM -0300, Alemao wrote:
Hi all,
I've made ports of u-boot for two powerpc processors, MPC8343 and MPC8541.
The boards has 128MB of DDR2. So I enabled CFG_DRAM_TEST in 127MB of those memories, and I got two scenarios:
MPC8343(ddr_clk = 264 MHz): test tooks 1min 35sec
MPC8541(ddr_clk = 333 MHz): test tooks 5 sec
Note: memories get ddr_clk / 2
Make sense? Is this cause MPC85xx family has L2 cache? Or cause ddr_clk? Or my port has problems in DDR configuration?
Im using Micron DDR2 memory, MT47H32M16HR-3:F, with CL = 3 for both ports.
I believe data cache is disabled on 83xx in u-boot.
-Scott
So the time for MPC8343 makes sense??? It tooks that long?
Data cache/instruction cache is inside e300c1 core, u-boot still have to enable/support it?
Any hint how could I do it in 83xx family?
Im loosing a lot of performance and all boards needs to pass this test before goes out...
Cheers,
-- Alemao
I forgot to mention that Im running dram test already in ram.
So it's faster then run it from flash.
-- Alemao
On Tue, 7 Jul 2009 15:01:05 -0300 Alemao xcarandiru@gmail.com wrote:
On Mon, Jul 6, 2009 at 7:07 PM, Alemaoxcarandiru@gmail.com wrote:
On Mon, Jul 6, 2009 at 3:45 PM, Scott Woodscottwood@freescale.com wrote:
I believe data cache is disabled on 83xx in u-boot.
-Scott
So the time for MPC8343 makes sense??? It tooks that long?
Data cache/instruction cache is inside e300c1 core, u-boot still have to enable/support it?
Any hint how could I do it in 83xx family?
Im loosing a lot of performance and all boards needs to pass this test before goes out...
maybe what you're testing for itself needs to be better defined..but in the meanwhile, check out the CONFIG_*_HID0 assignments for your board...they get used in cpu/mpc83xx/start.S - see how they're configuring the caches. See also previous discussions on this list.
Kim
On Tue, Jul 7, 2009 at 7:41 PM, Kim Phillipskim.phillips@freescale.com wrote:
On Tue, 7 Jul 2009 15:01:05 -0300 Alemao xcarandiru@gmail.com wrote:
On Mon, Jul 6, 2009 at 7:07 PM, Alemaoxcarandiru@gmail.com wrote:
On Mon, Jul 6, 2009 at 3:45 PM, Scott Woodscottwood@freescale.com wrote:
I believe data cache is disabled on 83xx in u-boot.
-Scott
So the time for MPC8343 makes sense??? It tooks that long?
Data cache/instruction cache is inside e300c1 core, u-boot still have to enable/support it?
Any hint how could I do it in 83xx family?
Im loosing a lot of performance and all boards needs to pass this test before goes out...
maybe what you're testing for itself needs to be better defined..but in the meanwhile, check out the CONFIG_*_HID0 assignments for your board...they get used in cpu/mpc83xx/start.S - see how they're configuring the caches. See also previous discussions on this list.
Kim
In cpu/mpc83xx/start.S, dcache is enable for stack-in-cache trick:
/* enable and invalidate the data cache */ bl dcache_enable sync
dcache_enable: mfspr r3, HID0 li r5, HID0_DCFI|HID0_DLOCK andc r3, r3, r5 mtspr HID0, r3 /* no invalidate, unlock */ ori r3, r3, HID0_DCE ori r5, r3, HID0_DCFI mtspr HID0, r5 /* enable + invalidate */ mtspr HID0, r3 /* enable */ sync blr
I didn't find any code that is disabling it after that.
My only concern is whether the times really are consistent, 1min 35sec is much time compared with 5sec from MPC8541. Maybe my DDR configuration is wrong.
I'm doing the test in ram, so it should be faster then running from flash.
-- Alemao
On Wed, Jul 08, 2009 at 11:23:15AM -0300, Alemao wrote:
In cpu/mpc83xx/start.S, dcache is enable for stack-in-cache trick:
/* enable and invalidate the data cache */ bl dcache_enable sync
dcache_enable: mfspr r3, HID0 li r5, HID0_DCFI|HID0_DLOCK andc r3, r3, r5 mtspr HID0, r3 /* no invalidate, unlock */ ori r3, r3, HID0_DCE ori r5, r3, HID0_DCFI mtspr HID0, r5 /* enable + invalidate */ mtspr HID0, r3 /* enable */ sync blr
I didn't find any code that is disabling it after that.
Did you find anything that unlocks it once the stack-in-cache is no longer needed? If not, it will not be usable as a cache, just as a RAM.
-Scott
participants (3)
-
Alemao -
Kim Phillips -
Scott Wood