BIOS project sanity check.

Status
Not open for further replies.
Greetings,
I wish to make a device which can automate the process of boot configuration of computers. For example, I'd have a Teensy 3.6 and a VGA adapter which splits of the RGB signals to the Teensy. (Using voltage divider circuits to reduce 5v to <3V.)

1. Plug Teensy into computer's via USB.
2. Hold down a button to indicate the type of computer in question. (HP 6200, HP 6300, Dell, Lenovo etc.)
3. The Teensy powers up, loads pre-recorded VGA data samples from the SD card into memory for comparison later.
4. The Teensy waits for VGA samples to relatively match those stored in memory. It detects the BIOS logo.
5. The Teensy presses F2 until the VGA sample nearly match the BIOS screen for configuration.
6. Do: Up, Up, Up ,Up , Enter, F10, Enter, F10. Set BIOS configured flag in the SD card to tell it to skip configuration this time. (It'll power off on reboot due to using USB power from the computer.)
7. Teensy does that of previous steps but instead presses F12 to boot to the network or PXE.
8. The Teensy just monitors the VGA signals waiting for success. Beeps or alerts the operator. Optionally, the Teensy writes a pin high to an ESP8266 which informs a server the computer is ready.

Is this even possible? If so, I will need about 30 of these built. But having not used a Teensy before, I'm not sure of the accuracy of the samples and whatnot. So I thought I'd ask.

Thanks,
 
I would say no, probably not feasible. The ADC isn't fast enough to sample a PC's VGA output. You'll need something much more powerful than Teensy, with proper video capture hardware.
 
Most motherboards still have a speaker header to connect a tweeter that beeps if POST has succeeded. Maybe that can be of use?

Also, BIOS initialises the USB. If you could detect this, it would probably mean a successful BIOS boot as well.
 
I would say no, probably not feasible. The ADC isn't fast enough to sample a PC's VGA output. You'll need something much more powerful than Teensy, with proper video capture hardware.

Hi Paul,
This will not be viable personally if video capture is a requirement as that'll add $150+ per unit. (150x30+=a months wages :p) It also imposes some complications and the speed of the whole process. Is there an ADC I could use and just read the data over I2C etc?
 
Most motherboards still have a speaker header to connect a tweeter that beeps if POST has succeeded. Maybe that can be of use?

Also, BIOS initialises the USB. If you could detect this, it would probably mean a successful BIOS boot as well.

Thanks for the suggestions,
I've been looking for means of 'sensors' from a computer. Especially, those instead of reading VGA signals as that is complicated. However, all would have to be external to a computer just given the nature of the production and work unless it would provide all the data needed. Opening the case and connecting a header to the mobo would be equal to like removing a wheel of a car just to fill up the gas. Just isn't an option in the long run given the time and effort it takes. Imagine doing that to 500 random computers a day. Some may not have it. Some may not beep.

I could use something like an Raspberrypi 3 with the official camera pointing at the screen. OpenCV for image detection. Then trigger the Teensy at the right moments for the HID parts...
 
You will not be able to caputure VGA screens, but if you have the time to come up with the supporting hardware to condition video to logic levels it might work to:
Negotiate with video card to set resolution (may not be required depending on video card/how many hardware flavours this will jack into)
Monitor the sync lines to detect start of frame.
use port reads to capture logic level conditioned R,G and B signals at specific points on the screen and dump them into an array (if need be captureing across multiple screens if you need close pixels)
Use a lookup table to compare to prior captures and work out where in BIOS you are.
Send keypresses as required.
While Teensy certainly can't capture every pixel, it should be possible to work out where the menu highlight bar is on the screen if you pick the right line to look in (a line without letters), or at the very least if you are in a blue BIOS screen or a black POST screen.

All of this depends on a fair bit of op amp finalging of blue and at least one other colour channel to get levels right at a very high slew rate and then trying to reliable capture a line fragment on screen, and then process that captured fragment into some useful status information.

Difference between possible and achievable on a non Apollo level budget and workforce of course.
 
You will not be able to caputure VGA screens, but if you have the time to come up with the supporting hardware to condition video to logic levels it might work to:
Negotiate with video card to set resolution (may not be required depending on video card/how many hardware flavours this will jack into)
Monitor the sync lines to detect start of frame.
use port reads to capture logic level conditioned R,G and B signals at specific points on the screen and dump them into an array (if need be captureing across multiple screens if you need close pixels)
Use a lookup table to compare to prior captures and work out where in BIOS you are.
Send keypresses as required.
While Teensy certainly can't capture every pixel, it should be possible to work out where the menu highlight bar is on the screen if you pick the right line to look in (a line without letters), or at the very least if you are in a blue BIOS screen or a black POST screen.

All of this depends on a fair bit of op amp finalging of blue and at least one other colour channel to get levels right at a very high slew rate and then trying to reliable capture a line fragment on screen, and then process that captured fragment into some useful status information.

Difference between possible and achievable on a non Apollo level budget and workforce of course.

Some computers have GPUs, but they're very rare. So I'm targeting just the integrated graphics of Intel processors, which all happen to have DB-15 connectors / VGA.

The furthest that the computers boot is Windows PE. Which have a resolution of 800 x 600. Honestly, I could differentiate 95% of the screens with a single line of pixels. I bet I could even use the average of the RGB levels. Such as an HP BIOS screen is mostly black and blue, with some white. The BIOS menu is just 90% blue. So I would capture much more of the B, or blue, of the RGB from the VGA source than all the other colors. At least in theory. :p
 
The 'in thoery' part is certainly where the fun is at. For 800*600 line sync is 46khz, so you have 21uS to process that one line. So you get something like 2000 instructions to do what you want to do. Plenty if you want to inline assembler, not so much if you are throwing libraries at the problem. Google suggests VGA signals peak at 0.7V, so setting aref to internal (1.2V) and setting ADC to 3Bit (unsure now what the minimal bit depth is) might get you something ugly but functional for at least one read in the line.

Lots of things wrong with the above, impeadance is mismatch for one thing but if you have the hardware to could be turned into some form of proof of concept fairly quickly, see how coarse you can make the ADC read and how many reads you can squeeze into one line. Signal conditioning and impeadance matching to make this a digital read would get more samples on the one line but need more hardware complexity.
 
Based on the VGA out from Teensy recently done - it was 3 bits on Red and Green and 2 bits on Blue - once 256 color mode was negotiated along with the 800x600 resolution.
 
The screens are mostly static images. Can you build a minimal (cheap) specialized oscilloscope? Don't try to sample fast enough to capture every transition of every frame. Instead, identify the sync and sample randomly within each frame until enough information accumulates to make a wave form detailed enough to distinguish one kind of image from another. You'll probably also need to read the DDC information, but this is I2C so this should be the easy part. Sounds like lots of work getting the waveforms and then doing pattern matching on them. By the was, there is oscilloscope code for the Teensy. I don't remember the project name.
 
I've decided to go the Raspberrpi + Teensy because it's something I know how to do; Python. I don't have the gear nor knowledge yet of VGA to reverse engineer it.


So it'll be an Rpi Zero and official cam, a single unit that will hang off the top of a monitor and simply watches it. Opencv to do object detection for logos and screens etc. Then the Teensy, with soldered GPIO wires from the Rpi, is inserted in the back of computers to do the HID automation instead of the normal keyboard that we'd normally use. (Some Arduinos support boot keyboard protocols using 3rd party libraries as well.)


Very often the computers don't boot. They have memory or PSU issues etc. One appeal that makes me like this system is all the Rpi can easily wirelessly communicate to a central server. I can have a laptop, hosting an ad-hoc network, with the Rpi connected. So I can make a master program or UI to see where 30+ computers are in the process. Only manually addressing those with problems while the others continue to get configured. Additionally, some BIOS screens require an additional press of a key. It's kind of random. With OpenCV, I can detect such prompts easily and I can also see the state of the monitor by using the green and yellow light on the monitor itself. (If not green...)

Thank you all for your advice with VGA and assistance helping decide which path to take. Cheers!
 
Sounds like a great way to go! Keep us posted on your progress. We love pictures!

Will do. I'll make a github repo. Probably be a few weeks though.

Costs:
-Rpi Zero W: $10
-Rpi Camera: $25
-Teensy (or official Arduino Uno. Depends on bulk prices.): $20-$30
Odd and ends:
-Micro USB to USB Type-A M/M
-Rpi / Teensy Case.

One of the things that I'm really looking forward to is watching the Pis and Teensys complete 50 computers all at the same time. And when it comes time to print stickers for them, I can programmatically and sequentially tell the first computer, then second, all the way through 50, to add a job to the print spooler all with a single touch of a button from the server. Normally, you hit enter on all of them as you walk by waiting 5 seconds in between each. It would be mind blowing.
 
Once this is all working, put it up on Tindie or some other site that gives you a cut. You'll be a hero and recoup your development costs!
 
For those curious, had need for a system counting pulses out of an FPGA so fired up a 800*600 test pattern generator board (so failure didn't nuke a graphics card) and knocked up some code to locate single lines in the frame and then read a single colour as many times as it could as a digital read.

Which captured the colour bars being display to one bit depth between 24 and 26 times (32 pixels between samples). Which suggests that you could identify which BIOS menu was selected, but yes/no confirmation boxes might be narrow enough to be a problem, due to dither and spacing between pixel captures.

Many,many ways to tighten the code up but an interesting proof of concept. Suspect you could improve things to reliably hit 8 pixels/a character, but not a pixel in a character so can't reconstruct a word or anything really useful.

Code:
uint32_t redValues[120];
byte arrayIndex = 0;
elapsedMicros  sinceupdate=0;
bool LineSyncWaslow = true;
int lineSyncCount =0;
uint32_t longcount =0;
uint32_t longcount2 =0;
uint32_t linetime =0;
void setup() {
  Serial.begin(57600);
  pinMode(13,INPUT); //frame synce
  pinMode(15,INPUT); //line sync
  pinMode(16,INPUT); //Red
}

void loop() {
  while (digitalRead(13)==LOW); //wait for frame pulse start
  while (digitalRead(13)==HIGH); //wait for frame pulse to end
 
  sinceupdate=0;
  lineSyncCount =0;
  longcount =0;
  arrayIndex = 0;
  while (digitalRead(13)==LOW){ //for length of one frame
    if (digitalRead(15)==HIGH&&LineSyncWaslow==true){
      if (lineSyncCount==50) sinceupdate=0;
      if (lineSyncCount==51) linetime=sinceupdate;
      LineSyncWaslow = false;
      lineSyncCount++;
    }
    if (lineSyncCount==50)longcount++;
    if (lineSyncCount==51){
      longcount2++;
      redValues[arrayIndex]=digitalRead(16);
      arrayIndex++;
    }
    if (digitalRead(15)==LOW&&LineSyncWaslow==false){LineSyncWaslow = true; }
  }
   Serial.print(longcount2);
  Serial.print(' ');
    Serial.print(arrayIndex);
  Serial.print(' '); 
  for (byte i=0;i<arrayIndex+1;i++){
          Serial.print(redValues[i]);
           Serial.print(',');
     }
  Serial.println();
    Serial.print(linetime);
  Serial.print(' ');
  Serial.print(longcount);
  Serial.print(' ');
  Serial.println(lineSyncCount);
  delay(1000);
  
}
 
For those curious, just a small update about things I've discovered regarding the path I chose.

I went with a Teensy 3.2 and it works great for entering the Bios and configuring it. I simply liked the size and price to be honest over newer models. Still, it is easily over powered for the job, but no complaints here. It did not work on some computer models; odd desktops and many laptops. But in general, I'd say it's a good choice for the job. I'm really appreciative of those that made the keyboard library. Very easy to use. Question, just to be clear, I don't need to drop down 5V signals from the Rpi Zero W to the Teensy 3.2? I read its I/O was 5V tolerant from the site. But I'd like some reassurance there. :D

The Rpi setup, I did not calculate the actual view the Rpi camera would have of a monitor. In my head, the Rpi and camera in a case, sat just above the monitor looking down. But this produced an awful viewing angle of the monitor. The colors I was looking for in code would be unique to each Rpi! I could may make some calibration software but it's not really practical. Also the camera feels super zoomed in. Like I have to put the camera about 25" away from the monitor to get a full picture that was decent enough to even consider using OpenCV against. Adding, Haar cascades for OpenCV suck to make. You need 1000+ of image to train a cascade for object recognition. (Not an easy job just getting images.) But what this accumulates to is if your camera has an off or skewed vision of the monitor, than all the 1000 images must be skewed as well. For example, I scraped many search engines for Dell logos and many other brands. To use them without the Rpi 25" away from the screen, they'd all need to be precisely changed perspective using photo editing software. That is my main concern at this point in time.

i2Gml31.jpg
 
Teensy 3.2 can handle logic up to 5V, other models most certainly can't - that said Rpi is also 3.3V logic so normally a good match.
 
Status
Not open for further replies.
Back
Top