* [RFC][PATCH] ibm_newemac: PowerPC 440GX EMAC PHY clock workaround
From: Valentine Barshak @ 2008-02-22 19:24 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1203634340.10422.203.camel@pasglop>
The PowerPC 440GX Taishan board fails to reset EMAC3 (reset timeout error)
and because of that it can't find PHY chip. The older ibm_emac driver had
a workaround for that: the EMAC_CLK_INTERNAL/EMAC_CLK_EXTERNAL macros which
toggle the Ethernet Clock Select bit in the SDR0_MFR register. This patch
does the same for "ibm,emac-440gx" compatible chips. The workaround forces
clock on -all- EMACs, so we select clock under global emac_phy_map_lock.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
drivers/net/ibm_newemac/core.c | 16 +++++++++++++++-
drivers/net/ibm_newemac/core.h | 8 ++++++--
2 files changed, 21 insertions(+), 3 deletions(-)
diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/core.c linux-2.6/drivers/net/ibm_newemac/core.c
--- linux-2.6.orig/drivers/net/ibm_newemac/core.c 2008-02-22 19:56:26.000000000 +0300
+++ linux-2.6/drivers/net/ibm_newemac/core.c 2008-02-22 20:38:47.000000000 +0300
@@ -43,6 +43,8 @@
#include <asm/io.h>
#include <asm/dma.h>
#include <asm/uaccess.h>
+#include <asm/dcr.h>
+#include <asm/dcr-regs.h>
#include "core.h"
@@ -2323,6 +2325,10 @@ static int __devinit emac_init_phy(struc
dev->phy.mdio_read = emac_mdio_read;
dev->phy.mdio_write = emac_mdio_write;
+ /* Enable internal clock source */
+ if (emac_has_feature(dev, EMAC_FTR_440GX_PHY_CLK_FIX))
+ mtdcri(SDR0, SDR0_MFR, mfdcri(SDR0, SDR0_MFR) | SDR0_MFR_ECS);
+
/* Configure EMAC with defaults so we can at least use MDIO
* This is needed mostly for 440GX
*/
@@ -2355,6 +2361,11 @@ static int __devinit emac_init_phy(struc
if (!emac_mii_phy_probe(&dev->phy, i))
break;
}
+
+ /* Enable external clock source */
+ if (emac_has_feature(dev, EMAC_FTR_440GX_PHY_CLK_FIX))
+ mtdcri(SDR0, SDR0_MFR, mfdcri(SDR0, SDR0_MFR) & ~SDR0_MFR_ECS);
+
mutex_unlock(&emac_phy_map_lock);
if (i == 0x20) {
printk(KERN_WARNING "%s: can't find PHY!\n", np->full_name);
@@ -2480,8 +2491,11 @@ static int __devinit emac_init_config(st
}
/* Check EMAC version */
- if (of_device_is_compatible(np, "ibm,emac4"))
+ if (of_device_is_compatible(np, "ibm,emac4")) {
dev->features |= EMAC_FTR_EMAC4;
+ if (of_device_is_compatible(np, "ibm,emac-440gx"))
+ dev->features |= EMAC_FTR_440GX_PHY_CLK_FIX;
+ }
/* Fixup some feature bits based on the device tree */
if (of_get_property(np, "has-inverted-stacr-oc", NULL))
diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/core.h linux-2.6/drivers/net/ibm_newemac/core.h
--- linux-2.6.orig/drivers/net/ibm_newemac/core.h 2008-02-21 16:45:36.000000000 +0300
+++ linux-2.6/drivers/net/ibm_newemac/core.h 2008-02-22 19:57:44.000000000 +0300
@@ -301,6 +301,10 @@ struct emac_instance {
* Set if we have new type STACR with STAOPC
*/
#define EMAC_FTR_HAS_NEW_STACR 0x00000040
+/*
+ * Set if we need phy clock workaround for 440gx
+ */
+#define EMAC_FTR_440GX_PHY_CLK_FIX 0x00000080
/* Right now, we don't quite handle the always/possible masks on the
@@ -312,8 +316,8 @@ enum {
EMAC_FTRS_POSSIBLE =
#ifdef CONFIG_IBM_NEW_EMAC_EMAC4
- EMAC_FTR_EMAC4 | EMAC_FTR_HAS_NEW_STACR |
- EMAC_FTR_STACR_OC_INVERT |
+ EMAC_FTR_EMAC4 | EMAC_FTR_HAS_NEW_STACR |
+ EMAC_FTR_STACR_OC_INVERT | EMAC_FTR_440GX_PHY_CLK_FIX |
#endif
#ifdef CONFIG_IBM_NEW_EMAC_TAH
EMAC_FTR_HAS_TAH |
^ permalink raw reply
* [PATCH] ibm_newemac: emac_tx_csum typo fix.patch
From: Valentine Barshak @ 2008-02-22 19:21 UTC (permalink / raw)
To: linuxppc-dev
Move the "&& skb->ip_summed == CHECKSUM_PARTIAL" part out of
emac_has_feature parameters.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
drivers/net/ibm_newemac/core.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/core.c linux-2.6/drivers/net/ibm_newemac/core.c
--- linux-2.6.orig/drivers/net/ibm_newemac/core.c 2008-02-21 16:45:36.000000000 +0300
+++ linux-2.6/drivers/net/ibm_newemac/core.c 2008-02-22 19:55:29.000000000 +0300
@@ -1235,8 +1235,8 @@ static int emac_close(struct net_device
static inline u16 emac_tx_csum(struct emac_instance *dev,
struct sk_buff *skb)
{
- if (emac_has_feature(dev, EMAC_FTR_HAS_TAH &&
- skb->ip_summed == CHECKSUM_PARTIAL)) {
+ if (emac_has_feature(dev, EMAC_FTR_HAS_TAH) &&
+ (skb->ip_summed == CHECKSUM_PARTIAL)) {
++dev->stats.tx_packets_csum;
return EMAC_TX_CTRL_TAH_CSUM;
}
^ permalink raw reply
* Re: [RFC][PATCH] PowerPC 4xx: ibm_newemac 440GX phy clock workaround.
From: Valentine Barshak @ 2008-02-22 19:15 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1203634340.10422.203.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Thu, 2008-02-21 at 17:46 +0300, Valentine Barshak wrote:
>> The PowerPC 440GX Taishan board fails to reset EMAC3 (reset timeout error)
>> and because of that it can't find PHY chip. The older ibm_emac driver had
>> a workaround for that: the EMAC_CLK_INTERNAL/EMAC_CLK_EXTERNAL macros which
>> toggle the Ethernet Clock Select bit in the SDR0_MFR register. This patch
>> does the same for "ibm,emac-440gx" compatible chips.
>
> The main problem is that will force clock on -all- EMACs ... which can
> be a problem as they can be in probe at the same time. Might be worth
> also adding a global mutex around that block.
I've tried to move clock selection inside the global emac_phy_map_lock
block. That works fine for 440GX.
>
> Also, would you mind having a look at the other workaround for the
> similar bug?
OK, I'll add 440EP/440GR workaround, but I'm not sure if we need it for
the currently supported boards. The older ibm_emac driver also has a
workaround for it on 405ep. This part uses CPC0 dcr registers. So, looks
like we'll have to search device tree for the CPC0 entry in ibm_newemac
driver, map dcr registers and select clock with dcr_read/write calls.
I've omitted the 405ep part, since there's currently no board supported.
Thanks,
Valentine.
>
> Cheers,
> Ben.
>
>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>> ---
>> drivers/net/ibm_newemac/core.c | 16 +++++++++++++++-
>> drivers/net/ibm_newemac/core.h | 8 ++++++--
>> 2 files changed, 21 insertions(+), 3 deletions(-)
>>
>> diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/core.c linux-2.6/drivers/net/ibm_newemac/core.c
>> --- linux-2.6.orig/drivers/net/ibm_newemac/core.c 2008-02-21 16:45:36.000000000 +0300
>> +++ linux-2.6/drivers/net/ibm_newemac/core.c 2008-02-21 17:21:21.000000000 +0300
>> @@ -43,6 +43,8 @@
>> #include <asm/io.h>
>> #include <asm/dma.h>
>> #include <asm/uaccess.h>
>> +#include <asm/dcr.h>
>> +#include <asm/dcr-regs.h>
>>
>> #include "core.h"
>>
>> @@ -2480,8 +2482,11 @@ static int __devinit emac_init_config(st
>> }
>>
>> /* Check EMAC version */
>> - if (of_device_is_compatible(np, "ibm,emac4"))
>> + if (of_device_is_compatible(np, "ibm,emac4")) {
>> dev->features |= EMAC_FTR_EMAC4;
>> + if (of_device_is_compatible(np, "ibm,emac-440gx"))
>> + dev->features |= EMAC_FTR_440GX_PHY_CLK_FIX;
>> + }
>>
>> /* Fixup some feature bits based on the device tree */
>> if (of_get_property(np, "has-inverted-stacr-oc", NULL))
>> @@ -2673,8 +2678,17 @@ static int __devinit emac_probe(struct o
>> dev->stop_timeout = STOP_TIMEOUT_100;
>> INIT_DELAYED_WORK(&dev->link_work, emac_link_timer);
>>
>> + /* Enable internal phy clock source */
>> + if (emac_has_feature(dev, EMAC_FTR_440GX_PHY_CLK_FIX))
>> + mtdcri(SDR0, SDR0_MFR, mfdcri(SDR0, SDR0_MFR) | SDR0_MFR_ECS);
>> +
>> /* Find PHY if any */
>> err = emac_init_phy(dev);
>> +
>> + /* Enable external phy clock source */
>> + if (emac_has_feature(dev, EMAC_FTR_440GX_PHY_CLK_FIX))
>> + mtdcri(SDR0, SDR0_MFR, mfdcri(SDR0, SDR0_MFR) & ~SDR0_MFR_ECS);
>> +
>> if (err != 0)
>> goto err_detach_tah;
>>
>> diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/core.h linux-2.6/drivers/net/ibm_newemac/core.h
>> --- linux-2.6.orig/drivers/net/ibm_newemac/core.h 2008-02-21 16:45:36.000000000 +0300
>> +++ linux-2.6/drivers/net/ibm_newemac/core.h 2008-02-21 17:21:47.000000000 +0300
>> @@ -301,6 +301,10 @@ struct emac_instance {
>> * Set if we have new type STACR with STAOPC
>> */
>> #define EMAC_FTR_HAS_NEW_STACR 0x00000040
>> +/*
>> + * Set if we need phy clock workaround for 440gx
>> + */
>> +#define EMAC_FTR_440GX_PHY_CLK_FIX 0x00000080
>>
>>
>> /* Right now, we don't quite handle the always/possible masks on the
>> @@ -312,8 +316,8 @@ enum {
>>
>> EMAC_FTRS_POSSIBLE =
>> #ifdef CONFIG_IBM_NEW_EMAC_EMAC4
>> - EMAC_FTR_EMAC4 | EMAC_FTR_HAS_NEW_STACR |
>> - EMAC_FTR_STACR_OC_INVERT |
>> + EMAC_FTR_EMAC4 | EMAC_FTR_HAS_NEW_STACR |
>> + EMAC_FTR_STACR_OC_INVERT | EMAC_FTR_440GX_PHY_CLK_FIX |
>> #endif
>> #ifdef CONFIG_IBM_NEW_EMAC_TAH
>> EMAC_FTR_HAS_TAH |
>
^ permalink raw reply
* RE: Xilinx PowerPC
From: Stephen Neuendorffer @ 2008-02-22 19:07 UTC (permalink / raw)
To: alan.casey5, Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <4726E9350007F2E5@hawk.dcu.ie>
> -----Original Message-----
> From: Alan Casey [mailto:alan.casey5@mail.dcu.ie]
> Sent: Friday, February 22, 2008 10:58 AM
> To: Stephen Neuendorffer; Grant Likely
> Cc: linuxppc-embedded
> Subject: RE: Xilinx PowerPC
>=20
>=20
> >-- Original Message --
> >Subject: RE: Xilinx PowerPC
> >Date: Fri, 22 Feb 2008 10:11:19 -0800
> >From: "Stephen Neuendorffer" <stephen.neuendorffer@xilinx.com>
> >To: <alan.casey5@mail.dcu.ie>,
> > "Grant Likely" <grant.likely@secretlab.ca>
> >Cc: linuxppc-embedded <linuxppc-embedded@ozlabs.org>
> >
> >
> >>
> >> Hi,
> >>
> >> Just wondering - is it possible to use U-Boot on the Xilinx
XUPV2PRO
> >> board or any similar tools (such as libfdt?) to copy a Linux
kernel
> >and
> >>
> >> ramdisk filesystem from a SystemACE card to memory, uncompress
them
> >and
> >>
> >> boot the Linux kernel etc?? If so is there any notes/docs about
how
> >to
> >> do
> >> this or similar online anywhere?
> >>
> >> Any info. appreciated,
> >> Regards&Thanks,
> >> Alan.
> >
> >In theory, yes... All the infrastructure to do this exists, but I
don't
> >know of anyone who as actually tried it yet with ARCH=3Dpowerpc
kernels.
> >There
> >
> >Steve
>=20
> So i can try the latest official U-Boot releases with the ML300
configuration
> or is there a port or similar of U-Boot for the Xilinx XUPV2PRO
board??
>=20
> Regards&Thanks,
> Alan.
>=20
>=20
That's probably your best starting point.... There is a uboot
application note on the Xilinx website (XAPP 542), but it's a little
thin on porting information.
Steve
^ permalink raw reply
* Re: How to dynamically disable/enable CPU features?
From: Gerhard Pircher @ 2008-02-22 19:05 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev
In-Reply-To: <ebff4ecb45908616728fb5c8ede8b0bf@bga.com>
Hi,
-------- Original-Nachricht --------
> Datum: Fri, 22 Feb 2008 11:24:38 -0600
> Von: Milton Miller <miltonm@bga.com>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: ppcdev <linuxppc-dev@ozlabs.org>
> Betreff: Re: How to dynamically disable/enable CPU features?
> We handle cpu features in a couple of ways:
> (1) we replace assembly instructions with nop early in the kernel boot
I'm pretty sure that is the problem.
> (2) we test the feature flags in c code
>
> In (2), we form two expressions for features that are
> (a) always set
> (b) never set
> so that the compiler can eliminate the test based on the config.
>
> To change a flag, you must make sure its in POSSIBLE but not ALWAYS,
> and also set it before it is used, either to nop out instructions (see
> early_init in setup-32.c for 32 bit), or tested by c code (in this
> case, maybe the initial_mmu setup is testing NEED_COHERENT, which is
> between early_init and probe). The code path is a bit different for 64
> bit.
The flag is in POSSIBLE. I now use this code in the platform probe
function to nop out the code affected by the flag:
cur_cpu_spec->cpu_features &= ~CPU_FTR_NEED_COHERENT;
/* Patch out unwanted feature. */
do_feature_fixups(cur_cpu_spec->cpu_features,
PTRRELOC(&__start___ftr_fixup),
PTRRELOC(&__stop___ftr_fixup));
It seems to work so far, but I would like to know if this is the right
way to do it, or if calling do_feature_fixups() more than once can have
any side effects.
regards,
Gerhard
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
^ permalink raw reply
* RE: Xilinx PowerPC
From: Alan Casey @ 2008-02-22 18:58 UTC (permalink / raw)
To: Stephen Neuendorffer, Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <20080222181124.5F07079007D@mail120-dub.bigfish.com>
>-- Original Message --
>Subject: RE: Xilinx PowerPC
>Date: Fri, 22 Feb 2008 10:11:19 -0800
>From: "Stephen Neuendorffer" <stephen.neuendorffer@xilinx.com>
>To: <alan.casey5@mail.dcu.ie>,
> "Grant Likely" <grant.likely@secretlab.ca>
>Cc: linuxppc-embedded <linuxppc-embedded@ozlabs.org>
>
>
>>
>> Hi,
>>
>> Just wondering - is it possible to use U-Boot on the Xilinx XUPV2PRO=
>> board or any similar tools (such as libfdt?) to copy a Linux kernel
>and
>>
>> ramdisk filesystem from a SystemACE card to memory, uncompress them
>and
>>
>> boot the Linux kernel etc?? If so is there any notes/docs about how
>to
>> do
>> this or similar online anywhere?
>>
>> Any info. appreciated,
>> Regards&Thanks,
>> Alan.
>
>In theory, yes... All the infrastructure to do this exists, but I don't=
>know of anyone who as actually tried it yet with ARCH=3Dpowerpc kernels.=
>There
>
>Steve
So i can try the latest official U-Boot releases with the ML300 configur=
ation
or is there a port or similar of U-Boot for the Xilinx XUPV2PRO board??
Regards&Thanks,
Alan.
^ permalink raw reply
* Re: MPC8540 : What's "SPE used in kernel" ?
From: Andy Fleming @ 2008-02-22 18:33 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: linuxppc-dev
In-Reply-To: <20080222095022.GA635@ingate.macqel>
On Feb 22, 2008, at 03:50, Philippe De Muyter wrote:
> Dear list,
>
> I have just compiled linux-2.6.24 for a MPC8540 target using a MPC8540
> specific gcc.
>
> I then got tan infinity of "SPE used in kernel" messages. Looking
> at the
> sources I ifdeffed out the printk call in KernelSPE, and I now have a
> silent kernel, that seems to work fine.
>
> Is there something wrong in my setting and should I look further to
> debug this problem or is this perfectly normal ?
>
> I wonder why a kernel configured for E500 and compiled by a E500-
> specific gcc
> triggers this message. Is it invalid to use SPE instructions in
> the kernel
> or do I misunderstand the message ?
We don't currently support using SPE in the kernel. Are you using
SPE in the kernel for some reason? Do you think that the compiler is
automatically generating SPE code in the kernel? I've never seen
that before.
Andy
^ permalink raw reply
* RE: Xilinx PowerPC
From: Stephen Neuendorffer @ 2008-02-22 18:11 UTC (permalink / raw)
To: alan.casey5, Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <4726E9350007F0D6@hawk.dcu.ie>
>=20
> Hi,
>=20
> Just wondering - is it possible to use U-Boot on the Xilinx XUPV2PRO
> board or any similar tools (such as libfdt?) to copy a Linux kernel
and
>=20
> ramdisk filesystem from a SystemACE card to memory, uncompress them
and
>=20
> boot the Linux kernel etc?? If so is there any notes/docs about how
to
> do
> this or similar online anywhere?
>=20
> Any info. appreciated,
> Regards&Thanks,
> Alan.
In theory, yes... All the infrastructure to do this exists, but I don't
know of anyone who as actually tried it yet with ARCH=3Dpowerpc kernels.
There=20
Steve
^ permalink raw reply
* Re: Xilinx PowerPC
From: Alan Casey @ 2008-02-22 17:23 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40802211102i7f636447hfca0f8e1673042a5@mail.gmail.com>
>-- Original Message --
>Date: Thu, 21 Feb 2008 12:02:21 -0700
>From: "Grant Likely" <grant.likely@secretlab.ca>
>To: "Stephen Neuendorffer" <stephen.neuendorffer@xilinx.com>
>Subject: Re: Xilinx PowerPC
>Cc: linuxppc-embedded <linuxppc-embedded@ozlabs.org>
>
>
>On Thu, Feb 21, 2008 at 10:50 AM, Stephen Neuendorffer
><stephen.neuendorffer@xilinx.com> wrote:
>> > Step 2).
>> > the code in arch/powerpc/???? is the devicetree equval=
ent
>> to
>> > arch/ppc/platforms/4xx/xilinx_ml410.c
>> http://git.xilinx.com/linux-2.6-xlnx.git contains a preliminary stab
at
>> the bootcode for Virtex. I've been using this for a while with
>> ARCH=3Dpowerpc. There isn't really much need for board specific plat=
form
>> code: This should (I think) be handled by the device tree. All of th=
is
>> is still pretty preliminary at the moment however. The big problem w=
ith
>> the boot code in the Xilinx tree is that you need to be able to alloc=
ate
>> memory in order to parse the device tree in order to figure out how m=
uch
>> memory you have. I just haven't rewritten the code to use libfdt, wh=
ich
>> can query the device tree without memory allocation yet. Grant has a=
>> slightly different scheme in his tree, but it works as well. General=
ly
>> I've been more focused on avoiding u-boot, whereas Grant has been usi=
ng
>> u-boot exclusively, I think.
>
>Actually, I'm not using u-boot at all. I've reworked the 'raw' image
>target to use libfdt and properly initialize the cache and stuff.
>I'll be merging it in the .26 merge window.
>
Hi,
Just wondering - is it possible to use U-Boot on the Xilinx XUPV2PRO
board or any similar tools (such as libfdt?) to copy a Linux kernel and=
ramdisk filesystem from a SystemACE card to memory, uncompress them and=
boot the Linux kernel etc?? If so is there any notes/docs about how to
do
this or similar online anywhere?
Any info. appreciated,
Regards&Thanks,
Alan.
^ permalink raw reply
* Re: How to dynamically disable/enable CPU features?
From: Milton Miller @ 2008-02-22 17:24 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: ppcdev
In-Reply-To: <20080221200758.62940@gmx.net>
At Fri Feb 22 07:07:58 EST 2008, Gerhard Pircher wrote:
> I'm wondering how to disable or enable CPU features based on the board
> the
> kernel is running on. In my case I want to disable the
> CPU_FTR_NEED_COHERENT flag for 74xx CPUs, because it locks up the
> machine.
> I tried to clear the flag in the platform's *_probe() function with the
> following code:
>
> cur_cpu_spec->cpu_features &= ~CPU_FTR_NEED_COHERENT;
>
> First I thought that this works fine, because the kernel booted once
> till
> the console login prompt (and died afterwards). Therefore I suspected
> that
> another change or bug in the kernel conflicts with my hardware (usually
> the machine died much earlier on older kernels, if the flag wasn't
> cleared).
> Now I removed all CPU_FTR_NEED_COHERENT entries from the cputable.h
> file
> and the kernel boots just fine without any lockups (reproducable).
> I don't quite understand the difference between dynamically clearing
> the
> flag in the platform setup code and removing the flag for all CPU
> defines in cputable.h. I can only suspect that clearing the flag in the
> platform probe function is too late, as the MMU and BATs may already be
> set up.
>
> Can anybody confirm my suspicion or give me a hint how to implement it
> correctly? (I don't want to tinker with cputable.h)
We handle cpu features in a couple of ways:
(1) we replace assembly instructions with nop early in the kernel boot
(2) we test the feature flags in c code
In (2), we form two expressions for features that are
(a) always set
(b) never set
so that the compiler can eliminate the test based on the config.
To change a flag, you must make sure its in POSSIBLE but not ALWAYS,
and also set it before it is used, either to nop out instructions (see
early_init in setup-32.c for 32 bit), or tested by c code (in this
case, maybe the initial_mmu setup is testing NEED_COHERENT, which is
between early_init and probe). The code path is a bit
different for 64 bit.
milton
^ permalink raw reply
* Re: [PATCH] Add support for binary includes.
From: Jon Loeliger @ 2008-02-22 16:24 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080222160820.GA19571@ld0162-tx32.am.freescale.net>
So, like, the other day Scott Wood mumbled:
> >
> > Can I ask; what is the intended usage of such a thing? How large
> > would a typical binary blob be?
>
> I use it for embedding guest device trees in a hypervisor's device tree.
Why wouldn't we instead, say, extend the source sytax
to allow a sub-tree or an embedded tree, rather than
obscuring an opaque form of that guest device tree?
Thanks,
jdl
^ permalink raw reply
* [PATCH] sata_fsl: fix build with ATA_VERBOSE_DEBUG
From: Anton Vorontsov @ 2008-02-22 16:54 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide, linuxppc-dev
This patch fixes build and few warnings when ATA_VERBOSE_DEBUG
is defined:
CC drivers/ata/sata_fsl.o
drivers/ata/sata_fsl.c: In function ‘sata_fsl_fill_sg’:
drivers/ata/sata_fsl.c:338: warning: format ‘%x’ expects type ‘unsigned int’, but argument 3 has type ‘void *’
drivers/ata/sata_fsl.c:338: warning: format ‘%x’ expects type ‘unsigned int’, but argument 4 has type ‘struct prde *’
drivers/ata/sata_fsl.c: In function ‘sata_fsl_qc_issue’:
drivers/ata/sata_fsl.c:459: error: ‘csr_base’ undeclared (first use in this function)
drivers/ata/sata_fsl.c:459: error: (Each undeclared identifier is reported only once
drivers/ata/sata_fsl.c:459: error: for each function it appears in.)
drivers/ata/sata_fsl.c: In function ‘sata_fsl_freeze’:
drivers/ata/sata_fsl.c:525: error: ‘csr_base’ undeclared (first use in this function)
make[2]: *** [drivers/ata/sata_fsl.o] Error 1
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/ata/sata_fsl.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index 9ac36df..93789bf 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -335,7 +335,7 @@ static unsigned int sata_fsl_fill_sg(struct ata_queued_cmd *qc, void *cmd_desc,
dma_addr_t indirect_ext_segment_paddr;
unsigned int si;
- VPRINTK("SATA FSL : cd = 0x%x, prd = 0x%x\n", cmd_desc, prd);
+ VPRINTK("SATA FSL : cd = 0x%p, prd = 0x%p\n", cmd_desc, prd);
indirect_ext_segment_paddr = cmd_desc_paddr +
SATA_FSL_CMD_DESC_OFFSET_TO_PRDT + SATA_FSL_MAX_PRD_DIRECT * 16;
@@ -459,7 +459,8 @@ static unsigned int sata_fsl_qc_issue(struct ata_queued_cmd *qc)
VPRINTK("CE=0x%x, DE=0x%x, CC=0x%x, CmdStat = 0x%x\n",
ioread32(CE + hcr_base),
ioread32(DE + hcr_base),
- ioread32(CC + hcr_base), ioread32(COMMANDSTAT + csr_base));
+ ioread32(CC + hcr_base),
+ ioread32(COMMANDSTAT + host_priv->csr_base));
return 0;
}
@@ -522,7 +523,8 @@ static void sata_fsl_freeze(struct ata_port *ap)
ioread32(CQ + hcr_base),
ioread32(CA + hcr_base),
ioread32(CE + hcr_base), ioread32(DE + hcr_base));
- VPRINTK("CmdStat = 0x%x\n", ioread32(csr_base + COMMANDSTAT));
+ VPRINTK("CmdStat = 0x%x\n",
+ ioread32(host_priv->csr_base + COMMANDSTAT));
/* disable interrupts on the controller/port */
temp = ioread32(hcr_base + HCONTROL);
--
1.5.2.2
^ permalink raw reply related
* Re: Doubt in Device tree entry for USB on Powerpc based board
From: Scott Wood @ 2008-02-22 16:50 UTC (permalink / raw)
To: mahendra varman; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <4ac2955e0802220533o3eba0e58ybb72326ab0e1a376@mail.gmail.com>
On Fri, Feb 22, 2008 at 07:03:07PM +0530, mahendra varman wrote:
> Please help me in the device tree where to give the device type
> compatibility address_cells size cells for the USB (since usb controller is
> in pci bridge i have some confusion in where to give the entry for usb)
You don't need to describe PCI devices in the device tree; they are
probed at runtime.
-Scott
^ permalink raw reply
* Re: MODPOST section mismatches
From: Steve Heflin @ 2008-02-22 16:12 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20080221213313.97814DDF55@ozlabs.org>
To reproduce the problem and see the details on section mismatches:
make ARCH=powerpc sequoia_defconfig
make ARCH=powerpc CONFIG_DEBUG_SECTION_MISMATCH=y
At 04:33 PM 2/21/2008, Steve Heflin wrote:
>while building vmlinux.o the MODPOST warns about 8 section mismatches.
>WARNING: modpost: Found 8 section mismatch(es).
>To see full details build your kernel with:
>'make CONFIG_DEBUG_SECTION_MISMATCH=y'
>
>After modifying the make launch to include the recommended option
>shown above, I see that the section mismatch warning is due to data
>structures containing the address of initialization modules which
>have the __init attribute. Since the memory model is FLAT, is this a problem?
>
>thanks,
>Steve
>
>
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] Add support for binary includes.
From: Scott Wood @ 2008-02-22 16:28 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1JSahk-0003ub-Eh@jdl.com>
On Fri, Feb 22, 2008 at 10:24:56AM -0600, Jon Loeliger wrote:
> So, like, the other day Scott Wood mumbled:
> > >
> > > Can I ask; what is the intended usage of such a thing? How large
> > > would a typical binary blob be?
> >
> > I use it for embedding guest device trees in a hypervisor's device tree.
>
> Why wouldn't we instead, say, extend the source sytax
> to allow a sub-tree or an embedded tree, rather than
> obscuring an opaque form of that guest device tree?
That was what I tried initially, but the implementation was much more
complicated, and path references are problematic.
-Scott
^ permalink raw reply
* Re: [PATCH] Add support for binary includes.
From: Scott Wood @ 2008-02-22 16:08 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, jdl
In-Reply-To: <fa686aa40802212205p38c3793bg8793740955b1e91@mail.gmail.com>
On Thu, Feb 21, 2008 at 11:05:58PM -0700, Grant Likely wrote:
> On Wed, Feb 20, 2008 at 12:19 PM, Scott Wood <scottwood@freescale.com> wrote:
> > A property's data can be populated with a file's contents
> > as follows:
> >
> > node {
> > prop = /incbin/("path/to/data");
> > };
> >
> > A subset of a file can be included by passing start and size parameters.
> > For example, to include bytes 8 through 23:
> >
> > node {
> > prop = /incbin/("path/to/data", 8, 16);
> > };
>
>
> Can I ask; what is the intended usage of such a thing? How large
> would a typical binary blob be?
I use it for embedding guest device trees in a hypervisor's device tree.
-Scott
^ permalink raw reply
* Re: [PATCH] Add support for binary includes.
From: Grant Likely @ 2008-02-22 15:50 UTC (permalink / raw)
To: David Woodhouse; +Cc: Scott Wood, linuxppc-dev, jdl
In-Reply-To: <1203670971.5771.41.camel@shinybook.infradead.org>
On Fri, Feb 22, 2008 at 2:02 AM, David Woodhouse <dwmw2@infradead.org> wrote:
>
> On Thu, 2008-02-21 at 23:05 -0700, Grant Likely wrote:
> > Can I ask; what is the intended usage of such a thing? How large
> > would a typical binary blob be?
>
> Device firmware?
That's what I was wondering about. Is this really a good idea?
Effectively, in the Linux kernel the device tree is being used as a
big blob of initdata, except that it cannot free the memory allocated
by the device tree when it is complete. As it is right now, device
trees seem to weigh in between 4-8kB, a pretty insignificant size for
memory that cannot be reclaimed. However, if firmware blobs start
getting added to the tree that size could balloon pretty quickly.
I'm not actually opposed to the feature, and I understand that it is
needed for the new u-boot image format, but I think we need some usage
guidelines in place when this feature is merged. As much as possible
I think we should be directing developers to use the existing firmware
loading facilities in the Linux kernel.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Marvell PHY driver fix
From: Alexandr Smirnov @ 2008-02-22 14:34 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, vbordug
Marvell PHY m88e1111 (not sure about other models, but think they too) works in
two modes: fiber and copper. In Marvell PHY driver (that we have in current
community kernels) code supported only copper mode, and this is not configurable,
bits for copper mode are simply written in registers during PHY
initialization. This patch adds support for both modes.
Signed-off-by: Alexandr Smirnov <asmirnov@ru.mvista.com>
diff -pruN powerpc.orig/drivers/net/phy/marvell.c powerpc/drivers/net/phy/marvell.c
--- powerpc.orig/drivers/net/phy/marvell.c 2008-02-07 14:59:32.000000000 +0300
+++ powerpc/drivers/net/phy/marvell.c 2008-02-19 21:47:34.000000000 +0300
@@ -58,9 +58,28 @@
#define MII_M1111_RX_DELAY 0x80
#define MII_M1111_TX_DELAY 0x2
#define MII_M1111_PHY_EXT_SR 0x1b
-#define MII_M1111_HWCFG_MODE_MASK 0xf
-#define MII_M1111_HWCFG_MODE_RGMII 0xb
+
+#define MII_M1111_HWCFG_MODE_MASK 0xf
+#define MII_M1111_HWCFG_MODE_COPPER_RGMII 0xb
+#define MII_M1111_HWCFG_MODE_FIBER_RGMII 0x3
#define MII_M1111_HWCFG_MODE_SGMII_NO_CLK 0x4
+#define MII_M1111_HWCFG_FIBER_COPPER_AUTO 0x8000
+#define MII_M1111_HWCFG_FIBER_COPPER_RES 0x2000
+
+#define MII_M1111_PHY_CR 0
+#define MII_M1111_SOFTWARE_RESET 0x8000
+
+#define MII_M1111_COPPER 0
+#define MII_M1111_FIBER 1
+
+#define MII_M1011_PHY_STATUS 0x11
+#define MII_M1011_PHY_STATUS_1000 0x8000
+#define MII_M1011_PHY_STATUS_100 0x4000
+#define MII_M1011_PHY_STATUS_SPD_MASK 0xc000
+#define MII_M1011_PHY_STATUS_FULLDUPLEX 0x2000
+#define MII_M1011_PHY_STATUS_RESOLVED 0x0800
+#define MII_M1011_PHY_STATUS_LINK 0x0400
+
MODULE_DESCRIPTION("Marvell PHY driver");
MODULE_AUTHOR("Andy Fleming");
@@ -141,12 +160,22 @@ static int marvell_config_aneg(struct ph
static int m88e1111_config_init(struct phy_device *phydev)
{
int err;
+ int temp;
+ int mode;
+
+ /* Enable Fiber/Copper auto selection */
+ temp = phy_read(phydev, MII_M1111_PHY_EXT_SR);
+ temp |= MII_M1111_HWCFG_FIBER_COPPER_AUTO;
+ phy_write(phydev, MII_M1111_PHY_EXT_SR, temp);
+
+ temp = phy_read(phydev, MII_M1111_PHY_CR);
+ temp |= MII_M1111_SOFTWARE_RESET;
+ phy_write(phydev, MII_M1111_PHY_CR, temp);
if ((phydev->interface == PHY_INTERFACE_MODE_RGMII) ||
(phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) ||
(phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
(phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)) {
- int temp;
temp = phy_read(phydev, MII_M1111_PHY_EXT_CR);
if (temp < 0)
@@ -171,7 +200,17 @@ static int m88e1111_config_init(struct p
return temp;
temp &= ~(MII_M1111_HWCFG_MODE_MASK);
- temp |= MII_M1111_HWCFG_MODE_RGMII;
+
+ mode = phy_read(phydev, MII_M1111_PHY_EXT_CR);
+ mode = (mode & MII_M1111_HWCFG_FIBER_COPPER_RES) >> 13;
+
+ switch (mode) {
+ case MII_M1111_COPPER:
+ temp |= MII_M1111_HWCFG_MODE_COPPER_RGMII;
+ break;
+ case MII_M1111_FIBER:
+ temp |= MII_M1111_HWCFG_MODE_FIBER_RGMII;
+ }
err = phy_write(phydev, MII_M1111_PHY_EXT_SR, temp);
if (err < 0)
@@ -262,6 +301,93 @@ static int m88e1145_config_init(struct p
return 0;
}
+/* marvell_read_status
+ *
+ * Generic status code does not detect Fiber correctly!
+ * Description:
+ * Check the link, then figure out the current state
+ * by comparing what we advertise with what the link partner
+ * advertises. Start by checking the gigabit possibilities,
+ * then move on to 10/100.
+ */
+static int marvell_read_status(struct phy_device *phydev)
+{
+ int adv;
+ int err;
+ int lpa;
+ int status = 0;
+
+ /* Update the link, but return if there
+ * was an error */
+ err = genphy_update_link(phydev);
+ if (err)
+ return err;
+
+ if (AUTONEG_ENABLE == phydev->autoneg) {
+ status = phy_read(phydev, MII_M1011_PHY_STATUS);
+ if (status < 0)
+ return status;
+
+ lpa = phy_read(phydev, MII_LPA);
+ if (lpa < 0)
+ return lpa;
+
+ adv = phy_read(phydev, MII_ADVERTISE);
+ if (adv < 0)
+ return adv;
+
+ lpa &= adv;
+
+ if (status & MII_M1011_PHY_STATUS_FULLDUPLEX)
+ phydev->duplex = DUPLEX_FULL;
+ else
+ phydev->duplex = DUPLEX_HALF;
+
+ status = status & MII_M1011_PHY_STATUS_SPD_MASK;
+ phydev->pause = phydev->asym_pause = 0;
+
+ switch (status) {
+ case MII_M1011_PHY_STATUS_1000:
+ phydev->speed = SPEED_1000;
+ break;
+
+ case MII_M1011_PHY_STATUS_100:
+ phydev->speed = SPEED_100;
+ break;
+
+ default:
+ phydev->speed = SPEED_10;
+ break;
+ }
+
+ if (phydev->duplex == DUPLEX_FULL) {
+ phydev->pause = lpa & LPA_PAUSE_CAP ? 1 : 0;
+ phydev->asym_pause = lpa & LPA_PAUSE_ASYM ? 1 : 0;
+ }
+ } else {
+ int bmcr = phy_read(phydev, MII_BMCR);
+
+ if (bmcr < 0)
+ return bmcr;
+
+ if (bmcr & BMCR_FULLDPLX)
+ phydev->duplex = DUPLEX_FULL;
+ else
+ phydev->duplex = DUPLEX_HALF;
+
+ if (bmcr & BMCR_SPEED1000)
+ phydev->speed = SPEED_1000;
+ else if (bmcr & BMCR_SPEED100)
+ phydev->speed = SPEED_100;
+ else
+ phydev->speed = SPEED_10;
+
+ phydev->pause = phydev->asym_pause = 0;
+ }
+
+ return 0;
+}
+
static struct phy_driver marvell_drivers[] = {
{
.phy_id = 0x01410c60,
@@ -296,7 +422,7 @@ static struct phy_driver marvell_drivers
.flags = PHY_HAS_INTERRUPT,
.config_init = &m88e1111_config_init,
.config_aneg = &marvell_config_aneg,
- .read_status = &genphy_read_status,
+ .read_status = &marvell_read_status,
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
.driver = { .owner = THIS_MODULE },
^ permalink raw reply
* Re: MPC8540 : What's "SPE used in kernel" ?
From: Johannes Berg @ 2008-02-22 15:29 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: linuxppc-dev
In-Reply-To: <20080222095022.GA635@ingate.macqel>
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
> I wonder why a kernel configured for E500 and compiled by a E500-specific gcc
> triggers this message. Is it invalid to use SPE instructions in the kernel
> or do I misunderstand the message ?
I think it's like floating point/altivec, we don't always save the FP
registers on kernel/userspace transitions and so have to explicitly save
them to use them in the kernel, otherwise we'd clobber the userspace
register state.
I guess there's something like kernel_enter_spe()?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: compile quirk linux-2.6.24 (with workaround)
From: Bernhard Reiter @ 2008-02-22 14:50 UTC (permalink / raw)
To: debian-powerpc; +Cc: linuxppc-dev, paulus
In-Reply-To: <20080218205248.1af469d4@zod.rchland.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]
On Tuesday 19 February 2008 03:52, Josh Boyer wrote:
> My apologies for taking so long on this. Digging through gcc history
> isn't exactly fun :)
No problem. Thanks for tackling the issue.
> Ok, so it seems -mcpu=440 was added in gcc 3.4. The -mcpu=405 option
> has been around since 2001. Seeing as how there really isn't anything
> 440 specific in the files effected, we should be able to pass -mcpu=405
> for everything and have it still work.
>
> Bernhard, can you try the patch below?
I will test it in the next days.
The short test for my sarge compiler makes me optimistic:
dpkg -l gcc | grep gcc
ii gcc 3.3.5-3 The GNU C compiler
bernhard@burn:~/tmp$ gcc -mcpu=440 x.c
cc1: error: bad value (440) for -mcpu= switch
bernhard@burn:~/tmp$ gcc -mcpu=405 x.c
bernhard@burn:~/tmp$
> -$(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=440
> +$(obj)/4xx.o: BOOTCFLAGS += -mcpu=405
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: MPC8641D PCI-Express error
From: Marco Stornelli @ 2008-02-22 13:52 UTC (permalink / raw)
To: LinuxPPC-Embedded; +Cc: s.balamurugan
In-Reply-To: <47BD9FA9.1000904@freescale.com>
Jon Loeliger ha scritto:
> Marco Stornelli wrote:
>> When I try to read some register from my FPGA (virtex5) I have this bus
>> error:
>
>
> Hmmm.... OK, so if we've eliminated PCI-E as a source
> for this issue, it really must be in the Virtex support
> somewhere then. Unfortunately, I know nothing about those,
> and am not going to be much direct help there.
>
> Sorry.
>
> jdl
>
>
>> Machine check in kernel mode.
>> Caused by (from SRR1=149030): Transfer error ack signal
>> Oops: Machine check, sig: 7 [#1]
>> PREEMPT SMP NR_CPUS=2
>> Modules linked in: virtex5
>> LTT NESTING LEVEL : 0
>> NIP: F108019C LR: F1080198 CTR: 00000001
>> REGS: c044dd60 TRAP: 0200 Not tainted (2.6.18-mpc8641d_hpcn)
>> MSR: 00149030 <EE,ME,IR,DR> CR: 22000222 XER: 00000000
>> TASK = c20e9990[568] 'insmod' THREAD: c044c000 CPU: 0
>> GPR00: F1080198 C044DE10 C20E9990 0000002E 80000000 FFFFFFFF 00008000
>> 00002EA3
>> GPR08: C20E9990 00000000 C04C0220 C044C000 22000222 1001956C 00000000
>> 00000000
>> GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> 00000000
>> GPR24: 3000EAA0 7FD6FDC0 00000000 C045FCC0 F107E594 F10A0000 00000000
>> C2036000
>> NIP [F108019C] virtex5_probe+0x130/0x1c4 [virtex5]
>> LR [F1080198] virtex5_probe+0x12c/0x1c4 [virtex5]
>> Call Trace:
>> [C044DE10] [F1080198] virtex5_probe+0x12c/0x1c4 [virtex5] (unreliable)
>> [C044DE30] [C01D2A58] pci_device_probe+0x84/0xbc
>> [C044DE50] [C0213754] driver_probe_device+0x60/0x118
>> [C044DE70] [C0213890] __driver_attach+0x84/0x88
>> [C044DE90] [C02130F4] bus_for_each_dev+0x58/0x94
>> [C044DEC0] [C02135D4] driver_attach+0x24/0x34
>> [C044DED0] [C0212AC8] bus_add_driver+0x88/0x164
>> [C044DEF0] [C021397C] driver_register+0x70/0xb8
>> [C044DF00] [C01D284C] __pci_register_driver+0x64/0x98
>> [C044DF10] [F1080030] init_module+0x30/0x6c [virtex5]
>> [C044DF20] [C004CBFC] sys_init_module+0xc8/0x25c
>> [C044DF40] [C0011358] ret_from_syscall+0x0/0x38
>> --- Exception: c00 at 0xff6de0c
>> LR = 0x10000de4
>> Instruction dump:
>> 40820060 3c60f108 3863cea0 48000311 807f0238 3c800001 48000395 7c7d1b78
>> 3c60f108 3863ced4 480002f5 809d0000 <3c60f108> 3863cf04 480002e5 3c60f108
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
I tried to use 2.6.24 but I have the same error. It looks like this
problem happens when I try to read something in my ML555 board (Virtex5
evaluation board), but if try to write everything works fine. I tried to
change the settings about inbound/outbound PCI-E windows but I have the
same problem. Have you got any suggestions?
Thanks.
Marco
^ permalink raw reply
* Doubt in Device tree entry for USB on Powerpc based board
From: mahendra varman @ 2008-02-22 13:33 UTC (permalink / raw)
To: linuxppc-embedded, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 6986 bytes --]
Hello All
Iam using Powerpc 7448 processor along with TSI 109 system controller.
On PCI interface of TSI 109 a PCI to PCI bridge(6520) is connected in which
an usb controller(Philips ISP1562) and PMC site is connected.
Iam following the Open Firmware Powerpc architecture and using Linux 2.6.23.
I have framed the device tree for the above architecture with usb entry. But
even though i enable the ohci ppc of in menuconfig the the functions
probe,etc inside ohci ppc of.c are not called when i insert the device in
usb port and hence it is not detecting ohci low/full speed devices.
Please help me in the device tree where to give the device type
compatibility address_cells size cells for the USB (since usb controller is
in pci bridge i have some confusion in where to give the entry for usb)
I have attached the device tree below
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
{ model = "CTP7448";
compatible = "mpc74xx";
#address-cells = <1>;
#size-cells = <1>;
cpus {
#address-cells = <1>;
#size-cells =<0>;
PowerPC,7448@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <20>; // 32 bytes
i-cache-line-size = <20>; // 32 bytes
d-cache-size = <8000>; // L1, 32K bytes
i-cache-size = <8000>; // L1, 32K bytes
timebase-frequency = <0>; // 33 MHz, from uboot
clock-frequency = <0>; // From U-Boot
bus-frequency = <0>; // From U-Boot
32-bit;
};
};
memory{
device_type = "memory";
reg = <00000000 10000000>; // DDR2 512M at 0
};
tsi108@c0000000 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
device_type = "tsi-bridge";
ranges = <00000000 c0000000 00010000
00000000 f0000000 00008000
00000000 f1000000 01000000
00000000 f8000000 01000000>;
reg = <c0000000 00010000>;
bus-frequency = <0>;
rtc@f0000000 {
device_type = "rtc";
compatible = "st,m48t59";
reg = <f0000000 8000>;
};
i2c@7000 {
interrupt-parent = <&mpic>;
interrupts = <E 0>;
reg = <7000 400>;
device_type = "i2c";
compatible = "tsi108-i2c";
};
MDIO: mdio@6000 {
device_type = "mdio";
compatible = "tsi108-mdio";
reg = <6000 50>;
#address-cells = <1>;
#size-cells = <0>;
phy1: ethernet-phy@1 {
interrupt-parent = <&mpic>;
interrupts = <0 0>;
reg = <1>;
device_type = "ethernet-phy";
};
phy8: ethernet-phy@8 {
interrupt-parent = <&mpic>;
interrupts = <1 0>;
reg = <8>;
device_type = "ethernet-phy";
};
};
ethernet@6200 {
#size-cells = <0>;
device_type = "network";
compatible = "tsi108-ethernet";
reg = <6000 200>;
address = [ 00 03 23 00 00 01 ];
interrupts = <10 0>;
interrupt-parent = <&mpic>;
mdio-handle = <&MDIO>;
phy-handle = <&phy1>;
};
ethernet@6600 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
compatible = "tsi108-ethernet";
reg = <6400 200>;
address = [ 00 03 23 00 00 02 ];
interrupts = <11 2>;
interrupt-parent = <&mpic>;
mdio-handle = <&MDIO>;
phy-handle = <&phy8>;
};
serial@7808 {
device_type = "serial";
compatible = "ns16550";
reg = <7808 200>;
clock-frequency = <3f6b5a00>;
interrupts = <c 0>;
interrupt-parent = <&mpic>;
};
serial@7c08 {
device_type = "serial";
compatible = "ns16550";
reg = <7c08 200>;
clock-frequency = <3f6b5a00>;
interrupts = <d 0>;
interrupt-parent = <&mpic>;
};
mpic: pic@7400 {
clock-frequency = <0>;
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <7400 400>;
built-in;
compatible = "chrp,open-pic";
device_type = "open-pic";
big-endian;
};
pci@1000 {
compatible = "tsi108-pci";
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <1000 1000>;
bus-range = <0 0>;
ranges = <02000000 0 e0000000 e0000000 0 10000000
01000000 0 00000000 f2000000 0 01000000>;
clock-frequency = <3ef1480>;
interrupt-parent = <&mpic>;
interrupts = <17 2>;
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x10 */
00000 0 0 1 &RT0 24 0
/* IDSEL 0x11 */
00800 0 0 1 &RT0 25 0
/* IDSEL 0x12 */
1000 0 0 1 &RT0 24 0
1000 0 0 2 &RT0 25 0
1000 0 0 3 &RT0 26 0
1000 0 0 4 &RT0 27 0 >;
pci_bridge@12 {
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x13 (PMC Site) */
1800 0 0 1 &RT0 24 0
1800 0 0 2 &RT0 25 0
1800 0 0 3 &RT0 26 0
1800 0 0 4 &RT0 27 0
/* IDSEL 0x14 (USB chip) */
2000 0 0 1 &RT0 27 0
2000 0 0 2 &RT0 27 0
2000 0 0 3 &RT0 27 0
2000 0 0 4 &RT0 27 0
>;
reg = <1000 0 0 0 0>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
ranges = <02000000 0 e0000000 e0000000 0 10000000 01000000 0
00000000 fa000000 0 00010000>;
clock-frequency = <1f78a40>;
RT0: router@1180 {
clock-frequency = <0>;
interrupt-controller;
device_type = "pic-router";
#address-cells = <0>;
#interrupt-cells = <2>;
built-in;
big-endian;
interrupts = <17 2>;
interrupt-parent = <&mpic>;
};
};
};
};
};
[-- Attachment #2: Type: text/html, Size: 17996 bytes --]
^ permalink raw reply
* Re: [PATCH] [POWERPC] 8xx: timebase frequency should not depend on bus-frequency
From: Bryan O'Donoghue @ 2008-02-22 13:01 UTC (permalink / raw)
To: cbouatmailru; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080221234136.GA3545@zarina>
On Fri, 22 Feb 2008 02:41:36 +0300
Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> On Thu, Feb 21, 2008 at 03:20:10PM -0600, Scott Wood wrote:
> > Anton Vorontsov wrote:
> > > On Thu, Feb 21, 2008 at 02:06:58PM -0600, Scott Wood wrote:
> > >> Current u-boots don't support device trees at all on 8xx.
> > >
> > > Yes, vanilla u-boots. I assume many of us use some u-boot hacks to
> > > actually boot with the device tree (no, not cuboots)... ;-)
> >
> > Fine, but don't expect misbehavior from out-of-tree u-boots to be used
> > as justification for the kernel ignoring device tree content. :-)
>
> You got me wrong, maybe I wasn't clear enough: it wasn't justification of
> any kind. It's was just a remark regarding u-boot still not supporting
> fdt for 8xx (20 lines of code we're lazy to cleanup, write annotation
> to the patch and send it ;-).
Hey Anton.
I won't make any comment on what Linux should do with an older version of
u-boot.
However, just to let you know, there are a couple of patches to do a more modern
fdt on 8xx- sent to the u-boot list in the last <= ~ 10 days.
Using those patches - which incorporate the changes suggested by Scott re:
get_tbclk()- the timebase-frequency field is indeed stuffed with u-boot's
get_tbclk(); - see below.
u-boot/cpu/mpc8xx/fdt.c
void ft_cpu_setup(void *blob, bd_t *bd)
{
do_fixup_by_prop_u32(blob, "device_type", "cpu", 4,
"timebase-frequency", get_tbclk(), 1);
do_fixup_by_prop_u32(blob, "device_type", "cpu", 4,
"bus-frequency", bd->bi_busfreq, 1);
do_fixup_by_prop_u32(blob, "device_type", "cpu", 4,
"clock-frequency", bd->bi_intfreq, 1);
do_fixup_by_compat_u32(blob, "fsl,cpm-brg", "clock-frequency",
gd->brg_clk, 1);
/* Fixup ethernet MAC addresses */
fdt_fixup_ethernet(blob, bd);
fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
}
Adding fdt support to an 8xx board is then as simple as defining
/* pass open firmware flat tree */
#define CONFIG_OF_LIBFDT 1
#define CONFIG_OF_BOARD_SETUP 1
In your u-boot/include/configs/MySuperBoard.h
Best,
Bryan
^ permalink raw reply
* TQM5200 2.6-denx SM501 voyager enabling problem.
From: Pedro Luis D. L. @ 2008-02-22 11:29 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I'm working right now with a TQM5200 microcontroller on a STX5200 board.
I'm having problems to enable SM501 video output using 2.6-denx kernel. The=
system is working properly using 2.4 kernel and I can have graphical outpu=
t, so I can be sure that there's no hardware problem.
With 2.6 I have used the tqm5200_defconfig configuration file and then I ha=
ve enabled the following features in the kernel:
- Device Drivers -> Multifunction Device Drivers -> Support forSilicon Mot=
ion SM501.
- Device Drivers -> Graphic Support -> Support for frame buffer devices.
- Device Drivers -> Graphic Support -> Support for frame buffer devices -=
> Silicon Motion SM501 framebuffer support.
- Device Drivers -> Character devices -> Virtual Terminal.
- Device Drivers -> Character devices -> Support for console on virtual te=
rminal.
But I still can't make the SM501 driver initialized at booting time and the=
re's no framebuffer video device available. /dev/fb and /dev/fb0 nodes are =
already created.
I'm using 1.3.1 u-boot from denx repository compiled with CONFIG_STK52XX=
=3Dy and CONFIG_MINIFAP=3Dy options, and video=3Dvoyager:fp options is pass=
ed to the kernel at booting.
I'm sure there's something I'm missing to enable in the kernel. Maybe someo=
ne can sent me a hint. I would appreciate any!
Pedro L.
_________________________________________________________________
MSN Noticias
http://noticias.msn.es/comunidad.aspx=
^ permalink raw reply
* Re: [PATCHv4 2.6.25] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
From: Jochen Friedrich @ 2008-02-22 11:16 UTC (permalink / raw)
To: Jean Delvare; +Cc: linux-kernel, linuxppc-dev list, i2c, Scott Wood
In-Reply-To: <20080221130520.12b01553@hyperion.delvare>
Hi Jean,
>> +/*
>> + * Wait for patch from Jon Smirl
>> + * #include "powerpc-common.h"
>> + */
>
> It doesn't make sense to merge this comment upstream.
I know you don't like the patch from Jon Smirl and you also explained your reasons.
Fortunately, I2c no longer uses numeric device IDs but names. So what are the alternatives?
1. modify the I2c subsystem to accept OF names additionally to I2c names (proposed by Jon smirl).
2. record the I2c name in the dts tree, either as seperate tag (like linux,i2c-name="<i2c-name>")
or as additional compatible entry (like compatible="...", "linux,<i2c-name>").
3. use a glue layer with a translation map.
What is the preferred way to do this?
Thanks,
Jochen
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox