Booting process
Martin
I have a problem here and I can't find a solution, so I thought you
might help me. We've got the following situation: I have written a
simple bootloader that prints a message on the screen and do some
other simple things. I assembled it to a binary file and copied it to
an USB stick. I used the "dd for windows" for the raw writing of the
image to the usb. Then, I tried booting from the stick and it worked
without a problem.
Now, I made some changes to the code and copied the binary again to
the stick. But .. it does not boot anymore. The BIOS returns
"Operating system not found" message. Well, I didn't change anything
important in the code. The boot signiture is there and the image works
as a mounted HDD on Bochs. I can't really find out what's the problem
and why it worked once and now does not. Has anyone of you had a
similar problem?
I'm freaking out. I think it might have been a usb problem, so I
formatted the stick and copied the image again. But it didn't work.
How does actually the BIOS recognize if a USB stick is bootable or
not? Only the signature? Or is there something else I'm missing?
James Harris
No guarantees someone there will know but alt.os.development is ideal
for this kind of query. I know there is a section on USB in the FAQ
for a.o.d.
James
Rod Pemberton
news:b1e1e517-1e5b-42a1...@y13g2000yqn.googlegroups.com...
> Hello everyone,
>
> I have a problem here and I can't find a solution, so I thought you
> might help me. We've got the following situation: I have written a
> simple bootloader that prints a message on the screen and do some
> other simple things. I assembled it to a binary file and copied it to
> an USB stick. I used the "dd for windows" for the raw writing of the
> image to the usb. Then, I tried booting from the stick and it worked
> without a problem.
>
I would recommend John Fine's partcopy or Rawrite, both for DOS. Or, you
can use the "dd" command in *nix and Linux environments.
> I used the "dd for windows"
That may be an issue. Windows 98 (and probably other versions of Windows)
will overwrite certain bytes near the beginning of the bootsector. IIRC,
these are bytes in the date field of an MS-DOS format bootsector. IIRC,
Windows inserts some unique serial number there for Windows disks.
> Now, I made some changes to the code and copied the binary again to
> the stick. But .. it does not boot anymore. The BIOS returns
> "Operating system not found" message.
...
> Well, I didn't change anything
> important in the code. The boot signiture is there and the image works
> as a mounted HDD on Bochs. I can't really find out what's the problem
> and why it worked once and now does not. Has anyone of you had a
> similar problem?
I haven't used Bochs. Use your "dd for windows" to copy the disk to an
image. Then, do a binary compare of the original "good" image you wrote to
the disk with the new "bad" image you read back from the disk. Are they the
same?
> I'm freaking out. I think it might have been a usb problem, so I
> formatted the stick and copied the image again. But it didn't work.
Is the stick recognized as a floppy or harddisk?
> How does actually the BIOS recognize if a USB stick is bootable or
> not? Only the signature? Or is there something else I'm missing?
>
I think this depends on whether the device is emulated by the BIOS legacy
USB as a harddisk (HD) or floppy. E.g., if I write a HD image to my usb
stick, it'll come up as a HD. If I write a floppy image to the exact same
usb stick, it'll come up as a 1.44Mb floppy at the next boot even thought
it's a 64Mb stick.
Anyway, what's required for a working HD bootsector and a floppy bootsector
are different.
A HD bootsector:
1) bootsector written to cylinder 0, head 0, sector 1 (or LBA 1)
2) code which is executable when loaded to 0:7C00h with CS=0, IP=7C00h
3) requires an 0xAA55 signature at location 510
4) requires four partition tables setup in bootsector
5) one valid partition must be marked active to be bootable
A floppy bootsector:
1) bootsector written to cylinder 0, head 0, sector 1
2) less than a certain number (8 to 128) of identical bytes to be considered
non-blank, i.e., BIOS will attempt to boot if non-blank.
3) code which is executable when loaded to 0:7C00h with CS=0, IP=7C00h and
complies with 2 & 4
4) an initial byte of the first instruction which is greater than 06h
5) does *NOT* need an 0xAA55 signature (e.g., allows an OS like CP/M to
boot)
6) does *NOT* need a partition table
The HD master boot sector is described in Table 00650 of Ralf Brown's
Interrupt List (RBIL). The HD partition record is Table 00651 of RBIL.
The floppy disk bootsector is really only described in the original PS/2
(perhaps AT and XT) manuals.
00650 http://www.delorie.com/djgpp/doc/rbinter/it/50/6.html
00651 http://www.delorie.com/djgpp/doc/rbinter/it/51/6.html
RBIL:
http://www.cs.cmu.edu/~ralf/files.html
http://www.delorie.com/djgpp/doc/rbinter
http://www.ctyme.com/rbrown.htm
HTH,
Rod Pemberton
Michael Tippach
>
> I'm freaking out. I think it might have been a usb problem, so I
> formatted the stick and copied the image again. But it didn't work.
> How does actually the BIOS recognize if a USB stick is bootable or
> not? Only the signature? Or is there something else I'm missing?
>
How the detection is done depends on actual implementation. Same is true
for how it is decided whether the USB stick will be installed as a
fixed or removable device. Some BIOSes allow a stick with no partition
table/mbr to install as a "fixed" drive anyway, which will cause the
boot loader to fall over later on. I would venture a guess that the
latter is what happened in your case.
Dirk Wolfgang Glomp
> "Martin" <spam...@crayne.org> wrote in message
> news:b1e1e517-1e5b-42a1...@y13g2000yqn.googlegroups.com...
>> Hello everyone,
>>
>> I have a problem here and I can't find a solution, so I thought you
>> might help me. We've got the following situation: I have written a
>> simple bootloader that prints a message on the screen and do some
>> other simple things. I assembled it to a binary file and copied it to
>> an USB stick. I used the "dd for windows" for the raw writing of the
>> image to the usb. Then, I tried booting from the stick and it worked
>> without a problem.
>>
>
> I would recommend John Fine's partcopy or Rawrite, both for DOS. Or, you
> can use the "dd" command in *nix and Linux environments.
>> I used the "dd for windows"
> That may be an issue. Windows 98 (and probably other versions of Windows)
> will overwrite certain bytes near the beginning of the bootsector. IIRC,
> these are bytes in the date field of an MS-DOS format bootsector. IIRC,
> Windows inserts some unique serial number there for Windows disks.
I found the "HP USB Disk Storage Format Tool".
To boot MSDOS 6.22 i use a 2GB-FAT16-Stick with harddrive-emulation.
But i have no garantie that this stick always boot in any board.
Some old 32bit-boards and their bios will boot and some other boards
don´t find the stick.
My new Asus Striker2-Bios can boot the DOS6 on this stick.
>> Now, I made some changes to the code and copied the binary again to
>> the stick. But .. it does not boot anymore. The BIOS returns
>> "Operating system not found" message.
> ...
>
>> Well, I didn't change anything
>> important in the code. The boot signiture is there and the image works
>> as a mounted HDD on Bochs. I can't really find out what's the problem
>> and why it worked once and now does not. Has anyone of you had a
>> similar problem?
>
> I haven't used Bochs. Use your "dd for windows" to copy the disk to an
> image. Then, do a binary compare of the original "good" image you wrote to
> the disk with the new "bad" image you read back from the disk. Are they the
> same?
>
>> I'm freaking out. I think it might have been a usb problem, so I
>> formatted the stick and copied the image again. But it didn't work.
>
> Is the stick recognized as a floppy or harddisk?
>> How does actually the BIOS recognize if a USB stick is bootable or
>> not? Only the signature? Or is there something else I'm missing?
>>
>
> I think this depends on whether the device is emulated by the BIOS legacy
> USB as a harddisk (HD) or floppy.
I know these special entrys to specify those emulation, but the Asus-
bios don´t let me a choice, only an entry with lagacy enable. Maybe the
bios can analyse this part anyway. I think another part of this usb-legacy
is to hook my mouse(plugged in the USB-device) to the PS2-enviroment of the
keyboard-controller. My mainboard comes without a PS2-mouseadapter, but a
test with int15h/C20X results the movement and the buttons successful.
> E.g., if I write a HD image to my usb
> stick, it'll come up as a HD. If I write a floppy image to the exact same
> usb stick, it'll come up as a 1.44Mb floppy at the next boot even thought
> it's a 64Mb stick.
>
> Anyway, what's required for a working HD bootsector and a floppy bootsector
> are different.
>
> A HD bootsector:
> 1) bootsector written to cylinder 0, head 0, sector 1 (or LBA 1)
> 2) code which is executable when loaded to 0:7C00h with CS=0, IP=7C00h
> 3) requires an 0xAA55 signature at location 510
> 4) requires four partition tables setup in bootsector
> 5) one valid partition must be marked active to be bootable
>
> A floppy bootsector:
> 1) bootsector written to cylinder 0, head 0, sector 1
> 2) less than a certain number (8 to 128) of identical bytes to be considered
> non-blank, i.e., BIOS will attempt to boot if non-blank.
> 3) code which is executable when loaded to 0:7C00h with CS=0, IP=7C00h and
> complies with 2 & 4
> 4) an initial byte of the first instruction which is greater than 06h
> 5) does *NOT* need an 0xAA55 signature (e.g., allows an OS like CP/M to
> boot)
> 6) does *NOT* need a partition table
So is it possible to boot without any emulation?
> The HD master boot sector is described in Table 00650 of Ralf Brown's
> Interrupt List (RBIL). The HD partition record is Table 00651 of RBIL.
> The floppy disk bootsector is really only described in the original PS/2
> (perhaps AT and XT) manuals.
>
> 00650 http://www.delorie.com/djgpp/doc/rbinter/it/50/6.html
> 00651 http://www.delorie.com/djgpp/doc/rbinter/it/51/6.html
>
> RBIL:
> http://www.cs.cmu.edu/~ralf/files.html
> http://www.delorie.com/djgpp/doc/rbinter
> http://www.ctyme.com/rbrown.htm
Thanks.
Dirk
Martin
> "Martin" <spamt...@crayne.org> wrote in message
I think it is emulated as a HD. At least after a successful boot, DL
has a value of 80h.
Well I don't have a partition table. It's somehow strange - sometimes
it boots, sometimes it does not.
How can I understand if it is emulated as a HD or as a floppy? BIOS
settings?
One more thing, I use int 13h in my bootloader to read the next
several sectors. I assume that a sector is 512 bytes long. Does this
also apply when I'm reading from a usb?
> Anyway, what's required for a working HD bootsector and a floppy bootsector
> are different.
>
> A HD bootsector:
> 1) bootsector written to cylinder 0, head 0, sector 1 (or LBA 1)
> 2) code which is executable when loaded to 0:7C00h with CS=0, IP=7C00h
> 3) requires an 0xAA55 signature at location 510
> 4) requires four partition tables setup in bootsector
> 5) one valid partition must be marked active to be bootable
>
> A floppy bootsector:
> 1) bootsector written to cylinder 0, head 0, sector 1
> 2) less than a certain number (8 to 128) of identical bytes to be considered
> non-blank, i.e., BIOS will attempt to boot if non-blank.
> 3) code which is executable when loaded to 0:7C00h with CS=0, IP=7C00h and
> complies with 2 & 4
> 4) an initial byte of the first instruction which is greater than 06h
> 5) does *NOT* need an 0xAA55 signature (e.g., allows an OS like CP/M to
> boot)
> 6) does *NOT* need a partition table
>
Thanks for the exaplanations! I was googling to find out how the
system does the boot up process, but couldn't find it so well and step
by step explained. :)
Das
> Hello everyone,
>
> I have a problem here and I can't find a solution, so I thought you
> might help me. We've got the following situation: I have written a
> simple bootloader that prints a message on the screen and do some
> other simple things. I assembled it to a binary file and copied it to
> an USB stick. I used the "dd for windows" for the raw writing of the
> image to the usb. Then, I tried booting from the stick and it worked
> without a problem.
>
> Now, I made some changes to the code and copied the binary again to
> the stick. But .. it does not boot anymore. The BIOS returns
> "Operating system not found" message. Well, I didn't change anything
> important in the code. The boot signiture is there and the image works
> as a mounted HDD on Bochs. I can't really find out what's the problem
> and why it worked once and now does not. Has anyone of you had a
> similar problem?
>
Are you overwriting the MBR??? (you should not)
Please check that.
for a bootable pendrive
1) partition it marm a partition as bootable
2) put an MBR (may use from syslinux, I generally use it)
3) dd the bootsector to the first sector of the bootable partition
created.
4) boot from it on a physical HW.
These are the steps I follow to make USB sticks bootable.
Martin
Yes, this is a possibility, but my idea is to understand how and what
the code in the MBR exactly does.
That's why I'm trying to create my own code that is written in the
MBR.
In your solution, where am I about the put my bootloader code? In the
active partition? As what?
Rod Pemberton
> Yes, this is a possibility, but my idea is to understand how and what
> the code in the MBR exactly does.
It accepts cpu instruction execution from the BIOS. Now that you have
control of the cpu, your task is to get your OS booted without problems.
You have control of the cpu. From there, you're on your own - unless you
decide to follow an existing implementation like MS-DOS, Linux, WinNT's, or
GRUB.
There are numerous ways you can go from here. If your code is small enough,
you could boot your OS from the MBR. Typically, with only 512 bytes or less
available to the MBR, this isn't a realistic possibility. So, that's where
multi-stage bootloaders come into the picture. The MBR does some stuff,
then it then loads another larger program - additional stage(s) which is
essentially a 16-bit mini-OS, that boots your OS. There are many things you
can do in the MBR and/or bootloader stages: disable interrupts to ensure you
don't loose execution control, disable NMI for the same reason, setup text
video, enable the A20 line to access memory above 1Mb, setup some low-level
PC devices like PIC's which control your interrupts, call BIOS routines
after you enable interrupts to determine information your OS may need like
the size of memory, installed devices, the boot device, video mode. You
might also use the BIOS to setup your protected mode transition (16-bit to
32-bit) since it has functions for this. However, the BIOS doesn't have a
way to transition to 64-bit. etc.
> In your solution, where am I about the put my bootloader code? In the
> active partition? As what?
The MBR goes to the first sector (cylinder 0, head 0, sector 1). But, any
code beyond that goes wherever, depending. It depends entirely on the
format you've chosen or designed for your disks. It could be between the
MBR sector and the first partition. Or, it could in the first partition,
typically at the start. But, there are some things you should consider.
First, the MBR must "know" where to get the 2nd stage from and must "know"
how to read those tracks. If it's just a raw program stored on the disk
between the MBR and a partition, you can just read in the data using BIOS
calls. But, if it's within a partition, the MBR must understand the
filesystem format in order to locate and extract the 2nd stage from the
filesystem format used by that partition. In most cases, extracting is easy
because data tracks don't have any filesystem information. But, you may
need to do some computation to locate the data tracks of your stage if
placed within a partition.
Second, in order to reduce the code size of your MBR and/or bootloader
stages, you'll probably be using BIOS calls, e.g., to read in additional
code or enable A20. It's not likely you'll be directly programming the raw
disk interfaces. Unfortunately, the BIOS has software limitations on how
large of a harddisk it can read. The original int 13h supports disks upto
528Mb, so your code should be below 528Mb if you want to support booting of
older machines. The extended int 13h supporst disks upto 8.4Gb. I.e., it's
probably not wise to locate your code at the end of a disk...
Rod Pemberton