BIOS Updates forum

Hello all,

I have a Via M10000, with on-board video and 6.00PG bios. My goal is to keep the fullscreen logo showing until my Linux kernel switches video modes and displays something else (removing text output from LILO and kernel, etc). So I removed all int 0x10's from my system bios, bootblock bios, and awardext.bin that were doing text output, or switching to text mode. But unfortunately, at the very end the bios still clears the screen, goes into text mode, and prints "Verifying DMI pool data... Success". So I think it must be writing this text directly to the framebuffer, and using some method other than int 0x10 to switch to text mode. But I don't know how it is doing it.

It also seems to me that the logo is drawn in one video "page" while text is drawn in another. I think that is the case because before I removed all the text printouts, after the logo was shown and it switched back to text mode, you could see all the text that was printed earlier. So I think if I can figure out where this page switching is taking place I can force it to stay in the logo page while booting.

Does anybody have any idea what I should be looking for?

Alex

Just to add more info... the "Verifying DMI Pool" string is located in awardext.bin. The mode switch occurs before this, but I don't know whether it's in awardext or the main system bios. I removed all int 0x10's from awardext as well, but it still prints that string. I did see a few places where strings are copied directly to B800+offset or B000+offset (framebuffer).

Also, it is ok if this modification removes ALL text, rendering configuration impossible, as it is for an embedded application and I have a bios savior should I ever need to make a configuration change.

Hi.

Using int10 is not the only method to display text.

IIRC, the Video Mode initialization is carried out just before displaying the EPA Logo (or whatever logo in may contain) in Award BIOS. However, my experience is limited to Award v4.50.

You might want to look for "80 8EE1 0110 F646 1430" byte pattern.

80 8E E1 01 10 or byte ptr [bp+1E1h], 10h
F6 46 14 30 test byte ptr [bp+14h], 30h

Above is the signature bytes of the beginning of the EPA Logo initialization.

IIRC it's still exist in Award v6.00PG. I've been working with Award v6.00PG, but not much and not in the video related area .

These articles might help you:
http://www.geocities.com/mamanzip/Artic ... cking.html
http://www.geocities.com/mamanzip/Artic ... ching.html

There is also a possibility that newer BIOS uses VESA procedure, not the old int 10h anymore.

The last resort if you still don't find it is to scan over the POST Jump Table .

In any case, IDA Pro disassembler is your friend

goodluck.

Borg Number One wrote: Using int10 is not the only method to display text.

I know... I wish it were that easy

They DO use some vesa stuff to switch to 640x480x256 colors, through the int 10 mechanism. After that I think they probably retrieve a pointer to the video card's vesa functions and call them directly, but I haven't figured that out yet.

In any case, I think the mode switch occurs right before the xgroup module is executed. The problem is, I don't understand the long jumps, since I don't know what is code sections/modules are mapped to what memory regions. So I'm having a hard time figuring out at which point it jumps to the xgroup. Does anyone know what that code signature looks like?

Thanks for the help,
Alex

XGROUP is decompressed and then relocated to segment 1000h by the system BIOS ("original.tmp") in Award v6.00PG. Note that this task is the very first POST routine/POST jump-table entry in Award v6.00PG.

Thus, if you find a code in POST that do a far call to this segment (1000h). It calls the related XGROUP function.

Moreover, XGROUP is "jumped-into" by the code in the system BIOS and other compressed BIOS modules numerous times for different kind of tasks, in different offsets. We can view XGROUP as an integral part of the system BIOS itself. It serves many functionalities, not just one. Thus, you can't just try to find its entry points coz there is no single entry point. There are many entry points, depending on the function that is requested by XGROUP "client(s)"

Thanks for the help everyone. I found out that the last POST function (127) calls a function that resets the video mode right before it jumps to the xgroup. After removing that with NOPs, the screen stays in graphics mode!

However...
There is still one thing that is not quite right. I still get the text "Verifying DMI pool data... Success" before it starts booting the OS. I have tried everything to get rid of this, including overwriting the string with space characters (in the xgroup module). But it still prints that out. I have searched for "DMI" in every bios module, but the only place I can find it is the xgroup string that I wrote over. Is it possible that that string is stored in the CMOS? I'm so confused...

Now I'm even more confused. I've been inserting the bytes FAEBFE (cli, short jump to same address) to freeze the bios in different places. I found that inserting it right before/over a "call 0x1000:0x28f8" made the bios freeze before the text gets printed, and placing it right after that call made the bios freeze after the text gets printed. So it looks like that function handles the DMI pool stuff. BUT, if I open up my xgroup code, awardext.rom, and insert those bytes at offset 0x28f8, nothing different happens! The bios just keeps running, prints out the DMI stuff, and boots up normally. It is as if that xgroup file makes no difference at all...

That function at 28f8 does print out several strings ("updating ESCI data", etc)... so from the code I would assume that I'm pretty close..

I figured out the problem! It is a bug in cbrom! I had the files awardext.rom and awardext-modified.rom in the same directory. When doing "cbrom215.exe mybios /xgroup awardext-modified.rom", it will actually insert awardext.rom (it truncates your filename to 8 chars). BUT, when you run cbrom /D, it will tell you that the module's filename was awardext-modified.rom.

Well, now everything works! Thank you all for the help.

the same as modbin6 bug

http://www.rebelshavenforum.com/sisubb/ ... 2;t=000041

cbrom 2.15 is NOT recommended for using. Use 2.07 or 2.08.
But for last bioses correct working only cbrom32-versions. I recommend - cbrom32 v. 1.49 (it correct work with old bioses too).