Hardwere switch for dual boot.

[georgian]

Hello guys,

dose anybody know a "easy" solution for an hardware switch dual boot?
I could use an spdt switch to switch between two ssds before each boot but this way it will require one more ssd for shared data. If there is any other way to monitor the DTR pin from RS-232 port (or something like this) on each boot and then automatically selected the OS to boot accordingly, i could use only one SSD with one extra partition for shared data. I want to have windows server and Linux saver to learn and play with. I don't plan to keep the server near my working PC and have a keyboard and monitor attached each time I want to chose the OS.

Maybe there is any software that dose it and have it running on each OS, like apple has the bootcamp thing. This way i could reboot in another OS remotely.

Thank you in advance,
Georgian.

[Ian.M]

Probably the easiest option would be to program an ATmega32U4 based Arduino (e.g Leonardo or Micro) to emulate a HID keyboard, read the switch and send the required keystrokes to select an OS to a boot manager e.g. GNU GRUB.

Alternatively, GRUB can be fully controlled from a serial console, which you could access over a hard-wired connection or via a TCP/IP to serial  bridge.

[Zbig]

Do you have any specific use case or requirement to go for dual boot instead of virtualization in this day and age?

[georgian]

Thank you for your answers.
I did think about the Leonardo as keyboard. The GNU grub method sounds good too. I have an industrial motherboard that i want to use and there is a custom bios on it without access to any settings. Just load setup defaults and save the settings. I'll see if this method works and if so how to chose what to boot.

There is no specific or use case. For now I'm using a raspberry pi as server to test C cgi code and and learn some mysql. The pi lacks support for windows server and I want to play around with windows server too. I don't have modern hardware to support virtualization.

[Red Squirrel]

One way might be to keep both OS drives plugged in, but have a A/B switch that provides power to only one at a time.  I think that would work.

As for VMs sometimes there is a need to have raw level access, such as if it's a workstation or for gaming.  Working out of a VM is kinda cumbersome and you need some form of physical machine to physically interact with anyway.   

[rdl]

I have a machine with an Icy Dock in one of the front bays. It's a two slot 3.5 inch. I just insert whichever drive I want to boot from. I think switching the power would work as well.

[bw2341]

One way might be to keep both OS drives plugged in, but have a A/B switch that provides power to only one at a time.  I think that would work.

You can buy one! Search for "hard drive power switch" on Ebay or Aliexpress. You'll get no name switch boxes that fit in a drive bay or back panel card slot. I haven't used any of these myself.

The last time I was looking for these, I remember seeing fancy models with MOSFET switching and soft touch buttons. It looks like we're left with the cheap passive physical switch models now.

[Nominal Animal]

Assuming it has free USB ports, I would use an ATtiny85 (a DigiSpark clone) with micronucleus on it (e.g, by getting a DigiSpark clone and programming it in the Arduino environment), and a slightly modified Grub to boot it.

You see, Grub has grub-core/commands/usbtest.c which only needs small changes to become a Grub scripting command that returns if an USB device with a specific vendor:product and version string is found.  That way, a simple Grub snippet can change the default OS to be booted, without interfering with the keyboard etc.

The DigiSpark clones (costing < USD $2 / EUR 2€ on eBay) have 5 free GPIO pins, so I'd connect a coded rotary switch – or, if you really just need to choose between two or three, a toggle switch – to (some) of the pins.  (The three-way one you wire backwards, with its common to e.g. VCC, and the three to separate GPIO pins, with pulldowns enabled or external pulldown resistors.  That way, exactly one of the pins is high with the two others low, depending on the switch state.)  Coded rotary switches with 2ⁿ positions typically have n+1 (or n+2) pins, with the common pin going to VCC or GND, and the other pins connected or disconnected based on the switch state.  (I used one on my first ATmega32u4-based USB Arcade Joystick, to choose the keycodes it would produce.)

When the DigiSpark is powered up, I'd have it report a specific (custom) Vendor:Product, with a version number depending on the GPIO pin states.  Optionally, if the pin states change, it'd simply detach and re-enumerate itself.

This way, the boot switch would not interfere with anything at all.  The Grub changes are quite simple, and the developers might even accept the new command – say, usb-find --vendor VVVV --product PPPP --serial S... which returns True if such an USB device is connected, and False otherwise – upstream, so you wouldn't have to re-add the command in everytime you update grub (which should be very rarely, though).

It'd make for a very interesting and not too hard project, if you're interested in microcontrollers (or Arduino environment programming), and don't mind patching Grub.  (It's not really a change per se, more an addition to the Grub sources.)

[bitwelder]

I'm not sure that I understand the way it should be controlled, but in one case I set up a 'remote' lab PC that had two harddisks, one with Linux and one with Windows.
The Linux side had boot entries for both itself and the Windows side, and so it was possible to 'program' next boot with the command "grub2-reboot <boot-entry>". Only downside was that it took just an extra boot cycle to go from Windows to Windows again.

[Nominal Animal]

Wait, does the board have a physical RS-232 serial port, with an 8250/16550 compatible UART, on the motherboard?

If it does, then you indeed can just use one of the status pins on that port, if you make sure the Grub iorw module (iorw.mod) is enabled.  Then,
    inb -v MCE 0x3FE        (for first serial port)
    inb -v MCE 0x2EE        (for second serial port)
    inb -v MCE 0x2FE        (for third serial port)
    inb -v MCE 0x3EE        (for fourth serial port)
saves the port status pin states in Grub variable MCE, in hexadecimal, without a leading 0x.  The four low bits should be zero.  The high four bits correspond to CTS (bit 4), DSR (bit 5), RI (bit 6), and DCD (bit 7).  On an 9-pin serial connector, CTS is pin 8, DSR is pin 6, RI is pin 9, and DCD is pin 1; except that pin 1 and/or pin 9 may be connected to a positive supply voltage.

So, let's say you connect a SPDT switch, common to pin 8 on the 9-pin serial port connector, and the two options to pin 5 (signal ground) and pin 1 or 9, whichever has a positive voltage on it.  In your Grub configuration file,
    serial --unit=0
    inb -v MCE 0x3FE
    set MCE=0x$MCE
    if [ $MCE -eq 16 -o $MCE -eq 48 -o $MCE -eq 80 -o $MCE -eq 112 -o $MCE -eq 144 -o $MCE -eq 176 -o $MCE -eq 204 -o $MCE -eq 240 ]; then
        set default=1
    else
        set default=0
    fi
and the default will be either the first or the second boot entry, depending on the position of the switch.

If you do the same for pin 6 as you did for pin 8 above, then
    serial --unit=0
    inb -v MCE 0x3FE
    set MCE=0x$MCE
    if [ $MCE -eq 16 -o $MCE -eq 80 -o $MCE -eq 144 -o $MCE -eq 208 ]; then
        set default=1
    elif [ $MCE -eq 32 -o $MCE -eq 96 -o $MCE -eq 160 -o $MCE -eq 224 ]; then
        set default=2
    elif [ $MCE -eq 48 -o $MCE -eq 112 -o $MCE -eq 176 -o $MCE -eq 240 ]; then
        set default=3
    else
        set default=0
    fi
gives you four possibilities.  Note that one switch could be for a "fast boot" to the selected OS, with no wait in Grub, and the other just selects the boot entry.

[andersm]

If you install an ext3/4 driver in Windows, it should be possible to set the next_entry variable in grub's environment file to select which OS will be started on next boot.

[georgian]

Wait, does the board have a physical RS-232 serial port, with an 8250/16550 compatible UART, on the motherboard?

If it does, then you indeed can just use one of the status pins on that port, if you make sure the Grub iorw module (iorw.mod) is enabled.  Then,
    inb -v MCE 0x3FE        (for first serial port)
    inb -v MCE 0x2EE        (for second serial port)
    inb -v MCE 0x2FE        (for third serial port)
    inb -v MCE 0x3EE        (for fourth serial port)
saves the port status pin states in Grub variable MCE, in hexadecimal, without a leading 0x.  The four low bits should be zero.  The high four bits correspond to CTS (bit 4), DSR (bit 5), RI (bit 6), and DCD (bit 7).  On an 9-pin serial connector, CTS is pin 8, DSR is pin 6, RI is pin 9, and DCD is pin 1; except that pin 1 and/or pin 9 may be connected to a positive supply voltage.

So, let's say you connect a SPDT switch, common to pin 8 on the 9-pin serial port connector, and the two options to pin 5 (signal ground) and pin 1 or 9, whichever has a positive voltage on it.  In your Grub configuration file,
    serial --unit=0
    inb -v MCE 0x3FE
    set MCE=0x$MCE
    if [ $MCE -eq 16 -o $MCE -eq 48 -o $MCE -eq 80 -o $MCE -eq 112 -o $MCE -eq 144 -o $MCE -eq 176 -o $MCE -eq 204 -o $MCE -eq 240 ]; then
        set default=1
    else
        set default=0
    fi
and the default will be either the first or the second boot entry, depending on the position of the switch.

If you do the same for pin 6 as you did for pin 8 above, then
    serial --unit=0
    inb -v MCE 0x3FE
    set MCE=0x$MCE
    if [ $MCE -eq 16 -o $MCE -eq 80 -o $MCE -eq 144 -o $MCE -eq 208 ]; then
        set default=1
    elif [ $MCE -eq 32 -o $MCE -eq 96 -o $MCE -eq 160 -o $MCE -eq 224 ]; then
        set default=2
    elif [ $MCE -eq 48 -o $MCE -eq 112 -o $MCE -eq 176 -o $MCE -eq 240 ]; then
        set default=3
    else
        set default=0
    fi
gives you four possibilities.  Note that one switch could be for a "fast boot" to the selected OS, with no wait in Grub, and the other just selects the boot entry.

This looks exactly like what I imagine. Doesn't sound very easy but i'll get there. I have to wait for my windows server DVD to arrive and I should be up and running. The motherboard has 4 physical RS-232 serial ports on board. No DB-9 socket on the it but all on one 40 pin header. No idea if they are 8250/16550 compatible, but why shouldn't they be?

To pull the pins high or low i will be using some esp-07 and small signal relays.

Thank you all so far and i'll be reporting my progress soon.

[NiHaoMike]

As for VMs sometimes there is a need to have raw level access, such as if it's a workstation or for gaming.  Working out of a VM is kinda cumbersome and you need some form of physical machine to physically interact with anyway.   

Might want to look at something like Xen which is designed to work at a much lower level than your typical VM solutions.

[Ed.Kloonk]

Not sure how much cost might be a factor but I wanted to point out that the modern single board computers can mean you could have a discrete Linux system running for nearly the price of a hardware switching solution.

If you're interested, check out explaining computers on youtube for some honest reviews on the latest gizmos. You can evaluate if you want to keep going with x86 or select an ARM based board if you can select a suitable distro.

https://explainingcomputers.com/

[Berni]

As for VMs sometimes there is a need to have raw level access, such as if it's a workstation or for gaming.  Working out of a VM is kinda cumbersome and you need some form of physical machine to physically interact with anyway.

There is VM software out there that can pass trough devices into the VM. Most VMs support USB passtrough, but some also support entire PCIe slots to be put into the VM.

For example LinusTechTips used KVM to run 10 full on gaming VMs on a single CPU:
https://linustechtips.com/main/topic/599553-8-or-is-it-10-gamers-1-cpu/

Granted it did take a monsterous CPU to run that many threads and a weird motherboard to provide enough PCIe slots for that many graphics cards plus USB controllers for that many VMs. Such niche odd hardware was also a lot of headace to configure correctly. But in the end it worked, 10 gaming VMs running off a single PC and running modern games perfectly smoothly at full performance with no latency or stutter issues.

With KVM its possible to auto start and passtrough everything on startup. So you can even make a PC that starts botting trough a linux console, then suddenly shows the Windows 10 startup screen and boots into it and keeps running like that. Once booted you wouldn't even know you are inside a VM as all the USB ports would work as expected, only thing is that you would be missing some CPU threads. All while in the background KVM is also running 2 other linux VMs in the background of what is seemingly a Windows 10 PC once booted.

Besides when it comes to servers most of it runs of VMs anyway. The performance penalty of a VM is next to zero due to every modern CPU having hardware support for virtualization while running servers as VMs makes working with them a lot easier. They can be moved onto new faster hardware without the server even noticing or even having been shut down. If the server crashes to a point it wont even boot you can still remotely fix everything easily by just rolling the VM back to a known working state at the click of a button. Updates can be applied to a clone of the VM and tested they work before swapping that VM into live production. Servers for different tasks can be easily kept separated without needing multiple physical machines, so if one crashes or gets hacked or whatever bad happens to it the other servers keep running. On larger scales where multiple machines run multiple VMs then if one machine catches fire the VMs can be moved over to other machines automatically and restarted, once the machine is fixed and back up the VMs can be moved back onto it....etc

[Nominal Animal]

To pull the pins high or low i will be using some esp-07 and small signal relays.

I would use P-channel MOSFETs (say, BSS84) using the 40-pin serial port connector voltage, each with a transistor to pull the gate down to ground to enable it, with optionally a digital isolator (say, Si8630) between the transistor bases and the microcontroller.  Three pins would give eight states, with just one isolator, three MOSFETs, three transistors, and nine (I think) resistors; maybe 1µF or 100nF decoupling capacitor or two.  Assuming there is a +15V (or whatever voltage the serial ports use) supply pin available.

Do you have documentation on the 40-pin(?) connector pinout?  Could you use a multimeter to measure if any of its pins has a supply voltage, and what that supply voltage is?  (Typically it is one of 5V, 9V, 12V, or 15V.)

If the board has a hardware parallel port, that would be even easier to use, because the voltages are between 0 and 5V on the parallel port.  Then, you could use a simple digital isolator (Si8630 for three bits, Si8640 for four bits, Si8650 for five bits, Si8660 for six bits) between the MCU and the parallel port.  (In Grub, you'd use iob -v LPT port to read the status pins (11, 10, 12, 13, 15), where portis 0x3BD, 0x379, or 0x279.)

If you need the parallel port for other stuff (and that's why you didn't mention it), add one (3 bit) or two (all 5 status bits) CD4053B to the status bits, with one bit from the digital isolator to control if the status bits are controlled by the parallel port device, or the microcontroller.  Something like this:

This parallel port circuit is nice in that if there is nothing on the MCU side of the circuit, the DB25F connector is pass-through to the computer.  When the MCU pulls MCU_EN high, then the computer sees MCU_B3 through MCU_/B7 (the last one inverted!) in port 0x3BD/0x379/0x279, allowing the MCU to pass a 5-bit value to Grub, but release the parallel port for normal use afterwards.

[georgian]

Thank you all for your rich-full answers.

I do not have an LPT port. I do have the pinout of the COM1-4 header (see attached foto) and there is no voltage pin on it, but that is not a problem. I could get 12V from somewhere else on the motherboard. (It uses a single 12V power supply.)

Fintek F81216AD should be the controller for the COM ports and is an LPC to 4 UART + 9-bit Protocol IC.

It might be easier to use some Virtual machines but I have no experience with this things and I don't really want to learn now.
The main reason for this thing is to have Linux and Windows server each with a C compiler and mySql database so I can learn to code CGI software that is portable. I'm sure there are many other ways and alternative languages like python and so on, but I like to stick with C.

Thanks again and I'll report back this weekend with my progress.

**EDDIT: Yes the COM ports are 16550 asynchronous. So I shouldn't have any compatibility problems.

[magic]

If you don't like grub you could always code an equivalent in x86 assembly, write it to the MBR and make it chainload either grub or the Windows boot sector

I do have the pinout of the COM1-4 header (see attached foto) and there is no voltage pin on it, but that is not a problem. I could get 12V from somewhere else on the motherboard. (It uses a single 12V power supply.)

A common trick in COM port dongles is to set two pins to opposite states such that they provide ±12V for your circuit. This would take writing something to the UART's registers before reading its state, but I'm not familiar with the details.

And I just came up with an almost 100% hardware solution:
use grub or any other multi-OS bootloader (even the one in Windows can be configured to chainload a Linux bootloader) and modify some old unused keyboard such that a switch or relay shorts its down arrow.

[S. Petrukhin]

Doesn't the F8 or F5 key allow you to select an OS to boot that can be installed on the same SSD at the same time? In addition, you can use Oracle VM VirtualBox to run a second OS inside Windows.

[Nominal Animal]

Like Magic mentioned, we only need to initialize the serial port, and we can use TXD for our voltage source; this is because RS-232 TX is idle high.
(Edited: As Ian.M mentions, UART is different to RS-232, and I was thinking of UART and assuming RS-232 was just voltage-level converted.  Ouch.  Apologies.)

Therefore, I personally would try something like this, except instead of TXD take the supply voltage from somewhere else, perhaps the DTR or RTS pin:

Note that I am just a hobbyist wrt. the electronics, so any comments/criticism regarding the circuit is welcome, and probably warranted!
You might wish to pull CTS to ground (instead of leaving it floating), by the way.  I'm not sure if Grub supports simple math (outside comparisons), so that would ensure bit 4 in the status register would be zero, making comparisons easier.  (I do believe the low 4 bits are zero on read; need to check part D of Ralf Browns Interrupt List!)

The 680 Ohm resistors are intended to limit the current to 5mA per pin or so.  ACPL-247 has 1.0V to 1.2V forward voltage at 5mA, and (5 V - 1.2 V)/(680 Ohm) = 0.005588 A ≃ 5.6 mA.
1 kOhm resistors would also work fine, yielding about 4mA per pin.
The 4.7 kOhm resistors are a best guess based on the datasheet, and the fact that we don't want to try and pull too much current off the TX pin.  If there is leakage through the optocoupler, one might add small-signal diodes (ordinary ones, not Schottkys, just for the voltage drop) between the optocoupler outputs and CD4053B inputs; or say 47k pull-down resistors to (serial) GND.
I'm not sure, because I just a hobbyist. 

[Ian.M]

Crazy-Crazy!  There wont be a positive voltage on TXD once the port is initialized unless a break condition is set.  Logic level serial port data lines idle high, however on a RS-232 serial port the levels are inverted,  positive voltage is logic '0', and negative voltage is logic '1'.  PC serial ports tend to accept 0V as logic '1' even though the official standard (currently TIA-232-F 1997) says that's out of spec. 

As you don't need to receive data from the PC, you can simply drive the lines you need from a suitable logic level converter, e.g. a 74HCT gate via a *SHORT* cable.   There's no need for isolation unless you are using cabled remote control, in which case, you'd be best off pulling the lines up to +12V locally and using high CTR optocouplers directly to pull them down when required,  each driven with current via a twisted pair in the cable, with a resistor across the LED so it doesn't turn on if the current is below the threshold.   

[Nominal Animal]

Crazy-Crazy!  There wont be a positive voltage on TXD once the port is initialized unless a break condition is set.

Right, thanks.  I did some more digging, and it looks like DTR and RTS could be used instead (were used in the olden days to power serial mice).  What do you think?

There's no need for isolation unless you are using cabled remote control

The OP mentioned they're using ESP-07, which is likely externally powered, so it can power up the board and control which OS it boots into, via WiFi or Bluetooth.  In this case, it is better/safer to have isolation, in my opinion, than rely on using isolated wall wart or battery for the MCU so that it will always share ground with the computer.  At least I like to use isolation, being my bumbly self...

[Nominal Animal]

All the above written, I think an USB HID device based approach is superior.

In Grub, you can do

Code: [Select]

if keystatus; then
    keystatus --alt
    state=$?
    keystatus --ctrl
    state=${state}$?
    keystatus --shift
    state=${state}$?
else
    state=xxx
fi
to obtain the Shift, Control, and Alt, modifier key states.  The state variable will contain three characters, first character corresponding to Alt, second to Ctrl, and third to Shift.  If the corresponding key is pressed, it will be 0; if not pressed, 1.  (This is because in general, True corresponds to exit status 0, and False to 1.)  If the state checking is not supported, state will be xxx.  This yields eight "modes" Grub can choose from trivially:

Code: [Select]

if [ x${state} == x110 ]; then
    default=shift
elif [ x${state} == x101 ]; then
    default=ctrl
elif [ x${state} == x100 ]; then
    default=shift+ctrl
elif [ x${state} == x011 ]; then
    default=alt
elif [ x${state} == x010 ]; then
    default=shift+alt
elif [ x${state} == x001 ]; then
    default=ctrl+alt
elif [ x${state} == x000 ]; then
    default=shift+ctrl+alt
fi
where default is the special Grub variable that chooses which boot entry is used unless user intervenes.  You can obviously do anything you want inside the if clauses.

For USB keyboards, the modifier key state is contained within each keypress/release report.  This means that if you have two keyboards, and press a modifier key on one, pressing a standard key on the other will/should not have the modifier key applied.  Semi-unfortunately, Grub does combine modifier keys from all active terminals, so it is kind of important to have the USB HID device send the modifier key reports only until Grub has started, i.e. for say a second longer than the BIOS/EFI takes to run on the machine.

In a separate thread, I asked feedback for an ultra-cheap USB gamepad using WCH CH551G microcontroller with an 8051 core that one can buy from LCSC for under USD $0.40 apiece. This has a native USB interface, and the MCU series were extensively discussed here in this thread.  This would be basically perfect for such an use case.  You could, for example, connect it to any ESP via UART or SPI.

In fact, this gives me a project idea I could use with my ARM-based SBCs (that use U-Boot and not Grub, though): CH551G mini display controller with bootloader graphics, for use with small OLED or TFT display modules (controlled via 4-wire SPI):

One would need to add USB commands to Grub/U-Boot for loading prepared images and USB HID commands to for a proper query-response interface, but that would not be a big endeavour.  Without any changes to Grub, this circuit can be used for the Shift/Ctrl/Alt "messaging".

During proper OS use, the display could be exposed as a tiny framebuffer via USB Serial, HID, or even just as a bulk USB endpoint, so that one could use the display with e.g. a simple Python or C program, to show the appliance status...  One of my SBCs has 1.8V UART only, so the schematic includes 74LVC1T45 level shifters.  CH551G and CH552G have the same pinout, but CH552G has an ADC; P3.2 and P1.4 (and P1.1, connected to VUSB via a voltage divider) can be used for analog inputs.

[Nominal Animal]

As to the microcontroller to serial port interface, the following might make a lot more sense than the one with CD4053B above. 


Note that the resistors are not in voltage divider configuration: the resistor to ground is first.

[Ian.M]

I'm still not too happy with your latest circuit.

RS232 outputs are either current limited or have considerable series resistance as the standard requires them to be short-circuit proof.   Typically the output voltage will drop about a volt for every mA of load current.  Therefore the above circuit may not reach a high enough voltage to be 'seen' as logic '0' when three or more of the OPTOs are on.  The 4.7K resistors in series with the inputs do nothing useful and may form a potential divider with the input resistance, reducing the signal level. 

IIRC the DTR output should also be high, so combine DTR and RTS with a BAT54C common cathode dual Schottky diode to maximize the available current to feed the phototransistor collectors, and get rid of the series resistors.   Worst case, if the serial port has particularly weak outputs, you may need to increase the pulldowns to 10K.