* [U-Boot-Users] PPC405GP - uboot - can't get past stackloop
2003-01-05 23:48 ` [U-Boot-Users] PPC405GP - uboot - can't get past stackloop Jerry Walden
@ 2003-01-05 23:02 ` Wolfgang Denk
2003-01-06 2:37 ` Jerry Walden
0 siblings, 1 reply; 7+ messages in thread
From: Wolfgang Denk @ 2003-01-05 23:02 UTC (permalink / raw
To: u-boot
In message <EGEGIJHKDKJGAJMGIDPNEEAECEAA.jwalden@digitalatlantic.com> you wrote:
>
> Now - I start tracing from the _start, and I get to:
>
> ..stackloop
> stwu r4, -4(r2)
> bdnz ..stackloop
Stop right before "..stackloop" and verify that the stack area is
really readable and writable, i. e. check if your initial RAM area
(in data cache or OCM ?) is configured correctly and working.
> If I set a breakpoint after the bdnz, the debugger never breaks - it is
> though it is in
> an infinite loop.
...because the CPU never gets there, because it's taking an exception
before?
> If I "interrupt" in DDD, the following message is displayed:
>
> Program received signal SIGSTOP, Stopped(Signal)
> 0x00000700 in ??()
Right, an exception happened.
> Any hint as to what might be going wrong?
Your initial RAM area is configured incorrectly and does not work?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
We are drowning in information but starved for knowledge.
-- John Naisbitt, Megatrends
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot-Users] PPC405GP - uboot - can't get past stackloop
2003-01-06 2:37 ` Jerry Walden
@ 2003-01-05 23:46 ` Wolfgang Denk
2003-01-06 17:05 ` Jerry Walden
0 siblings, 1 reply; 7+ messages in thread
From: Wolfgang Denk @ 2003-01-05 23:46 UTC (permalink / raw
To: u-boot
In message <EGEGIJHKDKJGAJMGIDPNMEAHCEAA.jwalden@digitalatlantic.com> you wrote:
> Yes - you are absolutly correct.
Been there myself often enough before ;-)
> Somewhere after about 1000 iterations of placing 0xdeaddead into what is
> supposed to be the temporary stack frame, I get a machine exception.
>
> So - now I know my memory is not configured correctly. My hardware guy is
Probably not your _memory_.
> not
> here, however I see that he has defined 64MB starting at 0x70000000.
Ignore that. RAM should always start at 0x0000.
> However if
> I change the value in my config file (CFG_INIT_RAM_ADDR) from 0x4000000 to
> 0x7000000
Be careful! The initial memory is NOT in RAM!!! It used the data
cache or OCM - don't know the design of your board. If in doubt, use
the data cache.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
This all sounds complicated, but it mostly does excatly what you ex-
pect. It's just difficult for us to explain what you expect...
- L. Wall & R. L. Schwartz, _Programming Perl_
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot-Users] PPC405GP - uboot - can't get past stackloop
2003-01-02 12:01 [U-Boot-Users] How To Use gdb w/ u-boot source tree Wolfgang Denk
@ 2003-01-05 23:48 ` Jerry Walden
2003-01-05 23:02 ` Wolfgang Denk
0 siblings, 1 reply; 7+ messages in thread
From: Jerry Walden @ 2003-01-05 23:48 UTC (permalink / raw
To: u-boot
Greetings:
I have managed to learn how to use GDB, and DDD with the BDI-2000 to start
to debug
my bootrom. I can load source, and symbols etc...
So - here is where I am stuck. First, I am using u-boot with the
WALNUT405GP config.
My board is a custom board with a 405GPr on it. The memory map looks the
same as
the development kit (or at least we tried our best).
Now - I start tracing from the _start, and I get to:
..stackloop
stwu r4, -4(r2)
bdnz ..stackloop
If I set a breakpoint after the bdnz, the debugger never breaks - it is
though it is in
an infinite loop.
If I "interrupt" in DDD, the following message is displayed:
Program received signal SIGSTOP, Stopped(Signal)
0x00000700 in ??()
Any hint as to what might be going wrong?
Thanks
Jerry
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot-Users] PPC405GP - uboot - can't get past stackloop
2003-01-05 23:02 ` Wolfgang Denk
@ 2003-01-06 2:37 ` Jerry Walden
2003-01-05 23:46 ` Wolfgang Denk
0 siblings, 1 reply; 7+ messages in thread
From: Jerry Walden @ 2003-01-06 2:37 UTC (permalink / raw
To: u-boot
Yes - you are absolutly correct.
Somewhere after about 1000 iterations of placing 0xdeaddead into what is
supposed to be the temporary stack frame, I get a machine exception.
So - now I know my memory is not configured correctly. My hardware guy is
not
here, however I see that he has defined 64MB starting at 0x70000000.
However if
I change the value in my config file (CFG_INIT_RAM_ADDR) from 0x4000000 to
0x7000000
I get an immediate fault the first time a store is attempted in that
region - so
r4 has something like 0x70001f48 in it, and I get the fault the very first
time
I execute the stwu instruction. However with the BDI, I can change memory
at 0x7000000 - 0x7fffffff all day long without a complaint. So obviously
the
code I am running at the very start of start.S is not setting something up
properly. Question is, what is it?
-----Original Message-----
From: wd@denx.de [mailto:wd at denx.de]
Sent: Sunday, January 05, 2003 3:03 PM
To: jwalden at digitalatlantic.com
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] PPC405GP - uboot - can't get past stackloop
In message <EGEGIJHKDKJGAJMGIDPNEEAECEAA.jwalden@digitalatlantic.com> you
wrote:
>
> Now - I start tracing from the _start, and I get to:
>
> ..stackloop
> stwu r4, -4(r2)
> bdnz ..stackloop
Stop right before "..stackloop" and verify that the stack area is
really readable and writable, i. e. check if your initial RAM area
(in data cache or OCM ?) is configured correctly and working.
> If I set a breakpoint after the bdnz, the debugger never breaks - it is
> though it is in
> an infinite loop.
...because the CPU never gets there, because it's taking an exception
before?
> If I "interrupt" in DDD, the following message is displayed:
>
> Program received signal SIGSTOP, Stopped(Signal)
> 0x00000700 in ??()
Right, an exception happened.
> Any hint as to what might be going wrong?
Your initial RAM area is configured incorrectly and does not work?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
We are drowning in information but starved for knowledge.
-- John Naisbitt, Megatrends
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot-Users] PPC405GP - uboot - can't get past stackloop
2003-01-06 17:05 ` Jerry Walden
@ 2003-01-06 15:18 ` Wolfgang Denk
0 siblings, 0 replies; 7+ messages in thread
From: Wolfgang Denk @ 2003-01-06 15:18 UTC (permalink / raw
To: u-boot
In message <EGEGIJHKDKJGAJMGIDPNCEBDCEAA.jwalden@digitalatlantic.com> you wrote:
> >Be careful! The initial memory is NOT in RAM!!! It used the data
> >cache or OCM - don't know the design of your board. If in doubt, use
> >the data cache.
Actually you must be using the data cache for initial data -
otherwise you would not enter "stackloop" at all.
> So if I read correctly, the OCM for the 405GP is not a function of how the
> board is "wired", but how I set it up programmatically. However it seems
> that you are indicating that it depends on the design of my board. Can
> you please help provide clarification.
Sorry for not being clear - for me the design of a board inclused
hardware and software issues - for example the memory map, which may
be dictated by hardware (address decoders etc.), but often is at
least partially adjustable by software.
Did you verify that your stack space (in data cache) can be read and
written?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
An Elephant is a mouse with an Operating System. - Knuth
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot-Users] PPC405GP - uboot - can't get past stackloop
2003-01-05 23:46 ` Wolfgang Denk
@ 2003-01-06 17:05 ` Jerry Walden
2003-01-06 15:18 ` Wolfgang Denk
0 siblings, 1 reply; 7+ messages in thread
From: Jerry Walden @ 2003-01-06 17:05 UTC (permalink / raw
To: u-boot
>Be careful! The initial memory is NOT in RAM!!! It used the data
>cache or OCM - don't know the design of your board. If in doubt, use
>the data cache.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot-Users] PPC405GP - uboot - can't get past stackloop
@ 2021-04-02 22:39 Katrina Copp
0 siblings, 0 replies; 7+ messages in thread
From: Katrina Copp @ 2021-04-02 22:39 UTC (permalink / raw
To: u-boot
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-04-02 22:39 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-04-02 22:39 [U-Boot-Users] PPC405GP - uboot - can't get past stackloop Katrina Copp
-- strict thread matches above, loose matches on Subject: below --
2003-01-02 12:01 [U-Boot-Users] How To Use gdb w/ u-boot source tree Wolfgang Denk
2003-01-05 23:48 ` [U-Boot-Users] PPC405GP - uboot - can't get past stackloop Jerry Walden
2003-01-05 23:02 ` Wolfgang Denk
2003-01-06 2:37 ` Jerry Walden
2003-01-05 23:46 ` Wolfgang Denk
2003-01-06 17:05 ` Jerry Walden
2003-01-06 15:18 ` Wolfgang Denk
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.