Re: Investigaciones previas sobre CHAMELEON96
Publicado: 30 Sep 2020, 22:25
Para empezar, diré que nunca antes había tenido o programado una FPGA de ninguna clase, así que para mí esto es bastante complicado, siendo generosos.
En el manual tenemos descritos los 3 relojes que hay, basados el reloj principal, el de periféricos y el de la SDRAM. Mi falta de experiencia en estas lides me hace desconocer si eso es suficiente o no. Desde luego, todo sale del HPS que, según donde lo leas, y suponiendo que lo interpreto bien, es un método desaconsejado expresamente por ALtera para coger un reloj por los problemas de jitter. Algunos conocedores del código me han asegurado que ese mismo reloj también lo usan en el proyecto MiSTer para algún core. Si es lo que hay, habrá que apañarse.
Lo de usar QSYS (cuyo nombre actual es en realidad Platform Designer) me temo que es la solución, si no la más rápida, sí la más simple. Una vez generado el proyecto mínimo, que a mi me ha costado varios días de lucha encarnizada con el Quartus, el resto ya lo programas de una forma más "normal". Lo de tener que borrar la dichosa línea del archivo .qip es debido a que, al menos en mi proyecto mínimo, no he añadido el manejo de la DDR3, cosa que en un SoC con un ARM dual-core se espera que se tenga. Una vez que sigues el nada evidente o trivial proceso de añadir los pines, ya no hace falta borrar la línea nunca más.
En todo caso, el problema que he visto es que copiando los parámetros de la DDR3 del proyecto CV96 original en mi proyecto, no funciona. O no consigo hacerlo funcionar por la complejidad del proceso, que esa es la segunda parte de la historia. El SoC tiene una cantidad salvaje de partes configurables, PERO, siempre hay uno, únicamente se pueden configurar inmediatamente después de un "cold boot". Eso obliga a, partiendo del QSYS y con ayuda del SoC FPGA, a generar unos ficheros .h que deben usarse para recompilar el u-boot con soporte de spl y, si vas a usar Linux, generar el nuevo device-tree adaptado a tu proyecto. Hay muchas cosas que programando únicamente la parte de la FPGA no se consigue nada, porque falta la otra. Debo reiterar, una vez más, que el proceso completo es complejo y nada evidente. Un usuario de Telegram, Marcus Jordan, ha portado a un u-boot del 2017 los cambios necesarios para que soporte la Chameleon 96. Ojo, porque este proceso es inherente al funcionamiento del SoC, y sucede lo mismo en la MiSTer. Solo que esta última lleva ya varios años de desarrollo de ventaja. Que yo sepa, el framework de la MiSTer permite reprogramar los relojes sin usar QSYS. Pero tampoco me parece algo gravísimo tener que usarlo para iniciar el proyecto.
Me he tirado una semana peleando con un par de docenas que no conocía ni entendía bien, y al final he podido manejar vía LOANIO los 4 LEDs de usuario que están colgando del HPS, generando el u-boot correspondiente de por medio. Afortunadamente, el manual es bastante completo, pero eso no quita la dificultad de manejo de un SoC tan bestia como es éste.
Efectivamente, del TDA no hay nada de nada. Pero sí existe lo justo como para inicializar un modo de 720p o de 1080p. A mi me preocupa más lo de después, tener bien preparada la conexión entre la FPGA y el TDA para enviarle los datos que hay que mostrar a partir de un framebuffer en la memoria DDR3. Pero bueno, la MiSTer lo hace, de modo que imposible no es. Por el medio hay que intentar no reinventar la rueda y aprender a manejar el interfaz I²C2 que está conectado al TDA para configurarlo, pero no como si fueran líneas GPIOs, sino usando la funcionalidad del interfaz I²C de verdad. Yo tengop muy claro cómo usar esos interfaces desde Linux (de hecho, el TDA lo inicializa u-boot, no Linux) a base de mapped-IO, pero ni idea aún de cómo usarlos desde Verilog.
Si empezar con un HDL es duro, empezar con éste SoC es tremendo y la implementación en la C96 no facilita las cosas, pero en Telegram un usuario portó los BASIC de 6502, 6809 y Z80 en unos cuantos ratos, funcionando bien vía consola serie. Compré la placa para aprender y espero que aún me sirva para eso, aunque no todo sea miel sobre hojuelas. A fin de cuentas, como tú mismo dices, esto va de entretenerse aprendiendo a base de martillazos.
Solo he encendido 4 LEDs, pero he aprendido en esa semana más que si hubiera iluminado el árbol de navidad del Rockefeller Center.
En el manual tenemos descritos los 3 relojes que hay, basados el reloj principal, el de periféricos y el de la SDRAM. Mi falta de experiencia en estas lides me hace desconocer si eso es suficiente o no. Desde luego, todo sale del HPS que, según donde lo leas, y suponiendo que lo interpreto bien, es un método desaconsejado expresamente por ALtera para coger un reloj por los problemas de jitter. Algunos conocedores del código me han asegurado que ese mismo reloj también lo usan en el proyecto MiSTer para algún core. Si es lo que hay, habrá que apañarse.
Lo de usar QSYS (cuyo nombre actual es en realidad Platform Designer) me temo que es la solución, si no la más rápida, sí la más simple. Una vez generado el proyecto mínimo, que a mi me ha costado varios días de lucha encarnizada con el Quartus, el resto ya lo programas de una forma más "normal". Lo de tener que borrar la dichosa línea del archivo .qip es debido a que, al menos en mi proyecto mínimo, no he añadido el manejo de la DDR3, cosa que en un SoC con un ARM dual-core se espera que se tenga. Una vez que sigues el nada evidente o trivial proceso de añadir los pines, ya no hace falta borrar la línea nunca más.
En todo caso, el problema que he visto es que copiando los parámetros de la DDR3 del proyecto CV96 original en mi proyecto, no funciona. O no consigo hacerlo funcionar por la complejidad del proceso, que esa es la segunda parte de la historia. El SoC tiene una cantidad salvaje de partes configurables, PERO, siempre hay uno, únicamente se pueden configurar inmediatamente después de un "cold boot". Eso obliga a, partiendo del QSYS y con ayuda del SoC FPGA, a generar unos ficheros .h que deben usarse para recompilar el u-boot con soporte de spl y, si vas a usar Linux, generar el nuevo device-tree adaptado a tu proyecto. Hay muchas cosas que programando únicamente la parte de la FPGA no se consigue nada, porque falta la otra. Debo reiterar, una vez más, que el proceso completo es complejo y nada evidente. Un usuario de Telegram, Marcus Jordan, ha portado a un u-boot del 2017 los cambios necesarios para que soporte la Chameleon 96. Ojo, porque este proceso es inherente al funcionamiento del SoC, y sucede lo mismo en la MiSTer. Solo que esta última lleva ya varios años de desarrollo de ventaja. Que yo sepa, el framework de la MiSTer permite reprogramar los relojes sin usar QSYS. Pero tampoco me parece algo gravísimo tener que usarlo para iniciar el proyecto.
Me he tirado una semana peleando con un par de docenas que no conocía ni entendía bien, y al final he podido manejar vía LOANIO los 4 LEDs de usuario que están colgando del HPS, generando el u-boot correspondiente de por medio. Afortunadamente, el manual es bastante completo, pero eso no quita la dificultad de manejo de un SoC tan bestia como es éste.
Efectivamente, del TDA no hay nada de nada. Pero sí existe lo justo como para inicializar un modo de 720p o de 1080p. A mi me preocupa más lo de después, tener bien preparada la conexión entre la FPGA y el TDA para enviarle los datos que hay que mostrar a partir de un framebuffer en la memoria DDR3. Pero bueno, la MiSTer lo hace, de modo que imposible no es. Por el medio hay que intentar no reinventar la rueda y aprender a manejar el interfaz I²C2 que está conectado al TDA para configurarlo, pero no como si fueran líneas GPIOs, sino usando la funcionalidad del interfaz I²C de verdad. Yo tengop muy claro cómo usar esos interfaces desde Linux (de hecho, el TDA lo inicializa u-boot, no Linux) a base de mapped-IO, pero ni idea aún de cómo usarlos desde Verilog.
Si empezar con un HDL es duro, empezar con éste SoC es tremendo y la implementación en la C96 no facilita las cosas, pero en Telegram un usuario portó los BASIC de 6502, 6809 y Z80 en unos cuantos ratos, funcionando bien vía consola serie. Compré la placa para aprender y espero que aún me sirva para eso, aunque no todo sea miel sobre hojuelas. A fin de cuentas, como tú mismo dices, esto va de entretenerse aprendiendo a base de martillazos.
Solo he encendido 4 LEDs, pero he aprendido en esa semana más que si hubiera iluminado el árbol de navidad del Rockefeller Center.