mcleod_ideafix escribió:La decisión de no permitir el acceso a la SPI flash desde, vamos a llamarlo, el "modo usuario" fue precisamente para evitar brickeos del aparato, intencionados o no, que obligarían al usuario a disponer de un programador universal o un cable JTAG. usar una key "secreta" para evitar el brickeo es inútil, dado el carácter abierto del proyecto. Usar una "secuencia mágica" para desbloquear el acceso a la SPI flash tiene más sentido (el tipo de cosas que hizo Amstrad para desbloquear las características avanzadas del ASIC del CPCplus) pero no evitas que un usuario malintencionado te cuele un TAP con un programa que ejecute esa secuencia, borre un cacho de flash y te brickee el ZX-Uno.
Es que me referia exactamente a eso, como ya he aclarado en los 2 posts de respuesta que he dado a yombo y jordi_ab. Me refería a esa secuencia mágica. De hecho ya he editado el psot quitando la parte en la que me expliqué mal)
Con respecto a lo del usuario malintencionado (que también he comentado en el post de respuesta a los mencionados usuarios), añado a esas respuestas:
mcleod_ideafix escribió:- Desbloquear el acceso a la SPI Flash con una secuencia mágica, key, o como quieras llamarlo, confiando en que no habrá usuarios perversos. [...]
Lo malo es que el sólo hecho de mencionar "usuario perverso que puede brickearte tu ZX-Uno con un TAP" ya puede poner en alerta a un usuario suspicaz. Cuando alguien usa un Spectrum, jamás de los jamases ha tenido que preocuparse por el software que carga en su ordenador, y no querría que esto cambiase. ¿Soy demasiado paranoico?
Bueno he dicho añado, pero en realidad sería repito, lo último, pero matizado (antes del EDITO) que he comentado en el post justo encima del tuyo (en respuesta a jordi_ab):
Si un usuario malintencionado quiere, como todo es abierto, tal como está ahora mismo la escritura sólo posible en BIOS, puede igualmente coger el script genrom y generar un TAP completamente válido de Machine partiendo de un archivo de 336kb lleno de ceros. Eso brickea el ZX-UNO exactamente igual que un .TAP malicioso con la "key" correcta. Así que no veo en la práctica mucha más ventaja al sistema actual en el aspecto de seguridad.
¿La solución "definitiva"? Advertir que SOLAMENTE se descarguen los upgrades y los cores desde el site OFICIAL, y así siempre van a estar seguros de que su ZX-UNO no se va a brickear.
Aun así, te doy la razón en que si dejamos escribir en modo usuario, un usuario muy muy retorcido podría intentar "colar" un TAP de un "juego muy chulo" y que fuera un "bricker" en la realidad.
mcleod_ideafix escribió:- Bloquear el acceso a la SPI flash para que sólo pueda tenerlo la BIOS como estamos haciendo por ahora, lo que significa que perdemos la posibilidad de lanzar cores desde un comando ESXDOS con toda la facilidad que eso implica, e implementar el código necesario para leer los cores desde la SD en la BIOS, sin soporte de ESXDOS. Tened en cuenta que el acceso de SD desde la BIOS es de todas formas muy conveniente, para poder actualizar ROMs, core principal, y el propio firmware desde la tarjeta SD en lugar/además de por EAR.
Esta es sin duda la mejor opción, como ya he comentado. También es más compleja de hacer, pero es la mejor.
A esto añado, que en vez de un comando exdos para lanzar cores veo mucho más facil tanto de ejecutar como de implementar, usar una combinación de teclas para lanzar cada core. Por ejemplo:
Ctrl+F1 = lanza core 1
Ctrl+F2 = lanza core 2
.... etc
En base a un mapa de X roms fijo en la flash (8 cores = 8 combinaciones de teclas), y según el tamaño que vayamos a usar (probablemente 32 MBits), no harán falta más (8 o 9 a lo sumo)
Es inmediato, rápido, no requiere teclear nada ni si quiera requiere tener el spectrum arrancado con una rom ni divMMC activado, y es muy fácil de implementar. Ahora mismo hago el cambio de core con un pulsador en el puerto de expansión, pero hacer que se mande un "1" al REBOOT no tendrá dificultad para añadirse al parser de teclado...
(bueno, para tí seguramente si será sencillo, claro, yo ahora mismo no se hacerlo... si no, lo habría hecho en vez de con un pulsador 
)La tercera opción me parece la menos conveniente y más complicada (y lenta). Yo apuesto por una flash bien grande donde los cores que quieres los grabas una sola vez (bueno, o alguna más si se van actualizando las funcionalidades de los cores, pero serían mínimas), evitando tener que escribir cada vez en la flash, lo que acortaría su vida. Además no requeriría programar nada extra (bueno si, la opcion 2, la de grabarlos desde SD).
mcleod_ideafix escribió:- ¿Alguna idea más? Aunque implique picar mucho más código, me parece más "elegante" la segunda opción.
Las que has puesto son las más lógicas.
De hecho, para la 2ª opción, hay ya bastante código ya hecho que sólo habría que adaptar un poco para nuestra BIOS (que comente Antonio cómo lo ve), que está en los archivos fuente que acompañan al core de SMS, donde ya se implementa para Z80 (en ensamblador la mayoría y algo en C), el protocolo de lectura SD y el driver FAT. De hecho se compila con z88dk (así lo compilé yo cuando hice el port). Si sólo es adaptarlo un poco, es bastante posible que el esfuerzo se reduzca bastante.
--
EDITO: acabo de ver tu actualización:
-- Actualizado 14 Sep 2015, 23:22 --
mcleod_ideafix escribió:Otra opción, del estilo de lo que plantea jordi_ab: tener una opción en la BIOS para permitir el uso de la flash desde el modo usuario. Esa opción tendría que activarse por el usuario, y sólo duraría hasta el siguiente reset o máster reset. La idea es que el usuario resetearía, pondría esa opción (puede ser pulsando alguna tecla concreta mientras la máquina arranca) y entonces sí puede usar ESXDOS para actualizar cores, o lo que sea, en la flash. En el siguiente reset, reboot, máster reset o lo que sea, el acceso a la flash vuelve a estar denegado. Esto bloquearía la gran mayoría de intentos de brickeo intencionados.
Me parece una muy buena idea, en el caso de que al final no se hiciese la opcion 2 (la de actualizar por SD desde BIOS)
