Re: All RTOS (linux Based ) Other than RT-Linux

Matt Giwer wrote:
The Natural Philosopher wrote:
Matt Giwer wrote:
Peter Köhlmann wrote:
Matt Giwer wrote:
The Natural Philosopher wrote:
Matt Giwer wrote:
...
Change the BIOS to no keyboard? Or something like that. The
keyboard is not a linux function. It only reads the BIOS.
Shows how little you know..most ROM BIOSES are TOTALLY bypassed by
linux. Their sole function is to get the OS in place with some form of
basic keyboard and screen control. In case intervention is needed.
I guess I have been confused by the necessity to have the BIOS reflect new
hardware before linux notices it is there.
And right here you made the next error
Odd that it is required. Perhaps you could take the time to explain.

Th BIOS merely provide a set of routines that are hopefully

- enough to get the machine to boot something else and
- MAY be used by whatever else runs to access the hardware, but its only MAY.

In fact most OS'es these days simply use the BIOS to bootstrap the boot loader, and maybe access the boot disk: Once the OS is loaded it is completely bypassed.

So in reality, all the BIOS dos in most systems is run the disk system and select a boot drive, and provide a minimal amount of screen/keyboard stuff for boot diagnostics.

What started this was my statement that the keypresses are found by accessing BIOS.

However my experience is that all hardware changes have to be registered in BIOS before they are recognized by the OS, linux or otherwise. I can see how once in BIOS the OS knows what to "look" for and then deal with it.

Not having actually followed the motherboard traces from the keyboard plug to see where they lead I cannot swear the BIOS is the only place where an OS can get the keypresses. However if the BIOS is not needed what his the physical access point the linux uses to get the keypress data?


Interrupt off the hardware controller that services the keyboard.

The vectors for these are held in RAM. They can be changed. You can install your own. Most systems do. IIRC the first thing a bios will do on boot is set these vectors up. Until it does the keyboard won;t work. As soon as the OS kernel comes in, it will rewrite some or all of them to point to its handlers.

What happens is that - say - a keypress is recogniosed by the keyboard peripheral chip. A small computer in its own right, whose job is to wait for keypresses and maybe mouse movements and the like. These days its probably the generic USB controller, and every time a block of data comes in,depending on how its programmed, it will either raise an interrupt line on every byte, or when its small internal buffer is full.

The interrupt lines go into another small piece of hardware - the interrupt controller - and that will register which peripheral has raised the interrupt, and pass a general interrupt along to the processsor, which will stop, shove its program counter in the stack, read the interrupt NUMBER from teh interrupt controller, and jump immdiately to the contents of teh NUMBERE'th row of a table held in (low?) RAM That might at one time have been pointing at BIOS ROM, but fter te OS has does its laoding, itr won;t be. It will point to the USB interrupt service routine.

What THAT des is read te USB device directly, and find out something about the device that caused the USB port to wake up. Decide its a keyboard key press and jump to a specific bit of code that will reda that byte of data, put it in a buffer, raise a flag to say 'keyboard data available' and then probabably call the scheduling part of the multitasker to tell it to resume any threads that are halted pending keyboard input. Then it will issue a return from interrupt and teh processor will resume what it was doing by popping its program cunter from the stack.

Now the next time the scheduler suspends the thread the processor was executing, it will immediately resume whatever task(s) was/were waiting for keyboard input. In whatever priority they were listed. Example: Some keys are flagged as super keys' and may be examined and acted on by the low level daemons..a break key for example will be examined by low level software t see if it means it needs to do Something Awful. So every process that MIGHT want to know what key is pressed or what button is clicked must examine all the inputs, and if they decide its not for them, leave it there and go back to sleep. Finally someone - say the application focus - gets the keystroke and says 'aha' I must type an A on the application..AND REMOVE IT FROM THE BUFFER. At this point its gone, No other application will get it, and if there are other lower priority task that might be waiting for it, they will either find no data, or won't even be woken up. If the keyboard interface is written well, it will call the scheduler when the command 'empty the buffer' is received and clear all wakeup flags from threads waiting for keyboard input.

Don;'t hold me to the exact details of this, buts thats broadly how it happened the last time I wrote this sort of stuff, which was 20 years ago on an 8086...:-)

The fundamental thing is that a BIOS ONLY has to carry enough code to boot the OS. Essentially that means

- set up a basic screen and keyboard and disk driver kernel
- read the NVRAM to find out where to boot from, and what type of built in driver to use.
-load and dive into the boot loader
- bye bye kansas.

After that the whole machine apart from the BIOS PROMS is available for modification, and in most cases, it will be modified completely.

In general the kernel will rush around interrogating I/O ports to find responses it recognises, and setting up handlers for what it finds: In case of unknown issues, it will refer to its disk based config files to load the correct stuff. Once it is relatively happy, it will launch the init daemon, which looks in ITS config files and carries on spawning daemons that get the machine up and running, until it finally spawns some kind of user interface.

At that point the BIOS is just a set of ROMS, idle and silent, and completely forgotten.

If for no other reason than the ROM bus speed is often WAY below the RAM bus speed: Using the ROMS will slow you down.

So, The onboard ROM BIOS only needs to understand the boot hardware. Of course you COULD talk about the hardware interface systems in the kernel as a BIOS as well, and be correct to do so, but BIOS on Intel machines of the PC variety is generally held to be that part that comes with the hardware in ROM: In a Linux context the terns 'device drivers' or 'device subsystem' and 'kernel' would be used instead to talk about various aspects of the kernel that deal with interfacing with the hardware.

I hope that helps.







.