OSDev.org

This is an issue I thought about looking at.

A problem with UEFI is that you must setup a single video mode (preferentially the mode which matches the display used), and this must be done before exiting boot-services. In practice, you must call ExitBootServices before you start paging, which means you cannot log faults or debug-reports between setting up paging and loading a TrueType font aware driver that could write to the selected video-mode. Of course, with text-mode support, it is simple to start in text-mode and to write these reports directly to B800:0, which is the buffer for legacy text mode.

Not that I use B800:0 directly anywhere, as all text-mode output is done with a specific API. Still I cannot rely on a functional TrueType rendering engine during boot or catastrophic fault reports.

So how to solve this issue? One possibility might be to create a fixed-font font generator with a 8x19 font (which uses only 4864 bytes) which for the typical 25x80 text mode will give a display width of 640x475, which means the 25x80 text mode will be visible on the minimum 640x480 resolution. But when this font is used on the more typical 1366x768 resolution, it will only cover about 1/4 of the display-area, possibly being unreadable on small displays.

The blue-screen of death of Windows seems to use a fixed-font (possibly 8x19), but scaling the text mode to fit the actual screen resolution. For 1366x768, this will mean a usable text area of 40x170.

Another possibility (more complex) is to provide a couple of different font sizes to better be able to adapt between the standard 25x80 text mode and different display resolutions.

Thoughts?

Log debugging information to serial, a file or the network.

Brynet-Inc wrote:Log debugging information to serial, a file or the network.

Serial: Not available on most modern computers. When available, are typically run over USB, and thus need functional USB drivers.

File: The file system is mounted at a very late stage. File systems are thread-based, and thus not guaranteed to be stable or usable if the kernel is booting or has a panic fault

Network: Network stacks are typically threaded as well, so has the same problem as the file approach.

For pure logging on remote installations, I write fault data to fixed disc sectors (not through the file system), but this doesn't work for panics or boot-problems. It doesn't work if the disc itself generates the problem either (for obvious reasons).

I'd just go and grab a copy of the font from one of the original IBM graphics cards. Due to a quirk of US copyright law, bitmap fonts are not eligible for copyright protection; therefore, all US originated bitmap fonts are public domain worldwide.

That will fill the hole until you can do better font rendering.

On UEFI, you might want to stash short crash reports in UEFI variables using the RuntimeServices->SetVariable method, with provisios regarding bricking of some Samsung laptop models

Owen wrote:I'd just go and grab a copy of the font from one of the original IBM graphics cards. Due to a quirk of US copyright law, bitmap fonts are not eligible for copyright protection; therefore, all US originated bitmap fonts are public domain worldwide.

I found one online, which was described with spaces and '#', which was easy enough to convert to assembler-format with DBs. It is 8x19, which is a good format. Then I found a table converting text-attributes to rgb.

I also need to redo the text-mode interface so it is independent of the normal graphics format which is loaded about the same time as the TTF-engine. This results in a set of assembler-routines that can be statically linked into the crash debugger and panic handler, and which also could be used when a graphics mode program aborts and Watcom outputs the fault-text with the console API.

rdos wrote:One possibility might be to create a fixed-font font generator with a 8x19 font (which uses only 4864 bytes) which for the typical 25x80 text mode will give a display width of 640x475, which means the 25x80 text mode will be visible on the minimum 640x480 resolution. But when this font is used on the more typical 1366x768 resolution, it will only cover about 1/4 of the display-area, possibly being unreadable on small displays.

The blue-screen of death of Windows seems to use a fixed-font (possibly 8x19), but scaling the text mode to fit the actual screen resolution. For 1366x768, this will mean a usable text area of 40x170.

Another possibility (more complex) is to provide a couple of different font sizes to better be able to adapt between the standard 25x80 text mode and different display resolutions.

Thoughts?

For the 800x600x32 resolution i have used the 8x8 GRAPHICS FONT for characters 00h-7Fh at the address in "F000h:FA6Eh" (1024 byte) from the pointer of int 1Fh. For each bit i set 4 pixel on the screen to become 16x16 chars.

Dirk

There is a bitmap (public domain) font, called unifont, which contains glyphs for all of the code points in the basic multilingual plane. Most of the glyphs are 16 pixels by 8 pixels, although some of the more exotic glyphs (Chinese for example) are 16 bits wide.

In its raw form it comes as a text file containing hexadecimal numbers representing the code points, then a colon, and then the corresponding bitmaps for each character. However, somebody wrote a utility which converted it into a true type font. Possibly you could find a utility to convert the true type font back into bitmaps of whatever size you desire.

Hi,
This topic is a little old, so apologies.
Not really sure but,
When a computer (Real Hardware) is rebooted the memory (RAM) isn't cleared, right?
How about your OS writing the log to a high and safe memory location which does not conflict with any firmware or your code, then when you reboot your PC, start it in legacy mode (I'm sure most firmwares provide that option), and then ouput it by writing it to 0xB8000 from the memory location.
This isn't neat, I could be wrong about the memory not being cleared (It could even contain 1's). Another way could be directly writing the log to disk sectors. (Which may even destroy the disk).
-Bender

rdos wrote:Network: Network stacks are typically threaded as well, so has the same problem as the file approach.

Actually, UDP is surprisingly easy to implement when you've got your ethernet (or whatever) driver written. In an early panic this driver doesn't need to be as complicated as the real driver. Anyway, with UDP you could send syslog messages to another machine.

Alternatively, you could log via Morse code using some indicator: LED, flashing screen, speaker, etc.

Hi,

Bender wrote:When a computer (Real Hardware) is rebooted the memory (RAM) isn't cleared, right? How about your OS writing the log to a high and safe memory location which does not conflict with any firmware or your code, then when you reboot your PC, start it in legacy mode (I'm sure most firmwares provide that option), and then ouput it by writing it to 0xB8000 from the memory location.

I've tried that before, only to find that for a lot of computers memory is cleared if/when the computer is reset. For security purposes this is a very good thing (e.g. RAM full of sensitive/protected data, where attacker resets computer and boots a tool to extract the sensitive data left in RAM).

Bender wrote:This isn't neat, I could be wrong about the memory not being cleared (It could even contain 1's). Another way could be directly writing the log to disk sectors. (Which may even destroy the disk).

An alternative is to reboot the OS without resetting the computer (e.g. kexec in Linux). This preserves the contents of RAM (e.g. allows you to boot an new instance of the OS to debug crashes in the previous instance of the OS), and could also be used for other reasons (e.g. minimising downtime due to kernel updates).


Cheers,

Brendan