Kernel hangs in early_init

I have a PPC405GPr based board w/ 128Meg SDRAM, and I'm building kernel 2.4.24 (devel CVS) for it. I also have U-Boot ported to it, and I'm using U-Boot as the bootstrap loader.

I am able to compile a uImage, load the uImage via SystemACE, and bootm seems happy with it. (See bootm log below.) I'm able to show that head_4xx.S gets as far as calling early_init in setup.c, and I can show that it starts executing in setup.c, but calls to reloc_offset never execute. It appears that the reloc_offset function never even starts.

I believe the SDRAM is configured OK, as u-boot is running out of it quite happily. So I'm left wondering what can possibly be wrong.

=> bootm 400000
## Booting image at 00400000 ...

   Image Name:   Linux-2.4.24-pre2
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    604749 Bytes = 590.6 kB

Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x07F7FC28 => set upper limit to 0x00800000 ## cmdline at 0x007FFF00 ... 0x007FFF30

bd address  = 0x07F7FE84
memstart    = 0x00000000
memsize     = 0x08000000
flashstart  = 0xFFF80000
flashsize   = 0x00080000
flashoffset = 0x0002A800
sramstart   = 0x00000000
sramsize    = 0x00000000
bootflags   = 0xF4000000
procfreq    = 266.500 MHz

plb_busfreq = 133.250 MHz
pci_busfreq = 33.312 MHz
baudrate = 9600 bps
No initrd
## Transferring control to Linux (at address 00000000) ...

--

Steve Williams                "The woods are lovely, dark and deep.
steve at XXXXXXXXXX           But I have promises to keep,
http://www.XXXXXXXXXX         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

...

Did you check the FAQ? See
http://www.denx.de/twiki/bin/view/DULG/LinuxHangsAfterUncompressingKernel

Best regards,

Wolfgang Denk

--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: [email protected] The only way to get rid of a temptation is to yield to it.
- Oscar Wilde

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Good point, I missed that. However, that particular FAQ doesn't seem to apply. I'm using 2.4.24+ (>2.4.5), the CFG_IMMR value doesn't seem to apply (PPC405GPr, not a MPC8xx system) and I double-checked that the bd_t structure matches. Besides, it's nowhere neer trying to access any of the arguments yet.

I put some progress checking code in the source to see where it goes, and I see it enters early_init, calls early_init (there is an initial MMU setup active at the time) and calls reloc_offset. However, it never actually seems to *arrive* in reloc_offset.

Humm... The MMU comment makes me think. U-Boot is running with the MMU off. The head_4xx.S entry code sets up a temporary MMU mapping that includes the linked kernel address space, but that is only 32meg. The stack at the time is still where U-Boot left it, near the end of the 128Meg memory. Is this something I should address (pardon the pun)?

--

Steve Williams                "The woods are lovely, dark and deep.
steve at XXXXXXXXXX           But I have promises to keep,
http://www.XXXXXXXXXX         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

I think it does access arguments. Linux will need parameters like clock frequencies, memory sizes etc. Passing wrong paramteters is one of the most frequent causes of that particular failure mode.

I don't think so.

Wolfgang Denk

--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: [email protected] If a man had a child who'd gone anti-social, killed perhaps, he'd still tend to protect that child.
-- McCoy, "The Ultimate Computer", stardate 4731.3

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

I know it will access the arguments *eventually*, but it is not there yet.

head_4xx.S:_start calls initial_mmu to set up a preliminary map, then turns on the MMU, branching to "start_here". start_here calls early_init, which immediately calls reloc_offset in misc.S, but stops there. In all this, I don't yet see any reference to the arguments until *after* early_init returns. Then the args are passed to machine_init.

Since it hangs *before* any reference to the passed in arguments, I don't believe the problem lies there.

I've homed in on the hang being during a bl to reloc_offset by using an o'scope and some spin loops, so I'm pretty sure where it's going.

I think it's something related to a stack, even if it's not that particular stack. Can someone explain this bit of code to me? I'm not a PPC ASM hotshot.

(from head_4xx.S)

	/* ptr to current */
	lis	r2,init_task_union@h
	ori	r2,r2,init_task_union@l

	/* ptr to phys current thread */
	tophys(r4,r2)
	addi	r4,r4,THREAD	/* init task's THREAD */
	mtspr	SPRG3,r4
	li	r3,0
	mtspr	SPRG2,r3	/* 0 => r1 has kernel sp */

	/* stack */
	addi	r1,r2,TASK_UNION_SIZE
	li	r0,0
	stwu	r0,-STACK_FRAME_OVERHEAD(r1)

	bl	early_init	/* We have to do this with MMU on */

--

Steve Williams                "The woods are lovely, dark and deep.
steve at XXXXXXXXXX           But I have promises to keep,
http://www.XXXXXXXXXX         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

...

Just a suggestion. Check that the whole data cache is invalidated. The kernel often relies on the bootloader to initialize dcache properly. And there is a chance that the bootloader was written for 405GP, but 405GPr's data cache is two times bigger. If this is the case you can either fix the bootloader, or invalidate dcache in the kernel's secondary bootloader (see arch/ppc/boot/simple/embed_config.c, embed_config() for Xilinx ML300 as an example).

Best regards,
Andrei

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

BINGO!

I am using U-Boot, and in my JSE.h I had mis-set the CFG_DCACHE_SIZE to 8K, as it was copied from another config file that I used as a starting point. U-Boot does some cache management, but obviously made a mess when it was told the wrong thing:-)

I set it properly, and I'm farther along.
--

Steve Williams                "The woods are lovely, dark and deep.
steve at XXXXXXXXXX           But I have promises to keep,
http://www.XXXXXXXXXX         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/