Couple of questions on L137 EMIF-A

This is taken from section 2.5.2 of the EMIFA User's Guide:

• The device has a limited number of dedicated EMIFA address pins, enough to interface directly to an
  SDRAM. If a device such as an asynchronous flash needs to be attached to the EMIFA, then GPIO pins
  may be used to control the flash device’s upper address lines. This is sufficient to boot from the flash.
  Normally, code stored in flash is copied into SDRAM or internal memory before executing because these
  memories have much faster access times. For details on which device pins are GPIO capable, see your
  device-specific data manual.

Jeff

Also for your second question Figure 8 in the same document shows the connections to asynchronous memory depending on the bus width.

Jeff

Jeff, thank you for your response.  But I still don't understand where the 32 megabit memory come from.  Are you saying the 32Mb is only valid for SDRAM, instead of an asynchronous memory?  My problem is that I can only count 15-bit address bus (i.e. BA0, BA1, EMA_A0, EMA_1... EMA_12).  15-bit address bus can only define 32Kb memory instead 32Mb.  Am I right?

In Figure 8, a) uses both BA0 and BA1 as the least significant bits for the EMIF-A memory, while b) uses only BA1.  What are the memory base address for these two configurations?

Thank you.

Another way to ask the question: Assume Figure 8 (b) configuration, if I want to read a data from BA1=1, EMA_A0=1, EMA_A1=1... EMA_A12=1,CS3 = 0, what is the MMR address I shall read the data from?  Thank you.

Yes the 32Mb comes from the SDRAM connection where less address bits are required to access the entire memory range. For async memories GPIOs have to be used to address the upper portions of memory.

In both cases the base address for CS[3] would be 0x62000000

Jeff

For 16 bit mode, you would read from base 0x62000000 at offset 0x400E

The EMA_A[15:0] pins correspond to the 32-bit address, so for your scenario where EMA_A[12:0] = 0b1000000000011, the MMR address offset would be that shifted left two bits, giving 0b100000000001100.

The BA1 pin corresponds to the 2nd bit of the MMR address, and for 16-bit accesses, the first bit would always be 0.

So the final MMR address offset would be 0b100000000001110, or 0x400E.

Jeff

Thank you Jeff.

If my access is 8-bit, then I should use Fig 8 (a) where both BA0 and BA1 are used (as least significant bits of the address), correct ?

I want to use EMIF-A to access a 8-bit asynchronous memory, with OMAP-L137 EVM board.  I noticed XA1 and XA2 pins are used for SD/MMC.  So I'm thinking to use BA0, BA1, XA0, XA3, XA4... XA12 as the address bus, together with CS3 for Chip Enable.  But I don't know how to multiplex EMIF-A between the asyn memory and SD/MMC.  It seems like  CS4 and CS5 pins connect to SD-WP and SD-CD pins.  However, these two pins are NOT EMIF-A controlled (once SD card inserts, CS4 and CS5 are asserted low.  Sort of fixed by the SD/MMC slot).  Am I right?  Any suggestions?

Thank you !

Yes for 8-bit you would follow fig 8 a.

If you are using SD/MMC then set those pins in the pinmux configuration to behave as SD/MMC pins. Since you are not using CS4 or CS5 (which are EMIFA  outputs) then there wont be an issue if these pins are used for MMC/SD.

Jeff

Normal 0 false false false EN-US ZH-CN X-NONE

Jeff, thank you for response.  CS4 and CS5 connect to SD-WP and CD pins of SD/MMC connector P2 (MHC-W21-601).  Here is its schematic:

http://www.riderelect.co.kr/demension/connector/card/memory/MHC-W21-601.pdf  

Page 1 shows how the SD-WP and CD are used.  It seems like they connect to GROUND (asserted to low) by mechanical means, instead of controlled by EMIF-A (i.e., as EMIF-A outputs).  If that’s true, then once card inserted, CS5 will always be low.  CS3 access toggles XA1 and XA2, which are used by SD/MMC as well.  I’m worried that CS3 access can affect SD/MMC access since CS5 is always low.  Any advice?  Thank you.

If XA1 and XA2 are selected in the pinmux registers to be MMC/SD pins, they will not toggle with CS3 accesses.

You can also configure CS4 and CS5 to be GPIO pins so that they are not driven high by the EMIF.

Jeff

Normal 0 false false false EN-US ZH-CN X-NONE

I misunderstood XA1 and XA2 from the beginning.  I thought they are EMIF-A pins to access SD/MMC card.  Actually they are not.  Correct?

Since the EVM board uses the SD/MMC to load linux OS, have XA1, XA2 already been set up as SD/MMC pins by default?  Same for CS4 and CS5, configured as GPIO by default?

Thanks,

Pins R9 and P9 have multiple functions depending on how the pinmux registers are setup. They can either function as EMIFA address pins or MMCSD CLK/CMD pins.

If you are booting from NOR then the pinmuxing must be set to EMIF-A by default in order to boot successfully. The UBL or UBOOT would have to change the pinmux to MMCSD in order to boot the OS from an SD or MMC card.

Jeff

I'm using the SPI Boot EEPROM and my PC talks to EVM through USB JTAG.  Why did you say "the pinmuxing must be set to EMIF-A by default in order to boot successfully"?  I looked at the EVM schematic, only SD/MMC and expansion connector P11 are connected to EMIF-A (i.e. EMIF-A seems nothing to do with SPI Boot EEPROM).  This case, it doesn't matter whether R9 and P9 are configured as XA1/2 or SD CLK/CMD.  Am I right?

Sorry I assumed you were using the EMIFA for boot.

Yes if you are booting from the SPI EEPROM, then R9 and P9 do not need to be configured.

Jeff

Jeff, thank you for the confirmation.  Appreciate all your replies and answers to my questions ! 

Jeff, sorry to ask one more question after such a long time.  A couple of weeks ago I asked here about how to multiplex L137 EMIFA between SD/MMC and other asyn memory.  I have one more fundamental question about L137 EVM board. 

In “evmomapl137_dsp.gel”, EMIFA configuration is:

Code Snippet said:

#define AEMIF_AWCCR                *( unsigned int* )( 0x68000004 )
#define AEMIF_A1CR              *( unsigned int* )( 0x68000010 )
#define AEMIF_A2CR              *( unsigned int* )( 0x68000014 )
#define AEMIF_A3CR              *( unsigned int* )( 0x68000018 )
#define AEMIF_A4CR              *( unsigned int* )( 0x6800001C )
#define AEMIF_NANDFCR              *( unsigned int* )( 0x68000060 )

Setup_EMIFA( )
{
    /* Use extended wait cycles to keep CE low during NAND access */
    AEMIF_AWCCR = 0xff;      

    /* Setup CS2 - 8-bit normal async */
    AEMIF_A1CR = 0x00300608;  // Setup=0, Strobe=C, Hold=0, TA=2, 8-bit
    AEMIF_NANDFCR &= ~1;

    /* Setup CS3 - 8-bit NAND */
    AEMIF_A2CR = 0x00300388;  // Setup=0, Strobe=7, Hold=0, TA=2, 8-bit
    AEMIF_NANDFCR |= 2;

    /* Setup CS4 - 8-bit normal async */
    AEMIF_A3CR = 0x00a00504;  // Setup=0, Strobe=A, Hold=0, TA=1, 8-bit
    AEMIF_NANDFCR &= ~4;

    /* Setup CS5 - 8-bit normal async */
    AEMIF_A4CR = 0x00a00504;  // Setup=0, Strobe=A, Hold=0, TA=1, 8-bit
    AEMIF_NANDFCR &= ~8;
}

Yes the NAND flash is actually on a separate interface board that connects to the expansion connectors. If you make your own board instead there won't be any conflict.

Jeff

great, thank you for the confirmation.