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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).