* Re: 2.6.16 does not boot on powerbook
From: Dustin Lang @ 2006-03-28 14:40 UTC (permalink / raw)
To: Michal Purzynski; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.60.0603280630130.8520@tin.icics.ubc.ca>
Hi again,
I was wrong about MULTIPLATFORM - it IS set in my config. Here's my
config:
CONFIG_PPC_MULTIPLATFORM=y
# CONFIG_PPC_ISERIES is not set
# CONFIG_EMBEDDED6xx is not set
# CONFIG_APUS is not set
# CONFIG_PPC_CHRP is not set
CONFIG_PPC_PMAC=y
I also set the environment variable ARCH=powerpc in my .bashrc file so I
don't forget :)
Cheers,
dstn.
^ permalink raw reply
* Re: 2.6.16 does not boot on powerbook
From: Dustin Lang @ 2006-03-28 14:37 UTC (permalink / raw)
To: Michal Purzynski; +Cc: linuxppc-dev
In-Reply-To: <442925A8.6030004@rsbac.org>
Hi,
> #
> # Platform support
> #
> CONFIG_PPC_MULTIPLATFORM=y
> # CONFIG_PPC_ISERIES is not set
> # CONFIG_EMBEDDED6xx is not set
> # CONFIG_APUS is not set
> # CONFIG_PPC_CHRP is not set
> # CONFIG_PPC_PMAC is not set
Could that be your problem? (I've never used MULTIPLATFORM, maybe you set
that intentionally; I've always used PPC_PMAC.)
Do you have ARCH=powerpc set? It's possible that ARCH=ppc is broken...
2.6.16 works fine on my PowerBook 6,2. When I patched up to 2.6.16 I
found I had to go through the config process - some of the PowerMac
options seem to have been turned off. Maybe that was just me doing
something wrong, or maybe some of the Kconfig defaults changed?
I'd suggest going through your config options again and making sure
everything is the way you want it.
Cheers,
dstn.
^ permalink raw reply
* Re: Kernel for MPC Lite 5200 will not compile
From: John Rigby @ 2006-03-28 16:15 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060328094939.GA43123@server.idefix.loc>
[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]
Sorry I'm not sure what the state of 5200 support in the eldk. I know that
Wolfgang
has said that 2.6 is not supported though. You may want to try out Sylvains
kernel: http://gitbits.246tnt.com/gitbits/linux-2.6-mpc52xx.git
You can search in list for Syvains instructions on how to use it.
On 3/28/06, Matthias Fechner <idefix@fechner.net> wrote:
>
> Hello John,
>
> * John Rigby <jcrigby@gmail.com> [27-03-06 18:01]:
> > try make lite5200_defconfig instead of copying it to .config
> > or make oldconfig after copying ti to .config
>
> I tried now several combinations with:
> make ARCH=ppc CROSS_COMPILE=ppc_6xx- lite5200_defconfig
> make ARCH=ppc CROSS_COMPILE=ppc_6xx- uImage
>
> then coping the file to .config and
> make ARCH=ppc CROSS_COMPILE=ppc_6xx- oldconfig
> make ARCH=ppc CROSS_COMPILE=ppc_6xx- uImage
>
> but it always leads to the same error message...
>
> Best regards,
> Matthias
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 1950 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Add FSL CPM2 device tree node documentation
From: Vitaly Bordug @ 2006-03-28 16:14 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Updated the documentation to include the initial description of the CPM2
device that are used on PQII and PQIII families. Only initial sub-devices
described so far, but that should be sufficient to move the respective
boards to powerpc, with a reasonable minimum supporteddevice set.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
---
Documentation/powerpc/booting-without-of.txt | 149 ++++++++++++++++++++++++++
1 files changed, 149 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index ee551c6..d44980c 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1436,6 +1436,155 @@ platforms are moved over to use the flat
descriptor-types-mask = <073f1127>;
};
+ h) Freescale SOC communication processor module (CPM)
+ This represents cpm module that is installed on PQ (PowerQUICC)
+ series,1-st, 2-nd and 3-rd generation. Basically, is is a bus of devices,
+ both those that are inalienable cpm parts (BRGs, etc.), and those that could act
+ more or less as a complete entity (FCC, SCC). All af them should be
+ siblings on the "root" cpm node, using the common properties from
+ there. The description below applies to the CPM2 (2-nd rev. found on
+ PQ2 and PQ3) but I beleive could be extended to the PQ CPM1 as well
+ later.
+
+ 1) Root cpm2 device
+ Required properties:
+
+ - device_type : Should be "cpm"
+ - model : Model of the device. Should be "CPM1" or "CPM2"
+ - reg : Offset and length of the register set for the device
+ - command-proc : Offset to the CPM command processor
+
+ 2) Baud-rate generators (BRG)
+ The CPM contains eight independent, identical baud-rate generators (BRGs) that can be
+ used with the FCCs, SCCs, and SMCs. The clocks produced by the BRGs are sent to the
+ bank-of-clocks selection logic, where they can be routed to the controllers. In addition, the
+ output of a BRG can be routed to a pin to be used externally.
+
+ Required properties:
+
+ - device_type : Should be "brg"
+ - model : should be "BRGx", x relative to the BRG number (usually
+ from 1 to 8)
+ - reg : Offset to the configuration register (from cpm reg)
+ - linux,phandle : phandle for this node; likely referenced by the CPM
+ devices (SCC, FCC, SMC, etc.)
+
+ Recommended properties:
+
+ - clock-divider : 12-bit integer (internal counter that is decremented at the DIV16 output rate)
+ - div16 : Either <0> or <1> the 1/16 prescalar before reaching the clock divider
+ - ext-clock : Either <0> or phandle of the external clock source
+
+ 3) CPM multiplexor
+ CPM supports special NMSI mode of operation for its devices. In short,
+ each serial device could be connected to the set of dedicated pins,
+ and this pseudo-device controls such behavior. They are different for
+ each device set, and could be recognised using "compatible" field.
+
+ Required properties:
+
+ - device_type : Should be "cpmux"
+ - reg : offset to the configuration register
+ - compatible : "fcc", "scc", or "smc"
+
+ 4) SCCs (Serial Communications Controllers)
+
+ Required properties:
+
+ - device_type : "serial" or "network"
+ - model : "SCCx", x is typically a small number depending on the
+ devices amount
+ - compatible : Either "fs_enet" or "cpm_uart"
+ - reg : offset to the register set and its length
+ - reg-pram : offset to the device parameter RAM
+ - clock-setup : should be <CMX_RT CMX_MSK> where CMX_... values define
+ multiplexor clock routing and clock mask respectively
+ - interrupts : <a b> where a is the interrupt number and b is a
+ field that represents an encoding of the sense and level
+ information for the interrupt. This should be encoded based on
+ the information in section 2) depending on the type of interrupt
+ controller you have.
+ - interrupt-parent : the phandle for the interrupt controller that
+ services interrupts for this device.
+
+ 5) FCCs (Fast Communications Controllers)
+
+ Required properties:
+
+ - device_type : should be "network"
+ - model : "FCCx", x is typically a small number depending on the
+ devices amount
+ - compatible : should be "fs_enet"
+ - address : List of bytes representing the ethernet address of
+ this controller
+ - reg : offset to the register set and its length
+ - reg-pram : offset to the device parameter RAM
+ - clock-setup : should be <CMX_RT CMX_MSK> where CMX_... values define
+ multiplexor clock routing and clock mask respectively
+ - interrupts : <a b> where a is the interrupt number and b is a
+ field that represents an encoding of the sense and level
+ information for the interrupt. This should be encoded based on
+ the information in section 2) depending on the type of interrupt
+ controller you have.
+ - interrupt-parent : the phandle for the interrupt controller that
+ services interrupts for this device.
+ - phy-handle : The phandle for the PHY connected to this ethernet
+ controller.
+ Example:
+ /*8272ADS*/
+ cpm@f0000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ device_type = "cpm";
+ model = "CPM2";
+ ranges = <0 f0000000 00100000>;
+ reg = <f0000000 000101a8>;
+ command-proc = <119c0>
+
+ brg@119f0 {
+ device_type = "brg";
+ model = "BRG1";
+ reg = <119f0>;
+ linux,phandle = <775>;
+ };
+
+ cpmux@11b04 {
+ device_type = "cpmux";
+ compatible = "fcc";
+ reg = <11b04>;
+ };
+
+ cpmux@11b08 {
+ device_type = "cpmux";
+ compatible = "scc";
+ reg = <11b08>;
+ };
+
+ scc@11a20 {
+ device_type = "serial";
+ compatible = "cpm_uart";
+ model = "SCC1";
+ reg = <11a20 100>;
+ reg_pram = <8000 ff>;
+ clock_setup = <0x00ffffff 0>;
+ interrupts = <28 3>;
+ interrupt-parent = <700>;
+ brg_phandle = <775>;
+ };
+
+ fcc@11300 {
+ device_type = "network";
+ compatible = "fs_enet";
+ model = "FCC1";
+ reg = <11300 1f>;
+ reg_pram = <8400 ff>;
+ address = [00 00 00 00 00 00];
+ interrupts = <20 3>;
+ interrupt-parent = <700>;
+ phy_handle = <2452000>;
+ };
+ };
More devices will be defined as this spec matures.
^ permalink raw reply related
* Re: 2.6.16 does not boot on powerbook
From: Étienne Bersac @ 2006-03-28 16:31 UTC (permalink / raw)
To: Dustin Lang; +Cc: linuxppc-dev, Michal Purzynski
In-Reply-To: <Pine.LNX.4.60.0603280630130.8520@tin.icics.ubc.ca>
Michal, have you tried arch/powerpc/configs/ defconfigs ?
^ permalink raw reply
* Re: Memory mapping PCI memory region to user space
From: David Hawkins @ 2006-03-28 16:35 UTC (permalink / raw)
To: Phil.Nitschke; +Cc: linuxppc-embedded
In-Reply-To: <1143528245.24304.28.camel@lamorak.int.avalon.com.au>
Hey Phil,
>
> Much better, thanks. I might be able to use your program/driver as a
> comparison to my own driver, at least as far as the mmap() goes, because
> mine is broken and yours isn't!
>
Great! Good to hear.
Dave
^ permalink raw reply
* PPC405EP and Abatron BDI help
From: Jeff.Fellin @ 2006-03-28 16:36 UTC (permalink / raw)
To: linuxppc-embedded
I'm not sure if this forum can help me, but perhaps someone has experience
with
using an Abatron BDI2000 to control an AMCC PPC405EP evaluation board. I am
having problems with getting the BDI to access devices on the external bus.
I have verifed the EBC settings are correct by comparing them to the values
set by Uboot 1.1.2 (Jun 2, 2005 Rev B) running on the board.
I have used the base bubinga.cfg , Stefan Roese's configuration file, sent
to me
from someone on this mailing list. I modified the configuration to match
the external
device configuration of the AMCC PPC405EP evaluation board.
Any ideas as to why I cannot access devices on the external bus using the
BDI,
but Uboot can?
Jeff Fellin
RFL Electronics
Jeff.Fellin@rflelect.com
973 334-3100, x 327
^ permalink raw reply
* Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation
From: Kumar Gala @ 2006-03-28 16:37 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060328161431.18517.82573.stgit@vitb.ru.mvista.com>
Paul,
Please dont accept this patch right away. I think we should let this
have some discussion on the list before it goes in. I believe this
is the first time any of the 8xx maintainers have seen this (Dan or
Marcelo) so getting their feedback would be good.
Nothing against your patch Vitaly :)
- kumar
On Mar 28, 2006, at 10:14 AM, Vitaly Bordug wrote:
>
> Updated the documentation to include the initial description of the
> CPM2
> device that are used on PQII and PQIII families. Only initial sub-
> devices
> described so far, but that should be sufficient to move the respective
> boards to powerpc, with a reasonable minimum supporteddevice set.
>
> Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
> ---
>
> Documentation/powerpc/booting-without-of.txt | 149 +++++++++++++++
> +++++++++++
> 1 files changed, 149 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/
> Documentation/powerpc/booting-without-of.txt
> index ee551c6..d44980c 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -1436,6 +1436,155 @@ platforms are moved over to use the flat
> descriptor-types-mask = <073f1127>;
> };
>
> + h) Freescale SOC communication processor module (CPM)
> + This represents cpm module that is installed on PQ (PowerQUICC)
> + series,1-st, 2-nd and 3-rd generation. Basically, is is a bus of
> devices,
> + both those that are inalienable cpm parts (BRGs, etc.), and those
> that could act
> + more or less as a complete entity (FCC, SCC). All af them should be
> + siblings on the "root" cpm node, using the common properties from
> + there. The description below applies to the CPM2 (2-nd rev. found on
> + PQ2 and PQ3) but I beleive could be extended to the PQ CPM1 as well
> + later.
> +
> + 1) Root cpm2 device
> + Required properties:
> +
> + - device_type : Should be "cpm"
> + - model : Model of the device. Should be "CPM1" or "CPM2"
> + - reg : Offset and length of the register set for the device
> + - command-proc : Offset to the CPM command processor
> +
> + 2) Baud-rate generators (BRG)
> + The CPM contains eight independent, identical baud-rate
> generators (BRGs) that can be
> + used with the FCCs, SCCs, and SMCs. The clocks produced
> by the BRGs are sent to the
> + bank-of-clocks selection logic, where they can be routed
> to the controllers. In addition, the
> + output of a BRG can be routed to a pin to be used
> externally.
> +
> + Required properties:
> +
> + - device_type : Should be "brg"
> + - model : should be "BRGx", x relative to the BRG number (usually
> + from 1 to 8)
> + - reg : Offset to the configuration register (from cpm reg)
> + - linux,phandle : phandle for this node; likely referenced by
> the CPM
> + devices (SCC, FCC, SMC, etc.)
> +
> + Recommended properties:
> +
> + - clock-divider : 12-bit integer (internal counter that is
> decremented at the DIV16 output rate)
> + - div16 : Either <0> or <1> the 1/16 prescalar before reaching
> the clock divider
> + - ext-clock : Either <0> or phandle of the external clock source
> +
> + 3) CPM multiplexor
> + CPM supports special NMSI mode of operation for its devices. In
> short,
> + each serial device could be connected to the set of dedicated
> pins,
> + and this pseudo-device controls such behavior. They are
> different for
> + each device set, and could be recognised using "compatible" field.
> +
> + Required properties:
> +
> + - device_type : Should be "cpmux"
> + - reg : offset to the configuration register
> + - compatible : "fcc", "scc", or "smc"
> +
> + 4) SCCs (Serial Communications Controllers)
> +
> + Required properties:
> +
> + - device_type : "serial" or "network"
> + - model : "SCCx", x is typically a small number depending on the
> + devices amount
> + - compatible : Either "fs_enet" or "cpm_uart"
> + - reg : offset to the register set and its length
> + - reg-pram : offset to the device parameter RAM
> + - clock-setup : should be <CMX_RT CMX_MSK> where CMX_... values
> define
> + multiplexor clock routing and clock mask respectively
> + - interrupts : <a b> where a is the interrupt number and b is a
> + field that represents an encoding of the sense and level
> + information for the interrupt. This should be encoded based on
> + the information in section 2) depending on the type of interrupt
> + controller you have.
> + - interrupt-parent : the phandle for the interrupt controller that
> + services interrupts for this device.
> +
> + 5) FCCs (Fast Communications Controllers)
> +
> + Required properties:
> +
> + - device_type : should be "network"
> + - model : "FCCx", x is typically a small number depending on the
> + devices amount
> + - compatible : should be "fs_enet"
> + - address : List of bytes representing the ethernet address of
> + this controller
> + - reg : offset to the register set and its length
> + - reg-pram : offset to the device parameter RAM
> + - clock-setup : should be <CMX_RT CMX_MSK> where CMX_... values
> define
> + multiplexor clock routing and clock mask respectively
> + - interrupts : <a b> where a is the interrupt number and b is a
> + field that represents an encoding of the sense and level
> + information for the interrupt. This should be encoded based on
> + the information in section 2) depending on the type of interrupt
> + controller you have.
> + - interrupt-parent : the phandle for the interrupt controller that
> + services interrupts for this device.
> + - phy-handle : The phandle for the PHY connected to this ethernet
> + controller.
> + Example:
> + /*8272ADS*/
> + cpm@f0000000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + #interrupt-cells = <2>;
> + device_type = "cpm";
> + model = "CPM2";
> + ranges = <0 f0000000 00100000>;
> + reg = <f0000000 000101a8>;
> + command-proc = <119c0>
> +
> + brg@119f0 {
> + device_type = "brg";
> + model = "BRG1";
> + reg = <119f0>;
> + linux,phandle = <775>;
> + };
> +
> + cpmux@11b04 {
> + device_type = "cpmux";
> + compatible = "fcc";
> + reg = <11b04>;
> + };
> +
> + cpmux@11b08 {
> + device_type = "cpmux";
> + compatible = "scc";
> + reg = <11b08>;
> + };
> +
> + scc@11a20 {
> + device_type = "serial";
> + compatible = "cpm_uart";
> + model = "SCC1";
> + reg = <11a20 100>;
> + reg_pram = <8000 ff>;
> + clock_setup = <0x00ffffff 0>;
> + interrupts = <28 3>;
> + interrupt-parent = <700>;
> + brg_phandle = <775>;
> + };
> +
> + fcc@11300 {
> + device_type = "network";
> + compatible = "fs_enet";
> + model = "FCC1";
> + reg = <11300 1f>;
> + reg_pram = <8400 ff>;
> + address = [00 00 00 00 00 00];
> + interrupts = <20 3>;
> + interrupt-parent = <700>;
> + phy_handle = <2452000>;
> + };
> + };
>
> More devices will be defined as this spec matures.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation
From: Vitaly Bordug @ 2006-03-28 16:42 UTC (permalink / raw)
To: Kumar Gala; +Cc: Marcelo, linuxppc-dev, Paul Mackerras
In-Reply-To: <BA98B559-3041-4D80-A0DA-0CD9F6080B1B@kernel.crashing.org>
On Tue, 28 Mar 2006 10:37:02 -0600
Kumar Gala <galak@kernel.crashing.org> wrote:
> Paul,
>
> Please dont accept this patch right away. I think we should let this
> have some discussion on the list before it goes in. I believe this
> is the first time any of the 8xx maintainers have seen this (Dan or
> Marcelo) so getting their feedback would be good.
>
That was implied... This is definitely RFC, I forgot to add that to the subject :)
> Nothing against your patch Vitaly :)
>
> - kumar
> --
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation
From: Paul Nasrat @ 2006-03-28 16:55 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Jon Loeliger, Paul Mackerras
In-Reply-To: <20060328161431.18517.82573.stgit@vitb.ru.mvista.com>
On Tue, 2006-03-28 at 20:14 +0400, Vitaly Bordug wrote:
> Updated the documentation to include the initial description of the CPM2
> device that are used on PQII and PQIII families. Only initial sub-devices
> described so far, but that should be sufficient to move the respective
> boards to powerpc, with a reasonable minimum supporteddevice set.
>
> + 5) FCCs (Fast Communications Controllers)
> +
> + Required properties:
> +
> + - device_type : should be "network"
> + - model : "FCCx", x is typically a small number depending on the
> + devices amount
> + - compatible : should be "fs_enet"
> + - address : List of bytes representing the ethernet address of
> + this controller
Umm should we not use local-mac-address and mac-address (and
address-bits) as in section 3.7.4 in 1275-1994?
Paul
^ permalink raw reply
* Re: [PATCH] lock PTE before updating it in 440/BookE page fault handler
From: Eugene Surovegin @ 2006-03-28 18:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17449.6575.927844.106127@cargo.ozlabs.ibm.com>
On Tue, Mar 28, 2006 at 10:10:39PM +1100, Paul Mackerras wrote:
> Eugene Surovegin writes:
>
> > Fix 44x and BookE page fault handler to correctly lock PTE before
> > trying to pte_update() it, otherwise this PTE might be swapped out
> > after pte_present() check but before pte_uptdate() call, resulting in
> > corrupted PTE. This can happen with enabled preemption and low memory
> > condition.
>
> That gives me this for an ARCH=powerpc 32-bit pmac build:
>
> /home/paulus/kernel/powerpc/arch/powerpc/mm/pgtable_32.c:376: error: conflicting types for 'get_pteptr'
> /home/paulus/kernel/powerpc/include/asm-ppc/pgtable.h:841: error: previous declaration of 'get_pteptr' was here
Oops, sorry. Haven't noticed we have duplicated files in ppc and
powerpc. Full patch follows.
Fix 44x and BookE page fault handler to correctly lock PTE before
trying to pte_update() it, otherwise this PTE might be swapped out
after pte_present() check but before pte_uptdate() call, resulting in
corrupted PTE. This can happen with enabled preemption and low memory
condition.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
---
arch/powerpc/mm/fault.c | 30 +++++++++++++++++-------------
arch/powerpc/mm/pgtable_32.c | 6 ++++--
arch/ppc/mm/fault.c | 30 +++++++++++++++++-------------
arch/ppc/mm/pgtable.c | 6 ++++--
include/asm-ppc/pgtable.h | 3 ++-
5 files changed, 44 insertions(+), 31 deletions(-)
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index ec4adcb..5aea090 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -267,25 +267,29 @@ good_area:
#endif
#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
pte_t *ptep;
+ pmd_t *pmdp;
/* Since 4xx/Book-E supports per-page execute permission,
* we lazily flush dcache to icache. */
ptep = NULL;
- if (get_pteptr(mm, address, &ptep) && pte_present(*ptep)) {
- struct page *page = pte_page(*ptep);
-
- if (! test_bit(PG_arch_1, &page->flags)) {
- flush_dcache_icache_page(page);
- set_bit(PG_arch_1, &page->flags);
+ if (get_pteptr(mm, address, &ptep, &pmdp)) {
+ spinlock_t *ptl = pte_lockptr(mm, pmdp);
+ spin_lock(ptl);
+ if (pte_present(*ptep)) {
+ struct page *page = pte_page(*ptep);
+
+ if (!test_bit(PG_arch_1, &page->flags)) {
+ flush_dcache_icache_page(page);
+ set_bit(PG_arch_1, &page->flags);
+ }
+ pte_update(ptep, 0, _PAGE_HWEXEC);
+ _tlbie(address);
+ pte_unmap_unlock(ptep, ptl);
+ up_read(&mm->mmap_sem);
+ return 0;
}
- pte_update(ptep, 0, _PAGE_HWEXEC);
- _tlbie(address);
- pte_unmap(ptep);
- up_read(&mm->mmap_sem);
- return 0;
+ pte_unmap_unlock(ptep, ptl);
}
- if (ptep != NULL)
- pte_unmap(ptep);
#endif
/* a write */
} else if (is_write) {
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index d296eb6..9062860 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -372,7 +372,7 @@ void __init io_block_mapping(unsigned lo
* the PTE pointer is unmodified if PTE is not found.
*/
int
-get_pteptr(struct mm_struct *mm, unsigned long addr, pte_t **ptep)
+get_pteptr(struct mm_struct *mm, unsigned long addr, pte_t **ptep, pmd_t **pmdp)
{
pgd_t *pgd;
pmd_t *pmd;
@@ -387,6 +387,8 @@ get_pteptr(struct mm_struct *mm, unsigne
if (pte) {
retval = 1;
*ptep = pte;
+ if (pmdp)
+ *pmdp = pmd;
/* XXX caller needs to do pte_unmap, yuck */
}
}
@@ -424,7 +426,7 @@ unsigned long iopa(unsigned long addr)
mm = &init_mm;
pa = 0;
- if (get_pteptr(mm, addr, &pte)) {
+ if (get_pteptr(mm, addr, &pte, NULL)) {
pa = (pte_val(*pte) & PAGE_MASK) | (addr & ~PAGE_MASK);
pte_unmap(pte);
}
diff --git a/arch/ppc/mm/fault.c b/arch/ppc/mm/fault.c
index 0217188..8e08ca3 100644
--- a/arch/ppc/mm/fault.c
+++ b/arch/ppc/mm/fault.c
@@ -202,6 +202,7 @@ good_area:
/* an exec - 4xx/Book-E allows for per-page execute permission */
} else if (TRAP(regs) == 0x400) {
pte_t *ptep;
+ pmd_t *pmdp;
#if 0
/* It would be nice to actually enforce the VM execute
@@ -215,21 +216,24 @@ good_area:
/* Since 4xx/Book-E supports per-page execute permission,
* we lazily flush dcache to icache. */
ptep = NULL;
- if (get_pteptr(mm, address, &ptep) && pte_present(*ptep)) {
- struct page *page = pte_page(*ptep);
-
- if (! test_bit(PG_arch_1, &page->flags)) {
- flush_dcache_icache_page(page);
- set_bit(PG_arch_1, &page->flags);
+ if (get_pteptr(mm, address, &ptep, &pmdp)) {
+ spinlock_t *ptl = pte_lockptr(mm, pmdp);
+ spin_lock(ptl);
+ if (pte_present(*ptep)) {
+ struct page *page = pte_page(*ptep);
+
+ if (!test_bit(PG_arch_1, &page->flags)) {
+ flush_dcache_icache_page(page);
+ set_bit(PG_arch_1, &page->flags);
+ }
+ pte_update(ptep, 0, _PAGE_HWEXEC);
+ _tlbie(address);
+ pte_unmap_unlock(ptep, ptl);
+ up_read(&mm->mmap_sem);
+ return 0;
}
- pte_update(ptep, 0, _PAGE_HWEXEC);
- _tlbie(address);
- pte_unmap(ptep);
- up_read(&mm->mmap_sem);
- return 0;
+ pte_unmap_unlock(ptep, ptl);
}
- if (ptep != NULL)
- pte_unmap(ptep);
#endif
/* a read */
} else {
diff --git a/arch/ppc/mm/pgtable.c b/arch/ppc/mm/pgtable.c
index 6ea9185..98a83be 100644
--- a/arch/ppc/mm/pgtable.c
+++ b/arch/ppc/mm/pgtable.c
@@ -368,7 +368,7 @@ void __init io_block_mapping(unsigned lo
* the PTE pointer is unmodified if PTE is not found.
*/
int
-get_pteptr(struct mm_struct *mm, unsigned long addr, pte_t **ptep)
+get_pteptr(struct mm_struct *mm, unsigned long addr, pte_t **ptep, pmd_t **pmdp)
{
pgd_t *pgd;
pmd_t *pmd;
@@ -383,6 +383,8 @@ get_pteptr(struct mm_struct *mm, unsigne
if (pte) {
retval = 1;
*ptep = pte;
+ if (pmdp)
+ *pmdp = pmd;
/* XXX caller needs to do pte_unmap, yuck */
}
}
@@ -420,7 +422,7 @@ unsigned long iopa(unsigned long addr)
mm = &init_mm;
pa = 0;
- if (get_pteptr(mm, addr, &pte)) {
+ if (get_pteptr(mm, addr, &pte, NULL)) {
pa = (pte_val(*pte) & PAGE_MASK) | (addr & ~PAGE_MASK);
pte_unmap(pte);
}
diff --git a/include/asm-ppc/pgtable.h b/include/asm-ppc/pgtable.h
index e1c62da..570b355 100644
--- a/include/asm-ppc/pgtable.h
+++ b/include/asm-ppc/pgtable.h
@@ -837,7 +837,8 @@ static inline int io_remap_pfn_range(str
*/
#define pgtable_cache_init() do { } while (0)
-extern int get_pteptr(struct mm_struct *mm, unsigned long addr, pte_t **ptep);
+extern int get_pteptr(struct mm_struct *mm, unsigned long addr, pte_t **ptep,
+ pmd_t **pmdp);
#include <asm-generic/pgtable.h>
^ permalink raw reply related
* Re: PPC405EP and Abatron BDI help
From: Tolunay Orkun @ 2006-03-28 17:59 UTC (permalink / raw)
To: Jeff.Fellin; +Cc: linuxppc-embedded
In-Reply-To: <OF3A743E50.87BEEA66-ON8525713F.00587402@teal.com>
Hi,
I am also involved in bring up effort of a 405EP board (in-house
developed). We had 3rd party 405GP boards before so I expected bring up
to be less rocky but there are some subtle differences to note.
Are you configuring the PerWE* and PerCS* properly?
1) You need to set CPC0_PCI[SPE] bit to set PerWE* as output for CS0
(So, you can write your Flash connected to CS0. Note that this is DCR
0x0F9. There are incorrect references in the manual as the register
number is 0x0F4 (which is PLLMR1)
2) You need to program GPIO pins to alternate functions via GPIO0
registers (Read Chapter 23 of 405EP manual) otherwise you will not sett
CS* asserted for your devices (except CS0). For example, for CS1 you
need to set GPIO10 to alternate function.
On the 405GP these would normally be configured CPC0_CR0/1. 405EP
probably does not use these registers at all (well, the CPC0_CR
registers are not documented in 405EP manual except two places make
refer to it: table 3-6 and 12.2.1 Timer Base Counter -- someone else
could chime on this)
3) Of course you need to configure EBC0_BnCR and EBC0_BnAP as
appropriate to your peripheral as well.
Best regards,
Tolunay
Jeff.Fellin@rflelect.com wrote:
> I'm not sure if this forum can help me, but perhaps someone has experience
> with
> using an Abatron BDI2000 to control an AMCC PPC405EP evaluation board. I am
> having problems with getting the BDI to access devices on the external bus.
> I have verifed the EBC settings are correct by comparing them to the values
> set by Uboot 1.1.2 (Jun 2, 2005 Rev B) running on the board.
>
> I have used the base bubinga.cfg , Stefan Roese's configuration file, sent
> to me
> from someone on this mailing list. I modified the configuration to match
> the external
> device configuration of the AMCC PPC405EP evaluation board.
>
> Any ideas as to why I cannot access devices on the external bus using the
> BDI,
> but Uboot can?
>
>
> Jeff Fellin
> RFL Electronics
> Jeff.Fellin@rflelect.com
> 973 334-3100, x 327
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: make install on ppc
From: Geoff Levand @ 2006-03-28 19:06 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev list
In-Reply-To: <f78eb6c06abb98fbc1cf8ae32bbf2268@penguinppc.org>
Hollis Blanchard wrote:
> On Mar 26, 2006, at 7:56 PM, Brent Cook wrote:
>
>> On Sunday 26 March 2006 19:42, Jin Qi Huang wrote:
>>> I also think the 'make install' is very useful, now on ia32, the
> 'make
>>> install' provided by the latest kernel linux-2.6.16 not only create
>>> initrd, copy vmlinuz and System.map to /boot directory, but also
>>> update
>>> grub, ppc32 does not provide this useful feature, maybe it is a pity!
>
> The feature sounds like a good idea to me, even if it's just the
> copying files part. Do any PPC distros provide a working installkernel
> script?
Problem is for multi-platform binary builds, 'install' could mean different
things for the different platforms, so to support install, there needs
to be some way to tell the build system what 'install' means that also
works with the muti-platform makefile logic. The current powerpc makefiles
don't have this, and it would take some non-trivial rework to add it.
There is also the question of what install means when cross building.
I run make from a script that I tell the platform. The script does
what's needed for that platform to get it built and installed.
-Geoff
^ permalink raw reply
* Re: [PATCH] Workaround for RTAS bug
From: Mike Kravetz @ 2006-03-28 19:42 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20060327231959.GA15383@w-mikek2.ibm.com>
On Mon, Mar 27, 2006 at 03:20:00PM -0800, Mike Kravetz wrote:
> Also note that the 32 bit version of enter_rtas() should have the same
> work around even though the chances of hitting the bug are much smaller
> due to the lack of DLPAR on 32 bit kernels. However, my assembly skills
> are a bit rusty and the 32 bit code doesn't seem to follow the conventions
> for where things should be saved. In addition, I don't have a system
> to test 32 bit kernels. Help creating and at least touch testing the
> same workaround for 32 bit would be appreciated.
Upon further examination, there does not appear to be any exposure to
this issue on 32 bit kernels. Therefore, the original patch for 64 bit
should be the only workaround that is required.
--
Mike
^ permalink raw reply
* Re: make install on ppc
From: Hollis Blanchard @ 2006-03-28 20:02 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev list
In-Reply-To: <44298929.1060003@am.sony.com>
On Tuesday 28 March 2006 13:06, you wrote:
> Problem is for multi-platform binary builds, 'install' could mean differe=
nt
> things for the different platforms, so to support install, there needs
> to be some way to tell the build system what 'install' means that also
> works with the muti-platform makefile logic. =C2=A0The current powerpc ma=
kefiles
> don't have this, and it would take some non-trivial rework to add it.
That is for the distribution- or user-supplied installkernel script to deal=
=20
with.
> There is also the question of what install means when cross building.
So don't run make install when cross-compiling (unless of course your=20
installkernel script supports that).
I don't understand these objections. If someone's platform is so super-spec=
ial=20
that a script couldn't possibly know how to install a kernel, just don't ru=
n=20
make install!
=2DHollis
^ permalink raw reply
* Re: make install on ppc
From: Geoff Levand @ 2006-03-28 20:30 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev list
In-Reply-To: <200603281402.02449.hollis@penguinppc.org>
Hollis Blanchard wrote:
> On Tuesday 28 March 2006 13:06, you wrote:
>> Problem is for multi-platform binary builds, 'install' could mean different
>> things for the different platforms, so to support install, there needs
>> to be some way to tell the build system what 'install' means that also
>> works with the muti-platform makefile logic. The current powerpc makefiles
>> don't have this, and it would take some non-trivial rework to add it.
>
> That is for the distribution- or user-supplied installkernel script to deal
> with.
To handle the situation I mentioned, the build system would need to either tell
the installkernel script what to do, or call different installkernel scripts,
so the build system itself needs to have some notion of what install means,
but as I mentioned, that is currently missing from the makefiles.
>> There is also the question of what install means when cross building.
>
> So don't run make install when cross-compiling (unless of course your
> installkernel script supports that).
But I would like to...
> I don't understand these objections. If someone's platform is so super-special
> that a script couldn't possibly know how to install a kernel, just don't run
> make install!
I guess you misunderstood me. I'm not objecting nor saying it shouldn't be
done, just stating some of what needs to be done to make it work properly.
The logic needed is not trivial, and more work is needed than just adding
an 'install' target line to a makefile.
-Geoff
^ permalink raw reply
* Re: Kernel for MPC Lite 5200 will not compile
From: Sylvain Munaut @ 2006-03-28 20:47 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-embedded
In-Reply-To: <4b73d43f0603280815n3fc7bb5dq38b72f87f18b905f@mail.gmail.com>
Hi Matthias,
You might want to try the "quick start" section of
http://www.246tnt.com/mpc52xx/
The last compile I tried worked just fine ... You just needed to be sure
CONFIG_NET is
enabled (even if you don't use network ... the issue is known and being
taken care of,
I've seen some posts of Russel King and Andrew Morton about it).
If it still doesnt work, report it and I'll have a closer look. Maybe
something changed
recently and I didn't update my tree since a few days ...
Sylvain
John Rigby wrote:
> Sorry I'm not sure what the state of 5200 support in the eldk. I know
> that Wolfgang
> has said that 2.6 is not supported though. You may want to try out
> Sylvains
> kernel: http://gitbits.246tnt.com/gitbits/linux-2.6-mpc52xx.git
>
> You can search in list for Syvains instructions on how to use it.
>
>
> On 3/28/06, *Matthias Fechner* <idefix@fechner.net
> <mailto:idefix@fechner.net>> wrote:
>
> Hello John,
>
> * John Rigby <jcrigby@gmail.com <mailto:jcrigby@gmail.com>>
> [27-03-06 18:01]:
> > try make lite5200_defconfig instead of copying it to .config
> > or make oldconfig after copying ti to .config
>
> I tried now several combinations with:
> make ARCH=ppc CROSS_COMPILE=ppc_6xx- lite5200_defconfig
> make ARCH=ppc CROSS_COMPILE=ppc_6xx- uImage
>
> then coping the file to .config and
> make ARCH=ppc CROSS_COMPILE=ppc_6xx- oldconfig
> make ARCH=ppc CROSS_COMPILE=ppc_6xx- uImage
>
> but it always leads to the same error message...
>
> Best regards,
> Matthias
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org <mailto:Linuxppc-embedded@ozlabs.org>
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: make install on ppc
From: Paul Mackerras @ 2006-03-28 21:13 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev list
In-Reply-To: <200603281402.02449.hollis@penguinppc.org>
Hollis Blanchard writes:
> I don't understand these objections. If someone's platform is so super-special
> that a script couldn't possibly know how to install a kernel, just don't run
> make install!
I don't see any problem either. If someone had bothered to produce a
patch, it would have been applied by now. :)
Paul.
^ permalink raw reply
* Re: snd-aoa & rates
From: Benjamin Herrenschmidt @ 2006-03-28 22:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list
In-Reply-To: <1143548101.13615.30.camel@localhost>
On Tue, 2006-03-28 at 14:15 +0200, Johannes Berg wrote:
> Hi,
>
> > Current snd-aoa blew up on me at module load btw ... anyway, that's not
> > my point here :)
>
> Yeah, keywest programming. Need help, see other mail.
No other mail in the box ...
^ permalink raw reply
* Re: 2.6.16 does not boot on powerbook
From: Benjamin Herrenschmidt @ 2006-03-28 22:07 UTC (permalink / raw)
To: wrobell; +Cc: linuxppc-dev
In-Reply-To: <1143556705.3562.104.camel@RECENT-CONVERT>
On Tue, 2006-03-28 at 15:38 +0100, wrobell wrote:
> On Tue, 2006-03-28 at 14:01 +0200, Michal Purzynski wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > hey,
> >
> > i've just installed 2.6.16 vanilla kernel on powerbook G4 but it cannot
> > boot.
> [...]
> > my kernel config (the same config works on 2.6.15)
> [...]
> > # CONFIG_PPC_PMAC is not set
>
> you have to go through configuration options carefully.
> some of them are disabled because of ppc32/64 arch merging changes
> (please correct me if i am wrong).
There is a pmac32_defconfig you can use as a basis now.
Ben.
^ permalink raw reply
* Re: 2.6.16 does not boot on powerbook
From: Benjamin Herrenschmidt @ 2006-03-28 22:08 UTC (permalink / raw)
To: Dustin Lang; +Cc: linuxppc-dev, Michal Purzynski
In-Reply-To: <Pine.LNX.4.60.0603280630130.8520@tin.icics.ubc.ca>
> 2.6.16 works fine on my PowerBook 6,2. When I patched up to 2.6.16 I
> found I had to go through the config process - some of the PowerMac
> options seem to have been turned off. Maybe that was just me doing
> something wrong, or maybe some of the Kconfig defaults changed?
Some stuffs changed in Kconfig causing it to stupidly drop most of the
pmac options ...
Ben.
^ permalink raw reply
* Re: Kernel for MPC Lite 5200 will not compile
From: Wolfgang Denk @ 2006-03-28 22:31 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060328000703.GA95672@server.idefix.loc>
In message <20060328000703.GA95672@server.idefix.loc> you wrote:
>
> I installed today ELDK 4.0 for the LITE5200 board (icecube).
There is no "ELDK 4.0 for the LITE5200 board".
> ./install -d /usr/local/eldk ppc_6xx
This installas ELDK 4.0 for PPC 6xx processors. Nothing less, but
nothing more either.
> After compiling u-boot and playing a little bit with it, i tried to
> compile the kernel 2.6.
Which kernel tree are you using? There is no support for MPC5200 in
the DENX Linux tree. Well, some code is there, as there is in the
public 2.6 kernel tree, but it's known to be broken and not supported
by us.
> For this I used the git repository.
Which one?
> I copied the file arch/ppc/configs/lite5200_defconfig to .config, and
> tried the following one:
> make ARCH=ppc CROSS_COMPILE=ppc_6xx- uImage
That's not the official way to build images.
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
We, the unwilling, led by the unknowing, are doing the impossible for
the ungrateful. We have done so much, for so long, with so little, we
are now qualified to do anything with nothing.
^ permalink raw reply
* Re: Kernel for MPC Lite 5200 will not compile
From: Wolfgang Denk @ 2006-03-28 22:33 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-embedded
In-Reply-To: <4b73d43f0603280815n3fc7bb5dq38b72f87f18b905f@mail.gmail.com>
In message <4b73d43f0603280815n3fc7bb5dq38b72f87f18b905f@mail.gmail.com> you wrote:
>
> Sorry I'm not sure what the state of 5200 support in the eldk. I know that
> Wolfgang
> has said that 2.6 is not supported though. You may want to try out Sylvains
Well, that's exxactly the state: not supported (i. e. known to be
broken).
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
Quotation, n. The act of repeating erroneously the words of another.
The words erroneously repeated.
- Ambrose Bierce _The Devil's Dictionary_
^ permalink raw reply
* [PATCH] Janitor: drivers/net/pcnet32: fix incorrect comments
From: Linas Vepstas @ 2006-03-28 22:36 UTC (permalink / raw)
To: tsbogend, donf; +Cc: linuxppc-dev, linux-kernel, jklewis, netdev
Please sign-off/ack/apply and/or forward upstream.
[PATCH] Janitor: drivers/net/pcnet32: fix incorrect comments
The comments concerning how the pcnet32 ethernet device driver selects
the MAC addr to use are incorrect. A recent patch (in the last 3 months)
changed how the code worked, but did not change the comments.
Side comment: the new behaviour is good; I've got a pcnet32 card which
powers up with garbage in the CSR's, and a good MAC addr in the PROM.
Signed-off-by: Linas Vepstas <linas@linas.org>
----
drivers/net/pcnet32.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.16-git6/drivers/net/pcnet32.c
===================================================================
--- linux-2.6.16-git6.orig/drivers/net/pcnet32.c 2006-03-23 12:21:41.000000000 -0600
+++ linux-2.6.16-git6/drivers/net/pcnet32.c 2006-03-28 16:08:23.398158717 -0600
@@ -1167,8 +1167,8 @@ pcnet32_probe1(unsigned long ioaddr, int
* station address PROM at the base address and programmed into the
* "Physical Address Registers" CSR12-14.
* As a precautionary measure, we read the PROM values and complain if
- * they disagree with the CSRs. Either way, we use the CSR values, and
- * double check that they are valid.
+ * they disagree with the CSRs. If they miscompare, and the PROM addr
+ * is valid, then the PROM addr is used.
*/
for (i = 0; i < 3; i++) {
unsigned int val;
^ permalink raw reply
* [PATCH] DTC - validation by device_type
From: Paul Nasrat @ 2006-03-28 22:49 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
Jon,
It'd be nice to be able to validate by device_type, to ensure that we
don't reinvent the wheel (address vs. local-mac-address) and to give
embedded designers an added level of sanity checking.
Here is a proposed implementation with an implemented check for
"network".
Signed-off-by: Paul Nasrat <pnasrat@redhat.com>
diff --git a/livetree.c b/livetree.c
index ef54174..351773b 100644
--- a/livetree.c
+++ b/livetree.c
@@ -441,6 +441,52 @@ static int check_structure(struct node *
(propname), (node)->fullpath); \
} while (0)
+static int check_network(struct node *net)
+{
+
+ int ok = 1;
+ struct property *prop;
+
+ CHECK_HAVE_STREQ(net, "device_type", "network");
+ CHECK_HAVE(net, "reg");
+ CHECK_HAVE(net, "local-mac-address");
+ CHECK_HAVE(net, "mac-address");
+ CHECK_HAVE(net, "address-bits");
+
+ return ok;
+}
+
+static struct {
+ char *devtype;
+ int (*check_fn)(struct node *node);
+} devtype_checker_table[] = {
+ {"network", check_network},
+};
+
+static int check_devtypes(struct node *root)
+{
+
+ struct node *child;
+ struct property *prop;
+ int ok = 1;
+ int i;
+
+ for_each_child(root, child) {
+ /* check this node */
+ if ((prop = get_property((child), ("device_type"))))
+ for (i = 0; i < ARRAY_SIZE(devtype_checker_table); i++) {
+ if (streq(prop->val.val, devtype_checker_table[i].devtype))
+ if (! devtype_checker_table[i].check_fn(child)) {
+ ok = 0;
+ break;
+ }
+ }
+ ok = check_devtypes(child);
+ }
+
+ return ok;
+}
+
static int check_root(struct node *root)
{
struct property *prop;
@@ -716,6 +762,7 @@ int check_device_tree(struct node *dt)
ok = ok && check_cpus(dt);
ok = ok && check_memory(dt);
ok = ok && check_chosen(dt);
+ ok = ok && check_devtypes(dt);
if (! ok)
return 0;
^ permalink raw reply related
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