Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
Hi Greg: We have obtained GPL 2 only header from Synopsis. We have also identified all parties that contributed to the code base and contacted them regarding license change. Any party that we could not reach, we will remove the patch from the submission. Let me know if this is sufficient for resubmission. Thanks Feng On Thu, Jul 29, 2010 at 8:36 PM, Greg KH wrote: > On Thu, Jul 29, 2010 at 07:02:44PM -0700, Feng Kan wrote: >> On Thu, Jul 29, 2010 at 6:26 PM, Greg KH wrote: >> > On Thu, Jul 29, 2010 at 06:19:25PM -0700, Feng Kan wrote: >> >> Hi Greg: >> >> >> >> On Thu, Jul 29, 2010 at 5:50 PM, Greg KH wrote: >> >> > On Thu, Jul 29, 2010 at 05:14:59PM -0700, Feng Kan wrote: >> >> >> Hi Greg: >> >> >> >> >> >> We will change to a BSD 3 clause license header. Our legal counsel is >> >> >> talking to Synopsis to make this change. >> >> > >> >> > Why BSD? ??You do realize what that means when combined within the body >> >> > of the kernel, right? >> >> > >> >> >> >> FKAN: We will shoot for a dual BSD/GPL license such as the one in the HP >> >> ?? ?? ?? ?? ?? ??Hil driver. >> > >> > What specific driver is this? >> >> FKAN: this is driver/input/serio/hil_mlc.c and quite a number of others. > > Ok, thanks. > > Are you _sure_ that you didn't take any existing GPL code and put it > into this driver when making it? Did all contributors to the code > release their contributions under both licenses? > >> > And are you sure that all of the contributors to the code agree with >> > this licensing change? ??Are you going to require contributors to >> > dual-license their changes? >> > >> > If so, why keep it BSD, what does that get you? >> >> FKAN: for one thing, to make it future proof on other submissions. > > What do you mean by this? What can you do with this code other than use > it on a Linux system? You can't put it into any other operating system > with a different license, can you? > >> >> > Are you going to be expecting others to contribute back to the code >> >> > under this license, or will you accept the fact that future >> >> > contributions from the community will cause the license to change? >> > >> > >> > You didn't answer this question, which is a very important one before I >> > can accept this driver. >> >> FKAN: Yes, all of the above. Our legal is working on that. I thought by >> default >> GPL defines the above statement. > > The GPL does, but as you are trying to dual-license the code, you have > to be careful about how you accept changes, and under what license. > It's a lot more work than I think you realize. What process do you have > in place to handle this? > >> >> >> We will resubmit once this is in place. Please let me know if you have >> >> >> any additional concerns. >> >> > >> >> > My main concern is that you, and everyone else involved in the driver, >> >> > never considered the license of the code in the first place and expected >> >> > the kernel community to accept it as-is, placing the problem on us. >> >> >> >> FKAN: Please don't think this is the case, we gone through this exercise >> >> ?? ?? ?? ?? ?? with Denx. >> > >> > What is "Denx"? >> >> FKAN: U-Boot Denx.de > > Ah, thanks. > >> >> We had legal looking into the header before submission >> >> ?? ?? ?? ?? ?? to them and the kernel. >> > >> > Then what happened here? ??Just curious as to how the driver was public >> > for so long before someone realized this. >> > >> >> FKAN: this was few years back. At the time we had the header changed >> so it was BSD like to be accepted by Denx. >> >> >> > What will be done in the future to prevent this from happening again? >> >> >> >> FKAN: agreed, once bitten :) >> > >> > That didn't answer the question :) >> >> FKAN: we have a system of checks for every patch that goes out. I will send >> out a guideline to all reviewer to make sure the header >> follow kernel precedence. > > But you took this code from a different vendor, are you able to properly > identify the code contributions to this base and what license it is > under and where they got it from? > >> Legal is quite aware of the issue now too. > > As they should be :) > > Please reconsider the dual licensing unless you really are ready to > handle the implications of it. > > thanks, > > greg k-h > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
On Thu, Jul 29, 2010 at 6:26 PM, Greg KH wrote: > On Thu, Jul 29, 2010 at 06:19:25PM -0700, Feng Kan wrote: >> Hi Greg: >> >> On Thu, Jul 29, 2010 at 5:50 PM, Greg KH wrote: >> > On Thu, Jul 29, 2010 at 05:14:59PM -0700, Feng Kan wrote: >> >> Hi Greg: >> >> >> >> We will change to a BSD 3 clause license header. Our legal counsel is >> >> talking to Synopsis to make this change. >> > >> > Why BSD? You do realize what that means when combined within the body >> > of the kernel, right? >> > >> >> FKAN: We will shoot for a dual BSD/GPL license such as the one in the HP >> Hil driver. > > What specific driver is this? FKAN: this is driver/input/serio/hil_mlc.c and quite a number of others. > > And are you sure that all of the contributors to the code agree with > this licensing change? Are you going to require contributors to > dual-license their changes? > > If so, why keep it BSD, what does that get you? FKAN: for one thing, to make it future proof on other submissions. > >> > Are you going to be expecting others to contribute back to the code >> > under this license, or will you accept the fact that future >> > contributions from the community will cause the license to change? > > > You didn't answer this question, which is a very important one before I > can accept this driver. FKAN: Yes, all of the above. Our legal is working on that. I thought by default GPL defines the above statement. > >> >> We will resubmit once this is in place. Please let me know if you have >> >> any additional concerns. >> > >> > My main concern is that you, and everyone else involved in the driver, >> > never considered the license of the code in the first place and expected >> > the kernel community to accept it as-is, placing the problem on us. >> >> FKAN: Please don't think this is the case, we gone through this exercise >> with Denx. > > What is "Denx"? FKAN: U-Boot Denx.de > >> We had legal looking into the header before submission >> to them and the kernel. > > Then what happened here? Just curious as to how the driver was public > for so long before someone realized this. > FKAN: this was few years back. At the time we had the header changed so it was BSD like to be accepted by Denx. >> > What will be done in the future to prevent this from happening again? >> >> FKAN: agreed, once bitten :) > > That didn't answer the question :) FKAN: we have a system of checks for every patch that goes out. I will send out a guideline to all reviewer to make sure the header follow kernel precedence. Legal is quite aware of the issue now too. > > thanks, > > greg k-h > -- Feng Kan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
Hi Greg: On Thu, Jul 29, 2010 at 5:50 PM, Greg KH wrote: > On Thu, Jul 29, 2010 at 05:14:59PM -0700, Feng Kan wrote: >> Hi Greg: >> >> We will change to a BSD 3 clause license header. Our legal counsel is >> talking to Synopsis to make this change. > > Why BSD? You do realize what that means when combined within the body > of the kernel, right? > FKAN: We will shoot for a dual BSD/GPL license such as the one in the HP Hil driver. > Are you going to be expecting others to contribute back to the code > under this license, or will you accept the fact that future > contributions from the community will cause the license to change? > >> We will resubmit once this is in place. Please let me know if you have >> any additional concerns. > > My main concern is that you, and everyone else involved in the driver, > never considered the license of the code in the first place and expected > the kernel community to accept it as-is, placing the problem on us. FKAN: Please don't think this is the case, we gone through this exercise with Denx. We had legal looking into the header before submission to them and the kernel. > > What will be done in the future to prevent this from happening again? FKAN: agreed, once bitten :) > > thanks, > > greg k-h > -- Feng Kan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
Hi Greg: We will change to a BSD 3 clause license header. Our legal counsel is talking to Synopsis to make this change. We will resubmit once this is in place. Please let me know if you have any additional concerns. Feng Kan Applied Micro On Mon, Jul 26, 2010 at 4:16 PM, Greg KH wrote: > On Mon, Jul 26, 2010 at 04:05:49PM -0700, Feng Kan wrote: >> Hi Greg: >> >> We are having our legal revisit this again. What would you advise us >> to do at this point? > > I thought I was very clear below as to what is needed. > >> Disclose the agreement or have someone with legal authority reply this >> thread. > > Neither will resolve the end issue, right? > >> Perhaps something in the header that states Applied Micro verified >> with Synopsys to use this code for GPL purpose. > > No, that will just make it messier. Someone needs to delete all of the > mess in the file, put the proper license information for what the code > is being licensed under (whatever it is), and provide a signed-off-by > from a person from Synopsys and APM that can speak for the company that > they agree that the code can properly be placed into the Linux kernel. > > thanks, > > greg k-h > -- Feng Kan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
Hi Greg: We are having our legal revisit this again. What would you advise us to do at this point? Disclose the agreement or have someone with legal authority reply this thread. Perhaps something in the header that states Applied Micro verified with Synopsys to use this code for GPL purpose. Feng Kan On Mon, Jul 26, 2010 at 3:08 PM, Greg KH wrote: > On Mon, Jul 26, 2010 at 03:05:13PM -0700, Greg KH wrote: >> Please, someone needs to go run this past the Synopsys lawyers (yeah, >> sorry, that's horrible to do, but it needs to be done to get it >> correct.) >> >> Because of this, I'd like to get a lawyer's signed-off-by on the code as >> well just to verify that it's all ok. > > Or someone with the legal authority to verify that this is an action > that Synopsys agrees with the license of the code now. This usually > means a VP or some such person that can act publicly for the company. > > thanks, > > greg k-h > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/9 v1.01] Add Synopsys DesignWare HS USB OTG Controller driver.
Chuck: Thanks for the information. Sorry that we missed the patch. It was not done out of specific reason. As you have commented, it is a very large patch with alot of changes. We wanted to submit the patch to make sure the fundamental structure of the driver align with the kernel. Once that is in place, additional patch will be easier. Fushen will make sure this change is in place on the next submission. Thanks Feng Kan On Tue, Jul 13, 2010 at 3:16 PM, Chuck Meade wrote: > On 07/12/2010 07:16 PM, Fushen Chen wrote: > > The DWC OTG driver module provides the initialization and cleanup > > entry points for the DWC OTG USB driver. > > > > Signed-off-by: Fushen Chen > > Signed-off-by: Mark Miesfeld > > --- > > This reply is to the patch series, not just this 1/9 patch section. > > Fushen, why did you pick and choose which fixes to incorporate from the > Denx > tree's version of the dwc_otg driver? > > I'm not taking the time here to go through this multipart patch and check > that > you incorporated every fix, but I *did* randomly pick one fix that I made > to that > driver, to see if you incorporated it, and it appears you did not. > I would have expected that you would have incorporated the fixes that were > made > to this driver in the Denx tree. > > The one that I checked is in the data toggle error interrupt handling, in > handle_hc_chhltd_intr_dma() (see your 5/9 email in this patch series). It > looks > like you left out the fix I made to this logic that averts an interrupt > storm. > > I assume that since I checked one particular fix, and it was missing from > your > patch series, that there are likely more fixes you omitted. Can you > explain why > you would leave this out, after Stefan asked you to incorporate the code > changes > made in the Denx tree's version of the driver? > > Chuck > _______ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev > -- Feng Kan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] fix the problem where pcix node is probed again as pci node.
Ok thanks. This short string match may be useful in some cases, but I
agree it plays havoc with the current code.
Feng Kan
On Mar 30, 2010, at 14:14, "Benjamin Herrenschmidt" > wrote:
On Wed, 2010-03-31 at 07:48 +1100, Benjamin Herrenschmidt wrote:
On Tue, 2010-03-30 at 10:41 -0700, Feng Kan wrote:
From: Feng Kan
The current matching scheme make the pci node match to pcix or
pciex node.
To avoid the match, change the method so only one type of
initialization
is called per node.
No, your patch is not right. The problem was introduced by a patch
from
Grant that incorrectly made of_device_is_compatible do a substring
match. Grant should have fixed that now. Grant ? Is your fix upstream
yet ? If not, can you send that ASAP ?
Better if I CC him too :-)
Cheers,
Ben.
Cheers,
Ben.
Signed-off-by: Feng Kan
Signed-off-by: Tirumala R Marri
---
arch/powerpc/sysdev/ppc4xx_pci.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/
sysdev/ppc4xx_pci.c
index 8aa3302..1e67c74 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -1842,14 +1842,16 @@ static int __init ppc4xx_pci_find_bridges
(void)
ppc_pci_flags |= PPC_PCI_ENABLE_PROC_DOMAINS |
PPC_PCI_COMPAT_DOMAIN_0;
+for_each_compatible_node(np, NULL, "ibm,plb-pci") {
+if (of_device_is_compatible(np, "ibm,plb-pcix"))
+ppc4xx_probe_pcix_bridge(np);
#ifdef CONFIG_PPC4xx_PCI_EXPRESS
-for_each_compatible_node(np, NULL, "ibm,plb-pciex")
-ppc4xx_probe_pciex_bridge(np);
+else if (of_device_is_compatible(np, "ibm,plb-pciex"))
+ppc4xx_probe_pciex_bridge(np);
#endif
-for_each_compatible_node(np, NULL, "ibm,plb-pcix")
-ppc4xx_probe_pcix_bridge(np);
-for_each_compatible_node(np, NULL, "ibm,plb-pci")
-ppc4xx_probe_pci_bridge(np);
+else
+ppc4xx_probe_pci_bridge(np);
+}
return 0;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] fix the problem where pcix node is probed again as pci node.
From: Feng Kan
The current matching scheme make the pci node match to pcix or pciex node.
To avoid the match, change the method so only one type of initialization
is called per node.
Signed-off-by: Feng Kan
Signed-off-by: Tirumala R Marri
---
arch/powerpc/sysdev/ppc4xx_pci.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index 8aa3302..1e67c74 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -1842,14 +1842,16 @@ static int __init ppc4xx_pci_find_bridges(void)
ppc_pci_flags |= PPC_PCI_ENABLE_PROC_DOMAINS | PPC_PCI_COMPAT_DOMAIN_0;
+ for_each_compatible_node(np, NULL, "ibm,plb-pci") {
+ if (of_device_is_compatible(np, "ibm,plb-pcix"))
+ ppc4xx_probe_pcix_bridge(np);
#ifdef CONFIG_PPC4xx_PCI_EXPRESS
- for_each_compatible_node(np, NULL, "ibm,plb-pciex")
- ppc4xx_probe_pciex_bridge(np);
+ else if (of_device_is_compatible(np, "ibm,plb-pciex"))
+ ppc4xx_probe_pciex_bridge(np);
#endif
- for_each_compatible_node(np, NULL, "ibm,plb-pcix")
- ppc4xx_probe_pcix_bridge(np);
- for_each_compatible_node(np, NULL, "ibm,plb-pci")
- ppc4xx_probe_pci_bridge(np);
+ else
+ ppc4xx_probe_pci_bridge(np);
+ }
return 0;
}
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/1] NDFC: add support for alternate ECC format for ndfc
Hi Sean: I will withdraw this patch. I had a talk with the U-Boot guys. The reason for this patch was to support those guys that had their ECC ordering at (213) on the older version of the kernel. Upgrading to (123) may be problematic. Since without a jtag it would be a bit complex. I still think this NAND_ECC_SMC define is somewhat missleading. Given that both 1-2-3 and 2-1-3 are supported by the correction routine. Feng From: Sean MacLennan [mailto:smaclen...@pikatech.com] Sent: Sat 2/20/2010 5:11 PM To: Feng Kan Cc: linux-...@lists.infradead.org; linuxppc-...@ozlabs.org; Feng Kan Subject: Re: [PATCH 1/1] NDFC: add support for alternate ECC format for ndfc On Thu, 18 Feb 2010 15:11:18 -0800 Feng Kan wrote: > This is to lock down the ordering in the correction routine against > the calculate routine. Otherwise, incorrect define would cause ECC > errors. Did you actually find a 44x PPC core that is not NAND_ECC_SMS format? Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/1] NDFC: add support for alternate ECC format for ndfc
This is to lock down the ordering in the correction routine against the calculate routine. Otherwise, incorrect define would cause ECC errors. Signed-off-by: Feng Kan Acked-by: Victor Gallardo --- drivers/mtd/nand/ndfc.c |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c index 40b5658..fc1f0ff 100644 --- a/drivers/mtd/nand/ndfc.c +++ b/drivers/mtd/nand/ndfc.c @@ -102,10 +102,15 @@ static int ndfc_calculate_ecc(struct mtd_info *mtd, wmb(); ecc = in_be32(ndfc->ndfcbase + NDFC_ECC); /* The NDFC uses Smart Media (SMC) bytes order */ +#ifdef CONFIG_MTD_NAND_ECC_SMC ecc_code[0] = p[1]; ecc_code[1] = p[2]; ecc_code[2] = p[3]; +#else + ecc_code[0] = p[2]; + ecc_code[1] = p[1]; + ecc_code[2] = p[3]; +#endif return 0; } -- 1.5.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/1] Fix ECC Correction bug for SMC ordering for NDFC driver.
Yes, I have considered that. However, it would make the #define rather confusing for the rest. Cheers, Feng -Original Message- From: Sean MacLennan [mailto:smaclen...@pikatech.com] Sent: Fri 8/21/2009 11:55 AM To: Feng Kan Cc: linuxppc-...@ozlabs.org; linux-...@lists.infradead.org; Feng Kan Subject: Re: [PATCH 1/1] Fix ECC Correction bug for SMC ordering for NDFC driver. On Thu, 20 Aug 2009 17:19:17 -0700 Feng Kan wrote: > Fix ECC Correction bug where the byte offset location were double > fliped causing correction routine to toggle the wrong byte location > in the ECC segment. The ndfc_calculate_ecc routine change the order > of getting the ECC code. It looks like another fix for this bug is to leave the current code alone and turn off CONFIG_MTD_NAND_ECC_SMC. This could be a better fix if this is the way u-boot currently works. Has anybody verified if the current u-boot has the ECC problem? Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/1] Fix ECC Correction bug for SMC ordering for NDFC driver.
Fix ECC Correction bug where the byte offset location were double fliped causing correction routine to toggle the wrong byte location in the ECC segment. The ndfc_calculate_ecc routine change the order of getting the ECC code. /* The NDFC uses Smart Media (SMC) bytes order */ ecc_code[0] = p[2]; ecc_code[1] = p[1]; ecc_code[2] = p[3]; But in the Correction algorithm when calculating the byte offset location, the b1 is used as the upper part of the address. Which again reverse the order making the final byte offset address location incorrect. byte_addr = (addressbits[b1] << 4) + addressbits[b0]; The order is change to read it in straight and let the correction function to revert it to SMC order. Signed-off-by: Feng Kan Acked-by: Victor Gallardo Acked-by: Prodyut Hazarika --- drivers/mtd/nand/ndfc.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c index 5906c40..d9d3e6e 100644 --- a/drivers/mtd/nand/ndfc.c +++ b/drivers/mtd/nand/ndfc.c @@ -101,8 +101,8 @@ static int ndfc_calculate_ecc(struct mtd_info *mtd, wmb(); ecc = in_be32(ndfc->ndfcbase + NDFC_ECC); /* The NDFC uses Smart Media (SMC) bytes order */ - ecc_code[0] = p[2]; - ecc_code[1] = p[1]; + ecc_code[0] = p[1]; + ecc_code[1] = p[2]; ecc_code[2] = p[3]; return 0; -- 1.5.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [U-Boot] NAND ECC Error with wrong SMC ording bug
Hi Stefan: We had a board with high number of correctable ECC errors. Which crashed the jffs when it was miss correcting the wrong byte location. Do you want me to submit a patch for this, or do you prefer to do it. I am submitting a patch for linux right now. Feng Kan AMCC Software On 08/19/2009 10:01 PM, Stefan Roese wrote: On Thursday 20 August 2009 06:38:51 Sean MacLennan wrote: I see other boards using SMC as well, can someone comment on the change I am proposing. Should I change the correction algorithm or the calculate function? If the later is preferred it would mean the change must be pushed in both U-Boot and Linux. Odds are the calculate function is wrong. The correction algo is used by many nand drivers, I *assume* it is correct. The calculate function was set to agree with u-boot (1.3.0). Yes, it seems that you changed the order in the calculation function while reworking the NDFC driver for arch/powerpc. So we should probably change this order back to the original version. And change it in U-Boot as well. BTW: I didn't see any problems with ECC so far with the current code. Feng, how did you spot this problem? Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk& Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
NAND ECC Error with wrong SMC ording bug
Hi All:
It seems that the ECC correction is broken on the Linux with the 4xx
NDFC driver.
It uses the SMC order when reading the ECC code. 2-1-3
static int ndfc_calculate_ecc(struct mtd_info *mtd,
const u_char *dat, u_char *ecc_code)
{
struct ndfc_controller *ndfc = &ndfc_ctrl;
uint32_t ecc;
uint8_t *p = (uint8_t *)&ecc;
wmb();
ecc = in_be32(ndfc->ndfcbase + NDFC_ECC);
/* The NDFC uses Smart Media (SMC) bytes order */
ecc_code[0] = p[2];
ecc_code[1] = p[1];
ecc_code[2] = p[3];
return 0;
}
However, when in the correction function, the byte address order is
again reverses
causing incorrect byte location.
* performace it does not make any difference
*/
if (eccsize_mult == 1)
byte_addr = (addressbits[b0] << 4) +
addressbits[b1];
>>>> The above really should be byte_addr = (addressbits[b1] << 4) +
addressbits[b0];
else
byte_addr = (addressbits[b2 & 0x3] << 8) +
(addressbits[b1] << 4) +
addressbits[b0];
bit_addr = addressbits[b2 >> 2];
/* flip the bit */
buf[byte_addr] ^= (1 << bit_addr);
printk(KERN_INFO "Corrected b[0] 0x%x b[1]0x%x\n", b0, b1);
printk(KERN_INFO "cal ecc b[0] 0x%x b[1]0x%x\n",
calc_ecc[0] , calc_ecc[1]);
printk(KERN_INFO "read ecc b[0] 0x%x b[1]0x%x\n",
read_ecc[0] , read_ecc[1]);
return 1;
I see other boards using SMC as well, can someone comment on the change
I am proposing.
Should I change the correction algorithm or the calculate function? If
the later is preferred
it would mean the change must be pushed in both U-Boot and Linux.
Feng Kan
AMCC Software
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1 v1] powerpc44x: Add Eiger AMCC (AppliedMicro) PPC460SX evaluation board support.
Please do, much appreciated. Thanks Feng Kan AMCC Software On 08/17/2009 08:34 AM, Josh Boyer wrote: On Wed, Aug 12, 2009 at 05:38:47PM -0700, Feng Kan wrote: This patch adds support for the AMCC (AppliedMicro) PPC460SX Eiger evaluation board. Signed-off-by: Tai Tri Nguyen Acked-by: Feng Kan Acked-by: Tirumala Marri --- arch/powerpc/boot/dts/eiger.dts| 421 ++ arch/powerpc/configs/44x/eiger_defconfig | 1200 arch/powerpc/platforms/44x/Kconfig | 12 + arch/powerpc/platforms/44x/ppc44x_simple.c |1 + 4 files changed, 1634 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/boot/dts/eiger.dts create mode 100644 arch/powerpc/configs/44x/eiger_defconfig Thanks, this looks great. If you have no objections, I will commit an updated defconfig against the current kernel sources instead of the one attached. Some of the options will move around a bit, but there should be no overall changes. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1 v1] powerpc44x: Add Eiger AMCC (AppliedMicro) PPC460SX evaluation board support.
Hi Felix:
Sorry the documentation seems a little miss leading. There is no harm
with the bit
turned off to zero. Once the nand boot is over, we change the EBC to use
the ready
signal, this bit does not affect performance anymore.
Thanks
Feng Kan
On 08/12/2009 11:14 PM, Felix Radensky wrote:
Hi,
Feng Kan wrote:
This patch adds support for the AMCC (AppliedMicro) PPC460SX Eiger
evaluation board.
Signed-off-by: Tai Tri Nguyen
Acked-by: Feng Kan
Acked-by: Tirumala Marri
---
arch/powerpc/boot/dts/eiger.dts| 421 ++
arch/powerpc/configs/44x/eiger_defconfig | 1200
arch/powerpc/platforms/44x/Kconfig | 12 +
arch/powerpc/platforms/44x/ppc44x_simple.c |1 +
4 files changed, 1634 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/eiger.dts
create mode 100644 arch/powerpc/configs/44x/eiger_defconfig
diff --git a/arch/powerpc/boot/dts/eiger.dts
b/arch/powerpc/boot/dts/eiger.dts
new file mode 100644
index 000..c4a934f
--- /dev/null
+++ b/arch/powerpc/boot/dts/eiger.dts
@@ -0,0 +1,421 @@
+/*
+ * Device Tree Source for AMCC (AppliedMicro) Eiger(460SX)
+ *
+ * Copyright 2009 AMCC (AppliedMicro)
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+
+/ {
+#address-cells = <2>;
+#size-cells = <1>;
+model = "amcc,eiger";
+compatible = "amcc,eiger";
+dcr-parent = <&{/cpus/c...@0}>;
+
+aliases {
+ethernet0 = &EMAC0;
+ethernet1 = &EMAC1;
+ethernet2 = &EMAC2;
+ethernet3 = &EMAC3;
+serial0 = &UART0;
+serial1 = &UART1;
+};
+
+cpus {
+#address-cells = <1>;
+#size-cells = <0>;
+
+c...@0 {
+device_type = "cpu";
+model = "PowerPC,460SX";
+reg = <0x>;
+clock-frequency = <0>; /* Filled in by U-Boot */
+timebase-frequency = <0>; /* Filled in by U-Boot */
+i-cache-line-size = <32>;
+d-cache-line-size = <32>;
+i-cache-size = <32768>;
+d-cache-size = <32768>;
+dcr-controller;
+dcr-access-method = "native";
+};
+};
+
+memory {
+device_type = "memory";
+reg = <0x 0x 0x>; /* Filled in by
U-Boot */
+};
+
+UIC0: interrupt-controller0 {
+compatible = "ibm,uic-460sx","ibm,uic";
+interrupt-controller;
+cell-index = <0>;
+dcr-reg = <0x0c0 0x009>;
+#address-cells = <0>;
+#size-cells = <0>;
+#interrupt-cells = <2>;
+};
+
+UIC1: interrupt-controller1 {
+compatible = "ibm,uic-460sx","ibm,uic";
+interrupt-controller;
+cell-index = <1>;
+dcr-reg = <0x0d0 0x009>;
+#address-cells = <0>;
+#size-cells = <0>;
+#interrupt-cells = <2>;
+interrupts = <0x1e 0x4 0x1f 0x4>; /* cascade */
+interrupt-parent = <&UIC0>;
+};
+
+UIC2: interrupt-controller2 {
+compatible = "ibm,uic-460sx","ibm,uic";
+interrupt-controller;
+cell-index = <2>;
+dcr-reg = <0x0e0 0x009>;
+#address-cells = <0>;
+#size-cells = <0>;
+#interrupt-cells = <2>;
+interrupts = <0xa 0x4 0xb 0x4>; /* cascade */
+interrupt-parent = <&UIC0>;
+};
+
+UIC3: interrupt-controller3 {
+compatible = "ibm,uic-460sx","ibm,uic";
+interrupt-controller;
+cell-index = <3>;
+dcr-reg = <0x0f0 0x009>;
+#address-cells = <0>;
+#size-cells = <0>;
+#interrupt-cells = <2>;
+interrupts = <0x10 0x4 0x11 0x4>; /* cascade */
+interrupt-parent = <&UIC0>;
+};
+
+SDR0: sdr {
+compatible = "ibm,sdr-460sx";
+dcr-reg = <0x00e 0x002>;
+};
+
+CPR0: cpr {
+compatible = "ibm,cpr-460sx";
+dcr-reg = <0x00c 0x002>;
+};
+
+plb {
+compatible = "ibm,plb-460sx", "ibm,plb4";
+#address-cells = <2>;
+#size-cells = <1>;
+ranges;
+clock-frequency = <0>; /* Filled in by U-Boot */
+
+SDRAM0: sdram {
+compatible = "ibm,sdram-460sx", "ibm,sdram-405gp";
+dcr-reg = <0x010 0x002>;
+};
+
+MAL0: mcmal {
+compatible = "ibm,mcmal
[PATCH 1/1 v1] powerpc44x: Add Eiger AMCC (AppliedMicro) PPC460SX evaluation board support.
This patch adds support for the AMCC (AppliedMicro) PPC460SX Eiger evaluation
board.
Signed-off-by: Tai Tri Nguyen
Acked-by: Feng Kan
Acked-by: Tirumala Marri
---
arch/powerpc/boot/dts/eiger.dts| 421 ++
arch/powerpc/configs/44x/eiger_defconfig | 1200
arch/powerpc/platforms/44x/Kconfig | 12 +
arch/powerpc/platforms/44x/ppc44x_simple.c |1 +
4 files changed, 1634 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/eiger.dts
create mode 100644 arch/powerpc/configs/44x/eiger_defconfig
diff --git a/arch/powerpc/boot/dts/eiger.dts b/arch/powerpc/boot/dts/eiger.dts
new file mode 100644
index 000..c4a934f
--- /dev/null
+++ b/arch/powerpc/boot/dts/eiger.dts
@@ -0,0 +1,421 @@
+/*
+ * Device Tree Source for AMCC (AppliedMicro) Eiger(460SX)
+ *
+ * Copyright 2009 AMCC (AppliedMicro)
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ model = "amcc,eiger";
+ compatible = "amcc,eiger";
+ dcr-parent = <&{/cpus/c...@0}>;
+
+ aliases {
+ ethernet0 = &EMAC0;
+ ethernet1 = &EMAC1;
+ ethernet2 = &EMAC2;
+ ethernet3 = &EMAC3;
+ serial0 = &UART0;
+ serial1 = &UART1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ c...@0 {
+ device_type = "cpu";
+ model = "PowerPC,460SX";
+ reg = <0x>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ timebase-frequency = <0>; /* Filled in by U-Boot */
+ i-cache-line-size = <32>;
+ d-cache-line-size = <32>;
+ i-cache-size = <32768>;
+ d-cache-size = <32768>;
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x 0x>; /* Filled in by
U-Boot */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = "ibm,uic-460sx","ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0x0c0 0x009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = "ibm,uic-460sx","ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0x0d0 0x009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <0x1e 0x4 0x1f 0x4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = "ibm,uic-460sx","ibm,uic";
+ interrupt-controller;
+ cell-index = <2>;
+ dcr-reg = <0x0e0 0x009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <0xa 0x4 0xb 0x4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC3: interrupt-controller3 {
+ compatible = "ibm,uic-460sx","ibm,uic";
+ interrupt-controller;
+ cell-index = <3>;
+ dcr-reg = <0x0f0 0x009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <0x10 0x4 0x11 0x4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ SDR0: sdr {
+ compatible = "ibm,sdr-460sx";
+ dcr-reg = <0x00e 0x002>;
+ };
+
+ CPR0: cpr {
+ compatible = "ibm,cpr-460sx";
+ dcr-reg = <0x00c 0x002>;
+ };
+
+ plb {
+ compatible = "ibm,plb-460sx", "ibm,plb4";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = &l
[PATCH 1/1 v1] powerpc44x: Add Eiger AMCC (AppliedMicro) PPC460SX evaluation board support.
This patch adds support for the AMCC (AppliedMicro) PPC460SX Eiger evaluation
board.
Signed-off-by: Tai Tri Nguyen
Acked-by: Feng Kan
Acked-by: Tirumala Marri
---
arch/powerpc/boot/dts/eiger.dts| 421 ++
arch/powerpc/configs/44x/eiger_defconfig | 1200
arch/powerpc/platforms/44x/Kconfig | 12 +
arch/powerpc/platforms/44x/ppc44x_simple.c |1 +
4 files changed, 1634 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/eiger.dts
create mode 100644 arch/powerpc/configs/44x/eiger_defconfig
diff --git a/arch/powerpc/boot/dts/eiger.dts b/arch/powerpc/boot/dts/eiger.dts
new file mode 100644
index 000..c4a934f
--- /dev/null
+++ b/arch/powerpc/boot/dts/eiger.dts
@@ -0,0 +1,421 @@
+/*
+ * Device Tree Source for AMCC (AppliedMicro) Eiger(460SX)
+ *
+ * Copyright 2009 AMCC (AppliedMicro)
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ model = "amcc,eiger";
+ compatible = "amcc,eiger";
+ dcr-parent = <&{/cpus/c...@0}>;
+
+ aliases {
+ ethernet0 = &EMAC0;
+ ethernet1 = &EMAC1;
+ ethernet2 = &EMAC2;
+ ethernet3 = &EMAC3;
+ serial0 = &UART0;
+ serial1 = &UART1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ c...@0 {
+ device_type = "cpu";
+ model = "PowerPC,460SX";
+ reg = <0x>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ timebase-frequency = <0>; /* Filled in by U-Boot */
+ i-cache-line-size = <32>;
+ d-cache-line-size = <32>;
+ i-cache-size = <32768>;
+ d-cache-size = <32768>;
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x 0x>; /* Filled in by
U-Boot */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = "ibm,uic-460sx","ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0x0c0 0x009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = "ibm,uic-460sx","ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0x0d0 0x009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <0x1e 0x4 0x1f 0x4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = "ibm,uic-460sx","ibm,uic";
+ interrupt-controller;
+ cell-index = <2>;
+ dcr-reg = <0x0e0 0x009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <0xa 0x4 0xb 0x4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC3: interrupt-controller3 {
+ compatible = "ibm,uic-460sx","ibm,uic";
+ interrupt-controller;
+ cell-index = <3>;
+ dcr-reg = <0x0f0 0x009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <0x10 0x4 0x11 0x4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ SDR0: sdr {
+ compatible = "ibm,sdr-460sx";
+ dcr-reg = <0x00e 0x002>;
+ };
+
+ CPR0: cpr {
+ compatible = "ibm,cpr-460sx";
+ dcr-reg = <0x00c 0x002>;
+ };
+
+ plb {
+ compatible = "ibm,plb-460sx", "ibm,plb4";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = &l
RE: ppc405ex + gigabit ethernet
Hi Lada: Please contact supp...@amcc.com for additional help for the coalescing patch. Feng Kan AMCC Software -Original Message- From: linuxppc-dev-bounces+fkan=amcc@lists.ozlabs.org on behalf of Lada Podivin Sent: Fri 7/3/2009 2:09 AM To: Cote, Sylvain Cc: linuxppc-...@ozlabs.org Subject: Re: ppc405ex + gigabit ethernet Hi Sylvain, the interrupt coalescing sounds like good idea - I'm surprised this feature is missing in the original ibm_newemac driver. You wrote you had got this optimisation directly from AMCC. Is it part of any framework? I'm just wondering how one can obtain it. I tried to find any suitable patch but with no success - the old friend Google didn't help this time :) Thank you very much! Lada ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3 v3] Added AMCC 460EX Canyonlands SATA support.
Signed-off-by: Feng Kan
---
arch/powerpc/boot/dts/canyonlands.dts |8 ++
arch/powerpc/platforms/44x/Makefile|4 +
arch/powerpc/platforms/44x/amcc-sata.c | 125
3 files changed, 137 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/44x/amcc-sata.c
diff --git a/arch/powerpc/boot/dts/canyonlands.dts
b/arch/powerpc/boot/dts/canyonlands.dts
index 5fd1ad0..b536223 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -163,6 +163,14 @@
interrupts = <0x1e 4>;
};
+SATA0: s...@bffd1000 {
+compatible = "amcc,sata-460ex";
+ reg = <4 0xbffd1000 0x800 4 0xbffd0800 0x400>;
+interrupt-parent = <&UIC3>;
+interrupts = <0 4 /* SATA */
+ 5 4>; /* AHBDMA */
+};
+
POB0: opb {
compatible = "ibm,opb-460ex", "ibm,opb";
#address-cells = <1>;
diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
index 01f51da..fa0a999 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -4,3 +4,7 @@ obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_SAM440EP) += sam440ep.o
obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
+ifeq ($(CONFIG_SATA_DWC),y)
+obj-$(CONFIG_CANYONLANDS) += amcc-sata.o
+endif
+
diff --git a/arch/powerpc/platforms/44x/amcc-sata.c
b/arch/powerpc/platforms/44x/amcc-sata.c
new file mode 100644
index 000..fdda917
--- /dev/null
+++ b/arch/powerpc/platforms/44x/amcc-sata.c
@@ -0,0 +1,125 @@
+/*
+ * AMCC Canyonlands SATA wrapper
+ *
+ * Copyright 2008 DENX Software Engineering, Stefan Roese
+ *
+ * Extract the resources (MEM & IRQ) from the dts file and put them
+ * into the platform-device struct for usage in the platform-device
+ * SATA driver.
+ *
+ */
+
+#include
+#include
+
+/*
+ * Resource template will be filled dynamically with the values
+ * extracted from the dts file
+ */
+static struct resource sata_resources[] = {
+ [0] = {
+ /* 460EX SATA registers */
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ /* 460EX AHBDMA registers */
+ .flags = IORESOURCE_MEM,
+ },
+ [2] = {
+ /* 460EX SATA IRQ */
+ .flags = IORESOURCE_IRQ,
+ },
+ [3] = {
+ /* 460EX AHBDMA IRQ */
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 dma_mask = 0xULL;
+
+static struct platform_device sata_device = {
+ .name = "sata-dwc",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(sata_resources),
+ .resource = sata_resources,
+ .dev = {
+ .dma_mask = &dma_mask,
+ .coherent_dma_mask = 0xULL,
+ }
+};
+
+static struct platform_device *ppc460ex_devs[] __initdata = {
+ &sata_device,
+};
+
+static int __devinit ppc460ex_sata_probe(struct of_device *ofdev,
+const struct of_device_id *match)
+{
+ struct device_node *np = ofdev->node;
+ struct resource res;
+ const char *val;
+
+ /*
+* Check if device is enabled
+*/
+ val = of_get_property(np, "status", NULL);
+ if (val && !strcmp(val, "disabled")) {
+ printk(KERN_INFO "SATA port disabled via device-tree\n");
+ return 0;
+ }
+
+ /*
+* Extract register address reange from device tree and put it into
+* the platform device structure
+*/
+ if (of_address_to_resource(np, 0, &res)) {
+ printk(KERN_ERR "%s: Can't get SATA register address\n",
+ __func__);
+ return -ENOMEM;
+ }
+ sata_resources[0].start = res.start;
+ sata_resources[0].end = res.end;
+
+ if (of_address_to_resource(np, 1, &res)) {
+ printk(KERN_ERR "%s: Can't get AHBDMA register address\n",
+ __func__);
+ return -ENOMEM;
+ }
+ sata_resources[1].start = res.start;
+ sata_resources[1].end = res.end;
+
+ /*
+* Extract IRQ number(s) from device tree and put them into
+* the platform device structure
+*/
+ sata_resources[2].start = sata_resources[2].end =
+ irq_of_parse_and_map(np, 0);
+ sata_resources[3].start = sata_resources[3].end =
+ irq_of_parse_and_map(np, 1);
+
+ return platform_add_devices(ppc460ex_devs, ARRAY_SIZE(ppc460ex_devs));
+}
+
+static int __d
[PATCH 3/3 v3] Add 4xx SATA dts node documentation
Signed-off-by: Feng Kan
---
Documentation/powerpc/dts-bindings/4xx/sata.txt | 24 +++
1 files changed, 24 insertions(+), 0 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/4xx/sata.txt
diff --git a/Documentation/powerpc/dts-bindings/4xx/sata.txt
b/Documentation/powerpc/dts-bindings/4xx/sata.txt
new file mode 100644
index 000..3ce00d0
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/4xx/sata.txt
@@ -0,0 +1,24 @@
+AMCC SoC SATA Support
+
+This following is only for the 460ex support for Designware SATA core
+
+Required properties:
+- compatible : "amcc,sata-460ex".
+- reg : the first set defines SATA controller register, the second set
+is for the AHB DMA controller for SATA.
+- interrupt-parent: UIC3
+- interrupts: one for SATA and one for the DMA
+
+Notes:
+The SATA is only available when the first PCIe port is disabled.
+
+Example:
+
+SATA0: s...@bffd1000 {
+ compatible = "amcc,sata-460ex";
+reg = <4 0xbffd1000 0x800 4 0xbffd0800 0x400>;
+ interrupt-parent = <&UIC3>;
+ interrupts = <0 4 /* SATA */
+ 5 4>; /* AHBDMA */
+};
+
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Added support for Designware SATA controller driver
Hi Scott: I agree with your statement, however this driver is wrapped with this AHB DMA controller. It would be very hard for it to work on non 460EX platforms. I can expand the depend in the future if it is available on more cores. Thanks Feng Kan Scott Wood wrote: Feng Kan wrote: This adds support for the Designware SATA controller. Signed-off-by: Feng Kan Signed-off-by: Mark Miesfeld --- drivers/ata/Kconfig| 10 + drivers/ata/Makefile |1 + drivers/ata/sata_dwc.c | 2053 3 files changed, 2064 insertions(+), 0 deletions(-) create mode 100644 drivers/ata/sata_dwc.c diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index 0bcf264..c3d0b24 100644 --- a/drivers/ata/Kconfig +++ b/drivers/ata/Kconfig @@ -72,6 +72,16 @@ config SATA_FSL If unsure, say N. +config SATA_DWC +tristate "DesignWare Cores SATA support" + depends on 460EX That "depends" looks too specific -- we don't want to grow a list if this controller gets added to other chips. Only depend on what this driver actually needs in order to function. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] Added AMCC 460EX Canyonlands SATA support.
This adds the OF platform support for the AMCC 460EX Canyonlands SATA port.
Signed-off-by: Feng Kan
---
arch/powerpc/boot/dts/canyonlands.dts |8 ++
arch/powerpc/platforms/44x/Makefile|4 +
arch/powerpc/platforms/44x/amcc-sata.c | 125
3 files changed, 137 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/44x/amcc-sata.c
diff --git a/arch/powerpc/boot/dts/canyonlands.dts
b/arch/powerpc/boot/dts/canyonlands.dts
index 5fd1ad0..b536223 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -163,6 +163,14 @@
interrupts = <0x1e 4>;
};
+SATA0: s...@bffd1000 {
+compatible = "amcc,sata-460ex";
+ reg = <4 0xbffd1000 0x800 4 0xbffd0800 0x400>;
+interrupt-parent = <&UIC3>;
+interrupts = <0 4 /* SATA */
+ 5 4>; /* AHBDMA */
+};
+
POB0: opb {
compatible = "ibm,opb-460ex", "ibm,opb";
#address-cells = <1>;
diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
index 01f51da..fa0a999 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -4,3 +4,7 @@ obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_SAM440EP) += sam440ep.o
obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
+ifeq ($(CONFIG_SATA_DWC),y)
+obj-$(CONFIG_CANYONLANDS) += amcc-sata.o
+endif
+
diff --git a/arch/powerpc/platforms/44x/amcc-sata.c
b/arch/powerpc/platforms/44x/amcc-sata.c
new file mode 100644
index 000..fdda917
--- /dev/null
+++ b/arch/powerpc/platforms/44x/amcc-sata.c
@@ -0,0 +1,125 @@
+/*
+ * AMCC Canyonlands SATA wrapper
+ *
+ * Copyright 2008 DENX Software Engineering, Stefan Roese
+ *
+ * Extract the resources (MEM & IRQ) from the dts file and put them
+ * into the platform-device struct for usage in the platform-device
+ * SATA driver.
+ *
+ */
+
+#include
+#include
+
+/*
+ * Resource template will be filled dynamically with the values
+ * extracted from the dts file
+ */
+static struct resource sata_resources[] = {
+ [0] = {
+ /* 460EX SATA registers */
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ /* 460EX AHBDMA registers */
+ .flags = IORESOURCE_MEM,
+ },
+ [2] = {
+ /* 460EX SATA IRQ */
+ .flags = IORESOURCE_IRQ,
+ },
+ [3] = {
+ /* 460EX AHBDMA IRQ */
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 dma_mask = 0xULL;
+
+static struct platform_device sata_device = {
+ .name = "sata-dwc",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(sata_resources),
+ .resource = sata_resources,
+ .dev = {
+ .dma_mask = &dma_mask,
+ .coherent_dma_mask = 0xULL,
+ }
+};
+
+static struct platform_device *ppc460ex_devs[] __initdata = {
+ &sata_device,
+};
+
+static int __devinit ppc460ex_sata_probe(struct of_device *ofdev,
+const struct of_device_id *match)
+{
+ struct device_node *np = ofdev->node;
+ struct resource res;
+ const char *val;
+
+ /*
+* Check if device is enabled
+*/
+ val = of_get_property(np, "status", NULL);
+ if (val && !strcmp(val, "disabled")) {
+ printk(KERN_INFO "SATA port disabled via device-tree\n");
+ return 0;
+ }
+
+ /*
+* Extract register address reange from device tree and put it into
+* the platform device structure
+*/
+ if (of_address_to_resource(np, 0, &res)) {
+ printk(KERN_ERR "%s: Can't get SATA register address\n",
+ __func__);
+ return -ENOMEM;
+ }
+ sata_resources[0].start = res.start;
+ sata_resources[0].end = res.end;
+
+ if (of_address_to_resource(np, 1, &res)) {
+ printk(KERN_ERR "%s: Can't get AHBDMA register address\n",
+ __func__);
+ return -ENOMEM;
+ }
+ sata_resources[1].start = res.start;
+ sata_resources[1].end = res.end;
+
+ /*
+* Extract IRQ number(s) from device tree and put them into
+* the platform device structure
+*/
+ sata_resources[2].start = sata_resources[2].end =
+ irq_of_parse_and_map(np, 0);
+ sata_resources[3].start = sata_resources[3].end =
+ irq_of_parse_and_map(np, 1);
+
+ return plat
[PATCH 0/2] Added support for Designware SATA controller driver
Fixed comment issue. Change goto statements to lower case. Also fixed the Kconfig problem. I don't know if I need to add Stefan Roese for the signoff, since he did the of platform part. Stefan, if you see this please let me know. Feng Kan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] Added AMCC 460EX Canyonlands SATA support.
Signed-off-by: Feng Kan
---
arch/powerpc/boot/dts/canyonlands.dts |8 ++
arch/powerpc/platforms/44x/Makefile|4 +
arch/powerpc/platforms/44x/amcc-sata.c | 125
3 files changed, 137 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/44x/amcc-sata.c
diff --git a/arch/powerpc/boot/dts/canyonlands.dts
b/arch/powerpc/boot/dts/canyonlands.dts
index 5fd1ad0..b536223 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -163,6 +163,14 @@
interrupts = <0x1e 4>;
};
+SATA0: s...@bffd1000 {
+compatible = "amcc,sata-460ex";
+ reg = <4 0xbffd1000 0x800 4 0xbffd0800 0x400>;
+interrupt-parent = <&UIC3>;
+interrupts = <0 4 /* SATA */
+ 5 4>; /* AHBDMA */
+};
+
POB0: opb {
compatible = "ibm,opb-460ex", "ibm,opb";
#address-cells = <1>;
diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
index 01f51da..fa0a999 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -4,3 +4,7 @@ obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_SAM440EP) += sam440ep.o
obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
+ifeq ($(CONFIG_SATA_DWC),y)
+obj-$(CONFIG_CANYONLANDS) += amcc-sata.o
+endif
+
diff --git a/arch/powerpc/platforms/44x/amcc-sata.c
b/arch/powerpc/platforms/44x/amcc-sata.c
new file mode 100644
index 000..fdda917
--- /dev/null
+++ b/arch/powerpc/platforms/44x/amcc-sata.c
@@ -0,0 +1,125 @@
+/*
+ * AMCC Canyonlands SATA wrapper
+ *
+ * Copyright 2008 DENX Software Engineering, Stefan Roese
+ *
+ * Extract the resources (MEM & IRQ) from the dts file and put them
+ * into the platform-device struct for usage in the platform-device
+ * SATA driver.
+ *
+ */
+
+#include
+#include
+
+/*
+ * Resource template will be filled dynamically with the values
+ * extracted from the dts file
+ */
+static struct resource sata_resources[] = {
+ [0] = {
+ /* 460EX SATA registers */
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ /* 460EX AHBDMA registers */
+ .flags = IORESOURCE_MEM,
+ },
+ [2] = {
+ /* 460EX SATA IRQ */
+ .flags = IORESOURCE_IRQ,
+ },
+ [3] = {
+ /* 460EX AHBDMA IRQ */
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 dma_mask = 0xULL;
+
+static struct platform_device sata_device = {
+ .name = "sata-dwc",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(sata_resources),
+ .resource = sata_resources,
+ .dev = {
+ .dma_mask = &dma_mask,
+ .coherent_dma_mask = 0xULL,
+ }
+};
+
+static struct platform_device *ppc460ex_devs[] __initdata = {
+ &sata_device,
+};
+
+static int __devinit ppc460ex_sata_probe(struct of_device *ofdev,
+const struct of_device_id *match)
+{
+ struct device_node *np = ofdev->node;
+ struct resource res;
+ const char *val;
+
+ /*
+* Check if device is enabled
+*/
+ val = of_get_property(np, "status", NULL);
+ if (val && !strcmp(val, "disabled")) {
+ printk(KERN_INFO "SATA port disabled via device-tree\n");
+ return 0;
+ }
+
+ /*
+* Extract register address reange from device tree and put it into
+* the platform device structure
+*/
+ if (of_address_to_resource(np, 0, &res)) {
+ printk(KERN_ERR "%s: Can't get SATA register address\n",
+ __func__);
+ return -ENOMEM;
+ }
+ sata_resources[0].start = res.start;
+ sata_resources[0].end = res.end;
+
+ if (of_address_to_resource(np, 1, &res)) {
+ printk(KERN_ERR "%s: Can't get AHBDMA register address\n",
+ __func__);
+ return -ENOMEM;
+ }
+ sata_resources[1].start = res.start;
+ sata_resources[1].end = res.end;
+
+ /*
+* Extract IRQ number(s) from device tree and put them into
+* the platform device structure
+*/
+ sata_resources[2].start = sata_resources[2].end =
+ irq_of_parse_and_map(np, 0);
+ sata_resources[3].start = sata_resources[3].end =
+ irq_of_parse_and_map(np, 1);
+
+ return platform_add_devices(ppc460ex_devs, ARRAY_SIZE(ppc460ex_devs));
+}
+
+static int __d
Re: Help!Some memory doesn't work on PPC405Ex based board!
Hi SunNeo: The fact that it is hanging at the same place in kernel seems strange. Usually when dram initialization is incorrect, the kernel would not run at all. Uboot just hangs at relocate code. I suggest you turn on early kernel printf to see if you get some other outputs. P.S when you have discrete memory on board. you have to be sure that your calibration values are correct. The RDCC RQDC value should be best possible. You can run the fix initialization and then lift the autocalibration routine to the end of the fix dram init to determine the best RFDC RQDC windows. After that recode the fix values for those registers. Feng Kan AMCC Software SunNeo wrote: > Hi, Stefan, > > Thanks for your help. > > My platform uses the MICRON MT47H256M8THN DDRII SDRAM and the DDRII SDRAM is > soldered on the board. > > As I said, my board was similar with "Kilauea" evb, so I created my > configuration header file from Kilauea's at U-Boot. In the configuration > file, register value for the DDR SDRAM controller is defined. But I have > removed DDR autocalibraton related configuration from the configuration file, > do you think this will cause any issues? > > I'm not sure what you mean about "intensive memory test". I use "mm" cmd > under U-Boot command prompt to modify value of high 512M memory, and this > command works well. > > About booting Linux, the kernel hangs at the same location. Always after this > print info "<4>Mount-cache hash table entries: 512". > > Best Regards, > Sun > > >> From: s...@denx.de >> To: linuxppc-dev@ozlabs.org >> Subject: Re: Help!Some memory doesn't work on PPC405Ex based board! >> Date: Tue, 14 Apr 2009 11:23:02 +0200 >> CC: sunwx2...@hotmail.com >> >> On Monday 13 April 2009, SunNeo wrote: >> >>> I'm porting Linux-2.6.29 on PPC405Ex based board, it's very similar to AMCC >>> "Kilauea" evb. >>> >>> In my board, two 512MB DDRII memory is connected to 2 ranks of the 405Ex >>> CPU. This 1GB memory works well at U-Boot-2009.01, but when I boot >>> Linux-2.6.29, the kernel hangs somewhere. >>> >> Does it just hang "somewhere", or always at the same location? A random >> hangup >> could mean that you are having a memory problem (hardware, or wrong >> initialization). >> >> >>> What interesting is, if I >>> configured the system to use only 512MB memory at U-Boot, the Linux can >>> boot normally . >>> >> Are you using DIMM's on your platform? Or soldered chips? Which memory >> initialization code are you using in U-Boot? And which autocalibration code? >> >> Did you do some intensive memory test? >> >> Best regards, >> Stefan >> > > > _ > > 把MSN装进手机，更多聊天乐趣等你挖掘！ 立刻下载！ <http://mobile.msn.com.cn/> > > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: AMCC 440EP phy detection
Hi Eddie: Are you able to ping in u-boot? Sounded like you were only pinging in linux. I would try the mii command in uboot. It seems like it detected the phys. Try enable the loopbacks at the different stages to see if the traffic is returning. This excerise is much easier in uboot than linux. Feng Kan AMCC Software Eddie Dawydiuk wrote: Hello, I'm working on a board based on the Yosemite AMCC 440EP eval board. I'm having some difficulty getting both network interfaces working. The first problem I found is the ibm_newemac driver was detecting the two phys at address 0 and 1 where we have them wired for addresses 1 and 3. As a result I hardcoded the phy-address in the dts file. I then found I was able to receive and send data on eth1(phy-address 3) without incident. Although I found eth0 can receive data but I see no packets being transmitted(using a packet sniffer) and I see no indication from a software standpoint of any transmit failures. We are using Micrel KSZ8041FTL phys(RMII mode) where the Yosemite board used Micrel KS8721BL phys. I've reviewed the schematic and it appears both phys are connected identically and I've seen this same failure on multiple boards. I thought the fact that the driver detected a phy at address 0 might be a clue, but I can't make much of the clue. So I thought I'd post this info in the hopes someone else might have run into a similar problem or have a suggestion. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: early kernel debugging
Hi: Did you try the early kernel printk option in kernel hacking. It can give some very helpful information. Make sure the address for the physical uart address is passed in correctly. Feng Tirumala Reddy Marri wrote: I am not sure if I understand correctly. But Looks like you are not passing the device tree along with kernel image and RAMDISK(you may not need it if you are using NFS mount). You boot command should some what look like this "bootm kernel_addr ramdisk_addr devtree_addr" or "bootm kernel_addr - devtree_addr" . If you are already doing that I would check my bootargs for correct params. -Original Message- From: linuxppc-dev-bounces+tmarri=amcc@ozlabs.org [mailto:linuxppc-dev-bounces+tmarri=amcc@ozlabs.org] On Behalf Of Yigal Goldberger Sent: Thursday, April 02, 2009 1:06 PM To: linuxppc-dev@ozlabs.org Subject: early kernel debugging Hi All, I'm using u-boot to boot kernel 2.6.24.2 on a powerpc based board . I see that after uncompressing the kernel it hangs. I found a location (System.map) I think corresponds to the __log_buf (my SDRAM starts at physical address 0 (and u-boot performs -> Load Address: Entry Point: ) . So I just removed the leading C0xx from the address leaving xx . And that's where I looked . I did see 2 error messages (though they were somewhat corrupt) the first designated a memory fault and the second a kernel oops at some address. I looked this address up on System.map and it's somewhere inside prom.c in of_scan_flat_dt( ) . I have a few question at this point : A)Am I looking at the right memory location for __log_buf ? B)What is printed to the buffer (printk's of what verbose level ?) C)In a previous kernel version 2.6.14 I don't remember explicitly using a flat device tree or pointing at such a tree through the bootm command) , but I used the ARCH=ppc then as opposed to ARCH=powerpc Now . I see a lot of stuff regarding the need to provide such a data structure upon booting via bootm .Do I need to explicitly prepare such a data structure and provide a pointer to it via bootm ? Might this be the cause for this early hang ? Best Regards, Yigal Goldberger. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: About [AMCC 460EX/canyonlands board] Synopsys DesignWare Cores (DWC) SATA host driver
Hi RenQuan:
We are aware of the issue, currently the sata is only supported up to
2.6.25.7. We are working on a patchable version
to submit to main line.
Thanks
Feng Kan
Cheng Renquan wrote:
Mark,
I found that the current sata_dwc can only work on
DENX-2.6.25-stable, and have problems in DENX-2.6.26, 27, 28,
29(master),
the boot errors is as the following, I hope you and AMCC staff submit
it into mainline soon, thanks.
there is also some other boot panic kmsg, I will reproduce it tomorrow.
http://git.denx.de/linux-2.6-denx.git/
Synopsys DesignWare Cores (DWC) SATA host driver
linuxppc-dev@ozlabs.org
About AMCC DesignWare Core SATA controller driver:
=> boot
Using ip address 172.16.90.27
## Booting kernel from Legacy Image at ff60 ...
Image Name: Linux-2.6.27.19
Created: 2009-03-13 10:18:17 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size:1574261 Bytes = 1.5 MB
Load Address:
Entry Point:
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Flattened Device Tree blob at fc1e
Booting using the fdt blob at 0xfc1e
## Loading init Ramdisk from Legacy Image at fc20 ...
Image Name: canyonlands ramdisk rev. 001
Created: 2008-05-13 11:18:24 UTC
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size:18968362 Bytes = 18.1 MB
Load Address:
Entry Point:
Verifying Checksum ... OK
Loading Device Tree to 007fa000, end 007f ... OK
Loading Ramdisk to 1ec3d000, end 1fe53f2a ... OK
Using Canyonlands machine description
Linux version 2.6.27.19 (fed...@ubox-h1) (gcc version 4.2.2) #1 Fri
Mar 13 18:18:05 HKT 2009
Found initrd at 0xdec3d000:0xdfe53f2a
Zone PFN ranges:
DMA 0x -> 0x0002
Normal 0x0002 -> 0x0002
HighMem 0x0002 -> 0x0002
scsi 0:0:0:0: Direct-Access ATA WDC WD10EVVS-63E 01.0 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 1953525168 512-byte hardware sectors (1000205 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 0:0:0:0: [sda] 1953525168 512-byte hardware sectors (1000205 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sda:<3>ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: link is slow to respond, please be patient (ready=0)
ata1: prereset failed (errno=-16)
ata1: reset failed, giving up
ata1.00: disabled
ata1: EH complete
sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
unable to read partition table
sd 0:0:0:0: [sda] Attached SCSI disk
4cc00.nor_flash: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
4cc00.nor_flash: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
RedBoot partition parsing not available
Creating 7 MTD partitions on "4cc00.nor_flash":
0x-0x001e : "kernel"
0x001e-0x0020 : "dtb"
0x0020-0x0160 : "ramdisk"
0x0160-0x01a0 : "jffs2"
0x01a0-0x03f6 : "user"
0x03f6-0x03fa : "env"
0x03fa-0x0400 : "u-boot"
NDFC NAND Driver initialized. Chip-Rev: 0x0111
NAND device: Manufacturer ID: 0x20, Chip ID: 0xf1 (ST Micro NAND
128MiB 3,3V 8-bit)
Scanning device for bad blocks
Number of partitions 3
Creating 3 MTD partitions on "NAND 128MiB 3,3V 8-bit":
0x-0x0010 : "u-boot"
0x0010-0x0014 : "env"
0x0014-0x0800 : "content"
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
dwc_otg: version 2.60a 22-NOV-2006
TCP cubic registered
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
eth0: link is up, 1000 FDX, pause enabled
IP-Config: Complete:
device=eth0, addr=172.16.90.27, mask=255.255.255.0, gw=255.255.255.255,
host=canyonlands, domain=, nis-domain=(none),
bootserver=172.16.90.26, rootserver=172.16.90.26, rootpath=
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 156k init
Startup utility found. Executing...
AMCC Startup utility launched.
BusyBox v1.2.1 (2008.05.13-11:11+) Built-in shell (ash)
Enter &#x
Re: [PATCH] PowerPC 440EPx/GRx fix memory size calculation
Hi Guys: Sequoia uses on board discrete memory with one rank. So one chip select would be fine. Turning on both won't matter, since the other cs is never used. Feng Kan Stefan Roese wrote: On Wednesday 11 March 2009, Valentine Barshak wrote: I've been looking at the docs once again and actually I couldn't find an explanation there. And I don't have that e-mail from AMCC support that I got a while back regarding the issue anymore. There might have been some misunderstanding. The docs (PPC440EPX UM 19.2 Device Address Mapping) say that the chip select field width is always fixed at one bit, but this doesn't actually mean that there's always one chip select used. The patch works fine on Sequoia and another Sequoia-like board with 1GB RAM installed, but it might not work with 2GB RAM. I've tried to play with DDR0_10 settings and Sequoia works fine regardless of what's actually written to DDR0_10. So, probably the best way would be to fix that in u-boot amcc/sequoia/sdram.c by doing mtsdram(DDR0_10, 0x0100); instead of mtsdram(DDR0_10, 0x0300); Sorry, for confusion, but after reviewing the docs, I think that only REDUC interpretation has to be fixed. The chips select part should be fixed in u-boot sdram code for Sequoia as was originally proposed by Mikhail. Stefan, could you please take a look? I'll apply the U-Boot patch today. But as Josh pointed out, we should try to find a way for the bootwrapper to work in all cases. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Broken PCI on Sequoia
Hi: It looks like the top bit is hard coded to 1. There doesn't seem to be anyway Of changing it. Feng Kan AMCC Engineering -Original Message- From: linuxppc-dev-bounces+fkan=amcc@ozlabs.org [mailto:linuxppc-dev-bounces+fkan=amcc@ozlabs.org] On Behalf Of Benjamin Herrenschmidt Sent: Friday, January 30, 2009 1:30 PM To: Geert Uytterhoeven Cc: Linux/PPC Development Subject: Re: Broken PCI on Sequoia > For that sort of 4xx PHB (ie, the PCI 2.x ones, not the PCI-X nor the > PCI-E), we only know how to program 32-bit of PLB address. IE. The old > code would have cropped the plb_addr when writing to the register, the > new code complains. > > I suspect some implementation support a register to put the "high" part > of the PLB address, and that it already contains 1, so the old code > would have worked by chance, the new code doesn't because it bails out. Hrm... from the doco it's also one 32-bit register... I'm starting to think that those guys always assume the top 1 bit is set or something like that ... The doc is unclear. Maybe somebody form AMCC can confirm ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
