kernel: replace Spleen font with an enlarged version of the original KDL font

Recently we introduced Spleen as a larger font for KDL for high
resolution displays. However, it looks quite different from our original
font. I designed an enlarged version of our original font (designed by
Brian J. Swetland and also found in NewOS, LK and Fuchsia) to use
instead.

Change-Id: I10872e407d45b906f8b6c7ba44b2f993dcd19bff
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5382
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>

boot_loader: Add a video_text_console for potential use by bootloaders.

This uses the frame buffer console that KDL uses. It needs some work,
though, as the frame_buffer_console colors system is not quite compatible.

kernel/debug/frame_buffer: Lock should always be initalized

* Without this, kernel will crash on boot when a framebuffer
isn't provided by bootloader. (like on the riscv64 today)

Change-Id: I5ec64db30972c7c3b19e4cdb31f0fe72b5982c0f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4494
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>

Framebuffer console: Add spleen font (12x24)

Use this larger font when the screen resolution is large (more than
1920x1080 in both directions). The usual font is too small and not easy
to read on such high resolution displays.

Change-Id: I14a40ecf6917d0c6c64ab5a8abe1affcb3839a74
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3818
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>

OS: Rename B_USER_CLONEABLE_AREA to B_CLONEABLE_AREA.

It now lives in OS.h. The idea is that this will now be
accessible to userland applications, so userland memory
is protected from access by other processes, just as
kernel memory is.

No functional change (the constants are still the same,
though I've changed some to use shifts to make clear
which bits are allocated are which are unused.)

kernel: support for Intel SMAP and SMEP on x86_64.

SMAP will generated page faults when the kernel tries to access user pages unless overriden.
If SMAP is enabled, the override instructions are written where needed in memory with
binary "altcodepatches".
Support is enabled by default, might be disabled per safemode setting.

Change-Id: Ife26cd765056aeaf65b2ffa3cadd0dcf4e273a96

kernel: debug: map the frame_buffer for the kernel only.

Add a dumb framebuffer driver.

This is separate to the VESA driver, as the VESA driver requires
using the VBE BIOS. Under UEFI, we don't have the VBE BIOS, nor
are we able to switch modes after leaving UEFI Boot Services, so
a dumb framebuffer driver seemed like the easier way to approach
the problem.

The framebuffer & vesa drivers now test for the presence of the
VESA_MODES_BOOT_INFO boot item to distinguish between which driver
to use. Also added check for the VESA mode count to determine
whether to add the VESA_MODES_BOOT_INFO item.

UEFI video updated to explicitly zero out the VESA and EDID
boot data.

Add blue_screen and frame_buffer_console into the bootloader.

These can be used for on-screen debug output with relatively little
effort, as they just need a plain framebuffer definition to work.

Some stubs are added to not clutter up the kernel sources with too
many ifdefs.

Removed the addr_t conversion operators from FixedWidthPointer which makes comparison against NULL work properly.

Changes to kernel_args to make it identical for x86 and x86_64.

* Added a FixedWidthPointer template class which uses 64-bit storage to hold
a pointer. This is used in place of raw pointers in kernel_args.
* Added __attribute__((packed)) to kernel_args and all structures contained
within it. This is necessary due to different alignment behaviour for
32-bit and 64-bit compilation with GCC.
* With these changes, kernel_args will now come out the same size for both
the x86_64 kernel and the loader, excluding the preloaded_image structure
which has not yet been changed.
* Tested both an x86 GCC2 and GCC4 build, no problems caused by these changes.

* Changed physical_entry::{address,size} to phys_{addr,size}_t and changed
map_physical_memory()'s physicalAddress parameter type from void* to
phys_addr_t. This breaks source compatibility, but -- as long as
phys_{addr,size}_t remain 32 bit wide -- keeps binary compatibility with
BeOS.
* Adjusted all code using the affected interfaces (Oh what fun!). Added a few
TODOs in places where the wrong types (e.g. void* for physical addresses
are used). Looks like quite a few drivers aren't 64 bit safe and others
will break with PAE.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36960 a95241bf-73f2-0310-859d-f6bbb57e9c96

* If the VESA driver remaps the frame buffer on init, it will now also make
sure that the kernel's frame buffer console points to the right data.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34835 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Moved the VM headers into subdirectory vm/.
* Renamed vm_cache.h/vm_address_space.h to VMCache.h/VMAddressSpace.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34449 a95241bf-73f2-0310-859d-f6bbb57e9c96

* The VESA driver now tries to find the PCI card that it is controlling by
checking the physical frame buffer location.
* This allows us to map the whole frame buffer at once, which means there is no
need anymore to remap the memory on mode change.
* Also, this will ease the burden of the MTRRs, as the memory size will be
properly aligned.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34206 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added VESA capabilities field to the kernel args.
* The vesa driver no longer uses VGA programming if the chip does not support
VGA compatibility.
* The VESA driver now tries to set the DAC to 8 bits per color gun.
* In VESA modes, the driver no longer tries to use VGA programming; introduced
the new vesa_set_indexed_colors() that is now used for palette programming.
This should fix wrong colors of 8 bit BWindowScreen users with VESA on real
hardware (emulators usually didn't mind either way).
* Note that the app_server needs to maintain a palette per 8 bit screen, as
right now, the colors are garbled after a workspace switch. Stefano, are you
looking into that already?


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32347 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Setting the depth to 1 for VGA mode in frame_buffer_console_init() was not
a good idea; it didn't have any consequences in there, but actually broke
the app_server's support for the VGA mode.
* Cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32181 a95241bf-73f2-0310-859d-f6bbb57e9c96

* This fixes VGA mode frame buffer use, no idea when this got broken. It might
be broken in the app_server now, but I haven't checked yet.
* Fixed typo in vesa.h.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32141 a95241bf-73f2-0310-859d-f6bbb57e9c96

* 15 and 16 bit KDL consoles now have nice colors, too.
* For 8 bit, the palette is pretty messed up during the boot process
(thanks to the boot loader image), so that we might want to change
how the colors are set then.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28393 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Made the KDL colors a bit more eye friendly in 24/32 bit modes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28391 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Initialize all static mutexes in the kernel through a MUTEX_INITIALIZER()
and remove the then unneeded mutex_init() for them.
* Remove the workaround for allowing uninitialized mutexes on kernel startup.
As they are all initialized statically through the MUTEX_INITIALIZER() now
this is not needed anymore.
* An uninitialized mutex will now cause a panic when used to find possibly
remaining cases.
* Remove now unnecessary driver_settings_init_post_sem() function.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25812 a95241bf-73f2-0310-859d-f6bbb57e9c96

* The boot loader now passes on its EDID info to the kernel, and that will
be put into a boot_item in frame_buffer_console_init().
* The VESA driver now supports gettings the EDID information as well; this
is necessary now, since the app_server no longer takes over the mode the
boot loader had chosen.
* Note, we might want to do this via vm86 instead in the future, and remove
the kernel part again.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25786 a95241bf-73f2-0310-859d-f6bbb57e9c96

Patch by Jan Klötzke with minor changes by myself:
* Use vm86 mode to call the VESA BIOS to do the actual mode switching by
providing an ioctl in the vesa driver.
* Fix vm86.h.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25680 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Changed get_boot_item() API: it now also can retrieve the size of the boot
item entry.
* The bios_ia32 video platform code now stores the available VESA modes in
the new vesa_modes kernel_args field.
* When configuring a VESA mode via settings file, it's no longer needed to
specify the exact mode - the closest available mode is now used. This should
help with bug #1962.
* frame_buffer_console_init() now also creates a boot_item for the VESA modes
in the kernel_args.
* The VESA accelerant now filters the mode list to only contain modes that
are actually supported.
* Moved non-shared vesa driver data into its own file vesa_private.h.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24675 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Fixed warnings, mostly due to NULL changes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24487 a95241bf-73f2-0310-859d-f6bbb57e9c96

* The boot loader now remembers the bytes per row as told by the graphics card, and
passes that information on to the kernel. This should fix wrong bytes per row with
certain resolutions and graphics cards.
* The boot loader now recognizes 15 bit modes that are advertised as 16 bit modes.
This should fix wrong colors in 16 bit modes on some cards.
* Reenabled setting MTRR for VESA mode - don't remember why I disabled it, but it
works fine on my test machines.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23006 a95241bf-73f2-0310-859d-f6bbb57e9c96

The mutex was created too early, before semaphores could be used.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20098 a95241bf-73f2-0310-859d-f6bbb57e9c96

Implemented on screen debug output during boot - to be enabled in the boot loader
safemode menu.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16081 a95241bf-73f2-0310-859d-f6bbb57e9c96

The short story: we now have MTRR support on Intel and AMD CPUs (the latter
has not yet been tested, though - I'll do this after this commit):
* Removed the arch_memory_type stuff from vm_area; since there are only 8 memory
ranges on x86, it's simply overkill. The MTRR code now remembers the area ID
and finds the MTRR that way (it could also iterate over the existing MTRRs).
* Introduced some post_modules() init functions.
* If the other x86 CPUs out there don't differ a lot, MTRR functionality might
be put back into the kernel.
* x86_write_msr() was broken, it wrote the 64 bit number with the 32 bit words
switched - it took me some time (and lots of #GPs) to figure that one out.
* Removed the macro read_ebp() and introduced a function x86_read_ebp()
(it's not really a time critical call).
* Followed the Intel docs on how to change MTRRs (symmetrically on all CPUs
with caches turned off).
* Asking for memory types will automatically change the requested length to
a power of two - note that BeOS seems to behave in the same, although that's
not really very clean.
* fixed MTRRs are ignored for now - we should make sure at least, though,
that they are identical on all CPUs (or turn them off, even though I'd
prefer the BIOS stuff to be uncacheable, which we don't enforce yet, though).



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15528 a95241bf-73f2-0310-859d-f6bbb57e9c96

Some work in progress of the MTRR support. Shouldn't do any harm yet :-)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15525 a95241bf-73f2-0310-859d-f6bbb57e9c96

Make sure only ASCII characters are rendered.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14039 a95241bf-73f2-0310-859d-f6bbb57e9c96

The app_server now updates the kernel's blue screen frame buffer on mode changes
(only the accelerant HW interface does this for now).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12897 a95241bf-73f2-0310-859d-f6bbb57e9c96

Removed debug/console.c, we no longer need it. frame_buffer_console_init() is now
called by debug_init_post_vm().
Since the availability of a blue screen specific getchar() is static anyway, there
is no need for the sBlueScreenGetChar variable (only the message "only serial input
available" gets lost, but since that is platform specific anyway...).
Hello blue screen! We now have an on-screen KDL, to be enabled by the kernel
setting "bluescreen", just like on BeOS.
The blue screen does not yet support any cursor actions or backspace, though (need
to grab some stuff from our console driver).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12896 a95241bf-73f2-0310-859d-f6bbb57e9c96

Renamed system/core to system/kernel.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12360 a95241bf-73f2-0310-859d-f6bbb57e9c96

Add blue_screen and frame_buffer_console into the bootloader.

These can be used for on-screen debug output with relatively little
effort, as they just need a plain framebuffer definition to work.

Some stubs are added to not clutter up the kernel sources with too
many ifdefs.

Removed the addr_t conversion operators from FixedWidthPointer which makes comparison against NULL work properly.

Changes to kernel_args to make it identical for x86 and x86_64.

* Added a FixedWidthPointer template class which uses 64-bit storage to hold
a pointer. This is used in place of raw pointers in kernel_args.
* Added __attribute__((packed)) to kernel_args and all structures contained
within it. This is necessary due to different alignment behaviour for
32-bit and 64-bit compilation with GCC.
* With these changes, kernel_args will now come out the same size for both
the x86_64 kernel and the loader, excluding the preloaded_image structure
which has not yet been changed.
* Tested both an x86 GCC2 and GCC4 build, no problems caused by these changes.

* Changed physical_entry::{address,size} to phys_{addr,size}_t and changed
map_physical_memory()'s physicalAddress parameter type from void* to
phys_addr_t. This breaks source compatibility, but -- as long as
phys_{addr,size}_t remain 32 bit wide -- keeps binary compatibility with
BeOS.
* Adjusted all code using the affected interfaces (Oh what fun!). Added a few
TODOs in places where the wrong types (e.g. void* for physical addresses
are used). Looks like quite a few drivers aren't 64 bit safe and others
will break with PAE.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36960 a95241bf-73f2-0310-859d-f6bbb57e9c96

* If the VESA driver remaps the frame buffer on init, it will now also make
sure that the kernel's frame buffer console points to the right data.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34835 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Moved the VM headers into subdirectory vm/.
* Renamed vm_cache.h/vm_address_space.h to VMCache.h/VMAddressSpace.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34449 a95241bf-73f2-0310-859d-f6bbb57e9c96

* The VESA driver now tries to find the PCI card that it is controlling by
checking the physical frame buffer location.
* This allows us to map the whole frame buffer at once, which means there is no
need anymore to remap the memory on mode change.
* Also, this will ease the burden of the MTRRs, as the memory size will be
properly aligned.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34206 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added VESA capabilities field to the kernel args.
* The vesa driver no longer uses VGA programming if the chip does not support
VGA compatibility.
* The VESA driver now tries to set the DAC to 8 bits per color gun.
* In VESA modes, the driver no longer tries to use VGA programming; introduced
the new vesa_set_indexed_colors() that is now used for palette programming.
This should fix wrong colors of 8 bit BWindowScreen users with VESA on real
hardware (emulators usually didn't mind either way).
* Note that the app_server needs to maintain a palette per 8 bit screen, as
right now, the colors are garbled after a workspace switch. Stefano, are you
looking into that already?


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32347 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Setting the depth to 1 for VGA mode in frame_buffer_console_init() was not
a good idea; it didn't have any consequences in there, but actually broke
the app_server's support for the VGA mode.
* Cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32181 a95241bf-73f2-0310-859d-f6bbb57e9c96

* This fixes VGA mode frame buffer use, no idea when this got broken. It might
be broken in the app_server now, but I haven't checked yet.
* Fixed typo in vesa.h.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32141 a95241bf-73f2-0310-859d-f6bbb57e9c96

* 15 and 16 bit KDL consoles now have nice colors, too.
* For 8 bit, the palette is pretty messed up during the boot process
(thanks to the boot loader image), so that we might want to change
how the colors are set then.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28393 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Made the KDL colors a bit more eye friendly in 24/32 bit modes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28391 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Initialize all static mutexes in the kernel through a MUTEX_INITIALIZER()
and remove the then unneeded mutex_init() for them.
* Remove the workaround for allowing uninitialized mutexes on kernel startup.
As they are all initialized statically through the MUTEX_INITIALIZER() now
this is not needed anymore.
* An uninitialized mutex will now cause a panic when used to find possibly
remaining cases.
* Remove now unnecessary driver_settings_init_post_sem() function.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25812 a95241bf-73f2-0310-859d-f6bbb57e9c96

* The boot loader now passes on its EDID info to the kernel, and that will
be put into a boot_item in frame_buffer_console_init().
* The VESA driver now supports gettings the EDID information as well; this
is necessary now, since the app_server no longer takes over the mode the
boot loader had chosen.
* Note, we might want to do this via vm86 instead in the future, and remove
the kernel part again.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25786 a95241bf-73f2-0310-859d-f6bbb57e9c96

Patch by Jan Klötzke with minor changes by myself:
* Use vm86 mode to call the VESA BIOS to do the actual mode switching by
providing an ioctl in the vesa driver.
* Fix vm86.h.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25680 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Changed get_boot_item() API: it now also can retrieve the size of the boot
item entry.
* The bios_ia32 video platform code now stores the available VESA modes in
the new vesa_modes kernel_args field.
* When configuring a VESA mode via settings file, it's no longer needed to
specify the exact mode - the closest available mode is now used. This should
help with bug #1962.
* frame_buffer_console_init() now also creates a boot_item for the VESA modes
in the kernel_args.
* The VESA accelerant now filters the mode list to only contain modes that
are actually supported.
* Moved non-shared vesa driver data into its own file vesa_private.h.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24675 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Fixed warnings, mostly due to NULL changes.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24487 a95241bf-73f2-0310-859d-f6bbb57e9c96

* The boot loader now remembers the bytes per row as told by the graphics card, and
passes that information on to the kernel. This should fix wrong bytes per row with
certain resolutions and graphics cards.
* The boot loader now recognizes 15 bit modes that are advertised as 16 bit modes.
This should fix wrong colors in 16 bit modes on some cards.
* Reenabled setting MTRR for VESA mode - don't remember why I disabled it, but it
works fine on my test machines.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23006 a95241bf-73f2-0310-859d-f6bbb57e9c96

The mutex was created too early, before semaphores could be used.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20098 a95241bf-73f2-0310-859d-f6bbb57e9c96

Implemented on screen debug output during boot - to be enabled in the boot loader
safemode menu.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16081 a95241bf-73f2-0310-859d-f6bbb57e9c96

The short story: we now have MTRR support on Intel and AMD CPUs (the latter
has not yet been tested, though - I'll do this after this commit):
* Removed the arch_memory_type stuff from vm_area; since there are only 8 memory
ranges on x86, it's simply overkill. The MTRR code now remembers the area ID
and finds the MTRR that way (it could also iterate over the existing MTRRs).
* Introduced some post_modules() init functions.
* If the other x86 CPUs out there don't differ a lot, MTRR functionality might
be put back into the kernel.
* x86_write_msr() was broken, it wrote the 64 bit number with the 32 bit words
switched - it took me some time (and lots of #GPs) to figure that one out.
* Removed the macro read_ebp() and introduced a function x86_read_ebp()
(it's not really a time critical call).
* Followed the Intel docs on how to change MTRRs (symmetrically on all CPUs
with caches turned off).
* Asking for memory types will automatically change the requested length to
a power of two - note that BeOS seems to behave in the same, although that's
not really very clean.
* fixed MTRRs are ignored for now - we should make sure at least, though,
that they are identical on all CPUs (or turn them off, even though I'd
prefer the BIOS stuff to be uncacheable, which we don't enforce yet, though).



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15528 a95241bf-73f2-0310-859d-f6bbb57e9c96

Some work in progress of the MTRR support. Shouldn't do any harm yet :-)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15525 a95241bf-73f2-0310-859d-f6bbb57e9c96

Make sure only ASCII characters are rendered.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14039 a95241bf-73f2-0310-859d-f6bbb57e9c96

The app_server now updates the kernel's blue screen frame buffer on mode changes
(only the accelerant HW interface does this for now).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12897 a95241bf-73f2-0310-859d-f6bbb57e9c96

Removed debug/console.c, we no longer need it. frame_buffer_console_init() is now
called by debug_init_post_vm().
Since the availability of a blue screen specific getchar() is static anyway, there
is no need for the sBlueScreenGetChar variable (only the message "only serial input
available" gets lost, but since that is platform specific anyway...).
Hello blue screen! We now have an on-screen KDL, to be enabled by the kernel
setting "bluescreen", just like on BeOS.
The blue screen does not yet support any cursor actions or backspace, though (need
to grab some stuff from our console driver).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12896 a95241bf-73f2-0310-859d-f6bbb57e9c96

Renamed system/core to system/kernel.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12360 a95241bf-73f2-0310-859d-f6bbb57e9c96