* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Jeff Garzik @ 2006-05-18 15:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Alexandre.Bounine, linuxppc-dev list, linux-kernel, linux-ide,
Paul Mackerras, Yang Xin-Xin-r48390
In-Reply-To: <1147935734.17679.93.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> On Thu, 2006-05-18 at 12:03 +0800, Zang Roy-r61911 wrote:
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: 2006年5月17日 21:28
>> To: Zang Roy-r61911
>> Cc: Paul Mackerras; linuxppc-dev list; Alexandre.Bounine@tundra.com; Yang Xin-Xin-r48390
>> Subject: Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerpc pl atform
>
> Copying here the comments I already made so Jeff gets them...
>
>> @@ -1032,6 +1032,9 @@ static inline void mv_crqb_pack_cmd(u16
>> {
>> *cmdw = data | (addr << CRQB_CMD_ADDR_SHIFT) | CRQB_CMD_CS |
>> (last ? CRQB_CMD_LAST : 0);
>> +#ifdef CONFIG_PPC
>> + *cmdw = cpu_to_le16(*cmdw);
>> +#endif
>> }
>
> Why an ifdef here ? The cpu_to_le16 should probably be unconditional.
> And even if for some weird reason you wanted to ifdef it, why PPC ? and
> what about other BE architectures ?
>
>> /**
>> @@ -1567,13 +1570,18 @@ static void mv5_read_preamp(struct mv_ho
>> static void mv5_enable_leds(struct mv_host_priv *hpriv, void __iomem
> *mmio)
>> {
>> u32 tmp;
>> -
>> +#ifndef CONFIG_PPC
>> writel(0, mmio + MV_GPIO_PORT_CTL);
>> +#endif
>
> You'll have to do better here too... I don't wee why when compiled on
> PPC, this driver should "magically" not clear those bits... At the very
> least, you should test the machine type if you want to do something
> specific to your platform, but first, you'll have to convince Jeff why
> this change has to be done in the first place and if there is a better
> way to handle it.
Correct... it does seem some bugs were found, but #ifdef powerpc is
certainly out of the question. We want the driver to work without
ifdefs on all platforms.
Jeff
^ permalink raw reply
* Re: [PATCH][resend] udbg_printf() formatting attribute
From: Michael Ellerman @ 2006-05-18 15:56 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev
In-Reply-To: <34FAC3E5-F717-4640-B094-312C8773852E@watson.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]
On Thu, 2006-05-18 at 08:22 -0400, Jimi Xenidis wrote:
> On May 17, 2006, at 7:36 PM, Michael Ellerman wrote:
>
> > On Wed, 2006-05-17 at 12:00 -0400, jimix@watson.ibm.com wrote:
> >> - pr_debug("%s: current_entitled = %lu, current_weight = %lu\n",
> >> + pr_debug("%s: current_entitled = %lu, current_weight = %u\n",
> >> __FUNCTION__, current_entitled, current_weight);
> >>
> >> - pr_debug("%s: new_entitled = %lu, new_weight = %lu\n",
> >> + pr_debug("%s: new_entitled = %lu, new_weight = %u\n",
> >> __FUNCTION__, *new_entitled_ptr, *new_weight_ptr);
> >
> > But pr_debug() calls printk, not udbg_printf() ?
>
> Now _thats_ funny!
> Then I'm so happy to have found and fixed this compiler warning :)
Haha, nice one Jimi :D
> >> -extern void udbg_printf(const char *fmt, ...);
> >> +extern void udbg_printf(const char *fmt, ...)
> >> + __attribute__ ((format (printf, 1, 2)));
>
> I believe this chunk is still goodness as it will catch format issues
> for developers.
I'm actually hoping to get rid of udbg_printf(), but if I can't we
should stick this in I guess. The real problem IMHO is that debug
printks rot because they're rarely compiled, not sure what to do about
that.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* MPC8xx: resolution of gettimeofday() ?
From: Steven Scholz @ 2006-05-18 15:10 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
what is the resolution of gettimeofday() for an MPC8xx?
IIUC then the "decrementer" is used to generate the timer interrupts every 10ms.
This decrementer runs at cpuclk/16. Thus with 80MHz CPU clock has a
resolution of 16/80MHz = 200ns and overflows every 50000 ticks.
But is this decrementer used to update xtime?
Will gettimeofday() have a resolution of 200ns?
How about linux 2.4 where xtime is a "struct timeval" rather then "struct
timespec"?
This trivial test programm
struct timeval first, next;
double diff;
gettimeofday(&first, NULL);
do {
gettimeofday(&next, NULL);
} while (first.tv_usec == next.tv_usec &&
first.tv_sec == next.tv_sec);
diff = ((double) next.tv_sec - (double) first.tv_sec) * 1e6;
diff += (double) (next.tv_usec - first.tv_usec);
printf ("Resolution gettimeofday() = %g µs\n", diff);
says it's between 13 - 16 µs on a linux-2.4.20. Could that be? how does this
relate to the decrementer frequency?
Thanks a million!
--
Steven
^ permalink raw reply
* [RFD] Hugetlb: Allowing hugetlb regions to be closed
From: Adam Litke @ 2006-05-18 15:23 UTC (permalink / raw)
To: linuxppc-dev; +Cc: libhugetlbfs-devel
Please correct me if I am wrong in any of the following...
On powerpc, once a region of the address space has been 'opened' for use
with hugetlb pages this region can never again contain normal pages for
the remaining life of the process -- even if all hugetlb mappings have
been unmapped from this region.
The above approach is nice and simple, but a bit restrictive too. Would
people be opposed to a patch which provides methods for closing low/high
hugetlb areas and logic in arch_get_unmapped_area() to perform the
closing? My thought would be to try closing only in the full_search:
case (so the fast path is left untouched.
As for why I want this... I have an application (libhugetlbfs), which
provides hugetlb pages to applications in an abstracted manner. There
are situations where the library creates a hugetlb area and needs to
later replace it with normal pages. The main case this will happen is
for a hugetlb-backed malloc area.
Thoughts?
--
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center
^ permalink raw reply
* MPC8xx USB SOF microcode patch
From: Josef Angermeier @ 2006-05-18 14:32 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am using linux 2.6.15 and try to get the MPC875 USB controller
working. I just checked if the microcode patch in
arch/ppc/8xx_io/micropatch.c for CONFIG_USB_SOF_UCODE_PATCH set
corresponds with the newest microcode patch for mpc8xx, downloadable
from freescale: They differ slighly, is it an older (working) version or
where is it from ?
ciao
josef
^ permalink raw reply
* Re: About BDI2000 and mpc8247
From: Mark Chambers @ 2006-05-18 14:22 UTC (permalink / raw)
To: Gosiuua, linuxppc-embedded
In-Reply-To: <ee10e9f40605180656q58f989bcg562b48d765afdba5@mail.gmail.com>
> Hello List..
>
> i have a develop board based on mpc8247. It has no eeprom to restore
> hareware configure word and i have to use default config word
> 0x00000000.
> my bdi config file:
>
<snip>
> - Waiting for target stop failed
> - TARGET: Break at boot vector failed, freeze forced
> /*****/
>
>
> BDI can't bread the CPU and i don't know what can i do!
> Any one can help me?
> _______________________________________________
I have had the same issue. You need lines similar to the following
in your bdi config file to stop the watchdog timer. Then you will
need other lines to set various registers to match your hardware
bus widths, etc.
[INIT]
; init core register
WREG MSR 0x00001042 ;MSR : ME,RI, exceptions high
WM32 0x000101a8 0xf0000000 ;move internal space
WM32 0xf0010004 0xFFFFFFC1 ;SYPCR: disable watchdog
Mark C.
^ permalink raw reply
* Re: About BDI2000 and mpc8247
From: Laurent Pinchart @ 2006-05-18 14:12 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Gosiuua
In-Reply-To: <ee10e9f40605180656q58f989bcg562b48d765afdba5@mail.gmail.com>
> i have a develop board based on mpc8247. It has no eeprom to restore
> hareware configure word and i have to use default config word
> 0x00000000.
> my bdi config file:
[...]
You should tell the BDI to initialize the SYPCR register, otherwise the
internal watchdog timer will keep resetting the CPU.
[INIT]
; *** Initialize the core internal registers
; Program the SYPCR - Disable the watchdog timer
WM32 0xf0010004 0xffff2081
You will need to initiliaze other internal registers as well (BCR, SIUMCR,
BRx, ORx, ...).
I'm not sure if this will be enough to solve your problem, but it should at
least be a start.
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 0/10] powerpc: add mpc7448hpc2 (Taiga) board support
From: Kumar Gala @ 2006-05-18 14:08 UTC (permalink / raw)
To: Zang Roy-r61911
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Paul Mackerras,
Alexandre.Bounine
In-Reply-To: <9FCDBA58F226D911B202000BDBAD46730626D618@zch01exm40.ap.freescale.net>
On May 17, 2006, at 5:13 AM, Zang Roy-r61911 wrote:
> Hi, Paul
>
> This series of patch adds mpc7448hpc2 (taiga) board support in
> arch/powerpc.
> Tsi108 chip of Tundra Semiconductor is also supported.
>
> Roy Zang
Can you post your .dts for us to take a look at. I know Mark Greer
is looking at support for the 105/6/7 family of bridges and the 10x
family should have consistent flat device trees.
- kumar
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Kumar Gala @ 2006-05-18 14:06 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, Alexandre.Bounine, Yang Xin-Xin-r48390
In-Reply-To: <17516.20191.490360.852876@cargo.ozlabs.ibm.com>
On May 18, 2006, at 5:39 AM, Paul Mackerras wrote:
> Zang Roy-r61911 writes:
>
>> I can migrate my code to embedded6xx technically. In fact,
>> I can move it into anywhere in the arch/powerpc/platforms.
>> While for mpc7448hpc2(taiga) board, it is not a embedded
>> application board. It is a high performance server! It seems
>> odd to put code there :). What's your opinion?
>
> What sort of machine(s) is this board used in? Or what machines will
> it be in?
Its a reference board from Freescale with a MPC7448 + TSI108.
Similar in concept to sandpoint.
- kumar
^ permalink raw reply
* About BDI2000 and mpc8247
From: Gosiuua @ 2006-05-18 13:56 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <ee10e9f40605180640g12a2671bo530c3ccbba8b3829@mail.gmail.com>
Hello List..
i have a develop board based on mpc8247. It has no eeprom to restore
hareware configure word and i have to use default config word
0x00000000.
my bdi config file:
[TARGET]
CPUTYPE 8270 ;the CPU type (603EV,750,8240,8260)
JTAGCLOCK 1 ;use 16 MHz JTAG clock
BOOTADDR 0xfff00100 ;boot address used for start-up break
WORKSPACE 0x00000000 ;workspace in target RAM for fast
download and data cache flushing
BDIMODE AGENT ;the BDI working mode (LOADONLY |
AGENT | GATEWAY)
BAUDRATE 115200 ;baudrate for gateway mode or
virtual IO
BREAKMODE SOFT ;<AGENT> SOFT or HARD, HARD uses PPC
hardware breakpoint
VECTOR CATCH ;<AGENT> catch unhandled exceptions
DCACHE NOFLUSH ;<AGENT> data cache flushing (FLUSH |
NOFLUSH)
MEMBASE 0 ;<AGENT> base of target memory
MEMSIZE 0x00004000 ;<AGENT> size of target memory, 64M
POOLBASE 0x00000000 ;<AGENT> base of host controlled target mem=
ory
POOLSIZE 0x00004000 ;<AGENT> size of host controlled
target memory
When i connect BDI2000(bdiwind_cop, firmware 1.13, logic 1.02 ) to
the board, the following messages
are printed, then it have no response!
/************************************************************/
- TARGET: processing power-up delay
- TARGET: processing user reset request
- BDI asserts HRESET
- Reset JTAG controller passed
- Bypass check: 0x55 =3D> 0xAA
- Bypass check: 0x55 =3D> 0xAA
- JTAG exists check passed
- Target PVR is 0x80822014
- Target SVR is 0x00000000
- COP status is 0x01
- Check running state passed
- BDI scans COP freeze command
- BDI removes HRESET
- COP status is 0x05
- Check stopped state passed
- Check LSRL length passed
- BDI sets breakpoint at 0xFFF00100
- BDI resumes program execution
- COP status is 0x01
- Waiting for target stop failed
- TARGET: Break at boot vector failed, freeze forced
- TARGET: Target PVR is 0x80822014
- TARGET: resetting target passed
- TARGET: processing target startup ....
/***/
When i set CPUTYPE to 8260, the following messages are printed continously=
:
/**************************************************************************=
****/
- TARGET: processing power-up delay
- TARGET: processing user reset request
- BDI asserts HRESET
- Reset JTAG controller passed
- Bypass check: 0x55 =3D> 0xAA
- Bypass check: 0x55 =3D> 0xAA
- JTAG exists check passed
- Target PVR is 0x80822014
- COP status is 0x01
- Check running state passed
- BDI scans COP freeze command
- BDI removes HRESET
- COP status is 0x05
- Check stopped state passed
- Check LSRL length passed
- BDI sets breakpoint at 0xFFF00100
- BDI resumes program execution
- COP status is 0x01
- Waiting for target stop failed
- TARGET: Break at boot vector failed, freeze forced
- TARGET: Target PVR is 0x80822014
- TARGET: resetting target passed
- TARGET: processing target startup ....
- TARGET: processing target startup passed
*** TARGET: reset detected, restarting target
- BDI asserts HRESET
- Reset JTAG controller passed
- Bypass check: 0x55 =3D> 0xAA
- Bypass check: 0x55 =3D> 0xAA
- JTAG exists check passed
- Target PVR is 0x80822014
- COP status is 0x01
- Check running state passed
- BDI scans COP freeze command
- BDI removes HRESET
- COP status is 0x05
- Check stopped state passed
- Check LSRL length passed
- BDI sets breakpoint at 0xFFF00100
- BDI resumes program execution
- COP status is 0x01
- Waiting for target stop failed
- TARGET: Break at boot vector failed, freeze forced
/*****/
BDI can't bread the CPU and i don't know what can i do!
Any one can help me?
^ permalink raw reply
* Re: [HACK] add sandpoint + flattened dt support to arch/powerpc/boot
From: Matthew McClintock @ 2006-05-18 13:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1147930376.17679.72.camel@localhost.localdomain>
Do you have any comments about how you envision updating the "virtual"
mode image with information passed from the boot loader? I am asking
this from the standpoint of updating the "virtual" flat tree with
correct values, in order to boot from older firmware.
-Matthew
On Thu, 2006-05-18 at 15:32 +1000, Benjamin Herrenschmidt wrote:
> That is why, I think, what we should do is have rules for building
> separate zImage wrappers. The basic OF one (which exists in both real
> and virtual mode versions and that I'd like to make capable of also
> working if a flat device-tree is passed in), the zImage.sandpoint, the
> zImage.prep, and whatever...
>
^ permalink raw reply
* Re: [HACK] add sandpoint + flattened dt support to arch/powerpc/boot
From: Matthew McClintock @ 2006-05-18 13:47 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060518002142.GA23182@mag.az.mvista.com>
On Wed, 2006-05-17 at 17:21 -0700, Mark A. Greer wrote:
> +void *
> +dt_find_prop_by_name(void *dt_blob, char *full_name, u32 *val_sizep)
Is there a reason you are not using of_get_flat_dt_prop() instead of
implementing your own version?
-Matthew
^ permalink raw reply
* Re: [PATCH] dtc: add setting of physical boot cpu
From: Jimi Xenidis @ 2006-05-18 13:23 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev
In-Reply-To: <20060518035734.2B2CA67A6D@ozlabs.org>
Hey Michael, a few questions:
How does this interact with "linux,boot-cpu"?
If -b is defined then the absence of "linux,boot-cpu" should no
longer cause a warning.
Perhaps if -b is missing the header value is set from "linux,boot-
cpu" property?
Should we extend the "linux,boot-cpu" to actually contain a thread-id
or are we deprecating this prop?
-JX
On May 17, 2006, at 11:56 PM, Michael Neuling wrote:
> dtc always sets the physical boot CPU to 0xfeedbeef. Add a -b
> option to
> set this.
>
> ---
> I've tested the blob output but not asm output.
>
> ---
> dtc.c | 12 +++++++++---
> dtc.h | 6 ++++--
> flattree.c | 16 ++++++++++------
> 3 files changed, 23 insertions(+), 11 deletions(-)
>
> Index: dtc/dtc.c
> ===================================================================
> --- dtc.orig/dtc.c
> +++ dtc/dtc.c
> @@ -95,6 +95,8 @@ static void usage(void)
> fprintf(stderr, "\t\tBlob version to produce, defaults to 3
> (relevant for dtb\n\t\tand asm output only)\n");
> fprintf(stderr, "\t-R <number>\n");
> fprintf(stderr, "\t\tMake space for <number> reserve map entries
> (relevant for \n\t\tdtb and asm output only)\n");
> + fprintf(stderr, "\t-b <number>\n");
> + fprintf(stderr, "\t\tSet the physical boot cpu\n");
> fprintf(stderr, "\t-f\n");
> fprintf(stderr, "\t\tForce - try to produce output even if the
> input tree has errors\n");
> exit(2);
> @@ -113,8 +115,9 @@ int main(int argc, char *argv[])
> FILE *outf = NULL;
> int outversion = 3;
> int reservenum = 1;
> + int boot_cpuid_phys = 0xfeedbeef;
>
> - while ((opt = getopt(argc, argv, "I:O:o:V:R:f")) != EOF) {
> + while ((opt = getopt(argc, argv, "I:O:o:V:R:fb:")) != EOF) {
> switch (opt) {
> case 'I':
> inform = optarg;
> @@ -134,6 +137,9 @@ int main(int argc, char *argv[])
> case 'f':
> force = 1;
> break;
> + case 'b':
> + boot_cpuid_phys = strtol(optarg, NULL, 0);
> + break;
> default:
> usage();
> }
> @@ -185,9 +191,9 @@ int main(int argc, char *argv[])
> if (streq(outform, "dts")) {
> dt_to_source(outf, bi);
> } else if (streq(outform, "dtb")) {
> - dt_to_blob(outf, bi, outversion);
> + dt_to_blob(outf, bi, outversion, boot_cpuid_phys);
> } else if (streq(outform, "asm")) {
> - dt_to_asm(outf, bi, outversion);
> + dt_to_asm(outf, bi, outversion, boot_cpuid_phys);
> } else if (streq(outform, "null")) {
> /* do nothing */
> } else {
> Index: dtc/dtc.h
> ===================================================================
> --- dtc.orig/dtc.h
> +++ dtc/dtc.h
> @@ -207,8 +207,10 @@ struct boot_info *build_boot_info(struct
>
> /* Flattened trees */
>
> -void dt_to_blob(FILE *f, struct boot_info *bi, int version);
> -void dt_to_asm(FILE *f, struct boot_info *bi, int version);
> +void dt_to_blob(FILE *f, struct boot_info *bi, int version,
> + int boot_cpuid_phys);
> +void dt_to_asm(FILE *f, struct boot_info *bi, int version,
> + int boot_cpuid_phys);
>
> struct boot_info *dt_from_blob(FILE *f);
>
> Index: dtc/flattree.c
> ===================================================================
> --- dtc.orig/flattree.c
> +++ dtc/flattree.c
> @@ -301,7 +301,8 @@ static struct data flatten_reserve_list(
> }
> static void make_bph(struct boot_param_header *bph,
> struct version_info *vi,
> - int reservesize, int dtsize, int strsize)
> + int reservesize, int dtsize, int strsize,
> + int boot_cpuid_phys)
> {
> int reserve_off;
>
> @@ -324,12 +325,13 @@ static void make_bph(struct boot_param_h
> + dtsize + strsize);
>
> if (vi->flags & FTF_BOOTCPUID)
> - bph->boot_cpuid_phys = 0xfeedbeef;
> + bph->boot_cpuid_phys = cpu_to_be32(boot_cpuid_phys);
> if (vi->flags & FTF_STRTABSIZE)
> bph->size_dt_strings = cpu_to_be32(strsize);
> }
>
> -void dt_to_blob(FILE *f, struct boot_info *bi, int version)
> +void dt_to_blob(FILE *f, struct boot_info *bi, int version,
> + int boot_cpuid_phys)
> {
> struct version_info *vi = NULL;
> int i;
> @@ -355,7 +357,8 @@ void dt_to_blob(FILE *f, struct boot_inf
> reservebuf = flatten_reserve_list(bi->reservelist, vi);
>
> /* Make header */
> - make_bph(&bph, vi, reservebuf.len, dtbuf.len, strbuf.len);
> + make_bph(&bph, vi, reservebuf.len, dtbuf.len, strbuf.len,
> + boot_cpuid_phys);
>
> fwrite(&bph, vi->hdr_size, 1, f);
>
> @@ -395,7 +398,7 @@ static void dump_stringtable_asm(FILE *f
> }
> }
>
> -void dt_to_asm(FILE *f, struct boot_info *bi, int version)
> +void dt_to_asm(FILE *f, struct boot_info *bi, int version, int
> boot_cpuid_phys)
> {
> struct version_info *vi = NULL;
> int i;
> @@ -434,7 +437,8 @@ void dt_to_asm(FILE *f, struct boot_info
> vi->last_comp_version);
>
> if (vi->flags & FTF_BOOTCPUID)
> - fprintf(f, "\t.long\t0xdeadbeef\t/*boot_cpuid_phys*/\n");
> + fprintf(f, "\t.long\t%i\t/*boot_cpuid_phys*/\n",
> + boot_cpuid_phys);
>
> if (vi->flags & FTF_STRTABSIZE)
> fprintf(f, "\t.long\t_%s_strings_end - _%s_strings_start\t/*
> size_dt_strings */\n",
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: PowerMac7,3 sound (was: PowerBook5,4 -- no sound?)
From: Andreas Schwab @ 2006-05-18 12:48 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1147948758.15507.52.camel@johannes>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Wed, 2006-05-17 at 21:32 +0200, Andreas Schwab wrote:
>
>> I have the following sound resources in /proc/iomem:
>>
>> 80008000-800083ff : 0.00010000:i2s
>> 80008000-800083ff : Sound DMA
>> 80010000-80010fff : 0.00010000:i2s
>> 80010000-80010fff : Sound Control
>>
>> I'm not sure whether the first mapping should be split, but I don't know
>> much about how resource mappings work.
>
> That looks like you have snd-powermac loaded
Yes, that's while I had that loaded. Of course, I unloaded it before I
tried snd-aoa.
>> The layout id is 36, and it has both line out and headphone, detected as a
>> Snapper.
>
> Hmm. What's that again? tas3004 or 3001? I'll look at the OSX layout
> file.
I think it's a tas3004.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* I2C bus issues on MPC8248
From: Laurent Pinchart @ 2006-05-18 12:33 UTC (permalink / raw)
To: linuxppc-embedded
Hi everybody,
I'm trying to use the MPC8248 hardware I2C bus in a 2.6.16 kernel. The mailing
list archives mention a driver for the MPC8260
(http://ozlabs.org/pipermail/linuxppc-embedded/2006-May/022837.html) which I
modified to reflect the memory map differences between the MPC8260 and the
MPC8248, as mentionned in the e-mail.
The good news is that the driver works. The bad news is that it doesn't work
correctly.
The Linux I2C layer probes the I2C bus for peripherals when drivers are
loaded. The probing function writes a single byte with the device address and
check if the data is acked. I monitored the SCL and SDA lines using an
oscilloscope, and found out that 5 bytes are written to the device (address +
4 data bytes) instead of a single one. The first 4 bytes are acked, the last
isn't. After further investigation, I found out that the cpm_iic_write()
function in drivers/i2c/busses/i2c-mpc8260.c fills two buffer descriptors,
the second one having cbd_datlen set to zero:
tbdf[0].cbd_bufaddr = __pa(tb);
tbdf[0].cbd_datlen = 1;
tbdf[0].cbd_sc = BD_SC_READY | BD_IIC_START;
tbdf[1].cbd_bufaddr = __pa(buf);
tbdf[1].cbd_datlen = count;
tbdf[1].cbd_sc = BD_SC_READY | BD_SC_INTRPT | BD_SC_LAST | BD_SC_WRAP;
Still, 5 bytes are sent on the bus. I suspected a CPM bug when cbd_datlen is
equal to zero, so I modified the first buffer descriptor to set the
BD_SC_LAST in cbd_sc when count is zero:
tbdf[0].cbd_bufaddr = __pa(tb);
tbdf[0].cbd_datlen = 1;
tbdf[0].cbd_sc = count ? BD_SC_READY | BD_IIC_START :
BD_SC_READY | BD_IIC_START | BD_SC_INTRPT |
BD_SC_LAST | BD_SC_WRAP;
Using that code, no data is sent on the bus, the BD_SC_READY bit is never
cleared and no interrupt is generated. Once again I suspected a CPM bug when
writing a single byte on the bus, so I increased cbd_datlen to 2:
tbdf[0].cbd_bufaddr = __pa(tb);
tbdf[0].cbd_datlen = 2;
tbdf[0].cbd_sc = count ? BD_SC_READY | BD_IIC_START :
BD_SC_READY | BD_IIC_START | BD_SC_INTRPT |
BD_SC_LAST | BD_SC_WRAP;
This worked, and two bytes were written on the bus, leading me to believe that
the CPM was at fault.
Has anyone noticed the same behaviour ? Is there a workaround available ? I
tried searching Freescale's website for CPM microcode updates but haven't
found anything related to the I2C controller.
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH][resend] udbg_printf() formatting attribute
From: Jimi Xenidis @ 2006-05-18 12:22 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1147908963.7360.1.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 872 bytes --]
On May 17, 2006, at 7:36 PM, Michael Ellerman wrote:
> On Wed, 2006-05-17 at 12:00 -0400, jimix@watson.ibm.com wrote:
>> - pr_debug("%s: current_entitled = %lu, current_weight = %lu\n",
>> + pr_debug("%s: current_entitled = %lu, current_weight = %u\n",
>> __FUNCTION__, current_entitled, current_weight);
>>
>> - pr_debug("%s: new_entitled = %lu, new_weight = %lu\n",
>> + pr_debug("%s: new_entitled = %lu, new_weight = %u\n",
>> __FUNCTION__, *new_entitled_ptr, *new_weight_ptr);
>
> But pr_debug() calls printk, not udbg_printf() ?
Now _thats_ funny!
Then I'm so happy to have found and fixed this compiler warning :)
>> -extern void udbg_printf(const char *fmt, ...);
>> +extern void udbg_printf(const char *fmt, ...)
>> + __attribute__ ((format (printf, 1, 2)));
I believe this chunk is still goodness as it will catch format issues
for developers.
-JX
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Ric Wheeler @ 2006-05-18 12:01 UTC (permalink / raw)
To: Zang Roy-r61911, Mark Lord
Cc: Alexandre.Bounine, linuxppc-dev list, linux-kernel, linux-ide,
Paul Mackerras, Yang Xin-Xin-r48390, jgarzik
In-Reply-To: <9FCDBA58F226D911B202000BDBAD46730626DE6E@zch01exm40.ap.freescale.net>
Mark Lord has been actively working on the sata_mv driver recently,
ric
Zang Roy-r61911 wrote:
>-----Original Message-----
>From: Kumar Gala [mailto:galak@kernel.crashing.org]
>Sent: 2006年5月17日 21:28
>To: Zang Roy-r61911
>Cc: Paul Mackerras; linuxppc-dev list; Alexandre.Bounine@tundra.com; Yang Xin-Xin-r48390
>Subject: Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerpc pl atform
>
>
>
>On May 17, 2006, at 5:14 AM, Zang Roy-r61911 wrote:
>
>
>
>>Fix Marvell SATA driver bugs on PowerPC platform:
>>SATA device can't work for the problem on little-endian mode.
>>U-Boot can't find SATA device after kernel reboots.
>>
>>Signed-off-by: Hongjun cheng <hong-jun.chen@reescale.com>
>>Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
>>
>>
>>
>>>From nobody Mon Sep 17 00:00:00 2001
>>>
>>>
>>From: roy zang <tie-fei.zang@freescale.com>
>>Date: Tue May 16 15:25:23 2006 +0800
>>Subject: [PATCH] Fix bugs on powerpc platform for mv sata driver
>>
>>
>
>This needs to go to Jeff Garzik as SATA driver maintainer.
>
>- kumar
>
>
>
>> drivers/scsi/sata_mv.c | 10 +++++++++-
>> 1 files changed, 9 insertions(+), 1 deletions(-)
>>
>>d82ac19d259f8487a31105eaf844a93cbd9008e8
>>diff --git a/drivers/scsi/sata_mv.c b/drivers/scsi/sata_mv.c
>>index d5fdcb9..4166422 100644
>>--- a/drivers/scsi/sata_mv.c
>>+++ b/drivers/scsi/sata_mv.c
>>@@ -1032,6 +1032,9 @@ static inline void mv_crqb_pack_cmd(u16
>> {
>> *cmdw = data | (addr << CRQB_CMD_ADDR_SHIFT) | CRQB_CMD_CS |
>> (last ? CRQB_CMD_LAST : 0);
>>+#ifdef CONFIG_PPC
>>+ *cmdw = cpu_to_le16(*cmdw);
>>+#endif
>> }
>>
>> /**
>>@@ -1567,13 +1570,18 @@ static void mv5_read_preamp(struct mv_ho
>> static void mv5_enable_leds(struct mv_host_priv *hpriv, void
>>__iomem *mmio)
>> {
>> u32 tmp;
>>-
>>+#ifndef CONFIG_PPC
>> writel(0, mmio + MV_GPIO_PORT_CTL);
>>+#endif
>>
>> /* FIXME: handle MV_HP_ERRATA_50XXB2 errata */
>>
>> tmp = readl(mmio + MV_PCI_EXP_ROM_BAR_CTL);
>>+#ifdef CONFIG_PPC
>>+ tmp &= ~(1 << 0);
>>+#else
>> tmp |= ~(1 << 0);
>>+#endif
>> writel(tmp, mmio + MV_PCI_EXP_ROM_BAR_CTL);
>> }
>>
>>--
>>1.3.0
>>_______________________________________________
>>Linuxppc-dev mailing list
>>Linuxppc-dev@ozlabs.org
>>https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
>>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 8/10] Add tsi108 8250 serial support
From: Zang Roy-r61911 @ 2006-05-18 4:00 UTC (permalink / raw)
To: rmk+serial
Cc: Alexandre.Bounine, linux-kernel, linuxppc-dev list,
Paul Mackerras, linux-serial, Yang Xin-Xin-r48390
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: 2006=E5=B9=B45=E6=9C=8817=E6=97=A5 21:26
To: Zang Roy-r61911
Cc: Paul Mackerras; linuxppc-dev list; Alexandre.Bounine@tundra.com; =
Yang Xin-Xin-r48390
Subject: Re: [PATCH/2.6.17-rc4 8/10] Add tsi108 8250 serial support
On May 17, 2006, at 5:14 AM, Zang Roy-r61911 wrote:
> This patch contains changes to the serial device driver specific =20
> for integrated
> serial port in Tsi108 Host Bridge.
>
> Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
>
>> From nobody Mon Sep 17 00:00:00 2001
> From: roy zang <tie-fei.zang@freescale.com>
> Date: Tue May 16 15:26:02 2006 +0800
> Subject: [PATCH] Add tsi108 serial support
This patch needs to go to Russell King as uart/8250 driver maintainer.
- kumar
>
> ---
>
> drivers/serial/8250.c | 17 +++++++++++++++++
> 1 files changed, 17 insertions(+), 0 deletions(-)
>
> 6cb950357e9970afa671d59f172dbc4b03f11560
> diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
> index bbf78aa..c12f516 100644
> --- a/drivers/serial/8250.c
> +++ b/drivers/serial/8250.c
> @@ -723,7 +723,9 @@ static int broken_efr(struct uart_8250_p
> static void autoconfig_16550a(struct uart_8250_port *up)
> {
> unsigned char status1, status2;
> +#ifndef CONFIG_TSI108_BRIDGE
> unsigned int iersave;
> +#endif
>
> up->port.type =3D PORT_16550A;
> up->capabilities |=3D UART_CAP_FIFO;
> @@ -833,6 +835,7 @@ static void autoconfig_16550a(struct uar
> * trying to write and read a 1 just to make sure it's not
> * already a 1 and maybe locked there before we even start start.
> */
> +#ifndef CONFIG_TSI108_BRIDGE
> iersave =3D serial_in(up, UART_IER);
> serial_outp(up, UART_IER, iersave & ~UART_IER_UUE);
> if (!(serial_in(up, UART_IER) & UART_IER_UUE)) {
> @@ -859,6 +862,7 @@ static void autoconfig_16550a(struct uar
> DEBUG_AUTOCONF("Couldn't force IER_UUE to 0 ");
> }
> serial_outp(up, UART_IER, iersave);
> +#endif
> }
>
> /*
> @@ -1348,7 +1352,12 @@ static irqreturn_t serial8250_interrupt(
>
> up =3D list_entry(l, struct uart_8250_port, list);
>
> +#ifdef CONFIG_TSI108_BRIDGE /* for TSI108_REV_Z1 errata U2 */
> + /* read IIR as part of 32-bit word */
> + iir =3D (in_be32((u32 *)(up->port.membase + UART_RX)) >> 8) & =
0xff;
> +#else
> iir =3D serial_in(up, UART_IIR);
> +#endif
> if (!(iir & UART_IIR_NO_INT)) {
> serial8250_handle_port(up, regs);
>
> @@ -1529,7 +1538,9 @@ static int serial8250_startup(struct uar
> {
> struct uart_8250_port *up =3D (struct uart_8250_port *)port;
> unsigned long flags;
> +#ifndef CONFIG_TSI108_BRIDGE
> unsigned char lsr, iir;
> +#endif
> int retval;
>
> up->capabilities =3D uart_config[up->port.type].flags;
> @@ -1567,7 +1578,9 @@ #endif
> */
> (void) serial_inp(up, UART_LSR);
> (void) serial_inp(up, UART_RX);
> +#ifndef CONFIG_TSI108_BRIDGE /* for TSI108_REV_Z1 errata U2 */
> (void) serial_inp(up, UART_IIR);
> +#endif
> (void) serial_inp(up, UART_MSR);
>
> /*
> @@ -1634,6 +1647,7 @@ #endif
>
> serial8250_set_mctrl(&up->port, up->port.mctrl);
>
> +#ifndef CONFIG_TSI108_BRIDGE
> /*
> * Do a quick test to see if we receive an
> * interrupt when we enable the TX irq.
> @@ -1652,6 +1666,7 @@ #endif
> } else {
> up->bugs &=3D ~UART_BUG_TXEN;
> }
> +#endif
>
> spin_unlock_irqrestore(&up->port.lock, flags);
>
> @@ -1678,7 +1693,9 @@ #endif
> */
> (void) serial_inp(up, UART_LSR);
> (void) serial_inp(up, UART_RX);
> +#ifndef CONFIG_TSI108_BRIDGE /* for TSI108_REV_Z1 errata U2 */
> (void) serial_inp(up, UART_IIR);
> +#endif
> (void) serial_inp(up, UART_MSR);
>
> return 0;
> --=20
> 1.3.0
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] Fix do_mlock so page alignment is to hugepage boundries when needed
From: Hugh Dickins @ 2006-05-18 11:13 UTC (permalink / raw)
To: Eric Paris; +Cc: discuss, linux-kernel, wli, linuxppc-dev
In-Reply-To: <1147895964.26468.35.camel@localhost.localdomain>
On Wed, 17 May 2006, Eric Paris wrote:
>
> This patch still solves the problem of the kernel currently being more
> restrictive on what we accept from userspace for the length of the mlock
> if it is a hugepage rather than a regular page. With a regular page we
> will round the value from userspace and happily go about our business of
> mlocking. For a hugepage it just rejects it if userspace doesn't align
> it themselves. This allows the kernel to do the same work for hugepages
> that it does for normal pages.
You do have a point that there's an inconsistency there. But we could
argue a long time what's inconsistent with what - I'd say it's mlock
being inconsistent with mprotect, munmap, msync, madvise, etc. I
don't see an outright reason to change from the current behaviour.
You do realize that there's almost no point in mlocking a hugepage area
anyway? (I wrote that first without the "almost", but now with hugepage
faulting, it does provide another way to fault in all the pages at once.)
Hugh
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Zang Roy-r61911 @ 2006-05-18 10:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Paul Mackerras,
Alexandre.Bounine
> On Thu, 2006-05-18 at 18:21 +0800, Zang Roy-r61911 wrote:
> > > On Thu, 2006-05-18 at 15:12 +0800, Zang Roy-r61911 wrote:
> > > > > I'm not repeating Kumar's comments about that CONFIG_7xxx
> > > > > thing and that
> > > > > 7xxx/ directory, it should all go.
> > > > >
> > > >
> > > > Should I move my code to embedded6xx?
> > >
> > > Probably for now yes.
> >
> > I can migrate my code to embedded6xx technically. In fact,
> > I can move it into anywhere in the arch/powerpc/platforms.
> > While for mpc7448hpc2(taiga) board, it is not a embedded
> > application board. It is a high performance server! It seems
> > odd to put code there :). What's your opinion?
>
> I think we should do a platform/generic for boards that don't
> need more
> than a single platform file, which I think will be the case
> once we are
> done with your port ;)
>
> Ben.
>
>
I will implement my board port as early as I can
according to the feedback :).
^ permalink raw reply
* RE: [HACK] add sandpoint + flattened dt support to arch/powerpc/b oot
From: Zang Roy-r61911 @ 2006-05-18 10:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
> On Thu, 2006-05-18 at 18:24 +0800, Zang Roy-r61911 wrote:
> > > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > > > index 6729c98..de09eac 100644
> > > > --- a/arch/powerpc/Kconfig
> > > > +++ b/arch/powerpc/Kconfig
> > > > @@ -323,7 +323,10 @@ config PPC_ISERIES
> > > >
> > > > config EMBEDDED6xx
> > > > bool "Embedded 6xx/7xx/7xxx-based board"
> > > > - depends on PPC32 && BROKEN
> > > > + depends on PPC32
> > > > + select PPC_UDBG_16550
> > > > + select MPIC
> > > > + select MPIC_SERIAL
> > >
> > > Not totally related to your patch but I'm tempted to turn
> that into a
> > > "Generic 6xx/7xx/7xxx" rather than "embedded" if we
> manage to always
> > > avoid board specific code most of the time, but instead
> add necessary
> > > bits in the device-tree. We still need a per-board
> Kconfig option I
> > > think that will just select the necessary bits and pieces
> > > (and more than
> > > one can be selected at one time). Also, I think right now,
> > > the embedded
> > > stuff is +/- exclusive from the MULTIPLATFORM stuff, that
> > > must be fixed
> > > asap. We are all living in the same kernel now :)
> >
> > config Embedded6xx is not accurate. It can not cover all the
> > board with 7xx/7xxx based processor.
>
> Forget about CONFIG_EMBEDDED6xx, just do your own CONFIG_BOARDNAME for
> now, the processor is irrelevant as long as it's a 6xx/7xx/7xxx
> derivative.
>
> Ben.
>
>
I can just do as your suggestion!
^ permalink raw reply
* Re: PowerMac7,3 sound (was: PowerBook5,4 -- no sound?)
From: Johannes Berg @ 2006-05-18 10:39 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <je3bf85twf.fsf@sykes.suse.de>
[-- Attachment #1: Type: text/plain, Size: 807 bytes --]
On Wed, 2006-05-17 at 21:32 +0200, Andreas Schwab wrote:
> I have the following sound resources in /proc/iomem:
>
> 80008000-800083ff : 0.00010000:i2s
> 80008000-800083ff : Sound DMA
> 80010000-80010fff : 0.00010000:i2s
> 80010000-80010fff : Sound Control
>
> I'm not sure whether the first mapping should be split, but I don't know
> much about how resource mappings work.
That looks like you have snd-powermac loaded, or some other driver,
otherwise it shouldn't show up in /proc/iomem at all. It isn't my
driver, because it would generated 'i2sbus ...' names there.
> The layout id is 36, and it has both line out and headphone, detected as a
> Snapper.
Hmm. What's that again? tas3004 or 3001? I'll look at the OSX layout
file.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Paul Mackerras @ 2006-05-18 10:39 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: Yang Xin-Xin-r48390, Alexandre.Bounine, linuxppc-dev list
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673062C0A97@zch01exm40.ap.freescale.net>
Zang Roy-r61911 writes:
> I can migrate my code to embedded6xx technically. In fact,
> I can move it into anywhere in the arch/powerpc/platforms.
> While for mpc7448hpc2(taiga) board, it is not a embedded
> application board. It is a high performance server! It seems
> odd to put code there :). What's your opinion?
What sort of machine(s) is this board used in? Or what machines will
it be in?
Paul.
^ permalink raw reply
* RE: [HACK] add sandpoint + flattened dt support to arch/powerpc/b oot
From: Benjamin Herrenschmidt @ 2006-05-18 10:36 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673062C0A9D@zch01exm40.ap.freescale.net>
On Thu, 2006-05-18 at 18:24 +0800, Zang Roy-r61911 wrote:
> > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > > index 6729c98..de09eac 100644
> > > --- a/arch/powerpc/Kconfig
> > > +++ b/arch/powerpc/Kconfig
> > > @@ -323,7 +323,10 @@ config PPC_ISERIES
> > >
> > > config EMBEDDED6xx
> > > bool "Embedded 6xx/7xx/7xxx-based board"
> > > - depends on PPC32 && BROKEN
> > > + depends on PPC32
> > > + select PPC_UDBG_16550
> > > + select MPIC
> > > + select MPIC_SERIAL
> >
> > Not totally related to your patch but I'm tempted to turn that into a
> > "Generic 6xx/7xx/7xxx" rather than "embedded" if we manage to always
> > avoid board specific code most of the time, but instead add necessary
> > bits in the device-tree. We still need a per-board Kconfig option I
> > think that will just select the necessary bits and pieces
> > (and more than
> > one can be selected at one time). Also, I think right now,
> > the embedded
> > stuff is +/- exclusive from the MULTIPLATFORM stuff, that
> > must be fixed
> > asap. We are all living in the same kernel now :)
>
> config Embedded6xx is not accurate. It can not cover all the
> board with 7xx/7xxx based processor.
Forget about CONFIG_EMBEDDED6xx, just do your own CONFIG_BOARDNAME for
now, the processor is irrelevant as long as it's a 6xx/7xx/7xxx
derivative.
Ben.
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Benjamin Herrenschmidt @ 2006-05-18 10:35 UTC (permalink / raw)
To: Zang Roy-r61911
Cc: linuxppc-dev list, Yang Xin-Xin-r48390, Paul Mackerras,
Alexandre.Bounine
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673062C0A97@zch01exm40.ap.freescale.net>
On Thu, 2006-05-18 at 18:21 +0800, Zang Roy-r61911 wrote:
> > On Thu, 2006-05-18 at 15:12 +0800, Zang Roy-r61911 wrote:
> > > > I'm not repeating Kumar's comments about that CONFIG_7xxx
> > > > thing and that
> > > > 7xxx/ directory, it should all go.
> > > >
> > >
> > > Should I move my code to embedded6xx?
> >
> > Probably for now yes.
>
> I can migrate my code to embedded6xx technically. In fact,
> I can move it into anywhere in the arch/powerpc/platforms.
> While for mpc7448hpc2(taiga) board, it is not a embedded
> application board. It is a high performance server! It seems
> odd to put code there :). What's your opinion?
I think we should do a platform/generic for boards that don't need more
than a single platform file, which I think will be the case once we are
done with your port ;)
Ben.
^ 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