bochs: can not load bootloader using a floppy image

Question

I have a simple (probably the simplest) bootloader. Very similar to this and this. The code is shown below

[org  0x7c00]

mov ah, 0x0e
mov al, 'h'

int 0x10

jmp  $

times  510-($-$$)  db  0

dw  0xaa55

The code is taken from the video series tutorial from here.

I have tried everything to compile and load this bootloader using bochs. But whatever I do, I get a black screen like the following

Nothing comes on the screen and after a bit I get that bochs is not responding.

My present approach to load the image is -

nasm boot_simple.asm -f bin -o boot.bin
dd if=boot.bin of=boot.img bs=512
bochs -f /dev/null -q 'display_library: sdl2' 'boot:a' 'floppya: 1_44=boot.img, status=inserted'

I tried many other approaches (slight variations of the above) (even tried to compile and load a separate bootloader from here) But nothing worked. Always the same black screen and does not show any other information.

I am becoming mad. What am I missing?

Ubuntu 22.04

Bochs version: Bochs x86 Emulator 2.7 (installed via sudo apt install)

I am super new to OS development and I want to learn it as a side project. Please help me getting started. Could not find suitable information anywhere.

Checking the log I see the following

00000000000i[FLOPPY] fd0: 'boot.img' ro=0, h=2,t=80,spt=18
00000000000i[FLOPPY] Using boot sequence floppy, none, none
00000000000i[FLOPPY] Floppy boot signature check is enabled

Not sure how to interpret this (if this is normal or some kind of error / mistake is hiding in them)

Tried to follow these steps as per here and here which I believe should create a simple 1.44 MB image, place the bin in the first sector and leave it to it. When done in this way (as well not padding it) in both cases qemu loads the image and shows the h each time without fault. Bochs does not load anything. Whatever I do. Always the same black screen and afterwards Not responding

I uninstalled, purged, and then reinstalled bochs. I do not know what else I can do. I can't understand why it fails to load the simple bootloader.

Here are the steps

nasm boot_simple.asm -f bin -o boot.bin
dd if=/dev/zero of=floppy.img bs=1024 count=1440
dd if=boot.bin of=floppy.img seek=0 count=1 conv=notrunc
mkfs.vfat -F 12 ./floppy.img (This step makes the floppy un-bootable in qemu but really does not change anything for bochs)
bochs -f /dev/null -q 'display_library: x' 'boot:floppy' 'floppya: 1_44=floppy.img, status=inserted' 'romimage: file=/usr/share/bochs/BIOS-bochs-latest' 'error: action=report'

But nothing happens. Bochs boots to a black screen.

Ok I have a slight idea. It seems that for some reason bochs halts at the first line of the code.

Printing something like this -

Next at t=0
(0) [0x0000fffffff0] f000:fff0 (unk. ctxt): jmpf 0xf000:e05b          ; ea5be000f0
<bochs:1>

Then waiting at the prompt <bochs:1>. If I do step there it does step through some instructions. Is there something I am missing here? Is there a bug in my code?

Trying to use seabios.bin with the default bochs vgabios brings me to this state

This is my bochs config file -

romimage: file="/usr/share/seabios/bios.bin"
vgaromimage: file ="/usr/share/bochs/VGABIOS-lgpl-latest"
floppya: 1_44=floppy.img, status=inserted
boot: a
display_library: x,
log: bochsout.txt

With this option I am able to get rid of the not-responding part. A small advancement. (using seabios) but it still does not display anything. So, I have checked from the menu and it is detecting the floppy in fd0. I am suspecting the vgabios is also not working And hence I do not see anything? Well I am a bit lost to be frank. But as comments say, I think it is not a normal case.

Debug log when trying to set breakpoint

With seabios

    <bochs:1> b 0x7c00
<bochs:2> c
(0) Breakpoint 1, 0x0000000000007c00 in ?? ()
Next at t=16650931
(0) [0x000000007c00] 0000:7c00 (unk. ctxt): mov ah, 0x0e              ; b40e
<bochs:3> n
Next at t=16650932
(0) [0x000000007c02] 0000:7c02 (unk. ctxt): mov al, 0x68              ; b068
<bochs:4> n
Next at t=16650933
(0) [0x000000007c04] 0000:7c04 (unk. ctxt): int 0x10                  ; cd10
<bochs:5> n
Next at t=16650935
(0) [0x000000007c06] 0000:7c06 (unk. ctxt): jmp .-2  (0x00007c06)     ; ebfe
<bochs:6> n
Next at t=16650936
(0) [0x000000007c06] 0000:7c06 (unk. ctxt): jmp .-2  (0x00007c06)     ; ebfe
<bochs:7> n
Next at t=16650937
(0) [0x000000007c06] 0000:7c06 (unk. ctxt): jmp .-2  (0x00007c06)     ; ebfe
<bochs:8> n
Next at t=16650938
(0) [0x000000007c06] 0000:7c06 (unk. ctxt): jmp .-2  (0x00007c06)     ; ebfe

So the breakpoint works. But, no display

With Bochs default bios

<bochs:1> b 0x7c00
<bochs:2> c
bx_dbg_read_linear: physical memory read error (phy=0x0000322f3130, lin=0x00000000322f3130)
Next at t=688972
(0) [0x0000fffffff0] f000:fff0 (unk. ctxt): jmpf 0xf000:e05b          ; ea5be000f0
<bochs:3> n
Next at t=688973
(0) [0x0000000fe05b] f000:e05b (unk. ctxt): xor ax, ax                ; 31c0
<bochs:4> n
Next at t=688974
(0) [0x0000000fe05d] f000:e05d (unk. ctxt): out 0x0d, al              ; e60d
<bochs:5> n
Next at t=688975
(0) [0x0000000fe05f] f000:e05f (unk. ctxt): out 0xda, al              ; e6da
<bochs:6> n
Next at t=688976
(0) [0x0000000fe061] f000:e061 (unk. ctxt): mov al, 0xc0              ; b0c0
<bochs:7> n
Next at t=688977
(0) [0x0000000fe063] f000:e063 (unk. ctxt): out 0xd6, al              ; e6d6
<bochs:8> n
Next at t=688978
(0) [0x0000000fe065] f000:e065 (unk. ctxt): mov al, 0x00              ; b000
<bochs:9> n
Next at t=688979
(0) [0x0000000fe067] f000:e067 (unk. ctxt): out 0xd4, al              ; e6d4
<bochs:10> n
Next at t=688980
(0) [0x0000000fe069] f000:e069 (unk. ctxt): mov al, 0x0f              ; b00f
<bochs:11>

I DID IT!! I downloaded and compiled bochs from source on my platform. I could not make sdl compile (--with-sdl did not work, even after installing sdl2-dev) but rest is good. So I guess the apt-get install is broken for Ubuntu 22.04 (at least)

Thanks a lot for all your help. It was a great learning session.

Well, did you see it boot before it got stuck at black screen? Did you test with other image? Also, bochs is sometimes picky about image formats so you should probably pad your image to the proper 1.44M size. Even though that should not cause it to stop responding. Could also be that everything is working properly just that you of course have an endless busy loop. — Jester, Jul 21 '22 at 14:01
I never saw it booting. I at least tried to boot using the last link I posted (did not try with grub yet). How do I make it pad to make it 1.44? According to the FIRST link in my post at least something should be shown. (also the video tutorial I mentioned shows that there were some prints to show it is booting from a floppy. — SRC, Jul 21 '22 at 14:15
So I followed word to word the instructions of little book on OS development (here - http://littleosbook.github.io/) and still all I see is a black screen and then not responding. I am starting to think if there is an issue with Ubuntu 22.04 / bochs version / the one that is available via apt install ... ? Starting to become a bit crazy on this. — SRC, Jul 21 '22 at 14:30
ok trying with qemu works. Thanks a lot. But that means I do not get any debug messages like bochs and also when I work with qemu I see that it is trying frist to load from hdd and then fails and then boots from the floppy. And to avoid a warning about auto detecting raw image I finally ended up using - `qemu-system-x86_64 -drive file=boot.img,format=raw,index=0,if=floppy` — SRC, Jul 21 '22 at 14:56
The question I am wondering is, why bochs did not work? What went wrong? Because the little I see in the internet it seems there are people who may have made this approach work in bosch. — SRC, Jul 21 '22 at 14:57
Try without the `'display_library: sdl2'` or with some other display method such as `'display_library: x'`. Also, do you get anything else in the terminal? Is the floppy related message the last thing? — Jester, Jul 21 '22 at 22:37
I have already tried `x` just a simple black screen. Nothing else. And no the floppy related message was not the last thing. It prints a hell lot of things. But looking at those logs nothing seems out of ordinary. I also have added a bit in the boot loader and print "Hello World" and then go in `jmp $` and when tried with qemu that works like a charm. But nothing works with bochs. Is there a known issue with bochs and Ubuntu 22.04? I am suspecting that there is something there maybe. Can't explain it otherwise. — SRC, Jul 22 '22 at 03:55
Have you tried Bochs with any known-good binary disk images and command lines? e.g. one that has a normal size for a floppy, instead of the 512 bytes you get from copying `boot.bin` to `boot.img` with the way you're invoking `dd`? — Peter Cordes, Jul 22 '22 at 06:41
> So I followed word to word the instructions of little book on OS development (here - littleosbook.github.io) and still all I see is a black screen and then not responding. Do you recommend some other images? — SRC, Jul 22 '22 at 06:46
I have updated the question with everything I could find. I am really interested to know if someone can reproduce this and/or help me debug this. — SRC, Jul 22 '22 at 07:22
No bug, bochs just stops at the first instruction. You should type `c` to let it run. — Jester, Jul 22 '22 at 10:42
Please use "--with-sdl2" other than "--with-sdl" in your compilation. Please refer to my answer for more details. — 慕冬亮, Feb 21 '23 at 03:27

Michael Petch · Accepted Answer · 2022-07-22T22:33:30.210

3

BOCHS will always stop at the first instruction in the BIOS when launched. The first instruction is at 0xf000:0xfff0 which is what you see in the output. This gives you a chance to set breakpoints ahead of time. For example b 0x7c00 would break at the first instruction of the bootloader if you wished. To start running just use the command c to continue.

edited Jul 22 '22 at 22:33

answered Jul 22 '22 at 17:54

Michael Petch

46,082
8
107
198

Thank you so much for this tip. Unfortunately, nowhere this is documented. All the videos and tutorials I have seen so far never talks about this behavior. But when I saw that prompt I start to have an idea. I used `c` with the image made using the process I mentioned above. When using `c` I get this error - `bx_dbg_read_linear: physical memory read error (phy=0x0000322f3130, lin=0x00000000322f3130)` The same image runs without error in qemu. – SRC Jul 23 '22 at 05:10
1

@SRC QEMU for purposes of speed doesn't do a number of checks and can allow bad code to execute seemingly correctly. BOCHs is more stringent about things. This includes reading and writing beyond a segment limit. Without seeing your exact code answering your question is going to be difficult. From the error message I am curious - do you enter protected mode and enable paging? To fix the problem you are having is a different issue than the one your question is really about. – Michael Petch Jul 23 '22 at 05:14
@SRC . I'm curious, are you able to run QEMU with the `-enable-kvm` or does it fail to run the code? – Michael Petch Jul 23 '22 at 05:15
Thanks for the fast reply. So here are some facts. One: My code is exactly what I posted in the question. Printing the letter 'h' and then going into a infinite loop. Second: I compile it using the steps I documented in the question also. Third: I tried to run this command `qemu-system-x86_64 -enable-kvm -drive file=floppy.img,format=raw,index=0,if=floppy` and qemu still ran without any issue and showed `h` but it also prints this `qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2]` which is not present otherwise. – SRC Jul 23 '22 at 05:33
I do totally understand that it is not entirely related. But I guess, my problem from the beginning was actually this. It was my inexperience in bochs and the lack of information that made me believe that I have some other issues. I want to learn this subject. Any help from experienced persons like you guys are much appreciated. – SRC Jul 23 '22 at 05:38
@SRC If you do a `b 0x7c00` after BOCHs first runs and then you hit `c` to continue... does it stop at your bootloader and can you step through the code to see what it is doing? One concern I have is that you are doing this `mkfs.vfat -F 12 ./floppy.img` . What happens if you create the floppy image as you are without doing that step. I'd expect that to potentially overwrite your bootloader. – Michael Petch Jul 23 '22 at 05:42
Thank you again for the fast reply. So to clarify, I did not do the mkfs step. I saw it somewhere and tried it once (did not change anything for bochs but made the image un-bootable for qemu) And now, when I am at the first prompt I do `b 0x7c00` then in the next time I enter `c` in prompt. That did not change anything. Am I doing it right? – SRC Jul 23 '22 at 05:57
However, one thing I must say, the first prompt says that `Next at t=0` and the very next prompt `Next at t=689952` (with or without my try to set break-point) also, what baffles me that there seem to be people who did make such kind of simple, hello world, style boot loader work in bochs. So what am I missing? (all the tutorials seem to say such an approach should work) – SRC Jul 23 '22 at 06:01
@SRC are you suggesting that when you did `b 0x7c00` followed by `c` it didn't actually stop at the beginning of your bootloader at 0x0000:0x7c00?? If things worked correctly it should have stopped. If it didn't I almost wonder if there is a problem with your ROM image. – Michael Petch Jul 23 '22 at 06:22
I have that feeling also. I am thinking to see if I can use seabios with it instead of the bios I installed using apt install `bochsbios`. Also, no. I did not see any difference between setting the breakpoint at the start and then using c in the next one or not setting it. Both seems to take the exact same path – SRC Jul 23 '22 at 06:29
@SRC : Yeah, use the default SeaBIOS. What happens with the bochs-legacy ROM image or even the bochs-qemu one (which should be seabios) – Michael Petch Jul 23 '22 at 06:31
@SRC I wish I had Ubuntu 22.04 handy on a system right now. The only other thing I can think of is that there is a problem with the VGA BIOS image being used (which might explain no output? At this point I am pretty sure the issue is not the bootloader but BOCHs booting properly . But what you are experiencing is not normal. – Michael Petch Jul 23 '22 at 06:38
You make me afraid. If the qemu that is in the bochs directory is the seabios then I am out of luck as none of the bios present in that directory (`/usr/share/bochs`) works so far. – SRC Jul 23 '22 at 06:39
@SRC the bochs-latest should work and it should be exactly 131072 in size. The only other thing is the VGA BIOS. I must admit I have used BOCHs for years and I haven't seen this behaviour. – Michael Petch Jul 23 '22 at 06:41
The size matches. That I can confirm. – SRC Jul 23 '22 at 06:42
@SRC Rather than running bochs from the command line as you are. Have you tried just running `bochs` and bringing up the text menu and telling it that you are using a `3.5" 1.44M` floppy (specifying the name of your disk image) and then set the boot drive to floppy? If you save it at the end as `bochsrc.txt` the next time you launch bochs it will read from that file by default. – Michael Petch Jul 23 '22 at 06:46
I have tried all these. I am pretty convinced it is not these kind of things. So I have just tried this settings - `romimage: file="/usr/share/seabios/bios.bin"` (left vgabios to the default bochs one) and there when I press `c` it does not directly return saying memory reading error. But instead it goes in some kind of stall mode. Nothing happens. Black screen. And then the `A:` symbol at the bottom of the window keeps blinking with green color... I think I am gonna give up on this :( – SRC Jul 23 '22 at 06:53
Updated the question with a screenshot of the state... Also I can actually step through in case of using seabios.bin but nothing ever happens. I step through or not. It does not print the `h` but seems to do a hello lot things. (may be goes into the infinite loop. But even then why not printing anything on the screen?) – SRC Jul 23 '22 at 06:59
Rather than SDL what happens if you just use X? Regarding your update (screenshot) what happens if you use seabios.bin and set a breakpoint with `b 0x7c00`. Does it stop at your bootloader or not? If it doesn't stop then the BIOS is munged or BOCHs on that platform is screwed up. – Michael Petch Jul 23 '22 at 07:11
So things are very strange. By bochrc.floppy (that is how I call it and I invoke bochs with the -f option and give in this name) has clearly written display_library: x. And when the first screen comes up it is indeed looking like that. But then when I use c (and it stalls) and then I use Ctrl-C it comes back to the prompt at that time magically it is in sdl :O – SRC Jul 23 '22 at 07:17
Updated the question with more information @Michael Petch – SRC Jul 23 '22 at 07:23
using seabios and breakpoint does stop and the memory read error goes. But I still am not able to see anything on the screen. And as I said it starts with `x` mode and then magically (!) switches to sdl once I use `c` at the prompt!! Unfortunately I am not in a situation (yet) where I can properly debug it, even though the breakpoint seems to work. – SRC Jul 23 '22 at 12:10
@SRC When you say the breakpoint stops do you mean at 0x7c00 or somewhere else? If it stops at 0x7c00 have you tried stepping through your bootloader instruction by instruction with the n command? What I'm suggesting you try is launch BOCHs and then type the command `b 0x7c00` followed by `c` command to continue. When it continues does it then stop at 0x7c00? If it does use `n` to step through the instructions in your bootloader. – Michael Petch Jul 23 '22 at 12:49
@SRC : If you can't stop at address 0x7c00 there are serious problems going on unelated to your bootloader or your disk image. – Michael Petch Jul 23 '22 at 13:11
Yeah. I think I will give up for now. So here is what is happening (with seabios): I set the breakpoint. I type c. It stalls. So no. It does not automatically comes to that address and stops. But then once it stalls I can use Ctrl-C to break that loop and then again press `n` or `s` to step through. But I can't really see my code there. But this may be my inexperience. And yes, it never really goes to the jump part – SRC Jul 23 '22 at 13:21
@SRC : What you are observing is not normal. You aren't getting to 0x7c00 . After hitting `c` after setting the breakpoint with `b 0x7c00` it should almost immediately break at the first instruction of the bootloader when working properly. The fact you see no output in the BOCHS window is suspect like the VGA BIOS isn't working as expected. If I get a chance later today I'll load Ubuntu 22.04 and see what happens here. – Michael Petch Jul 23 '22 at 13:25
Thank you so much. For all the help. I also understand it is not normal. But I just do not have enough experience to figure out the actual issue here. – SRC Jul 23 '22 at 13:27
I updated example prompt so that you can take a look. – SRC Jul 23 '22 at 13:30
I WAS WRONG!! With the right floppy image, and the romimage set to bios.bin (seabios) and vgabios set as vgabios-bochs-display.bin the breakpoint setting ACTUALLY WORKS! I could walk through my code. With zero thing being displayed. Meaning the romimage is working. And the vgabios is not?... – SRC Jul 23 '22 at 13:36
@SRC : I wonder what would happen if you do `sudo apt-get install bochs-x` and then use X11. – Michael Petch Jul 23 '22 at 13:39
I did install `bochs-x` but my display setting is `x` (which magically turns into sdl as I mentioned) do I need to put `x11` instead? I do not think so. But still better to verify, – SRC Jul 23 '22 at 15:40
1

I have managed to make it work. Please the updated part of the question. @Michael Petch. Thanks a lot for all your input. It was great to learn things from you. – SRC Jul 24 '22 at 06:02
2

@SRC : I can confirm that pre-built BOCHS in a fully updated Ubuntu 22.04 fresh install exhibits similar behaviour to what you are seeing. It might be worth filing a bug with Ubuntu as building it from source (as you have also noticed) produces a workable BOCHS. I didn't have time to find out why/where this bug exists in BOCHS when built on Ubuntu 22.04. – Michael Petch Jul 24 '22 at 22:15

score 2 · Answer 2 · answered Feb 21 '23 at 03:26

2

I encountered the same problem with you in Debian. The latest bochs(2.7+dfsg-4+b2) in the Debian or Ubuntu software repository is the culprit of this wired situation.

The solution is what you did before - downloading and compiling bochs 2.7 by yourself.

./configure --with-sdl2 --enable-debugger
make
sudo make install

Note that you need to use --with-sdl2 other than --with-sdl [1], or you will encounter the compilation error - "SDL.h is not found". Because bochs 2.7 uses sdl2, meanwhile, bochs 2.6.11 uses sdl1.2.

Another way to solve this problem is to use bochs 2.6.11, tested in Debian and Ubuntu.

[1] https://bochs.sourceforge.io/doc/docbook/user/compiling.html

answered Feb 21 '23 at 03:26

慕冬亮

339
1
2
10

What's wrong with Debian's package? Did they replace a non-free BIOS image or something to meet the DFSG (Debian Free Software Guidelines), resulting in a Bochs that works differently from mainline? Or do they not enable the built-in debugger? – Peter Cordes Feb 21 '23 at 03:32
I am not sure, so I am using reportbug to report this problem to the bochs maintainers. – 慕冬亮 Feb 21 '23 at 03:38
2

@PeterCordes I did some testing of this a while back (under my answer the length comments suggest a problem with the build on Debian). Since then I discovered the problem is specific to the ROM image file `BIOS-bochs-latest` produced by Debian for that release. They do apply patches related to it. If you change the configuration to point at a working build of `BIOS-bochs-latest` from a 2.7 release it seems to work. I'd suggest the problem should be directed at the Debian maintainers. – Michael Petch Feb 21 '23 at 05:55
2

This problem has also been mentioned on Reddit: https://reddit.com/r/osdev/comments/11353ws/bochs_black_screen using Cinnamon 21.1(which uses the the same files and config as Ubuntu 22.04). All are based on Debian bookworm/sid . Note: The Debian package builder applies a number of patches and one is for the ROM BIOS. – Michael Petch Feb 21 '23 at 06:17
@MichaelPetch Have you tried to replace this file with upstream and tested again? – 慕冬亮 Feb 21 '23 at 11:26

score 0 · Answer 3 · answered Jul 23 '23 at 16:49

I solved the issue. recompile the bochs-2.7 with Bochs-REL_2_7_FINAL

when config, append --with-sdl2 --enable-debugger

./configure **--with-sdl2 \
        --enable-debugger \**
            ......

nvidia@nvidia-PC:~/Downloads/Bochs-REL_2_7_FINAL/bochs$ cat .conf.linux 
#!/bin/sh
#
# .conf.linux
#

#which_config=normal
which_config=plugins

CC="gcc"
CXX="c++"
CFLAGS="-Wall -O3 -fomit-frame-pointer -pipe"    # for speed
#CFLAGS="-Wall -g -pipe"                         # for development
CXXFLAGS="$CFLAGS"

export CC
export CXX
export CFLAGS
export CXXFLAGS


case $which_config in

  normal)

    #######################################################################
    # configuration 1 for release binary RPMs
    # Include a few standard options, speed optimizations, X11 only.
    #######################################################################
    ./configure --with-sdl2 \
            --enable-debugger \
            --enable-sb16 \
                --enable-ne2000 \
                --enable-all-optimizations \
                --enable-cpu-level=6 \
                --enable-x86-64 \
                --enable-vmx=2 \
                --enable-pci \
                --enable-clgd54xx \
                --enable-voodoo \
                --enable-usb \
                --enable-usb-ohci \
                --enable-usb-ehci \
                --enable-usb-xhci \
                --enable-busmouse \
                --enable-es1370 \
                --enable-e1000 \
                --enable-show-ips \
                ${CONFIGURE_ARGS}
    ;;

  plugins)
    #######################################################################
    # configuration 2 for release binary RPMs
    # Include plugins, every possible gui.
    #######################################################################
    ./configure -with-sdl2 \
            --enable-debugger \
            --enable-sb16 \
                --enable-ne2000 \
                --enable-all-optimizations \
                --enable-cpu-level=6 \
                --enable-x86-64 \
                --enable-vmx=2 \
                --enable-pci \
                --enable-clgd54xx \
                --enable-voodoo \
                --enable-usb \
                --enable-usb-ohci \
                --enable-usb-ehci \
                --enable-usb-xhci \
                --enable-busmouse \
                --enable-es1370 \
                --enable-e1000 \
                --enable-plugins \
                --enable-show-ips \
                --with-all-libs \
                ${CONFIGURE_ARGS}
    ;;

esac

nvidia@nvidia-PC:~/Downloads/Bochs-REL_2_7_FINAL/bochs$ . .conf.linux

bochs: can not load bootloader using a floppy image

3 Answers3