OSDev.org

What is the best way to enable the "linear framebuffer"?

You haven't actually read the manual I linked, have you?

DMA at A0000

Do you know what DMA is (and therefore how wrong that statement is)?

In other words:

Forum rules wrote:If you don't understand...

If you don't understand the answer, do not immediately bounce back a demand for clarification. Use the same tools that you used to try and answer your original question (manuals, FAQs, the Web, skilled friends) to understand the answer. Then, if you still need to ask for clarification, exhibit what you have learned.

Try it, it helps.

Chandra wrote:C0000000 is the virtual address.

That should be a physical address.

I think that's all.

-Set A20
-Scaned al vesa modes and stored all usefull VESA info
-Set VESA mode
-Stored all usefull information about the BOOT DRIVE
-Stored the memorymap (function E820 of int 0x15 -> Ralf Browns Interrupt List -> vendor specific TRUE???)
-Set protected mode
-Load sector 2 to 10 (should be changed if the kernel finished in the year 2154 and i know the size)

133 bytes (0x85) left on sector 0 for comments or someting I forgot.
Now it just display "!" if something is not supported of just fails to work.

Does a USB keyboard still work by scanning port 60???
I don't have a USB-keyboard so I can't test this. (hammer time)

Hi,

Holus wrote:So far:
1. I checked the memory so I know what limits my memory-manager has.
2. I checked the bootdevice so I can define how to read from it to set-up other hardware.

Ideas include (not necessarily in any order):

1. Get the BIOS "ticks since midnight" value as soon as possible, and store it somewhere
2. Make sure you're in 80*25 text mode (so you can reliably display error messages, etc)
3. Get a map of the physical address space (e.g. where usable RAM is, etc); and convert it to the format that the OS/kernel wants (e.g. make sure there's no overlapping areas and sort the list)
4. Start building a "boot log" in RAM (so that after boot you can store it as a file or something that contains all messages from the OS since the beginning of the boot loader). Note: from this point on, everything displayed on the screen would also be added to the end of the boot log
5. Find ACPI, MP spec and/or SMBIOS tables (you may or may not need info from ACPI tables in the boot loader)
6. Uniquely identify the boot device if possible, so OS can correctly find it after boot
7. Gather information about other storage devices, so that OS can know which devices correspond to which BIOS device numbers; and can know how many sectors per track, heads and cylinders the BIOS thinks the device uses (needed by any partitioning tools to reliably/correctly set the legacy "CHS" fields in partition tables, because you can't know which CHS -> LBA translation scheme/s the BIOS uses without this info and would have to rely on "guessing with fingers crossed").
8. Enable A20
9. Ask "PCI BIOS" which mechanism should be used to access PCI configuration space (so OS doesn't need to probe/guess if it should use "mechanism #1" or "mechanism #2" later).
10. Load more data from the boot device (e.g. kernel and device drivers, or "boot image" or "RAM disk" or whatever), and:
    • Decompress whatever you loaded from the boot device
    • Check whatever you loaded from the boot device (could be a CRC or a simple checksum intended to detect corrupt files; or could be something intended for security like a digital certificate, and could potentially involve TPM)
11. Determine if there's a video card, and:
    • Get a list of video modes
    • Get EDID from the monitor
    • Decide which video mode to use and prepare to set that video mode (e.g. pre-allocate any buffers, etc)
    • Set a video mode
    • Re-display the last lines from the "boot log in RAM" (so user isn't suddenly left with a blank screen)
    Or:
    • Prepare for an alternative (e.g. serial port to a dumb terminal, or maybe telnet over ethernet)
12. Prepare timing, including:
    • Get the BIOS "ticks since midnight" value again and use it (in conjunction with the original "ticks since midnight" value) to calculate time spent in boot loader up to this point
    • Get the value of some other time counter that doesn't rely on IRQs (e.g. ACPI's idle counter, HPET's main counter, a CPU's TSC or something) and store it; so that (later on) kernel can accurately calculate total time spent booting (including time spent in boot loader)
    • Get the current time and date from the BIOS; so that later on kernel can use "time and date when some other counter was first read plus difference in some other time counter" to initialise its time and date service. Note: The idea here is "future-proofing" - using BIOS or EFI functions to get time and date during boot, to avoid the need to directly access the RTC chip later.
13. Mask all IRQs in the PIC, then allow BIOS to handle any "pending" IRQs that occurred while you were masking, then set IDT limit to zero so that unexpected NMIs (that boot code is unable to handle correctly) are guaranteed to cause triple fault/reset

Cheers,

Brendan

Hi,

Holus wrote:Does a USB keyboard still work by scanning port 60???
I don't have a USB-keyboard so I can't test this. (hammer time)

For some motherboards the legacy "PS/2" interface does work, because it's emulated by the chipset and firmware's SMM code. For some motherboards it doesn't work (because this emulation is disabled by the user, not supported, or broken). Some computers are so broken that even the BIOS "get keystroke" function doesn't work (although that's hopefully rare).

USB drivers are the only reliable way of getting USB keyboards working.


Cheers,

Brendan

Brendan wrote:Ask "PCI BIOS" which mechanism should be used to access PCI configuration space (so OS doesn't need to probe/guess if it should use "mechanism #1" or "mechanism #2" later).

Never heard of that. What is "PCI BIOS", and what are the different mechanisms? Wouldn't it be best to use ACPI to enumerate PCI devices (provided ACPI support is available)?

rdos wrote:Never heard of that. What is "PCI BIOS", and what are the different mechanisms? Wouldn't it be best to use ACPI to enumerate PCI devices (provided ACPI support is available)?

PCI BIOS is int 1Ah, function 0B1h. Mechanism #1 realizes access to configuration space through 32-bit ports 0CF8h, 0CFCh. Mechanism #2 realizes access to configuration space through 8-bit ports 0CF8h, 0CFAh and 4 kb IO space frame (it's legacy). What is date when PCI was introduced and what is date when ACPI was introduced?

Brendan wrote:Mask all IRQs in the PIC, then allow BIOS to handle any "pending" IRQs that occurred while you were masking, then set IDT limit to zero so that unexpected NMIs (that boot code is unable to handle correctly) are guaranteed to cause triple fault/reset

And what about "NMI disable" during initialization. Is it not works?

Brendan wrote:USB drivers are the only reliable way of getting USB keyboards working.

That's NOT what I was not what I wanna hear!!
Are there (just like VESA funtion 0x4F0A BL=0x00 INT 0x10) way's to get functions to probe the keyboard??

rdos wrote:

Brendan wrote:Ask "PCI BIOS" which mechanism should be used to access PCI configuration space (so OS doesn't need to probe/guess if it should use "mechanism #1" or "mechanism #2" later).

Never heard of that. What is "PCI BIOS", and what are the different mechanisms? Wouldn't it be best to use ACPI to enumerate PCI devices (provided ACPI support is available)?

I thought ACPI was mechanism 2
Is that not true??

Hi,

rdos wrote:Wouldn't it be best to use ACPI to enumerate PCI devices (provided ACPI support is available)?

The ACPI specification says something like "For hardware that has decent/standardised enumeration (like PCI and USB), an OS uses the existing decent/standardised enumeration and doesn't use ACPI".

egos wrote:

Brendan wrote:Mask all IRQs in the PIC, then allow BIOS to handle any "pending" IRQs that occurred while you were masking, then set IDT limit to zero so that unexpected NMIs (that boot code is unable to handle correctly) are guaranteed to cause triple fault/reset

And what about "NMI disable" during initialization. Is it not works?

There's 3 different approaches for NMI handling (that I'm aware of). The first approach is to disable NMIs when they can't be handled properly (e.g. when you're changing from real mode to protected mode). NMIs were typically generated when there's hardware errors (and ignoring hardware errors and pretending that nothing is wrong is a very bad idea), so this approach is questionable at best. Worst case here is erratic/unpredictable behaviour.

Another approach is to ensure that any NMI that can't be handled properly causes a triple fault. Worst case here is a small chance of "unexplained" reset (which is better than erratic/unpredictable behaviour). This isn't necessarily the best possible method (but it's better than disabling NMI, and it is practical).

The last approach is to be "overly clever". It's possible to trash the real mode IVT entries for interrupt 0x04 (Overflow Exception) and interrupt 0x05 (Bound Range Exceeded Exception) and overwrite these two 4-byte IVT entries with an 8-byte protected mode IDT entry for a protected mode NMI handler; such that immediately before a "mov cr0" that enables protected mode the IVT has a valid real mode NMI handler (at offset 0x0008), and immediately after a "mov cr0" that enables protected mode the IDT has a valid protected mode NMI handler (at offset 0x0010). This also requires a GDT with a valid descriptor for the protected mode NMI handler's CS; and you have to make sure that SS:ESP is valid in both real mode and protected mode - e.g. SS = 0x0008 in real mode, where in protected mode 0x0008 is a data segment with "base = 0x00000080" (note: alternatively you could use a "task gate" for the protected mode NMI handler). In any case, this method is too complex to be practical.


Cheers,

Brendan

Pfff I'm making a DATABASE CLIENT.
I shouldn't be switching to PMODE in the first place!!!
The client stores no data that not is transmitted directly to NIC.
And for quick access it's no option to relay on stored local data.
SO 4 MB of RAM is not even needed.

I switch to PMODE if I start making a DB server that not runs in windows.

I gonna post a new question!!!

Brendan wrote:The ACPI specification says something like "For hardware that has decent/standardised enumeration (like PCI and USB), an OS uses the existing decent/standardised enumeration and doesn't use ACPI".

But PCI does not have decent enumeration since the address space supported by different PCI systems are not identical. Some PCIs will have the same device at many addresses because it doesn't decode everything. Also, it takes too long to check every possible PCI address at boot-time. That's why extracting available PCI addresses, and only checking them, from the PCI0 object in the ACPI-namespace would make sense.

Brendan wrote:[*]Find ACPI, MP spec and/or SMBIOS tables (you may or may not need info from ACPI tables in the boot loader)

This is realy cool stuff and less hard then expected.
But it is accessible in protected mode also.

Does it change when you plug in a USB-device. Or is it only be filled at boot??

SMBIOS is realy cool but the probing for _SM_ is not that cool.

Does this "_SM_" allways found at [0x0000FXXX0] address?
I found some code that searching in staps of 0x10.

And how about:
"_DMI_" and "_SYSID_" (on my computer if can find them with staps of 0x10)

"_UUID_" is placed on 0x10 + 1
or is this only an on my computer exsisting ID?

Hi,

rdos wrote:

Brendan wrote:The ACPI specification says something like "For hardware that has decent/standardised enumeration (like PCI and USB), an OS uses the existing decent/standardised enumeration and doesn't use ACPI".

But PCI does not have decent enumeration since the address space supported by different PCI systems are not identical. Some PCIs will have the same device at many addresses because it doesn't decode everything. Also, it takes too long to check every possible PCI address at boot-time. That's why extracting available PCI addresses, and only checking them, from the PCI0 object in the ACPI-namespace would make sense.

"PCI configuration space" (what it contains, how it is accessed and how to traverse it to discover/enumerate all devices) is well standardised (although unfortunately some of those standards are behind a tall "pay wall"). The only thing not covered is devices behind a "PCI to LPC" or "PCI to ISA" bridge (and ACPI does include some information for legacy/non-PCI devices behind these bridges).

The only case of "same device at many addresses" that I can think of is ISA/legacy devices that aren't PCI (e.gh. behind a "PCI to LPC bridge"); although there may also be some issues with dodgy/borked bridges that don't handle 64-bit device properly.

If you're checking every possible "PCI address" (e.g. "for(bus = 0 to 255) { for(device = 0 to 31) { for(function = 0 to 7) { ... } } }") then you're doing it wrong. If you're doing it right (e.g. only checking buses that exist, and only checking for functions 1 to 7 if the device is a multi-function device), then if it takes too long it's likely that it's not PCI's fault.

For one example of what I meant, here's one paragraph from ACPI (the note in "3.4 Controlling Device Power" in ACPI revision 4.0):

Note:Other buses enumerate some devices on the main board. For example, PCI devices are reported through the standard PCI enumeration mechanisms. Power management of these devices is handled through their own bus specification (in this case, PCI). All other devices on the main board are handled through ACPI. Specifically, the ACPI table lists legacy devices that cannot be reported through their own bus specification, the root of each bus in the system, and devices that have additional power management or configuration options not covered by their own bus specification.

For another example, here's a paragraph from "3.7 Configuration and "Plug and Play" in ACPI revision 4.0:

ACPI is used primarily to enumerate and configure motherboard devices that do not have other hardware standards for enumeration and configuration. For example, PCI devices on the motherboard need not be enumerated by ACPI; Plug and Play information for these devices need not be included in the APCI Namespace. However, power management information and insertion/removal control for these devices can still appear in the namespace if the devices’ power management and/or insertion/removal is to be controlled by OSPM via ACPI-defined interfaces.

To be honest, I'm not too sure what the "_SB.PCIn" part of the ACPI name space is meant to be used for. It's not a replacement for PCI configuration space or PCI's enumeration; and looks like it's only an extension for things that can't be covered by PCI configuration space directly (like PCI hot-plug).

I also don't know much about Intel's ACPICA - it's possible that ACPICA includes PCI device enumeration even though it's not part of ACPI.


Cheers,

Brendan

Hi,

Holus wrote:Does it change when you plug in a USB-device. Or is it only be filled at boot??

All of those tables are created by the firmware during boot and don't change after boot (or when you plug a USB device in).

Holus wrote:Does this "_SM_" allways found at [0x0000FXXX0] address?

If it's present, it's always at a "0x000F???0" address. If SMBIOS isn't supported (e.g. old hardware) then it probably won't be present (you should be careful of "false positive" - always use the checksum to make sure you found it and don't rely on the "_SM_" signature alone, as there's a small chance of "random bytes" containing that signature by accident).

Holus wrote:And how about:
"_DMI_" and "_SYSID_" (on my computer if can find them with staps of 0x10)

"_UUID_" is placed on 0x10 + 1
or is this only an on my computer exsisting ID?

"_DMI_" is obsolete (superseded by SMBIOS) and I wouldn't bother checking for it. I can't remember what the "_SYSID_" and "_UUID_" signatures are for (are you scanning the firmware for anything that happens to look like an ASCII string?).


Cheers,

Brendan

Brendan wrote:To be honest, I'm not too sure what the "_SB.PCIn" part of the ACPI name space is meant to be used for. It's not a replacement for PCI configuration space or PCI's enumeration; and looks like it's only an extension for things that can't be covered by PCI configuration space directly (like PCI hot-plug).

As far as I can see (albeit from very limited testing on a small number of machines), any machine with ACPI support that also has a PCI root bus will have a device in the _SB namespace with a _HID value for the PCI root ("PNP0A03"). This allows you to have a single 'machine init' process for ACPI which will then load a PCI driver if PCI is detected. Similarly for PCIe. All of the ones I have seen also provide an interrupt routing table for the PCI bus (_PRT) and also a _CRS entry which usually contains an IO address at 0xcf8. I suspect presence of this entry implies that configuration mechanism 1 can be used.

Once a PCI bus is identified then you should use the PCI enumeration functions rather than ACPI to find devices and other buses (as previously stated by Brendan).

Note that there is nothing specifying that a PCI root bus needs to be called \_SB.PCI0 (although most are) - searching for the HID string seems the safest way.

It is highly likely however, that some supposedly ACPI compliant machines will not report this information correctly and either direct probing for a PCI bus or use of real mode functions should probably also be used as a backup - for this you would have to use the PCI bios functions before switching to pmode (or switch back later/use vm86).

Regards,
John.