Tema: Mods firms para cubos basados en chips realtek

A ver si este finde con paciencia pruebo (y documento bien) todas las opciones.

Otra cosa que voy a probar es a cambiar el HDD. Compré un WD de 1TB para el ordenador y moví el SAMSUNG 2TB del ordenador al cubo. Es un coñazo, pero volveré a volcar toda la info al de 2TB y probaré el cubo con el WD, a ver si va a ser eso (aunque me extraña que el SAMSUNG funcione a veces si, y a veces no).

Y otra cosa que me planteo investigar es frikear y montarle un linux nuevecito, incluyendo un kernel actualizado, un xorg como servidor gráfico y un mplayer sustituyendo al Dvdplayer (pero vamos, eso es trabajo para un equipo experto y durante meses, así que solo frikear, no tratar de conseguir nada... me conformo si consigo ver el fondo y el cursor de xorg).

Te mantendré al tanto.

Saludos.

Iniciado por lamberete

Y otra cosa que me planteo investigar es frikear y montarle un linux nuevecito, incluyendo un kernel actualizado, un xorg como servidor gráfico y un mplayer sustituyendo al Dvdplayer (pero vamos, eso es trabajo para un equipo experto y durante meses, así que solo frikear, no tratar de conseguir nada... me conformo si consigo ver el fondo y el cursor de xorg).

Te mantendré al tanto.

Saludos.

Soy todo orejas, para mi seria genial.

Suerte.

Bueno pues ya dispongo de "parted" para el 3000.

Gracias a optware http://ipkg.nslu2-linux.org/feeds/optware/oleg/cross/

Creo que ya se ha comentado alguna vez cientos de aplicaciones para nuestro cubos con chip RTD ya compiladas, instalar y listo (eso si, la mayoria para usar desde la linea de comandos por telnet)

A lo que iba, faltaba informacion de parted. Resultados del icube 5000 con el firm v8.5.55.r7672-120416 + IMS 5.2:

Código:

~ # parted /dev/scsi/host0/bus0/target0/lun0/disc print free
Model: ATA Hitachi HDS5C101 (scsi)
Disk /dev/scsi/host0/bus0/target0/lun0/disc: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
        32.3kB  8225kB  8193kB           Free Space
 1      8225kB  983GB   982GB   primary
 2      983GB   983GB   165MB   primary
 3      983GB   983GB   165MB   primary
 4      983GB   1000GB  17.2GB  primary
        1000GB  1000GB  167MB            Free Space

Como ves hay espacio libre al principio y al final del HDD

Y ahora el del 3000 que es SDK3:

Código:

root@HMB:~# parted
GNU Parted 1.7.1
Using /dev/scsi/host1/bus0/target0/lun0/disc
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print free

Disk /dev/scsi/host1/bus0/target0/lun0/disc: 1500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
        32.3kB  8225kB  8193kB           Free Space
 1      8225kB  1482GB  1482GB  primary  ntfs
 2      1482GB  1482GB  165MB   primary  linux-swap
 3      1482GB  1483GB  559MB   primary  ext3
 4      1483GB  1500GB  17.2GB  primary
        1500GB  1500GB  165MB            Free Space

(parted)

Como ves el espacio libre es el mismo independientemente del tamaño del HDD y del SDK imagino que al princio del HDD estara el MBR o similar, ¿Pero al final? en fin ni idea, es por dar mas informacion.

Y si, la version de parted que hay para descarga es mas antigua que la de los SDK4.

En el 3800 tengo la version de fabrica del 3850, asi que ni siquiera hay acceso por telnet, si no se hace un modfirm. :-(, asi que no tengo los datos del HDD, eso si recuerdo que la particion swap era mas pequeña que en el 5000.

Iniciado por lamberete

Y otra cosa que me planteo investigar es frikear y montarle un linux nuevecito, incluyendo un kernel actualizado, un xorg como servidor gráfico y un mplayer sustituyendo al Dvdplayer (pero vamos, eso es trabajo para un equipo experto y durante meses, así que solo frikear, no tratar de conseguir nada... me conformo si consigo ver el fondo y el cursor de xorg).

Me gustaría creer que sabes lo que dices, pero me da la impresión de que simplemente ha sido una afirmación demasiado osada...

¿Vas a portar tú el kernel actualizado para los procesadores RTD1283? Porque el linux que existe para estos procesadores es el mismo. Creo que alguien empezó a portar uno más moderno, pero no tengo noticias de que lo terminara y las únicas versiones modernas son para los 1186. Lo mismo con el XORG ¿Vas a crear tú el driver para el vídeo? ¿Conoces cómo funciona el hardware de vídeo? Porque en los firmwares oficiales NO HAY DRIVERS DE VÍDEO y es DvdPlayer el que accede al hardware bien directamente o usando el firmware de vídeo del que no hay información disponible.

En cualquier caso, te deseo mucha suerte...

Saludos.

Iniciado por calimocho

Me gustaría creer que sabes lo que dices, pero me da la impresión de que simplemente ha sido una afirmación demasiado osada...

¿Vas a portar tú el kernel actualizado para los procesadores RTD1283? Porque el linux que existe para estos procesadores es el mismo. Creo que alguien empezó a portar uno más moderno, pero no tengo noticias de que lo terminara y las únicas versiones modernas son para los 1186. Lo mismo con el XORG ¿Vas a crear tú el driver para el vídeo? ¿Conoces cómo funciona el hardware de vídeo? Porque en los firmwares oficiales NO HAY DRIVERS DE VÍDEO y es DvdPlayer el que accede al hardware bien directamente o usando el firmware de vídeo del que no hay información disponible.

En cualquier caso, te deseo mucha suerte...

Saludos.

Pues eso es precisamente lo que quería explorar, y eso es precisamente lo que me he encontrado. Hace muchos años participé en el desarrollo software de un equipo con algunas similitudes, y de ahí mi idea de montarle Xorg al cubo, pero claro, disponíamos de los drivers de la salida de vídeo. Al cubo se le podría poner un nuevo kernel, pero, tal y como dices, no hay salida de vídeo "estándar" disponible, así que no valdría de nada, y no queda más remedio que pasar por el aro del DvdPlayer, cuyos firmwares están compilados para el Kernel 2.6.12, y para que se puedan usar hay que quedarse en ese mismo. Ya no se si sería posible es recompilar ese kernel con otras opciones (y ahora os cuento por qué me lo planteo), o cargar algún módulo más (para que funcionen más wifis-usb, por ejemplo), pero bueno...

A mi problema (que ha sido básicamente mi finde):
- No era un problema con la versión de firmware, sino con el disco duro. Una vez instalado el WD de 1TB el disco es detectado consistentemente, el formateo apenas dura un par de minutos, y funcionan bien todos los firmwares (woxter o inves)
- Ya centrado en el problema, y tras muchas pruebas, mucho examinar el log de dmesg.... acabé por centrarme en el módulo sata_mars y fui a dar con este post de un foro de otro cubo de realtek. Parece ser que algunos discos necesitan más tiempo para arrancar y los 7 ¿segundos? que deja nuestro cubo (según "cat /sys/block/sda/device/timeout" vía telnet) no son suficientes para mi SAMSUNG de 2TB (de hecho, el valor cuando lo monto en mi PC es de 30). A partir de ahí me he puesto como loco a intentar modificar dicho parámetro, pero no encuentro el script (o punto del arranque del sistema) donde aplicarlo; he probado a forzar el uso de los módulos sata_mars_1.ko y libata_1.ko; he probado a usar la versión de esos módulos de otros cubos.... tampoco ha habido suerte; otras soluciones más sofisticadas que he encontrado por internet no son válidas para un linux tan simplificado como el del cubo; y cosas que ya no recuerdo....

De todos modos no tiro la toalla... dejaré que se me enfríe la cabeza y volveré a retomarlo en unos días, porque de verdad que prefiero pasar el disco de 2TB al cubo. Espero que baste con modificar el script apropiado, o como mucho recompilar algún módulo y que no toque recompilar el kernel (porque encontrar las opciones que lo hagan "compatible" con el DvdPlayer puede ser telita....)

Bueno, espero que esto al menos valga para que si a alguien le pasa algo similar, no de (ni os haga dar) tantas vueltas.

Un saludo a todos.

PD: Creo que me quedo con la interfaz nueva (la de chucky de abril). Entiendo por lo que me dijo Chucky que está incompleta, así que si puedo echar un cable en el progreso, no dudéis en avisarme, Que es lo menos que puedo hacer después de el follón que os he dado.

Iniciado por lamberete

Pues eso es precisamente lo que quería explorar, y eso es precisamente lo que me he encontrado. Hace muchos años participé en el desarrollo software de un equipo con algunas similitudes, y de ahí mi idea de montarle Xorg al cubo, pero claro, disponíamos de los drivers de la salida de vídeo. Al cubo se le podría poner un nuevo kernel, pero, tal y como dices, no hay salida de vídeo "estándar" disponible, así que no valdría de nada, y no queda más remedio que pasar por el aro del DvdPlayer, cuyos firmwares están compilados para el Kernel 2.6.12, y para que se puedan usar hay que quedarse en ese mismo. Ya no se si sería posible es recompilar ese kernel con otras opciones (y ahora os cuento por qué me lo planteo), o cargar algún módulo más (para que funcionen más wifis-usb, por ejemplo), pero bueno...

A mi problema (que ha sido básicamente mi finde):
- No era un problema con la versión de firmware, sino con el disco duro. Una vez instalado el WD de 1TB el disco es detectado consistentemente, el formateo apenas dura un par de minutos, y funcionan bien todos los firmwares (woxter o inves)
- Ya centrado en el problema, y tras muchas pruebas, mucho examinar el log de dmesg.... acabé por centrarme en el módulo sata_mars y fui a dar con este post de un foro de otro cubo de realtek. Parece ser que algunos discos necesitan más tiempo para arrancar y los 7 ¿segundos? que deja nuestro cubo (según "cat /sys/block/sda/device/timeout" vía telnet) no son suficientes para mi SAMSUNG de 2TB (de hecho, el valor cuando lo monto en mi PC es de 30). A partir de ahí me he puesto como loco a intentar modificar dicho parámetro, pero no encuentro el script (o punto del arranque del sistema) donde aplicarlo; he probado a forzar el uso de los módulos sata_mars_1.ko y libata_1.ko; he probado a usar la versión de esos módulos de otros cubos.... tampoco ha habido suerte; otras soluciones más sofisticadas que he encontrado por internet no son válidas para un linux tan simplificado como el del cubo; y cosas que ya no recuerdo....

De todos modos no tiro la toalla... dejaré que se me enfríe la cabeza y volveré a retomarlo en unos días, porque de verdad que prefiero pasar el disco de 2TB al cubo. Espero que baste con modificar el script apropiado, o como mucho recompilar algún módulo y que no toque recompilar el kernel (porque encontrar las opciones que lo hagan "compatible" con el DvdPlayer puede ser telita....)

Bueno, espero que esto al menos valga para que si a alguien le pasa algo similar, no de (ni os haga dar) tantas vueltas.

Un saludo a todos.

PD: Creo que me quedo con la interfaz nueva (la de chucky de abril). Entiendo por lo que me dijo Chucky que está incompleta, así que si puedo echar un cable en el progreso, no dudéis en avisarme, Que es lo menos que puedo hacer después de el follón que os he dado.

Creo es que tu problema (Y digo creo, me parece que tus conocimientos al respecto de linux son muy superiores a los mios) es que el disco desde que recibe corriente, hasta que esta disponible, pasa un tiempo excesivo, y mi solucion quizas sea una perugrullada:

¿Retrasar el arranque del cubo completo?, si, se que tendras que esperar 30 segundos mas en el arranque, pero no se me ocurre otra cosa.

El primer archivo que se ejecuta es /usr/local/bin/rcS, y luego ya se pasa a /etc/int.d/rcS, donde tienes tambien el scrip de montaje de las particiones. No sabria decirte donde, pero añadiendo en cualquiera de los script "sleep 30", podrias retrasar o bien el proceso de arranque completo o bien el montaje de las unidades. echale un ojo, y decide tu mismo.

El montar wifis de otras marcas es posible si tienes los drivers compilados, al menos que yo sepa hay firms SDK3 con drivers para los wifi ralink. y no es necesario recompilar el kernel. Mira aqui en un perfecto ruso: http://tty.org.ru/node/34 ;-)

En cuanto a la interfaz, el problema es que yo no me estoy dedicando a modificarla. para que te hagas una idea, hay que modificar todas las imagenes que hay en /usr/local/bin/Resource, + la de las carpetas de los menus de configuracion, vamos trabajo de chinos.

Iniciado por lamberete

Pues eso es precisamente lo que quería explorar, y eso es precisamente lo que me he encontrado. Hace muchos años participé en el desarrollo software de un equipo con algunas similitudes, y de ahí mi idea de montarle Xorg al cubo, pero claro, disponíamos de los drivers de la salida de vídeo. Al cubo se le podría poner un nuevo kernel, pero, tal y como dices, no hay salida de vídeo "estándar" disponible, así que no valdría de nada, y no queda más remedio que pasar por el aro del DvdPlayer, cuyos firmwares están compilados para el Kernel 2.6.12, y para que se puedan usar hay que quedarse en ese mismo. Ya no se si sería posible es recompilar ese kernel con otras opciones (y ahora os cuento por qué me lo planteo), o cargar algún módulo más (para que funcionen más wifis-usb, por ejemplo), pero bueno...

A mi problema (que ha sido básicamente mi finde):
- No era un problema con la versión de firmware, sino con el disco duro. Una vez instalado el WD de 1TB el disco es detectado consistentemente, el formateo apenas dura un par de minutos, y funcionan bien todos los firmwares (woxter o inves)
- Ya centrado en el problema, y tras muchas pruebas, mucho examinar el log de dmesg.... acabé por centrarme en el módulo sata_mars y fui a dar con este post de un foro de otro cubo de realtek. Parece ser que algunos discos necesitan más tiempo para arrancar y los 7 ¿segundos? que deja nuestro cubo (según "cat /sys/block/sda/device/timeout" vía telnet) no son suficientes para mi SAMSUNG de 2TB (de hecho, el valor cuando lo monto en mi PC es de 30). A partir de ahí me he puesto como loco a intentar modificar dicho parámetro, pero no encuentro el script (o punto del arranque del sistema) donde aplicarlo; he probado a forzar el uso de los módulos sata_mars_1.ko y libata_1.ko; he probado a usar la versión de esos módulos de otros cubos.... tampoco ha habido suerte; otras soluciones más sofisticadas que he encontrado por internet no son válidas para un linux tan simplificado como el del cubo; y cosas que ya no recuerdo....

De todos modos no tiro la toalla... dejaré que se me enfríe la cabeza y volveré a retomarlo en unos días, porque de verdad que prefiero pasar el disco de 2TB al cubo. Espero que baste con modificar el script apropiado, o como mucho recompilar algún módulo y que no toque recompilar el kernel (porque encontrar las opciones que lo hagan "compatible" con el DvdPlayer puede ser telita....)

Bueno, espero que esto al menos valga para que si a alguien le pasa algo similar, no de (ni os haga dar) tantas vueltas.

Un saludo a todos.

PD: Creo que me quedo con la interfaz nueva (la de chucky de abril). Entiendo por lo que me dijo Chucky que está incompleta, así que si puedo echar un cable en el progreso, no dudéis en avisarme, Que es lo menos que puedo hacer después de el follón que os he dado.

Se pueden compilar/cargar nuevos módulos sin excesivos problemas.

El primer script que se ejecuta es el localizado en /etc/init.d/rcS que lo único que hace es ejecutar /etc/init.d/rcS1 enviando su salida a la consola para que se pueda ver si tienes el reproductor conectado al PC con el correspondiente cable serie. La pega es que esos scripts están en un sistema de archivos de solo lectura, con lo que tienes que crear un nuevo firmware con los ficheros modificados. Sin embargo, tienes el script /usr/local/etc/rcS que se ejecuta desde /etc/init.d/rcS1 y que es modificable. Además, es ahí donde se cargan los drivers sata y se ejecuta DvdPlayer que es el que monta las particiones. Así pues, podrías añadir líneas del tipo echo '30' > /sys/block/sdX/device/timeout a /usr/local/etc/rcS y ver si con ello resolvías tu problema (he puesto sdX porque no sólo lo deberías hacer con sda, ya que si arrancas el reproductor con un pendrive conectado lo más probable es que el disco duro interno pase a ser sdb).

Saludos.