AnsweredAssumed Answered

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

Question asked by Vinay Bondade on Jun 19, 2019
Latest reply on Jun 27, 2019 by igorpadykov
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. 

Outcomes