Fuente del módulo IOS del bakuploader liberado

El ISO Loader esta mas cerca de lo que nos imaginamos peña. Gracias por la info tronko. Saludos

Muchas gracias por la info nuvalo.
A proposito y ya que mencionas es gc-linux, como van tus instentos de ponerle colores y todo eso? Ya lo conseguiste? O aun sigues en ello?

Fumadikto escribió:El ISO Loader esta mas cerca de lo que nos imaginamos peña. Gracias por la info tronko. Saludos

Te lo dicen los astros???    Porque si el usb sigue siendo 1.1.....

darkspeed escribió:

Fumadikto escribió:El ISO Loader esta mas cerca de lo que nos imaginamos peña. Gracias por la info tronko. Saludos

Te lo dicen los astros??? Porque si el usb sigue siendo 1.1.....

De hecho, ya se pueden cargar ISOs desde el Linux, lo que no se es con que comando porque yo de momento soy de güindows xD

oOoPoZaSoOo escribió:

darkspeed escribió:

Fumadikto escribió:El ISO Loader esta mas cerca de lo que nos imaginamos peña. Gracias por la info tronko. Saludos

Te lo dicen los astros??? Porque si el usb sigue siendo 1.1.....

De hecho, ya se pueden cargar ISOs desde el Linux, lo que no se es con que comando porque yo de momento soy de güindows xD

Para montar ISOs normales: mount -t iso9660 "imagen" "punto montaje" -o loop
Para montar ISOs de Wii, no hay nada como el Wiifuse: ./wiifuse "imagen" "punto montaje"

De hecho, ya se pueden cargar ISOs desde el Linux, lo que no se es con que comando porque yo de momento soy de güindows xD

tio, una cosa es montar y otra cosa cargar


saludos...

Gran noticia para los curiosos como yo

viva la GPL!

-

nuvalo escribió:

A proposito y ya que mencionas es gc-linux, como van tus instentos de ponerle colores y todo eso? Ya lo conseguiste? O aun sigues en ello?

Pues sigue igual que la última vez que colgué el video. No he tenido tiempo de mejorar el driver de las X, así que se siguen quedando sombras en el background. Por lo demás funciona más o menos bien, las aplicaciones que usan la pantalla completa van bastante bien. De momento estaba acondicionandolo todo para una primera release, a la espera que rene (el jefe de t2-sde) lo pruebe y de el visto bueno.

POdís ver algo más de información aquí:

http://www.t2-project.org/hardware/cons ... tendo/Wii/

A ver que sale de todo esto, que ganas de catarlo

nuvalo escribió:
POdís ver algo más de información aquí:

http://www.t2-project.org/hardware/cons ... tendo/Wii/

Una pregunta, ahora mismo el linux está usando como memoria base los 24 Megas de memoria principal y los otros 52 (bueno en esa página pone 64) como swap. ¿No habría forma de usar los 24+52 como memoria principal y usar una partición de la sd como swap?

A mi intentando compilar ciertas cosas se me queda frito hasta que da un error de memoria... no se si por esa vía se podría arreglar algo.

Muchas gracias

-

Lo de la mem2 es un mito. No se puede usar para datos o código del programa cargados directamente desde el DOL, porque ese área la está usando el loader (al igual que mem1 por encima de 0x81330000), pero se puede usar para lo que quieras una vez se está ejecutando tu programa. De hecho, el Twilight Hack se ejecuta desde MEM2.

Los mantenedores de libogc son unos cabezotas y unos vagos, y no quieren aceptar mi parche para que se pueda usar MEM2 directamente con malloc(). En nuestro fork git si se puede, pero es 100% compatible hacia atras porque si no la usas (si tus malloc() no llegan a llenar mem1), puedes administrarla como quieras normalmente. Lo normal si quieres hacerlo a mano es usar OSGetArena2Lo y OSSetArena2Lo para obtener la dirección base libre, tomar eso como la base para tus datos, sumarle el tamaño, y reasignarlo como base para que otros la usen. Obviamente esto es una operación permanente, ya que no puedes volver a liberar ese trozo de memoria si has obtenido otro mas adelante. El parche que tiene la libogc git hace que el malloc de C, via sbrk, pase a MEM2 en cuanto tenga un alloc que no le cabe en MEM1.

La unica pega es que el espacio libre en MEM1, una vez intentar obtener memoria que no cabe en MEM1, queda inutilizado. Esto es por una limitación de la implementación malloc de newlib. Pero si liberas memoria en mem1, esta si queda disponible - la que se pierde es la que NUNCA se ha usado en mem1, cuando se pasa a mem2.

Por cierto, manejar MEM2 a mano (sin OSGetArena2Lo) es pedir a gritos que las cosas peten. MEM2 SI se usa por defecto, entre otras cosas para buferes IPC y para temas de Bluetooth. Otra cosa es que no se use la mayoría. Lo normal en juegos es usar OSGet/SetArena2Lo (y Hi, si quieres, que funciona igual pero a la inversa, desde arriba) para obtener trozos grandes de memoria, y luego montar un sistema de alloc/free interno en cada bloque (lwp en libogc tiene un allocator generico para eso, y el SDK de nintendo tiene una lib entera de sistemas de alloc), optimizando según el tipo de datos. Así se evita la fragmentación y puedes poner los datos de acceso mas rápido en MEM1. Pero a no ser que estés haciendo algo que consuma tanta memoria que te suponga un problema la fragmentación, o que necesites optimizar la velocidad de alloc/free/acceso, en casos de homebrew normal, se puede usar MEM2 tal cual, con nuestro fork de libogc en git y malloc() de toda la vida.

Usar MEM2 como swap en wiilinux es una bobada. Eso estaba muy bien en Gamecube donde MEM2 era ARAM y esa sí que no era unificada y no se podía usar directamente para casi nada (había que hacer DMA). En la Wii la unica diferencia practica entre MEM1 y MEM2 es que MEM2 es algo mas lenta, así que lo lógico es ponerla a disposición de las aplicaciones como mas memoria. Linux se encargará de mapear las tablas y obtener páginas de la zona mas conveniente, y las aplicaciones verán memoria contigua. Para algo es un sistema operativo con memoria virtual. Lo único que tienes que hacer es definirle a Linux dos zonas no contiguas de RAM.

Muchas gracias por la explicación marcan, ahora entiendo porque hermes me dijo que usará el git para compilar su juego.
Ya que el git lo manteneis vosotros, podríais actualizar el usbstorage.c para que use 4kb de buffer y se alcanze mas velocidad, aparte de añadir el bug de liberar memoria en el USBStorage_Close, se lo podías pedir a sven y así cada vez que actualizo el git no tengo que acordarme de sustituirlo, es que soy muy perro

Ya se que sólo se pedir pero tambien sería buena idea que hicieseis un git de la libfat con los parches de sven para la cache y el usb, ya que no los pasan al cvs ni a tiros, chism solo pone los parches que le paso si son pequeños y obvios.

Saludos

work

Yo también conseguí cargar las X. Costo y tenia colores raros, pero lo conseguí despues, por algún extraño motivo el invento dejo de funcionar

capitanquartz escribió:Yo también conseguí cargar las X. Costo y tenia colores raros, pero lo conseguí despues, por algún extraño motivo el invento dejo de funcionar

joder todo un hito, ivan bien? xD

joee que bueno entonces alguien seguira haciendo el Backuploader o no??

nuvalo escribió: ¿que cosas estás intentando compilar?

El xbmc para linux sin opengl, pero sólo por probar que ya se que aunque vaya irá como el culo que es un bicho de aplicación.
Conseguí resolver todas las dependencias que faltan en el repositorio de etch añadiendo los sources de http://www.debian-multimedia.org/ (básicamente ffmpeg). Ejecuta sin problema el ./configure (tardando un huevo eso sí) y a la hora de compilar va compilando, pero llega a un punto que se queda frito y da error de memoria.

Otra cosa es que tire después de compilarlo , aunque en la página aseguran que debería de ir en una máquina similar a la xbox...

A tomar por culo. No se debería haber liberado el backup loader y ahora encima resulta que se van a poner a estudiarlo y liberarlo, y además ya es pública la Fuente del módulo IOS. Además de que con la fuente Nintendo se lo puede cargar, nos estamoa cargando a Nintendo con el Backup loader.

La liberación de la fuente tiene ventajas e inconvenientes:

Ventajas:

Nintendo se lo va a cargar y Nintendo no morirá (YUJU!!!)

Desventajas:

Ahora tendremos una lucha con el puñetero backup loader...

marcansoft escribió:Usar MEM2 como swap en wiilinux es una bobada. Eso estaba muy bien en Gamecube donde MEM2 era ARAM y esa sí que no era unificada y no se podía usar directamente para casi nada (había que hacer DMA). En la Wii la unica diferencia practica entre MEM1 y MEM2 es que MEM2 es algo mas lenta, así que lo lógico es ponerla a disposición de las aplicaciones como mas memoria. Linux se encargará de mapear las tablas y obtener páginas de la zona mas conveniente, y las aplicaciones verán memoria contigua. Para algo es un sistema operativo con memoria virtual. Lo único que tienes que hacer es definirle a Linux dos zonas no contiguas de RAM.

No tan rápido, que nos la pegamos...
Quizás primero haya que añadir soporte para memoria discontinua en ARCH=powerpc 32 bits... (sólo está soportado para powerpc 64 bits en Linux)

Lo de usar MEM2 como dispositivo de bloque se hizo para poder aprovechar de manera inmediata, aunque fuese como swap, esa memoria en Linux, sin tener que esperar a hacer modificaciones mayores en el código genérico de la arquitectura. Bobada, bobada, visto con la perspectiva correcta, no lo es.

~/isobel

isobel escribió:No tan rápido, que nos la pegamos...
Quizás primero haya que añadir soporte para memoria discontinua en ARCH=powerpc 32 bits... (sólo está soportado para powerpc 64 bits en Linux)

Interesante. Me imaginaba que Linux soportaría este tipo de cosas en todas las arquitecturas (con MMU, claro) a día de hoy.

En cualquier caso, la solución correcta (definir varios rangos de memoria independientes) dudo que sea muy complicada, sobre todo teniendo en cuenta que este no es el caso típico de memoria discontinua por pasar la barrera de los 4GB (32 bits), con todo que eso conlleva. La Wii sigue siendo una arquitectura PPC normal, solo que hay dos áreas de memoria. La mayor complicación de la memoria discontinua probablemente sea la obtención de esa información desde el bootloader, cosa que no existe en la Wii. Mirando la init de la arch ppc, me he encontrado con esto en arch/ppc/mm/init.c:

Puede que empezar por definir un segundo rango de memoria al principio, en phys_avail, sea un buen comienzo

isobel escribió:Lo de usar MEM2 como dispositivo de bloque se hizo para poder aprovechar de manera inmediata, aunque fuese como swap, esa memoria en Linux, sin tener que esperar a hacer modificaciones mayores en el código genérico de la arquitectura. Bobada, bobada, visto con la perspectiva correcta, no lo es.

Llamémoslo cutreatajo temporal a la espera de la solución correcta entonces

marcansoft escribió:

isobel escribió:No tan rápido, que nos la pegamos...
Quizás primero haya que añadir soporte para memoria discontinua en ARCH=powerpc 32 bits... (sólo está soportado para powerpc 64 bits en Linux)

Interesante. Me imaginaba que Linux soportaría este tipo de cosas en todas las arquitecturas (con MMU, claro) a día de hoy.

Pues imaginabas mal, todavía hay sus peros en la letra pequeña, y no tiene que ver con la disponibilidad de MMU.

marcansoft escribió:En cualquier caso, la solución correcta (definir varios rangos de memoria independientes) dudo que sea muy complicada, sobre todo teniendo en cuenta que este no es el caso típico de memoria discontinua por pasar la barrera de los 4GB (32 bits), con todo que eso conlleva. La Wii sigue siendo una arquitectura PPC normal, solo que hay dos áreas de memoria. La mayor complicación de la memoria discontinua probablemente sea la obtención de esa información desde el bootloader, cosa que no existe en la Wii.

Que no insistas que te la pegas...
Definir los rangos en el bootloader es trivial. Basta con añadirlos al device tree. Pero como he dicho ese no es el problema.

marcansoft escribió: Mirando la init de la arch ppc, me he encontrado con esto en arch/ppc/mm/init.c:
...

Puede que empezar por definir un segundo rango de memoria al principio, en phys_avail, sea un buen comienzo

Y dale...
En primer lugar, obviamente ese no es el único cambio necesario sino ya estaría hecho... Y en segundo lugar, ARCH=ppc muere en 2.6.27 o sea que si quieres aportar algo de verdad mira en ARCH=powerpc.

marcansoft escribió:

isobel escribió:Lo de usar MEM2 como dispositivo de bloque se hizo para poder aprovechar de manera inmediata, aunque fuese como swap, esa memoria en Linux, sin tener que esperar a hacer modificaciones mayores en el código genérico de la arquitectura. Bobada, bobada, visto con la perspectiva correcta, no lo es.

Llamémoslo cutreatajo temporal a la espera de la solución correcta entonces

Venga, llamémosle así. Ala.

~/isobel

-

No estoy crosscompilando... yo a lo gañán . De todas formas vi por ahí que crosscompilar el python (el xbmc lo utiliza) da bastantes problemas. A ver si esta semana salgo algún día a una hora decente del curro y pruebo .

Muchas gracias!

-

nuvalo escribió:

Creo que lo "integra" en algunas librerias del xbmc (utiliza python-dev), pero no me hagas mucho caso. De todas formas en cuanto tenga tiempo libre pruebo a compilar desde el pc.

Otra cosa que no tiene que ver con el tema... ¿algún enlace para obtener Xsdl? es que no lo doy encontrado por ningún lado, no se si habría que compilarlo o si hay algún repositorio para poder obtenerlo por apt. Si no esperaré a tú release (a todo esto muchas gracias por todo el curro).

-

isobel escribió:Que no insistas que te la pegas...

Me pregunto por qué te preocupa tanto que intente aportar alguna idea. Si me equivoco, me corriges, pero me sorprende que intentes disuadirme de hacerlo en primer lugar.

marcansoft escribió:Y dale...

No se por qué me da la impresión de que, o te parezco demasiado inutil como para entender esto y por lo tanto evitas dar una explicación real, o simplemente no quieres realizar este cambio, sea dificil o no.

marcansoft escribió:Y en segundo lugar, ARCH=ppc muere en 2.6.27 o sea que si quieres aportar algo de verdad mira en ARCH=powerpc.

Gracias por el dato (me extrañaba lo de las dos arquitecturas para PPC).

En cualquier caso, no uso Wiilinux, así que no me preocupa lo suficiente como para ponerme a investigar que es lo que lo hace tan dificil. Y dado que tu al parecer lo sabes pero no me lo quieres decir, pues ahi queda la cosa.

marcansoft escribió:Me pregunto por qué te preocupa tanto que intente aportar alguna idea. Si me equivoco, me corriges, pero me sorprende que intentes disuadirme de hacerlo en primer lugar.

...

No se por qué me da la impresión de que, o te parezco demasiado inutil como para entender esto y por lo tanto evitas dar una explicación real, o simplemente no quieres realizar este cambio, sea dificil o no.

...

En cualquier caso, no uso Wiilinux, así que no me preocupa lo suficiente como para ponerme a investigar que es lo que lo hace tan dificil. Y dado que tu al parecer lo sabes pero no me lo quieres decir, pues ahi queda la cosa.

No intento disuadirte, y si eso es lo que parece no es lo que pretendo. Y en absoluto me parece que seas un inútil.
<rant>
Pero has empezado haciendo una crítica a una decisión (usar mem2 como block device) tachándola de bobada sin tener mínimamente una idea del por qué. Y luego has trivializado el problema de usar mem2 como memoria normal en el kernel de Linux citando un trozo de código y proponiendo un cambio parcial. Eso sinceramente no es serio, así que no pretendas que la discusión sea seria.
</rant>
Pero gracias de todas maneras.

En el código de gestión de memoria de 32 bits de la arquitectura powerpc para Linux hay varias partes que simplemente asumen que la memoria real está físicamente contigua. Yo no digo que sea difícil cambiar esas partes, dispersas en varios lugares.
Si nadie lo ha hecho antes no es por que técnicamente sea complejo, aunque no es trivial como tú lo planteas: requiere un mínimo análisis serio.
Yo creo que nadie, y me incluyo, lo ha hecho todavía porque no ha tenido la motivación o porque simplemente ha dedicado su tiempo a otras cosas (y nadie me refiero a _nadie_, recuerda que esa parte es genérica del kernel de Linux y no tiene nada que ver con nuestras queridas videoconsolas).

Si alguien quiere aportar una solución real (léase parche) a este problema siempre es bienvenida, como son bienvenidas aportaciones en cualquier otro aspecto que haga mejor la experiencia de correr Linux en una GameCube o Wii.
Por mi parte el problema con mem2 de momento sigue en mi backlog, junto con el resto de temas pendientes para la adaptación del kernel de Linux para la Wii.

~/isobel

isobel escribió:Pero has empezado haciendo una crítica a una decisión (usar mem2 como block device) tachándola de bobada sin tener mínimamente una idea del por qué.

La tacho de bobada al no haber ningun motivo técnico para usarla de esa forma. Técnicamente es una bobada. Otra cosa es que no se haya hecho por motivos practicos (es decir, que no sea trivial implementar su uso como memoria normal), lo cual me parece perfecto. El caso es que usarla como swap no deja de ser una forma inefectiva de aprovechar la memoria (aunque es mejor que nada, claro), y yo lo veo como algo que hay que corregir (el cuando ya se verá). El problema son la gente como los de devkitpro/libogc. Ahora mismo en devkitpro y libogc hay varios chanchullos de este tipo, incluyendo lo que comento de que MEM2 no se maneja via la libc por defecto, pero a ellos no no les parece un problema y, es mas, rechazan soluciones (parches) cuando se los pones delante de las narices. Es eso lo que quería dejar claro con lo de "bobada" - que, dado el tiempo, debería corregirse en algún momento. No digo que haya sido una decisión incorrecta hacerlo de esa forma actualmente.

isobel escribió:Y luego has trivializado el problema de usar mem2 como memoria normal en el kernel de Linux citando un trozo de código y proponiendo un cambio parcial. Eso sinceramente no es serio, así que no pretendas que la discusión sea seria.

Yo, desde mi total inexperiencia con las entrañas del manejo de memoria del kernel de Linux, pensaba que no sería tan dificil. Para llegar a esa conclusión, me he basado en lo siguiente:

• Tener varias áreas de memoria es típico en algunas arquitecturas, y no solo de 64 bits
• Hay partes de la memoria del sistema que quedan inutilizadas, como por ejemplo para guardar el initrd, o para uso privado de la BIOS / firmware / lo que sea.
• Existen parches para marcar áreas de RAM como no utilizables, y yo de hecho he trasteado con los parches de badram, que te permiten marcar áreas de RAM como malas (anecdota curiosa: esto lo hice porque una vez tenía, precisa y exactamente, un bit de memoria defectuoso según memtest86, que causó unos efectos muy interesantes, tales como errores de sintaxis en módulos perl del sistema al aparecer un único caracter como mayúsculas en lugar de minúsculas). En su día porté el parche de badram de x86 a x86_64. Aunque de eso hace tiempo, si mal no recuerdo simplemente marcaba las áreas defectuosas como en uso / no utilizables en las tablas.
• Desde mi punto de vista, tener RAM no utilizable es similar a considerar todo MEM1 + gap + MEM2 como una memoria física, y marcar el gap como no utilizable.
• Una de las complejidades de memoria discontigua, en arquitecturas de 64 bits, es que no se puede implementar marcando los huecos como inusables, porque esos huecos son enormes. En la Wii esto no es así, y dudo que se pierda mas de 4MB de memoria con el mapa, incluso con esta solución cutre (y ganas tener mucha mas memoria usable directamente).
• En cualquier caso, y por lo que he visto de los includes de otras arquitecturas con soporte, no estamos hablando de una cantidad enorme de cambios, sino mas bien de algunas macros para ayudar en el mapeo de páginas, y de modificar el código específico de la arquitectura para añadir el soporte. Nada que no se pueda hacer en un par de tardes bien aprovechadas, creo yo
• Además, tenemos el ejemplo de ppc64.

isobel escribió:En el código de gestión de memoria de 32 bits de la arquitectura powerpc para Linux hay varias partes que simplemente asumen que la memoria real está físicamente contigua. Yo no digo que sea difícil cambiar esas partes, dispersas en varios lugares.
Si nadie lo ha hecho antes no es por que técnicamente sea complejo, aunque no es trivial como tú lo planteas: requiere un mínimo análisis serio.
Yo creo que nadie, y me incluyo, lo ha hecho todavía porque no ha tenido la motivación o porque simplemente ha dedicado su tiempo a otras cosas (y nadie me refiero a _nadie_, recuerda que esa parte es genérica del kernel de Linux y no tiene nada que ver con nuestras queridas videoconsolas).

Yo creo que aquí la confusión viene con los sistemas de memoria discontigua de 64 bits, donde a veces la RAM está separada por muchos gigas, y si hubiera que mantener todo eso en la tabla de memoria ocuparía muchísimo. Por eso es complejo, porque hay que cambiar todo el sistema que se usa para acceder a la tabla y dividirla en varios super-bloques de memoria. En la Wii en concreto, sólo hay 59392 páginas de 4kB entre el final de MEM1 y el principio de MEM2, por lo que la solución simple de marcarlas es factible.

Por supuesto que la solución ideal es implementar el soporte de discontigmem correctamente en PPC, pero yo pienso que hacerlo con la tabla de memoria directamente es mas simple. La desventaja es que pierdes memoria en la tabla, pero la ventaja es que no debería ser complicado de implementar, y desde luego ganas mucho respecto a usar MEM2 como swap.

marcansoft escribió:Yo, desde mi total inexperiencia con las entrañas del manejo de memoria del kernel de Linux, pensaba que no sería tan dificil. Para llegar a esa conclusión, me he basado en lo siguiente:

...

Bueno, esto me gusta más, una discusión seria.

Efectivamente, en el kernel de Linux para powerpc al igual que en sparc, se utilizan LMBs (Logical Memory Blocks) durante la inicialización del kernel para definir las diferentes áreas de memoria que el kernel podrá (o no) utilizar como memoria. El bootloader, a través del device tree, o un kernel con un device tree embebido (como en la GameCube/Wii) puede definir zonas reservadas de memoria. Esto se utiliza como comentas para excluir el área del initrd, el área del device tree o el área del crash kernel para kdump.

Recuerdo vagamente haber tenido la discusión en su momento de utilizar mem2 como sugieres, es decir, definir mem1+hueco+mem2 como memoria y reservar el hueco, y perder la memoria extra gastada en el memmap. En su día lo consideré otro "cutreatajo temporal" y creo que ni siquiera lo llegué a probar.

De todos modos, me ha picado el gusanillo, así que he analizado la manera más rápida y menos intrusiva de implementar esa idea y lo he hecho. La idea es que mem1 sea lowmem y mem2 highmem. Para esto tan sólo hace falta una combinación de ajustes de configuración adecuada (.config y .dts).

En el .dts he colocado el framebuffer al final de mem2 y delante de éste el área de buffers (ioh, io heap) que utilizo para comunicar con starlet /* el ipc de starlet no funciona correctamente en todos los casos si se usa memoria de mem1 en lugar de memoria de mem2 (y no es un problema de coherencia de cache en el lado del powerpc), como pudimos comprobar al crear el controlador usb */.
He definido como memoria existente el rango de direcciones desde 0 hasta el punto en el que comienza el ioh (mem1 + hueco + (mem2 - ioh - framebuffer)). Al quedar el ioh y framebuffer fuera del rango de memoria podemos seguir utilizando sin problemas el ioremap de powerpc 32 bits para éstos.
En la configuración del kernel he especificado que el tamaño de lowmem sea el tamaño de mem1 (CONFIG_LOWMEM_SIZE=0x01800000) y he habilitado highmem (CONFIG_HIGHMEM=y).
Después en el .dts he reservado el hueco entre mem1 y mem2 (01800000-0fffffff).

Con esto consigo 69320K frente a los 19484K (+ 53112K de swap) de usar mem2 como swap.

Bueno, al final ha salido algo de todo esto.

~/isobel

Me alegro de que al final hayas encontrado una forma fácil de hacerlo

isobel escribió:/* el ipc de starlet no funciona correctamente en todos los casos si se usa memoria de mem1 en lugar de memoria de mem2 (y no es un problema de coherencia de cache en el lado del powerpc), como pudimos comprobar al crear el controlador usb */

Lo sé, es bastante curioso. Mas que el IPC, que realmente hace "mas bien poco", será el driver de USB que no hace las cosas correctamente (o un problema de hardware incluso). Recuerdo que alguien (shagkur probablemente) se topó con lo mismo al portar lwbt, con lo que ahora se reserva un área en MEM2 alta para los buffers de Bluetooth. Los heaps IPC se encuentran ahí también, pero rutinariamente usamos bloques en pila, heap, data o bss (todo en MEM1 normalmente) sin problemas para otras funciones que no tienen nada que ver con USB, asi que creo que es un problema aislado de ese subsistema.

Por otro lado, a ver si algún día me acuerdo y meto un código machacabúferes en el driver IPC de libogc, para comprobar las cosas. Supongo que esto lo sabrás, aunque yo tardé un poco en caer en la cuenta, pero los búferes de IOS no sólo deben estar alineados a 32 bytes, sino que también deben estar alloceados hasta la siguiente dirección alineada. Es decir, si tienes un búfer de 51 bytes, debes reservar 64 por lo menos, ya que los 13 bytes sobrantes podrían corromperse al realizarse las operaciones de caché (ya que se realizan en bloques de 32 bytes). Seguro que algún bug por eso tenemos por ahí.

Joder, muchas gracias, yo también me alegro de que la discusión haya servido de algo

isobel escribió:Con esto consigo 69320K frente a los 19484K (+ 53112K de swap) de usar mem2 como swap.

Bueno, al final ha salido algo de todo esto.

~/isobel

Mola, casi 70MB de RAM "directa"... ya se podrán hacer más cosillas sin problemas (como lo de compilar que le pasaba a beto79 ).
A ver si me compro un teclado USB de una vez, a ver si consigo mi objetivo de ejecutar Amarok en la Wii
Y si consigo alguna forma para añadir una swap de forma eficiente, probaré a ejecutar KDE 4.1.1 completo

marcansoft escribió:Lo sé, es bastante curioso. Mas que el IPC, que realmente hace "mas bien poco", será el driver de USB que no hace las cosas correctamente (o un problema de hardware incluso). Recuerdo que alguien (shagkur probablemente) se topó con lo mismo al portar lwbt, con lo que ahora se reserva un área en MEM2 alta para los buffers de Bluetooth. Los heaps IPC se encuentran ahí también, pero rutinariamente usamos bloques en pila, heap, data o bss (todo en MEM1 normalmente) sin problemas para otras funciones que no tienen nada que ver con USB, asi que creo que es un problema aislado de ese subsistema.

Sí, coincide con lo que empíricamente he observado.
Yo también uso mem1 para algunos buffers ipc, pero sólo mem2 para los buffers de entrada/salida de las ioctlv que hablan con el driver usb en starlet.

marcansoft escribió:Por otro lado, a ver si algún día me acuerdo y meto un código machacabúferes en el driver IPC de libogc, para comprobar las cosas. Supongo que esto lo sabrás, aunque yo tardé un poco en caer en la cuenta, pero los búferes de IOS no sólo deben estar alineados a 32 bytes, sino que también deben estar alloceados hasta la siguiente dirección alineada. Es decir, si tienes un búfer de 51 bytes, debes reservar 64 por lo menos, ya que los 13 bytes sobrantes podrían corromperse al realizarse las operaciones de caché (ya que se realizan en bloques de 32 bytes). Seguro que algún bug por eso tenemos por ahí.

Sí, las operaciones de cache para powerpc actúan siempre sobre como mínimo una línea de cache (32 bytes en el caso de GameCube y Wii). El problema se puede presentar si tienes en memoria cacheable un buffer de entrada y uno de salida compartiendo la misma línea de cache. Si para el buffer de entrada invalidas/descartas su contenido (dcbi) esperando que el dispositivo escriba en él, a la vez te estás cargando los datos que has puesto en el buffer de salida (si no se han escrito todavía en memoria antes por otra vía).

~/isobel

isobel escribió:Sí, las operaciones de cache para powerpc actúan siempre sobre como mínimo una línea de cache (32 bytes en el caso de GameCube y Wii). El problema se puede presentar si tienes en memoria cacheable un buffer de entrada y uno de salida compartiendo la misma línea de cache. Si para el buffer de entrada invalidas/descartas su contenido (dcbi) esperando que el dispositivo escriba en él, a la vez te estás cargando los datos que has puesto en el buffer de salida (si no se han escrito todavía en memoria antes por otra vía).

Exacto. En el otro lado (Starlet, es decir, ARM9) también son de 32 bytes, por cierto.

En realidad podrías tener problemas aunque la parte sobrante de la línea de caché no sea un bufer IPC. Por ejemplo, si son datos privados del PPC. Escribes algo (queda en caché), realizas una operación IPC de lectura con la otra mitad de la línea, se invalida la caché previamente y tus datos desaparecen.

-

WC24 no tiene nada que ver. No existe ningun canal que se ejecute "en segundo plano" en la Wii, ni existe un sistema multiproceso para el PPC, ni un hypervisor, ni nada. DVDX no es ningun canal que se ejecute de fondo. Todo lo que se hace en segundo plano de WC24 se hace dentro de IOS, en su memoria privada. No hay nadie que te pueda robar memoria.

DVDX es solo un trampolin para cambiar un flag interno de IOS que activa el modo DVD. El canal es necesario porque ese flag solo se activa al ejecutar canales. Lo que hace el código de DVDX en sí es solo reconfigurar un poco el PPC y luego saltar de vuelta a tu código, y ya esta. Para usarlo con Linux, lo lógico es cargarlo muy pronto en el proceso de arranque (con alguna implementación de IPC simple - no se cómo exactamente funciona la de Linux, ni si es capaz de funcionar muy pronto durante el proceso de arranque). No es muy factible hacerlo al cargarse el driver ya que DVDX causa un reset puro y duro del PPC y de Starlet, y te toca reconfigurar todos los registros de CPU para mantener el contexto y además pierdes todo lo que tengas abierto en IOS. En la libdi lo que hacemos es usar los mecanismos normales de libogc para reinicializar IPC (tuvimos que añadirle algunos parches), y salvar y restaurar el contexto del PPC. Por eso en libogc hay que inicializar DVDX antes que ningún servicio de IOS adicional. Pero con Linux eso sería mucho mas complicado, así que lo mas simple sería hacerlo durante el proceso de arranque.

La solución simple sería usar un wrapper escrito con libogc que inicialice libdi (y por tanto DVDX) y luego cargue el DOL de Linux ya con el modo DVD activado, pero entonces arrastras libogc entera con Linux. No se cómo funciona el proceso de arranque de Wiilinux, así que no se cómo de viable será reimplementar la carga del canal.

En cuanto a los problemas de WC24, serán específicos de IOS. Probablemente te moleste al usar los sockets o algo así. No es que se pisen la memoria.

-

nuvalo escribió:

WC24 no tiene nada que ver. No existe ningun canal que se ejecute "en segundo plano" en la Wii, ni existe un sistema multiproceso para el PPC, ni un hypervisor, ni nada. DVDX no es ningun canal que se ejecute de fondo.

Ok, como el método se llamaba "launchtitlebackground" ya me pensaba que era que se iba a ejecutar a la vez que el programa que lo llamara.

El truco es que LaunchTitleBackground retorna al recibir el ACK desde IOS, y deja que IOS lance el canal en segundo plano. Esto es, se pone a lanzar el canal, en segundo plano (que no significa que el canal vaya a ejecutarse en segundo plano una vez lanzado). Mientras IOS está ocupado haciendo eso, yo apago IPC, guardo todo, y pongo el PPC en un bucle infinito. Como IOS es mas lento, cuando termina de hacer sus tareas, lanza el canal (lo cual incluye resetear el PPC), y entonces se restaura todo.