Dudas sobre piBacteria

[antoniovillena]

Respondo por aquí las dudas de neuro_999 porque lo mismo pueden valer para otras personas interesadas en hacer su propio emulador para RPi.

Una pregunta mas, he visto que has añadido la variable qemu al source. ¿Ahora se puede cargar el kernel.img en el qemu para testear?. He estado intentandolo pero no lo consigo. Uso la version 2.2 de windows .

Me bajé la última de aquí:

http://qemu.weilnetz.de/w64/

Creo que es la 2.2 o la 2.3 pero no estoy seguro. El soporte para Raspberry de QEMU es algo relativamente nuevo así que es importante que tengas una versión reciente, aunque no hace falta que sea la última.

¿Ensambras el source con algún otro comando para que se pueda abrir con el qemu?.
Yo lo ensamblo desde windows con el arm-none-eabi y las instrucciones de tu pagina.
as -o tmp.o piBacteria.s
ld -e 0 -Ttext=0x8000 -o tmp.elf tmp.o
objcopy tmp.elf -O binary kernel.img

Exacto. Si te sirve aquí tengo el Makefile:

Código: Seleccionar todo

PREFIX= arm-none-eabi-

all: kernel.img

clean :
	rm -f tmp.elf
	rm -f *.o
	rm -f *.img

piBacteria.o : piBacteria.s z80.s
	$(PREFIX)as -o $@ $<

kernel.img : piBacteria.o
	$(PREFIX)ld -e 0 -Ttext=0x10000 -o tmp.elf $<
	$(PREFIX)objcopy tmp.elf -O binary $@

Ojo, cuando compiles para máquina real se carga en 0x8000. No sé porqué razón en el emulador qemu se carga de la 0x10000, no creo que sea muy difícil cambiarlo. Mientras tanto ten esto en cuenta a la hora de compilar (o crea 2 compilaciones distintas desde el Makefile).

Luego para cargarlo con el qemu he probado "qemu-system-arm -M versatilepb -m 128M -kernel kernel.img -serial stdio" pero no me carga nada, se queda a la espera de inicializacion grafica.

Ahí está el problema, que la máquina versatilepb no está centrada para Raspi, aunque hasta hace poco era la única forma de hacer funcionar el emulador. De hecho si buscas en google las instrucciones que hay son para versatilepb. El comando que tienes que usar para lanzar el emulador es éste:

Código: Seleccionar todo

qemu-system-arm.exe -M raspi -cpu arm1176 -kernel kernel.img -m 192

Igual es que me he flipao pensando que se podia ver con el qemu y no se puede.

No, no te has flipao. Lo estoy haciendo así por 2 motivos: ir corrigiendo los bugs que ha detectado Benkobi, y meterle soporte de teclado USB. Lo último no estoy seguro si se podrá hacer. Por ejemplo para la parte gráfica he hecho una adaptación porque el emulador no soporta framebuffer de 4 bits/pixel, por lo que con ensamblado condicional genero uno de 16 que sí soporta (también desactivo el control de velocidad, ya que bajo qemu no me importa que vaya más rápido de la cuenta).

Evidentemente el teclado no va a funcionar cuando lo ejecutes desde qemu porque el emulador no ve nada conectado al puerto GPIO.

[antoniovillena]

Si tenéis curisidad, el 90% del código (6000 líneas) es el core Z80 y el 10% restante (600 líneas) el emulador en sí. Y del emulador si le quitas las tablas, las constantes y el código de depuración (hexs, hexh y send que sacan valores hexadecimales por el puerto serie) se te queda en la mitad. Yo lo hice para aprender ensamblador, de hecho el core lo pasé de C a ensamblador. Si alguien está interesado en hacer un emulador en C, puede sacar el código de aquí:

http://retrolandia.net/foro/showthread. ... 654#pid654

Es un emulador genérico de Z80 por línea de comandos. Lo tengo versionado en subversion aquí:

http://sourceforge.net/p/emuscriptoria/ ... ot/ticks.c

Por si queréis seguir los cambios, pero lo que hice fue separar el código fuente en 2 partes (antes estaba en un único archivo en C) y pasar la parte que se corresponde con la emulación Z80 a ensamblador del ARM. De esta forma tenía un medio para comparar que lo que estaba portando a ensamblador funcionaba correctamente: de hecho usaba un benchmark que probaba todas las instrucciones y hacía 2 ejecuciones paraleras: la del motor Z80 en C y la del ensamblador. En el momento en que notaba una diferencia hacía una búsqueda binaria para encontrar el ciclo exacto donde fallaba, y así encontraba la instrucción Z80 "mal emulada".

[Ben-kenobi]

Gran trabajo!

[neuro_999]

Muchisimas Gracias... ya me funciona así da gusto hacer pruebas sin tener que poner y quitar la SD.

Voy a descargarme los fuentes en C para echarles un ojo también, aunque me llama mas aprender ensamblador de ARM, ya que el del 8086 y el de AS400 se me daban bien.



Salu2.

[antoniovillena]

Muchisimas Gracias... ya me funciona así da gusto hacer pruebas sin tener que poner y quitar la SD

Puedes comprarte un conversor USB-Serie que cuesta menos de 2 euros e instalarte un bootloader (un kernel.img que carga lo que le envíes por el puerto serie). De esta forma no hace falta estar cambiando continuamente la SD. En el libro explico cómo se hace, y si además conectas la señal de reset la carga es automática.

[antoniovillena]

En este video...

http://www.va-de-retro.com/foros/viewto ... =50&t=3055

...cargo varios programas Bare Metal por el procedimiento que te he explicado. La velocidad del puerto serie es suficiente 115200bps para que la carga sea instantánea, y si tienes programas más pesados puedes overclockear el puerto serie. Yo he conseguido ponerlo hasta los 4Mbps.

[neuro_999]

Ya he pedido mi conversor a china a ver cuando llega.
Por cierto he estado revisando el fuente del bacteria e investigando un poco de baremetal y he llegado hasta el framebuffer de momento.
Resulta que estoy mirando las primeras inicializaciones que hace el fuente al buffer y hay algo que se me escapa.

Código: Seleccionar todo

mbox:   ldr     r3, [r2, #MBOXSTATUS]
        tst     r3, #0x80000000
        bne     mbox
        str     r0, [r2, #MBOXWRITE]
mbox1:  ldr     r3, [r2, #MBOXSTATUS]
        tst     r3, #0x40000000
        bne     mbox1
        ldr     r3, [r2, #MBOXREAD]
        and     r3, #0x0000000f
        cmp     r3, r4
        bne     mbox1
        bx      lr

Basicamente hace la lectura y la escritura al framebuffer cuando esta libre, y por el cmp r3,r4 con el valor #8 que se carga en r4 antes de saltar, supongo que usas el canal 8, ya que es el que buscas para la respuesta de los 4 ultimos bits.
Pero en el valor del write le envias r0 que contiene la direccion donde se ha cargado la rom mas el valor de ogetrev+8 (que segun mis calculos da -128) lo que me lleva al valor de opaleta que es -64.
Pues si mando el Write de -64 (FFFFFFC0) se supone que los 4 ultimos bits son para el canal, y ese caso seria el canal 0 no?.
Ya te digo que estoy empezando a meterme con el framebuffer del baremetal y de momento estoy un poco pez, pero era para ver si me aclarabas un poco el valor de esas variables misteriosas de números negativos.

Salu2.

[antoniovillena]

Es que yo tengo un puntero cargado en un registro, Mem, y el resto de variables las cargo con desplazamiento ese puntero. El canal son los 4 bits bajos pero creo que 0 no era. Te recomiendo el tutorial baking pi para aprender a manejar el frame buffer

[neuro_999]

Si justo me había dado cuenta de eso después de escribir, me había hecho un lio al contar las posiciones de memoria de las variables. Ahora ya veo claro el desplazamiento.
Ahora ya he visto que lo primero que le mandas al framebuffer es 0x00010002 que es la tercera word del getrev, aunque tampoco se aun porque. voy a estudiarme mas el framebuffer.
No se si es alguna parte de codigo que usaste para ver la version de la pi y que no entiendo bien que hace, pero bueno le dare otra vuelta.

Muchas Gracias tio.

[antoniovillena]

Ahora con portátil te lo explico mejor (antes estaba con móvil). Para configurar el framebuffer se usan mailboxes, pero tiene otros muchos usos, aquí tienes toda la API:

https://github.com/raspberrypi/firmware ... -interface

En concreto en el piBacteria hago una llamada al canal 8 y otra al canal 1. La del canal 8 es para leer la revisión de la placa (tag 0x10002) y la del canal 1 es la que configura el framebuffer. Para escribir en un canal hay que sumarle el canal a la dirección ogetrev+8 para canal 8 y ofbinfo+1 para canal 1 y también ponerlo en r4. De esta forma, después de la lectura se comprueba que el dato viene de dicho canal.

Para configurar el framebuffer tienes más información aquí:

https://www.cl.cam.ac.uk/projects/raspb ... een01.html

Pero vamos, no tiene mucha miga. Pones dos resoluciones, la de la pantalla y la del framebuffer. Yo tengo 1024x768 en la pantalla y 352x264, de esta forma pinto en un área muy pequeña y el hardware gráfico me lo escala. De hecho la pantalla de colorines que se ve al principio es un framebuffer de 2x2 pixeles escalado por hardware. Más abajo hay un valor que es el bit Depth, que es el número de bit por pixeles. Yo lo tengo a 4 bits, ya que de esta forma tengo para mostrar todos los colores del spectrum usando el mínimo de ram de video. Eso sí, los colores van paletizados y la paleta está justo debajo de fbinfo. Tras hacer la llamada al mailbox en esa misma estructura te devuelve el puntero al framebuffer (point). Tan sólo tienes que escribir ahí y los cambios se ven reflejados directamente por pantalla (es un buffer lineal).

Para que sea más rápida la generación de video yo lo hago todo mediante una tabla lookup. Con los 8 bit del atributo más los 8 bit del bitmap accedo a una tabla de 16 bit que me da directamente los 8 pixeles a pintar (caben en 32 bits). La tabla la genero al inicio mediante código y para pintar una línea se accede a dicha tabla 32 veces, que es mucho más rápido que generar pixel a pixel en un bucle de 256.