On Fri, Mar 27, 2009 at 04:36:28PM +0800, chmhou wrote:

there is something confused me, which is my kernel code is halt because of something wrong i have no hint about it.
my bootloader is u-boot, version is 1.1.4, kernel version is 2.6.14.1, processor is MPC8247.

That is very old code; you're more likely to get help when running
something up-to-date.

u-boot have run on the board already. bootloader booting information as follow:
U-Boot 1.1.4 (Mar 22 2009 - 20:30:57)
MPC8272 Reset Status: External Soft, External Hard
MPC8272 Clock Configuration
 - Bus-to-Core Mult 4x, VCO Div 2, 60x Bus Freq  25-75 , Core Freq 100-300
 - dfbrg 1, corecnf 0x1a, busdf 3, cpmdf 1, plldf 0, pllmf 3
 - vco_out  400000000, scc_clk  100000000, brg_clk   25000000
 - cpu_clk  400000000, cpm_clk  200000000, bus_clk  100000000

This alternative was listed as text/plain.  &nbsp is not plaintext. 
Please fix your mailer (and better yet, don't send HTML at all).

by LEDs i am sure that it surely performs in kernel. then by sequence
early_init, mmu_off, clear_bats and flush_tlbs. at call_setup_cpu, the
performing is halt, i get "bl call_setup_cpu" will invoke
setup_common_caches actually. right here, enable caches for 603e by
HID0, get HID0 register and setting DCE and ICE bit put into HID0
register, the performing halt.

I doubt that it is actually halting here; more likely, you're just
hitting a spot in the boot sequence where it's not safe to access your
LEDs or other I/O, because you have the MMU off and the cache enabled.

You'll typically be much better off leaving the very early code alone
(it's almost never the culprit), except to ensure that you have a BAT
mapping (cache-inhibited and guarded) for the I/O you want to use for
debugging.  Then, only touch that I/O device *after* the MMU is on and
your mapping is in place.

-Scott