📣 Soporte bitstream upload SRAM en Alhambra-ii

[charli va]

Hola amigos! he hecho un descubrimiento increible, y me he sentido absurdo.

Estoy trabajando unas cosas nuevas para la nueva versión de icestudio y entre ellas estoy explorando bastante openfpgaloader y he visto que tenía soporte tipo dirty jtag para el modelo FTDI de la Alhambra-II y me he preguntado, joder si tiene ese soporte tiene que poder escribir en la SRAM de la FPGA directamente......

y justo, esque no he tardado ni 10 segundos en verlo en la documentación.

Como la Alhambra-ii como tal no está integrada pero sí soporta tarjetas genéricas basdas en el modelo de la icestick FTDI+SPI+ice40 con este simple comando:

openFPGALoader -b ice40_generic bitstream.bit    

donde bitstream.bit es vuestro bitstream, se guarda en la SRAM usando el modo JTAG del FTDI!!! 

Increible, diseños grandes que me tardaban en grabarse en la flash casi 30 segundos, se cargan volando!

En la próxima versión de icestudio que liberaré pronto contad que irá incluido y para los que uséis linea de comandos os va a dar la vida.

Recordad que openfpgaloader está en yosys, no tenéis que instalar nada adicional si ya lo tenéis instalado.

Buenas noches!

[beni...@gmail.com]

Hola charliva,

Si, en la implementacion que yo hice de las placas ECP5 el bitfile se sube en la propia FPGA (tu la llamas SRAM) , no en la SPI Flash. Por tanto es mucho mas rapido, pero el inconveniente que tiene es que es volatil, si se quiere grabar permanentemente en la SPI Flash se ha de usar el comando de OpenFPGALoader que graba el bitfile en la SPI Flash de la placa.

En la Alhambra siempre lo habeis grabado en la SPI Flash y la verdad es que me he estado preguntando siempre el por que de ello.
Si ahora lo cambias en el IceStudio sera mucho mejor para todos. Lo conveniente seria tenerr un apartado en la configuracion y marcar si se quiere hacer los cambios permanentes (subior a la SPI Flash) o temporales (Subir a la FPGA , es decir, la SRAM de la FPGA)
Gracias por compartir tu nuevo hallazgo

Un Saludo

Fernando Mosquera

[charli va]

Buenas Fernando! efectivamente funciona así, puse el post porque hace poco lo estuvimos hablando al igual que en  Apio hace unas semanas y en ambos casos lo dimos por camino perdido.

El tema es que la Alhambra-ii no tiene los pines configurados entre la spi , el ftdi y la fpga para que se pueda programar la fpga directamente con iceprog, por eso en icestudio por herencia ,solo había un comando de upload que en la Alhambra grababa en la flash , porque básicamente iceprog no puede saltarse la spi y llegar ala FPGA por un tema de conexionado físico (se podrían cortar y puentear pistas pero habría que tener pulso y ojo sobrehumano). Por otro lado se podría modificar iceprog posiblemente, hace unas semanas estuve mirando el código para ver si se podría modificar haciendo algún tipo de bitbanging para simular precisamente lo que hace openfpgaloader, pero lo descarté porque aunque intuí que podría ser posible veía trabajo y sobre todo dolores de cabeza a futuro en cuanto a mantener un fork de una herramienta importante, por lo que descarté el camino.

Pero la sorpresa ha venido cuando de casualidad he visto que el FTDI puede trabajar en modo JTAG y de este modo se puede usar este protocolo para que el ftdi rute como quien dice los datos en vez de a la spi a la fpga directamente.

iceprog no puede hacer eso pero openfpgaloader sí (y lo acabo de descubrir).

Ya tengo encaminado una nueva opción en icestudio para poder grabar de un modo u otro en las placas que lo soporten, la nueva versión va a traer muchos cambios.

Os lo he compartido porque sé que hay usuarios que utilizan directamente yosys sin icestudio (yo mismo para muchas cosas que tiro directamente de verilog ). y aunque aún no esté en icestudio creo que puede ser una ayuda importante para mucha gente poder trabajar desde ya así.

Pasad buena tarde/noche!

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/6d6cb65e-0e38-4d5a-a19e-71f9d1474acan%40googlegroups.com.

[Fernando Mosquera]

Exactamente es como dices, el OpenFPGALoader permite los dos modos de grabación mediante un programador FTDI.

Yo es que provengo de la vieja escuela con las FPGAs. Empecé primero con Xilinx, luego Altera , Lattice y ahora estoy con las Chinas Tang que también me parecen muy interesantes.

En estas placas se permite grabar generalmente en ambos modos aunque por defecto se suele grabar en la SRAM de la FPGA porque es mucho más rápido.

También ocurre que a mayor tamaño de la FPGA, más ocupa el bitfile y más tarda en grabarse en la SPI Flash

Esperando con ansia tu nueva versión del IceStudio.

Saludos y buenas noches a todos,

Fernando

Get Outlook for Android

---

From: fpga-wars-explora...@googlegroups.com <fpga-wars-explora...@googlegroups.com> on behalf of charli va <char...@gmail.com>
Sent: Saturday, May 10, 2025 3:56:18 PM
To: fpga-wars-explora...@googlegroups.com <fpga-wars-explora...@googlegroups.com>
Subject: Re: 📣 Soporte bitstream upload SRAM en Alhambra-ii

 

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCYvLU6UsKht6YHrxb6Hp%2BxbzNCwP%2BWFCJ85SGDW0m8PZg%40mail.gmail.com.

[charli va]

Gracias a ti Fernando! tus aportaciones siempre son fantásticas!  y por cierto las Tang también van incluidas en la nueva versión!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/SJ2PR20MB597049D9A2271EEB1C670E78FF95A%40SJ2PR20MB5970.namprd20.prod.outlook.com.

[beni...@gmail.com]

Si las Tangs van incluidas , mas razon para esperar con ansia esa nueva version.

Muchas gracias por el grandisimo trabajo que haces

Saludos

Fernando

[Jesus Arias]

Hola Carlos,

Hace ya años que me hice una aplicación para cargar los bitstreams directamente en la FPGA de la placa ICESTICK, y también funciona con la Alhambra.

El truco es usar un modo bitbanging pues no hay forma de intercambiar SDI y SDO sin recurrir a apaños hardware como puentes o similares. (Seguramente eso se podría conseguir en modo JTAG, por lo que nos comentas)

Normalmente usaba esta aplicación para pruebas rápidas e "iceprog" cuando quería que la programación fuese no-volátil.

Adjunto el código por si sirve de inspiración para algo.

Saludos

[charli va]

Que bueno! da por hecho que lo voy a probar, estas cosas son siempre interesantes.

Era un tema que tenía pendiente mirar en profundidad (el ftdi no lo conozco al máximo detalle pero sí  he explorado  su configuración para usarlo en otros proyectos en los modos de ráfaga y en su día vi posibilidades al bitbanging o al modo jtag pero no he tenido tiempo de probarlo).

Como tenía a fuego por lo que había leído y me habían comentado otras personas que no se podía si no se hacía ñapa hardware, la verdad que me había quedado con eso, pero a veces soy un poco cabezón con las cosas y al leer el tema del modo JTAG del openfpgaloader se me activó la bombilla y la tarea salió del background XD

Como siempre muchísimas gracias por estas joyas!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/7bdc13fe-479b-4c13-99b1-16372a737e8cn%40googlegroups.com.

[charli va]

Hola Jesús! haciendo pruebas, resulta que el openfpgaloader me la "ha jugado", intenta guardar en la sram pero finalmente no lo consigue y guarda en la flash. Al guardar bitstreams más grandes me ha empezado a tardar y ya investigando me he dado cuenta de que efectivamente no guarda en la sram.... XD me dejé llevar por la emoción sin testearlo suficiente.

Exploraré tu código que me parece prometedor, muchas gracias!

[charli va]

Buenas Jesús!, confirmarte que iceram funciona como la seda. Desconocía la posibilidad de hacer bitbanging puro y duro contra el FTDI, super interesante.

Estoy viendo darle soporte para multi sistema operativo pero vamos que va a ir de cabeza en icestudio para icestick, alhambra y cualquier placa que tenga este problema.

Mil gracias de nuevo!

[Gerardo Tenreiro Vazquez]

Buenas

Estos dos últimos mensajes no los entiendo, parece que el primero se indica que no se carga en la SRAM y en el segundo se indica que si.

lo podéis aclarar?

Como sabéis estoy indeciso de utilizar el FTDI y esto es importante para mi y creo que para todos.

muchas gracias

[charli va]

Hola Gerardo, la Alhambra, al igual que la Icestick y algunas otras placas basadas en FTDI+ice40 por como tienen configuradas físicamente sus pines en la pcb no pueden simultanear el modo de grabar el bitstream en la flash o directamente en la FPGA . La diferencia es que en el segundo modo aunque volátil es rapidísimo y para el trabajo constante es muy ágil porque no tienes que esperar prácticamente nada para probar cada nuevo bitstream.

Hasta ahora siempre se ha trabajado en estas placas grabando directamente en la flash (permanente entre reinicios) aunque sea algo más lento.

Estoy añadiendo mejoras a icestudio y entre ellas un modo de subida ligera, algunas otras tarjetas soportan este tipo de configuración de serie con el programador estándar pero en el caso de estas dos placas que precisamente son de las más usadas al menos aquí, resulta que no se podía.

openFPGAloader es un software que permite programar un montón de FPGAs con diferentes protocolos y además es bastante más rápido incluso grabando en la flash (tendrá más optimizado el flujo de comunicaciones, tamaño de los chunks...) y aunque le mandaba el comando de grabar en modo jtag en la sram de la FPGA directamente , "me engañó"  al no poder hacerlo se ve que salta automáticamente al modo flash si detecta que existe una en el bus, y yo la verdad no me di cuenta.

Pero Jesús llegó con la caballería al rescate y tiene un código hecho por el ,adaptando el código original de iceprog para engañar al ftdi, básicamente activándole un modo bitbanging. El modo bitbanging es para el que no lo conozca manejar a mano el reloj y las señales, de forma que se salta las limitaciones de los pines pudiendo manejar la temporización a mano.

Y funciona increíblemente bien.

Si no se quiere recurrir a este truco, posiblemente se pueda con algún jumper físico poder alternar entre un modo de programación u otro (FLASH o directo) porque es un tema básicamente de intercambiar un par de pines , no conozco el FTDI a más nivel físico para poder responderte mejor, espero más o menos haberme explicado.

Buena tarde!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/3ae4fdfa-9812-492d-85cf-56292ee0cf7dn%40googlegroups.com.

[Gerardo Tenreiro Vazquez]

Gracias por la explicación,

Según esto seguir esperando los avances y veré por donde ir tirando.

Con los micros el tiempo de carga es importante sobre todo en las pruebas. algunos programas tardan mucho y de prueba a prueba pasas el dia.

Tenemos idea de para cuando estará la nueva versión?

Muchas gracias

[charli va]

Como te comento Gerardo, la carga no es algo super crítico, se lleva trabajando así con icestudio desde los inicios XD y los bitstreams tampoco son gigantes. Claro que ganaremos en agilidad con este nuevo modo pero no es algo que vaya a marcar un antes y después.

ME gustaría sacar una versión relativamente estable para pruebas antes del verano pero vamos andando porque estoy ahora con una tarea del motor gráfico con la que no contaba y me ha comido ya más de un mes. Pero bueno vamos avanzando y va quedando menos para salir del atasco.

Como te digo esto no es algo que te tenga que preocupar.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/efb0a3b8-a031-44ce-90c6-3995d8c6b159n%40googlegroups.com.

[charli va]

Hola a todos! estoy bastante emocionado XD

gracias al código de Jesús me ha dado luz a un tema que tenía aparcado de hace tiempo por estar bastante atascado y no entender muy bien que pasaba.

Este año quiero hacer foco en poder llevar icestudio a la web , para uso incluso offline pero con la idea de minimizar a cero la necesidad de instalar nada para gente que empieza o que simplemente quiere probar cosas.

Uno de las limitaciones es grabar las fpgas, en parte ya lo tengo resuelto (sobre todo el flasheado ) pero hay muchas limitaciones por necesitar activar opciones especiales en el navegador y cosas que al final no lo hacen "práctico 100%" así que tomé por las bravas a implementar con webusb  y usando de base iceprog un programador nativo.

El objetivo inicial era el modo sram y la verad que me atasqué, si el protocolo usb es complejo y farragoso el webusb es un piso más de nata montada XD, al ser web y un api javascript todo se convierte en llamadas asíncronas y muchísimos problemas de latencias y buffers intermedios totalmente opacos.... muy duro.

Pero el programa de JEsús al tenerlo funcionando me ha dado pistas y me ha permitido probar y comparar, tanto en programación como con el osciloscopio y....buff ha funcionado!!! al menos en mi ordenador, realmente si me echais una mano a probar sería fantástico, porque realmente esto acabo de sacarlo del horno y puede no funcionar de forma masiva.

En principio es multi plataforma, eso sí debe funcionar en chrome con un chrome no muy desactualizado pero no os pedirá absolutamente ninguna configuración especial.

He hecho una página de test para el que pueda probar en su alhambra (debería funcionar en la icestick también o en cualquier placa ftdi+ice40).

Os dejo dos bitstreams para la alhambra-ii un blink (led parpadeante) y el coche fantástico (kid).

Sólo tenéis que conectar la FPGA, darle a subir bitstream y luego a programar, os aparecerá un cuadro de diálogo en el que tendréis que elegir el usb.

Son los ejemplos de icestudio , si los queréis probar en icestudio y comparar el tiempo de carga me vendría fantástico las métricas en vuestros equipos y sistemas operativos.

Como es un volcado a sram , cuando reseteeis tendreis el bitstream que tuvierais grabado previamente y como veréis se graba a toda velocidad.

https://icestudio.io/play/iceram/

espero que os guste!!

Como os digo esta web es para testearlo y sacar conclusiones, igual no funciona en ningún lado , webusb es muy caprichoso y al jugar con las temporizaciones en modo bitbanging esto va a ser una prueba de fuego!!

Gracias a todos!

[Democrito]

Lo he probado en tres navegadores (Opera, Edge y Brave) y no ha habido manera. Te dejo con el mensaje que sale siempre.

[Jesus Arias]

Hola Carlos

Parece que mi programa te está siendo útil. Sin embargo la prueba que acabo de hacer no va:

[2025-05-18T21:33:38.994Z] Iniciando prueba con interfaz 0...
[2025-05-18T21:33:38.994Z] Probando FT2232H con interfaz 0...
[2025-05-18T21:33:43.636Z] Dispositivo abierto: vendorId=1027, productId=24592
[2025-05-18T21:33:43.637Z] Error en testFTDI (interfaz 0): NetworkError: Failed to execute 'claimInterface' on 'USBDevice': Unable to claim interface.
[2025-05-18T21:33:43.638Z] Dispositivo cerrado en limpieza
[2025-05-18T21:33:43.638Z] Prueba con interfaz 0 completada

Estoy usando Chrome en Lubuntu 22.04

Con iceram los bitstreams cargan sin problemas

Saludos

El domingo, 18 de mayo de 2025 a las 22:31:20 UTC+2, charliva escribió:

[charli va]

Buenas a los dos!,  tu programa me ha dado las claves , de echo en la versión desktop va a ir de serie, tengo que ver aún en multiplataforma pero no creo que de problemas, lo he probado solo en linux pero no creo que de problemas en compilarlo en osx o windows.

En modo web que creo que va a dar mucho juego, los dos tenéis el mismo problema y es de permisos, es buena señal, en parte me lo esperaba, así que gracias por probarlo.

Voy a intentar montar un entorno que pueda replicar el fallo para depurarlo y os aviso en cuanto esté listo, porque la gracia es que no haya que hacer nada para que funcione.

Investigo y mañana os aviso.

Gracias de nuevo!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/00171d48-7cf5-4512-bca1-bbd147d0c746n%40googlegroups.com.

[charli va]

Por recabar información, ya hoy me voy a dormir XD pero mañana intentaré montar un entorno limpio para que falle, posiblmente en mi equipo tengo configurados permisos de otras historias que me han hecho no tener problemas de inicio.

Es probable que igual que en windows hay que instalar zadig , o en linux crear una regla udev, también haya que hacerlo, lo que acabo de mirar ahora rápido parece ser que todo loque acaba usando libusb para ftdi  y parece que webusb no queda otra, investigaré de todas formas.

En cualquier caso si podeis probarlo en un chrome 10%  (que no sea chromium o derivado, es decir en windows, edge, brave,etc) sería ideal.

y si podéis entrad en chrome://flags/

y buscar webusb a ver si os aparece enabled/default pero no disabled.

Muchas gracias y que descanséis!

[charli va]

y si podeis ver si en esta url os sale algo similar a mi:

chrome://settings/content/usbDevices

[Democrito]

Carlos, instalando el driver WinUSB ha funcionado en Edge, Opera y Brave, y sin tocar los flags.

Se pone la cosa muy interesante!

Por cierto, he intercalado los bin, para asegurar que realmente funcionaba, es decir, que si en una subida metía a Kitt (kid), en el siguiente metía Blinky.

[Democrito]

Y acabo de comprobar ahora mismo que realmente se guarda en la sram (esta parte para mí es desconocida, no sé realmente qué memoria es), pero al desenchufar y volver a enchufar se carga el último proyecto personal con el que estaba.

[lmcapacho]

Hola Carlos,

Muy interesante esta característica. La verdad que si ayuda mucho para pruebas rápidas y para cuando los diseños crecen. Hice la prueba en Chrome usando Linux Ubuntu 24.04 y me aparece el mismo error:

Revisando, el problema es que el sistema operativo toma control y no permite que Chrome/WebUSB pueda tomar control de la interfaz USB. Ejecutando este comando echo -n '1-1:1.0' | sudo tee /sys/bus/usb/drivers/ftdi_sio/unbind pude liberar el USB y probar la webapp que funciona muy bien 

[charli va]

Fantástico!!!! en windows pasa como con cualquier driver FTDI que necesita el zadig,esto Demócrito tu que te defiendes mucho con eso, mira a ver, no sé si podrás probar una instalación limpia y ver si en limpio funciona (tu al final tienes el zadig ya tocado) o si hace falta instalar zadig y poner el winusb, si es lo que hay no es un drama inicialmente en windows para cualquier cosa con la ftdi habría que hacer eso, pensé que el webusb encapsularía drivers internamente porque se basa en libusb pero se ve que no.

En linux pasa más de lo mismo hay que meter unas reglas udev, quiero ver la forma de hacerlo lo más sencillo posible, a ver si puedo detectarlo y de algún modo facilitarle al usuario el paso aunque tenga que hacer algo manualmente.

Si alguno podéis hacer una prueba de ejecutar  chrome con un sudo o con el usuario root para ver si sin reglas con un usuario con permisos para todo funciona ,yo tengo mis equipos contaminados conreglas udev y todo tipo de permisos y me funciona todo sin problemas, y con vosotros al hacerlo de cero es fantásitco porque me ayuda a ver esos problemas iniciales.

Lo del udev os aviso en cuanto lo tenga par aque probéis y si podéis testear lo de ejecutar como root sólo para probar genial.

en OSX va a la primera inicialmente, aunque haré pruebas en algún osx limpio hoy o mañana.

Que tengais buen día!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/2116fd66-8d5b-49fb-985e-f3fdbf8bcea6n%40googlegroups.com.

[Democrito]

He hecho una instalación limpia como pedías y por defecto verás que Windows pone un driver llamado "usbser".

 

Y sin instalar nada con Zadig (dejando "usbser") he probado lo de subir a través de web, pero no funciona. Te dejo una imagen para que veas lo que detecta.

Pero lo dicho, lo selecciono, le doy a subir y nada.

[Democrito]

La salida que da es esta:

Pone "No device selected". Yo lo selecciono, pero algo sucede.

[charli va]

Fantástico Demócrito! con eso me vale igual te pido me grabes un vídeo para ponerlo a modo de tutorial de configurar el zadig ya te diré concretamente, para no hacerte perder tiempo.

Realmente pasa como en icestudio o con cualquier programa que use el ftdi, necesita sus drivers y el navegador no los lleva por defecto, tengo que prepararel detectar el sistema operativo y en ese evento que salta cuando el sistema operativo no le cede al navegador el control del usb sacar una ventanita con los pasos a seguir, al final es solo una vez y no nos queda otra. Quiero hacer varias pruebas y con varias tarjetas diferentes y algunas que no tienen ftdi y para programar también en la flash así veremos en cuales va solo y en cuales necesita drivers, con ftdi seguro que lo van a necesitar.

Muchísimas gracias por las molestias de hacer la instalación limpia y demás, muchas gracias!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/afa6a4b8-00b4-4def-9ae5-ade36a47f3f0n%40googlegroups.com.

[charli va]

Para linux ya lo tengo visto, o eso creo, estoy preparando una forma de añadir las reglas udev de forma sencilla, esta tarde o mañana os lo tengo para probar.

Un abrazo!

[charli va]

PAra los linuxeros, si podéis en un terminal ejecutar el comando:

lsusb

y mandarme la captura os lo agradecería (con la fpga conectada) y decirme si es una icestick o una alhambra.

Gracias!!!

[Jesus Arias]

lsusb  con ICESTICK:

...

Bus 001 Device 008: ID 0403:6010 Future Technology Devices International, Ltd FT2232C/D/H Dual UART/FIFO IC

...

Y dmesg:

[ 4144.772238] usb 1-1.2.3: new high-speed USB device number 8 using xhci_hcd
[ 4144.856587] usb 1-1.2.3: New USB device found, idVendor=0403, idProduct=6010, bcdDevice= 7.00
[ 4144.856597] usb 1-1.2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 4144.856600] usb 1-1.2.3: Product: Lattice FTUSB Interface Cable
[ 4144.856602] usb 1-1.2.3: Manufacturer: Lattice
[ 4144.901096] usbcore: registered new interface driver usbserial_generic
[ 4144.901110] usbserial: USB Serial support registered for generic
[ 4144.903308] usbcore: registered new interface driver ftdi_sio
[ 4144.903329] usbserial: USB Serial support registered for FTDI USB Serial Device
[ 4144.903461] ftdi_sio 1-1.2.3:1.0: FTDI USB Serial Device converter detected
[ 4144.903508] usb 1-1.2.3: Detected FT2232H
[ 4144.904197] usb 1-1.2.3: FTDI USB Serial Device converter now attached to ttyUSB0
[ 4144.904257] ftdi_sio 1-1.2.3:1.1: FTDI USB Serial Device converter detected
[ 4144.904315] usb 1-1.2.3: Detected FT2232H
[ 4144.904906] usb 1-1.2.3: FTDI USB Serial Device converter now attached to ttyUSB1

[charli va]

Es curioso porque en la captura que me mandasteis ayer aparece otro vendorid

Que no es el de la Alhambra.

Justo estoy viendo un tema con Eladio por los números de serie del ftdi porque ellos los modifican del estándar de ftdi y puede que esto sea parte del lío aunque de todas todas hay que darle permisos , luego os cuento cuando haga algunas pruebas y lo vaya teniendo claro 100% para no marearos.

Muchas gracias porque con él lsusb que me has mandado se corrobora mi teoría.

Buena mañana!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/929a371f-df87-4dd1-a10f-f36fda5655ban%40googlegroups.com.

[charli va]

Los Ids están todos bien difieren en el log porque los tengo puestos en decimal en vez de hexadecimal pero son los números de serie de Eladio.

Muchas gracias por las pruebas, os sigo contando!

[charli va]

Jesús por descartar cosas de tu instalación podrías ejecutar esto en la consola?, cuando puedas y sin prisas, muchas gracias!

grep -R "403" /etc/udev/rules.d/

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/929a371f-df87-4dd1-a10f-f36fda5655ban%40googlegroups.com.

[Jesus Arias]

sale esto:

/etc/udev/rules.d/70-snap.snapd.rules:ATTRS{idVendor}=="0403", ENV{ID_MM_DEVICE_MANUAL_SCAN_ONLY}="1"
/etc/udev/rules.d/70-snap.firefox.rules:SUBSYSTEM=="hidraw", KERNEL=="hidraw*", ATTRS{idVendor}=="1050", ATTRS{idProduct}=="0113|0114|0115|0116|0120|0121|0200|0402|0403|0406|0407|0410", TAG+="snap_firefox_firefox"
/etc/udev/rules.d/70-snap.firefox.rules:SUBSYSTEM=="hidraw", KERNEL=="hidraw*", ATTRS{idVendor}=="1050", ATTRS{idProduct}=="0113|0114|0115|0116|0120|0121|0200|0402|0403|0406|0407|0410", TAG+="snap_firefox_geckodriver"

[charli va]

Fenómeno! Ya tengo el mapa claro , preparando contraataque 😉

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/d4a1654b-7f6e-4754-a1c2-2e53b397cb27n%40googlegroups.com.

[charli va]

Hola Amigos! estoy alucinando del jaleo que hay montado desde hace un año y pico con los sandboxes de seguridad de las diferentes distribuciones de linux y los navegadores (paquetes snap, nix, appimage, el propio sandbox del navegador....).

Mirad a ver si podéis alguno hacer esta prueba (Jesús o Luis Miguel que os da el error en linux, pero sin presión y si no os importa, puede que no funcione):

Importante la prueba tiene que hacerse con chrome y no con chromium (hay un bug en chromium con webusb puro y no lo arreglan desde 2019).

Ejecutar los siguientes comandos:

sudo gedit /etc/udev/rules.d/80-fpga-ftdi.rules

gedit, vim o el editor que os guste, si el fichero no existe lo creará en blanco.

si existe mirad si tenéis estas reglas, si las tenéis me decís y  no hace falta que sigais, pero si no las tenéis o el archivo no existe, añadidlas:

sudo gedit /etc/udev/rules.d/80-fpga-ftdi.rules

ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6010", MODE="0666", GROUP="plugdev", TAG+="uaccess"

ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6014", MODE="0666", GROUP="plugdev", TAG+="uaccess"

ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", MODE="0666", GROUP="plugdev", TAG+="uaccess"

ATTRS{idVendor}=="1209", ATTRS{idProduct}=="5af0", MODE="0666", GROUP="plugdev", TAG+="uaccess"

ATTRS{idVendor}=="1209", ATTRS{idProduct}=="5bf0", MODE="0666", GROUP="plugdev", TAG+="uaccess"

y luego ejecutar:

sudo udevadm control --reload-rules 

sudo udevadm trigger 

sudo service udev restart 

cerrar el navegador, desconectar la alhambra y volver a encender el navegador y conectar la alhambra.

Probad ahora de nuevo la url:

https://icestudio.io/play/iceram

y ya me decís si funcionó o no, si funciona invertiré tiempo en que este setup sea muy sencillo. A mi me funciona pero como tengo el ordenador super tocado con todos los desarrollos relacionados con el usb tengo en ese sentido todas las barreras de seguridad desactivadas y me va perfectamente, ya que os ha pasado esto vamos aprovechar porque será algo común.

Muchísimas gracias como siempre.

[charli va]

He conseguido replicar el error y ya probándolo lo he solucionado en un momento.

Si tenéis chrome instalado con apt con las reglas que os he pasado arriba debería funcionar, si no os funciona, decídmelo porque se pueden mejorar.

Si tenéis instalado chrome con paquetes snap (muy típico en las últimas distribuciones de ubuntu), tenéis que meter las reglas de arriba y luego ejecutar en la consola:

snap connect chrome:raw-usb

luego ya abrís chrome y podréis usar el usb.

He probado y funciona perfectamente en chromium.

En cuanto me confirméis que funciona esta semana lo pondré bonito y le añadiré alguna feature para que el cargador tenga algo más de utilidad. y ya funcionando lo fusionaré con un programador para muchas mas tarjetas que también tengo ya funcionando online.

Muchas gracias por todo!

[lmcapacho]

Hola Carlos,

Ya tenía las reglas en el archivo: /etc/udev/rules.d/80-fpga-ftdi.rules

Sin embargo, ejecute los comandos:

sudo udevadm control --reload-rules 

sudo udevadm trigger 

sudo service udev restart 

Volví a abrir el navegador y conectar la Alhambra y no funcionó. 

Me pasó algo curioso y es que abrí Icestudio, programé otro proyecto y después de eso hice la prueba con la webapp y me dejó programar. No sé si al momento de programar con Icestudio queda listo el driver para usarlo con WebUSB. Porque después de eso todo funciona, aún con Icestudio cerrado. Si desconecto la tarjeta vuelve y toca hacer el procedimiento o ejecutar el comando que compartí ayer. 

Algo adicional, la prueba que realicé ayer programaba más rápido. No sé si se actualizó algo en esta nueva versión, porque siento más lenta la programación desde la webapp, incluso más que con Icestudio. 

[charli va]

Gracias Luis Miguel!, estoy investigando varias cosas tu hallazgo del ftdi_sio  me ha dado una buena pista porque de echo  es algo que puede fastidiar incluso a icestudio a corto plazo, son cosas que están cambiando en linux, con la llegada de rust y las nuevas tendencias de meter todo en sandboxes por temas de seguridad se van a complicar mucho las cosas. Estoy viendo la forma de si está instalado ftdi_sio, ignore a la alhambra a través de las udev y creo que lo tengo, haré algunas pruebas más.

Tenías las reglas porque icestudio las mete cuando le das a "Instalar driver", lo que no entiendo muy bien es por qué te ha funcianado después de ejecutar icestudio, me imagino que como icestudio tiene un chrome internamente, resetearon algo , pero está bien haberlo detectado.

Voy a seguir haciendo pruebas que mi idea es que si el navegador detecta que no tiene permitsos, le permita bajar al usuario un script que le configure todo sin tener que preocuparse de nada.

Ya viendo que va funcionando voy a investigar esto bien, porque además ocmo os digo en corto plazo nos va a explotar esta bomba en icestudio, así que gracias a esto nos vamos a adelantar.

La idea de esta webapp es por un lado probar la tecnología web y por otra darle un poco más de forma y añadirle incluso un terminal serie muy acotado para que valga para en un momento dado poder cargar bitstreams de forma rápida sin tener que tener nada instaldo y por otra permitir a gente que acaba de empezar y tiene su tarjeta a sin saber nada poder ejecutar demos en su nueva tarjeta, creo que es algo que puede motivar mucho.

Por otro lado en icestudio usaremos la versión nativa de Jesús ya la tengo funcionando en windows y en osx, la meteremos en apio y así será transparente su uso y tendremos la nueva opción.

Lo de que vaya lento, he tocado pequeñas cosas yando haciendo pruebas, puede que la versión de ahora sea un poco más lenta porque ando jugando con el tamaño del chunk que en la versión nativa va a toda leche con 64 bytes por chunk pero eso con webusb tardaría del orden de 15 minutos XD porque en webusb los buffers se saturan y se genera overhead, y he subido varias pruebas con diferentes tamaños y puede que haya dejado alguno no de los más rápidos. 

Os dejaré la versión buena esta semana en cuanto acote bien el problema este y así probamos una versión bien cerrada y si me da tiempo la pongo bonita, así probamos y vemos como va, en webusb hay cosas raras, latencias y temas que no puedes conctrolar pero yo croe que podemos tener un juguete muy interesante.

Buenas noches!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/6fe923b4-7a01-4595-9b7c-5cf844b2898an%40googlegroups.com.

[Jesus Arias]

Hola Carlos,

Tengo el mismo comportamiento. Si uso primero Icestudio y programo algo en la Alhambra luego ya funciona.

Saludos

[charli va]

Icestudio vacine XD

Como más o menos voy teniendo los problemas catalogados, no intentéis arreglarlo para ue prepare el script y así vemos si salimos del  atasco  y damos con la fórmula mágica, si lo conseguimos se van a poner contentos en un montón de proyectos que andan con el mismo problema XD

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/317a0f15-ece7-412a-9875-de21571cf8bdn%40googlegroups.com.

[charli va]

Buenas tardes a todos! a ver si me podéis confirmar lo siguiente, estamos muy cerca de tener la fórmula, esto puede abrir muchas puertas.

Importante reiniciar el ordenador para que no haya rastros de haber ejecutado icestudio, una vez reiniciado y partir de un punto limipio (sin dar de baja el driver ftdi ni nada), editar vuestro fichero de udev rules que hablamos anteriormente, el /etc/udev/rules.d/80-fpga-ftdi.rules

Sustituir lo que os pasé anteriormente por:

SUBSYSTEM=="usb",ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6010", MODE="0777", GROUP="plugdev", TAG+="uaccess",RUN+="/bin/sh -c 'echo -n %k > /sys/bus/usb/drivers/ftdi_sio/unbind'"
SUBSYSTEM=="usb",ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6014", MODE="0777", GROUP="plugdev", TAG+="uaccess",RUN+="/bin/sh -c 'echo -n %k > /sys/bus/usb/drivers/ftdi_sio/unbind'"
SUBSYSTEM=="usb",ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", MODE="0777", GROUP="plugdev", TAG+="uaccess",RUN+="/bin/sh -c 'echo -n %k > /sys/bus/usb/drivers/ftdi_sio/unbind'"
SUBSYSTEM=="usb",ATTRS{idVendor}=="1209", ATTRS{idProduct}=="5af0", MODE="0777", GROUP="plugdev", TAG+="uaccess",RUN+="/bin/sh -c 'echo -n %k > /sys/bus/usb/drivers/ftdi_sio/unbind'"
SUBSYSTEM=="usb",ATTRS{idVendor}=="1209", ATTRS{idProduct}=="5bf0", MODE="0777", GROUP="plugdev", TAG+="uaccess",RUN+="/bin/sh -c 'echo -n %k > /sys/bus/usb/drivers/ftdi_sio/unbind'"

tras guardar ejecutar los dos comandos siguientes:

udevadm control --reload-rules
udevadm trigger

Reconectar la tarjeta.

Si no funcionara, haced el comando:

which chrome

ó 

which chromium

dependiendo de cual ejecutéis

mirad si el path está dentro de snap, por ejemplo en mi caso /snap/bin/chromium

Si estáis dentro del sandbox snap, teneis que ejecutar (esto sería sólo una vez)

snap connect chromium:raw-usb

ó

snap connect chrome:raw-usb

si habéis ejecutado esto último porque estuvierais en snap , tenéis que reiniciar el navegador.

en algunas distribuciones chrome es chrome-browser

Muchas gracias por estas pruebas tediosas, sois la leche! ;)

Saludos!

[lmcapacho]

Hola Carlos,

Realicé los cambios en el archivo de reglas de udev con las líneas que compartiste, y reinicié el computador para asegurarme de que la prueba no funcionara simplemente por haber estado trabajando previamente con Icestudio. Todo funcionó muy bien. Incluso volví a notar la velocidad de la primera prueba al cargar. Al final se demora un poco (no mucho) después de que empieza: Verificando CDONE final...

Que buen trabajo!!

[charli va]

Me alegro!!! al final encontramos el combo :)

El tema de la latencia con el webusb es normal, os cuento por encima, quiero hacer un documento con todo esto porque puede ser muy interesante.

el tema es que cuando hacemos un programa nativo como iceram que habla con el usb , lo hace directamente y como quien dice no hay controles, es algo que está en la base del sistema y tiene acceso a todo.

Por ejemplo el código de Jesús maneja bloques de 64bytes y va volado porque como literlamente en cuanto abre el dispositivo está el código de iceram y el ftdi no hay intermediarios pero en el caso webusb tengo que cambiar el tamaño de los bloques porque al haber muchos paquetes el canal se satura con las validaciones por parte del navegador., posiblemente se pueda afinar aún más probando con otros tamaño de paquetes y midiendo, pero bueno es un gran punto de partida.

En webusb tenemos una pila de  "persojanes", son todo como aduanas, cada una te pide unos papeles diferentes XD y todo lo que se manda pasa por toda esa pila de validadores, así que las cosas no funcionan directamente aunque queramos hablar con el ftdi , nuestra aplicación tiene que pasar por todo el "papeleo" así que hay momentos al abrir/cerrar que pueden genrar retardos o incluso lo cargado que tengas el navegador, al final no deja de ser un api del navegador que en sí es como un sistema operativo dentro del sistema operativo real.

En fin que muchísimas gracias por validarlo, ahora sabiendo que funciona voy a poner bonito esto y que te permita ejecutar un script fácilmente en el terminal que te configure todo.

También os pasaré los binarios nativos para todas las plataformas, ando con algunos problemas para compilar en osx, en cuanto lo tenga os lo paso todo.

Buenas noches amigos!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/9699234a-87e6-4083-a455-2bada6ac674en%40googlegroups.com.