From: Dan A. Dickey <hidden> Date: 2000-05-17 02:31:10
"Dan A. Dickey" wrote:
Nicolas-Peter Pohland wrote:
quoted
Did you try "rms der 0" (assuming you have the ADI board and MPC8bug SW)
Nope, haven't tried that. I'll look at it later tonight; thanks
for the tip.
Good! Fantastic tip.
This helps tremendously, especially in the fact that now I can
actually boot and run the kernel on my fads... while the ADI &
mpc8bug are connected. Before that, I would always get the
InstructionTLBMiss exception - and of course, mpc8bug didn't
really know anything about the address.
Also, I'm also now running in "stand alone" mode - with the
ADI & mpc8bug disconnected. Straight from the flash.
For me, this is great news. I know that most of you don't
give a hoot! :)
So, I'm attributing this recent success to:
A) Setting SYPCR in the rom code fairly early on.
B) Issuing a "rms der 0" to mpc8bug when it is connected.
I'm a happy camper at the moment. Mostly. :)
I just need to get my regular system setup to allow bootp and
host an nfs root for the fads.
Also, I just noticed - the kernel couldn't mount root, so it's
doing its "Rebooting in 180 seconds.." act. However, about
all I'm seeing after that is a:
<0>Kernel panic: Kernel Mode Software FPU Emulation
and then the duo is repeating every 180 seconds...
Not quite what I call a reboot. I would think it would at
least manage to restart the rom initialization code.
Anyways, thats relatively minor...
have a good night!
-Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Richard Hendricks <hidden> Date: 2000-05-17 19:08:56
"Dan A. Dickey" wrote:
"Dan A. Dickey" wrote:
quoted
Nicolas-Peter Pohland wrote:
quoted
Did you try "rms der 0" (assuming you have the ADI board and MPC8bug SW)
Nope, haven't tried that. I'll look at it later tonight; thanks
for the tip.
Good! Fantastic tip.
This helps tremendously, especially in the fact that now I can
actually boot and run the kernel on my fads... while the ADI &
mpc8bug are connected. Before that, I would always get the
InstructionTLBMiss exception - and of course, mpc8bug didn't
really know anything about the address.
Also, I'm also now running in "stand alone" mode - with the
ADI & mpc8bug disconnected. Straight from the flash.
For me, this is great news. I know that most of you don't
give a hoot! :)
Au Contraire, I care very much, being the MPC823 support body! :)
So, I'm attributing this recent success to:
A) Setting SYPCR in the rom code fairly early on.
B) Issuing a "rms der 0" to mpc8bug when it is connected.
Interesting. So clearing the SYPCR early in the ROM code is what
was preventing you from getting the code to run stand-alone? Kinda
odd, considering the initial value of the watchdog is very long,
and you were having problems getting your Aux LED to turn on
right at the very beginning.
I'm a happy camper at the moment. Mostly. :)
I just need to get my regular system setup to allow bootp and
host an nfs root for the fads.
Also, I just noticed - the kernel couldn't mount root, so it's
doing its "Rebooting in 180 seconds.." act. However, about
all I'm seeing after that is a:
<0>Kernel panic: Kernel Mode Software FPU Emulation
and then the duo is repeating every 180 seconds...
Not quite what I call a reboot. I would think it would at
least manage to restart the rom initialization code.
Anyways, thats relatively minor...
have a good night!
-Dan
--
MPC823 Applications Engineering Development
Get help from other MPC823 customers on the
comp.sys.powerpc.tech newsgroup!
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Dan Malek <hidden> Date: 2000-05-18 03:20:24
Richard Hendricks wrote:
Interesting. So clearing the SYPCR early in the ROM code is what
was preventing you from getting the code to run stand-alone?
Oh, yes. Clearing SYPCR is a very bad thing. You end up with counter
values set to zero and immediately time out. It seems a little strange,
as you have also cleared the enable flags. I am sure someone at SPS
could explain the transistors flipping inside the part to make this
happen.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Dan A. Dickey <hidden> Date: 2000-05-18 03:20:42
Richard Hendricks wrote:
"Dan A. Dickey" wrote:
...
quoted
So, I'm attributing this recent success to:
A) Setting SYPCR in the rom code fairly early on.
B) Issuing a "rms der 0" to mpc8bug when it is connected.
Interesting. So clearing the SYPCR early in the ROM code is what
was preventing you from getting the code to run stand-alone? Kinda
odd, considering the initial value of the watchdog is very long,
and you were having problems getting your Aux LED to turn on
right at the very beginning.
I believe that was at least a goodly portion of it.
It is interesting to note that the Aux LED still doesn't
blink unless the ADI & mpc8bug are connected.
Stand alone - no blinking light. I'm going to
attribute this for the time being to the UPM not
being initialized - or some piece of hardware.
In any case, I was trying to use the Aux LED as
an indicator of how far the cpu got through the
code. Getting to the point of an 8xxrom prompt
at which I can enter 'bootz', hit C/R, and see
linux boot up was enough for me to yank the assembly
version of the Aux LED blinking code.
I also think it was the delays I put in between
turning the light on/off that caused it to take too
long and for the watchdog to bite.
I might add that doing the "rms der 0" helped tremendously
as well. I can now leave the ADI & mpc8bug connected
(for flashing new code) - but still allow linux to load
& start. It doesn't without doing that (even though
8xxrom sets DER to 0!).
-Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Dan A. Dickey <hidden> Date: 2000-05-18 03:22:43
Dan Malek wrote:
Richard Hendricks wrote:
quoted
Interesting. So clearing the SYPCR early in the ROM code is what
was preventing you from getting the code to run stand-alone?
Oh, yes. Clearing SYPCR is a very bad thing. You end up with counter
values set to zero and immediately time out. It seems a little strange,
as you have also cleared the enable flags. I am sure someone at SPS
could explain the transistors flipping inside the part to make this
happen.
Ok ok...not *clearing* SYPCR. :)
Just setting it to 0xFFFFFF88.
-Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Richard Hendricks <hidden> Date: 2000-05-18 16:15:34
"Dan A. Dickey" wrote:
Richard Hendricks wrote:
quoted
"Dan A. Dickey" wrote:
...
quoted
quoted
So, I'm attributing this recent success to:
A) Setting SYPCR in the rom code fairly early on.
B) Issuing a "rms der 0" to mpc8bug when it is connected.
Interesting. So clearing the SYPCR early in the ROM code is what
was preventing you from getting the code to run stand-alone? Kinda
odd, considering the initial value of the watchdog is very long,
and you were having problems getting your Aux LED to turn on
right at the very beginning.
I believe that was at least a goodly portion of it.
It is interesting to note that the Aux LED still doesn't
blink unless the ADI & mpc8bug are connected.
Stand alone - no blinking light.
Well that's just plain odd. If for some reason you couldn't
access the Aux LED, then you shouldn't be able to activate
any of the other stuff. Something very bizarre is happening. :)
Have you tried activating the LED from much later in your code?
I'm going to
attribute this for the time being to the UPM not
being initialized - or some piece of hardware.
In any case, I was trying to use the Aux LED as
an indicator of how far the cpu got through the
code. Getting to the point of an 8xxrom prompt
at which I can enter 'bootz', hit C/R, and see
linux boot up was enough for me to yank the assembly
version of the Aux LED blinking code.
I also think it was the delays I put in between
turning the light on/off that caused it to take too
long and for the watchdog to bite.
I might add that doing the "rms der 0" helped tremendously
as well. I can now leave the ADI & mpc8bug connected
(for flashing new code) - but still allow linux to load
& start. It doesn't without doing that (even though
8xxrom sets DER to 0!).
Um, that's documented so I take no blame for it. :)
See page 20-41. If you have debug mode enabled, and
are not currently IN debug mode (ie, MPC8bug is connected,
but you are running your code), then a write to the
DP registers is ignored.
What I do to download programs to MPC8bug is:
Flash the S-Records
Just download the ELF file symbols (load blah :js) for debug
Set the DER to something reasonable like 0xfdc7400f
(I'm very lazy about this, I added a "setder" command to .mpctcl.cfg
at the very end. Looks like:
a setder rms der 0xfdc7400f
Laziness is the mother of invention!)
Then I unload the PLPRCR and set the MF. Sometimes MPC8bug gets
lost when the CPU changes clock frequencies, this gets around that.
-Dan
--
MPC823 Applications Engineering Development
Get help from other MPC823 customers on the
comp.sys.powerpc.tech newsgroup!
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Dan A. Dickey <hidden> Date: 2000-05-19 11:12:50
Richard Hendricks wrote:
"Dan A. Dickey" wrote:
quoted
Richard Hendricks wrote:
quoted
"Dan A. Dickey" wrote:
...
quoted
quoted
So, I'm attributing this recent success to:
A) Setting SYPCR in the rom code fairly early on.
B) Issuing a "rms der 0" to mpc8bug when it is connected.
Interesting. So clearing the SYPCR early in the ROM code is what
was preventing you from getting the code to run stand-alone? Kinda
odd, considering the initial value of the watchdog is very long,
and you were having problems getting your Aux LED to turn on
right at the very beginning.
I believe that was at least a goodly portion of it.
It is interesting to note that the Aux LED still doesn't
blink unless the ADI & mpc8bug are connected.
Stand alone - no blinking light.
Well that's just plain odd. If for some reason you couldn't
access the Aux LED, then you shouldn't be able to activate
any of the other stuff. Something very bizarre is happening. :)
Have you tried activating the LED from much later in your code?
Yes, works just fine.
quoted
I'm going to
attribute this for the time being to the UPM not
being initialized - or some piece of hardware.
In any case, I was trying to use the Aux LED as
an indicator of how far the cpu got through the
code. Getting to the point of an 8xxrom prompt
at which I can enter 'bootz', hit C/R, and see
linux boot up was enough for me to yank the assembly
version of the Aux LED blinking code.
I also think it was the delays I put in between
turning the light on/off that caused it to take too
long and for the watchdog to bite.
I might add that doing the "rms der 0" helped tremendously
as well. I can now leave the ADI & mpc8bug connected
(for flashing new code) - but still allow linux to load
& start. It doesn't without doing that (even though
8xxrom sets DER to 0!).
Um, that's documented so I take no blame for it. :)
See page 20-41. If you have debug mode enabled, and
are not currently IN debug mode (ie, MPC8bug is connected,
but you are running your code), then a write to the
DP registers is ignored.
Page 20-41 of what? There's nothing like that in my
850 users manual, and the mpc8bug users manual doesn't
come close to having 20 chapters.
What I do to download programs to MPC8bug is:
Flash the S-Records
Just download the ELF file symbols (load blah :js) for debug
Set the DER to something reasonable like 0xfdc7400f
(I'm very lazy about this, I added a "setder" command to .mpctcl.cfg
at the very end. Looks like:
a setder rms der 0xfdc7400f
Laziness is the mother of invention!)
Then I unload the PLPRCR and set the MF. Sometimes MPC8bug gets
lost when the CPU changes clock frequencies, this gets around that.
Sounds good, I'll try this.
Though, at the moment I don't have any idea what the
PLPRCR or MF are. :) I'll read up on them.
-Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Richard Hendricks <hidden> Date: 2000-05-19 15:01:12
"Dan A. Dickey" wrote:
quoted
Um, that's documented so I take no blame for it. :)
See page 20-41. If you have debug mode enabled, and
are not currently IN debug mode (ie, MPC8bug is connected,
but you are running your code), then a write to the
DP registers is ignored.
Page 20-41 of what? There's nothing like that in my
850 users manual, and the mpc8bug users manual doesn't
come close to having 20 chapters.
Oooooh, you're one of those Netcomm customers. :) I currently
support the MPC823/MPC823e. They're very similar chips. Our
manual is slightly different from the Netcomm manual. The
chapter in question is the Development Capabilities chapter.
I don't have an MPC850 manual handy. Besides, ours is much
better. :)
BTW, the final version of the MPC823/MPC823e manual is now
availible on our website. A printed version should be availible
at the LDC in a few weeks. The Powers That Be are making us change
the cover from the spiffy one we have to a black Digital DNA one.
Feh.
--
MPC823 Applications Engineering Development
Get help from other MPC823 customers on the
comp.sys.powerpc.tech newsgroup!
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/