Problem on mounting a jffs2 rootfs image

DISCUSSION Tony Lindgren 2 participants 3 messages Jan 2, 2006 4 messages not in the archive

Subsystems (3)

Arm (32-bit) Arm sub-architectures OMAP1 support

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Tony Lindgren

author reviewer

2006-01-02 18:31 UTC #4 lore raw

Quoted 38 lines · Dirk Behme

Quoted 8 lines · Tony Lindgren
Quoted 5 lines
Do you checked the thread "JFFS2 problem on OSK"
http://linux.omap.com/pipermail/linux-omap-open-source/2005-July/004717.html
?
I wonder if there's any way to test for the OSK version? Then we could check the timings.
Are there any OSKs out there which need different *CS3* timings? If not, we only have to check for correct timings, something like:
--- ./arch/arm/mach-omap/omap1/board-osk.c_orig 2005-11-11 20:22:40.628440008 +0100
+++ ./arch/arm/mach-omap/omap1/board-osk.c 2005-11-11
20:31:51.056762184 +0100
(quoted diff) +10 -0
@@ -192,8 +192,18 @@ static struct omap_board_config_kernel o
        { OMAP_TAG_USB,           &osk_usb_config },
 };
 
+#define EMFIS_CS3_VAL (0x30003361)
+
 static void __init osk_init(void)
 {
+        /* Workaround for wrong CS3 (NOR flash) timing
+         * There are some U-Boot versions out there which configure
+         * wrong CS3 memory timings. This mainly leads to CRC
+         * or similiar errors if you use NOR flash (e.g. with JFFS2)
+         */
+        if(omap_readl(EMIFS_CS3_CONFIG) != EMFIS_CS3_VAL)
+               omap_writel(EMFIS_CS3_VAL, EMIFS_CS3_CONFIG);
+
        osk_flash_resource.end = osk_flash_resource.start = 
 omap_cs3_phys();
        osk_flash_resource.end += SZ_32M - 1;
        platform_add_devices(osk5912_devices, ARRAY_SIZE(osk5912_devices));

Quoted 3 lines

0x30003361 is the value used by spectrum digital. Seems to work. But I don't think it's the fastest possible timing. Anybody with a better CS3 timing?

I think we should push this to avoid postings on JFFS2 problems. How about changing the patch to use the EMIFS_CCS macro instead?

Regards,

Tony

Dirk Behme

2006-01-02 20:35 UTC #5 lore raw

Quoted 5 lines · Tony Lindgren

Quoted 1 line
0x30003361 is the value used by spectrum digital. Seems to work. But I don't think it's the fastest possible timing. Anybody with a better CS3 timing?
I think we should push this to avoid postings on JFFS2 problems. How about changing the patch to use the EMIFS_CCS macro instead?

Something like this?

Nobody with a better timing?

Dirk

arch/arm/mach-omap1/board-osk.c renamed from arch/arm/mach-omap1/board-osk.c_orig +10 -0

@@ -254,8 +254,18 @@ static void __init osk_mistral_init(void
 static void __init osk_mistral_init(void) { }
 #endif
 
+#define EMFIS_CS3_VAL (0x30003361)
+
 static void __init osk_init(void)
 {
+        /* Workaround for wrong CS3 (NOR flash) timing
+         * There are some U-Boot versions out there which configure
+         * wrong CS3 memory timings. This mainly leads to CRC
+         * or similiar errors if you use NOR flash (e.g. with JFFS2)
+         */
+	if(omap_readl(EMIFS_CCS(3)) != EMFIS_CS3_VAL)
+               omap_writel(EMFIS_CS3_VAL, EMIFS_CCS(3));
+ 
 	osk_flash_resource.end = osk_flash_resource.start = omap_cs3_phys();
 	osk_flash_resource.end += SZ_32M - 1;
 	platform_add_devices(osk5912_devices, ARRAY_SIZE(osk5912_devices));

Tony Lindgren

author reviewer

2006-01-02 22:10 UTC #6 lore raw

Quoted 10 lines · Dirk Behme

Quoted 7 lines · Tony Lindgren
Quoted 3 lines
0x30003361 is the value used by spectrum digital. Seems to work. But I don't think it's the fastest possible timing. Anybody with a better CS3 timing?
I think we should push this to avoid postings on JFFS2 problems. How about changing the patch to use the EMIFS_CCS macro instead?
Something like this?

This should do it:

if (EMIFS_CCS(3) != EMIFS_CS3_VAL)

	EMIFS_CCS(3) = EMIFS_CS3_VAL;

It's a REG32 define.

Quoted 1 line

Nobody with a better timing?

I guess not.

Tony