Kernel hangs in early_init

Kernel hangs in early_init

[Stephen Williams]

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/

Re: Kernel hangs in early_init

[Wolfgang Denk]

In message <19122-27221@sneakemail.com> you wrote:
>
> 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.
...
> ## Transferring control to Linux (at address 00000000) ...

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: wd@denx.de
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/

Re: Kernel hangs in early_init

[Stephen Williams]

Wolfgang Denk wd-at-denx.de |PPC Linux Embedded| wrote:
 > In message <19122-27221@sneakemail.com> you wrote:
 >
 >>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.
 >
 > ...
 >
 >>## Transferring control to Linux (at address 00000000) ...
 >
 >
 > Did you check the FAQ? See
 > http://www.denx.de/twiki/bin/view/DULG/LinuxHangsAfterUncompressingKernel

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/

Re: Kernel hangs in early_init

[Wolfgang Denk]

In message <4522-80798@sneakemail.com> you wrote:
>
> 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 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.

> 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)?

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: wd@denx.de
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/

Re: Kernel hangs in early_init

[Stephen Williams]

Wolfgang Denk wd-at-denx.de |PPC Linux Embedded| wrote:
> In message <4522-80798@sneakemail.com> you wrote:
>
>>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 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 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.

>
>>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)?
>
>
> I don't think so.

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/

Re: Kernel hangs in early_init

[Andrei Konovalov]

Stephen Williams wrote:
> I'm using ... PPC405GPr ...
...
>
> 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)?
>

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/

Re: Kernel hangs in early_init

[Stephen Williams]

Andrei Konovalov akonovalov-at-ru.mvista.com |PPC Linux Embedded| wrote:
> Stephen Williams wrote:

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

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/