Boot Modes/es

From Qi-Hardware
Jump to: navigation, search

NAND Flash boot

Cuando se inicia el sistema de archivos mediante la NAND Flash el boot program se encarga de configurar los puertos EMC y GPIO segun la informacion del primer byte. Lo primero que hace es leer el primer byte de la NAND Flash para saber si es de 16 o 8 bits de ancho, y tambien si es de 2 o 3 page cycles. Cuando la informacion de bit [7:4] del primer byte es cero la NAND es de 16-bits de lo contrario es de 8-bits, luego se leen bit[3:0] del primer byte para determinar los pages cycles si estos son cero tiene 2 page cycles sino 3. En este caso el NanoNote utiliza una NAND flash con comunicacion de 16-bits aunque solo usa 8 bits. Luego carga 8KB de la NAND a la SRAM interna y salta a la SRAM interna hasta desplazarse 4 bytes.

El boot program puede cargar dos areas de datos de la NAND flash a la SRAM interna, una es el area normal en la cual carga 8KB de la NAND flash desde la direccion 0, y la otra es el backup area, donde tambien carga 8KB pero comienza desde la direccion de memoria 0x2000. En la figura se presenta el flujo de datos que se sigue cuando se realiza el boot. Despues del Reset se lee el primer byte de la NAND, luego se lee el area normal de la NAND desde la direccion 0 a traves del [Reed-Solomon [ECC]], se verifican si no hay problemas de ECC, si no hay errores de ECC o si se corrigen, entonces el boot program salta hasta a la SRAM interna y se desplaza 4 bytes. Si se detectan errores que no se pueden corregir entonces lee el area del backup de la NAND usando Reed-Solomon ECC, desde la direccion 0x20000, igual que en el anterior si no existen errores ECC o son corregibles, salta RAM interna y se desplaza 4 bytes. Si se encuentran errores ECC que no se pueden corregir entonces, intenta inicializar desde la NOR flash, pero como el NanoNote no tiene de este tipo de memoria, no puede iniciar.

Cada vez que el boot program comienza a leer una pagina, verifica si los datos son correctos, si es asi, lee la pagina de la SRAM interna. Sino entonces este finaliza de leer y salta a la SRAM y se desplaza 4 bytes. El boot program decidira si la pagina es valida de acuerdo al tercero, cuarto y quinto byte de el area reservada de estas. Si uno de los tres bytes es cero el dato es valido, de lo contrario no. El boot program habilita hardware RS ECC cuando lee la NAND flash data. Cuando el 512-byte es leido, compara el ECC almanecado con el calculado. Ambos tienen 9-bytes por cada 512-byte de datos. Y el noveno byte almacenado comienza desde el septimo byte del area reservada de cada pagina.

Nand Boot Flow Diagram

USB boot

Cuando el boot es seleccionado desde el usb es decir cuando BOOT_SEL se encuentra en [1:0], se presenta una ventaja con respecto a los otros modos, debido a que la transmision de datos toma poco tiempo, alrededor de dos minutos. Luego de que los pines son seleccionados, el interno boot ROM espera los USB requerimientos del host, hasta descargar el boot program desde el puerto USB y cargarlo a la interna SRAM y luego saltar a la SRAM para comenzar a ejecutar el programa.

El boot program puede ser realizado a atraves de dos diferentes modos de transferencia. Full-speed que se realiza a 12MHz y high-speed a 480MHz. A continuacion se presentan los dos tipos de transferencia.

TABLE

El flujo de la comunicacion entre el host y el JZ4720 se presenta en la figura, donde se observa a gran escala el envio y recepcion de informacion.

Comunication host-device USB

El USB boot program los siguientes 6 vendor-request VR_GET_CPU_INFO (0x00), VR_SET_DATA_ADDRESS (0x01), VR_SET_DATA_LENGTH (0x02), VR_FLUSH_CACHES (0x03), VR_PROGRAM_START1 (0x04) y VR_PROGRAM_START2 (0x05), a traves del control endpoint, los cuales permiten download/upload informacion to/from dispositivo, y luego saltar a una direccion a ejecutar el programa que es transferido mediante Bulk IN o Bluk OUT endpoint.

Cuando se conecta el USB y el host lo reconoce, comienza the device enumeration, cuando esta finaliza se puede enviar el primer vendor request VR_GET_CPU_INFO (0x00), que como el nombre lo indica consulta la informacion de la CPU del dispositivo. Luego si se quiere download/upload un programa to/from dispositivo, dos vendor request se envian primero VR_SET_DATA_ADDRESS (0x01) y VR_SET_DATA_LENGTH (0x02) para indicar la direccion y el tamano de byte de la transferencia de datos que se va a llevar a cabo. La cual se puede realizar mediante Bulk-in/Bulk-out endpoint. Cuando la primera parte ha terminado de transferir datos al dispositivo, se envia el siguiente vendor request VR_PROGRAM_START1 (0x04) para que la CPU pueda ejecutar el programa, el cual no debe ser mayor a 16KB y es usado para iniciar los GPIO y la SDRAM de la target board. Cuando la primera parte se realiza, se devuelve a el interno boot Program saltando al $31 registro. Ahora el usuario puede descargar un nuevo programa a la SDRAM de la target board como en la primera etapa y enviar nuevamente otras vendor request VR_FLUSH_CACHES (0x03) y VR_PROGRAM_START2 (0x05) para que la CPU pueda ejecutar el programa. En la figura se observa el flujo en el que transcurre el boot a traves del usb.

Secuence usb boot
Personal tools
Namespaces
Variants
Actions
Navigation
interactive
Toolbox
Print/export