issue at the beginning of kernel booting

issue at the beginning of kernel booting

[chmhou]

[-- Attachment #1: Type: text/plain, Size: 3249 bytes --]

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.
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
Board: Motorola MPC8272ADS
DRAM:  32 MB
FLASH: 512 kB
In:    serial
Out:   serial
Err:   serial
Net:   FCC1 ETHERNET
Hit any key to stop autoboot:  0 
then i "tftp uImage" and "bootm" with no parameters, i suppose that booting kernel will be normal at beginning even if there is no any parameters. 
=> tftp
Using FCC1 ETHERNET device
TFTP from server 192.168.0.99; our IP address is 192.168.0.100
Filename 'uImage'.
Load address: 0x400000
Loading: #################################################################
  #################################################################
  ########################################################
done
Bytes transferred = 952157 (e875d hex)
=> bootm
## Booting image at 00400000 ...
   Image Name:   Linux-2.6.14
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    952093 Bytes = 929.8 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
OK
 
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. 
_GLOBAL(__setup_cpu_603)
 b setup_common_caches
setup_common_caches:
 mfspr r11,SPRN_HID0
 andi. r0,r11,HID0_DCE
 ori r11,r11,HID0_ICE|HID0_DCE
 ori r8,r11,HID0_ICFI
 bne 1f   /* don't invalidate the D-cache */
/* halt here */ 
 ori r8,r8,HID0_DCI  /* unless it wasn't enabled */
1: sync
 mtspr SPRN_HID0,r8  /* enable and invalidate caches */
 sync
 mtspr SPRN_HID0,r11  /* enable caches */
 sync
 isync
 blr
then after i clear HI0_DCI , performing will run till MSR[DR] is set, i clear that bit. will run again. 
i have nerver changed the code because i think there is something be independent of my board device. isnt?
why the performing halt there ? or do you think there is something wrong in the front?
Cheers~ 
Sauce

-------------------------------------------------------------------
新浪空间——与朋友开心分享网络新生活！(http://space.sina.com.cn/ )

[-- Attachment #2: Type: text/html, Size: 3908 bytes --]

Re: issue at the beginning of kernel booting

[Scott Wood]

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

Re: issue at the beginning of kernel booting

[Sauce.Cheng]

thanks Scott!

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

i have a latest u-boot-2009.03 updated instead of mine, and kernel version
is instead of 2.6.24.5

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

yeah, it is my fault. i am a newer of mail lists , i will be careful next
time.

> 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.

according to your point, i have moved the codes used for debuging to the
place where after mmu being on, then there is nothing happened. it indicated
that proforming had halt before this.

i dont think there may be likely had some wrong in kernel source. but
actually it halt there in early code.

first i guess the reason that before i boot kernel without fdt. it still
halt after wiht fdt.

now i show my early code with debug code, please check it what fault is more
likely. 


early code 


	/* initialize LEDs, used by Port B */
	lis	r8, (0x000000FF)@h
	ori	r8, r8, (0x000000FF)@l
	lis	r9, (M8247_IOP_PDIRB(0xF0000000))@h		//define 0x10D20 as
M8247_IOP_PDIRB(Port B dir)
	lis	r9, r9, (M8247_IOP_PDIRB(0xF0000000))@l		//define 0x10D30 as
M8247_IOP_PDATB(Port B dat)
	stw	r8, 0(r9)

	/* turn D1 , successful */
	lis	r8, (0xFFFFFFFE)@h
	ori	r8, r8, (0xFFFFFFFE)@l
	lis	r9, (M8247_IOP_PDATB(0xF0000000))@h		
	lis	r9, r9, (M8247_IOP_PDATB(0xF0000000))@l		
	stw	r8, 0(r9)

	bl	early_init
/* here : mmu off: */
 	addi	r4, r3, __after_mmu_off - _start
	mfmsr	r3
	andi.	r0,r3,MSR_DR|MSR_IR		/* MMU enabled? */
	beqlr
	andc	r3,r3,r0
	mtspr	SPRN_SRR0,r4
	mtspr	SPRN_SRR1,r3
	sync
	RFI
__after_mmu_off:
/* here : clear_bats: */ 
	li	r10,0
	mfspr	r9,SPRN_PVR
	rlwinm	r9,r9,16,16,31		/* r9 = 1 for 601, 4 for 604 */
	cmpwi	r9, 1	
	beq	1f			// my core is 603e, so both DBATx and IBATx should be initialized.

	mtspr	SPRN_DBAT0U,r10
		.
		.
		.
	mtspr	SPRN_DBAT3L,r10
1:
	mtspr	SPRN_IBAT0U,r10
		.
		.
		.
	mtspr	SPRN_IBAT3L,r10
BEGIN_FTR_SECTION			// CPU_FTR_HAS_HIGH_BATS is default feature for G2_LE
core
	mtspr	SPRN_DBAT4U,r10
		.
		.
		.
	mtspr	SPRN_IBAT7L,r10
END_FTR_SECTION_IFSET(CPU_FTR_HAS_HIGH_BATS)	
	blr

/* here: flush_tlbs: */
	lis	r10, 0x40
1:	addic.	r10, r10, -0x1000
	tlbie	r10
	blt	1b
	sync
	blr
/* here : initial_bats: */ 
	lis	r11,KERNELBASE@h
	mfspr	r9,SPRN_PVR
	rlwinm	r9,r9,16,16,31		/* r9 = 1 for 601, 4 for 604 */
	cmpwi	0,r9,1
	bne	4f
4:	tophys(r8,r11)
	ori	r8,r8,2			/* R/W access */
	ori	r11,r11,BL_16M<<2|0x2	/* set up BAT registers for 604 */
	mtspr	SPRN_DBAT0L,r8		/* N.B. 6xx (not 601) have valid */
	mtspr	SPRN_DBAT0U,r11		/* bit in upper BAT register */
	mtspr	SPRN_IBAT0L,r8
	mtspr	SPRN_IBAT0U,r11
	isync
	blr
	bl	reloc_offset
	li	r24,0			/* cpu# */
	bl	call_setup_cpu		/* Call setup_cpu for this CPU */
here jump to call_setup_cpu, actually invoked setup_common_caches.
setup_common_caches:
	/* turn D1 and D2 , successful */
	lis	r15, (0xFFFFFFFC)@h
	ori	r15, r15, (0xFFFFFFFC)@l
	lis	r16, (M8247_IOP_PDATB(0xF0000000))@h		
	lis	r16, r16, (M8247_IOP_PDATB(0xF0000000))@l		
	stw	r15, 0(r16)


	mfspr	r11,SPRN_HID0
	andi.	r0,r11,HID0_DCE
	ori	r11,r11,HID0_ICE|HID0_DCE
	ori	r8,r11,HID0_ICFI
	bne	1f			/* don't invalidate the D-cache */
	ori	r8,r8,HID0_DCI		/* unless it wasn't enabled */
1:	sync
	mtspr	SPRN_HID0,r8		/* enable and invalidate caches */

	/* turn D1,D2 and D3 , fault */
	lis	r15, (0xFFFFFFF8)@h
	ori	r15, r15, (0xFFFFFFF8)@l
	lis	r16, (M8247_IOP_PDATB(0xF0000000))@h		
	lis	r16, r16, (M8247_IOP_PDATB(0xF0000000))@l		
	stw	r15, 0(r16)
	sync
	mtspr	SPRN_HID0,r11		/* enable caches */
	sync
	isync
	blr
here, if i removed the HID0_DCE, will be normal. in this situation , at
turn_on_mmu:, after enter start_here, will halt there.

Sauce
-- 
View this message in context: http://www.nabble.com/issue-at-the-beginning-of-kernel-booting-tp22741532p22828498.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.

Re: issue at the beginning of kernel booting

[Sauce.Cheng]

thanks Scott
> Another thing that would generally be good is to keep replies on the 
> list rather than taking it to private e-mail as soon as someone replies.

> Someone else may have something helpful to say based on your followup, 
> or may have the same problem and be helped by the conclusion.

ok~ excuse for my mistake, thank you for your words. i will do it like you
say from now on. it surely be better.

> I don't see where you set up a BAT that covers 0xf0000000.

if i have to set up a BAT that cover 0xF0000000. i had a debug with LEDs
like that in u-boot code. everything is //normal. 0xF00000000 is the value
of CFG_IMMR(CONFIG_SYS_IMMR) that memory map register, it is the phy address
and //base //address of all internal regishters, isnt? you mean that if i
set BATs, i should not get the phy address like in the //front ?

> Do you have a correct fdt, that matches a platform that is enabled in 
> your .config?

i think so, i used mpc8272ads_defconfig becasue my processor is mpc8272, i
got a mail before about modifying and //config fdt file mpc8272ads.dts. i
fixed up my file like that.

i tried 
CONFIG_PPC_EARLY_DEBUG_CPM=y 
CONFIG_PPC_EARLY_DEBUG_CPM_ADDR=0xf00000008	
how can i make sure CPM_ADDR, 0xf0000008 is default value 

now it show as follow. i select smc1 as console. please check it and give me
some advice.

/ {
	model = "MPC8272ADS";
	compatible = "fsl,mpc8272ads";
	#address-cells = <1>;
	#size-cells = <1>;

	cpus {
		#address-cells = <1>;
		#size-cells = <0>;

		PowerPC,8272@0 {
			device_type = "cpu";
			reg = <0>;
			d-cache-line-size = <d#32>;
			i-cache-line-size = <d#32>;
			d-cache-size = <d#16384>;
			i-cache-size = <d#16384>;
			timebase-frequency = <0>;
			bus-frequency = <0>;
			clock-frequency = <0>;
		};
	};

	memory {
		device_type = "memory";
		reg = <0 0>;
	};

	localbus@f0010100 {
		compatible = "fsl,mpc8272-localbus",
		             "fsl,pq2-localbus";
		#address-cells = <2>;
		#size-cells = <1>;
		reg = <f0010100 40>;
/* chengmo : modify by my own device */
		ranges = <0 0 FFF00000 00080000	//CS0: Flahs 512k
		          2 0 00000000 02000000	//CS2: SDRAM 32M
						>;

		flash@0,0 {
			compatible = "cfi-flash";
			reg = <0 0 00080000>;
			bank-width = <4>;
			device-width = <1>;	// 16 bits
		};

		PCI_PIC: interrupt-controller@3,0 {
			compatible = "fsl,mpc8272ads-pci-pic",
			             "fsl,pq2ads-pci-pic";
			#interrupt-cells = <1>;
			interrupt-controller;
			reg = <3 0 8>;
			interrupt-parent = <&PIC>;
			interrupts = <14 8>;
		};
	};

	soc@f0000000 {
		#address-cells = <1>;
		#size-cells = <1>;
		device_type = "soc";
		compatible = "fsl,mpc8272", "fsl,pq2-soc";
		ranges = <00000000 f0000000 00053000>;

		// Temporary -- will go away once kernel uses ranges for get_immrbase().
		reg = <f0000000 00053000>;

		cpm@119c0 {
			#address-cells = <1>;
			#size-cells = <1>;
			compatible = "fsl,mpc8272-cpm", "fsl,cpm2";
			reg = <119c0 30>;
			ranges;

			muram@0 {
				#address-cells = <1>;
				#size-cells = <1>;
				ranges = <0 0 10000>;

				data@0 {
					compatible = "fsl,cpm-muram-data";
					reg = <0 2000 9800 800>;
				};
			};

			brg@119f0 {
				compatible = "fsl,mpc8272-brg",
				             "fsl,cpm2-brg",
				             "fsl,cpm-brg";
				reg = <119f0 10 115f0 10>;
			};

			serial@11a82 {
				device_type = "serial";
				compatible = "fsl,mpc8272-smc-uart",
				             "fsl,cpm2-smc-uart";
				reg = <11a82 20 87FC 100>;
				interrupts = <28 8>;
				interrupt-parent = <&PIC>;
				fsl,cpm-brg = <1>;
				fsl,cpm-command = <00800000>;
			};

			mdio@10d40 {
				device_type = "mdio";
				compatible = "fsl,mpc8272ads-mdio-bitbang",
				             "fsl,mpc8272-mdio-bitbang",
				             "fsl,cpm2-mdio-bitbang";
				reg = <10d40 14>;
				#address-cells = <1>;
				#size-cells = <0>;
				fsl,mdio-pin = <12>;
				fsl,mdc-pin = <13>;

				PHY0: ethernet-phy@0 {
					interrupt-parent = <&PIC>;
					interrupts = <17 8>;
					reg = <0>;
					device_type = "ethernet-phy";
				};

				PHY1: ethernet-phy@1 {
					interrupt-parent = <&PIC>;
					interrupts = <17 8>;
					reg = <3>;
					device_type = "ethernet-phy";
				};
			};

			ethernet@11300 {
				device_type = "network";
				compatible = "fsl,mpc8272-fcc-enet",
				             "fsl,cpm2-fcc-enet";
				reg = <11300 20 8400 100 11390 1>;
				local-mac-address = [ 00 00 00 00 00 00 ];
				interrupts = <20 8>;
				interrupt-parent = <&PIC>;
				phy-handle = <&PHY0>;
				linux,network-index = <0>;
				fsl,cpm-command = <12000300>;
			};
		};

		PIC: interrupt-controller@10c00 {
			#interrupt-cells = <2>;
			interrupt-controller;
			reg = <10c00 80>;
			compatible = "fsl,mpc8272-pic", "fsl,cpm2-pic";
		};
	};

	chosen {
		linux,stdout-path = "/soc/cpm/serial@11a82";
	};
};

-- 
View this message in context: http://www.nabble.com/issue-at-the-beginning-of-kernel-booting-tp22741532p22840131.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.

Re: issue at the beginning of kernel booting

[Scott Wood]

On Wed, Apr 01, 2009 at 08:23:42PM -0700, Sauce.Cheng wrote:
> > I don't see where you set up a BAT that covers 0xf0000000.
> 
> if i have to set up a BAT that cover 0xF0000000. i had a debug with LEDs
> like that in u-boot code. everything is //normal. 0xF00000000 is the value
> of CFG_IMMR(CONFIG_SYS_IMMR) that memory map register, it is the phy address
> and //base //address of all internal regishters, isnt? you mean that if i
> set BATs, i should not get the phy address like in the //front ?

I don't quite follow the above, but what I meant is that you need to
put a mapping in place that covers your LED I/O once you have the MMU on.

Any mappings that U-boot made will be gone at that point.

> i tried 
> CONFIG_PPC_EARLY_DEBUG_CPM=y 
> CONFIG_PPC_EARLY_DEBUG_CPM_ADDR=0xf00000008	
> how can i make sure CPM_ADDR, 0xf0000008 is default value 

Look at the u-boot source, or dump the memory and see if it looks like a
ring buffer.

> 		PowerPC,8272@0 {
> 			device_type = "cpu";
> 			reg = <0>;
> 			d-cache-line-size = <d#32>;
> 			i-cache-line-size = <d#32>;
> 			d-cache-size = <d#16384>;
> 			i-cache-size = <d#16384>;

This is a dts-v0 tree, which implies it's fairly old.

> 			brg@119f0 {
> 				compatible = "fsl,mpc8272-brg",
> 				             "fsl,cpm2-brg",
> 				             "fsl,cpm-brg";
> 				reg = <119f0 10 115f0 10>;
> 			};

Make sure that the clock-frequency property of the brg node is being set
by u-boot.  I should probably send a patch for that while the merge
window's still open...

> 			serial@11a82 {
> 				device_type = "serial";
> 				compatible = "fsl,mpc8272-smc-uart",
> 				             "fsl,cpm2-smc-uart";
> 				reg = <11a82 20 87FC 100>;

regs = <11a80 20 87fc 2>;

> 				interrupts = <28 8>;

interrupts = <4 8>;

> 				interrupt-parent = <&PIC>;
> 				fsl,cpm-brg = <1>;
> 				fsl,cpm-command = <00800000>;

You need to update fsl,cpm-command; that is the SCC1 command word.
The SMC1 command is 0x1d000000 (see the ep8248e device tree).

Also make sure that the brg is correct.

-Scott

Re: issue at the beginning of kernel booting

[Benjamin Herrenschmidt]

On Thu, 2009-04-02 at 11:12 -0500, Scott Wood wrote:
> On Wed, Apr 01, 2009 at 08:23:42PM -0700, Sauce.Cheng wrote:
> > > I don't see where you set up a BAT that covers 0xf0000000.
> > 
> > if i have to set up a BAT that cover 0xF0000000. i had a debug with LEDs
> > like that in u-boot code. everything is //normal. 0xF00000000 is the value
> > of CFG_IMMR(CONFIG_SYS_IMMR) that memory map register, it is the phy address
> > and //base //address of all internal regishters, isnt? you mean that if i
> > set BATs, i should not get the phy address like in the //front ?
> 
> I don't quite follow the above, but what I meant is that you need to
> put a mapping in place that covers your LED I/O once you have the MMU on.
> 
> Any mappings that U-boot made will be gone at that point.

Also, f0000000 isn't a very good idea for a hard wired mapping, it will
overlap some kernel stuffs. You should dynamically allocate the virtual
address, or pick something above 0xfff00000 which should be unused iirc.

Ben.

Re: issue at the beginning of kernel booting

[Sauce.Cheng]

thanks Scott 's following

> I don't quite follow the above, but what I meant is that you need to
> put a mapping in place that covers your LED I/O once you have the MMU on.
> Any mappings that U-boot made will be gone at that point.

i am sorry for my poor expression. i think i have got your meaning about
that.
the suggestion from others that the situation that external access will be
disabled at early booting time. i guess that means like yours, sometimes I/O
disabled due to cache operating or something.

certainly, if i have to turn LEDs at booting time, the way your said is the
best. but i supposed i could operate LEDs after early booting time. 

>> i tried 
>> CONFIG_PPC_EARLY_DEBUG_CPM=y 
>> CONFIG_PPC_EARLY_DEBUG_CPM_ADDR=0xf00000008	
>> how can i make sure CPM_ADDR, 0xf0000008 is default value 

> Look at the u-boot source, or dump the memory and see if it looks like a
> ring buffer.

sorry, i mean that CPM_ADDR is address of what? address of CPM registers or
something?

> This is a dts-v0 tree, which implies it's fairly old.
dose later dts be used in corresponding kernel version ?

i guess i must read "booting-without-of.txt". many of contents in dts i have
no idea.

in addition, there is one more question. 
my RAM size is 32MBytes, my "vmlinux" size is 30MBytes, "vmlinux.o" size is
58MBytes. so , will there be something wrong at uncompressing time ?

Sauce
-- 
View this message in context: http://www.nabble.com/issue-at-the-beginning-of-kernel-booting-tp22741532p22930588.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.

Re: issue at the beginning of kernel booting

[Sauce.Cheng]

evolution! kernel 2.6.11 has run on the board with u-boot 1.1.4, also, at
early booting time LEDs are disabled due to MMU on and off. so i tried to
turn LEDs on after start_kernel function, wow, blinking! that is before
start_kernel will be done successfully. then i modified registers mapping in
immap_cpm2.h and configure smc1 as serial. console worked normally.
booting info as following
U-Boot 1.1.4 (Apr  2 2009 - 20:05:19)

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

Board: Motorola MPC8272ADS
DRAM:  32 MB
FLASH: 512 kB
In:    serial
Out:   serial
Err:   serial
Net:   FCC1 ETHERNET
Hit any key to stop autoboot:  0 
Using FCC1 ETHERNET device
TFTP from server 192.168.0.99; our IP address is 192.168.0.100
Filename 'uImage'.
Load address: 0x400000
Loading: #################################################################
	 #################################################################
	 #######################
done
Bytes transferred = 781091 (beb23 hex)
=> bootm

## Booting image at 00400000 ...
   Image Name:   Linux-2.6.11
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    781027 Bytes = 762.7 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
OK
Linux version 2.6.11 (root@localhost.localdomain) (gcc version 4.0.0 (DENX
ELDK 4.0 4.0.0)) #49 Tue Apr 7 04:11:56 EDT 2009

Motorola PQ2 ADS PowerPC port

Built 1 zonelists

Kernel command line: mem=32M console=ttyCPM0,9600 root=/dev/mtdblock0 rw
rootfstype=jffs2

PID hash table entries: 256 (order: 8, 4096 bytes)

Warning: real time clock seems stuck!

Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)

Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)

Memory: 30728k available (1304k kernel code, 276k data, 104k init, 0k
highmem)

Mount-cache hash table entries: 512 (order: 0, 4096 bytes)

Chengmo : Here will enter rest_init()!

NET: Registered protocol family 16

PCI: Probing PCI hardware

Generic RTC Driver v1.07

Serial: CPM driver $Revision: 0.01 $

ttyCPM0 at MMIO 0xf0011a80 (irq = 4) is a CPM UART

io scheduler noop registered

io scheduler anticipatory registered

io scheduler deadline registered

io scheduler cfq registered

RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize

loop: loaded (max 8 devices)

halt here~
i have tried to build newer kernel and bootloader. but LEDs were not
blinking at start_kernel, i guessed something wrong with dts, i should check
OF doc and dts. 
-- 
View this message in context: http://www.nabble.com/issue-at-the-beginning-of-kernel-booting-tp22741532p22931181.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.

Re: issue at the beginning of kernel booting

[Scott Wood]

Sauce.Cheng wrote:
>>> i tried 
>>> CONFIG_PPC_EARLY_DEBUG_CPM=y 
>>> CONFIG_PPC_EARLY_DEBUG_CPM_ADDR=0xf00000008	
>>> how can i make sure CPM_ADDR, 0xf0000008 is default value 
> 
>> Look at the u-boot source, or dump the memory and see if it looks like a
>> ring buffer.
> 
> sorry, i mean that CPM_ADDR is address of what? address of CPM registers or
> something?

It's the address of a transmit descriptor for the serial port.  It's 
typically in DPRAM, but the exact position depends on where u-boot put 
it.  Try 0xf0000088.

>> This is a dts-v0 tree, which implies it's fairly old.
> dose later dts be used in corresponding kernel version ?

Yes, current kernels use dts-v1.

> in addition, there is one more question. 
> my RAM size is 32MBytes, my "vmlinux" size is 30MBytes, "vmlinux.o" size is
> 58MBytes. so , will there be something wrong at uncompressing time ?

That's just debugging information; it won't end up in the uImage.  Use 
the "size" utility in your toolchain to see how big the actual code and 
data are.

-Scott