* Re: [PATCH 06/12] mpc5121: Added NAND Flash Controller driver.
From: John Rigby @ 2009-05-08 2:22 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, linux-mtd, Wolfgang Denk, Piotr Ziecik
In-Reply-To: <fa686aa40905061359p3ba2115fj57f4d9a79f01efda@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 826 bytes --]
On Wed, May 6, 2009 at 2:59 PM, Grant Likely <grant.likely@secretlab.ca>wrote:
>
>
> > diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c
> b/arch/powerpc/platforms/512x/mpc512x_shared.c
> > index d8cd579..7135d89 100644
> > --- a/arch/powerpc/platforms/512x/mpc512x_shared.c
> > +++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
> > @@ -71,6 +71,7 @@ void __init mpc512x_init_IRQ(void)
> > static struct of_device_id __initdata of_bus_ids[] = {
> > { .compatible = "fsl,mpc5121-immr", },
> > { .compatible = "fsl,mpc5121-localbus", },
> > + { .compatible = "fsl,mpc5121-nfc", },
>
> This doesn't look right. Shouldn't the NAND controller be hanging of
> the IMMR node?
>
I just wanted to confirm that NFC is in its own memory space. It has its
own mapping and is not part of the IMMR space.
[-- Attachment #2: Type: text/html, Size: 1239 bytes --]
^ permalink raw reply
* Re: [PATCH 08/12] mpc5121: Added I2C support.
From: John Rigby @ 2009-05-08 2:12 UTC (permalink / raw)
To: Grant Likely
Cc: linux-i2c, linuxppc-dev, Wolfgang Denk, Detlev Zundel,
Piotr Ziecik
In-Reply-To: <fa686aa40905061941p6fd4b03dt1097cf4d16bdd665@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]
Ok, the interrupt enabling should happen in the driver. Should it key off
compatible or should a new property be added like the existing 5200 clocking
property?
On Wed, May 6, 2009 at 8:41 PM, Grant Likely <grant.likely@secretlab.ca>wrote:
> On Wed, May 6, 2009 at 4:51 PM, Grant Likely <grant.likely@secretlab.ca>
> wrote:
> > On Wed, May 6, 2009 at 4:19 PM, Wolfgang Denk <wd@denx.de> wrote:
> >> Dear Grant Likely,
> >>
> >> In message <fa686aa40905061401k319313c5q89fd3e245c30808f@mail.gmail.com>
> you wrote:
> >>> On Wed, May 6, 2009 at 2:15 PM, Wolfgang Denk <wd@denx.de> wrote:
> >>> > From: Piotr Ziecik <kosmo@semihalf.com>
> >>> >
> >>> > - Enabled I2C interrupts on MPC5121.
> >>> > - Updated Kconfig for i2c-mpc driver.
> >>>
> >>> I think this workaround belongs in the driver itself.
> >>
> >> Sorry, I don't get it. Which workaround? What exactly should I change?
> >
> > Sorry, I misread the patch. Never mind.
>
> Actually, on 3rd reading, I think my first impression was correct
> (even if I was wrong about it being a workaround). This code in
> mpc512x_init_i2c() is only relevant for i2c busses (it isn't shared
> with any other drivers). Therefore, it belongs with the i2c bus
> itself. It does not belong in platform code.
>
> Cheers,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
[-- Attachment #2: Type: text/html, Size: 2143 bytes --]
^ permalink raw reply
* Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
From: John Rigby @ 2009-05-08 2:09 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <1241641262-5202-6-git-send-email-wd@denx.de>
[-- Attachment #1: Type: text/plain, Size: 3034 bytes --]
I think the fec's parent clock is the ipb clock not the ppc core clock.
Could that be the problem?
On Wed, May 6, 2009 at 2:21 PM, Wolfgang Denk <wd@denx.de> wrote:
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: John Rigby <jcrigby@gmail.com>
> ---
> This patch is NOT intended for inclusion into mainline, but rather a
> request for help. For some reason which I don't understand yet, the
> Ethernet interface on the ARIA board does not work in the default
> configuration, because MII probing fails.
>
> What I'm seeing is this; the problem is with this part of code in
> "drivers/net/fs_enet/mii-fec.c":
>
> 156 fec->mii_speed = ((ppc_proc_freq + 4999999) / 5000000) << 1;
> ...
> 163 out_be32(&fec->fecp->fec_mii_speed, fec->mii_speed);
>
> I added some debug messages, and this is what I see:
>
> On the ADS5121, we have the CPU clocked at 400 MHz. I get:
> ...
> ## ppc_proc_freq = 399999996, fec->mii_speed = 160
> FEC MII Bus: probed
> ...
> It works fine.
>
> According to the Ref. Man.:
> A value of 0 in this field turns off the MDC and leaves it in
> a low-voltage state. Any non-zero value results in the MDC
> frequency of 1/(mii_speed*2) of the system clock frequency.
> that means we have a MDC frequency of
> 400 MHz / (2 * 160) = 1.25 MHz
> which is obviously within the 2.5 MHz limit.
>
> Now ARIA is currently running at 316.8 MHz, and this is what I get:
> ...
> ## ppc_proc_freq = 316800000, fec->mii_speed = 128
> fsl-fec-mdio: probe of 80002800.mdio failed with error -5
> ...
> It fails. MDC frequency is
> 316.8 MHz / (2 * 128) = 1.24 MHz
> which should be fine.
>
> However, If I change the code to
>
> fec->mii_speed = (((ppc_proc_freq / 1000000) / 30) + 1) << 1;
>
> then I get:
> ...
> ## ppc_proc_freq = 316800000, fec->mii_speed = 22
> FEC MII Bus: probed
> ... and it's working!!! However, I compute MDC frequency as
> 316.8 MHz / (2 * 22) = 7.2 MHz
> which is far above the maximum allowed clock of 2.5 MHz ???
>
> Has anybody any idea what might be going on here?
>
>
> drivers/net/fs_enet/mii-fec.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/fs_enet/mii-fec.c b/drivers/net/fs_enet/mii-fec.c
> index 9d8bd97..a51dd83 100644
> --- a/drivers/net/fs_enet/mii-fec.c
> +++ b/drivers/net/fs_enet/mii-fec.c
> @@ -153,8 +153,12 @@ static int __devinit fs_enet_mdio_probe(struct
> of_device *ofdev,
> if (!fec->fecp)
> goto out_fec;
>
> +#if 0
> fec->mii_speed = ((ppc_proc_freq + 4999999) / 5000000) << 1;
> -
> +#else
> + fec->mii_speed = (((ppc_proc_freq / 1000000) / 30) + 1) << 1;
> + printk("## ppc_proc_freq = %d, fec->mii_speed = %d\n",
> ppc_proc_freq, fec->mii_speed);
> +#endif
> setbits32(&fec->fecp->fec_r_cntrl, FEC_RCNTRL_MII_MODE);
> setbits32(&fec->fecp->fec_ecntrl, FEC_ECNTRL_PINMUX |
> FEC_ECNTRL_ETHER_EN);
> --
> 1.6.0.6
>
>
[-- Attachment #2: Type: text/html, Size: 3837 bytes --]
^ permalink raw reply
* Re: [PATCH 02/12] fs_enet: Add MPC5121 FEC support.
From: John Rigby @ 2009-05-08 2:02 UTC (permalink / raw)
To: linuxppc, Wolfgang Denk; +Cc: netdev, Piotr Ziecik, Detlev Zundel
In-Reply-To: <fa686aa40905070709r7478837fnefb094d46f03ae0e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3305 bytes --]
Wolfgang,
Welcome to my world and why I gave up on this months ago.
Everyone else,
One thing to consider here is a rewrite with the goal of a new improved fec
driver that would work on both 5121 and the various mx platforms that also
have this same fec core.
Also don't forget that the register map is the same on 512x, mx and coldfire
platforms but not on the other ppc platforms so if you want to one binary to
rule them all you will need to have an offest table or some such.
John
On Thu, May 7, 2009 at 8:09 AM, Grant Likely <grant.likely@secretlab.ca>wrote:
> On Wed, May 6, 2009 at 4:41 PM, Wolfgang Denk <wd@denx.de> wrote:
> > Dear Grant,
> >
> > In message <fa686aa40905061529u11b231afle3b5bb10a2334ad0@mail.gmail.com>
> you wrote:
> >>
> >> > Agreed that it's ugly, but duplicatio9ng the code would have been even
> >> > worse. I don't think that it has multiplatform - at least not as long
> >> > as you don't ask for one image that runs on 83xx and on 512x.
> >>
> >> Actually, I *am* asking for one image that runs on 83xx, 52xx and
> >> 521x. I already can and do build and test a single image which boots
> >> on all my 52xx boards, on my 8349 board, and on my G4 Mac.
> >
> > He. I was afraid you'd say that ;-)
> >
> > In this case I need a helping hand as I can't figure out how to make
> > this work. Any suggestions?
>
> Hmmm, it is rather ugly because the layout of fec_t is so different.
> Easiest solution would be to duplicate the driver in its entirety, but
> as you say it results in a lot of duplicate code. It might be the
> lesser of many weevils though.
>
> Second easiest would be to factor out all the common code in the
> driver into a separate .c file that gets included by a 'wrapper' .c
> file for each config which first includes the correct definition of
> fec_t. This approach solves the duplicate code problem, but it also
> fell out of the ugly tree and hit every branch on the way down.
>
> ie: the wrappers would look something like this:
>
> fs_enet_cpm1.c:
> #include <asm/cpm1.h>
> #include "fs_enet_main.c"
>
> fs_enet_cpm2.c:
> #include <asm/cpm2.h>
> #include "fs_enet_main.c"
>
> fs_enet_512x.c:
> #include <asm/mpc512x.h>
> #include "fs_enet_main.c"
>
> And then the makefile would be something along the lines of:
> obj-${CONFIG_FS_ENET_CPM1_ += fs_enet_cpm1.o
> obj-${CONFIG_FS_ENET_CPM2_ += fs_enet_cpm2.o
> obj-${CONFIG_FS_ENET_MPC512x_ += fs_enet_512x.o
>
> A brief look at the driver suggests that access to the fec_t structure
> is restricted to the fec-mii.c and mac-fec.c files. It might be
> appropriate to duplicate just those files and do some form of
> fs_enet_ops to select between them.
>
> While on the topic, it looks to me like the driver could really use
> some refactoring love. Having multiple definitions of "fec_t" is
> confusing and potentially lead to hard to find bugs if the wrong
> header gets included by anyone. I'd like to see all the fec specific
> stuff in arch/powerpc/include/asm moved into drivers/net/fs_enet and
> renamed to reflect the hardware it is associate with. Stuff like
> "fec_t" is far to generic, not to mention that typedefs are
> discouraged now.
>
> Regardless, I feel your pain. It is not a pretty situation.
>
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
[-- Attachment #2: Type: text/html, Size: 4196 bytes --]
^ permalink raw reply
* Re: PPC8247 booting error
From: Sauce.Cheng @ 2009-05-08 1:47 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090505162649.GA4473@ld0162-tx32.am.freescale.net>
thanks for Scott's following
> You need to pass your physical address (0xd0000000) to ioremap() to
> obtain a virtual address that you can dereference.
actually, i have done that like you said. pass my phy addr to a virtual
addr, but i suppose it is a kernel virtual addr. i wanna get data from phy
in my application of user space. i try it by copy_to_user transfer a kernel
virtual addr to a use virtual addr for using by user. but copy_to_user
failed...
i do it like this
ssize_t read(....,char *buf,....,....)
{
....
kernel_buf = (void *)ioremap(0xD0000000, 4096);
copy_to_user(buf, kernel_buf, 4096);
....
}
--
View this message in context: http://www.nabble.com/PPC8247-booting-error-tp23381214p23438722.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] powerpc/iseries; fix pci breakage
From: Stephen Rothwell @ 2009-05-07 23:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras; +Cc: ppc-dev, Becky Bruce
In-Reply-To: <20090507100752.4fa4db7f.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 424 bytes --]
Hi Ben,
On Thu, 7 May 2009 10:07:52 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> This is a regression in v2.6.29 from v2.6.28, so I guess we need to
> send this to the stable team (backported if necessary) after it is upstream.
This same patch applies to 2.6.29.2 and fixes the problem there.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Trouble using with Kegel cross tool chain
From: Chris Plasun @ 2009-05-07 22:19 UTC (permalink / raw)
To: linuxppc
Hi Wolfgang,
> Trouble using with Kegel cross tool chain
> Wolfgang Denk wd at denx.de
> Thu May 7 15:32:36 EST 2009
>
> * Previous message: Trouble using with Kegel cross tool chain
> * Next message: Trouble using with Kegel cross tool chain
> * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>
> Dear Chris,
>
> In message <407093.53240.qm at web58102.mail.re3.yahoo.com> you wrote:
> >
> > I'm getting a bit desperate trying to build a gcc / glibc
> cross-toolchainfor
> > use on a Freescale MPC8313 but am having problems.
>
> Try using ELDK (see http://www.denx.de/wiki/view/DULG/ELDK resp.
> ftp://ftp.denx.de/pub/eldk/4.2/); it's based on crosstool but has
> these issues already solved for you.
>
> Best regards,
>
> Wolfgang Denk
Is Denx your site? I poured over it for U-Boot.
I will take a look at this tool.
Danke schoen!
Chris Plasun
^ permalink raw reply
* Trouble using with Kegel cross tool chain
From: Chris Plasun @ 2009-05-07 22:12 UTC (permalink / raw)
To: linuxppc-dev
> > + echo 'SRC_DIR not set, so source tarballs will be unpacked in the
> > build dir
> > ectory'
> > SRC_DIR not set, so source tarballs will be unpacked in the build
> > directory
> > + case x$PREFIX in
> > + case x$USER in
> > + abort 'Don'\''t run all.sh or crosstool.sh as root, it'\''s
> > dangerous'
> > + echo 'Don'\''t' run all.sh or crosstool.sh as root, 'it'\''s'
> > dangerous
> > Don't run all.sh or crosstool.sh as root, it's dangerous
> > + exec false
>
> Are you running as root? If so, don't.
>
> Mikey
Ah, now it's doing something...
Thanks Mikey. I didn't think running as root would prevent the process from running. Everything is running in VirtualBox so I wasn't concerned about blowing things up.
The build has been in progress for the past 15 minutes...
I set the target as powerpc-603. Is this appropriate for the MPC8313?
Thank you.
Chris Plasun
^ permalink raw reply
* Re: MPC5121 new board constantly resetting after u-boot passes control to Linux
From: Wolfgang Denk @ 2009-05-07 20:20 UTC (permalink / raw)
To: Damien Dusha; +Cc: linuxppc-dev
In-Reply-To: <c788c1220905070143t5271ebe1ra12df43f8f53e491@mail.gmail.com>
Dear Damien,
in message <c788c1220905070143t5271ebe1ra12df43f8f53e491@mail.gmail.com> you wrote:
>
> We are attempting to bring up a new MPC5121e board, somewhat based on the
> Silicon Turnkey's ADS5121 development board. We are using a kernel and
> u-boot based on Freescale/STx's board support package.
I recommend to use current code - tip of tree in U-Boot (although I
have a long stack of patches in the queue - wait for the weekend) and
Linux (use mainline aka kernel.org plus the patches I just posted for
a start).
> We have successfully modified u-boot for the 64MB of DDR2 RAM, and we can
> use u-boot's (and the BDI's) memory test facility to check that the RAM is
> working.
Let's say, it is *basicly* working. Note that these memory tests
don't stress-test the bus; for example, they do not stress-test any
burst-mode accesses.
See the FAQ: http://www.denx.de/wiki/view/DULG/UBootCrashAfterRelocation
My bet is you got a memory initialization error.
> At this point, the board immediately resets. There is no hint of life from
> the kernel from the console, although setting a breakpoint on the BDI at
> 0x0000000 and tracing through appears as though some code (although we don't
> know what) is being executed.
Why don't you know which code this is? GDB will tell you.
Did you try the standard methods, like post-mortem dump of the log
buffer area, etc.? See the FAQ for details.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I think there's a world market for about five computers.
-- attr. Thomas J. Watson (Chairman of the Board, IBM), 1943
^ permalink raw reply
* RE: [PATCH] 83xx: add support for the kmeter1 board.
From: Varlese, Christopher @ 2009-05-07 17:49 UTC (permalink / raw)
To: hs, Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <49F544DE.1010307@denx.de>
Hello all,
(FYI I working on the kmeter1)
kmeter1.c reuses the same QE_ENET10 RGMII errata workaround code from =
mpc836x_mds.c (MPC8360EMDS eval board).
In my view errata nodes in the dts is overkill. Maybe the errata code =
can go into a reusable function somewhere in 83xx/ or in ucc_geth.c?
I also think the original errata code needs improving:
- mask some SVR bits so activated for all matching CPU models, e.g. =
MPC8360 & MPC8360E.
- The code in mpc836x_mds.c and kmeter1.c does not do exactly what =
Freescale errata says!
Here the errata document:
http://www.freescale.com/files/32bit/doc/errata/MPC8360ECE.pdf
Because kmeter1 is using an MPC8360 CPU model the workaround doesn't =
actually trigger. So to kill 2 birds with 1 stone we tested a Uboot =
patch (below) doing what QE_ENET10 says. It seemed to work fine for =
us.
/* RGMII timing Errata workaround for rev 2.1 silicon
* (ref: MPC8360ECE rev.1 12/2007 QE_ENET10 UCC2 option 1)
*/
void *reg =3D (void *)(CONFIG_SYS_IMMR + 0x14ac);
clrsetbits_be32 (reg, 0x000000F0, 0x000000A0);
>From my point of view:
- The workaround code in kmeter1.c could go for now.
- An improved errata workaround for 836x boards would be nice (..who is =
motivated? :-))
Best regards
Christopher Varlese
R&D Software
________________________________________=A0
KEYMILE AG
Schwarzenburgstrasse 73
3097 Bern, Switzerland
www.keymile.com=A0
-----Original Message-----
From: linuxppc-dev-bounces+christopher.varlese=3Dkeymile.com@ozlabs.org =
[mailto:linuxppc-dev-bounces+christopher.varlese=3Dkeymile.com@ozlabs.org=
] On Behalf Of Heiko Schocher
Sent: Monday, April 27, 2009 7:39 AM
To: Kumar Gala
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] 83xx: add support for the kmeter1 board.
Hello Kumar,
Kumar Gala wrote:
[...]
>> diff --git a/arch/powerpc/platforms/83xx/kmeter1.c
>> b/arch/powerpc/platforms/83xx/kmeter1.c
>> new file mode 100644
>> index 0000000..99cf5c6
>> --- /dev/null
>> +++ b/arch/powerpc/platforms/83xx/kmeter1.c
>> @@ -0,0 +1,170 @@
>> +/*
[...]
>> + np =3D of_find_compatible_node(NULL, "network", "ucc_geth");
>> + if (np !=3D NULL) {
>> + uint svid;
>> +
>> + /* handle mpc8360ea rev.2.1 erratum 2: RGMII Timing */
>> + svid =3D mfspr(SPRN_SVR);
>> + if (svid =3D=3D 0x80480021) {
>> + void __iomem *immap;
>> +
>> + immap =3D ioremap(get_immrbase() + 0x14a8, 8);
>=20
> we should add a proper device node to cover whatever register space =
this
> is.
What if we do something like the following:
1) add in the soc node an "errata" node and in this "errata" node
we can add all CPU specific errata as an example the qe_enet10
errata, which above code covers:
soc8360@e0000000 {
[...]
errata {
device_type =3D "errata";
compatible =3D "fsl,mpc83xx_errata";
#address-cells =3D <1>;
#size-cells =3D <1>;
qe_enet10@14a8 {
device_type =3D "errata";
compatible =3D =
"fsl,mpc83xx_errata_qe_enet10";
reg =3D <0x14a8 0x08>;
};
};
[...]
};
2) we add in arch/powerpc/sysdev/fsl_soc.c a
static int __init mpc83xx_errata_init(void)
function, which holds the code for the errata
If you agree with that, I can make a patch ...
Hmm.. Is it OK, if I first sent a v2 of the "83xx: add support for
the kmeter1 board." with the QE_ENET10 errata in kmeter1.c (as it is
also for the mpc836x_mds board), and then send a seperate patch, which
removes this errata from the two boards?
bye
Heiko
--=20
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] powerpc: Fix oprofile sampling of marked events on POWER7
From: Mike Wolf @ 2009-05-07 15:48 UTC (permalink / raw)
To: linuxppc-dev
From: Maynard Johnson <maynardj@us.ibm.com>
Description
-----------
Change ppc64 oprofile kernel driver to use the SLOT bits (MMCRA[37:39]only on
older processors where those bits are defined.
Background
----------
The performance monitor unit of the 64-bit POWER processor family has the
ability to collect accurate instruction-level samples when profiling on marked
events (i.e., "PM_MRK_<event-name>"). In processors prior to POWER6, the MMCRA
register contained "slot information" that the oprofile kernel driver used to
adjust the value latched in the SIAR at the time of a PMU interrupt. But as of
POWER6, these slot bits in MMCRA are no longer necessary for oprofile to use,
since the SIAR itself holds the accurate sampled instruction address. With
POWER6, these MMCRA slot bits were zero'ed out by hardware so oprofile's use of
these slot bits was, in effect, a NOP. But with POWER7, these bits are no
longer zero'ed out; however, they serve some other purpose rather than slot
information. Thus, using these bits on POWER7 to adjust the SIAR value results
in samples being attributed to the wrong instructions. The attached patch
changes the oprofile kernel driver to ignore these slot bits on all newer
processors starting with POWER6.
Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>
Signed-off-by: Michael Wolf <mjw@linux.vnet.ibm.com>
---
diff -paur linux/arch/powerpc/oprofile/op_model_power4.c linux-p7-oprofile-patch//arch/powerpc/oprofile/op_model_power4.c
--- linux/arch/powerpc/oprofile/op_model_power4.c 2009-05-01 08:20:21.000000000 -0500
+++ linux-p7-oprofile-patch//arch/powerpc/oprofile/op_model_power4.c 2009-05-01 08:20:05.000000000 -0500
@@ -26,6 +26,7 @@
static unsigned long reset_value[OP_MAX_COUNTER];
static int oprofile_running;
+static int use_slot_nums;
/* mmcr values are set in power4_reg_setup, used in power4_cpu_setup */
static u32 mmcr0_val;
@@ -61,6 +62,12 @@ static int power4_reg_setup(struct op_co
else
mmcr0_val |= MMCR0_PROBLEM_DISABLE;
+ if (__is_processor(PV_POWER4) || __is_processor(PV_POWER4p) ||
+ __is_processor(PV_970) || __is_processor(PV_970FX) ||
+ __is_processor(PV_970MP) || __is_processor(PV_970GX) ||
+ __is_processor(PV_POWER5) || __is_processor(PV_POWER5p))
+ use_slot_nums = 1;
+
return 0;
}
@@ -206,7 +213,7 @@ static unsigned long get_pc(struct pt_re
mmcra = mfspr(SPRN_MMCRA);
- if (mmcra & MMCRA_SAMPLE_ENABLE) {
+ if (use_slot_nums && (mmcra & MMCRA_SAMPLE_ENABLE)) {
slot = ((mmcra & MMCRA_SLOT) >> MMCRA_SLOT_SHIFT);
if (slot > 1)
pc += 4 * (slot - 1);
^ permalink raw reply
* Re: MPC5121 new board constantly resetting after u-boot passes control to Linux
From: David Jander @ 2009-05-07 15:26 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <c788c1220905070143t5271ebe1ra12df43f8f53e491@mail.gmail.com>
On Thursday 07 May 2009 10:43:49 Damien Dusha wrote:
> Dear all,
>
> We are attempting to bring up a new MPC5121e board, somewhat based on the
> Silicon Turnkey's ADS5121 development board. We are using a kernel and
> u-boot based on Freescale/STx's board support package.
Somewhat based on the ADS? How much? The ADS is quite a "special" board, and
no other board should be similar with it (unless you have some strange reason
to even copy the CPLD that's on it, which I assume you did not).
> We have successfully modified u-boot for the 64MB of DDR2 RAM, and we can
> use u-boot's (and the BDI's) memory test facility to check that the RAM is
> working.
>
> Our problem is that as soon as control is passed from u-boot to Linux, the
> board immediately resets. It appears that the kernel has been decompressed
> correctly, and the memory at 0x00000000 appears to be similar to the same
> memory on the ADS board at the same address. i.e. We have some confidence
> that the kernel is being decompressed correctly.
>
> With debug on, u-boot produces the following output on the console:
>
> U-Boot 2009.01-svn27683 (May 07 2009 - 15:35:15) MPC512X
>
> CPU: MPC5121e rev. 2.0, Core e300c4 at 396 MHz, CSB at 198 MHz
>Board: ADS5121 rev. 0x0000 (CPLD rev. 0x00)
>[...removed lots of hard-to-read text output...]
The ADS5121 board has a CPLD that is being initialized at the beginning, and
your output looks like you have not actually created a different
board-support/name for your hardware. So I suspect, the linux kernel and/or
your device tree is expecting the CPLD where there is probably no such CPLD,
hence the crash.
You should try to create your own board-support stuff
in /arch/powerpc/platforms/512x/... or use the generic support as it exists
in mailine linux already. Then make your own DTS file describing YOUR
hardware and be careful not to mention the ADS-board anywhere in it
(specially not in "compatible..." sentences), to avoid confusing linux
drivers that do special things for the ADS, that will probably break things
for you.
Please also fix your u-boot BSP...
Best regards,
--
David Jander
Protonic Holland.
^ permalink raw reply
* Re: [PATCH 0/5] rapidio: adding memory mapping IO support and misc fixes
From: Kumar Gala @ 2009-05-07 15:21 UTC (permalink / raw)
To: Jan Neskudla; +Cc: linuxppc-dev
In-Reply-To: <1241705447.19689.114.camel@demuxf9c>
On May 7, 2009, at 9:10 AM, Jan Neskudla wrote:
> And one more think, when I enabled usage of DMA, rionet does not
> compile too,
> but in this case I do not have a fix. I tested this on kernel
> 2.6.29.1 and
> EP8548 as target board.
What exactly do you mean by that? What CONFIG options cause compile
failure? Can you post the compiler error.
- k
^ permalink raw reply
* howto disable dcache (on a MPC8313)
From: Norbert van Bolhuis @ 2009-05-07 15:06 UTC (permalink / raw)
To: linuxppc-dev
We have a network-switch connected via PCI which comes with 3rd
party (kernel) software.
The frames trapped by the switch and sent to CPU (with DMA)
are corrupt.
To rule out any data cache problems (which probably isn't causing
our problem) I thought I "quickly" disable the data cache.
we use a pretty standard linux-2.6.28 kernel (on our custom MPC8313E
board).
I first tried to mark the one BAT entry that the kernel setups as
cache_inhibit. I replaced setbat(..., _PAGE_RAM) by
setbat(..., _PAGE_IO) (in mmu_mapin_ram). This results in the
kernel not booting at all.
I also tried to not set DCE in HID0 in u-boot, this results in
the board not booting up at all.
I couldn't find the kernel source for setting HID0. It's not
op_powerpc_cpu_setup since CONFIG_OPROFILE isn't set (but
CONFIG_HAVE_OPROFILE is ?)
Is there a way to (simply) disable dcache for MPC8313 ?
Btw. some other architecturs (e.g. blackfin) have a kernel config option
to disable DCACHE.
---
N. van Bolhuis.
^ permalink raw reply
* RE: [PATCH 0/5] rapidio: adding memory mapping IO support and misc fixes
From: Jan Neskudla @ 2009-05-07 14:10 UTC (permalink / raw)
To: linuxppc-dev
Hallo,
I tested your patches, and the MMIO is working when enabled in the
rionet driver. Only the compilation of rionet as modules was a problem.
I had to add following lines into rio.c to export missing symbols.
EXPORT_SYMBOL_GPL(rio_unmap_inb_region);
EXPORT_SYMBOL_GPL(rio_map_inb_region);
EXPORT_SYMBOL_GPL(rio_unmap_outb_region);
EXPORT_SYMBOL_GPL(rio_map_outb_region);
And one more think, when I enabled usage of DMA, rionet does not compile too,
but in this case I do not have a fix. I tested this on kernel 2.6.29.1 and
EP8548 as target board.
Jan
>
> The patch series add MMIO support to Linux rapidio and fix a few nits.
> The patches cross rapidio, netdev, powerpc sub-systems. It will be
> good for them to go through one tree. Probably Andrew? As the
> previous rapidio patches are mostly merged by you.
>
> - Leo
^ permalink raw reply
* Re: [PATCH 02/12] fs_enet: Add MPC5121 FEC support.
From: Grant Likely @ 2009-05-07 14:09 UTC (permalink / raw)
To: Wolfgang Denk
Cc: Piotr Ziecik, Detlev Zundel, netdev, linuxppc-dev, John Rigby
In-Reply-To: <20090506224134.83F1583420E8@gemini.denx.de>
On Wed, May 6, 2009 at 4:41 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Grant,
>
> In message <fa686aa40905061529u11b231afle3b5bb10a2334ad0@mail.gmail.com> =
you wrote:
>>
>> > Agreed that it's ugly, but duplicatio9ng the code would have been even
>> > worse. I don't think that it has multiplatform - at least not as long
>> > as you don't ask for one image that runs on 83xx and on 512x.
>>
>> Actually, I *am* asking for one image that runs on 83xx, 52xx and
>> 521x. =A0I already can and do build and test a single image which boots
>> on all my 52xx boards, on my 8349 board, and on my G4 Mac.
>
> He. I was afraid you'd say that ;-)
>
> In this case I need a helping hand as I can't figure out how to make
> this work. Any suggestions?
Hmmm, it is rather ugly because the layout of fec_t is so different.
Easiest solution would be to duplicate the driver in its entirety, but
as you say it results in a lot of duplicate code. It might be the
lesser of many weevils though.
Second easiest would be to factor out all the common code in the
driver into a separate .c file that gets included by a 'wrapper' .c
file for each config which first includes the correct definition of
fec_t. This approach solves the duplicate code problem, but it also
fell out of the ugly tree and hit every branch on the way down.
ie: the wrappers would look something like this:
fs_enet_cpm1.c:
#include <asm/cpm1.h>
#include "fs_enet_main.c"
fs_enet_cpm2.c:
#include <asm/cpm2.h>
#include "fs_enet_main.c"
fs_enet_512x.c:
#include <asm/mpc512x.h>
#include "fs_enet_main.c"
And then the makefile would be something along the lines of:
obj-${CONFIG_FS_ENET_CPM1_ +=3D fs_enet_cpm1.o
obj-${CONFIG_FS_ENET_CPM2_ +=3D fs_enet_cpm2.o
obj-${CONFIG_FS_ENET_MPC512x_ +=3D fs_enet_512x.o
A brief look at the driver suggests that access to the fec_t structure
is restricted to the fec-mii.c and mac-fec.c files. It might be
appropriate to duplicate just those files and do some form of
fs_enet_ops to select between them.
While on the topic, it looks to me like the driver could really use
some refactoring love. Having multiple definitions of "fec_t" is
confusing and potentially lead to hard to find bugs if the wrong
header gets included by anyone. I'd like to see all the fec specific
stuff in arch/powerpc/include/asm moved into drivers/net/fs_enet and
renamed to reflect the hardware it is associate with. Stuff like
"fec_t" is far to generic, not to mention that typedefs are
discouraged now.
Regardless, I feel your pain. It is not a pretty situation.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 02/12] fs_enet: Add MPC5121 FEC support.
From: Kumar Gala @ 2009-05-07 13:05 UTC (permalink / raw)
To: Wolfgang Denk
Cc: Piotr Ziecik, John Rigby, netdev, linuxppc-dev, Detlev Zundel
In-Reply-To: <20090506220119.7322783420E8@gemini.denx.de>
On May 6, 2009, at 5:01 PM, Wolfgang Denk wrote:
> Dear Grant,
>
> in message <fa686aa40905061333q29c263c8p24856c048e30f4d0@mail.gmail.com
> > you wrote:
>>
> ...
>>> #ifdef CONFIG_FS_ENET_HAS_FEC
>>> +#ifdef CONFIG_FS_ENET_MPC5121_FEC
>>> + {
>>> + .compatible = "fsl,mpc5121-fec",
>>> + .data = (void *)&fs_fec_ops,
>>> + },
>>> +#else
>>> {
>>> .compatible = "fsl,pq1-fec-enet",
>>> .data = (void *)&fs_fec_ops,
>>> },
>>> #endif
>>> +#endif
>>
>> Hmmm. A lot of these #ifdefs in here. Does this have a
>> multiplatform
>> impact? Not to mention the fact that it's just plain ugly. :-)
>
> Agreed that it's ugly, but duplicatio9ng the code would have been even
> worse. I don't think that it has multiplatform - at least not as long
> as you don't ask for one image that runs on 83xx and on 512x.
We do ask for that. The fedora ppc6xx kernel should work on any 6xx/
7xx/7xxx based core chip. We should NOT be breaking such capability
in drivers.
- k
^ permalink raw reply
* Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
From: Ingo Molnar @ 2009-05-07 10:11 UTC (permalink / raw)
To: Nicholas Miell
Cc: linux-mips, linuxppc-dev, x86, linux-kernel, sparclinux,
Markus Gutschke (顧孟勤), Andrew Morton,
Linus Torvalds, stable, Roland McGrath
In-Reply-To: <1241670237.11500.7.camel@entropy>
* Nicholas Miell <nmiell@comcast.net> wrote:
> On Wed, 2009-05-06 at 15:21 -0700, Markus Gutschke (顧孟勤) wrote:
> > On Wed, May 6, 2009 at 15:13, Ingo Molnar <mingo@elte.hu> wrote:
> > > doing a (per arch) bitmap of harmless syscalls and replacing the
> > > mode1_syscalls[] check with that in kernel/seccomp.c would be a
> > > pretty reasonable extension. (.config controllable perhaps, for
> > > old-style-seccomp)
> > >
> > > It would probably be faster than the current loop over
> > > mode1_syscalls[] as well.
> >
> > This would be a great option to improve performance of our sandbox. I
> > can detect the availability of the new kernel API dynamically, and
> > then not intercept the bulk of the system calls. This would allow the
> > sandbox to work both with existing and with newer kernels.
> >
> > We'll post a kernel patch for discussion in the next few days,
> >
>
> I suspect the correct thing to do would be to leave seccomp mode 1
> alone and introduce a mode 2 with a less restricted set of system
> calls -- the interface was designed to be extended in this way,
> after all.
Yes, that is what i alluded to above via the '.config controllable'
aspect.
Mode 2 could be implemented like this: extend prctl_set_seccomp()
with a bitmap pointer, and copy it to a per task seccomp context
structure.
a bitmap for 300 syscalls takes only about 40 bytes.
Please take care to implement nesting properly: if a seccomp context
does a seccomp call (which mode 2 could allow), then the resulting
bitmap should be the logical-AND of the parent and child bitmaps.
There's no reason why seccomp couldnt be used in hiearachy of
sandboxes, in a gradually less permissive fashion.
Ingo
^ permalink raw reply
* Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
From: Joakim Tjernlund @ 2009-05-07 9:30 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20090507091948.6C86883420E8@gemini.denx.de>
Wolfgang Denk <wd@denx.de> wrote on 07/05/2009 11:19:48:
>
> Dear Joakim Tjernlund,
>
> In message
<OF97606123.49B50465-ONC12575AF.002E2518-C12575AF.002E6300@transmode.se>
you wrote:
> >
> > Just a stab in the dark: Perhaps the fec->fecp->fec_mii_speed field is
> > misaligned or is 16 bits ?
>
> Good idea. The RM documents the register at offset 0x44 and describes
> it as 32 bits... and it's working fine on the MPC5121ADS board, but
> fails on ARIA.
OK, this is just a guess too: Some odd byte order requirements?
No more ideas, sorry.
Jocke
^ permalink raw reply
* Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
From: Wolfgang Denk @ 2009-05-07 9:19 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev
In-Reply-To: <OF97606123.49B50465-ONC12575AF.002E2518-C12575AF.002E6300@transmode.se>
Dear Joakim Tjernlund,
In message <OF97606123.49B50465-ONC12575AF.002E2518-C12575AF.002E6300@transmode.se> you wrote:
>
> Just a stab in the dark: Perhaps the fec->fecp->fec_mii_speed field is
> misaligned or is 16 bits ?
Good idea. The RM documents the register at offset 0x44 and describes
it as 32 bits... and it's working fine on the MPC5121ADS board, but
fails on ARIA.
Thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Lots of people drink from the wrong bottle sometimes.
-- Edith Keeler, "The City on the Edge of Forever",
stardate unknown
^ permalink raw reply
* MPC5121 new board constantly resetting after u-boot passes control to Linux
From: Damien Dusha @ 2009-05-07 8:43 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 11707 bytes --]
Dear all,
We are attempting to bring up a new MPC5121e board, somewhat based on the
Silicon Turnkey's ADS5121 development board. We are using a kernel and
u-boot based on Freescale/STx's board support package.
We have successfully modified u-boot for the 64MB of DDR2 RAM, and we can
use u-boot's (and the BDI's) memory test facility to check that the RAM is
working.
Our problem is that as soon as control is passed from u-boot to Linux, the
board immediately resets. It appears that the kernel has been decompressed
correctly, and the memory at 0x00000000 appears to be similar to the same
memory on the ADS board at the same address. i.e. We have some confidence
that the kernel is being decompressed correctly.
With debug on, u-boot produces the following output on the console:
U-Boot 2009.01-svn27683 (May 07 2009 - 15:35:15)
MPC512X
CPU: MPC5121e rev. 2.0, Core e300c4 at 396 MHz, CSB at 198
MHz
Board: ADS5121 rev. 0x0000 (CPLD rev.
0x00)
I2C: 85
kHz,
85
kHz,
85
kHz,
ready
DRAM: 64
MB
Top of RAM usable for U-Boot at:
04000000
Reserving 249k for U-Boot at:
03fc1000
Reserving 520k for malloc() at:
03f3f000
Reserving 60 Bytes for Board Info at:
03f3efc4
Reserving 64 Bytes for Global Data at:
03f3ef84
Stack Pointer at:
03f3ef68
New Stack Pointer is:
03f3ef68
Now running in RAM - U-Boot at:
03fc1000
FLASH: flash detect
cfi
fwc addr fc000000 cmd f0 f0 8bit x 8
bit
fwc addr fc000000 cmd ff ff 8bit x 8
bit
fwc addr fc000055 cmd 98 98 8bit x 8
bit
is= cmd 51(Q) addr fc000010 is= 30
51
fwc addr fc000555 cmd 98 98 8bit x 8
bit
is= cmd 51(Q) addr fc000010 is= 0
51
fwc addr fc000000 cmd f0 f0f0 16bit x 8
bit
fwc addr fc000000 cmd ff ffff 16bit x 8
bit
fwc addr fc0000aa cmd 98 9898 16bit x 8
bit
is= cmd 51(Q) addr fc000020 is= 2032
5151
fwc addr fc000aaa cmd 98 9898 16bit x 8
bit
is= cmd 51(Q) addr fc000020 is= 2032
5151
fwc addr fc000000 cmd f0 00f0 16bit x 16
bit
fwc addr fc000000 cmd ff 00ff 16bit x 16
bit
fwc addr fc0000aa cmd 98 0098 16bit x 16
bit
is= cmd 51(Q) addr fc000020 is= 2032
0051
fwc addr fc000aaa cmd 98 0098 16bit x 16
bit
is= cmd 51(Q) addr fc000020 is= 2032
0051
fwc addr fc000000 cmd f0 f0f0f0f0 32bit x 8
bit
fwc addr fc000000 cmd ff ffffffff 32bit x 8
bit
fwc addr fc000154 cmd 98 98989898 32bit x 8
bit
is= cmd 51(Q) addr fc000040 is= 00510051
51515151
fwc addr fc001554 cmd 98 98989898 32bit x 8
bit
is= cmd 51(Q) addr fc000040 is= 00510051
51515151
fwc addr fc000000 cmd f0 00f000f0 32bit x 16
bit
fwc addr fc000000 cmd ff 00ff00ff 32bit x 16
bit
fwc addr fc000154 cmd 98 00980098 32bit x 16
bit
is= cmd 51(Q) addr fc000040 is= 00510051
00510051
is= cmd 52(R) addr fc000044 is= 00520052
00520052
is= cmd 59(Y) addr fc000048 is= 00590059
00590059
device interface is
2
found port 4 chip 2 port 32 bits chip 16
bits
00 : 51 52 59 02 00 40 00 00 00 00 00 27 36 00 00 06 QRY..@.....'6...
10 : 06 09 13 03 05 03 02 19 02 00 06 00 01 ff 00 00
................
20 : 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01
................
fwc addr fc000000 cmd f0 00f000f0 32bit x 16
bit
fwc addr fc001554 cmd aa 00aa00aa 32bit x 16
bit
fwc addr fc000aa8 cmd 55 00550055 32bit x 16
bit
fwc addr fc001554 cmd 90 00900090 32bit x 16
bit
fwc addr fc000000 cmd f0 00f000f0 32bit x 16
bit
fwc addr fc000154 cmd 98 00980098 32bit x 16
bit
manufacturer is
2
manufacturer id is
0x1
device id is
0x227e
device id2 is
0x0
cfi version is
0x3133
size_ratio 2 port 32 bits chip 16
bits
found 1 erase
regions
erase region 0:
0x020000ff
erase_region_count = 256 erase_region_size =
131072
fwc addr fc000000 cmd f0 00f000f0 32bit x 16
bit
flash_protect ON: from 0xFFF00000 to
0xFFF36FFF
protect on
252
flash_protect ON: from 0xFFF40000 to
0xFFF7FFFF
protect on
253
flash_protect ON: from 0xFFF80000 to
0xFFF81FFF
protect on
254
64
MB
In:
serial
Out:
serial
Err:
serial
i2c_write: failed to address
chip
i2c_read: failed to address
chip
DVI Encoder Read:
0x00
i2c_write: failed to address
chip
i2c_read: failed to address
chip
DVI Encoder Read:
0x00
U-Boot relocated to
03fc1000
Net: FEC
ETHERNET
Type "run flash_nfs" to mount root filesystem over
NFS
### main_loop entered:
bootdelay=5
### main_loop: bootcmd="run
cramfsboot"
Hit any key to stop autoboot:
0
=>
U-Boot 2009.01-svn27683 (May 07 2009 - 15:35:15)
MPC512X
CPU: MPC5121e rev. 2.0, Core e300c4 at 396 MHz, CSB at 198
MHz
Board: ADS5121 rev. 0x0000 (CPLD rev.
0x00)
I2C: 85
kHz,
85
kHz,
85
kHz,
ready
DRAM: 64
MB
Top of RAM usable for U-Boot at:
04000000
Reserving 249k for U-Boot at:
03fc1000
Reserving 520k for malloc() at:
03f3f000
Reserving 60 Bytes for Board Info at:
03f3efc4
Reserving 64 Bytes for Global Data at:
03f3ef84
Stack Pointer at:
03f3ef68
New Stack Pointer is:
03f3ef68
Now running in RAM - U-Boot at:
03fc1000
FLASH: flash detect
cfi
fwc addr fc000000 cmd f0 f0 8bit x 8
bit
fwc addr fc000000 cmd ff ff 8bit x 8
bit
fwc addr fc000055 cmd 98 98 8bit x 8
bit
is= cmd 51(Q) addr fc000010 is= 30
51
fwc addr fc000555 cmd 98 98 8bit x 8
bit
is= cmd 51(Q) addr fc000010 is= 0
51
fwc addr fc000000 cmd f0 f0f0 16bit x 8
bit
fwc addr fc000000 cmd ff ffff 16bit x 8
bit
fwc addr fc0000aa cmd 98 9898 16bit x 8
bit
is= cmd 51(Q) addr fc000020 is= 2032
5151
fwc addr fc000aaa cmd 98 9898 16bit x 8
bit
is= cmd 51(Q) addr fc000020 is= 2032
5151
fwc addr fc000000 cmd f0 00f0 16bit x 16
bit
fwc addr fc000000 cmd ff 00ff 16bit x 16
bit
fwc addr fc0000aa cmd 98 0098 16bit x 16
bit
is= cmd 51(Q) addr fc000020 is= 2032
0051
fwc addr fc000aaa cmd 98 0098 16bit x 16
bit
is= cmd 51(Q) addr fc000020 is= 2032
0051
fwc addr fc000000 cmd f0 f0f0f0f0 32bit x 8
bit
fwc addr fc000000 cmd ff ffffffff 32bit x 8
bit
fwc addr fc000154 cmd 98 98989898 32bit x 8
bit
is= cmd 51(Q) addr fc000040 is= 00510051
51515151
fwc addr fc001554 cmd 98 98989898 32bit x 8
bit
is= cmd 51(Q) addr fc000040 is= 00510051
51515151
fwc addr fc000000 cmd f0 00f000f0 32bit x 16
bit
fwc addr fc000000 cmd ff 00ff00ff 32bit x 16
bit
fwc addr fc000154 cmd 98 00980098 32bit x 16
bit
is= cmd 51(Q) addr fc000040 is= 00510051
00510051
is= cmd 52(R) addr fc000044 is= 00520052
00520052
is= cmd 59(Y) addr fc000048 is= 00590059
00590059
device interface is
2
found port 4 chip 2 port 32 bits chip 16
bits
00 : 51 52 59 02 00 40 00 00 00 00 00 27 36 00 00 06 QRY..@.....'6...
10 : 06 09 13 03 05 03 02 19 02 00 06 00 01 ff 00 00
................
20 : 02 00 00 00 00 00 00 00 00 00 00 00 00 f7 ff fd
................
fwc addr fc000000 cmd f0 00f000f0 32bit x 16
bit
fwc addr fc001554 cmd aa 00aa00aa 32bit x 16
bit
fwc addr fc000aa8 cmd 55 00550055 32bit x 16
bit
fwc addr fc001554 cmd 90 00900090 32bit x 16
bit
fwc addr fc000000 cmd f0 00f000f0 32bit x 16
bit
fwc addr fc000154 cmd 98 00980098 32bit x 16
bit
manufacturer is
2
manufacturer id is
0x1
device id is
0x227e
device id2 is
0x0
cfi version is
0x3133
size_ratio 2 port 32 bits chip 16
bits
found 1 erase
regions
erase region 0:
0x020000ff
erase_region_count = 256 erase_region_size =
131072
fwc addr fc000000 cmd f0 00f000f0 32bit x 16
bit
flash_protect ON: from 0xFFF00000 to
0xFFF36FFF
protect on
252
flash_protect ON: from 0xFFF40000 to
0xFFF7FFFF
protect on
253
flash_protect ON: from 0xFFF80000 to
0xFFF81FFF
protect on
254
64
MB
In:
serial
Out:
serial
Err:
serial
i2c_write: failed to address
chip
i2c_read: failed to address
chip
DVI Encoder Read:
0x00
i2c_write: failed to address
chip
i2c_read: failed to address
chip
DVI Encoder Read:
0x00
U-Boot relocated to
03fc1000
Net: FEC
ETHERNET
Type "run flash_nfs" to mount root filesystem over
NFS
### main_loop entered:
bootdelay=5
### main_loop: bootcmd="run
cramfsboot"
Hit any key to stop autoboot:
0
=>
boot
## Current stack ends at
0x03f3e8f8
* kernel: cmdline image address =
0xffc40000
## Booting kernel from Legacy Image at ffc40000
...
Image Name:
Linux-2.6.24.6
Created: 2009-04-30 3:54:13
UTC
Image Type: PowerPC Linux Kernel Image (gzip
compressed)
Data Size: 1782150 Bytes = 1.7
MB
Load Address:
00000000
Entry Point:
00000000
Verifying Checksum ...
OK
kernel data at 0xffc40040, len = 0x001b3186
(1782150)
## Skipping init
Ramdisk
## No init
Ramdisk
ramdisk start = 0x00000000, ramdisk end =
0x00000000
* fdt: cmdline image address =
0xffec0000
## Checking for 'FDT'/'FDT Image' at
ffec0000
* fdt: raw FDT
blob
## Flattened Device Tree blob at
ffec0000
Booting using the fdt blob at
0xffec0000
of_flat_tree at 0xffec0000 size
0x00000e06
Uncompressing Kernel Image ...
OK
kernel loaded at 0x00000000, end =
0x003ac244
## initrd_high = 0xffffffff, copy_to_ram =
1
ramdisk load start = 0x00000000, ramdisk load end =
0x00000000
## device tree at 0xFFEC0000 ... 0xFFEC0E05
(len=15878=0x3E06)
Loading Device Tree to 007fc000, end 007ffe05 ...
OK
Updating property 'local-mac-address' = 00 00 00 00 00
00
Updating property 'address' = 00 00 00 00 00
00
Updating property 'bus-frequency' = 03 ef 14
80
Updating property '/cpus/PowerPC,5121@0/timebase-frequency' = 02 f3 4f
60
Updating property '/cpus/PowerPC,5121@0/bus-frequency' = 0b cd 3d
80
Updating property '/cpus/PowerPC,5121@0/clock-frequency' = 17 9a 7b
00
Updating property 'bus-frequency' = 03 ef 14
80
## Transferring control to Linux (at address 00000000)
...
Booting using OF flat tree... (at address
007fc000)
At this point, the board immediately resets. There is no hint of life from
the kernel from the console, although setting a breakpoint on the BDI at
0x0000000 and tracing through appears as though some code (although we don't
know what) is being executed.
Our u-boot environment is as follows:
=>
printenv
bootdelay=5
baudrate=115200
loads_echo=1
preboot=echo;echo Type \"run flash_nfs\" to mount root filesystem over
NFS;echo
rootpath=/opt/eldk/ppc_6xx
hostname=gg200
bootfile=gg200/uImage
loadaddr=400000
u-boot_addr_r=200000
kernel_addr_r=600000
fdt_addr_r=880000
ramdisk_addr_r=900000
u-boot_addr=FFF00000
kernel_addr=FFC40000
fdt_addr=FFEC0000
ramdisk_addr=FC040000
ramdiskfile=ads5121/uRamdisk
u-boot=ads5121/u-boot.bin
bootfile=ads5121/uImage
fdtfile=ads5121/ads5121.dtb
rootpath=/opt/eldk/ppc_6xx
netdev=eth0
consdev=ttyPSC0
nfsargs=setenv bootargs root=/dev/nfs rw
nfsroot=${serverip}:${rootpath}
ramargs=setenv bootargs root=/dev/ram
rw
addip=setenv bootargs ${bootargs}
ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:${netdev}:off
panic=1
addtty=setenv bootargs ${bootargs}
console=${consdev},${baudrate}
flash_nfs=run nfsargs addip addtty;bootm ${kernel_addr} -
${fdt_addr}
flash_self=run ramargs addip addtty;bootm ${kernel_addr} ${ramdisk_addr}
${fdt_addr}
net_nfs=tftp ${kernel_addr_r} ${bootfile};tftp ${fdt_addr_r} ${fdtfile};run
nfsargs addip addtty;bootm ${kernel_addr_r} -
${fdt_addr_r}
net_self=tftp ${kernel_addr_r} ${bootfile};tftp ${ramdisk_addr_r}
${ramdiskfile};tftp ${fdt_addr_r} ${fdtfile};run ramargs addip addtty;bootm
${kernel_addr_r} ${ramdisk_a}
load=tftp ${u-boot_addr_r}
${u-boot}
update=protect off ${u-boot_addr} +${filesize};era ${u-boot_addr}
+${filesize};cp.b ${u-boot_addr_r} ${u-boot_addr}
${filesize}
upd=run load
update
ethact=FEC
ETHERNET
cramfsboot=set bootargs root=/dev/mtdblock1 mem=64M; run addtty;bootm
${kernel_addr} -
${fdt_addr}
bootcmd=run
cramfsboot
stdin=serial
stdout=serial
stderr=serial
If anyone is able to provide some help as to where we should start looking
for our problem (or how we can stop it from immediately rebooting, or trap
the reboot on the BDI), we would be extremely grateful for the help.
Best regards
Damien.
[-- Attachment #2: Type: text/html, Size: 48629 bytes --]
^ permalink raw reply
* Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
From: Joakim Tjernlund @ 2009-05-07 8:26 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <1241641262-5202-6-git-send-email-wd@denx.de>
>
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: John Rigby <jcrigby@gmail.com>
> ---
> This patch is NOT intended for inclusion into mainline, but rather a
> request for help. For some reason which I don't understand yet, the
> Ethernet interface on the ARIA board does not work in the default
> configuration, because MII probing fails.
>
> What I'm seeing is this; the problem is with this part of code in
> "drivers/net/fs_enet/mii-fec.c":
>
> 156 fec->mii_speed = ((ppc_proc_freq + 4999999) / 5000000) << 1;
> ...
> 163 out_be32(&fec->fecp->fec_mii_speed, fec->mii_speed);
Just a stab in the dark: Perhaps the fec->fecp->fec_mii_speed field is
misaligned or is 16 bits ?
Jocke
^ permalink raw reply
* Re: [PATCH 02/12] fs_enet: Add MPC5121 FEC support.
From: David Jander @ 2009-05-07 8:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Wolfgang Denk, Piotr Ziecik
In-Reply-To: <fa686aa40905061529u11b231afle3b5bb10a2334ad0@mail.gmail.com>
On Thursday 07 May 2009 00:29:59 Grant Likely wrote:
> On Wed, May 6, 2009 at 4:01 PM, Wolfgang Denk <wd@denx.de> wrote:
> > Dear Grant,
> >
> > in message <fa686aa40905061333q29c263c8p24856c048e30f4d0@mail.gmail.com>
> > you wrote:
> >
> > ...
> >
> >> > #ifdef CONFIG_FS_ENET_HAS_FEC
> >> > +#ifdef CONFIG_FS_ENET_MPC5121_FEC
> >> > + =A0 =A0{
> >> > + =A0 =A0 =A0 =A0.compatible =3D "fsl,mpc5121-fec",
> >> > + =A0 =A0 =A0 =A0.data =3D (void *)&fs_fec_ops,
> >> > + =A0 =A0},
> >> > +#else
> >> > =A0 =A0{
> >> > =A0 =A0 =A0 =A0.compatible =3D "fsl,pq1-fec-enet",
> >> > =A0 =A0 =A0 =A0.data =3D (void *)&fs_fec_ops,
> >> > =A0 =A0},
> >> > #endif
> >> > +#endif
> >>
> >> Hmmm. =A0A lot of these #ifdefs in here. =A0Does this have a multiplat=
form
> >> impact? =A0Not to mention the fact that it's just plain ugly. =A0:-)
> >
> > Agreed that it's ugly, but duplicatio9ng the code would have been even
> > worse. I don't think that it has multiplatform - at least not as long
> > as you don't ask for one image that runs on 83xx and on 512x.
>
> Actually, I *am* asking for one image that runs on 83xx, 52xx and
> 521x. I already can and do build and test a single image which boots
> on all my 52xx boards, on my 8349 board, and on my G4 Mac.
Cool! I also want that! We have different boards with 5200 and 5121e's and =
it=20
would be terrific if one day we'd be able to use just one kernel for all of=
=20
them!
(Sorry for being a me-too-er)
Best regards,
=2D-=20
David Jander
Protonic Holland.
^ permalink raw reply
* Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
From: Markus Gutschke (顧孟勤) @ 2009-05-07 8:01 UTC (permalink / raw)
To: Roland McGrath
Cc: linux-mips, Andrew Morton, x86, linux-kernel, linuxppc-dev,
sparclinux, Ingo Molnar, Linus Torvalds, stable
In-Reply-To: <20090507070312.DCC5EFC39E@magilla.sf.frob.com>
On Thu, May 7, 2009 at 00:03, Roland McGrath <roland@redhat.com> wrote:
>
> That is not a "ptrace problem" per se at all. =C2=A0It's an intrinsic pro=
blem
> with any method based on "generic" syscall interception, if the filtering
> and enforcement decisions depend on examining user memory.
Yes, this is indeed the main problem that we are aware of. It can be
avoided by suspending all threads during user memory inspection, but
that's a horrible price to pay (also: see below for an alternative
approach, that could in principle be adapted to use with ptrace)
> The only reason seccomp does not have this "reliability problem" is that
> its filtering is trivial and depends only on registers (in fact, only on
> one register, the syscall number).
Simplicity is really the beauty of seccomp. It is very easy to verify
that it does the right thing from a security point of view, because
any attempt to call unsafe system calls results in the kernel
terminating the program. This is much preferable over most ptrace
solutions which is more difficult to audit for correctness.
The downside is that the sandbox'd code needs to delegate execution of
most of its system calls to a monitor process. This is slow and rather
awkward. Although due to the magic of clone(), (almost) all system
calls can in fact be serialized, sent to the monitor process, have
their arguments safely inspected, and then executed on behalf of the
sandbox'd process. Details are tedious but we believe they are
solvable with current kernel APIs.
The other issue is performance. For system calls that are known to be
safe, we would rather not pay the penalty of redirecting them. A
kernel patch that made seccomp more efficient for these system calls
would be very welcome, and we will post such a patch for discussion
shortly.
> If you want to do checks that depend on shared or volatile state, then
> syscall interception is really not the proper mechanism for you.
We agree that syscall interception is a poor abstraction level for a
sandbox. But in the short term, we need to work with the APIs that are
available in today's kernels. And we believe that seccomp is one of
the more promising API that are currently available to us.
Markus
^ permalink raw reply
* Re: [PATCH 06/12] mpc5121: Added NAND Flash Controller driver.
From: David Jander @ 2009-05-07 8:08 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-mtd, Wolfgang Denk, Piotr Ziecik
In-Reply-To: <1241640919-4650-7-git-send-email-wd@denx.de>
On Wednesday 06 May 2009 22:15:13 Wolfgang Denk wrote:
> --- /dev/null
> +++ b/drivers/mtd/nand/mpc5121_nfc.c
>[...]
> +/* Init external chip select logic on ADS5121 board */
> +static int ads5121_chipselect_init(struct mtd_info *mtd)
> +{
> + struct nand_chip *chip = mtd->priv;
> + struct mpc5121_nfc_prv *prv = chip->priv;
> + struct device_node *dn;
> +
> + dn = of_find_compatible_node(NULL, NULL, "fsl,mpc5121ads-cpld");
> + if (dn) {
> + prv->csreg = of_iomap(dn, 0);
> + of_node_put(dn);
> + if (!prv->csreg)
> + return -ENOMEM;
> +
> + /* CPLD Register 9 controls NAND /CE Lines */
> + prv->csreg += 9;
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +
> +/* Control chips select signal on ADS5121 board */
> +static void ads5121_select_chip(struct mtd_info *mtd, int chip)
> +{
> + struct nand_chip *nand = mtd->priv;
> + struct mpc5121_nfc_prv *prv = nand->priv;
> + u8 v;
> +
> + v = in_8(prv->csreg);
> + v |= 0x0F;
> +
> + if (chip >= 0) {
> + mpc5121_nfc_select_chip(mtd, 0);
> + v &= ~(1 << chip);
> + } else
> + mpc5121_nfc_select_chip(mtd, -1);
> +
> + out_8(prv->csreg, v);
> +}
I am just a humble beginner, but isn't this platform dependend code supposed
to be in /arch/powerpc/platforms/.... ?
>[...]
> +static int __init mpc5121_nfc_probe(struct of_device *op,
> + const struct of_device_id *match)
> +{
> + struct device_node *rootnode, *dn = op->node;
> + struct device *dev = &op->dev;
> + struct mpc5121_nfc_prv *prv;
> + struct resource res;
> + struct mtd_info *mtd;
> +#ifdef CONFIG_MTD_PARTITIONS
> + struct mtd_partition *parts;
> +#endif
> + struct nand_chip *chip;
> + unsigned long regs_paddr, regs_size;
> + const uint *chips_no;
> + int resettime = 0;
> + int retval = 0;
> + int rev, len;
> +
> + /*
> + * Check SoC revision. This driver supports only NFC
> + * in MPC5121 revision 2.
> + */
> + rev = (mfspr(SPRN_SVR) >> 4) & 0xF;
> + if (rev != 2) {
> + printk(KERN_ERR DRV_NAME
> + ": SoC revision %u is not supported!\n", rev);
> + return -ENXIO;
> + }
> +
> + prv = devm_kzalloc(dev, sizeof(*prv), GFP_KERNEL);
> + if (!prv) {
> + printk(KERN_ERR DRV_NAME ": Memory exhausted!\n");
> + return -ENOMEM;
> + }
> +
> + mtd = &prv->mtd;
> + chip = &prv->chip;
> +
> + mtd->priv = chip;
> + chip->priv = prv;
> +
> + /* Read NFC configuration from Reset Config Word */
> + retval = mpc5121_nfc_read_hw_config(mtd);
> + if (retval) {
> + printk(KERN_ERR DRV_NAME ": Unable to read NFC config!\n");
> + return retval;
> + }
> +
> + prv->irq = irq_of_parse_and_map(dn, 0);
> + if (prv->irq == NO_IRQ) {
> + printk(KERN_ERR DRV_NAME ": Error mapping IRQ!\n");
> + return -EINVAL;
> + }
> +
> + retval = of_address_to_resource(dn, 0, &res);
> + if (retval) {
> + printk(KERN_ERR DRV_NAME ": Error parsing memory region!\n");
> + return retval;
> + }
> +
> + chips_no = of_get_property(dn, "chips", &len);
> + if (!chips_no || len != sizeof(*chips_no)) {
> + printk(KERN_ERR DRV_NAME ": Invalid/missing 'chips' "
> + "property!\n");
> + return -EINVAL;
> + }
> +
> + regs_paddr = res.start;
> + regs_size = res.end - res.start + 1;
> +
> + if (!devm_request_mem_region(dev, regs_paddr, regs_size, DRV_NAME)) {
> + printk(KERN_ERR DRV_NAME ": Error requesting memory region!\n");
> + return -EBUSY;
> + }
> +
> + prv->regs = devm_ioremap(dev, regs_paddr, regs_size);
> + if (!prv->regs) {
> + printk(KERN_ERR DRV_NAME ": Error mapping memory region!\n");
> + return -ENOMEM;
> + }
> +
> + mtd->name = "MPC5121 NAND";
> + chip->dev_ready = mpc5121_nfc_dev_ready;
> + chip->cmdfunc = mpc5121_nfc_command;
> + chip->read_byte = mpc5121_nfc_read_byte;
> + chip->read_word = mpc5121_nfc_read_word;
> + chip->read_buf = mpc5121_nfc_read_buf;
> + chip->write_buf = mpc5121_nfc_write_buf;
> + chip->verify_buf = mpc5121_nfc_verify_buf;
> + chip->select_chip = mpc5121_nfc_select_chip;
> + chip->options = NAND_NO_AUTOINCR | NAND_USE_FLASH_BBT;
> + chip->ecc.mode = NAND_ECC_SOFT;
> +
> + /* Support external chip-select logic on ADS5121 board */
> + rootnode = of_find_node_by_path("/");
> + if (of_device_is_compatible(rootnode, "fsl,mpc5121ads")) {
> + retval = ads5121_chipselect_init(mtd);
> + if (retval) {
> + printk(KERN_ERR DRV_NAME ": Chipselect init error!\n");
> + of_node_put(rootnode);
> + return retval;
> + }
> +
> + chip->select_chip = ads5121_select_chip;
> + }
Hmmm, I guess it would be overkill to build some sort of generic framework for
providing special chip-select functions here.... but it just doesn't look
clean like this.... oh well.
Best regards,
--
David Jander
Protonic Holland.
^ 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