ajxs wrote:I purchased a paper copy of the first book in the series recently. It's really been a great resource.
Thank you for all your effort in writing the series!
Thank you for your kind words.
I have recently been working on my
own project and have successfully booted via a 64-bit UEFI and a mostly working kernel. It is almost to what the 32-bit version is though this runs on a 64-bit machine in long mode. Recently, after working on my
Ultimate project, I decided to see if I can get it to boot on a legacy 64-bit machine. i.e.: No UEFI. After building a 64-bit loader to load everything, I can't quite get it to work.
I have paging identity-mapped, A20 line on, 4k pages, you name it, a very basic loader. However, when running the kernel, I get some errors. Running the exact same kernel via a UEFI loader, the kernel runs as expected. Somewhere, somehow, I am not initializing something before moving to the kernel from the legacy loader. I can't figure it out at the moment.
I have verified that the kernel is loaded correctly, I have identity mapped the paging, a20 line is on, 4k pages (as apposed to 2meg or 4meg pages), everything I can think of. Some how my UEFI loader is doing something that my legacy loader is not, or visa-versa, and the kernel doesn't like the legacy boot.
Oh well, I will figure it out sooner or later.
Merry Christmas to all.
Edit a day later:
Come to find out, there were two things wrong and each had to do with the ACPI:
- First, I mistakenly used a pointer declaration for a 32-bit field. Therefore, when moving to 64-bit, this field now became 64-bits in size instead of staying at 32-bits.
- Second, for some reason, QEMU (using ACPI v1.0) places a value of one (1) in the FADT's x_dsdt field. I was checking for NOT NULL.
Neither of these errors were shown in the EFI bootable version since it uses ACPI 2.0+ which uses 64-bit fields
and has a valid FADT x_dsdt field. :-)
Ben
-
http://www.fysnet.net/osdesign_book_series.htm