HISTORICAL, FIXED:: SDRAM problem

[Harald Welte]

======================================================================
THIS IS OLD, outdated and fixed, problem doesn't exist anymore.
just for your reference about what was going on and how it was resolved!
======================================================================

Hi!

As it seems, most of our 'system instability' bugs actually come from a
SDRAM memory problem.  Particularly the "system oopses during lots of
I/O" issues are related to memory.

Why do I think so:

0) When using the system with regular 128MB, we get random kernel
   oopses, see also
   http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=245

1) When using 'memtester' on a regular system, using size > 64MB results
   in an immediate kernel oops.

2) When booting the system with mem=64M (using only lower half SDRAM)
   everything works fine.  Not only are the kernel oopses gone, but also
   'memtester' (a linux memory testing program) runs without any
   problems

3) When I use JTAG to halt the system, and I look at physical address
   0x30000000 and compare it with 0x34000000, they show the same
   contents.  If I write a magic value to 0x30000000, it automatically
   appears at 0x34000000, too.  This means, there is some mirroring
   happening.

I have verified the configration of BANKCON/BANKSIZE configuration
registers, and it seems correct.

Our memory organization is:

	2 chips, 4 banks of 16 bits x 8M
equals	1 chips, 4 banks of 32 bits x 8M

This results in a bank size of 32MB (0x200000).  The memory is mapped at
0x30000000 of the CPU, whihc provides the following memory-map:

0x30000000 bank0
0x32000000 bank1
0x34000000 bank2
0x36000000 bank3
0x37ffffff last byte of RAM

The selection of SDRAM banks with ADD25/ADD26 lines therfore seems
absolutely correct.

The BK76MAP field of BANKSIZE (Page 5-18 of S3c2410 documentation) is
set to '010', i.e. 128MB size for BANK6 of the SoC.

Therefore, everything seems right, both on the schematics, and from the
memory controller configuration point of view.

Now what I could imagine, is that ADD26 is somehow not switched.

And at that point I realized that ADD26 is one of the address lines
which are not dedicated address lines, but dual function (GPIO or
address).  And our low-level GPIO initialization code was switching it
jsut the wrong way around...

-- 
- Harald Welte <laforge at openmoko.org>          	        http://openmoko.org/
============================================================================
Software for the world's first truly open Free Software mobile phone