Commit Graph

9 Commits

Author SHA1 Message Date
Kevin Lange
193158079d Bunch of kernel cleanup 2012-11-30 18:26:47 -08:00
Kevin Lange
742a6e7448 Fix up style in system.c, fix some bugs, too 2012-10-03 22:01:45 -07:00
Kevin Lange
bba242dd62 Add a testing framework.
This is an automated system by which we boot qemu headless and use the
serial line to capture output from a testing application that is started
on bootup, running with the VGA terminal shell. This might be expanded
to boot to the graphical display within VNC and perform more advanced
tests with the Python shim using a VNC module for Python; we'll see.
2012-09-02 02:24:25 -07:00
Kevin Lange
f68ca25622 Boot-to-shell through kernel argument 'single' 2012-03-27 21:47:25 -05:00
Kevin Lange
89d9265c73 Actually deschedule processes when they are waiting 2012-01-31 19:27:38 -06:00
Kevin Lange
6b2ee875d4 Interrupts on/off is a semaphore 2012-01-10 19:54:05 -06:00
Kevin Lange
edebb12573 [misc] Boot logging to screen 2011-12-26 19:23:58 -06:00
Kevin Lange
c0f45e0b7f VESA mode switching support.
BIOS execution is provided through the `v8086` module, which provides
software emulation of an 8086 processor. It is not currently working
with some BIOSes and may (read: probably will be) replaced with another
emulator (x86emu comes to mind) at some point in the near future. In the
meantime, the default video mode for QEMU works with this and it's
enough to get us on real VESA instead of fake VBE. The `bochs` module
will be renamed in a future commit. Userspace programs have been
adjusted to work at bitrates other than 32 *POORLY*. If you write pixels
left-to-right, they should work fine. They only work with 24-bpp
otherwise, and then you need to be careful of what pixels you are
writing when, or you will overwrite things in other pixels.

You may pass a commandline argument like the following to set display
modes:

  vid=vesa,1024,768

Or for stranger modes under QEMU or Bochs, use the bochs VBE
initializer:

  vid=bochs,1280,720

Note that the address of the linear framebuffer is still found via
hackish probing instead of PCI or trusting the VBE information, so if
you have things in the wrong memory ranges (0xE0000000+), be prepared to
have them get read.

Once again, this entire commit is a massive hack. I am happy that it
worked, and I will continue to make it less hacky, but in the meantime,
this is what we've got.

Happy holidays.
2011-12-25 00:40:40 -06:00
Kevin Lange
8c548c0db0 Restructure directory tree for kernel modules 2011-12-14 22:15:47 -06:00