QEMU and ElTorito and EDD 3

QEMU and ElTorito and EDD 3

[Alex Roman]

[-- Attachment #1: Type: text/plain, Size: 592 bytes --]

I've been messing around with int 13h calls and it seems that the QEMU
BIOS supports EDD 3 extensions.

However, it does not support ElTorito extensions... I called the 4D
function (Return Boot Catalog) and the QEMU BIOS (I think) printed a
"nice" informative message:
"FATAL: Int13 eltorito call with AX=4D00. Please report" (see screenshot)

... which I will (report, that is) :)

But I thought I'd share the find first.. Looks like I'm going to have
to use either a different emulator (vmware&co.) or a real PC... What
do you folks suggest?


Cheers!
-- 
Alex Roman <alex.roman@gmail.com>

[-- Attachment #2: qemu_bios_no_eltorito.png --]
[-- Type: image/png, Size: 13950 bytes --]

Re: QEMU and ElTorito and EDD 3

[Alex Roman]

On 13/06/07, Alex Roman <alex.roman@gmail.com> wrote:
> However, it does not support ElTorito extensions... I called the 4D
> function (Return Boot Catalog) and the QEMU BIOS (I think) printed a
> "nice" informative message:
> "FATAL: Int13 eltorito call with AX=4D00. Please report" (see screenshot)

Furthermore, I wonder... If QEMU doesn't support this, and installing
Windows and other operating systems off CDs works, will many BIOSes
support this interface at all? PHOENIX BIOSes should, IMO, since the
ElTorito standard is made by PHOENIX, but what about the others?

We might have to read the boot catalog manually, not with the 4Dh
function to achieve more compatibility. Tonight I'll try to do an
"Extended Read", function 42h, to get the boot catalog and parse it in
a structure and see if it "makes sense".

-- 
Alex Roman <alex.roman@gmail.com>

Re: QEMU and ElTorito and EDD 3

[Robert Millan]

On Wed, Jun 13, 2007 at 08:33:02AM -0400, Alex Roman wrote:
> I've been messing around with int 13h calls and it seems that the QEMU
> BIOS supports EDD 3 extensions.
> 
> However, it does not support ElTorito extensions... I called the 4D
> function (Return Boot Catalog) and the QEMU BIOS (I think) printed a
> "nice" informative message:
> "FATAL: Int13 eltorito call with AX=4D00. Please report" (see screenshot)
> 
> ... which I will (report, that is) :)
> 
> But I thought I'd share the find first.. Looks like I'm going to have
> to use either a different emulator (vmware&co.) or a real PC... What
> do you folks suggest?

I was about to suggest bochs, but then found:

  ./bochs-2.3/bios/rombios.c:      BX_PANIC("Int13 eltorito call with AX=%04x. Please report\n",AX);

You could also try with virtualbox, which is (non-copyleft) free software.  It
doesn't work on x86_64 hosts though.

-- 
Robert Millan

My spam trap is honeypot@aybabtu.com.  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.

Re: QEMU and ElTorito and EDD 3

[Vesa Jääskeläinen]

Alex Roman wrote:
> On 13/06/07, Alex Roman <alex.roman@gmail.com> wrote:
>> However, it does not support ElTorito extensions... I called the 4D
>> function (Return Boot Catalog) and the QEMU BIOS (I think) printed a
>> "nice" informative message:
>> "FATAL: Int13 eltorito call with AX=4D00. Please report" (see screenshot)
> 
> Furthermore, I wonder... If QEMU doesn't support this, and installing
> Windows and other operating systems off CDs works, will many BIOSes
> support this interface at all? PHOENIX BIOSes should, IMO, since the
> ElTorito standard is made by PHOENIX, but what about the others?
> 
> We might have to read the boot catalog manually, not with the 4Dh
> function to achieve more compatibility. Tonight I'll try to do an
> "Extended Read", function 42h, to get the boot catalog and parse it in
> a structure and see if it "makes sense".
> 

El Torito part of the EDD3 spec might not be accessible if you have not
booted with such media that needs that support. At least this seems to
be case with VMWare which uses Phoenix BIOS. I once tested out those
CD-ROM access API's, but problem is that those devices are not exposed
by BIOS when booted from floppy or from HDD. Eg. when you enumerate all
devices, CD-ROM drives are not listed at all thus cannot be accessed.

But then again... I noticed that your device id was 0xe0 which I think I
may have not tried out. I had much better success with directly using ATA :)

If you have floppy image, I can try it out in VMWare and tell results
what happens.

Re: QEMU and ElTorito and EDD 3

[Jeroen Dekkers]

At Wed, 13 Jun 2007 16:28:42 +0200,
Robert Millan wrote:
> 
> On Wed, Jun 13, 2007 at 08:33:02AM -0400, Alex Roman wrote:
> > I've been messing around with int 13h calls and it seems that the QEMU
> > BIOS supports EDD 3 extensions.
> > 
> > However, it does not support ElTorito extensions... I called the 4D
> > function (Return Boot Catalog) and the QEMU BIOS (I think) printed a
> > "nice" informative message:
> > "FATAL: Int13 eltorito call with AX=4D00. Please report" (see screenshot)
> > 
> > ... which I will (report, that is) :)
> > 
> > But I thought I'd share the find first.. Looks like I'm going to have
> > to use either a different emulator (vmware&co.) or a real PC... What
> > do you folks suggest?
> 
> I was about to suggest bochs, but then found:
> 
>   ./bochs-2.3/bios/rombios.c:      BX_PANIC("Int13 eltorito call with AX=%04x. Please report\n",AX);
> 
> You could also try with virtualbox, which is (non-copyleft) free software.  It
> doesn't work on x86_64 hosts though.

Aren't they also using the bochs BIOS?

Jeroen Dekkers

Re: QEMU and ElTorito and EDD 3

[Bean]

On Wed, Jun 13, 2007 at 08:33:02AM -0400, Alex Roman wrote:
> I've been messing around with int 13h calls and it seems that the QEMU
> BIOS supports EDD 3 extensions.
> 
> However, it does not support ElTorito extensions... I called the 4D
> function (Return Boot Catalog) and the QEMU BIOS (I think) printed a
> "nice" informative message:
> "FATAL: Int13 eltorito call with AX=4D00. Please report" (see screenshot)
> 
> ... which I will (report, that is) :)
> 
> But I thought I'd share the find first.. Looks like I'm going to have
> to use either a different emulator (vmware&co.) or a real PC... What
> do you folks suggest?

I think the bios service is not reliable, the best way to access cdrom is to use ATAPI command directly.

-- 
Bean <bean123@126.com>

Re: QEMU and ElTorito and EDD 3

[Alex Roman]

On 13/06/07, Bean <bean123@126.com> wrote:
> I think the bios service is not reliable, the best way to access cdrom is to use ATAPI command directly.

That is the second stage of my project... the first stage is to make
this work using BIOS Int 13h which will be useful since it provides
compatibility with many CD-ROM types, not only ATAPI (i.e. SCSI, USB,
whatever the BIOS supports) :)


-- 
Alex Roman <alex.roman@gmail.com>

Re: QEMU and ElTorito and EDD 3

[Alex Roman]

On 13/06/07, Vesa Jääskeläinen <chaac@nic.fi> wrote:
> Alex Roman wrote:
>
> El Torito part of the EDD3 spec might not be accessible if you have not
> booted with such media that needs that support. At least this seems to
> be case with VMWare which uses Phoenix BIOS. I once tested out those
> CD-ROM access API's, but problem is that those devices are not exposed
> by BIOS when booted from floppy or from HDD. Eg. when you enumerate all
> devices, CD-ROM drives are not listed at all thus cannot be accessed.

That may be a problem...

>
> But then again... I noticed that your device id was 0xe0 which I think I
> may have not tried out. I had much better success with directly using ATA :)

I got that through random probing... I probed for all drives which
presented EDD 3 extensions, and 0xe0 was the only one.. It turned out
it was actually the CD-ROM :) Is there any standard device numbering
algorithm used by BIOSes?

>
> If you have floppy image, I can try it out in VMWare and tell results
> what happens.

Sure, I'll send it tonight, when I get home... Thanks!

-- 
Alex Roman <alex.roman@gmail.com>

Re: QEMU and ElTorito and EDD 3

[Robert Millan]

On Wed, Jun 13, 2007 at 07:55:38PM +0200, Jeroen Dekkers wrote:
> > > "FATAL: Int13 eltorito call with AX=4D00. Please report" (see screenshot)
> > > 
> > > ... which I will (report, that is) :)
> > > 
> > > But I thought I'd share the find first.. Looks like I'm going to have
> > > to use either a different emulator (vmware&co.) or a real PC... What
> > > do you folks suggest?
> > 
> > I was about to suggest bochs, but then found:
> > 
> >   ./bochs-2.3/bios/rombios.c:      BX_PANIC("Int13 eltorito call with AX=%04x. Please report\n",AX);
> > 
> > You could also try with virtualbox, which is (non-copyleft) free software.  It
> > doesn't work on x86_64 hosts though.
> 
> Aren't they also using the bochs BIOS?

That was the point :-)

-- 
Robert Millan

My spam trap is honeypot@aybabtu.com.  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.

Re: QEMU and ElTorito and EDD 3

[Alex Roman]

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]

On 13/06/07, Alex Roman <alex.roman@gmail.com> wrote:
> On 13/06/07, Vesa Jääskeläinen <chaac@nic.fi> wrote:
> > Alex Roman wrote:
>
> Sure, I'll send it tonight, when I get home... Thanks!

Vesa:

I don't have a floppy image, but a core.img which I use to boot with
qemu through pxe... I'm attaching it to this message, but let me know
if you'd rather have a floppy image: I can make one...

To test it, just boot the core.img and enter the command eltorito. It
should print similar stuff to what my screenshot shows... As long as
the drive for the CD-ROM is 0xe0, since that's the only drive I'm
probing.

Thanks!

-- 
Alex Roman <alex.roman@gmail.com>

[-- Attachment #2: core.img --]
[-- Type: application/octet-stream, Size: 42822 bytes --]

Re: QEMU and ElTorito and EDD 3

[Alex Roman]

On 13/06/07, Alex Roman <alex.roman@gmail.com> wrote:
> We might have to read the boot catalog manually, not with the 4Dh
> function to achieve more compatibility. Tonight I'll try to do an
> "Extended Read", function 42h, to get the boot catalog and parse it in
> a structure and see if it "makes sense".

I tried the extended read as follows:
  struct grub_biosdisk_dap dap;
  grub_uint8_t buffer[2048];
  dap.length = sizeof( dap );
  dap.reserved = 0;
  dap.blocks = 1;
  dap.buffer = (grub_uint32_t) buffer;
  dap.block = 17;
  x = grub_biosdisk_rw_int13_extensions( 0x42, drive, &dap );

"drive" was still 0xe0.

However, all I get in buffer is 0's. I tried reading other blocks as
well (e.g. 0, 1...). Any idea if I'm doing something wrong?

Thanks!

-- 
Alex Roman <alex.roman@gmail.com>