Qemu and image file

[Dario]

Can I use ordinary file to act as HDD?
What I did is I created a file using command: dd if=/dev/zero of=hdd.img bs=512 count=100
I also assembled a boot loader and stored it on the first block using dd command: dd if=boot.S of=hdd.img bs=512 seek=1
Then I assembled a second stage boot loader and stored it 2 sectors away from MBR: dd if=setup16.S of=hdd.img bs=512 seek=3
But it won't load that second sector to memory...so I think that it might be problem with CHS addressing of an image file.

Thank you!

[Combuster]

Which emulator? what configuration options/command line? logged messages?

[Dario]

Qemu, no command line options. I just type: qemu <file_name>.
One more quick questions, in what state are segment registers after BIOS completes system initialization?

[JwB]

Try

Code: Select all

qemu -hda hdd.img

[xenos]

Code: Select all

dd if=/dev/zero of=hdd.img bs=512 count=100
dd if=boot.S of=hdd.img bs=512 seek=1
dd if=setup16.S of=hdd.img bs=512 seek=3

I guess *.S are assembler sources, do you really copy these into your disk image? How about assembling them first and using the binaries?

[Dario]

Hi,

yes, sources are assembled. I'm using this small script to automate the process:

Code: Select all

#!/bin/sh

nasm -f bin boot.S
nasm -f bin setup16.S
dd if=./boot of=./qdrive/disk_0 bs=512 count=1 seek=0
dd if=./setup16 of=./qdrive/disk_0 bs=512 count=1 seek=1
hexdump ./qdrive/disk_0

This is the output:

Code: Select all

1+0 records in
1+0 records out
512 bytes (512 B) copied, 7.5709e-05 s, 6.8 MB/s
0+1 records in
0+1 records out
25 bytes (25 B) copied, 6.9702e-05 s, 359 kB/s
0000000 3fbe e87c 002b 00b4 13cd 053c f874 00b8
0000010 8e7e 31c0 b9db 0005 59be b47c b002 b501
0000020 b100 b602 cd00 7313 e202 e8f0 0003 cfe9
0000030 ac01 0eb4 00b7 07b3 10cd 003c f375 4cc3
0000040 616f 6964 676e 7320 6365 6e6f 2064 7473
0000050 6761 2e65 2e2e 0d0a 4f00 0a4b 000d 0000
0000060 0000 0000 0000 0000 0000 0000 0000 0000
*
00001f0 0000 0000 0000 0000 0000 0000 0000 aa55
0000200 14be ac00 0eb4 00b7 07b3 10cd 003c f375
0000210 e9c3 fffd 4b4f 0a0d 0000               
0000219

So, at 0x200 you can see the second source file (setup16.S). I'm also not sure if it coresponds to CHS = [0,0,2];
But that shouldn't matter since, I guess, my code isn't quite good. So here it is(boot.S):

Code: Select all

[BITS 16]
[ORG 0x7C00]

mov si, boot_msg 

call prt_msg

reset_drive:
        mov ah, 0x00    ; reset disk drives
        int 0x13        ; do it!
        cmp al, 0x05    ; result
        jz reset_drive ; if failed, reset again

mov ax, 0x7e00
mov es, ax
xor bx, bx

mov cx, 0x05    ; read loop countdown
mov si, ok_msg

read_sector:
        mov ah, 0x02 ; read sector from drive
        mov al, 0x01 ; # of sectors to read
        mov ch, 0x00 ; track
        mov cl, 0x02 ; sector
        mov dh, 0x00 ; head
        int 0x13
        jnc setup16
        loop read_sector

setup16:
        call prt_msg
        jmp 0x7e00

prt_msg:
        lodsb       
        mov ah, 0x0E 
        mov bh, 0x00 
        mov bl, 0x07 
        int 0x10      
        cmp al, 0
        jne prt_msg
        ret


boot_msg db 'Loading second stage...',10,13,0
ok_msg db 'OK',10,13,0

times 510-($-$$) db 0 
dw 0xAA55 

[Candy]

When you DD to a device, it overwrites the bytes currently at that place. You're trying to achieve that on a file. When you DD to a file, it usually truncates it. That means that your 100-sector image is now 2.1 sectors long. QEMU probably doesn't like reading the 0.1 sector and passing it out as a whole sector.

To prevent that, add "conv=notrunc" to your dd commands. That leaves the file in untruncated conditions - 100 sectors long (or more depending on what you DD).

[Dario]

Thank you Candy, but it still doesn't work.
I've dumped registers in Qemu and got some weird results. Segments are totally messed up, so I'll try with different emulator.