I'm having a problem getting FAST_nCS to work. According to the hardware specification, FAST_nCS is active when nCS4 is active, and address 23 is high, and the schematic logic confirms this behaviour. Even with the simplest possible code (below), running stand-alone under LoLo, FAST_nCS stays high. (The same thing happens under Linux.) Tracing the signals with a 'scope shows that nCS4 is going low when it should, but A23 never goes high. This gates off FAST_nCS and U31 pin 3 is always high. I've checked this on two different modules, and three different base-boards. I'm 'scoping directly on the module, at U31. By the way, nCS4 also controls the ethernet chip, (when A23 is low) and this works perfectly.
I've tried remapping the address using LoLo's remap command, but to no effect. Also, I'm aware of PCN374, but this problem is more fundamental.
I must be doing something silly, but can't spot it. Has anyone else got this working, or can you see the error? Any ideas would be welcome!
#define FAST_nCS 0xb4800000
volatile long *addr;
addr = (long *)FAST_nCS;
for(;;) *addr = 0;
24th July 2008
Solved it! There is a note on the schematic for the LogicPD iMX31 module (sheet 02) which says:
NOTE: ADDRESS TEXT LABELS IN BLACK ARE
WIRED FOR SUPPORTING AN EXTERNAL 16 BIT
INTERFACE. THE CPU AUTOMATICALLY
SHIFTS THE LEAST SIGNIFICANT ADDRESS BIT
TO SIGNAL uP_MA0.
What it doesn't say is that this shift does not apply to the internal chip select decoder logic. So
although nCS4 is still decoded (inside the CPU) at physical address 0xB4000000, address line A23 to U31 is
affected by the shift, so the actual physical address of nFAST_CS is 0xB5000000, not 0xB4800000.