Need know Specifics of BIOS operation at code level.

[RamonetB]

I need to know the specifics of how a BIOS operates, specifically at the code level. More importantly, cpu identification and initialization sequences.

I'm sure this varies by bios. But a generalized outline would be nice.

For instance: THe CPU first access code at FFFF_FFF0h. In here there is a JMP statement telling the cpu where to go to begin processing code, specifically the BIOS. Now, where does this JMP point to???
THis probably also varies by BIOS, so how can I determine what it is??

And where exactly is that memory location anyway (FFFF_FFF0h)? Is that a register on the CPU or truly a memory address? Because it sure as heck isn't coded into the BIOS.


Please help!

-kirk

 

[Peter]

FFFF_FFF0 is a memory address, 16 bytes from the top of the 32-bit address space. And it sure as heck IS within BIOS. As you guessed, there's a JMP there that makes the freshly started CPU hop into the early BIOS initialization sequence. See earlier threads on this for more information.

regards, Peter

 

[RamonetB]

I think I see the problem I'm encountering. THe memory address is NOT a position in the BIOS rom itself. THe BIOS puts a JMP at that memory location.

Where can I find these previous threads? Are they in this forum or others on anandtech?

Haven't found them searching this one.

-kirk

P.S. Forgive my ignorance, I'm new at this.

 

[Peter]

Again, read my lips: The memory address IS within the BIOS ROM. How should BIOS (a piece of software!) possibly do anything before the CPU started?!? It can't. The system is built (in hardware) such that the BIOS ROM lies in memory exactly at the place where the CPU starts executing - at the upper end of the CPU address space.

Yes, that's a linear hex address, sixteen bytes from top-of-address space. How do I know? Well, I'm an x86 BIOS engineer in real life ...

regards, Peter

 

[RamonetB]

I'm by no means doubting your credentials.

What I AM trying to do is add in support for the K6-2+ on my laptop, which supports all Socket 7 chips aside from the AMD + line.
The going has been very slow since information is hard to come by. Learning x86 is not the easiest thing either. Those who know the details haven't been willing to help much either.
Confusion is easy.
And the reason is thus:

I've backed up the current BIOS and have decompiled it to x86 language. I can't find the JMP string in the code. It's a 256K AMI BIOS with max memory line of 0003_FFFFh.
That's confusing thing number one. Now I recognize that with the BIOS in memory and decompressed the memory address may be different. Which is why I was asking as well how I'd figure out what that JMP value actually is.
In any event, there is no JMP value in that location.
Or in 0002_FFF0 or 0001_FFF0 or 0000_FFF0 16byte locations. Which doesn't line up anyway since the location is supposed to be FFFF_FFF0 16bytes. As for my previous statement about the BIOS placing it in memory, you're right that was stupid. I wasn't thinking then. Confusion and frustration will do that to me.

So, I'm obviously thinking about this very wrong. And I'm sure I'm beginning to frustrate you as well. Understandable. However, if you could explain these things to me so I could finally see it clearly I'd greatly appreciate it.
And those other threads would be nice too.

-kirk

 

[Peter]

so ... that BIOS chip has a size, yours is 256 KBytes. The mainboard chipset automatically, upon powerup or reset, makes these 256 KBytes visible to the CPU at the top of address space. So starting from linear address FFFC_0000, you'll see your 256 KBytes of stuff.

Calcing back, you should see the long sought for "JMP elsewhere" starting point at offset 3FFF0 in your EEPROM dump file.

Typically, at least the top 16 KBytes in there are uncompressed code handling the very early pre-initialization of the most important stuff (the "bootblock" code). Your JMP will hop somewhere in there and start working on stupid legacy stuff like enabling the keyboard controller and RTC device, then go on pre-initing the chipset, and detecting RAM. Up to this point this is really nasty spaghetti assembly language code - it has to be that way since there is no stack and no RAM, so you can't store, load, push, pop, nor call subroutines the usual way. Once RAM has been found, it's initialized, the stack activated. Then the last thing bootblock program does is decompress the main POST program into the newly found RAM, and JMP into it.

Somewhere early in main POST the CPU type detection and init will be done. Good luck in finding it. I'd start out by skipping the bootblock altogether, just looking at the POST program.

regards, Peter

 

[RamonetB]

You've been of tremendous help.

I have one more question for you then.

After reading your post about the details of the boot process I am now suspecting that the Laptop, hardware wise, does not support this chip.

You see, with the chip installed nothing happens. Litterally, nothing happens. The system responds as though there were no chip in it at all. It's not the first I've heard of a system not booting when a chip isn't supported, but usually you get some other action, correct? Even when I put a chip in and try to operate it beyond what it can boot or something similar, I at least get a cd-rom power on light.
With the K6-2+ I don't even get that. To reiterate, it's as though no chip is present in the slot.

According to the K6-2+ Data Sheets, there are certain power requirements, rather certain power up times that are required for proper support. My original theories were the BIOS receiving a code "D" (the chip family) from the chip when CPUID is called and not knowing what to do with it and then hanging (I don't really trust others putting gaurded statements in code anymore). Another was that the power management featuers and register needed to be initialized when the chip is detected. Since no code is present, nothing happens. However, I now doubt it's getting that far.

In your professional opinion, is this an unsupported BIOS issue or a hardware issue?

THanks again.

-kirk

 

[Peter]

Without the proper diagnostic tools, no way of telling. It might be that the thing doesn't even come out of Reset/Poweron
properly, it might be that BIOS starts, does the bootblock thing, then finds an unknown CPU and gives up (or tries to
boot up anyway and hangs later because of the un-initialized processor). Things like that. This is the point where you
need some kind of debug access, a logic analyzer, the schematics of the thing and the source code to the BIOS. In other
words, the engineering team that made it could diagnose what happens. From the blackbox view you have as a consumer,
not a chance.

regards, Peter