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
Donations are rare and welcome: Donate
2018-06-18 - FAT16, Linux Kernel, NTLDR
No update since one month. What happened? Nothing special. Just some booting. But don't expect too much!
FAT16 reading works fine. I can change directories and read files. FAT16 writing and FAT12/32 support is left to do. But with the FAT16 reading support, I was able to do some interesting things.
Native Linux Kernel booting works (from FAT16). I can load the kernel and an initrd file and boot Linux. I can also set the Linux Kernel Command Line.
Native Windows XP booting with direct loading of the NTLDR works (from FAT16). More recent Windows booting should work too. That's not an important feature, but nice to have.
MBR loading and booting works too.
What comes next? There are still a lot of things to do. I am far away from any beta testing. Many things that are working are splitted up in own parts and have to put together. But this comes later.
Next steps are
• Boot sector loading and booting. That should not be difficult.That's a heavy to-do list for the next steps!
2018-05-07 - Are you dreaming in hex?
Maybe sometimes! Hexadecimal is part of my life. File Allocation Table Artwork :)
I started with FAT file system support. Currently required for native Linux kernel loading tests. The boot manager will need FAT support too. I began with FAT16. Directory listing works. Of course with long file name support (optional only 8.3 format). Cluster reading works too. Next step is a working "read file" routine. And then modify the code for FAT12 and FAT32.
2018-05-03 - MBR Partition Table / GUID Partition Table
The Master Boot Record partition table support has been finished. Classic and cascaded extended partitions are supported. Now, I am numbering the partitions in the same way as Linux. Primary partitions get a number from 1 to 4, according to the position in the partition table. The first logical partition starts with 5.
I also wrote the support for GUID Partition Tables (GPT).
All various partitions are accessed by the same shared ReadSector/WriteSector function call. It works very well :)
2018-04-28 - Drive access layer
I did some code cleanup and various fixes. I also added a layer to access various drives with the same function call. Now it doesn't matter if its a DVD drive or a hard disk (floppy is not done yet). The drives are registered during PATA/SATA enumeration. I also added a simple support for the classic MBR to access primary partitions. The partitions are registered too and can be also accessed by a shared function call. Full MBR support and GPT support will be implemented on Monday/Thursday.
Read boot sector of partition 1 from drive 3.
Drive registration. Using wrapper functions for standardized calls. Dynamic registering for USB drives is not done yet.
Current drive register routine
2018-04-19 - ATAPI CDROM drive drivers
The ATAPI drivers for IDE (PATA) and AHCI (SATA) for CDROM (and similar) drives are almost done. There is a strange behavior with the AHCI ATAPI driver. The first ATAPI command ends in an error. After this, all tested ATAPI commands are working fine. At the moment, I have no idea why the first command fails.
Drivers tested only on two machines.
2018-03-28 - Relocate addresses for program/driver loading
For long time, nothing important happened. Now, I spent two days for a simple address relocation system which is needed to support dynamic loading of programs and drivers.
I wrote two PHP scripts which are analyzing the list file, generated by NASM with the '-l' parameter.
The first PHP script (syscalls.php) generates a file with jumps to the kernel system functions (syscalls.inc). This generated file is included by the program/driver (my_program.asm) to make it easy to call the kernel functions. NASM generates all addresses according to the ORG command. Those addresses must be updated when the program/driver has been loaded into the memory.
The second PHP script (relocate.php) creates a file with two tables (relocate_table.inc). This tables are holding the positions of all addresses used by the program/driver. This file has to be included too.
The addresses, which are now stored in the header of the program, are updated by a simple routine in the kernel (relocation code), before the kernel can start the program.
Here is an overview with source codes. It may change in the future. It is just the first version. Maybe it looks difficult, but I tried to keep it simple. Explaining is not my strength.
Sample code to load a program:
Simple program header:
Address relocation code:
Sample program (my_program.asm):
Simple PHP script to export kernel function calls (syscalls.php):
Simple PHP script to create the relocation table (relocate.php):
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.
Driver development stage 1
Keyboard PS/2: Key read done.
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