Issue with modifying the SDRAM's row address width on i.mx258

[vinaybondade]

Hello All,

I am currently working on i.mx258 micro controller. There has been a hardware change to support 128Mb RAM. The hardware currently supports 64Mb RAM. The problem has come as it is required to support both 64Mb RAM for (backward compatibility with the hardware) and 128 Mb RAM on newer boards.

128 Mb RAM requires that Row address width to be set to 14 row addresses instead of 13 row addresses (for 64 Mb RAM) in the ESDRAM control register. To support older hardware, we decided to keep the row address width as 14 for both hardware (older ones with 64Mb RAM and the new ones with 128Mb). This allows to retain generic boot loader for both hardware.

Is it correct to set row address width to 14 where the older units with 64Mb RAM had this value set to 13. Is this going to result in any undefined behaviour from i.mx258 perspective beacuase of suing 14 row addresses where 13 was sufficient?

We are facing intermittent lock up in Redboot while copying buffers to RAM. Cannot say how kernel is dealing as we haven't booted the kernel with row address set to 14. The issues appears only on hardware with 64Mb RAM that required row width to be set to 13. New hardware with 128Mb is working OK with row address width set to 14.

for ex, consider the code below - 

char *buffer_ptr = (char *)0x81000000; // RAM destination address
char *flash_addr_ptr = 0xe8c0000; // Flash memory address

int size = 0x1480000;

int index = 0;

for(index = 0; index < size; index+=2048, buffer_ptr+=2048, flash_addr_ptr+=2048){

flash_read(buffer_ptr, flash_addr_ptr, 2048); // calls memcpy after reading flash memory

}

This above code is from Redboot, while copying at RAM location 0x81100000, Redboot is hung up in memcpy() function. Further debugging has revealed that storing the value at 0x81100000 is where the system seems to be hung up.

The behaviour seems to be different if I use the destination start address as 0x81100000 instead of 0x81000000, where the data copy at this location works. It seems the problem

 is intermittent and is not at a specific RAM address.

Due to this issue I tried dynamically changing the row address width from 13 to 14 if 128 Mb RAM is found, but changing the ESDRAM control register while Redboot is executing from RAM crashes the Redboot, tried doing this by relocating the code to internal RAM, still no luck. Is it allowed to change the row address width after ESDRAM has been initialised?

It will be really helpful, if anybody can provide any inputs on these quieries. 

[igorpadykov]

Hi Vinay

in i.MX25 address translation is based on the following concept: COLUMN - ROW - BANK.
So for 0x81000000; // RAM destination address, 0x0"1"000000 corresponds to A24 described in
Table 24-17. Address Multiplexing by Column/Row Width for 16-bit Devices
i.MX25 Refernce Manual. Since device with  row address width 13 do not have it,

it accesses to 0x80000000, ignoring it.
https://www.nxp.com/docs/en/reference-manual/IMX25RM.pdf

> Is it allowed to change the row address width after ESDRAM has been initialised?

sorry, not allowed.

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[vinaybondade]

Hi Igor,

Thanks for the response.

After your response, it is clear that I cannot set the row address width to 14 for a 512 Mbit SDRAM memory device (I was trying to achieve a generic Redboot for both 512 Mbit and 1 GBit memory devices). It is messing up the bank selection if the row address width is set to 14 for a 512 Mbit SDRAM memory device. 

The option I can think to make Redboot generic for both devices are - 

1. Change the row address width to 14 after FIS init (I can read some configuration ASCII strings from a partition which tells the size of the RAM) but by this time SDRAM init has already completed. The SDRAM init happens from DCD table. From your previous reply you are indicating that this is not possible. I am planning to relocate the code that changes the row width address to internal RAM (0x7800_0000) then reset SDRAM controller, copy Redboot again to RAM and continue normal execution.
2. Have two DCD table entries and execute the correct one depending on the hardware, this might require resigning Redboot to succeed the HAB check and restarting the device to use the DCD entries for 1GBit RAM.
3. Have a GPIO pin to decide which memory device is present (512 MBit or 1 GBit), before Redboot gets loaded to RAM set the SDRAM row address width to 14

Let me know what do you think.

Thanks,

Vinay

[igorpadykov]

Hi Vinay

I think all these options are feasible.

Best regards
igor