Re: [PATCH] MTD: OMAP2-NAND: Fix partition reading from board info
* Kamat, Nishant [EMAIL PROTECTED] [080703 14:55]: Hi, Kyungmin Park on July 02, 2008 4:57 AM, wrote: Hi, It's should be sent to MTD list. and we also fix the NOR similar ways. It's already posted but not committed. Posting the patch on MTD list. Please merge. Looks like this driver does not exist outside linux-omap tree, care to send the whole driver to MTD list? Pushing this fix to linux-omap tree meanwhile. Tony --- Cut here --- From: Nishant Kamat [EMAIL PROTECTED] This patch fixes the omap2 nand driver code that allows reading of partition data from board info. The parse_mtd_partitions() function no longer returns a negative error in case cmdline is not passed. See commit: b0d06afb607 Signed-off-by: Nishant Kamat [EMAIL PROTECTED] --- drivers/mtd/nand/omap2.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Index: linux-omap-ti.ldp/drivers/mtd/nand/omap2.c === --- linux-omap-ti.ldp.orig/drivers/mtd/nand/omap2.c 2008-06-30 22:01:50.0 +0530 +++ linux-omap-ti.ldp/drivers/mtd/nand/omap2.c 2008-06-30 22:03:34.446471469 +0530 @@ -699,7 +699,7 @@ err = parse_mtd_partitions(info-mtd, part_probes, info-parts, 0); if (err 0) add_mtd_partitions(info-mtd, info-parts, err); - else if (err 0 pdata-parts) + else if (pdata-parts) add_mtd_partitions(info-mtd, pdata-parts, pdata-nr_parts); else #endif -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MTD: OMAP2-NAND: Fix partition reading from board info
On Monday 04 August 2008, Tony Lindgren wrote: Looks like this driver does not exist outside linux-omap tree, care to send the whole driver to MTD list? Unless someone created a big-endian OMAP, the cpu_to_le16() calls in the read/write buffer calls can be removed ... and then the read buffer code can use __raw_readsw(...) to get what's been a significant speedup on some other ARMs. (The atmel_nand.c code should be usable as-is.) If there are big-endian OMAPs, it's still unclear why that would be needed (maybe the hardware ECC code would need to become byteorder-aware?) ... little point in byteswapping on the i/o paths, except maybe to slow things down. It'd make sense to merge the driver version which handles both OMAP2 and OMAP3, too. With beagleboard.org pushing out those puppies, the omap3 support matters more. :) - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MTD: OMAP2-NAND: Fix partition reading from board info
On Monday 04 August 2008, Lennert Buytenhek wrote: On Mon, Aug 04, 2008 at 01:02:46PM -0700, David Brownell wrote: Looks like this driver does not exist outside linux-omap tree, care to send the whole driver to MTD list? Unless someone created a big-endian OMAP, Don't they use standard ARM ARM cores, which can all be used in both LE and BE modes? And when those cores turn into silicon, the choice is usually hard-wired. Regardless, all OMAP cores I've worked with are set up for LE mode ... and then there's still the point that byteswapping to/from the NAND chip seems to add no value. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MTD: OMAP2-NAND: Fix partition reading from board info
On Mon, Aug 04, 2008 at 01:02:46PM -0700, David Brownell wrote: Looks like this driver does not exist outside linux-omap tree, care to send the whole driver to MTD list? Unless someone created a big-endian OMAP, Don't they use standard ARM ARM cores, which can all be used in both LE and BE modes? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MTD: OMAP2-NAND: Fix partition reading from board info
On Mon, Aug 04, 2008 at 01:26:38PM -0700, David Brownell wrote: Looks like this driver does not exist outside linux-omap tree, care to send the whole driver to MTD list? Unless someone created a big-endian OMAP, Don't they use standard ARM ARM cores, which can all be used in both LE and BE modes? And when those cores turn into silicon, the choice is usually hard-wired. I've never seen CPU endianity being hardwired in any ARM system ever -- but maybe OMAP is different. (Out of all the ARM subarchs supported in the kernel right now, I've had ep93xx'es, iop13xx'es, iop32x'es, iop33x'es, ixp2000s, ixp23xx'es, ixp4xx'es, kirkwoods, mv78xx0's, and orion5x'es all running in BE mode at some point.) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MTD: OMAP2-NAND: Fix partition reading from board info
On Mon, Aug 04, 2008 at 04:23:35PM -0500, Woodruff, Richard wrote: The most visible BE-ARM seems to be Intel's IXP network processors. The IXPs are one of the few cases where the vendors _ships an all-BE software development environment by default_ -- but that doesn't mean that BE doesn't work on ARM CPUs where the vendor ships a LE software development environment by default (BE has certainly worked on all ARM CPUs I've ever tried it on). -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MTD: OMAP2-NAND: Fix partition reading from board info
On Monday 04 August 2008, Lennert Buytenhek wrote: I've never seen CPU endianity being hardwired in any ARM system ever -- but maybe OMAP is different. I'll let TI answer that one, since I'm not going to look at docs for all the ARM's I've ever used. My observation stands *REGARDLESS* of whether endianness was fixed in hardware, bootloader, or kernel ... and in any case, with very few exceptions (not including OMAP), Linux uses ARMs in LE mode: ~/kernel/linux-2.6/arch/arm/configs$ grep ENDIAN * | egrep -v '#' |egrep -v OHCI ixp2000_defconfig:CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y ixp2000_defconfig:CONFIG_CPU_BIG_ENDIAN=y ixp23xx_defconfig:CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y ixp23xx_defconfig:CONFIG_CPU_BIG_ENDIAN=y ixp4xx_defconfig:CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y ixp4xx_defconfig:CONFIG_CPU_BIG_ENDIAN=y ~/kernel/linux-2.6/arch/arm/configs$ ls | wc -l 105 ~/kernel/linux-2.6/arch/arm/configs$ To repeat: there's no point in having the words byteswapped when writing, then again when reading, like this driver does. All that does is ensure slow I/O paths. Were you disagreeing with that main point? Or just quibbling about where any unusual big-endianness might come from? - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MTD: OMAP2-NAND: Fix partition reading from board info
On Mon, Aug 04, 2008 at 02:37:34PM -0700, David Brownell wrote: I've never seen CPU endianity being hardwired in any ARM system ever -- but maybe OMAP is different. I'll let TI answer that one, since I'm not going to look at docs for all the ARM's I've ever used. My observation stands *REGARDLESS* of whether endianness was fixed in hardware, bootloader, or kernel ... and in any case, with very few exceptions (not including OMAP), Linux uses ARMs in LE mode: ~/kernel/linux-2.6/arch/arm/configs$ grep ENDIAN * | egrep -v '#' |egrep -v OHCI ixp2000_defconfig:CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y ixp2000_defconfig:CONFIG_CPU_BIG_ENDIAN=y ixp23xx_defconfig:CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y ixp23xx_defconfig:CONFIG_CPU_BIG_ENDIAN=y ixp4xx_defconfig:CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y ixp4xx_defconfig:CONFIG_CPU_BIG_ENDIAN=y ~/kernel/linux-2.6/arch/arm/configs$ ls | wc -l 105 ~/kernel/linux-2.6/arch/arm/configs$ That's just because not many people ask for BE or use BE -- not because the LE'ness would be hardwired in hardware as you asserted earlier. To repeat: there's no point in having the words byteswapped when writing, then again when reading, like this driver does. All that does is ensure slow I/O paths. Were you disagreeing with that main point? Or just quibbling about where any unusual big-endianness might come from? I was responding to your statement that ARM CPU endianity is hardwired when ARM cores are turned into silicon. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] MTD: OMAP2-NAND: Fix partition reading from board info
The most visible BE-ARM seems to be Intel's IXP network processors. The IXPs are one of the few cases where the vendors _ships an all-BE software development environment by default_ -- but that doesn't mean that BE doesn't work on ARM CPUs where the vendor ships a LE software development environment by default (BE has certainly worked on all ARM CPUs I've ever tried it on). I wonder how many shipping systems use LE. A grep of current ARM Linux Kconfig's only shows 3 IXP systems setting CONFIG_CPU_BIG_ENDIAN. Perhaps you are correct about ability but few seem to use it. Seems like a trivia question for ARM Ltd. At any rate all OMAPs have been hardwired. Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MTD: OMAP2-NAND: Fix partition reading from board info
On Mon, Aug 04, 2008 at 04:45:19PM -0500, Woodruff, Richard wrote: The most visible BE-ARM seems to be Intel's IXP network processors. The IXPs are one of the few cases where the vendors _ships an all-BE software development environment by default_ -- but that doesn't mean that BE doesn't work on ARM CPUs where the vendor ships a LE software development environment by default (BE has certainly worked on all ARM CPUs I've ever tried it on). I wonder how many shipping systems use LE. A grep of current ARM Linux Kconfig's only shows 3 IXP systems setting CONFIG_CPU_BIG_ENDIAN. Perhaps you are correct about ability but few seem to use it. Seems like a trivia question for ARM Ltd. At any rate all OMAPs have been hardwired. Hmmm. So bit [7] of the system control register is ignored entirely, and if you write a 1 to it, nothing at all happens and the system boots as usual? (To test, add a line OBJS += big-endian.o to the top of arch/arm/boot/compressed/Makefile.) Does it also mean that the ARMv6 based OMAPs have the SETEND instruction behave as NOPs? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] MTD: OMAP2-NAND: Fix partition reading from board info
Hmmm. So bit [7] of the system control register is ignored entirely, and if you write a 1 to it, nothing at all happens and the system boots as usual? (To test, add a line OBJS += big-endian.o to the top of arch/arm/boot/compressed/Makefile.) Does it also mean that the ARMv6 based OMAPs have the SETEND instruction behave as NOPs? Last time I explicitly tried was back on OMAP1. I then dug into doc's it was said that the bit was hardwired at the integration point. I don't recall signal name. Now, Peeking into OMAP2 (armv6) MPU integration docs I see that BIGENDINIT is pulled low. This forces the behavior as I indicated. OMAP3 (armv7) does something similar at cpu-to-bus bridge. Doing a quick desktop search in documents I see the armv6 behavior is defined as part of BIGENDINIT in ARM TRMs. I'll guess SETEND instruction follows what ever that dictates. I don't know as I've never tried. Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MTD: OMAP2-NAND: Fix partition reading from board info
Hi, It's should be sent to MTD list. and we also fix the NOR similar ways. It's already posted but not committed. Thank you, Kyungmin Park On Tue, Jul 1, 2008 at 11:32 PM, Kamat, Nishant [EMAIL PROTECTED] wrote: From: Nishant Kamat [EMAIL PROTECTED] MTD: OMAP2-NAND: Fix partition reading from board info The parse_mtd_partitions() function no longer returns a negative error in case cmdline is not passed. See commit: b0d06afb607 Signed-off-by: Nishant Kamat [EMAIL PROTECTED] --- drivers/mtd/nand/omap2.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Index: linux-omap-ti.ldp/drivers/mtd/nand/omap2.c === --- linux-omap-ti.ldp.orig/drivers/mtd/nand/omap2.c 2008-06-30 22:01:50.0 +0530 +++ linux-omap-ti.ldp/drivers/mtd/nand/omap2.c 2008-06-30 22:03:34.446471469 +0530 @@ -699,7 +699,7 @@ err = parse_mtd_partitions(info-mtd, part_probes, info-parts, 0); if (err 0) add_mtd_partitions(info-mtd, info-parts, err); - else if (err 0 pdata-parts) + else if (pdata-parts) add_mtd_partitions(info-mtd, pdata-parts, pdata-nr_parts); else #endif -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
