English / Deutsch

The New Boot Manager

This page is just temporary. The URL will change in the future. The new boot manager will be different to the Plop Boot Manager series. It became an own product. The name is not defined now.

The Boot Manager should work on BIOS and UEFI systems.

The new boot manager will be written from scratch. Planed features are

  • Full USB 1.1/2.0/3.0 support (thumbs, hard disks, floppys, optical drives, keyboards, hubs, maybe mouse)
  • PC-Card (PCMCIA) flash disk support
  • PCI Express support
  • VHD support
  • (U)EFI support
  • GPT support
  • Simple text mode, enhanced text mode, gfx mode
  • Support various file systems (FAT12-32, Ext2/3/4, limited NTFS, limited HFS+)
  • Native Linux Kernel boot
  • Native AHCI support
  • Modular
  • Simple shell

Donations are welcome: Donate

2017-12-29  -  NASM Helper

At the beginning of the new boot manager development, I wrote some macros to make the use of function calls easier in Assembler. The macros are written for NASM. Now, I released them under the name "NASM Helper".

NASM Helper

At the bottom of the page, you will find a complex routine called QueueControlTransfer. Its from my OHCI USB driver. I know, its useless without the other functions, but its a nice example for a more complex function.


OHCI Enumeration bug fixed.

Rewriting UHCI code done.

2017-12-18  -  Bug killed

I found the bug, without converting the old code. I figured out that the host suddenly stopped sending frames. Very mysterious. Finally I found the reason for this behavior. Unintentionally, I set the USB port into suspend mode. I used "OR" to write a bit, without modifying the other bits, in the port register. But for this register, its required to set the bit with "MOV" without other bits set. The strange thing is, that the "OR" works on other hardware, which seem to be more tolerant in this case. This bug wasted a lot of time, but it works now. Now there is a new issue with the enumeration process on that machine, but it should not be difficult to fix it.

Asking again, is the code from 2007 better? No, the new code is better now :)

2017-12-16  -  Hmm, bugs

Hmm, what should I say. I hoped to have finished a lot of things. But I didn't. I was ill in November. Then I had various things to do in the rest of November and in December. And now I am struggeling with a crazy "new boot manager" driver bug since a week. Its the OHCI USB driver. I thought it works fine, but then I used it on my old Gericom Webboy Laptop. A simple USB resquest ends in a DeviceNotResponding error. The frustrating thing is, my driver of 2007 works flawless. I cannot figure out whats wrong. Data structures and register values are the same. Frustrating. I am not able to fix that for one week!!!! The old code was written for LZASM. Now I am using NASM. Since days I try to find the bug without converting the old code to NASM. But I fear, I reached the point to accept that I have to convert the old code to find the difference....

Is the code from 2007 better? Hmmm, yes and no.

2017-10-13  -  What do I have so far

Its time for a development status.

The code is written in pure assembler. I am using NASM. The goal is to operate in various CPU modes on i386 CPUs and better. Most of the code is currently tested in the 'unreal mode' (16/32 bit). With just a few modifications, the code will run in native 32 bit too. This code will also run fine on 64 bit CPUs.

The device access (except video mode switching) happens native without BIOS. This is required to work in various CPU modes in the same way, regardless if I have a BIOS in the background or not. Why do I need various CPU modes? Because I want to support old and modern computers. DOS should be able to use the boot manager drivers without additional software. But don't dream about DOS and UEFI. This will not work.

Basic system routines

Memory management: Done.
PCI device enumeration: Done.
CPU mode switching: Done.
Basic text mode output routines: Done.
Graphic mode (VBE): Mode detection, initialization, pixel drawing, text drawing done.
Image files: Reading and display TIFF images done. TIFF format: uncompressed, RGB, Intel.

Driver development stage 1

Keyboard PS/2: Key read done.
PATA (IDE) HDD: Read and write.
PATA (IDE) optical drives: Not done.
SATA AHCI HDD: Read and write.
SATA AHCI optical drives: Not done.
Classic floppy drive: Not done.
USB 1.1 UHCI: Most done, but I am unhappy with the code. I have to rewrite the most.
USB 1.1 OHCI: Initialization, control transfers, interrupt transfers, bulk transfers, USB device enumeration done. Some things are left to do.
USB 2.0 EHCI: Initialization, control transfers, bulk transfers, USB device enumeration done. Lets say over 50% is done. Difficult things like split transactions and other things are left to do.
USB 3.x: Not started.
USB Keyboard: Detection and key read works. TODO: Key mapping.
USB Mass Storage: Basic functions like device identify works. This implementation shouldn't be a big deal.
USB HUB: Starting in the next days.

What means development stage 1? In this stage the drivers are working in their own environment. But its too early to put them together.

2017-10-06  -  A driver development adventure

Last week I started to write the USB 2.0 EHCI driver from scratch. Everything looked fine and worked as expected, but then I tried it with VirtualBox. You know, the Plop Boot Manager 5.0.x hangs when you use the USB 2.0 EHCI driver to boot from USB in VirtualBox. I tried my new code and ........... it hangs too.

I said okay, I try to figure out whats wrong. I am motivated and I want to fix this problem. Then I struggled with the problem for one week. It was frustrating. The queue heads haven't been processed. Only malformed queue heads resulted in a transaction error. But nothing happened on correct queue heads with correct transfer descriptors. For some time I thought the port reset is the problem and the USB device is in a problematic state. You have to know, in VirtualBox, the port reset ends immediately after starting the reset. According to the EHCI Specification, the reset has to be ended by the software and not the host. Then I thought that the host cannot transmit to device 0 because the USB device is still configured with an address because of the strange port reset behavior. So I created queue heads for every possible device number. Hmmmm, I received no errors and no transactions. Nothing! When there is no response, then its really frustrating.

Accepting that my code does not work in VirtualBox became an option for me. But finally I can not accept it. Meanwhile it looks like I am in an endless loop. Doing the same things with the same disappointing result. Then by luck, I made a mistake. And now comes an important information for those who plan to write an EHCI driver. As first transfer descriptor, I linked a transfer descriptor without any data except the 'Next qTD Pointer' to a SETUP transfer descriptor. And suddenly, the SETUP transfer descriptor has been processed as expected. Strange. When the first transfer descriptor is empty, then the following transfer descriptors are processed.

I don't know why, but this works on other EHCI controllers too, so I accept that and I am happy that my code works now also in VirtualBox. I will fix the EHCI driver of the Plop Boot Manager 5.0.15 that the USB 2.0 boot works also in VirtualBox. But thats enough for today.

2017-09-17  -  UEFI

I spent some time for UEFI and created a simple menu to boot Plop Linux and Windows with UEFI. This was just a funny test. There is no dynamic OS detection or config file. All is hard coded, just to see how software development with UEFI works.


Programming the new boot manager, but it's a slow process. Nothing to show at the moment...


New development start is April 2017.


My desk. Developing a driver at night.

During rewriting the USB drivers, I found some bugs in the old code. The chances are good, that I release a 5.1 version of the old 5.0.15 boot manager with fixed USB drivers. But who knows...


No news, no time to update this page. Coding has been stop at beginning of 05/2016. Maybe I find time in august 2016.


Continue coding :)


Coding paused because of other work.


I created a concept art of the GUI. The final product will look different, but this could be a nice design. No line of code has been written for the GUI, booting has priority ;) A release date is far far away.

There will be also a hidden mode and a simple text mode interface like in the current Plop Boot Manager.


Work in progress...

© 2018 by Elmar Hanlhofer
This page was last modified on 29/12/2017.