qemu reporting EDD-2.x where 3.0 is available

[bradbobak]

Hi, I've done an int 0x13, ah 0x41, everything succeeds, and ah=0x30 is returned (specifying major version of EDD extensions as 3.0).
Now that I know that extensions are supported, I move foreword with int 0x13, ah=0x48 (extension : get drive parameters).
I stuff in word [0x42h] at the start of my buffer (pointed to by si), set up the registers, then call the interrupt.
Upon return, the word at the start of my buffer reports 0x1e, which, from http://www.ctyme.com/intr/rb-0715.htm#Table278
specifies the bios is returning info for a version 2.0x EDD (function ah 0x41 reported EDD 3.0 is avail), and upon inspection of
the returned data, word [si + 0x1e] contains the value 0xBEDD, which is the header signature for the EDD 3.0 part of the buffer.

Code: Select all

  mov dl, [DATA_INT13_DRIVE] ; saved, but its 0x80
  mov si, BUFFER_512 ; general purpose buffer location
  mov ah, 0x48 ; get drive parameters
  mov [si], word 0x42 ; EDD 3.0 uses this many bytes
  push si ; just to be safe
  int 0x13
  pop si
  jc .failed
  mov eax, 0
  mov ax, [si]
  call print_eax ; this reports 0x1e, which is the size of an EDD 2.x buffer.
  ; but a
  cmp [si + 0x1e], word 0xbedd
  jne .falied
  ; we're still here, thinking we have a EDD 2.x buffer, but the 3.0 stuff is in there.

  ret
.failed: ; output some fail message.

The reference I'm using for ah = 0x41.
http://www.oocities.org/wangxuancong/int13h.html

Any ideas what I should do here? maybe if the EDD 3.0 signature matches, just default to using that?

(btw. this is being tested under qemu).

[Brendan]

Hi,

Any ideas what I should do here?

Yes - if the word at offset 0x00000 says the BIOS only returned 0x1E bytes (e.g. the bytes from offset 0x0000 to offset 0x001D), don't bother reading bytes the BIOS says it didn't return (and don't check the 2 bytes at offset 0x001E).

You should probably also consider filing a bug report for Qemu developers, to let them know their code is buggy.


Cheers,

Brendan

[Kevin]

SeaBIOS, not qemu, to be precise.

Can you please try the following (completely untested) patch to SeaBIOS and report back whether it works? I can take care of submitting it to SeaBIOS then. You can get the SeaBIOS source code from git://git.seabios.org/seabios.git, a simple make should be enough to build it, and you can pass the resulting bios.bin binary to qemu with -bios.

Code: Select all

diff --git a/src/block.c b/src/block.c
index 7892be5..46afca0 100644
--- a/src/block.c
+++ b/src/block.c
@@ -339,6 +339,7 @@ fill_generic_edd(u16 seg, struct int13dpt_s *param_far, struct drive_s *drive_gf
         return DISK_RET_SUCCESS;
 
     // EDD 3.x
+    SET_FARVAR(seg, param_far->size, 66);
     SET_FARVAR(seg, param_far->key, 0xbedd);
     SET_FARVAR(seg, param_far->dpi_length, t13 ? 44 : 36);
     SET_FARVAR(seg, param_far->reserved1, 0);

[bradbobak]

Ok. I wont have a chance til tomorrow. I'll let you know how it goes.

[bradbobak]

Kevin, the patch seems to work fine. Thanks for looking into this.

[Kevin]

Okay, got a reply and it turns out that your assumptions are wrong. The spec says the following about the size field:

The caller sets this value to the maximum buffer size. If the length of this buffer is less than 30 bytes, this function does not return the pointer to DPT extension. If the buffer size is 30 or greater on entry, it shall be set to 30 on exit. If the buffer size is between 26 and 29, it shall be set to 26 on exit. If the buffer size is less than 26 on entry an error is returned.

Looks like you have to clear the word at offset 30 before the call and check on return whether it is 0xBEDD. It's beyond me why you would write a spec this way when you already have a size field, but this is how it is. Perhaps some compatibility problems that prevented them from doing the obvious thing.

[bradbobak]

Ok, thanks for clarifying and looking into this.