3

I wrote an MBR program:

section MBR vstart=0x7C00
    mov sp, $$

    ; initialize register
    mov ax, 0
    mov ds, ax
    mov es, ax
    mov ss, ax
    mov fs, ax
    ; Set the address of the video memory to the es segment register.
    mov ax, 0xB800
    mov es, ax

    ; Scroll up the screen to achieve the effect of clearing the screen
    ; Set BIOS sub-function number
    mov ax, 0x600
    ; Set the properties of the rollup line
    mov bx, 0x700
    ; Set the rectangular display area of the text, in VGA text mode, a line can only hold 80 characters, a total of 25 lines
    ; Set the upper left corner coordinates (0, 0)
    mov cx, 0x0000
    ; Set the coordinates of the lower right corner (24, 27)
    mov dx, 0x184F
    ; BIOS interrupt call.
    int 0x10

    ; Get the cursor position.
    mov ah, 3
    mov bh, 0
    int 0x10

    ; Send ASCII characters to video memory.
    ; Set the source address of the string.
    mov si, MESSAGE
    ; Sets the destination address of the string.
    mov di, 0x0
    ; Set the text properties, the background color is green, and the text flashes.
    mov ah, 0xA4
    mov cx, STRLEN
    cycle:
        mov al, [si]
        mov [es: di], ax
        add si, 1
        add di, 2
        sub cx, 1
        cmp cx, 0
        ja cycle

    jmp $

MESSAGE db "Hello world"
STRLEN equ $ - MESSAGE
times 510-($-$$) db 0
db 0x55, 0xAA

It works fine in qemu:

enter image description here

After that, I wrote the MBR to my USB stick using:

dd if=mbr.bin of=/dev/sdc

and in the BIOS, I turned on Compatibility Support Module (CSM) support.

The result of its operation on the physical machine is as follows:

enter image description here

enter image description here

Obviously, there is no problem with the property setting of the string, the background is green and the text is blinking, but the wrong text is displayed.

why is that? How can i fix it?

Here is some qemu and physical machine info:

$ qemu-system-x86_64 -hda mbr.bin
$ qemu-system-x86_64 -version
QEMU emulator version 7.1.0
Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers
$ lspci | grep -i vga
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 620 (rev 02)
$ lspci | grep -i nvidia
01:00.0 3D controller: NVIDIA Corporation GM108M [GeForce 940MX] (rev a2)
$ lscpu
Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         39 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  4
  On-line CPU(s) list:   0-3
Vendor ID:               GenuineIntel
  Model name:            Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz

=================================================================

In my chat in the comments, I learned that the MBR may be overwriting some memory by the BIOS. I tested this hypothesis using Michael Petch's code and the results are as follows:

enter image description here

Except for the first 3 bytes, the other bytes that are not "AA" are the memory overwritten by the BIOS.

aszswaz
  • 609
  • 3
  • 10
  • 1
    Usually when code works in QEMU but not via USB on real hardware, it's that the BIOS overwrites part of your MBR with a BPB after loading it from disk. (Or if you set up segment registers wrong but got lucky with qemu. That doesn't look like the case here.) – Peter Cordes Oct 10 '22 at 02:24
  • 1
    Although not likely part of your problem, but is a potential problem - changing SP without SS could have you pointing your stack into unknown memory since you don't know what SS is set to. If an interrupt occurs between updating SP and SS there is a possibility for problems of SS:SP pointing to some critical place in memory. You should update SP *IMMEDIATELY* after you change SS to 0. So move `mov sp, $$` right after `mov ss, ax` – Michael Petch Oct 10 '22 at 07:15
  • 1
    I wish these question wouldn't be closed so quickly, until the OP responds. Anyway, have you tried adding a BIOS Parameter Block as in https://stackoverflow.com/questions/47277702/custom-bootloader-booted-via-usb-drive-produces-incorrect-output-on-some-compute ? (There is some test code in my answer that can help you determine if the overwriting of the code/data in the MBR is the culprit). In Your BIOS is the USB stick being booted as HDD (Hard Drive) or FDD (Floppy)? – Michael Petch Oct 10 '22 at 07:56
  • I don't see it in this question but I think I saw it in your other now deleted question - you write to /dev/sdc with dd. This suggestion is not likely going to fix the problem given that the USB still boots but have you considered using `eject /dev/sdc` to ensure that the USB stick can be safely removed? I don't think it's likely this is the issue but it is just a good practice. – Michael Petch Oct 10 '22 at 12:36
  • @MichaelPetch There are no partitions on the USB stick, so it was never mounted. – aszswaz Oct 10 '22 at 13:03
  • If you write to USB you still need to eject it properly to ensure that all the data was properly written (it could be cached) and that includes to the MBR that sits outside any partition. Usually this is a problem if you write multiple sectors directly to the device. In this case it is not likely the issue since the MBR is one sector. However it still holds true - you still need to properly eject it or you risk data loss. – Michael Petch Oct 10 '22 at 13:05
  • 1
    Since I know you are around, have you looked at whether the BPB area is being overwritten in memory by the BIOS by trying things in the linked question and its answer: https://stackoverflow.com/a/47320115/3857942 (see section **Test Code to See if Your BIOS is Overwriting the BPB**). The issue with the BPB (and emulated USB floppy media) is a very common problem. Thus the question about whether your BIOS is booting as HDD (Hard disk) or FDD (Floppy). You should be able to tell by entering the BIOS setup. – Michael Petch Oct 10 '22 at 13:08
  • @MichaelPetch: I closed it as a duplicate of one of the BPB Q&As because that's a showstopper problem that this bootloader doesn't avoid. Until the OP has tried and verified that's *not* the problem on their hardware, there's little point in anyone looking for others, although they could always comment if there are others. If there was some other definite showstopper bug that we could see also needed to be fixed, *then* we could reopen or edit the dup list. I don't see any value in having this question open when we have enough of a [mcve] to see it's 99% likely to be a dup. – Peter Cordes Oct 10 '22 at 19:12
  • 1
    @MichaelPetch I tested it the way you provided and the BIOS did use my USB as a floppy boot, the BPB overwrite happened. I stuffed something at the beginning of the MBR, bypassing the overwritten memory, and the MBR worked fine. thank you very much for your suggestion. – aszswaz Oct 10 '22 at 23:40
  • Glad to hear it, I will now close this as a duplicate of the other. Glad you go it going! If you ever consider booting USB as HDD media - that often comes with its own set of problems where you often need an MBR with a valid partition table with *one* active partition otherwise many BIOSes won't even consider it a bootable device. In some rarer cases BIOSes will automatically boot the active partition bypassing the code in the MBR and load the Volume Boot Record of the active partition directly. – Michael Petch Oct 11 '22 at 00:00
  • You can also consider upvoting any of the questions and answer(s) that helped you. – Michael Petch Oct 11 '22 at 00:20
  • I have a request. I'm curious if you could add to your question the output (a picture of the screen) of my bootloader that allows you to see the changed data overwritten in memory by the BIOS. I'm curious to see which data bytes were overwritten by your BIOS. I assume drive geometry values, but I'm still curious. If you could just add a picture of the screen with the output to your question I'd be appreciative. – Michael Petch Oct 11 '22 at 01:20
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/248717/discussion-between-peter-cordes-and-michael-petch). – Peter Cordes Oct 11 '22 at 01:46
  • 1
    @MichaelPetch I've added the test results to the question, it seems, just a few 0s are filled in, the BIOS doesn't write anything meaningful. – aszswaz Oct 11 '22 at 02:29
  • Thanks, The values seem to be oddly enough the hidden sectors (DWORD at 7C1C) and the physical drive number at 7C24. I asked the question because some people have suggested in the past that their BIOS seems to write gibberish into some of the BPB fields. The values written don't appear meaningful. Technically you'd expect the Heads and Sectors per Track to be filled in at the very least as those fields are needed to compute Logical Block Address to CHS. It is just a curiosity for me, I appreciate you taking the time to do that for me. – Michael Petch Oct 11 '22 at 02:41
  • I guess the physical drive number being 0 might be right since it is likely emulating that as the first floppy drive. – Michael Petch Oct 11 '22 at 02:46

0 Answers0