Bios, generación de código

[julian403]

Un sistema operativo es un programa cuyo objetivo es el control del hardware y brindar una máquina extendida comprendiendo drivers y rutinas especificas para los dispositivos de entrada y salida, la cual pueden ser llamadas por un programa de aplicación. Con esto se puede decir que el BIOS es un sistema operativo que reside en la memoria no valatil del PC de manera que cuando se inicia el sistema, el valor iniciado por el registro Contador de programa es el comienzo del bios o una dirección cuyo salto será donde se encuentra el código del bios.

El BIOS además de ejecutar el POST tiene funciones específicas de control del hardware y de los diferentes dispositivos E/S, de manera de dar una interfaz estandarizada y desligarse de las diferencias entre los dispositivos de cada fabricante. Y de esta manera poder inicializar a cada uno correctamente para luego cargar en la memoria el Bootloader y darle inicio.

Mi pregunta es, los desarrolladores del BIOS, como American Megatrens o Phoenix cuando crean las rutinas del BIOS ¿estos desarrollan una rutina específica en la cual los desarrolladores de dispositivos como, discos duros, deben acomodarse sus intergaces y controladores en función del controlador de la bios? o ¿cómo sería?

Por ejemplo, el siguiente fragmento es la primera parte de POST (power on selft test) de AMIBIOS POST, de 1995.

D0h The NMI is disabled. Power on delay is starting. Next, the initialization code checksum will be verified.
D1h Initializing the DMA controller, performing the keyboard controller BAT test, starting memory refresh, and entering 4 GB flat mode next. D3h Starting memory sizing next.
D4h Returning to real mode. Executing any OEM patches and setting the stack next.
D5h Passing control to the uncompressed code in shadow RAM at E000:0000h.The initialization code is copied to segment 0 and control will be transferred to segment 0.
D6h Control is in segment 0. Next, checking if <Ctrl> <Home> was pressed and verifying the system BIOS checksum. If either <Ctrl> <Home> was pressed or the system BIOS checksum is bad, next will go to checkpoint code E0h. Otherwise, going to checkpoint code D7h.

En la dirección D1h está la inicialización del controlador DMA (controlador de memoria ram). Entonces, ¿los fabricantes de memoria ram como Kingston, deben desarrollar sus placas en función a que respondan al controlador que trae la bios? o ¿los desarrolladores de la bios deben crea el controlador DMA en función de las placas? este último me parece dificil ya que tendrían que crear un código específico para cada fabricante, porque ya conocen como es el mercado cada fabricante quiere desligarse y hacer lo suyo. Y recuerden que la bios reside en memoria no volatil y no puede cargar un controlador porque todabía no inició la ram, entonces el controlador que inicie la ram debe ser parte del código del bios.

No sé si entienden mi dudilla.

 

[analogico]

No sé si entienden mi dudilla.

no se pero existen bios libres que puedes investigar como hacen eso
como la openbios y el coreboot

 

[tiago]

@julian403

Lo poco que yo se al respecto es que el BIOS está comunicado únicamente al EC controler. Éste a su vez posee unos puertos de comunicación directos a ciertos dspositivos que controla a base de señales lógicas simples (Niveles alto y bajo) Como es el encendido de los LED de mayúsculas, el power LED, el arranque y velocidad del ventilador, encender y apagar el módulo wi-fi y el control de las fuentes de voltaje, así como las señales de OK que mandan los dispositivos cuando están disponibles para arrancar, teclado y bastantes mas cosas.

Pero también tiene varios bloques GPIO que están comunicados principalmente y entre otros con el Puente Sur
que controla básicamente los canales SATA o IDE, y con el puente Norte, la BIOS le indica en que modo debe leerlos y muchas veces las opciones de éste modo las tienes en la pantalla de configuración que el BIOS ofrece al usuario y que éste puede hacer cambios. Es un gran tela de araña.

El Puente Norte controla básicamente A la GPU y a las memorias RAM. Como el Puente Norte mantiene comunicación con el Puente Sur, éste le cuenta al BIOS lo que está pasando en el piso de arriba y si todo está bien deja que siga el juego.
El puente Norte posee el gobierno de las RAM y éste es el que gestiona su información
Luego creo, se inicia el procesador y la GPU, si al EC controller le llegan todas las señales de OK en estado alto comunica BIOS con Puente Sur para saber que sector de qué dispositivo debe leer e iniciar así el S.O.
Despues, el Bios ya queda como juez y parte de todo el conjunto.

Creo que los P norte y P sur llevan ya grabadas intrucciones o protocolos estandar. Me imagino que según éstos la BIOS podrá reconocer cierto tamaño de memoria, velocidad y latencia de la misma etc ...
La misma Bios consultará con la RAM cual es su dirección de inicio y ya le servirá ésta info al Puente Norte.
El BIOS comprueba y se informa de todos los dispositivos antes de proceder al arranque del equipo.

Lo que digo puede que sea un poco espeso pero es mas o menos correcto.a la hora de analizar el funcionamiento hay que ver la placa como un todo.

De todos modos encontrarás información mas precisa y bien explicada en publicaciones al respecto, como ya te han aconsejado.

Saludos.

 

[julian403]

Por lo que he leido hasta ahora de la documentación de coreboot o openbios, efectivamente es el puente norte el que se encarga del manejo del bus de datos y direcciones al microporcesador dandole la interfaz física y en cuanto a secuencia de datos en la multiplexación por división de tiempo que le corresponde a cada elemento del esquema ordenado y por sobre todas las cosas le brinda un mapa de memoria que va más allá de la memoria principal incluyendo los dispositivos PCI y la memoria flash del bios.

Hoy en día en los procesadores de sexta generación de intel he visto en su documentación, en especial con el chipset Z170 (con un arquitectura PCH) que la memoria principal (RAM) está conectada directamente al micro.

Puede verse acá: https://en.wikipedia.org/wiki/Platform_Controller_Hub
o en la hoja de datos de los procesadores intel sexta generación:http://www.intel.com/content/www/us...mobile-h-processor-lines-datasheet-vol-2.html

Entonces, al parecer son los desarrolladores de dispositivos como memorias ram y dispositivos PCI que deben realizar sus productos de manera tal que tengan una interfaz física y lógica (controladores) con los chipset.

 

[TRILO-BYTE]

a eso se le llama protocolo de compatibilidad

nadie puede hacer algo sacado de la manga

yo digo que el bios es solo una ROM que se encarga de darle las primeras intrucciones al CPU de cuanta memoria tiene, cuantos puertos tiene, a que velocidad corre el reloj, etc.

no creo que como tal sea un sistema operativo muy complejo como para empezar a ahacer algo .

siento que es un firmware que permite que un segundo programa entre en ejecucion y una vez que este segundo programa entra en ejecucion el bios deja de trabajar para que el segundo programa tome el control.

es como a los viejos sistemas minimos que tenias que hacer una ROM para encender el el sistema y una vez que hacia lo que tenia que hacer brincaba a la direccion donde el programa principal era ejecutado.
ya era tu opcion que en el programa pudieras regresar a la ROM o no

 

[julian403]

yo digo que el bios es solo una ROM que se encarga de darle las primeras intrucciones al CPU de cuanta memoria tiene, cuantos puertos tiene, a que velocidad corre el reloj, etc.

Yo pensaba exactamente lo mismo pero porque está el pensamiento general que sistema operativo es Windows o alguna distribución linux. En general, cualquier programa que maneja el hardware y/o brinde funciones para el manejo de este es un sistema operativo o como me gusta llamarlo sistema de operación , por ejemplo, si programas un pic de la linea 18f, el programa principal que tu hagas y que reside en la memoria ROM, es un sistema operativo porque tiene completo manejo del microcontrolador, de la cpu, de los perifericos, es más si otro dispositivo pide atención a través de una interrupción externa, va a ser tu programa el que desidirá atenderlo, si está habilitada las interrupciones y que dirección pusiste en el vector de interrupción, eso mi amigo es un programa que opera el hardware.
Por el hecho de residir en la memoria no volatil y trabajar sobre el se lo denomina firmware pero eso no implica que ese código no sea un sistema de operación. Todo firmware es un sistema de operación pero quizás no tenga rutinas que dan soporte a otras aplicaciones, que es lo que hace windows o linux pero la bios si da rutinas que dan soporte estandarizado.

siento que es un firmware que permite que un segundo programa entre en ejecucion y una vez que este segundo programa entra en ejecucion el bios deja de trabajar para que el segundo programa tome el control.

Tampoco, las funciones estandarizadas para el manejo del hardware que brinda el bios siguen estando ahi, en la memoria no volatil, la cual es mapeada por el chipset en la zona baja, que en el primer momento es la zona alta de la memoria hasta que el bios inicialice el chipset, o el micro en los nuevos procesadores, inicialice los controladores de memoria. El sistema operativo principal tiene la posibilidad de utilizarlas pero en general el sistema operativo dice "yo tengo mejores rutinas de manejo del hardware, gracias".

Cuando termine de leer lo que es el código de openbios preguntaré porque hay algo que no me cierra, pero quizás en la documentación está.

 

[TRILO-BYTE]

no se te ocurra comparar una computadora con un pic

los pic tienen el problema de que si uno escribe un programa sea dentro de una eeprom externa el pic solo ejecutara el programa que esta en la flash osea no ejecutara el programa en la eeprom externa.

en cambio un sistema basado en un CPU sea un 8086, 6502 o un Z80 podemos escribir en una ROM un programa que le indique al CPU cuantos bancos de memoria existen, cuantos puertos, etc.

y una segunda ROM que antiguamente eran los cartuchos digamos que el bios empezaba no se en la direccion 100h y terminaba en digamos 600h

entonces nuestro programa empezaba en la direccion 601h pero en nuestro programa podemos brincar a voluntad a la 100h

cosa que el pic no puede hacer por que no lee roms externas pero si podemos hacer algo similar con los bootloaders, podemos leer informacion en una EPROM, una SD, pero no podemos leer instrucciones ASM de esas memorias.

todo tiene que ver como se administran los bancos de memoria.

otra cosa

prender un led y mover un Relè no es un sistema operativo eso es una patraña

que si existen sistemas operativos para los microcontroladores los RTOS

no es como tu dices ver paint , abrir block de notas, no es administrar tiempos de ejecucion.

digamos que queremos prender 5 leds y generar 8 señales cudradas, y escribir hola en una memoria

podemos hacerlo con timer dentro del pic de la manera tradicional "sin un sistema operativo"

pero hacer que un micro se haga multitarea esta cerca de ser un sistema operativo solo hay que pulir el codigo

pero si no tenemos tiempo y el proyecto urge se requiere de uno un RTOS
y podemos escribir de la manera mas puerca y marranamente posible el codigo y el RTOS se encargara de ejecutar todas las tareas al mismo tiempo

como cuando uno abre varias ventanitas o aplicaciones en una computadora

cada uno requiere recursos del CPU pero el CPU ejecuta una tarea a la vez, y el sistema operativo se encarga de ejecutar las tareas por pedacitos dando la apariencia de que todo se ejecuta al mismo tiempo

 

[julian403]

los pic tienen el problema de que si uno escribe un programa sea dentro de una eeprom externa el pic solo ejecutara el programa que esta en la flash osea no ejecutara el programa en la eeprom externa.

en cambio un sistema basado en un CPU sea un 8086, 6502 o un Z80 podemos escribir en una ROM un programa que le indique al CPU cuantos bancos de memoria existen, cuantos puertos, etc.

No, todo dispositivo que implemente un esquema ordenador ya sea una arquitectura pc o una arquitectura ARM implementada en microcontroladores o microcontroladores gama media bajo poseen una unidad de control en la cual hay un registro denominador registro Contador de programa, cada bits del registro está conectado al bus de dirección y este registro establece la dirección de la memoria a leer.

Cada fabricante establece una dirección cuando se produce el encendido y esa dirección es donde se leerá la primera instrucción. En el caso de los micros por supuesta esa dirección es la dirección de la memoria de programa o no volatil, de manera de asegurar que inicie con algo. En el caso de los procesadores la dirección de inicio es 000F_FFFFH, ahora bien es el chipset el que vincula esa dirección fisica del procesador con una dirección de la memoria principal ¿por qué esa dirección? pues porque se debe seguir manteniendo la compatibilidad hacia atras desde que salió la arquitectura x86 con el 8086

Un microcontrolador es un esquema ordenador completo y un procesador no, es por eso que entre la memoria principal y este le puedes poner un chipset y que el micro vea lo que el chipset le muestre.

digamos que queremos prender 5 leds y generar 8 señales cudradas, y escribir hola en una memoria

podemos hacerlo con timer dentro del pic de la manera tradicional "sin un sistema operativo"

pero hacer que un micro se haga multitarea esta cerca de ser un sistema operativo solo hay que pulir el codigo

Por más que no lo quieras, un código en un pic (pongamos un ejemplo de uno de los más básicos el 16f8
) para prender un led es un sistema de operación para dicho pic. Porque tu código debe configurar el timer, debe configurar los puertos, debes preescalar el timer para que la frecuencia sea visible. Ahí hay un control del hardware.

¿Me crees si te digo que es posible implementar multitarea como los hacen los microprocesadores de un nucleo en un pic? Pues debes configurar el timer para que cuando desborde salte interrupción, es decir, al desbordar el timer saltará a la dirección 0x04 (por ejemplo en las gamas altas ya hay vectores de interrupción como en los procesadores) y en esa posición está un salto a cierto lugar de la memoria que ejecuta una rutina, esa rutina (llamemosle de control) compara que parte de la memoria se estaba ejecutando, donde había una rutina en particular (es decir, un programa o aplicación 1) y saltará al programa o aplicación 2 en otra posicion de memoria. Al desbordar el timer salta a 0x04 y de ahí a la rutina de control y compara que es lo que se estaba ejecutando (esto se hace con un simple BTFSC por ejemplo) y ahí salta a la aplicación 1. Como vez la rutina que empieza con un goto RUTINA_CONTROL en 0x04 es análoga a la rutina de un SO de control de multiproceso.

Un sistema operativo como windows hace eso, trabaja con interrupciones externas del timer. Y el bios también.

Puedes ver algo de esto acá: https://en.wikipedia.org/wiki/Interrupt_request_(PC_architecture)

los RTOS son sistemas operativos, programas como cualquiera pero que tienen ya código de manejo de los dispositivos del I/O y también de configuraciones que en vez de hacerlo uno, carga el SO y se realizan llamadas a las rutinas del RTOS que se quiera porque ¿para que vas a programar algo que ya está hecho? sino quieres un RTOS y hacer llamadas debes linkear librerias y el programa ocupará mucha memoria en vez de la poco que te puede ocupar llamadas al RTOS

Tu idea de sistema operativo es que si lo programó una empresa si es SO y si lo programas vos no es un SO. O si es un programa básico y pequeño (como el bios) no es SO y si es grande con una enorme cantidad de rutinas y controladores si

Ahora el bios es un SO completito porque maneja el hardware y tiene funciones que configura los registros del chipset y el micro para inicializar los controladores que estos tienen para el control de los dispositivos externos como memoria, disco, teclado, mouse, pantalla, etc. Pero la duda que sigo teniendo si que si los fabricantes de estos dispositivos hacen los controladores físico en función de los controladores del chipset y micro para que halla interfaz lógica además de interfaz física (que esa si deben tener en cuenta los fabricantes de los dispositivos) o si el bios se encarga de ralizar la interfaz lógica configurando los registros que modificarán estos controladores en función de que dispositivo sea y de que marca. ¿se entiende mi duda?

 

[TRILO-BYTE]

que parte de protocolo no se entendio

nadie hace las cosas sacadas de la manga , hay protocolos un mouse siempre sea un mouse , un teclado sera un teclado, una memoria sera memoria.

si nosotros hacemos un circuito y/o programa que emule el protocolo de no se una impresora aunque no sea impresora la computadora lo reconocera.

si nosotros metemos el protocolo de comunicacion de un teclado sea ps2 o usb en un micro cualquiera aunque no sea realmente un teclado el bios lo reconoce.

si agarramos una computadora y simulamos una targeta de sonido con su protocolo de bus el bios lo detectara

asi de simple

 

[julian403]

Solamente para cerrar el tema, después de haber leido sobre open bios si bien cada fabricante debe seguir una interfaz física estandarizada y protocolos de comunicación estandarizados se debe tener en cuenta que los estándarez son creados por las empresas lideres. A si pues el estandar del BIOS fue desarrollado por IBM y todabía se mantiene en lo que constituye la UEFI.

En particular es el BIOS el encargado de brindar funciones estándares para diferentes dispositivos que quizás tengan protocolos diferentes. Así por ejemplo el modo de funcionamiento en cuanto al driver físico de un disco de platos es diferente al disco de estado sólido tipo flash. Pero la bios debe brindar una interfaz estandar para los programadores de sistemas operativos como microsoft o alguna distribución linux de manera tal que estos no se tengan que ocupar como se inicializa el bootloader. Así pues, el programa setup de la bios debe poder brindar la elección al usuario del PC, de que disco usará para que el sistema funcione y por supuesto tener las correspondiente rutinas y parámetros.

 

[Ferdinando12]

Tal vez pueda contribuir un poco y para entender un poco más es necesario remontarnos al origen de los tiempos.
IBM inició toda la movida de lo que hoy conocemos como PCs. Si la memoria no me falla el mayor esfuerzo estuvo en como la Central Processor Unit (microprocesador) se vincularía con el resto del mundo (dispositivos de entrada (teclados) dispositivos de salida (pantalla, impresoras), dispositivos de acceso secuencial (cintas) dispositivos de acceso directo (diskettes), de hecho se le denominó periférico a cualquier cosa que estuviera fuera del micro, en otras palabras... hasta el controlador de memoria era un periférico del micro....
Entonces alguien muy ingenioso creó lo que se conoció en su momento como bus transaccional. Este bus que "transaccionaba" tareas, era la autopista a la que TODOS los periféricos debían estar conectados en paralelo y este bus estaba diagramado en concordancia perfecta con la arquitectura del microprocesador. Resumiendo... todo el resto del equipo se diseñaba en función del micro, si poseía un bus de datos y otro de instrucciones entonces habían dos "buses" (al inicio no fué así, era un solo bus), por lo tanto como sabía cada periférico que debía atender las llamadas? con un protocolo de control y su chip asociado....
A medida que la arquitectura se fué ampliando y "complejizando" (apareció la memoria caché) hubo que agregar mas chips de control... un lío bárbaro...
El BIOS comienza a brillar por la carga de tareas delegadas que cada vez eran mas, contiene las rutinas de inicialización y testeo, "sabe" como "preguntarle" al chipset si tiene todas sus funciones disponibles y las inicializa adecuadamente.
El BIOS no hace nada espectacular, simplemente es un mayordomo el cual de acuerdo a los "huespedes" que tiene, son las instrucciones pre-grabadas que se le graba, de hecho su "gestación" es posterior a la elección del chipset que los ingenieros eligieron para auxiliar al micro.
El micro condiciona todo, así de simple, de acuerdo al micro se fabrican los "periféricos", de acuerdo a los "periféricos" se fabrica el BIOS.
.-