From: Joshua Lamorie <jpl@xiphos.ca>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] v2p4 porting troubles
Date: Mon, 15 Mar 2004 22:05:26 -0500 [thread overview]
Message-ID: <009401c40b03$8800ae90$cb01a8c0@xiphos.ca> (raw)
Gidday there,
We have a custom made board containing not much more than a Virtex-II Pro
(v2p4) and 16 Megs of Mobile SDRAM. We are trying to port Linux, and in
preparing we've successfully built kernels and code for a development board
from Amirix.
But...
We have had a series of problems with getting u-boot to work. Firstly, this
is a small Virtex-II, so we are unable to put everything into BRAM. So
we've made a stripped down version of Amirix's ppcboot-lite, that is
supposed to load u-boot, which then will load Linux.
Ppcboot-lite runs fine out of BRAM. However we've had several problems with
executing from SDRAM. With various versions of the IPIF interface we have
gone through the various Machine Check Exceptions problems with jumps to
0x700 and 0x200.
Now, it seems that we have found a working configuration (ipif v1.0.d) that
lets us run code compiled by EDK (on WinXP under VMWare), but there is an
odd problem with the same code compiled by our Linux cross-compiler.
We have some LEDs connected to memory mapped I/O, and our test code writes
to it. The EDK compiled binary makes the following assembly for the output
part.
stw r0,0(r9)
This works fine, and the LEDs blink all pretty and flashy like.
The Linux tools compile...
stw r9,0(r0)
However, the LEDs respond with blankity nothingness. Using XMD, we swap
around these general purpose (according to how we read the docs) registers
(r8,r10, r1 etc.) , and sometimes it works and sometimes it doesn't.
In the mailing-list archive, I've seen mention of a common SDRAM problem
with u-boot, but it wasn't clear if this was just for Virtex-IIs or what.
Has anyone seen a problem like this? Is it our toolchain? Could it be
signal integrity on our board? (we have slowed things on the bus down to
16MHz, just in case)
We are using crosstools-0.26, with gcc-3.3-20040112 and glibc-2.3.2.
Questions for clarification are welcome. Pointers, smack-up-side-the-heads,
hints, cajoles, rants are also welcome.
Joshua Lamorie
Department of Random Walks
Xiphos Technologies Inc.
next reply other threads:[~2004-03-16 3:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-16 3:05 Joshua Lamorie [this message]
2004-03-16 15:43 ` [U-Boot-Users] v2p4 porting troubles Joshua Lamorie
2004-03-16 16:01 ` Wolfgang Denk
2004-03-16 19:41 ` Eric St-Jean
2004-03-16 20:36 ` Wolfgang Denk
2004-03-16 23:01 ` Joshua Lamorie
2004-03-16 23:40 ` Wolfgang Denk
2004-03-17 9:47 ` Joakim Tjernlund
2004-03-17 11:16 ` Joakim Tjernlund
2004-03-17 2:02 ` Peter Ryser
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='009401c40b03$8800ae90$cb01a8c0@xiphos.ca' \
--to=jpl@xiphos.ca \
--cc=u-boot@lists.denx.de \
/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