* Re: mfspr r0,638. Why 638 ?
From: Kumar Gala @ 2005-12-03 16:16 UTC (permalink / raw)
To: zengshuai; +Cc: ppc
In-Reply-To: <7707540.1133606321114.JavaMail.postfix@mx3.mail.sohu.com>
This is 8xx (PQ1) SPR. If you look one of those user manuals you =20
will see it.
- kumar
On Dec 3, 2005, at 4:38 AM, <zengshuai@sogou.com> =20
<zengshuai@sogou.com> wrote:
> We know "mfspr r0,638" can get the IMMR.
> But why?
> I checked "MPC82xx Reference Manual","G2 PowerPC™ Core =20
> Reference Manual","Programming Environments Manual",
> but I didn't find any word about that.How did the person who first =20
> known know?
>
> "G2 PowerPC™ Core Reference Manual" where is the "SPR 638"?
> Table 3-33. Implementation-Specific SPR Encodings (mfspr)
> Decimal spr[5?9] spr[0?4] RegisterName Access
> 58 00001 11010 CSRR0 Supervisor
> 59 00001 11011 CSRR1 Supervisor
> 276 01000 10100 SPRG4 Supervisor
> 277 01000 10101 SPRG5 Supervisor
> 278 01000 10110 SPRG6 Supervisor
> 279 01000 10111 SPRG7 Supervisor
> 286 01000 11110 SVR Supervisor
> 309 01001 10101 IBCR Supervisor
> 310 01001 10110 DBCR Supervisor
> 311 01001 10111 MBAR Supervisor
> 317 01001 11101 DABR2 Supervisor
> 560 10001 10000 IBAT4U Supervisor
> 561 10001 10001 IBAT4L Supervisor
> 562 10001 10010 IBAT5U Supervisor
> 563 10001 10011 IBAT5L Supervisor
> 564 10001 10100 IBAT6U Supervisor
> 565 10001 10101 IBAT6L Supervisor
> 566 10001 10110 IBAT7U Supervisor
> 567 10001 10111 IBAT7L Supervisor
> 568 10001 11000 DBAT4U Supervisor
> 569 10001 11001 DBAT4L Supervisor
> 570 10001 11010 DBAT5U Supervisor
> 571 10001 11011 DBAT5L Supervisor
> 572 10001 11100 DBAT6U Supervisor
> 573 10001 11101 DBAT6L Supervisor
> 574 10001 11110 DBAT7U Supervisor
> 575 10001 11111 DBAT7L Supervisor
> 976 11110 10000 DMISS Supervisor
> 977 11110 10001 DCMP Supervisor
> 978 11110 10010 HASH1 Supervisor
> 979 11110 10011 HASH2 Supervisor
> 980 11110 10100 IMISS Supervisor
> 981 11110 10101 ICMP Supervisor
> 982 11110 10110 RPA Supervisor
> 1008 11111 10000 HID0 Supervisor
> 1009 11111 10001 HID1 Supervisor
> 1010 11111 10010 IABR Supervisor
> 1011 11111 10011 HID2 Supervisor
> 1013 11111 10101 DABR Supervisor
> 1018 11111 11010 IABR2 Supervisor
>
> ------------------------------
> =E6=88=91=E7=8E=B0=E5=9C=A8=E4=BD=BF=E7=94=A8Sogou.com=E7=9A=842G=E9=82=AE=
=E7=AE=B1=E4=BA=86=EF=BC=8C=E4=BD=A0=E4=B9=9F=E6=9D=A5=E8=AF=95=E8=AF=95=E5=
=90=A7!
> http://mail.sogou.com/recommend/sogoumail_invite_reg1.jsp?=20
> from=3Dsogouinvitation&s_EMAIL=3Dzengshuai%=20
> 40sogou.com&username=3Dlinuxppc-embedded&FullName=3Dlinuxppc-=20
> embedded&Email=3Dlinuxppc-embedded%=20
> 40ozlabs.org&verify=3D755eff4e640bdcfc57d93cbd8b0a9cb7
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* mfspr r0,638. Why 638 ?
From: zengshuai @ 2005-12-03 10:38 UTC (permalink / raw)
To: ppc
We know "mfspr r0,638" can get the IMMR.
But why?
I checked "MPC82xx Reference Manual","G2 PowerPC™ Core Reference Manual","Programming Environments Manual",
but I didn't find any word about that.How did the person who first known know?
"G2 PowerPC™ Core Reference Manual" where is the "SPR 638"?
Table 3-33. Implementation-Specific SPR Encodings (mfspr)
Decimal spr[5?9] spr[0?4] RegisterName Access
58 00001 11010 CSRR0 Supervisor
59 00001 11011 CSRR1 Supervisor
276 01000 10100 SPRG4 Supervisor
277 01000 10101 SPRG5 Supervisor
278 01000 10110 SPRG6 Supervisor
279 01000 10111 SPRG7 Supervisor
286 01000 11110 SVR Supervisor
309 01001 10101 IBCR Supervisor
310 01001 10110 DBCR Supervisor
311 01001 10111 MBAR Supervisor
317 01001 11101 DABR2 Supervisor
560 10001 10000 IBAT4U Supervisor
561 10001 10001 IBAT4L Supervisor
562 10001 10010 IBAT5U Supervisor
563 10001 10011 IBAT5L Supervisor
564 10001 10100 IBAT6U Supervisor
565 10001 10101 IBAT6L Supervisor
566 10001 10110 IBAT7U Supervisor
567 10001 10111 IBAT7L Supervisor
568 10001 11000 DBAT4U Supervisor
569 10001 11001 DBAT4L Supervisor
570 10001 11010 DBAT5U Supervisor
571 10001 11011 DBAT5L Supervisor
572 10001 11100 DBAT6U Supervisor
573 10001 11101 DBAT6L Supervisor
574 10001 11110 DBAT7U Supervisor
575 10001 11111 DBAT7L Supervisor
976 11110 10000 DMISS Supervisor
977 11110 10001 DCMP Supervisor
978 11110 10010 HASH1 Supervisor
979 11110 10011 HASH2 Supervisor
980 11110 10100 IMISS Supervisor
981 11110 10101 ICMP Supervisor
982 11110 10110 RPA Supervisor
1008 11111 10000 HID0 Supervisor
1009 11111 10001 HID1 Supervisor
1010 11111 10010 IABR Supervisor
1011 11111 10011 HID2 Supervisor
1013 11111 10101 DABR Supervisor
1018 11111 11010 IABR2 Supervisor
------------------------------
我现在使用Sogou.com的2G邮箱了，你也来试试吧!
http://mail.sogou.com/recommend/sogoumail_invite_reg1.jsp?from=sogouinvitation&s_EMAIL=zengshuai%40sogou.com&username=linuxppc-embedded&FullName=linuxppc-embedded&Email=linuxppc-embedded%40ozlabs.org&verify=755eff4e640bdcfc57d93cbd8b0a9cb7
^ permalink raw reply
* RE: Booting hangs after "Calibrating delay loop..."
From: Nguyen Thanh Binh @ 2005-12-03 2:14 UTC (permalink / raw)
To: Autran, Guillaume; +Cc: 'linuxppc-embedded@ozlabs.org '
In-Reply-To: <19EE6EC66973A5408FBE4CB7772F6F0A2105B5@ltnmail.xyplex.com>
Hi Guillaume,
Thanks for replying.
I have did that but I did not work. I am using Monta
Vista Linux (kernel 2.4) on the Memec Virtex-4 FX12 LC
board.
Best Regards,
Binh
--- "Autran, Guillaume" <gautran@mrv.com> wrote:
> Hi Binh Nguyen,
>
> m8xx_setup.c moved in the recent 2.6 kernels to the
> syslib directory. I am
> using the 2.6.14 and the external RTC works with the
> modification I gave
> you.
>
> The only other thing different is the initialization
> of the stamp variable
> in time.c
> I added the line: 'stamp = get_native_tbl();' right
> before
> 'last_jiffy_stamp(0) = tb_last_stamp = stamp;'
>
> That's all.
> Guillaume
>
Nguyễn Thanh Bình
___________________________________________________________
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
^ permalink raw reply
* RE: Booting hangs after "Calibrating delay loop..."
From: Nguyen Thanh Binh @ 2005-12-03 2:13 UTC (permalink / raw)
To: Autran, Guillaume; +Cc: 'linuxppc-embedded@ozlabs.org '
In-Reply-To: <19EE6EC66973A5408FBE4CB7772F6F0A2105B5@ltnmail.xyplex.com>
Hi Guillaume,
Thanks for replying.
I have did that but I did not work. I am using Monta
Vista Linux (kernel 2.4).
Best Regards,
Binh
--- "Autran, Guillaume" <gautran@mrv.com> wrote:
> Hi Binh Nguyen,
>
> m8xx_setup.c moved in the recent 2.6 kernels to the
> syslib directory. I am
> using the 2.6.14 and the external RTC works with the
> modification I gave
> you.
>
> The only other thing different is the initialization
> of the stamp variable
> in time.c
> I added the line: 'stamp = get_native_tbl();' right
> before
> 'last_jiffy_stamp(0) = tb_last_stamp = stamp;'
>
> That's all.
> Guillaume
>
Nguyễn Thanh Bình
___________________________________________________________
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
^ permalink raw reply
* RE: Xilinx_uartlite
From: T Ziomek @ 2005-12-03 1:02 UTC (permalink / raw)
To: Jaap de Jong; +Cc: linuxppc-embedded
In-Reply-To: <6915D0AE8B9047438F320B466AE30FDD324CCD@nvs0003.nedap.local>
On Thu, 1 Dec 2005, Jaap de Jong wrote:
>
> Thanks for your reply, but then I only get:
> Now booting the kernel
Well, I never see that exact text, plus it's hard to tell much from such a
short snippet. Could you provide a more complete transcript of your con-
sole output?
--
/"\ ASCII Ribbon Campaign |
\ / | Email to user 'CTZ001'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
^ permalink raw reply
* Re: AmigaOne 2.6.x Linux kernel port
From: Benjamin Herrenschmidt @ 2005-12-02 21:56 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <4885.1133513163@www38.gmx.net>
On Fri, 2005-12-02 at 09:46 +0100, Gerhard Pircher wrote:
> > --- Ursprüngliche Nachricht ---
> > Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > An: Gerhard Pircher <gerhard_pircher@gmx.net>
> > Kopie: linuxppc-dev list <linuxppc-dev@ozlabs.org>,
> > debian-powerpc@lists.debian.org
> > Betreff: Re: AmigaOne 2.6.x Linux kernel port
> > Datum: Fri, 02 Dec 2005 10:58:55 +1100
> >
> > (I'm moving this to the linuxppc-dev list)
> >
> > Well, you need consistent alloc functions to really provide you with
> > non-cached memory. Fushing is not enough. Flushing is fine for dma_map
> > etc..., not for consistent alloc.
> >
> > So in theory, you should be able to re-use the existing consistent
> > allocation functions, except that the current implementation has
> > "issues":
> Well, as far as I could understand the code, you need to define a start and
> end address for the consistent memory, but as all the memory is managed by
> the kernel, it's not possible to do this (I hope that I don't write nonsense
> here ;-) ).
Nah, those are virtual addresses, they are defined in .config, the
default ones might just work.
> > I understand this is probably done to keep the TLB miss handler for the
> > kernel mapping as fast as possible. Unfortunately, it's also incorrect
> > if your processor is capable of any kind of prefetching accross a 4k
> > boundary.
>
> Well, the processor is a normal G3/G4 desktop CPU...
I know and that's a problem.
> Okay, I think reserving memory outside of the BAT mapping, is the approach
> that is used in the arch/ppc/kernel/dma-mapping.c file. There you should
> define a consistent memory area (by it's start and end address), which is
> used for non-coherent DMA memory allocations, right? But as that isn't
> possible on the AmigaOne, we have to go the hard way.
No. This area is only used for virtual space allocation. Actual physical
pages are picked up anywhere using the page allocator.
> Well, after all the performance of the AmigaOne isn't that good (but
> acceptable) due to the ArticiaS northbridge, but I think it's more important
> to fix the real problem than doing a lot of workarounds. I'm going to study
> now the processor docs, otherwise I won't understand not even a single bit
> of the kernel code. :-)
The real problem is the northbridge being crap.
Ben.
^ permalink raw reply
* Re: [PATCH 2.6.15-rc4] ppc32: Fixes for non-zero PPC_MEMSTART on PPC440
From: Josh Boyer @ 2005-12-02 21:14 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: linuxppc-embedded
In-Reply-To: <20051202080711.GA32759@obsidianresearch.com>
On Fri, 2005-12-02 at 01:07 -0700, Jason Gunthorpe wrote:
> I have a custom embedded system with a 440GP derived CPU that places the
> memory starting at 0xc0000000 which requires a non-zero PPC_MEMSTART. There
> are a couple of places that assume PPC_MEMSTART is 0. This results in
> various tricky crashing during booting. Most of the problems are
> not accounting for PPC_MEMSTART during va/pa translations. My fixes
> convert these places to use pre-existing macros instead of duplicating
> the calculation.
>
> The two items in head_4xx.S are critical, but I can't see a good way
> to link them in without an #ifdef, or maybe a CONFIG_* symbol. The
> alternate version of the tlb index picker will work for any platform,
> but is based on 'random' selection of the tlb index using the timebase
> rather than linear increment. I don't know if this is better, but it
> is an easy way to skip the problematic memory reference.
Shouldn't your board be using head_44x.S?
/me is confused...
josh
^ permalink raw reply
* Re: INTERACTIVE_CONSOLE for misc-embedded.c and watchdog issue
From: Marcelo Tosatti @ 2005-12-02 18:24 UTC (permalink / raw)
To: Tom Rini; +Cc: linux-ppc-embedded
In-Reply-To: <20051128232738.GE7766@smtp.west.cox.net>
Hi Tom,
On Mon, Nov 28, 2005 at 04:27:38PM -0700, Tom Rini wrote:
> On Thu, Nov 17, 2005 at 01:17:30PM -0200, Marcelo Tosatti wrote:
>
> > The following patch against misc-embedded.c adds an INTERACTIVE_CONSOLE
> > #define to guard reading from console (causes unecessary delay in some
> > situations).
> >
> > Its an adaptation of misc.c's define, a difference being that platform
> > headers define "NO_INTERACTIVE_CONSOLE" if required.
> >
> > What do you think?
>
> Please put a comment above the #ifndef stating where the define should
> be. But I have a feeling that's going to be somewhere under
> arch/ppc/platforms/ or include/asm-ppc/ and I don't know if that's a
> good idea...
arch/ppc/platforms/ surely. You have a problem with that?
> I've got a vauge idea on how we can handle this a little bit more
> cleanly, in the merge tree.
How's that? Should I cancel the patch, then?
^ permalink raw reply
* Re: PowerBook5,8 - TrackPad update
From: Parag Warudkar @ 2005-12-02 17:02 UTC (permalink / raw)
To: Stelian Pop, Michael Hanselmann
Cc: linuxppc-dev, johannes, debian-powerpc, linux-kernel
My original patch is still work in progress and was intended as a starting point if someone was already adept with the trackpad stuff and was willing to help.
(Basically it was a call for help - nothing for end users ;)
Things that remained to be done -
Either
1) Support for all PowerBooks in one code base (> Feb 2005)
Or
1) Create different versions for each one or two of them
Depending upon whether or not widely varying algorithms are needed for each variety.
2) Major part - reliably working code for finger movement detection for all Oct 2005 PowerBooks (15" itself seems to come with trackpads having entirely different characteristics.)
3) Possibly Dual Finger Detection for scrolling - this is optional but would be good to have.
I am working on it as time and urges permit and it will speed up only if Johannes doesn't get his PowerBook or the one he gets is 0x0216 !!
Parag
^ permalink raw reply
* ieee1394, Denx 3.1 (2.4.25+), PPC
From: Jeff Angielski @ 2005-12-02 16:14 UTC (permalink / raw)
To: linuxppc-embedded
Has anybody out there gotten this combination of hardware and software
to work?
I am trying to figure out if this is a problem with my particular
system/configuration or inherent in the current software baseline. The
problem is that while all software loads and runs without error, I am
unable to detect any devices/nodes on the IEEE1394 bus.
Thanks,
Jeff Angielski
The PTR Group
Some details for those not faint of heart...
Custom MPC826x board
EKF CYMBAL cPCI adapter
LACIE 250GB external HD
u-boot 1.1.3
Denx 3.1 - 2.4.25+
Latest ieee1394 Linux 2.4 SVN snapshot from http://www.linux1394.org/
Command sequence:
insmod ieee1394.o
insmod ohci1394.o
insmod raw1394.o
insmod sbp2.o
testlibraw
rescan-scsi-bus.sh
Output in /var/log/messages
ohci1394: $Rev: 1286 $ Ben Collins <bcollins@debian.org>
ohci1394_0: Remapped memory spaces reg 0xc90a6800
ohci1394_0: Soft reset finished
ohci1394_0: Iso contexts reg: 000000a8 implemented: 0000000f
ohci1394_0: 4 iso receive contexts available
ohci1394_0: Iso contexts reg: 00000098 implemented: 000000ff
ohci1394_0: 8 iso transmit contexts available
ohci1394_0: GUID: 00c08802:00a41ca0
ohci1394_0: Receive DMA ctx=0 initialized
ohci1394_0: Receive DMA ctx=0 initialized
ohci1394_0: Transmit DMA ctx=0 initialized
ohci1394_0: Transmit DMA ctx=1 initialized
ohci1394_0: OHCI-1394 1.0 (PCI): IRQ=[66] MMIO=[bffff800-bfffffff] Max
Packet=[2048]
ohci1394_0: request csr_rom address: c5d78000
ieee1394: CSR: setting expire to 10, HZ=100
ohci1394_0: IntEvent: 00020000
ohci1394_0: irq_handler: Bus reset requested
ohci1394_0: Cancel request received
raw1394: /dev/raw1394 device initialized
ieee1394: sbp2: sbp2_module_init
sbp2: $Rev: 1227 $ Ben Collins <bcollins@debian.org>
ieee1394: sbp2: Driver forced to serialize I/O (serialize_io = 1)
raw1394:write_request called
raw1394:write_request called
scsi singledevice 0 0 0 0
scsi singledevice 0 0 0 1
scsi singledevice 0 0 0 2
scsi singledevice 0 0 0 3
scsi singledevice 0 0 0 4
scsi singledevice 0 0 0 5
scsi singledevice 0 0 0 6
scsi singledevice 0 0 0 7
Output from testlibraw:
successfully got handle
current generation number: 1
1 card(s) found
nodes on bus: 0, card name: ohci1394
using first card found: 0 nodes on bus, local ID is 0, IRM is 63
doing transactions with custom tag handler
using standard tag handler and synchronous calls
testing FCP monitoring on local node
testing config rom stuff
get_config_rom returned 0, romsize 64, rom_version 1
here are the first 10 quadlets:
0. quadlet: 0x04047381
1. quadlet: 0x31333934
2. quadlet: 0xe000a002
3. quadlet: 0x00c08802
4. quadlet: 0x00a41ca0
5. quadlet: 0x000323fb
6. quadlet: 0x03000000
7. quadlet: 0x81000002
8. quadlet: 0x0c0083c0
9. quadlet: 0x000603ab
update_config_rom returned 0
polling for leftover messages
^ permalink raw reply
* Re: back trace when a SIGSEGV
From: Wolfgang Denk @ 2005-12-02 15:35 UTC (permalink / raw)
To: Redondo Garcia, Roberto; +Cc: linuxppc-dev
In-Reply-To: <6A28467355D2AD478D1F51C479415AE77B47E9@MADTORMAIL.indra.es>
In message <6A28467355D2AD478D1F51C479415AE77B47E9@MADTORMAIL.indra.es> you wrote:
>
> I have a program that when it has been several hours running, it has a
> problem and falls and it produces a SIGSEGV. I would like to know to
> how debug this error, because I do not have ulimit for generate core
> dump o examine a back trace.
Run the program under control of a debugger (gdb, or - if you're on a
resource-limited target - gdbserver).
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Es ist nicht genug zu wissen, man muß auch anwenden; es ist nicht ge-
nug zu wollen, man muß auch tun. -- Goethe, Maximen und Reflexionen
^ permalink raw reply
* Re: CPU off power consumption
From: Giuliano Pochini @ 2005-12-02 15:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: LinuxPPC-dev
In-Reply-To: <1133146369.7768.170.camel@gaston>
On Mon, 28 Nov 2005, Benjamin Herrenschmidt wrote:
> No, I think CPUs that have not been started are held in a similar sleep
> loop in ROM. I don't see right away why there would be any power
> consumption difference unless some bug causing us to never actually call
> the sleep loop ....
Any hint on how to debug it ? Where is the code that enables/disables the
cpus ? Where is the sleep loop ?
--
Giuliano.
^ permalink raw reply
* Re: PowerBook5,8 - TrackPad update
From: Stelian Pop @ 2005-12-02 14:28 UTC (permalink / raw)
To: Michael Hanselmann
Cc: linuxppc-dev, johannes, debian-powerpc, linux-kernel,
Parag Warudkar
In-Reply-To: <20051130234653.GB15102@hansmi.ch>
Le jeudi 01 décembre 2005 à 00:46 +0100, Michael Hanselmann a écrit :
> On Wed, Nov 30, 2005 at 11:39:17PM +0100, Michael Hanselmann wrote:
> > The patch is attached for easier use.
>
> There was a mistake in it due to which the mouse button wouldn't work.
> Fixed in the now attached patch.
Is this version really working well on the new Powerbooks ? From what
I've seen in this thread there are still issues and it's still a work in
progress, so it may be too early to integrate the changes in the kernel.
Also, some other comments on the code itself:
+#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
+#include <linux/relayfs_fs.h>
+#endif
While the relayfs code is ok for debugging, I'm wondering if it should be left in the final version at all.
+ int is0215; /* is the device a 0x0215? */
No need for that, just use udev->descriptor.idProduct == 0x0215 (in a macro perhaps)
+ int overflowwarn; /* overflow warning printed? */
I would use a static variable in the case -OVERFLOW: block here.
+ dev->xy_cur[i++] = dev->data[19];
+ dev->xy_cur[i++] = dev->data[20];
+ dev->xy_cur[i++] = dev->data[22];
+ dev->xy_cur[i++] = dev->data[23];
There is obviously a pattern here:
for (i = 0; i < 15; i++)
dev->xy_cur[i] = dev->data[ 19 + (i * 3) / 2 ]
I'm wondering if the same formula doesn't apply for more X and Y sensors (like 16 X
and 16 Y sensors on the old Powerbooks, 26 for the 17" models)
+#if 0
+ /* Some debug code */
+ for (i = 0; i < dev->urb->actual_length; i++) {
+ printk("%2x,", (unsigned char)dev->data[i]);
+ }
+ printk("\n");
+#endif
Please dump that.
+ /* Prints the read values */
+ if (debug > 1) {
+ printk("appletouch: X=");
+ for (i = 0; i < 15; i++) {
+ printk("%2x,", (unsigned char)dev->xy_cur[i]);
+ }
+ printk(" Y=");
+ for (i = ATP_XSENSORS; i < (ATP_XSENSORS + (9 - 1)); i++) {
+ printk("%2x,", (unsigned char)dev->xy_cur[i]);
+ }
+ printk("\n");
+ }
What is the point in doing this since the dbg_dump is called a few lines
later ? Best is to modify dbg_dump to know about the new number of
sensors...
+ printk(KERN_INFO "appletouch: atp_probe found interrupt "
+ "in endpoint: %d\n", int_in_endpointAddr);
Why is this useful to know ?
+ if (dev->is0215) {
+ dev->datalen = 64;
+ } else {
+ dev->datalen = 81;
+ }
Braces are not needed here.
PS: please inline the patch instead of attaching it to the mail, it's
much more easy to quote it that way.
Stelian.
--
Stelian Pop <stelian@popies.net>
^ permalink raw reply
* Re: pq2_find_bridges hangs system
From: Vitaly Bordug @ 2005-12-02 14:55 UTC (permalink / raw)
To: Alex BASTOS; +Cc: linuxppc-embedded list
In-Reply-To: <1133534967.43905ef73521a@webmail.televes.com:443>
Alex,
please probe this. If it will not help, pq2ads_setup_pci should be digged for some board specifics.
Also, check if hose->set_cfg_type is 1 as done for ads8272.
-------- Original Message --------
Subject: [patch 01/34] ppc32: Fix incorrect PCI frequency value
Date: Thu, 01 Dec 2005 00:51:15 -0800
From: akpm@osdl.org
To: torvalds@osdl.org
CC: akpm@osdl.org, vbordug@ru.mvista.com, galak@kernel.crashing.org
From: Vitaly Bordug <vbordug@ru.mvista.com>
The time to wait after deasserting PCI_RST has been counted with incorrect
value - this patch fixes the issue.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
arch/ppc/syslib/m82xx_pci.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
diff -puN arch/ppc/syslib/m82xx_pci.c~ppc32-fix-incorrect-pci-frequency-value arch/ppc/syslib/m82xx_pci.c
--- devel/arch/ppc/syslib/m82xx_pci.c~ppc32-fix-incorrect-pci-frequency-value 2005-11-30 23:58:00.000000000 -0800
+++ devel-akpm/arch/ppc/syslib/m82xx_pci.c 2005-11-30 23:58:00.000000000 -0800
@@ -248,7 +248,8 @@ pq2ads_setup_pci(struct pci_controller *
pci_div = ( (sccr & SCCR_PCI_MODCK) ? 2 : 1) *
( ( (sccr & SCCR_PCIDF_MSK) >> SCCR_PCIDF_SHIFT) + 1);
freq = (uint)((2*binfo->bi_cpmfreq)/(pci_div));
- time = (int)666666/freq;
+ time = (int)66666666/freq;
+
/* due to PCI Local Bus spec, some devices needs to wait such a long
time after RST deassertion. More specifically, 0.508s for 66MHz & twice more for 33 */
printk("%s: The PCI bus is %d Mhz.\nWaiting %s after deasserting RST...\n",__FILE__,freq,
_
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: back trace when a SIGSEGV
From: Dustin Lang @ 2005-12-02 14:27 UTC (permalink / raw)
To: Redondo Garcia, Roberto; +Cc: linuxppc-dev
In-Reply-To: <6A28467355D2AD478D1F51C479415AE77B47E9@MADTORMAIL.indra.es>
Hi,
SIGSEGV (also known as a "segmentation fault" or "segfault") usually means
your program is doing something wrong like trying to dereference a null
pointer. (ie, int* x = NULL; *x = 42;). To track this down, you can use
"gdb" (the gnu debugger) - gnu.org. Another option is "valgrind" -
valgrind.org - there is a PowerPC port (thanks, Paul!).
However, this mailing list is for _development_ of the linux _kernel_ on
PowerPC. Your question is not about kernel development so it doesn't
belong here. (Unless you are sure that your program is correct and
somehow the kernel is unfairly giving you a segfault - which doesn't seem
to be the case, based on your message.) Find a mailing list or message
board about userspace programming and ask your question there.
Also, you should learn how to write a bug report. Go to google.com, type
in "how to write a bug report", and read the first ten results. (For
example: What program are you running? Something you wrote? What OS are
you using? Why do you think the SIGSEGV is something caused by someone
else's code and not your own? Why does it matter how long the program
runs before it crashes? Why didn't you type "debug" into google and see
what came up? (GDB is number 6! Come on, get with it!))
Happy debugging!
dustin.
> hello,
> I have a program that when it has been several hours running, it has a
> problem and falls and it produces a SIGSEGV. I would like to know to
> how debug this error, because I do not have ulimit for generate core
> dump o examine a back trace.
>
> thanks
^ permalink raw reply
* Re: pq2_find_bridges hangs system
From: Kalle Pokki @ 2005-12-02 14:09 UTC (permalink / raw)
To: Alex BASTOS; +Cc: linuxppc-embedded
In-Reply-To: <0IQV004GGIH0UG@mailstore1.hut-mail>
Alex BASTOS wrote:
>The Tranfer Error makes not many sense for me, as _TEA is pulled-up.
>Maybe the oops after that is caused by the bad call return point?
>
>
I remember using this to prevent machine check exceptions during the PCI
scan. This is in the beginning of the pciauto_bus_scan() function.
--- trunk/linux/arch/ppc/syslib/pci_auto.c (revision 127)
+++ trunk/linux/arch/ppc/syslib/pci_auto.c (revision 128)
@@ -382,6 +382,10 @@
unsigned short vid;
unsigned char header_type;
+
+ /* must ignore machine checks during scan */
+ *(volatile unsigned short *) 0xf0010888 &= ~0x0800;
+
/*
* Fetch our I/O and memory space upper boundaries used
* to allocated base addresses on this hose.
^ permalink raw reply
* Re: pq2_find_bridges hangs system
From: Alex BASTOS @ 2005-12-02 14:49 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded
In-Reply-To: <1133531801.4390529995cfa@webmail.televes.com:443>
Vitally,
Finally, more clever informacion from log_buf.
(...and sorry about previos uncomplete information)
<5>Linux version 2.6.15-rc2 (alebas@xxxx) (gcc version 3.3.2) #1 PREEMPT Fri Dec
2 12:22:09 CET 2005
<6>Televes xxxxxx
<4>arch/ppc/syslib/m82xx_pci.c: The PCI bus is 66666666 Mhz.
<4>Waiting 1 second after deasserting RST...
<4>Machine check in kernel mode.
<4>Caused by (from SRR1=41030): Transfer error ack signal
<4>Oops: machine check, sig: 7 [#1]
<4>PREEMPT
<4>NIP: C001150C LR: C0011530 SP: C01D1EA0 REGS: c01d1df0 TRAP: 0200 Not
tainted
<4>MSR: 00041030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
<4>TASK = c01a2ff8[0] 'swapper' THREAD: c01d0000
<4>Last syscall: 0
<6>GPR00: 000000FF C01D1EA0 C01A2FF8 00000000 00000008 F0010906 00000001
C01D1ED8
<6>GPR08: 00000001 00000002 00000800 F0010904 24008028 FFFFFFFF 03FFE000
00000000
<6>GPR16: 00000001 00000001 FFFFFFFF 007FFF00 03FF8CE8 00000000 00000003
03BCB578
<6>GPR24: 00000000 00000000 00000001 0000000E 00000008 C01D1ED8 C01EC2DC
C01FC000
<4>NIP [c001150c] indirect_read_config+0xe8/0x11c
<4>LR [c0011530] indirect_read_config+0x10c/0x11c
<4>Call trace:
<4> [c00c8fb4] pci_bus_read_config_byte+0x60/0xa8
<4> [c000a784] early_read_config_byte+0x30/0x44
<4> [c01dc04c] pciauto_bus_scan+0xac/0x298
<4> [c01dba00] pq2_find_bridges+0x184/0x1b0
<4> [c01db1a0] m8260_setup_arch+0x30/0x80
<4> [c01d8c2c] setup_arch+0x110/0x18c
<4> [c01d2544] start_kernel+0x34/0x1bc
<4> [000032bc] 0x32bc
<4>Oops: kernel access of bad area, sig: 11 [#2]
<4>PREEMPT
<4>NIP: C001196C LR: C0012940 SP: C01D1C70 REGS: c01d1bc0 TRAP: 0300 Not
tainted
<4>MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
<4>DAR: 00000000, DSISR: 20000000
<4>TASK = c01a2ff8[0] 'swapper' THREAD: c01d0000
<4>Last syscall: 0
<6>GPR00: 00010005 C01D1C70 C01A2FF8 C01A2FF8 00000000 00000001 C01ED8E0
00000000
<6>GPR08: 00000000 00000001 00000078 C01D0000 00000000 FFFFFFFF 03FFE000
00000000
<6>GPR16: 00000001 00000001 FFFFFFFF 007FFF00 03FF8CE8 00000000 00000003
C01F0000
<6>GPR24: C01F0000 00000000 00000001 0000000E C01EB09C 00000000 C01EDD20
C01A2FF8
<4>NIP [c001196c] dequeue_task+0x0/0x78
<4>LR [c0012940] scheduler_tick+0x244/0x3b0
<4>Call trace:
<4> [c002284c] update_process_times+0xa4/0x168
<4> [c0005bb4] timer_interrupt+0x90/0x25c
<4> [c0004a7c] ret_from_except+0x0/0x14
<4> [c0004d9c] die+0xa0/0xc4
<4> [c0004a30] ret_from_except_full+0x0/0x4c
<4> [c001150c] indirect_read_config+0xe8/0x11c
<4> [c00c8fb4] pci_bus_read_config_byte+0x60/0xa8
<4> [c000a784] early_read_config_byte+0x30/0x44
<4> [c01dc04c] pciauto_bus_scan+0xac/0x298
<4> [c01dba00] pq2_find_bridges+0x184/0x1b0
<4> [c01db1a0] m8260_setup_arch+0x30/0x80
<4> [c01d8c2c] setup_arch+0x110/0x18c
<4> [c01d2544] start_kernel+0x34/0x1bc
<4> [000032bc] 0x32bc
<0>Kernel panic - not syncing: Aiee, killing interrupt handler!
<4> <0>Rebooting in 180 seconds..
The Tranfer Error makes not many sense for me, as _TEA is pulled-up.
Maybe the oops after that is caused by the bad call return point?
Thanks,
Alex BASTOS
^ permalink raw reply
* Re: pq2_find_bridges hangs system
From: Alex BASTOS @ 2005-12-02 13:56 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded
In-Reply-To: <4390223C.8060103@ru.mvista.com>
Vitaly,
> >
> There are 2 indirect_read_config(), one for PCI9 case, and one for not.
> I guess you should have CONFIG_8260_PCI9 disabled.
>
> If config seems OK, pleas submit backtrace. As long as I can see, "proper"
> setup_indirect_pci has been moved over to arch/powerpc/sysdev/indirect_pci.c.
> Check it it is compiled/used.
>
Config file seems OK to me:
# CONFIG_CPCI690 is not set
CONFIG_PPC_INDIRECT_PCI=y
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCI_8260=y
# CONFIG_PCI_LEGACY_PROC is not set
# CONFIG_PCI_DEBUG is not set
# CONFIG_NET_PCI is not set
and indirect_pci from arch/powerpc is compiled and used ...
I have tested a bit more. The call trace would be:
[c01db170] m8260_setup_arch
[c01db87c] pq2_find_bridges
[c01dbfa0] pciauto_bus_scan
[c000a754] early_read_config_byte
[c00c8f54] pci_bus_read_config_byte
[c0011424] indirect_read_config
I have done manually, since GDB only reports last two,
and I couldn't get it from log_buf.
(gdb) bt
#0 indirect_read_config (bus=0x0, devfn=3223241436,
offset=8, len=14, val=0x1032)
at arch/powerpc/sysdev/indirect_pci.c:32
#1 0xc00c8fb4 in pci_bus_read_config_byte (bus=0xc01ec2dc,
devfn=8, pos=14, value=0xc01d1f3a "")
at drivers/pci/access.c:52
Now I have check indirect_read_config, and I have seen
the call ends itself, but after that it returns to
pci_bus_read_config_dword
executes some asm and then hangs.
Any idea?
Thanks,
Alex BASTOS
^ permalink raw reply
* back trace when a SIGSEGV
From: Redondo Garcia, Roberto @ 2005-12-02 10:33 UTC (permalink / raw)
To: linuxppc-dev
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 1457 bytes --]
hello,
I have a program that when it has been several hours running, it has a
problem and falls and it produces a SIGSEGV. I would like to know to
how debug this error, because I do not have ulimit for generate core
dump o examine a back trace.
thanks
-------------------------------------------------------------------------------------------------------------------
Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, contiene información de carácter confidencial exclusivamente dirigida a su destinatario o destinatarios. Queda prohibida su divulgación, copia o distribución a terceros sin la previa autorización escrita de Indra. En el caso de haber recibido este correo electrónico por error, se ruega notificar inmediatamente esta circunstancia mediante reenvío a la dirección electrónica del remitente. POR FAVOR, ANTES DE IMPRIMIR ESTE CORREO ELECTRÓNICO CONSIDERE SU APORTACIÓN A LA CONSERVACIÓN DEL MEDIO AMBIENTE POR LA REDUCCIÓN DE CONSUMO DE PAPEL.
The information in this e-mail and in any attachments is confidential and solely for the attention and use of the named addressee(s). You are hereby notified that any dissemination, distribution or copy of this communication is prohibited without the prior written consent of Indra. If you have received this communication in error, please, notify the sender by reply e-mail. PLEASE CONSIDER YOUR ENVIRONMENTAL RESPONSIBILITY BEFORE PRINTING THIS E-MAIL.
[-- Attachment #2: Type: text/html, Size: 2230 bytes --]
^ permalink raw reply
* Re: pq2_find_bridges hangs system
From: Vitaly Bordug @ 2005-12-02 10:30 UTC (permalink / raw)
To: Alex BASTOS; +Cc: linuxppc-embedded
In-Reply-To: <1133520697.4390273987a6a@webmail.televes.com:443>
Alex BASTOS wrote:
> Hi,
>
> I am working on a board with a MPC8248 based on ADS8272.
> Until now I was working with ppc kernel 2.6.11. Now, it's
> time to go up, so I am trying 2.6.15-rc2.
>
> Unfortunately, kernel hangs at boot-up, and with a BDI2000
> I have reached the pq2_find_bridges() call, more precisely,
> in indirect_read_config(). Now I am a bit lost, as I have
> almos any knowledge about PCI.
>
> The board doesn't need PCI support at all, but I need it
> active on kernel as it is required by USB HCD stack.
>
> I have tested this on the ADS8272 and i doesn't happends,
> so, any clue.
>
> And, has the indirect_read_config any to do with the PCI9
> workaround, which is supposed to be corrected on HIP7
> devices?
>
There are 2 indirect_read_config(), one for PCI9 case, and one for not.
I guess you should have CONFIG_8260_PCI9 disabled.
If config seems OK, pleas submit backtrace. As long as I can see, "proper" setup_indirect_pci has been moved over to arch/powerpc/sysdev/indirect_pci.c.
Check it it is compiled/used.
> Thanks in advance.
>
> Alex BASTOS
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* pq2_find_bridges hangs system
From: Alex BASTOS @ 2005-12-02 10:51 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am working on a board with a MPC8248 based on ADS8272.
Until now I was working with ppc kernel 2.6.11. Now, it's
time to go up, so I am trying 2.6.15-rc2.
Unfortunately, kernel hangs at boot-up, and with a BDI2000
I have reached the pq2_find_bridges() call, more precisely,
in indirect_read_config(). Now I am a bit lost, as I have
almos any knowledge about PCI.
The board doesn't need PCI support at all, but I need it
active on kernel as it is required by USB HCD stack.
I have tested this on the ADS8272 and i doesn't happends,
so, any clue.
And, has the indirect_read_config any to do with the PCI9
workaround, which is supposed to be corrected on HIP7
devices?
Thanks in advance.
Alex BASTOS
^ permalink raw reply
* [PATCH] ppc32: remove "jumbo" member from ocp_func_emac_data
From: Eugene Surovegin @ 2005-12-02 9:12 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-embedded
This patch removes not needed anymore "jumbo" member from
ocp_func_emac_data. Jumbo frame support is handled by PPC4xx EMAC
driver internally now.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
---
arch/ppc/platforms/4xx/ibm440gx.c | 2 --
arch/ppc/platforms/4xx/ibm440sp.c | 1 -
include/asm-ppc/ibm_ocp.h | 1 -
3 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/ppc/platforms/4xx/ibm440gx.c b/arch/ppc/platforms/4xx/ibm440gx.c
index 956f45e..d24c09e 100644
--- a/arch/ppc/platforms/4xx/ibm440gx.c
+++ b/arch/ppc/platforms/4xx/ibm440gx.c
@@ -58,7 +58,6 @@ static struct ocp_func_emac_data ibm440g
.wol_irq = 65, /* WOL interrupt number */
.mdio_idx = -1, /* No shared MDIO */
.tah_idx = 0, /* TAH device index */
- .jumbo = 1, /* Jumbo frames supported */
};
static struct ocp_func_emac_data ibm440gx_emac3_def = {
@@ -72,7 +71,6 @@ static struct ocp_func_emac_data ibm440g
.wol_irq = 67, /* WOL interrupt number */
.mdio_idx = -1, /* No shared MDIO */
.tah_idx = 1, /* TAH device index */
- .jumbo = 1, /* Jumbo frames supported */
};
OCP_SYSFS_EMAC_DATA()
diff --git a/arch/ppc/platforms/4xx/ibm440sp.c b/arch/ppc/platforms/4xx/ibm440sp.c
index feb17e4..71a0117 100644
--- a/arch/ppc/platforms/4xx/ibm440sp.c
+++ b/arch/ppc/platforms/4xx/ibm440sp.c
@@ -31,7 +31,6 @@ static struct ocp_func_emac_data ibm440s
.wol_irq = 61, /* WOL interrupt number */
.mdio_idx = -1, /* No shared MDIO */
.tah_idx = -1, /* No TAH */
- .jumbo = 1, /* Jumbo frames supported */
};
OCP_SYSFS_EMAC_DATA()
diff --git a/include/asm-ppc/ibm_ocp.h b/include/asm-ppc/ibm_ocp.h
index 9c21de1..ddce616 100644
--- a/include/asm-ppc/ibm_ocp.h
+++ b/include/asm-ppc/ibm_ocp.h
@@ -63,7 +63,6 @@ struct ocp_func_emac_data {
int wol_irq; /* WOL interrupt */
int mdio_idx; /* EMAC idx of MDIO master or -1 */
int tah_idx; /* TAH device index or -1 */
- int jumbo; /* Jumbo frames capable flag */
int phy_mode; /* PHY type or configurable mode */
u8 mac_addr[6]; /* EMAC mac address */
u32 phy_map; /* EMAC phy map */
^ permalink raw reply related
* I want to A maillist about ppclinux
From: licongyong @ 2005-12-02 5:29 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 7 bytes --]
thanks!
[-- Attachment #2: Type: text/html, Size: 305 bytes --]
^ permalink raw reply
* Re: AmigaOne 2.6.x Linux kernel port
From: Gerhard Pircher @ 2005-12-02 8:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1133481536.6100.32.camel@gaston>
> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> Kopie: linuxppc-dev list <linuxppc-dev@ozlabs.org>,
> debian-powerpc@lists.debian.org
> Betreff: Re: AmigaOne 2.6.x Linux kernel port
> Datum: Fri, 02 Dec 2005 10:58:55 +1100
>
> (I'm moving this to the linuxppc-dev list)
>
> Well, you need consistent alloc functions to really provide you with
> non-cached memory. Fushing is not enough. Flushing is fine for dma_map
> etc..., not for consistent alloc.
>
> So in theory, you should be able to re-use the existing consistent
> allocation functions, except that the current implementation has
> "issues":
Well, as far as I could understand the code, you need to define a start and
end address for the consistent memory, but as all the memory is managed by
the kernel, it's not possible to do this (I hope that I don't write nonsense
here ;-) ).
> The main problem I see with the implementation is that it just allocates
> pages out of the normal kernel allocator and maps them in the
> "consistent" virtual range without ever unmapping them from the kernel
> linear mapping. That means that those pages end up being mapped twice:
> cacheable and non-cacheable, which is absolutely wrong and will explode
> in colorful ways on a number of CPUs. The pages should at least be
> unmapped from the kernel linear (& cacheable) mapping.
>
> I understand this is probably done to keep the TLB miss handler for the
> kernel mapping as fast as possible. Unfortunately, it's also incorrect
> if your processor is capable of any kind of prefetching accross a 4k
> boundary.
Well, the processor is a normal G3/G4 desktop CPU...
> Then, remains the BAT mapping problem. In order to improve performances,
> the kernel uses BATs to map the main memory (to know more about BATs,
> look at the proccessor docs). That means that unmapping the memory from
> the linear mapping will not work if that memory happens to be covered by
> a BAT (there aren't even page tables entries for those pages anyway).
> Thus, in order to be able to reliably unmap things from the linear
> mapping (or individually change page attributes) you need to disable BAT
> mapping of memory, either completely, or by preallocating (and thus
> actually reserving) memory outside of the BAT mapping for use in the
> consistent allocator.
Okay, I think reserving memory outside of the BAT mapping, is the approach
that is used in the arch/ppc/kernel/dma-mapping.c file. There you should
define a consistent memory area (by it's start and end address), which is
used for non-coherent DMA memory allocations, right? But as that isn't
possible on the AmigaOne, we have to go the hard way.
> However, the exception handling of the kernel is designed with the
> assumption that it will not take hash faults in some critical locations,
> and this assumption is correct thanks to ... the BAT mapping. You are
> lucky though that recent kernels have been fixed to be able to recover
> from such faults provided the instructions are still BAT mapped, so you
> can probably hack the initialisation of the memory on ppc to not use
> data BATs but only instruction BATs and still create the page tables for
> the entire memory. That will allow you to implement proper unmapping of
> pages in the consistent allocator. However, it will also impact your
> overall performances ...
Well, after all the performance of the AmigaOne isn't that good (but
acceptable) due to the ArticiaS northbridge, but I think it's more important
to fix the real problem than doing a lot of workarounds. I'm going to study
now the processor docs, otherwise I won't understand not even a single bit
of the kernel code. :-)
Thanks again!
Gerhard
--
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
^ permalink raw reply
* Re: Can I operate i2c device in a tasklet?
From: Eugene Surovegin @ 2005-12-02 8:45 UTC (permalink / raw)
To: Sam Song; +Cc: linuxppc-embedded
In-Reply-To: <20051202062007.52513.qmail@web15804.mail.cnb.yahoo.com>
On Fri, Dec 02, 2005 at 02:20:07PM +0800, Sam Song wrote:
> Hi all,
>
> I found that once I operated i2c bus like
> read from i2c device in 2.4.31 kernl in a
> interrupt handler or tasklet, kernel panic
> would happen. Is there any way to make it
> in such case? I need to write sth on RTC
> alarm register with an interrupt event.
>
> ......
> Scheduling in interrupt
> kernel BUG at sched.c:564!
You cannot access i2c layer from non-process context. Please, search
mail list archives, this matter was discussed countless number of
times.
--
Eugene
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox