RE: Virtex-II Pro tlbia exception

From: Kerl, John <hidden>
Date: 2003-03-28 21:01:52

$ grep -i mmu *.mhs
system.mhs:  PORT tiec405mmuen = net_gnd

Thanks!!!!

-----Original Message-----
From: Prakash kanthi [mailto:pkanthi@yahoo.com]
Sent: Friday, March 28, 2003 2:00 PM
To: Kerl, John; 'linuxppc-embedded@lists.linuxppc.org'
Subject: Re: Virtex-II Pro tlbia exception


John,

I had similar problems. Here is what i would do.

1. Check the ESR register for the exception. If the
exception indicates "Illegal Instruction", problem
could be because your hw folks i have mmu_enable
signal set to 'net_gnd'. Ask them to change it to
'net_vcc', and you are good to go.

2. If the ESR does not help you much, double check
your code that does I/D cache cleanups.

Prakash

--- "Kerl, John" <John.Kerl@Avnet.com> wrote:
Hello all,

After several weeks on other projects I am picking
up on
the VII-Pro again.

For reference, we have our firmware up and running
fine on
the board; we can talk to the UART, and SDRAM tests
fine.
(The hardware-level verification is actually
something we are
good at doing.)

Using arch/ppc/boot/avnet (modified from
arch/ppc/boot/common),
along with our firmware, I'm able to build a
zImage.initrd.elf,
TFTP to the board, and jump into
arch/ppc/boot/avnet/misc-embedded.c.
This code reports on the bd_t parameters passed from
the firmware
(all parameters are as expected), and decompresses
the kernel to
address 0.  I can hex-dump the address-0 region & I
find that
what I see in vmlinux on the host PC really is what
I see at
address 0 and above.

Then the arch/ppc/boot code jumps to address 0,
entering vmlinux
per se.  The first few instructions (head_4xx.S)
save boot args
r3-r7 to r31-27, then jump to initial_mmu.  The very
first thing
there is a tlbia.

Now, when I single-step through this, I find that
the debugger
(XMD) shows me tlbia being executed twice (e.g.
"stp" once and
I'm still at the tlbia, "stp" again and continue),
and also
the next instruction after that is fetched from
address 0xedba0700.

Now, the 0xedba0000 prefix is, as far as I can tell,
garbage.
8xx's have an MSR bit that specifies whether
exception prefixes
are 0x00000000 or 0xfff00000; I see no such bit for
the VII-Pro 405.
And the 0700 suffix looks like a program check; yet,
my MSR is 00000000
indicating that I am indeed in privileged mode.
SRR0 is just the
address of the tlbia.

Since I've been running simple-minded firmware up to
this point, I
think it highly likely that I haven't yet told the
405 to be in
some mode it needs to be in.  But I don't know what.
 I checked
around in PPCBoot source for the ML2 board, thinking
that perhaps
someone else porting to Virtex-II Pro might have
found some magic
ingredient, but actually the initialization there
appears to be
minimal (as expected).

Does anyone know why (a) the prefix 0xedba is so
bizarre, (b)
why I appear to be taking a program check, and/or
(c) am I
missing some initialization steps that the firmware
should
have done?

Thanks.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help