x86 boot process

[CTho9305]

RamonetB's thread got me wondering how exactly the system boots. I found this informative site.

As a result, I have some questions.

I used debug to find this:
FFFF:0000 EA5BE000F0 JMP F000:E05B

and subsequently this:
F000:E05B E91114 JMP F46F

and finally: (commented to the best of my ability)
F000:F46F FA CLI ;clear interrupts
F000:F470 FC CLD ;set loop stuff to count up instead of down? doesn't make sense to me
F000:F471 0F DB 0F ;I didn't think it was valid to have something like this.
F000:F472 01E0 ADD AX,SP ;i assume AX starts at zero
F000:F474 A801 TEST AL,01 ; why not just test sp, 01? would that do the high half (ah) instead?
F000:F476 7408 JZ F480 ;the cpu is happy, do some more booting
F000:F478 FA CLI ;not sure why this is needed again. I see no STI anywhere.
F000:F479 B0FE MOV AL,FE
F000:F47B E664 OUT 64,AL ;reboot, something wasn't good
F000:F47D F4 HLT [/b];everything since the 286 should have rebooted above

what exactly is the test for? make sure that the stack starts off at an address that doesn't end in a 1? I don't understand this. does the stack always have to be an even size? what would it mean if not?

Also, I don't understand the presence of "DB 0F". why is it there? I wrote this:
0AF2:0100 cli
0AF2:0101 cld
0AF2:0102 db 0f
0AF2:0103 mov ax,4c
0AF2:0106 int 21
which gives me an illegal instruction at the DB 0F instruction when I ran it. if I tell windows to ignore the error, the program terminates normally (as expected)

anyway, after that, there is a lot more code. I recognize the test for cold vs. hard boot further on :
F000:249E 813E72043412 CMP WORD PTR [0472],1234

edit: ooh, i'm a platinum member. and this is my 2^11th post

 

[RamonetB]

SO here you are.

It sounds like you've got a much better grasp on this than me. I'm still trying to identify the utilities I need and how they work!!

Your help is greatly appreciated.

-kirk

 

[CTho9305]

edit: oops. i didn't do a binary compare

 

[jhu]

the problem with debug is that it doesn't recognize some opcodes so some of the downstream instructions might not be what debug says they should be

 

[CTho9305]

got any recommendations?

I've run into another problem. I can find certain strings that MUST be coming from the image I flash, but when I search the image itself, the string is nowhere to be found. What is going on there?

specifically, when I dump starting at ffff:0000, I find "11/22/00" (31 31 2F 32 32 2F 30 30) starting at the 6th byte (this is immediately after the initial JMP). I can't locate that anywhere in the bios image that I flashed.

thoughts? does a lot of stuff get decompressed on boot and the image only has the compressed version?

edit:
using hackman to disassemble some of the data (the part I commented above), I got this instead:

CLI
CLD
SMSW EAX ;ahhh, makes sense now ! move the status "are we in protected mode" to eax
TEST AL,01 [/b];see if we are in proteted mode
JE 00000011 ;not entirely sure here. the address strikes me as odd... but basically, go somewhere if not protected
CLI
MOV AL,FE
OUT 64,AL
HLT

so... clear interrupts, count up (still don't see why it matters ), check if we are in protected mode. if so, reset the processor to get out. if not, THEN go on to boot. makes much more sense than the stack thing earlier

now the question is what's up with that funky address.

edit2: right now (in windows), TEST AL,01 after the SMSW EAX instruction is not zero. cool! now the question is why my attempt to do the reset 1. didn't work and 2. didn't result in windows complaining.

edit3: i'll trust the location debug jumps to, because the code there calls another location with code that does in fact make sense.

 

[CTho9305]

bump. I can't figure out where the information is coming from. The Asus flash utility tells me that the image I have is for the K7V, and gives me a version: "ASUS K7V ACPI BIOS Revision 1008 Beta 001-D", and a date: 11/22/2000.

I can't find that in the image that I flashed.

 

[Peter]

in a nutshell ... after the power-on and reset sequence, the needle goes onto the record at linear address FFFFFFF0, 16 bytes from top of address space. This is where the CPU does the first code read from memory address space.

The chipset in turn must come out of reset in a state that maps the BIOS ROM there, and mirrors 64 KBytes of it into the 000Fxxxx range (right below 1 MByte).

Now what the initial program (the "bootblock") does is JMP down into the mirror, enable the RTC and keyboard controller devices, pre-init the chipset, find and enable system RAM, decompress the main POST program from ROM into RAM, and hop over into it.

POST sets up the peripheral busses and devices, starts all the ROMs associated with them (like with VGA or SCSI), initializes all the mass storage systems, unpacks the runtime part of BIOS from ROM into shadow RAM at 000Fxxxx, and then passes control to the boot services that installed during the mass storage init.

Boot services try to find an activated MBR on one of the boot devices, loads it and passes control to the OS bootloader contained therein.

From that point on, the BIOS loses control. The OS boot loader calls runtime BIOS services to load the operating system kernel from mass storage, and then passes control to the OS kernel to finally get the show started.

Any questions?

regards, Peter

 

[RamonetB]

Yes.

Can you help us in getting a BIOS to recognize and support the AMD K6-2+?

Pretty please?

 

[highwire]

Man, all this code cracking with Debug is giving me really bad flashbacks. But, keep it up.

 

[CTho9305]

<< Any questions? >>


yup. How do I write my own BIOS? Basically, how do I get assembly I write to get run FIRST THING on boot?

edit: i imagine this depends on the chipset, right? what exactly it does with the ROM BIOS

 

[Peter]

RamonetB,

well sure I can write a BIOS that supports K6-2+ ... for my company's boards. While BIOS core is something you buy
from AMI or Phoenix, one needs to port quite a lot of stuff to the particular implementation on each mainboard.
Without the board's schematics, no chance to do it right.

CTho, what do you want? Get a grip of the system during POST, before boot, or right when the CPU is coming
out of Reset? For the former, write an extension ROM image (see Microsoft PnP specification on how to do that) and
hook it up to the main BIOS using the appropriate Award, AMI or Phoenix tools. For the latter, write assembly language
stuff - caution: You have no RAM and no stack at this point, just the CPU, the chipset north and south bridges, and the ROM -
and put an ORG directive in there that makes a "JMP mycode" appear sixteen bytes from the end of your resulting binary file.

Pull the original BIOS chip out and your own one in. But to get any given system to actually do something useful, you
need lots and lots of documentation - CPU, chipset, super-IO, everything else that's on. Mainboard schematics, 3rd party
code from the makers of graphics, IDE, SCSI, sound, modem, network chips.

It's hard enough if you do that for a living and have access to all the undisclosed information, get your engineering questions
answered by the chip makers' application engineers, have the mainboard schematics at hand. Write your own BIOS for
something you don't know - forget it, I'd say.

regards, Peter

 

[RamonetB]

The trick of it is this:

THe board already supports the AMD K6-3. On boards that don't properly detect the K6-2+, they detect it as the K6-3 and run it as such (with half the Cache of course since the cache detection only sees 128K).

SO in reality, we don't want to rewrite the BIOS entirely. Just get it to think the K6-2+ IS a K6-3. The current BIOS is designed so that if it doesn't recognize it specifically as one it knows, it doesn't bother booting.

This does, of course, leave out the PowerNow! Technology as well as the write back feature of the cache. But to be honost, we don't really care about that since the only other option IS the K6-3. Which is VERY expensive and produces A LOT OF HEAT.

How hard would it be to get the BIOS to see the K6-2+ as the K6-3?

-kirk

 

[CTho9305]

<< CTho, what do you want? Get a grip of the system during POST, before boot, or right when the CPU is coming
out of Reset? For the former, write an extension ROM image (see Microsoft PnP specification on how to do that) and
hook it up to the main BIOS using the appropriate Award, AMI or Phoenix tools. For the latter, write assembly language
stuff - caution: You have no RAM and no stack at this point, just the CPU, the chipset north and south bridges, and the ROM -
and put an ORG directive in there that makes a "JMP mycode" appear sixteen bytes from the end of your resulting binary file. >>



cool, it is there. now I can see whats going on by looking at the image. (i'm interested in controlling the CPU right out of reset)



<< But to get any given system to actually do something useful, you need lots and lots of documentation - CPU, chipset, super-IO, everything else that's on. Mainboard schematics, 3rd party code from the makers of graphics, IDE, SCSI, sound, modem, network chips >>



it doesn't need to be useful. just doing it to learn. Do I have interrupts yet? like int 10h for video stuff?

also, could you enable PM's?

 

[Peter]

As I said, you have NOTHING.

To get to the point where you can call Int 10h runtime VGA services, you must have come a looooooong way.

You need to invoke the VGA BIOS so that it hooks Int 10h.

To be able to do that, you must have initialized PCI and AGP busses, found all devices there, mapped all the resources they request into CPU memory and I/O address space, and enabled them. If a VGA device is among them, you copy its ROM image from where you mapped it to into system ShadowRAM in the legacy VGA ROM space starting at 000Cxxxxh, and call it. (The VGA BIOS will then bring the graphics engine up, set it to text mode, say hi to the user, and return to the system BIOS.) In order to do all that, you must obviously have found and enabled the system RAM, and enabled ShadowRAM to appear there.

Now read that paragraph from end to start, and you have the same boot sequence again. RAM first, then chipset init, then peripheral busses init, then peripheral device init, then mass storage, input/output devices, runtime preparations, and finally OS boot sequence.

In other words, at the point where you can finally output stuff to the screen you're almost done. The hard work has happened before that.

regards, Peter

 

[CTho9305]

interesting, thanks. got any resources which list what different "out <port>, data" instructions do?

 

[Peter]

Yep. You have the legacy ISA resources (timer, DMA and IRQ controllers), as well as the PCI and ISA PnP configuration
access ports. See any chipset south bridge datasheet ... Intel's describe that old stuff pretty well.

Everything else needs to be enabled to a certain I/O port or memory address range by YOU, the BIOS developper, before
it can be accessed.
How to do that, and what the stuff you just enabled does and how, is in the datasheet of the respective device.

Like if you want a legacy keyboard controller, you access the chip it is in (the SIO or the chipset south bridge, depends
on chip choice and mainboard design) to set the KBC control registers such that the KBC decodes to I/O ports 60h and
64h and enable it. Subsequent I/O to ports 60h and 64h will then give you access to the KBC. To find out how to
do the configuration part, you need to know which chipset and super-IO chip you have there, and if both of them have
a KBC, which one the mainboard designers actually wired to the keyboard and mouse plugs.

regards, Peter