PrettyOS inside coreboot/SeaBIOS as a virtual floppy! - Stuck while booting at "Switching to Protected Mode (PM)..._"
infarmer8 last edited by infarmer8
Dear @Erhard-Henkes and C++/OSDev community members, good day and happy coming 2019 to you!
I built the open source BIOS "coreboot+SeaBIOS" for my quadcore AMD A10-5750M based Lenovo G505S coreboot-supported laptop with 16 GB RAM ( for those who are interested, check this coreboot Supported Motherboards list - https://coreboot.org/status/board-status.html - maybe you already have a PC from this list or a real chance to get one ) . Then added a PrettyOS floppy image to coreboot.rom by using this command: (with LZMA compression 1440KB ---> 375KB to save some space inside the SPI flash BIOS chip for another cool stuff, by itself coreboot+SeaBIOS takes less than 1MB out of 4MB chip, much less than fat proprietary UEFI 3.5MB )
./build/cbfstool ./build/coreboot.rom add -f ./prettyos.img -n floppyimg/prettyos.lzma -t raw -c lzma
Flashed this coreboot.rom inside my laptop's BIOS chip and tried booting PrettyOS from SeaBIOS boot menu ! However I ran into the following problem:
Loading Second Stage Bootloader XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX GTD installed Unreal Mode entered Loading Kernel... Floppy Disk Motor switched off Switching to Protected Mode (PM)..._
^^^ and blinking _ cursor at the end of line above
Also my font successfully changed to PrettyOS style. What might be the reason that PrettyOS got stuck at "Switching to Protected Mode" ? Sadly this problem isn't reproduced at QEMU or VirtualBox, but I could help you to debug it, waiting for your instructions
infarmer8 last edited by
Dear @Erhard-Henkes , do you have any news about this problem? We could debug it together, just waiting for you...
What might be the reason that PrettyOS got stuck at "Switching to Protected Mode" ? Sadly this problem isn't reproduced at QEMU or VirtualBox, but I could help you to debug it, waiting for your instructions
Did you try the boot process with other real computers?
You could look up the assembler code of the second stage bootloader:
line 77 ff.
Perhaps you could check code/data selectors with your system?
Could you make any progress?