Over the past last month or so, I have been work­ing on cre­at­ing the hard­ware and the soft­ware needed to be able to boot/re­boot/hard re­boot my com­put­ers at home. The rea­son I need this is that I am go­ing away for a few months, away from my com­put­ers, and I would like to be able to keep on re­verse en­gi­neer­ing nvidia’s ptherm.

A pos­si­ble soft­ware-only so­lu­tion is to use Wake-On-Lan to boot up the com­puter re­motely, ssh to con­nect to the com­puter, grub-re­boot to se­lect the ker­nel to boot on at the next re­boot and fi­nally, the watch­dog to re­boot the com­puter when it crashes. If it seems to you like a pain to use, I def­i­nitely agree!

So, a hard­ware-based so­lu­tion seems more in­ter­est­ing! The stan­dard so­lu­tion to solve this is­sue is called IPMI. The in­ter­est­ing fea­tures are:

• Be­ing able to cut the power down and put it back up again;
• Read back some of the state (Power & disk LEDs for in­stance);
• Hav­ing a se­r­ial con­sole.

How­ever, I don’t have an IPMI-ready moth­er­board as they are usu­ally used on servers. I thus de­cided to make my­self an equiv­a­lent. The only thing that was wor­ry­ing me was that I had to be able to con­trol that from the in­ter­net. So, one ma­chine had to be up and run­ning! I de­cided to buy a Rasp­berry Pi as it was the cheap­est and low­est-power con­sump­tion com­puter I could get with an eth­er­net port and a few Gen­eral Pur­pose In­put/Out­put (GPIO).

Us­ing those GPIOs, I can con­trol a cus­tom-made cir­cuit board to cut the power, press the power switch and read the power led state but the real ques­tion was about the user in­ter­face to wrap those GPIOs. I de­cided to make a web-based user in­ter­face be­cause it was more demo-able and also could be up­dated in real time for dis­play­ing logs and the power LED state.

Writ­ing the web in­ter­face

I choose to use Wt as it is a C++ wid­get-ori­ented web toolkit. This means that push­ing up­dates is very sim­ple (han­dled by the toolkit) and ac­cess­ing the GPIOs can be done with a na­tive li­brary, namely wiringPi. The rea­son I choose Wt was be­cause I loved it when I used it in my Wt com­ments pro­ject.

There isn’t much to say about the code ap­part from the fact it is lo­cated on gi­to­ri­ous un­der the name wt-rpm. Here is how the re­sult looks like:

The elec­tron­ics

With the soft­ware done and out of the way, it was time to work on the elec­tron­ics part that would take the Rasp­ber­ryPi’s GPIOs and would con­trol the moth­er­board / ATX power sup­ply.

My main de­sign goal was that I didn’t want to fry my RPi no mat­ter how stu­pid I was with the GPIOs. In­deed, the GPIOs are ap­par­ently very sen­si­tive and shouldn’t draw more than 3mA when in out­put mode. We dis­cussed about that at the Bor­deaux hack­er­space (LabX) and we agreed that the best so­lu­tion is to use opto-iso­la­tors.

I also wanted the Rasp­ber­ryPi to con­trol as many com­put­ers as needed. So I de­cided to have all the opto-iso­la­tion on the Rasp­berry Pi side and all the heavy lift­ing on the pc side. This means there would be N+1 boards for N PCs. I was then ad­vised to use an eth­er­net ca­bles to con­nect all cir­cuits to­gether.

Here is the de­signed elec­tron­ics cir­cuit:

• 
• 

Cut­ting the com­puter’s power

In or­der to cut the com­puter’s power, I first thought about us­ing a re­lay to cut the power be­fore the ATX power sup­ply. The prob­lem with that was that I would have needed an­other power sup­ply to com­mand the re­lay as it usu­ally needs a volt­age of 12 to 24V and con­sumes a lot of power (with re­gards to what a USB port can ac­tu­ally pro­vide).

Some­one at the LabX made me look into the pos­si­bil­ity of cut­ting the power af­ter the ATX power sup­ply. For those of you who don’t know, when plugged, the PSU de­liv­ers a +5V volt­age that al­lows the moth­er­board and some pe­riph­er­als to op­er­ate even when the com­puter is shut down (pur­ple wire). When the moth­er­board wants to boot up, it shorts the green wire with the ground. This is the sig­nal for the ATX power sup­ply to sup­ply­ing volt­age on the other pins. The com­puter then boots up.

The idea was to be able to cut the green wire so as it wouldn’t be shorted any­more and would re­sult in com­puter not be­ing sup­plied with power. If the com­puter was al­ready booted, it would come to a stop in­stantly.

As I didn’t want to fid­dle with my ATX power sup­plies, I cre­ated an ATX ex­ten­sion cord with a MOS­FET (a volt­age-com­manded tran­sis­tor) that would let through the cur­rent in the green wire but, when the gate would be forced to 0V, would cut the power sup­ply. To let through the cur­rent by de­fault, I just put a pull-up re­sis­tor (10 kOhm) at the gate of the MOS­FET. The gate is then con­nected to the out­put of the opto-iso­la­tor that would tie it to the ground when needed.

Here are some pic­tures of how it looks:

• 
• 

The ATX con­nec­tor pinout fig­ure has been made by Lazar Rozen­blat. Check out his awe­some page on ATX power sup­plies.

Press­ing the power switch but­ton

This part is more straight­for­ward. To elec­tron­i­cally act as the main power switch, we only need to short the two power SW pins found on the moth­er­board. This can be done with a sim­ple tran­sis­tor,

As I also wanted to be able to power-up the com­puter by press­ing the ac­tual but­ton, I de­cided to put the but­ton and the opto-iso­la­tor in par­al­lel.

Read­ing out the power LED’s state

There is noth­ing fancy here. The power LED pins are redi­rected to the in­put part of the opto-iso­la­tor. I also put in par­al­lel the orig­i­nal power LED. That’s not a proper so­lu­tion be­cause by do­ing so, the real power LED re­ceives mA than it should. How­ever, since the opto-iso­la­tor’s in­ter­nal LED only draws a few mA, it seems to work fine.

The fi­nal cir­cuit and its as­sem­bly

So, here is how the fi­nal cir­cuit looks like:

• 
• 

I de­cided to mount it on a bracket so as it wouldn’t float around in the com­puter. I both sol­dered and hot-glued the eth­er­net con­nec­tor to the bracket to make it as sturdy as pos­si­ble. Sol­der­ing was hard as the bracket was cool­ing the sol­der­ing iron but af­ter putting the tem­per­a­ture to 450°C and be­ing a bit pa­tient, I man­aged to get a proper sol­der­ing.

The fi­nal cir­cuit (a close ver­sion of it) can be found in the repos­i­tory of wt-rpm, as two sep­a­rate fritz­ing pro­jects.

The (nec­es­sary) video

Adding a se­r­ial con­sole

Now that we can force a com­puter on and off, we need a way to se­lect which ker­nel should be booted and be able to de­bug is­sues that could hap­pen be­fore ssh is up and run­ning. For that, I de­cided to use the se­r­ial port of my moth­er­boards.

I found on ebay some very cheap RS-232-to-USB con­vert­ers, for about 3€ each. The only prob­lem with them is that they use the stan­dard db-9 con­nec­tor and none of my moth­er­boards ac­tu­ally had one. In­stead, they had a con­nec­tor at the bot­tom ex­pos­ing the dif­fer­ent pins. So I made a very sim­ple null mo­dem ca­ble (just used the ground, RX and TX) that would con­nect on the moth­er­board’s ex­posed pins and con­nect them to the adap­tor.

I got it to work quite re­li­ably, how­ever, from time to time, grubs re­ally looks gar­belled, I won­der if it is due to the very cheap­ness of the adap­tors or if it is a prob­lem due to the fact I have no hard­ware hand-shack­ing on my ca­bles. When I come back, I’ll try to have a look at it!

That’s all folks!