Te recuerdo que todo esto tiene el objetivo de armar un ataque al comportamiento de un programa desde el hardware para mostrar en H4CK3D 2021. Como productos colaterales, una mejor adaptación de grahamedgecombe/icicle a ciaa/icicle, en parte aceptada como PR, en parte quedará en cpantel/evilCodeSequence y un montón de aprendizaje de mi parte, que te comparto como siempre, más si venís de leer todo esto:
- H4CK3D 2021: configuración básica
- H4CK3D 2021: leyendo los botones de la placa
- H4CK3D 2021: un desvío necesario
- H4CK3D 2021: un desvío innecesario
- H4CK3D 2021: sigue el desvío, para bien
- H4CK3D 2021: cambios al Makefile
El problema que vengo arrastrando es el tiempo:
- yosys: 1:10
- nextpnr-ice40: 1:45
- iceprog: 2:00
No puedo evitarlos, pero como habías visto en la entrada anterior, hay dos ramas, una para el hardware y otra para el software. Convergen en la que llamo "system", que es al resultado del proceso de hardware pegotearle la imagen obtenida por el proceso de software.
 |
| Makefile detallado original |
Tal como está el Makefile, como que no está fácil, así que lo desarmé para terminar de entenderlo y lo volví a armar. De paso, veamos el proceso pero un poco menos detallado:
 |
| Makefile con reglas sencillas, diagrama simplificado |
Eliminé algunas partes del diagrama para recalcar las cuatro reglas y lo de la memoria.
Arriba a la derecha, se arma la imagen, lo cual incluye tanto nuestro programa como otro código, de esto aún no sé mucho, parece haber algo de inicialización y el de arranque, ya seá desde la RAM o desde flash, este es un punto interesante a explorar, cargar el programa desde memoria SD, agilizaría aún más el proceso.
Arriba a la izquierda, como que estaba confundida la construcción de la imagen con la inclusión de RAM. De hecho, en el Makefile original si modificás el programa regenera sin necesidad el hardware. El primer icebram lo que hace es sólo reservar el espacio de memoria, luego, en system, nuevamente icebram, pone el programa en esa área reservada.
Las nuevas reglas las construí apuntando al final de reglas existentes, los cambios son en el Makefile:
software: BUILD/progmem.hex
Sencillo, pedís "software", hace lo necesario para construir progmem.hex.
hardware: $(ASC_SYN)
según ASC_SYN = BUILD/$(TOP)_syn.asc viene a ser top_syn.asc en el diagrama.
system: $(BIN)
según BIN = BUILD/$(TOP).bin es top.bin en el diagrama
Para romper el encadenamiento erróneo que había, convertí:
$(BLIF) $(JSON): $(YS) $(SRC) BUILD/progmem_syn.hex BUILD/progmem.hex BUILD/defines.sv
en
$(BLIF) $(JSON): $(YS) $(SRC) BUILD/progmem_syn.hex BUILD/defines.sv
Ahora, tal como es de esperar, puedo reemplazar el programa en sólo dos minutos en lugar de los cinco originales.
Respecto a utilizar la flash como arranque, mmh, estuve mirando con más detalle y dice ser SPI, lo cual implica cuatro señales: SCLK (el clock), SS (Slave Select para elegir el chip), MOSI (datos del master al slave) y MISO (datos del slave al master).
Para comenzar, en top.sv parecen estar los dos primeros, pero los últimos están como inout
Me da olor a Dual SPI. Más que luego se instancian uno tales "flash_io" del tipo SB_IO y TRELLIS_IO que según veo por encima rapidito tienen que ver con tristate.
Luego, en flash.sv, dice
assign clk_out = clk;
y no me suena que SPI soporte 36Mhz.
¡Qué lástima! Me había hecho ilusiones, incluso le había soldado los pines al sdcard reader que tengo. Esto está muy encima de mis habilidades y no es bloqueante ni aporta mucho al malware que tengo que hacer funcionar...