Can *anyone* who is doing Linux + EDK (not V2PDK) please forward me a copy of your .mhs???
(The ML300 port was done by MontaVista using V2PDK. & when I contacted Xilinx about Linux & EDK, their answer was simply to say "we're still working on it".) Thanks in advance. -----Original Message----- From: Prakash kanthi [mailto:[EMAIL PROTECTED] Sent: Friday, March 28, 2003 5:56 PM To: Kerl, John Subject: RE: Virtex-II Pro tlbia exception John, Interesting. This should not happen. I never ran into this problem. You may want to double check your memory again. Check your image objdump. Prakash --- "Kerl, John" <John.Kerl at Avnet.com> wrote: > > Excellent; I now get past the tlbia. > What happens soon thereafter, though, is troubling. > > What I see is, from the beginning of vmlinux: > > * At phys. 00000000, save regs. > * bl initial_mmu (still running from real memory) > - map c0000000 to 00000000, 16 MB > - return > * back near the top of head_4xx.S: > - set SRR1 to 0x1032 > - set SRR0 to c00022dc (vrt. start_here) > - rfi > * Processor starts to fetch from address 0xc00022dc. > > Problem: c000xxxx is still apparently not mapped! > I can dump out 0000xxxx region & still see expected > vmlinux data; I dump out c000xxxx region and see > zeroes. > (This is a strange fact of MicroBlaze & VII-Pro -- > non-existent address ranges do provide data on a > read, > and read back as zeroes.) > > Furthermore, XMD (if it can be trusted) tells me the > MSR is still zero! > > The 0x0030 in 0x1032 should set MSR[IR] and MSR[DR]. > Xilinx notes that the 0x0002 bit is reserved; I also > tried setting SRR1 to just 0x1030, but with no > difference. > > I'm at a loss here, as the Xilinx docs are quite > clear > that you set SRR1 to your desired MSR value, SRR0 to > return address, then rfi. But it seems to simply > *not > happen*. > > Has anyone gotten a VII-Pro system off the ground > and > is willing to share advice and/or code? > > Thanks. > > > -----Original Message----- > From: Prakash kanthi [mailto:pkanthi at yahoo.com] > Sent: Friday, March 28, 2003 2:00 PM > To: Kerl, John; > 'linuxppc-embedded at 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 at 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/
