Tenemos un tablero (nuevo, prototipo) que es, en el mejor de los casos, temperamental. Utiliza un Micron MT47H64M16HR-25: H DDR RAM, la placa de referencia de diseño usa un Micron MT47H64M16HR-25E: H. Sólo una letra diferente, ¿qué podría salir mal? La letra adicional significa que el DDR de nuestra junta tiene un Cas Latency (CL) de 6, mientras que el de referencia tiene un CL de 5.
Entonces, ¡lo que podría salir mal es que nuestra placa no funciona! O, si descartamos la frecuencia del reloj, se iniciará parcialmente pero luego se bloqueará. Por supuesto, hay muchas otras cosas que podrían causar esto, así que estoy analizando las posibilidades, siendo esta una de ellas.
Una arruga es que la CPU (TI DM368) no se puede configurar para CAS mayor que 5. Otra arruga es que el DDR no se está ejecutando a la velocidad máxima; se ejecuta a 340 (680) MHz o 270 ( 540) MHz, que están por debajo de las especificaciones de la parte de 400 (800) MHz. Hay una tabla en la hoja de datos de Micron que sugiere que el CL puede disminuir cuando se ejecuta más lento, pero no hay una explicación para confirmar o negar.
Esta publicación sugiere que CL es un valor basado en el tiempo, I.E. siempre se necesitarán Xns para acceder a la pieza, independientemente de la frecuencia de reloj.
En mi opinión, dado que el SDRAM es un dispositivo impulsado por reloj, el CL estaría relacionado con los tics del reloj en lugar de un período fijo, pero estoy bastante consciente de que en DDR hay todo tipo de trucos para presionar el límites.
Por lo tanto, la pregunta es: ¿CL está fijo en ciclos de reloj o en hora?
Pregunta de bonificación : ¿Cómo puedo probar el DDR sin poder iniciar Linux? Las pruebas de ram U-Boot son de lectura / escritura muy básicas y nunca arrojan un error. ¿Alguien tiene buenos trucos? Puedo recompilar U-Boot con una nueva rutina si es necesario.