Older
-
r255
(Revised IOAPIC stuff. Checked HPET stuff. Added Revision n...) committed by wilkie05
- Revised IOAPIC stuff. Checked HPET stuff. Added Revision numbering to makefile (Joe Frambach) and
fixed prettyness of header.
Revised IOAPIC stuff. Checked HPET stuff. Added Revision numbering to makefile (Joe Frambach) and
fixed prettyness of header.
-
-
-
r252
(re:Added IOAPIC debug code (not currently working). Wilkie ...) committed by untwisted
- re:Added IOAPIC debug code (not currently working). Wilkie is gonna double check it.
re:Added IOAPIC debug code (not currently working). Wilkie is gonna double check it.
-
r251
(Added IOAPIC debug code (not currently working). Wilkie is ...) committed by untwisted
- Added IOAPIC debug code (not currently working). Wilkie is gonna double check it.
Added IOAPIC debug code (not currently working). Wilkie is gonna double check it.
-
r250
(Because you asked for it... multiprocessor support! That's ...) committed by wilkie05
- Because you asked for it... multiprocessor support! That's right, now
you can ACTUALLY have 3 CPUs and not have many cases of fail show up at
your door. Reason: each CPU gets its own 16K stack allocated by the now
functional kernel heap allocator.
Soon, I will enable the interrupt mechanisms of the APs and, with that,
the Local APIC of each. But for now, the CPU does not have much
functionality besides using the kernel page table and running in kernel
space. Running... a busy loop of nothing.
More soon.
Because you asked for it... multiprocessor support! That's right, now
you can ACTUALLY have 3 CPUs and not have many cases of fail show up at
your door. Reason: each CPU gets its own 16K stack allocated by the now
functional kernel heap allocator.
Soon, I will enable the interrupt mechanisms of the APs and, with that,
the Local APIC of each. But for now, the CPU does not have much
functionality besides using the kernel page table and running in kernel
space. Running... a busy loop of nothing.
More soon.
-
r249
(Should now run in Xen fairly well.
Now accepts malformed MP...) committed by wilkie05
- Should now run in Xen fairly well.
Now accepts malformed MP tables (where the list is not sorted) because we get one of those tables.
We normally exit, and it works fine, but now it
will read the rest of the table.
Should now run in Xen fairly well.
Now accepts malformed MP tables (where the list is not sorted) because we get one of those tables.
We normally exit, and it works fine, but now it
will read the rest of the table.
-
-
r247
(Fixed simple config bug.
) committed by wilkie05
- Fixed simple config bug.
-
-
-
r244
(Some minor updates) committed by untwisted
- Some minor updates
-
r243
(added a new flag DEBUG_IOAPIC to deal with the output line i...) committed by GreenmanSpirit
- added a new flag DEBUG_IOAPIC to deal with the output line in ioapic.d
added a new flag DEBUG_IOAPIC to deal with the output line in ioapic.d
-
r242
(adding keyboard.d) committed by untwisted
- adding keyboard.d
-
r241
(Fixed race condition in kernel (wilkie), added in better deb...) committed by untwisted
- Fixed race condition in kernel (wilkie), added in better debugging support via config.d
Fixed race condition in kernel (wilkie), added in better debugging support via config.d
-
r240
(Simple change to make more sense.
) committed by wilkie05
- Simple change to make more sense.
Simple change to make more sense.
-
IOAPICWTF
(Information on the IO APIC / HPET stuff being worked on.) Wiki page edited by wilkie05
-
IOAPICWTF
(Information on the IO APIC / HPET stuff being worked on.) Wiki page added by untwisted
-
r237
(Whoops on IOAPIC. I need to map that region, or trust GRUB....) committed by wilkie05
- Whoops on IOAPIC. I need to map that region, or trust GRUB. I do not
trust GRUB and simply mapped the single page I need. BOCHS' IOAPIC is
reporting valid version numbers from the IOAPICVER register.
Whoops on IOAPIC. I need to map that region, or trust GRUB. I do not
trust GRUB and simply mapped the single page I need. BOCHS' IOAPIC is
reporting valid version numbers from the IOAPICVER register.
-
r236
(Some supplementary changes, fixed build :)
) committed by wilkie05
- Some supplementary changes, fixed build :)
Some supplementary changes, fixed build :)
-
r235
(I have fixed some IOAPIC stuff and fixed up some HPET stuff ...) committed by wilkie05
- I have fixed some IOAPIC stuff and fixed up some HPET stuff and started
the HPET implementation on my own building off of Adam's work. I have
to figure out this whole Interrupt thing to test the timers out.
I have fixed some IOAPIC stuff and fixed up some HPET stuff and started
the HPET implementation on my own building off of Adam's work. I have
to figure out this whole Interrupt thing to test the timers out.
-
r234
("I" implemented the IOAPIC crazy shit. Woot.
) committed by melancholyfleur
- "I" implemented the IOAPIC crazy shit. Woot.
"I" implemented the IOAPIC crazy shit. Woot.
-
r233
(Added the code to map BIOS regions and handle some of the re...) committed by wilkie05
- Added the code to map BIOS regions and handle some of the related stuff
in a more elegant fashion. Fixed up HPET to work with these changes.
Added some convention changes to the multiboot code. Changed the name
of vmem_structs.d to regions.d.
Added the code to map BIOS regions and handle some of the related stuff
in a more elegant fashion. Fixed up HPET to work with these changes.
Added some convention changes to the multiboot code. Changed the name
of vmem_structs.d to regions.d.
-
r232
(formatted a if line because apparently really long lines are...) committed by GreenmanSpirit
- formatted a if line because apparently really long lines are out :-P
formatted a if line because apparently really long lines are out :-P
-
r231
(added call to hpet.init to kmain.d
fixed a pointer issue in ...) committed by GreenmanSpirit
- added call to hpet.init to kmain.d
fixed a pointer issue in vga.d
added to the hpet init function
added call to hpet.init to kmain.d
fixed a pointer issue in vga.d
added to the hpet init function
-
r230
(added a cast to the call to printstruct in the printarray fu...) committed by GreenmanSpirit
- added a cast to the call to printstruct in the printarray fuction
added a cast to the call to printstruct in the printarray fuction
-
r229
(Fixed my errors in printStruct. Added Arrays in Struct supp...) committed by wilkie05
- Fixed my errors in printStruct. Added Arrays in Struct support.
Fixed my errors in printStruct. Added Arrays in Struct support.
-
r228
(Added a globals area which will reduce the amount of redunda...) committed by wilkie05
- Added a globals area which will reduce the amount of redundancy in the
kernel. It will grab a value from the linker.
Added a globals area which will reduce the amount of redundancy in the
kernel. It will grab a value from the linker.
-
-
r226
(Small convention change in IDT.
) committed by wilkie05
- Small convention change in IDT.
Small convention change in IDT.
-
r225
(Updated conventions for pMem.
) committed by wilkie05
- Updated conventions for pMem.
Updated conventions for pMem.
-
r224
(Updated conventions for vMem.
) committed by wilkie05
- Updated conventions for vMem.
Updated conventions for vMem.
-
r223
(Added some preliminary IO APIC code.
) committed by wilkie05
- Added some preliminary IO APIC code.
Added some preliminary IO APIC code.
-
-
-
-
-
r218
(I finished up printArray which should benefit debugging. Al...) committed by wilkie05
- I finished up printArray which should benefit debugging. Also, added
mechanisms for the print family of functions to have conditional
locking. This way printStruct and printArray can both call eachother
and themselves recursively and still be guaranteed no interruption in
their execution or a deadlock.
Oddly, I cannot create and initialize a static array:
int stuff[3] = [0,1,2]; // FAIL
int stuff[] = [0,1,2]; // FAIL
int stuff[3];
stuff[0..2] = [0,1,2]; // FAIL
int stuff[3];
stuff[0] = 0;
stuff[1] = 1;
stuff[2] = 2; // SUCCESS
The failures are assertions at an unknown location at runtime. What is
the issue with array initialization and copying?
I finished up printArray which should benefit debugging. Also, added
mechanisms for the print family of functions to have conditional
locking. This way printStruct and printArray can both call eachother
and themselves recursively and still be guaranteed no interruption in
their execution or a deadlock.
Oddly, I cannot create and initialize a static array:
int stuff[3] = [0,1,2]; // FAIL
int stuff[] = [0,1,2]; // FAIL
int stuff[3];
stuff[0..2] = [0,1,2]; // FAIL
int stuff[3];
stuff[0] = 0;
stuff[1] = 1;
stuff[2] = 2; // SUCCESS
The failures are assertions at an unknown location at runtime. What is
the issue with array initialization and copying?
-
TODO
(A current list of stuff that should be done) Wiki page edited by wilkie05
-
r216
(Fixed a bug with the vMem code that won't allow more than 1 ...) committed by wilkie05
- Fixed a bug with the vMem code that won't allow more than 1 GB of
system ram. This was discovered by running the kernel on my own
machine, which even now will restart upon vMem.install(). Will
investigate later.
Fixed a bug with the vMem code that won't allow more than 1 GB of
system ram. This was discovered by running the kernel on my own
machine, which even now will restart upon vMem.install(). Will
investigate later.
-
-
-
-
r212
(vMem and pMem now somewhat namespaced so we can import them ...) committed by wilkie05
- vMem and pMem now somewhat namespaced so we can import them easier.
Also, they are locked, i think. It seems like it could never fail, but
it hasn't been tested. Logically, I'd say it is correct.
vMem and pMem now somewhat namespaced so we can import them easier.
Also, they are locked, i think. It seems like it could never fail, but
it hasn't been tested. Logically, I'd say it is correct.
-
-
r210
(VGA locking... now with more correctness!
) committed by wilkie05
- VGA locking... now with more correctness!
VGA locking... now with more correctness!
-
-
r208
(changed the log so that it resets the colors to the default ...) committed by GreenmanSpirit
- changed the log so that it resets the colors to the default rather than white/blck
this is my attempt at making vga.d mp safe, feel free to look over it and change what may need
changed. Its been a while since I have done locks.
changed the log so that it resets the colors to the default rather than white/blck
this is my attempt at making vga.d mp safe, feel free to look over it and change what may need
changed. Its been a while since I have done locks.
-
r207
(I always forget to add files.
) committed by wilkie05
- I always forget to add files.
I always forget to add files.
-
r206
(Trying to get around compiler bug. Do not need locks.kmutex...) committed by wilkie05
- Trying to get around compiler bug. Do not need locks.kmutex, just
kmutex. Added the vgaMutex lock, but no locks have been implemented.
Trying to get around compiler bug. Do not need locks.kmutex, just
kmutex. Added the vgaMutex lock, but no locks have been implemented.
|
