I have a USB stick that I've managed to install DUET on (it was a long, complicated, "fun" process). I want to create a hard disk image of it for Bochs, but as it is USB it doesn't have any CHS geometry which Bochs needs for a disk image. I already have the thing extracted into a flat file.

I've already tried guessing based on the number of sectors, as well as using what Linux said it had. Neither worked (Bochs complained about Linux's numbers not matching the image size, and my guess booted but confused DUET's loader and so is obviously incorrect).

My question is: is there a way to reliably get the CHS geometry for my USB stick or am I going to have to go through a long convoluted process of installing it on a fresh disk image?

Sorry no idea what DUET is, so I don't know if you will need to boot from your image. Booting from USB in Bochs is still not supported.Honestly, I even have no idea if this USB disk mode works but worth trying

Making a new disk image doesn't have to be convoluted, either. Write a quickie C program -- allocate a great big buffer, open the file, read the file, close the file, create a new file, and then write out only the correct number of sectors to match a good/legal CHS size. You can do it in 10 lines of code.

Sorry no idea what DUET is, so I don't know if you will need to boot from your image.

I'd assume DUET is "Intel(R) Platform Developer's UEFI Emulation (DUET)", which is part of the tianocore project now.

bewing wrote:

Making a new disk image doesn't have to be convoluted, either. Write a quickie C program -- allocate a great big buffer, open the file, read the file, close the file, create a new file, and then write out only the correct number of sectors to match a good/legal CHS size. You can do it in 10 lines of code.

Based on "and my guess booted but confused DUET's loader and so is obviously incorrect" I'd assume that DUET's code uses hard-coded CHS values somewhere, so the disk image has to have the same number of sectors per track and heads as the original media (so that those hard-coded CHS values still work). I could be wrong, and it could be worse than that - for e.g. maybe it's partitioned with GPT and needs to find a correct secondary GPT header in the last sector of the disk or something.

Firestryke31 wrote:

I have a USB stick that I've managed to install DUET on (it was a long, complicated, "fun" process).

If installing DUET is both long and complicated, then maybe it'd just be easier to port UEFI to Bochs and run it as firmware (it's been done for both Qemu and VirtualBox before)...

Cheers,

Brendan

_________________For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.

First, I want to clear up what I'm trying to do: I'm trying to make a regular disk image for Bochs, that just happens to have the same "geometry" and contents as the physical USB stick I have.

Most of the DUET complications arose from the fact that I had to add support for VS2010 myself (mainly be copy/modify/pasting the VS2008 stuff) and the fact that I had to use a real disk as none of the emulation systems I tried for a hard disk image (under Windows) supported the method the DUET installer used to read/write the boot sector.

Quote:

Based on "and my guess booted but confused DUET's loader and so is obviously incorrect" I'd assume that DUET's code uses hard-coded CHS values somewhere, so the disk image has to have the same number of sectors per track and heads as the original media (so that those hard-coded CHS values still work). I could be wrong, and it could be worse than that - for e.g. maybe it's partitioned with GPT and needs to find a correct secondary GPT header in the last sector of the disk or something.

There are 5 bootloaders included in the DUET system: FAT12, FAT16, FAT32, MBR, and GPT. I tried DUET on a floppy and it almost worked, but (a) it froze up and (b) there was only like 32k of space left over after the Flash image and shell. The USB stick I used is partitioned using MBR with a single FAT32 partition. If I had to guess I would say the FAT32 sector is the point of failure, probably by trying to use the BPB's geometry instead of the ah=42h extensions (though I haven't yet peeked at the source to confirm).

If I still can't get the disk image I have working, I'll probably end up installing Windows in Bochs and installing DUET through that on a known good disk image.

Personally I would say forget about floppies and then you can use INT 13h AH=42h, no more stupid CHS problems.

I'm not the one who wrote the code, and I did give up on floppies. I am not yet at the point of running my own software, so I can't use int 13h to check the USB's geometry as I would have to boot my own software on real hardware.

I think I'm just going to do the "install it with Windows inside Bochs" thing as I can't seem to find any way to get the thing's "real" geometry. It'll just take a while to install Windows in Bochs.

... as I can't seem to find any way to get the thing's "real" geometry.

Heh. In bochs or rebochs you just set a breakpoint at 0x7c00, run to the breakpoint twice, and dump the memory at 0x7c00. The bpb will be looking back at you. Then you can step a few more times and watch for an Int0x13/ah=8 or whatever, to see if it does that. It would take less than 20 minutes to singlestep through the bootsector, if you are comfy reading asm. Then you would know what values you need to change, and what you need to change them to.

... as I can't seem to find any way to get the thing's "real" geometry.

Heh. In bochs or rebochs you just set a breakpoint at 0x7c00, run to the breakpoint twice, and dump the memory at 0x7c00. The bpb will be looking back at you. Then you can step a few more times and watch for an Int0x13/ah=8 or whatever, to see if it does that. It would take less than 20 minutes to singlestep through the bootsector, if you are comfy reading asm. Then you would know what values you need to change, and what you need to change them to.

I can't do it in Bochs as I need the disk geometry to get Bochs to use the disk image. I tried using a hex editor to get the BPB from the FAT32 bootsector but Bochs didn't like that.

Doesn't Bochs allow you to use the actual USB stick instead of a drive image? In that case, I would simply try do follow bewing's suggestion and single-step through the boot sector, starting right off the USB stick, to figure out the CHS geometry. I have to admit that I never tried to boot Bochs with an actual USB stick, but I tried it in QEMU a few times and it worked without problems (so using QEMU instead would be my second suggestion).

Blarg, I ended up installing XP in a Bochs emulator and using that to "natively" set up DUET on a known good disk image. Turns out DUET and Bochs don't play well together anyway so there goes that idea. I guess I'll get back to work on VIXEN by looking at how DUET does it.

I peeked through the bootloader source and they do int 13h ah=08h first and they don't use the ah=42h extensions. In fact, it looks like I did a better job my first time around :/

They only read the root directory, scan it for the file they want and load only a single sector of that file, and it's hard coded to do it this way via ah=02h. I on the other hand can read from subfolders and read in the entire "ROM" file using ah=42h.

It looks like they had a grand total of 4 spare bytes whereas I have 14 and could probably get more if I tried (maybe I could use it for a ah=02h fallback if the 42h functions aren't present...)

TL;DR: DUET isn't worth the trouble and I want to write my own anyway because I think I could do better.

as far as creating Images from real devices to use with bochs, this has been working out for me.I just hexdump the device I want (using Hexden) then open/create a new file in Hexden and past you devices dump in it.Save as XYZ.img and put it on the path for bochsrc. use int 13 ah=08h to determine the BIOS emulated geometry. When the boot device is not a floppy or HDD (in this case a USB flash memory stick) the BIOS apparently "Emulates geometry" , which you can retrieve its parameters (C & H & S) using the int13 ah=08h and proceed as a normal floppy boot.

I am no where near being seasoned with this, but this seems to be working with me, so I hope it helps

Who is online

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum