From: "Stephen Williams" <612dlag102@sneakemail.com>
To: linuxppc-embedded@lists.linuxppc.org
Subject: Re: Kernel hangs in early_init
Date: Tue, 02 Mar 2004 16:14:23 -0800 [thread overview]
Message-ID: <5993-72182@sneakemail.com> (raw)
In-Reply-To: <20040302235632.341E4C0655@atlas.denx.de>
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/
next prev parent reply other threads:[~2004-03-03 0:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-02 6:41 Kernel hangs in early_init Stephen Williams
2004-03-02 8:51 ` Wolfgang Denk
2004-03-02 18:48 ` Stephen Williams
2004-03-02 23:56 ` Wolfgang Denk
2004-03-03 0:14 ` Stephen Williams [this message]
2004-03-03 9:44 ` Andrei Konovalov
2004-03-03 20:16 ` Stephen Williams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5993-72182@sneakemail.com \
--to=612dlag102@sneakemail.com \
--cc=linuxppc-embedded@lists.linuxppc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.