[ECOS] sdram scrubbing and MMU enabling.

[ECOS] sdram scrubbing and MMU enabling.

[Mynampati, Venkata S.]

Hi 
in hal_platform_setup.h ( iq80310/include), i noticed that we are
enabling MMU and then scrubbing sdram starting from RAM_BASE i.e A0000000.
Now, my doubt is:
since we have mapped the first 4K of RAM to flash,
	[ mmu_table_rambase:
	        // Map 4k page at 0xa0000000 virt --> 0x00000000 physical
	        //   Read-Write, cacheable, non-bufferable ]
does that mean writing a 0x00 to a0000000 is same as writing to flash?
Am i missing something here?

Venkat

Worry about chances you miss when you don't even try.
  

Re: [ECOS] sdram scrubbing and MMU enabling.

[Mark Salter]

>>>>> Mynampati, Venkata S writes:

> Hi 
> in hal_platform_setup.h ( iq80310/include), i noticed that we are
> enabling MMU and then scrubbing sdram starting from RAM_BASE i.e A0000000.
> Now, my doubt is:
> since we have mapped the first 4K of RAM to flash,
> 	[ mmu_table_rambase:
> 	        // Map 4k page at 0xa0000000 virt --> 0x00000000 physical
> 	        //   Read-Write, cacheable, non-bufferable ]
> does that mean writing a 0x00 to a0000000 is same as writing to flash?
> Am i missing something here?

No, its a problem. It came up this week on the ARM linux kernel mailing list.
I'm working on a fix.

--Mark
  

RE: [ECOS] sdram scrubbing and MMU enabling.

[Mynampati, Venkata S.]

> >>>>> Mynampati, Venkata S writes:
> 
> > Hi 
> > in hal_platform_setup.h ( iq80310/include), i noticed that we are
> > enabling MMU and then scrubbing sdram starting from 
> RAM_BASE i.e A0000000.
> > Now, my doubt is:
> > since we have mapped the first 4K of RAM to flash,
> > 	[ mmu_table_rambase:
> > 	        // Map 4k page at 0xa0000000 virt --> 
> 0x00000000 physical
> > 	        //   Read-Write, cacheable, non-bufferable ]
> > does that mean writing a 0x00 to a0000000 is same as 
> writing to flash?
> > Am i missing something here?
> 
> No, its a problem. It came up this week on the ARM linux 
> kernel mailing list.
> I'm working on a fix.
> 
> --Mark
>   
what i am doing is scrubbing and then enabling mmu.

venkat

Re: [ECOS] sdram scrubbing and MMU enabling.

[Mark Salter]

>>>>> Mynampati, Venkata S writes:

>> >>>>> Mynampati, Venkata S writes:
>> 
>> > Hi 
>> > in hal_platform_setup.h ( iq80310/include), i noticed that we are
>> > enabling MMU and then scrubbing sdram starting from 
>> RAM_BASE i.e A0000000.
>> > Now, my doubt is:
>> > since we have mapped the first 4K of RAM to flash,
>> > 	[ mmu_table_rambase:
>> > 	        // Map 4k page at 0xa0000000 virt --> 
>> 0x00000000 physical
>> > 	        //   Read-Write, cacheable, non-bufferable ]
>> > does that mean writing a 0x00 to a0000000 is same as 
>> writing to flash?
>> > Am i missing something here?
>> 
>> No, its a problem. It came up this week on the ARM linux 
>> kernel mailing list.
>> I'm working on a fix.
>> 
>> --Mark
>> 
> what i am doing is scrubbing and then enabling mmu.

I was told by the hw designer that that would not work. Scrubbing
needs to occur with the dcache/ECC turned on which means the MMU
must be on.

There is also a related problem where the first 1MB of SDRAM does
not have ECC turned on. Since the board is populated with ECC RAM,
its likely that single bit errors will occur and go undetected.

--Mark

RE: [ECOS] sdram scrubbing and MMU enabling.

[Mynampati, Venkata S.]

are
> >> > enabling MMU and then scrubbing sdram starting from 
> >> RAM_BASE i.e A0000000.
> >> > Now, my doubt is:
> >> > since we have mapped the first 4K of RAM to flash,
> >> > 	[ mmu_table_rambase:
> >> > 	        // Map 4k page at 0xa0000000 virt --> 
> >> 0x00000000 physical
> >> > 	        //   Read-Write, cacheable, non-bufferable ]
> >> > does that mean writing a 0x00 to a0000000 is same as 
> >> writing to flash?
> >> > Am i missing something here?
> >> 
> >> No, its a problem. It came up this week on the ARM linux 
> >> kernel mailing list.
> >> I'm working on a fix.
> >> 
> >> --Mark
> >> 
> > what i am doing is scrubbing and then enabling mmu.
> 
> I was told by the hw designer that that would not work. Scrubbing
> needs to occur with the dcache/ECC turned on which means the MMU
> must be on.
> 
> There is also a related problem where the first 1MB of SDRAM does
> not have ECC turned on. Since the board is populated with ECC RAM,
> its likely that single bit errors will occur and go undetected.
> 
> --Mark

  I am going thru 80312's documentation page 3-31, section
  3.2.4.4 and it's related to Scrubbing. This doesn't say anything
  about cache's. Is it in someother section? also, where can i find
  info about first 1MB of sdram stuff?
  
Venkat

Re: [ECOS] sdram scrubbing and MMU enabling.

[Mark Salter]

>>>>> Mynampati, Venkata S writes:

>   I am going thru 80312's documentation page 3-31, section
>   3.2.4.4 and it's related to Scrubbing. This doesn't say anything
>   about cache's. Is it in someother section?

I didn't read it in the manual. I was told verbally. The section you
point to involves scrubbing a specific location as part of the ECC
exception handler, not the initial scrub upon power up. The only way
you'll get an ECC exception is to turn on the MMU because ECC is
enabled only when the first level PTE has the P bit set.

> also, where can i find
>   info about first 1MB of sdram stuff?

In hal_platform_setup.h where the P bit is not turned on in the
first level page table entry for the first MB or RAM.

--Mark

Re: [ECOS] sdram scrubbing and MMU enabling.

[Mark Salter]

>>>>> Mynampati, Venkata S writes:

> are
>> >> > enabling MMU and then scrubbing sdram starting from 
>> >> RAM_BASE i.e A0000000.
>> >> > Now, my doubt is:
>> >> > since we have mapped the first 4K of RAM to flash,
>> >> > 	[ mmu_table_rambase:
>> >> > 	        // Map 4k page at 0xa0000000 virt --> 
>> >> 0x00000000 physical
>> >> > 	        //   Read-Write, cacheable, non-bufferable ]
>> >> > does that mean writing a 0x00 to a0000000 is same as 
>> >> writing to flash?
>> >> > Am i missing something here?
>> >> 
>> >> No, its a problem. It came up this week on the ARM linux 
>> >> kernel mailing list.
>> >> I'm working on a fix.
>> >> 
>> >> --Mark
>> >> 
>> > what i am doing is scrubbing and then enabling mmu.
>> 
>> I was told by the hw designer that that would not work. Scrubbing
>> needs to occur with the dcache/ECC turned on which means the MMU
>> must be on.
>> 
>> There is also a related problem where the first 1MB of SDRAM does
>> not have ECC turned on. Since the board is populated with ECC RAM,
>> its likely that single bit errors will occur and go undetected.
>> 
>> --Mark

>   I am going thru 80312's documentation page 3-31, section
>   3.2.4.4 and it's related to Scrubbing. This doesn't say anything
>   about cache's. Is it in someother section? also, where can i find
>   info about first 1MB of sdram stuff?
  
> Venkat

Here is a patch that turns on ECC for the first MB of SDRAM and
fixes the boot time scrubbing.

--Mark


Index: devs/flash/arm/iq80310/current/ChangeLog
===================================================================
RCS file: /home/cvs/ecc/ecc/devs/flash/arm/iq80310/current/ChangeLog,v
retrieving revision 1.7
diff -u -p -5 -r1.7 ChangeLog
--- devs/flash/arm/iq80310/current/ChangeLog	2001/06/11 13:06:02	1.7
+++ devs/flash/arm/iq80310/current/ChangeLog	2001/08/04 13:46:44
@@ -1,5 +1,9 @@
+2001-08-04  Mark Salter  <msalter@redhat.com>
+
+	* src/flash.h (FLASH_P2V): First 4K of flash now mapped at 0xd0000000.
+
 2001-06-11  Gary Thomas  <gthomas@redhat.com>
 
 	* src/iq80310_flash.c: Remove dependency on printf() via user functions.
 
 2001-05-23  Jesper Skov  <jskov@redhat.com>
Index: devs/flash/arm/iq80310/current/src/flash.h
===================================================================
RCS file: /home/cvs/ecc/ecc/devs/flash/arm/iq80310/current/src/flash.h,v
retrieving revision 1.1
diff -u -p -5 -r1.1 flash.h
--- devs/flash/arm/iq80310/current/src/flash.h	2000/10/27 04:45:40	1.1
+++ devs/flash/arm/iq80310/current/src/flash.h	2001/08/04 13:46:44
@@ -45,11 +45,11 @@
 #define _FLASH_HWR_H_
 
 // First 4K page of flash at physical address zero is
 // virtually mapped at address 0xa0000000.
 #define FLASH_P2V(x) ((volatile unsigned char *)(((unsigned)(x) < 0x1000) ?  \
-                           ((unsigned)(x) | 0xa0000000) :  \
+                           ((unsigned)(x) | 0xd0000000) :  \
                            (unsigned)(x)))
 
 #define FLASH_BOOT_BLOCK_SIZE   0x4000
 
 #define FLASH_Intel_code   0x89
Index: hal/arm/iq80310/current/ChangeLog
===================================================================
RCS file: /home/cvs/ecc/ecc/hal/arm/iq80310/current/ChangeLog,v
retrieving revision 1.38
diff -u -p -5 -r1.38 ChangeLog
--- hal/arm/iq80310/current/ChangeLog	2001/06/21 05:03:42	1.38
+++ hal/arm/iq80310/current/ChangeLog	2001/08/04 13:46:45
@@ -1,5 +1,10 @@
+2001-08-04  Mark Salter  <msalter@redhat.com>
+
+	* include/hal_platform_setup.h: Fix mapping so first MB of SDRAM has
+	ECC turned on. Now map first 4K of flash at 0xd0000000.
+
 2001-06-21  Jonathan Larmour  <jlarmour@redhat.com>
 
 	* images/*: Remove. Don't bloat repository with things already on
 	the web.
 
Index: hal/arm/iq80310/current/include/hal_platform_setup.h
===================================================================
RCS file: /home/cvs/ecc/ecc/hal/arm/iq80310/current/include/hal_platform_setup.h,v
retrieving revision 1.9
diff -u -p -5 -r1.9 hal_platform_setup.h
--- hal/arm/iq80310/current/include/hal_platform_setup.h	2001/04/30 14:10:15	1.9
+++ hal/arm/iq80310/current/include/hal_platform_setup.h	2001/08/04 13:46:56
@@ -133,15 +133,15 @@
 	.word (\base << 20) | (\x << 12) | (\ap << 10) | (\p << 9) |\
 	      (\d << 5) | (\c << 3) | (\b << 2) | 2
 	.endm
 
 	// form a first-level page table entry
-	.macro FL_PT_ENTRY base,d
+	.macro FL_PT_ENTRY base,p,d
 	// I wanted to use logical operations here, but since I am using symbols later 
 	// to fill in the parameters, I had to use addition to force the assembler to
 	// do it right
-	.word \base + (\d << 5) + 1
+	.word \base + (\p << 9) + (\d << 5) + 1
 	.endm
 
 	// form a second level small page entry
 	.macro SL_SMPAGE_ENTRY base,ap3,ap2,ap1,ap0,c,b
 	.word (\base << 12) | (\ap3 << 10) | (\ap2 << 8) | (\ap1 << 6) |\
@@ -168,11 +168,11 @@
 	// the following alignment creates the mmu table at address 0x4000.
     mmu_table:
 
 	// 1MB of FLASH with i80312 MMRs mapped in using 4K small pages so we can
 	// set the access permission on flash and memory-mapped registers properly.
-	FL_PT_ENTRY mmu_table_flashbase,0
+	FL_PT_ENTRY mmu_table_flashbase,0,0
 
 	// Remaining 7MB of FLASH
 	//   rw, cacheable, non-bufferable
 	.set	__base,1
 	.rept	7
@@ -184,17 +184,15 @@
 	.rept	0xA00 - 0x8
 	FL_SECTION_ENTRY __base,0,3,0,0,0,0
 	.set	__base,__base+1
 	.endr
 
-	// up to 512MB ECC SDRAM
+	// up to 512MB ECC SDRAM mapped 1-to-1
+	// first 1MB mapped in 4K chunks
 	//   x=c=b=1
-	// first 1MB mapped by second level table
-	FL_PT_ENTRY mmu_table_rambase,0
+	FL_PT_ENTRY mmu_table_rambase,1,0
 	.set	__base,__base+1
-	
-	// remainder of SDRAM mapped 1-to-1
 	.rept	0xC00 - 0xA01
 	FL_SECTION_ENTRY __base,1,3,1,0,1,1
 	.set	__base,__base+1
 	.endr
 
@@ -203,12 +201,17 @@
 	.rept	0xD00 - 0xC00
 	FL_SECTION_ENTRY __base,0,3,0,0,1,1
 	.set	__base,__base+1
 	.endr
 	
+	// Alias for first 1MB of FLASH
+	//  rw, cacheable, non-bufferable
+	FL_SECTION_ENTRY 0x000,0,3,0,0,1,0
+	.set	__base,__base+1
+
 	// Invalid
-	.rept	0xF00 - 0xD00
+	.rept	0xF00 - 0xD01
 	.word 0
 	.set	__base,__base+1
 	.endr
 
 	// only I/O at 0xFE8xxxxx
@@ -244,19 +247,14 @@
 	.endr
 
 	// Now is the second level table for the first megabyte
 	// of DRAM.
     mmu_table_rambase:
-	// Map 4k page at 0xa0000000 virt --> 0x00000000 physical
-	//   Read-Write, cacheable, non-bufferable
-	SL_SMPAGE_ENTRY 0x00000,3,3,3,3,1,0
-	.set	__base,__base+1		   
-
-	// Map remainder of first meg of SDRAM
+	// Map first meg of SDRAM
 	//   Read-Write, cacheable, bufferable
-	.set    __base,0xA0001
-	.rept	0x100 - 0x1
+	.set    __base,0xA0000
+	.rept	0x100
 	SL_XSMPAGE_ENTRY __base,1,3,1,1
 	.set	__base,__base+1
 	.endr
 
 _real_platform_setup:
@@ -725,12 +723,24 @@ SDRAM_DRIVE_2_BANK_X8:
     10: // fastScrubLoop
 	subs	r12, r12, #32	// 32 bytes/line
 	stmia	r11!, {r0-r7}
 	beq	15f
 	b	10b
-    15:	
+    15:
 	
+	// now copy 1st 4K page of flash into first 4K of RAM.
+	ldr	r1, =RAM_BASE	// base address of SDRAM
+	mov     r2, #0xd0000000 // alias for first 1M of flash
+	mov     r3, #0x1000
+    16:
+	ldr     r4, [r2]
+	add	r2, r2, #4
+	str	r4, [r1]
+	add	r1, r1, #4
+	subs    r3, r3, #4
+	bne     16b
+
 	// Battery Backup SDRAM Memory Test
 	// Store 4 byte Test Pattern back into memory
 	str r10, [r9, #0x0]
 
 	HEX_DISPLAY r0, r1, DISPLAY_1, DISPLAY_0