From: Dan Malek <dan@netx4.com>
To: "Robin O'Leary" <ppc@ro.nu>
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: 860T cold boot
Date: Mon, 29 Nov 1999 19:24:05 -0500 [thread overview]
Message-ID: <38431925.2B0111C2@netx4.com> (raw)
In-Reply-To: 19991129234653.A1270@mail.ro.nu
Robin O'Leary wrote:
> Using the (rather unreliable) SDS SingleStep development kit and BDM
> cable, I can address all the CPU memory-mapped registers, set up the SIU,
> load zImages into RAM or flash and make them run. I can write simple
> programs that waggle I/O ports and generally test that the hardware is
> present and correct. But when I try to run a zImage it all goes wrong.
> The debugger doesn't seem able to insert working breakpoints after the
> first ``rfi'' so I can't tell exactly what's the matter,
The trouble is Linux+MMU+BDM doesn't work. Once the MMU is
enabled by the rfi, BDM debuggers don't understand the world
and keep poking around and breaking things.
When trying to run Linux, you must use a BDM debugger that allows
you to disable all debugging hooks. All you can do is download
the kernel, disable all debugging, and then push the 'go' button.
Or, use a kernel-aware BDM debugger for Linux, which doesn't
exist.....yet.
>
> I currently set up 25 registers plus the UPM table with values derived
> initially from Motorola's hopeless mcuinit tool, later much tinkered with
> by reference to the 860UM/AD manual. I'm sure that's all I should need to
> get it going.
There are lots of 8xx internal registers that have to be
set properly depending upon your hardware configuration. If
you didn't sit down with a hardware engineer to derive your
DRAM timing, I doubt the UPM tables are correct. You also
need to set several multifunction pin configurations depending
upon the external bus connections and external devices.
Since you were able to get something downloaded and running
at least that far, some of the hardware configuration is
correct. The worst case bus timing occurs when you start up
an Ethernet port which performs burst mode DMA while the PPC
core has copyback caches enabled. That's when you are going
to start looking for software bugs, but the real problem is
DRAM timing or other hardware configuration problems.
> ....If anybody has a working set of initialisation
> instructions that they could share, or even just a register dump of how
> their boot-loader leaves things set, I should be most grateful.
That is a place to start, but these values have to be properly
set for your hardware design.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
prev parent reply other threads:[~1999-11-30 0:24 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-11-29 23:46 860T cold boot Robin O'Leary
1999-11-30 0:24 ` Dan Malek [this message]
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=38431925.2B0111C2@netx4.com \
--to=dan@netx4.com \
--cc=linuxppc-embedded@lists.linuxppc.org \
--cc=ppc@ro.nu \
/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).