RE: [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
> -Original Message- > From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On > Behalf Of Grant Likely > Sent: Thursday, July 08, 2010 12:38 AM > To: Benjamin Herrenschmidt > Cc: Steve Deiters; linuxppc-dev@lists.ozlabs.org > Subject: Re: [PATCH] arch/powerpc/lib/copy_32.S: Use > alternate memcpy for MPC512x and MPC52xx > > On Wed, Jul 7, 2010 at 11:10 PM, Benjamin Herrenschmidt > wrote: > > On Tue, 2010-06-29 at 11:04 -0500, Steve Deiters wrote: > >> These processors will corrupt data if accessing the local bus with > >> unaligned addresses. This version fixes the typical case > of copying > >> from Flash on the local bus by keeping the source address always > >> aligned. > > > > Shouldn't this be solved by using memcpy_to/fromio ? > > Maybe. plain memcpy() access to anything localbus-attached > on the mpc5xxx is the wrong thing to do. memcpy_to/fromio > might do the right thing; but the caller must understand the > limitations of the localplus bus. The byte-wise alignment > that memcpy_to/fromio() does may not work (depending on > configuration). > > Steve, what code is doing a memcpy from flash? > > g. This was done in the JFFS2 code, in fs/jffs2/scan.c. At least in one function, in jffs2_scan_dirent_node it was using memcpy on a localbus mapped structure. I was getting JFFS2 filesystem corruption because of this. In fact I first tried changing this to memcpy_fromio and it fixed that particular problem. I was concerned though that other places I was not aware of might be using memcpy from the localbus in a similar manner so I decided to just tweak the memcpy routine. Just out of curiousity, what configuration might cause a byte-wise alignment not to work? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
These processors will corrupt data if accessing the local bus with unaligned addresses. This version fixes the typical case of copying from Flash on the local bus by keeping the source address always aligned. Signed-off-by: Steve Deiters --- arch/powerpc/lib/copy_32.S | 56 1 files changed, 56 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/lib/copy_32.S b/arch/powerpc/lib/copy_32.S index 74a7f41..42e7df5 100644 --- a/arch/powerpc/lib/copy_32.S +++ b/arch/powerpc/lib/copy_32.S @@ -226,6 +226,60 @@ _GLOBAL(memmove) bgt backwards_memcpy /* fall through */ +#if defined(CONFIG_PPC_MPC512x) || defined(CONFIG_PPC_MPC52xx) + +/* + * Alternate memcpy for MPC512x and MPC52xx to guarantee source + * address is always aligned to prevent corruption issues when + * copying unaligned from the local bus. This only fixes the usage + * when copying from the local bus (e.g. Flash) and will not fix + * issues copying to the local bus + */ +_GLOBAL(memcpy) + srwi. r7,r5,3 + addir6,r3,-4 + addir4,r4,-4 + beq 2f /* if less than 8 bytes to do */ + andi. r0,r4,3 /* get src word aligned */ + mtctr r7 + bne 5f +1: lwz r7,4(r4) + lwzur8,8(r4) + stw r7,4(r6) + stwur8,8(r6) + bdnz1b + andi. r5,r5,7 +2: cmplwi 0,r5,4 + blt 3f + andi. r0,r4,3 + bne 3f + lwzur0,4(r4) + addir5,r5,-4 + stwur0,4(r6) +3: cmpwi 0,r5,0 + beqlr + mtctr r5 + addir4,r4,3 + addir6,r6,3 +4: lbzur0,1(r4) + stbur0,1(r6) + bdnz4b + blr +5: subfic r0,r0,4 + mtctr r0 +6: lbz r7,4(r4) + addir4,r4,1 + stb r7,4(r6) + addir6,r6,1 + bdnz6b + subfr5,r0,r5 + rlwinm. r7,r5,32-3,3,31 + beq 2b + mtctr r7 + b 1b + +#else + _GLOBAL(memcpy) srwi. r7,r5,3 addir6,r3,-4 @@ -267,6 +321,8 @@ _GLOBAL(memcpy) mtctr r7 b 1b +#endif + _GLOBAL(backwards_memcpy) rlwinm. r7,r5,32-3,3,31 /* r0 = r5 >> 3 */ add r6,r3,r5 -- 1.5.4.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: JFFS2 corruption when mounting filesystem with filenamesoflength> 7
> I think there may be something weird going on with the memcpy > in my build. If I use the following patch I no longer get > errors when I mount the filesystem. All I did was replace > the memcpy with a loop. > > I'm not sure what's special about this particular use of > memcpy. I can't believe that things would be working as well > as they do if memcpy was broken in general. > > This is on a PowerPC 32 bit build for a MPC5121. I am using > a GCC 4.1.2 to compile. Is anyone aware of any issues with > memcpy in this configuration? > > Thanks. It seems this processor is mangling the data when it access unaligned addresses into Flash with a lwz instruction. The memcpy implementation in copy_32.S aligns the destination, leaving the source possibly unaligned. In this particular instance the source is an address into my Flash address space which is causing the problem. When the filenames were < 8 it always does a bytewise copy which is why I wasn't having problems with those. It seems this only occurs when I have the translation enabled. If I clear the DR bit in the MSR and then repeat the instruction with the corresponding physical address it will read correctly. I'm not sure if this is expected behavior with this core. I can fix at least this one problem by using memcpy_fromio since it does alignment checks for the source and destination. I'm not sure what the proper fix is for this. If I use memcpy_fromio I think I'll just run into problems somewhere else. Any other suggestions? Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: JFFS2 corruption when mounting filesystem with filenames oflength> 7
> -Original Message-
> From: linux-mtd-boun...@lists.infradead.org
> [mailto:linux-mtd-boun...@lists.infradead.org] On Behalf Of
> Steve Deiters
> Sent: Thursday, June 24, 2010 3:02 PM
> To: linux-...@lists.infradead.org
> Subject: RE: JFFS2 corruption when mounting filesystem with
> filenames oflength> 7
>
> > -Original Message-
> > From: linux-mtd-boun...@lists.infradead.org
> > [mailto:linux-mtd-boun...@lists.infradead.org] On Behalf Of Steve
> > Deiters
> > Sent: Wednesday, June 23, 2010 5:42 PM
> > To: linux-...@lists.infradead.org
> > Subject: RE: JFFS2 corruption when mounting filesystem with
> filenames
> > oflength > 7
> >
> > > -Original Message-
> > > From: linux-mtd-boun...@lists.infradead.org
> > > [mailto:linux-mtd-boun...@lists.infradead.org] On Behalf Of Steve
> > > Deiters
> > > Sent: Wednesday, June 23, 2010 5:21 PM
> > > To: linux-...@lists.infradead.org
> > > Subject: JFFS2 corruption when mounting filesystem with
> > filenames of
> > > length > 7
> > >
> > > I found an archived post which seems to be identical to my issue.
> > > However, this is quite old and there never seemed to be any
> > > resolution.
> > >
> > > http://www.infradead.org/pipermail/linux-mtd/2006-September/01
> > > 6491.html
> > >
> > > If I mount a filesystem that has filenames greater than 7
> > characters
> > > in length, the files are corrupted when I mount.
> > > In my case, I am making a
> > > JFFS2 image with mkfs.jffs2 and flashing it in with u-boot.
> > > However, I have attached a workflow where I erase the Flash
> > and create
> > > a new filesystem completely within Linux and it gives the same
> > > behavior. I can list the files with the 'ls'
> > > command from within u-boot. If I mount from within
> Linux, and then
> > > reboot into u-boot, it will not display any files that had
> > a filename
> > > greater than 7 characters.
> > >
> > > I enabled the MTD debug verbosity at level 2 for the
> > attached example
> > > session.
> > >
> > > I am running on a custom board with a MPC5121 and Linux 2.6.33.4.
> > >
> > > Thanks in advance for any help.
> >
> >
> > Sorry for the jumbled mess. Looks like the line endings are messed
> > up.
> > Trying again. I also provided this as an attachment in
> case it gets
> > messed up again.
>
> Once again sorry for the mess.
>
> I tried this again with the DENX-v2.6.34 tag in the DENX git
> repository (git://git.denx.de/linux-2.6-denx.git). The only
> modification I made was to add my dts file. I still get the
> same issue I had before.
>
> I've attached my kernel config if that gives any clues.
>
> Are there any thoughts on what may be causing this?
>
> Thanks.
I think there may be something weird going on with the memcpy in my
build. If I use the following patch I no longer get errors when I mount
the filesystem. All I did was replace the memcpy with a loop.
I'm not sure what's special about this particular use of memcpy. I
can't believe that things would be working as well as they do if memcpy
was broken in general.
This is on a PowerPC 32 bit build for a MPC5121. I am using a GCC 4.1.2
to compile. Is anyone aware of any issues with memcpy in this
configuration?
Thanks.
---
diff --git a/fs/jffs2/scan.c b/fs/jffs2/scan.c
index 46f870d..673caa2 100644
--- a/fs/jffs2/scan.c
+++ b/fs/jffs2/scan.c
@@ -1038,7 +1038,10 @@ static int jffs2_scan_dirent_node(struct
jffs2_sb_info *c, struct jffs2_eraseblo
if (!fd) {
return -ENOMEM;
}
- memcpy(&fd->name, rd->name, checkedlen);
+ int i;
+ for(i = 0; i < checkedlen; i++)
+ ((unsigned char*)fd->name)[i] = ((const unsigned
char*)rd->name)[i];
+
fd->name[checkedlen] = 0;
crc = crc32(0, fd->name, rd->nsize);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH resend] mpc5121_nfc: Changed SVR check to allow MPC5123.
The revision in SVR for MPC5123 is 3. The NFC is the same as MPC5121
revision 2.
Signed-off-by: Steve Deiters
---
drivers/mtd/nand/mpc5121_nfc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/mpc5121_nfc.c
b/drivers/mtd/nand/mpc5121_nfc.c
index 191bf99..dc04d74 100644
--- a/drivers/mtd/nand/mpc5121_nfc.c
+++ b/drivers/mtd/nand/mpc5121_nfc.c
@@ -666,10 +666,10 @@ static int __devinit mpc5121_nfc_probe(struct
of_device *op,
/*
* Check SoC revision. This driver supports only NFC
-* in MPC5121 revision 2.
+* in MPC5121 revision 2 and MPC5123 revision 3.
*/
rev = (mfspr(SPRN_SVR) >> 4) & 0xF;
- if (rev != 2) {
+ if ((rev != 2) && (rev != 3)) {
dev_err(dev, "SoC revision %u is not supported!\n",
rev);
return -ENXIO;
}
--
1.5.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] mpc5121_nfc: Changed SVR check to allow MPC5123.
The revision in SVR for MPC5123 is 3. The NFC is the same as MPC5121
revision 2.
---
drivers/mtd/nand/mpc5121_nfc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/mpc5121_nfc.c
b/drivers/mtd/nand/mpc5121_nfc.c
index 191bf99..dc04d74 100644
--- a/drivers/mtd/nand/mpc5121_nfc.c
+++ b/drivers/mtd/nand/mpc5121_nfc.c
@@ -666,10 +666,10 @@ static int __devinit mpc5121_nfc_probe(struct
of_device *op,
/*
* Check SoC revision. This driver supports only NFC
-* in MPC5121 revision 2.
+* in MPC5121 revision 2 and MPC5123 revision 3.
*/
rev = (mfspr(SPRN_SVR) >> 4) & 0xF;
- if (rev != 2) {
+ if ((rev != 2) && (rev != 3)) {
dev_err(dev, "SoC revision %u is not supported!\n",
rev);
return -ENXIO;
}
--
1.5.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Fixes for MPC512x PSC
This will apply on the mpc512x-v2.6.33-devel branch of the DENX git
repository. This is all mostly based
on what was in the Freescale LTIB release from the Freescale website.
On a somewhat unrelated note, does anyone know if the Freescale LTIB
drivers have been merged into any newer
kernel versions? In particular, I could not find a branch that has
drivers for the newer NAND Flash controller
that was in the LTIB version.
In clock.c replaced clk_enable with mpc5121_clk_enable as clk_functions
is not yet set.
Added initialization of the FIFO address and size registers based on
device tree.
Removed port-number property from mpc5121ads device tree as the driver
doesn't use it.
Made sure PSC clocks are enabled early for console.
Made sure interrupt is requested with IRQF_SHARED as they share the
FIFO irq.
Moved initialization of CSR to mpc52xx_uart_set_termios so it is done
for the MPC512x
and also so it is done early in the console setup.
---
arch/powerpc/boot/dts/mpc5121ads.dts |3 +-
arch/powerpc/platforms/512x/clock.c |2 +-
arch/powerpc/platforms/512x/mpc5121_ads.c|1 +
arch/powerpc/platforms/512x/mpc512x.h|1 +
arch/powerpc/platforms/512x/mpc512x_shared.c | 80
++
drivers/serial/mpc52xx_uart.c|7 +-
6 files changed, 87 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc5121ads.dts
b/arch/powerpc/boot/dts/mpc5121ads.dts
index d2b2db7..bdaf534 100644
--- a/arch/powerpc/boot/dts/mpc5121ads.dts
+++ b/arch/powerpc/boot/dts/mpc5121ads.dts
@@ -325,6 +325,7 @@
interrupt-parent = < &ipic >;
};
+ // UART port numbers are enumerated in the order they
occur
// 512x PSCs are not 52xx PSC compatible
// PSC3 serial port A aka ttyPSC0
ser...@11300 {
@@ -332,7 +333,6 @@
compatible = "fsl,mpc5121-psc-uart",
"fsl,mpc5121-psc";
// Logical port assignment needed until driver
// learns to use aliases
- port-number = <0>;
cell-index = <3>;
reg = <0x11300 0x100>;
interrupts = <40 0x8>;
@@ -347,7 +347,6 @@
compatible = "fsl,mpc5121-psc-uart",
"fsl,mpc5121-psc";
// Logical port assignment needed until driver
// learns to use aliases
- port-number = <1>;
cell-index = <4>;
reg = <0x11400 0x100>;
interrupts = <40 0x8>;
diff --git a/arch/powerpc/platforms/512x/clock.c
b/arch/powerpc/platforms/512x/clock.c
index 8733143..d32c83f 100644
--- a/arch/powerpc/platforms/512x/clock.c
+++ b/arch/powerpc/platforms/512x/clock.c
@@ -681,7 +681,7 @@ static void psc_clks_init(void)
psc_calc_rate(clk, pscnum, np);
sprintf(clk->name, "psc%d_mclk", pscnum);
clk_register(clk);
- clk_enable(clk);
+ mpc5121_clk_enable(clk);
}
}
}
diff --git a/arch/powerpc/platforms/512x/mpc5121_ads.c
b/arch/powerpc/platforms/512x/mpc5121_ads.c
index aa4d5a8..44a0a51 100644
--- a/arch/powerpc/platforms/512x/mpc5121_ads.c
+++ b/arch/powerpc/platforms/512x/mpc5121_ads.c
@@ -64,6 +64,7 @@ static int __init mpc5121_ads_probe(void)
void __init mpc5121_ads_init_early(void)
{
mpc512x_init_diu();
+ mpc5121_psc_early_init();
}
define_machine(mpc5121_ads) {
diff --git a/arch/powerpc/platforms/512x/mpc512x.h
b/arch/powerpc/platforms/512x/mpc512x.h
index 1cfe9d5..fb69e3f 100644
--- a/arch/powerpc/platforms/512x/mpc512x.h
+++ b/arch/powerpc/platforms/512x/mpc512x.h
@@ -21,3 +21,4 @@ extern void __init mpc512x_init_diu(void);
extern void __init mpc512x_setup_diu(void);
extern struct fsl_diu_shared_fb diu_shared_fb;
#endif /* __MPC512X_H__ */
+extern void __init mpc5121_psc_early_init(void);
diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c
b/arch/powerpc/platforms/512x/mpc512x_shared.c
index 65b0a5d..1d74046 100644
--- a/arch/powerpc/platforms/512x/mpc512x_shared.c
+++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
@@ -61,6 +61,86 @@ void mpc512x_restart(char *cmd)
;
}
+#define DEFAULT_FIFO_SIZE 16
+
+static unsigned int get_fifo_size(struct device_node *np, int psc_num,
char *fifo_name)
+{
+ const unsigned int *fp;
+
+ fp = of_get_property(np, fifo_name, NULL);
+ if (fp) {
+ /* make sure has at least 1 byte */
+ return *fp ? *fp : 1;
+ }
+
+ printk(KERN_WARNING "no %s property for psc%d defaulting to
%d\n",
+ fifo_name, psc_num, DEFAULT_FIFO_SIZE);
+ return DEFAULT_FIFO_SIZE;
+}
+
+static void __init mpc5121_psc_lowlevel_clock_init(void)
+{
Git repository for MPC5121?
What is the recommended git repository for active MPC5121 development? I pulled the tag "DENX-v2.6.33.1" from git.denx.de, and, unless I'm overlooking something, it seems to be lacking some driver support such as NAND, RTC, etc. I also notice an older head called "mpc512x-v2.6.33-devel". Should I be pulling from this one instead? I'm playing a mix and match game now trying to upgrade from an old 2.6.24 Freescale version which seems pretty much the same as the "ads5121" head. Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
