Date: Fri, 22 Dec 2006 22:08:49 +1300 From: Andrew Turner <andrew@fubar.geek.nz> To: Peter Grehan <grehan@freebsd.org> Cc: freebsd-ppc@freebsd.org Subject: Re: FreeBSD on an Efika Message-ID: <20061222220849.1b978f6c@hermies.int.fubar.geek.nz> In-Reply-To: <458B5C21.907@freebsd.org> References: <20061218104841.72ba51ea@hermies.int.fubar.geek.nz> <4585CCC1.7050005@freebsd.org> <20061218222327.308dca53@hermies.int.fubar.geek.nz> <4586CA29.10803@freebsd.org> <20061219113230.34182787@hermies.int.fubar.geek.nz> <4587316C.1070500@freebsd.org> <20061220192614.04c53dbf@hermies.int.fubar.geek.nz> <45898F1F.402@freebsd.org> <20061221233622.60ca5eb3@hermies.int.fubar.geek.nz> <458B5C21.907@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 21 Dec 2006 20:16:33 -0800 Peter Grehan <grehan@freebsd.org> wrote: > > I get no output on either the screen or the serial line. After about > > 30s the computer reboots. It prints around 80 chars of a mixture of > > ASCII and binary and enters SmartFirmware (Open Firmware > > implementation) > > Alright, no clues there :( I suspect it is from Minicom as it also puts "icom2.1Minicom2.1" on the firmware prompt. > - write your favourite 0xdeadbeef-style pattern into the first word > of the physical address of the message buffer. > - read it back through the virtual address and verify that it is > this pattern. This works. > - write a different pattern to the phys address and verify it > again thorugh the virt address. I can write to the physical address. The kernel stops while reading from the virtual address. > > If it hangs on the second read as before, then it's time to try > something different: > > - create an exception handler that is identical to the existing > trapcode asm, but with 3 additional instructions prepended to clear > the GPR0-3 shadowing > > mfmsr %r0 > xoris %r0,%r0,PSL_TGPR@h > mtmsr %r0 > > /* fall through to trapcode */ > > - copy this to the TLB miss exception vectors. On a trap, you will > now end up in powerpc/trap.c:trap(), and can put in code to catch the > TLB miss vectors. At this point, it's worth dumping the DCMP, DMISS, > HASH1 and HASH2 spr's using the C-callable mfspr() routine. You can > then try implementing the TLB load routine in C, and verify that it > does what you think. I can't get this to work. I will have to investigate getting this information by some other means. Andrew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061222220849.1b978f6c>