Menu
▾
▴
trion-kernel-dev
|
From: Daniel R. <cos...@gm...> - 2006-01-07 22:25:08
|
Hello, I know that I've actually promised you a full blown UML documentation but after I had a closer look at umbrello I soon abandoned the idea. While UML certainly is a great tool to describe the architecture of complex programs, using it to document the design of a nucleus seems like overkill to me as the resulting diagrams are - due to the lack of higher-level interdependencies - hardly any more expressive that plain header files. I therefore rather spent the last week building a new code branch which I've now uploaded to the cvs (module: "trion v0.2") as a reference for future releases. The code is of course still very crude but as a basic console and simple paging methodes are already supported I hope that it will be sufficient as a base. Here's a more detailed list of what the kernel can do at the moment: [loader/entry.asm] sets up a basic idt/gdt and enables paging, kernel gets mapped to 3.5GB+ [loader/main.cpp] this is the C++ entrypoint, maps x86 console in and writes a message to the screen [loader/console.cpp] prints messages needed for debugging [hal/mmu.cpp] class provides methodes to map/unmap pages The four folders are defined as follows: [hal] contains classes that allow access to the hardware and handle events (irqs, syscall, exception, ipi). All hal-objects are created dynamically per cpu, that is each cpu has its own instance of the hal. [loader] asm/c++ entrypoint and helper classes like the console that are needed for debugging [multiplexion] multiplexion classes manage the application's access-rights for the kernel resources [object] basic in-kernel memory management that allows the allocation of pages for kernel objects I'll see if I can add some functionality that will be needed for mp systems to the loader in the next few days, after that we can basically start with the implementation of the hal. In case that you have some time left you might have a look at one of the following issues in the mean-time: - add support for autotools - allow << and >> operators to be used in the console class - maybe compile an up-to-date toolchain In case that you want to write one of the hal classes (eg ports) please contact me first, I'll then give you some more information about what the class is meant to be used and what functionality is needed. cheers, cosmo86 |
|
From: Manuel H. <mho...@ph...> - 2006-01-08 13:22:22
|
Hi Daniel, it's great to hear that Trion development continues! I'll have a look at the code in the next days. The concept looks quite clear to me. I think that I can also contribute by adding some mp support since I already implemented that part with my new OS. Regards, Manuel |
|
From: Stephen M. W. <ste...@br...> - 2006-01-10 14:06:43
|
> I'll see if I can add some functionality that will be needed for mp > systems to the loader in the next few days, after that we can basically > start with the implementation of the hal. In case that you have some time > left you might have a look at one of the following issues in the mean-time: > - add support for autotools > - allow << and >> operators to be used in the console class > - maybe compile an up-to-date toolchain I haven'y been able to build an up-to-date toolchain for some time. Granted, I haven't put a lot of effort into it, since the old toolchain is Good Enough For Now. I tried building the code out of the box and failed miserably (toolchain problems). I'll see what I can do about getting a good toolchain up and running then turn my hand to the autoconfigury. I don't know if I'll be able to find the time in the next two weeks 'cos we're in crunch mode at work with a big release coming up, so we'll see. It's good to see movement again. -- Stephen M. Webb ste...@br... |
|
From: Stephen M. W. <ste...@xa...> - 2006-01-11 00:54:31
|
On 10/01/06 08:53, Stephen M. Webb wrote: > > I tried building the code out of the box and failed miserably (toolchain > problems). I'll see what I can do about getting a good toolchain up and > running then turn my hand to the autoconfigury. Okay, I reinstalled the old toolchain and build the code no problem. I wil= l=20 now undertake to convert to autoconf (including automatically generating a= =20 bootable floppy image). =2D- Stephen M. Webb ste...@br... |
|
From: Jeff W. <jw...@ne...> - 2006-01-14 19:56:27
|
Excellent! I'm planning on syncing up the recent cvs repo and getting acquited with the code and documentation again. It's been too long. By the way, does anyone know if sourceforge supports email notification of checkins? Perforce does this, and I miss it with CVS projects... it's nice to see what changes are being made to the code, by who, and when, as they're being made. Cheers, Jeff On Tuesday 10 January 2006 19:54, Stephen M. Webb wrote: > On 10/01/06 08:53, Stephen M. Webb wrote: > > I tried building the code out of the box and failed miserably (toolchain > > problems). I'll see what I can do about getting a good toolchain up and > > running then turn my hand to the autoconfigury. > > Okay, I reinstalled the old toolchain and build the code no problem. I > will now undertake to convert to autoconf (including automatically > generating a bootable floppy image). > > -- > Stephen M. Webb > ste...@br... |
|
From: Daniel R. <cos...@gm...> - 2006-01-14 22:19:24
|
> Manuel wrote: > I think that I can also contribute by adding some mp support since > I already implemented that part with my new OS. With my last update to the cvs I've now begun preparing the framework for the muli-pocessor code: - Entry.asm now contains code that can be relocated to 0x7C00 in order to boot the APs - main() is multi-processor aware and can be used by both BSP and APs - Basic (pysical) heap management allows allocation of memory for the hal-classes of each CPU - virtual memory map is the same for all CPUs: 0xE0000000 - Start of the kernel image + image_size - This CPU's Stack + 4096 bytes - Debugging console + 4096 bytes - Nodestructure of CPU #1 + 4096 bytes - Nodestructure of CPU #2 + 4096 bytes - Nodestructure of CPU #n 0xFFFC0000 - Pagedirectory of this CPU Nodestructure: offset 0x000-0x1FF -> gdt (loaded by entry.asm) offset 0x200-0x3FF -> idt (set-up in main.cpp) offset 0x400 -> Header containing pointers to hal objs offset 0x400++ -> ~3kb free space for the hal objects Apart from the multi-processor initilization routines in main.cpp there are three hal objects that are meant to provide an interface to the functionality of the APIC. Maybe you could have a look at these classes while I'll add some more multi-processor detection and booting code to main(): * irq.hpp The irq class initializes the APIC by mapping all IRQs to a certain range of interrupt numbers (ie: 0x20 - 0x3F). Whenever an IRQ occures the static methode DeliverIRQ() gets called and informs the driver of the device(s) using the just triggered IRQ via an IPC message. * timer.hpp This class allows timers to be set and calls the scheduler on a timer event. I would like to use single-shot only as they allow a much more fine grained scheduling of tasks than periodic timers. As we don't want to lose any time between the deli- very of a timer event and the reinitialization of the internal timer clock, the class supports the NEXT_TIMER to be set in advance. Immediately after CURRENT_TIMER ran off the hardware may thus be reseted. * ipi.hpp To send an ipi the caller first has to aquire the mutex of its own ipi-class aswell as the receiver's mutex. It then copies its message to the arguments fields of the receiving CPU and causes an IPI that will be processed by the receiver's ProcessIPI() methode. Once the receiver has finished it writes a return value to the sender's arguments field which will then in turn release the two mutex. > Stephen M. Webb wrote: > Okay, I reinstalled the old toolchain and build the code no problem. > I will now undertake to convert to autoconf (including automatically > generating a bootable floppy image). Thanks alot, also for fixing the website.. > Jeff Weeks wrote: > By the way, does anyone know if sourceforge supports email notification > ofcheckins? Perforce does this, and I miss it with CVS projects... it's > niceto see what changes are being made to the code, by who, and when, as > they'rebeing made. Sure, just register to the other mailing list: http://sourceforge.net/mail/?group_id=90198 I've, by the way, noticed that the cvs reposity contains a number of empty folders that don't seem to be used any longer: http://cvs.sourceforge.net/viewcvs.py/trion/Desktop/ http://cvs.sourceforge.net/viewcvs.py/trion/include/ http://cvs.sourceforge.net/viewcvs.py/trion/source/ http://cvs.sourceforge.net/viewcvs.py/trion/trion v0.2/cvsroot/ Would anybody here mind me asking the sf-team to remove these ? regards, Daniel |
|
From: Manuel H. <mho...@ph...> - 2006-01-30 06:43:28
|
Hi Daniel, after having a close look at the sources I have some questions and suggestions: - Why does each CPU set up an own GDT, IDT and page tables? The entries in all the GDT's will be identically, so it would be sufficient to use only one. The only advantage I can see from multiple GDT's is by putting task state segments for each CPU in a different GDT - but of course they could also be located in the same GDT. But I can't see the advantage in having multiple IDT's (and also multiple interrupt stubs, calling the same interrupt handler). Finally, multiple page tables allow all CPU's to see the same virtual memory layout while having their data at different locations within physical memory, but I wonder whether this justifies the memory overhead causes by the page tables. - The kernel entry is not (yet) thread safe. As soon as an AP boots up and enters main(), it will clobber some global variables (stack, nodestruct and so on) since they exist only once as part of the kernel. I'll try to add some mp requirements (locks...) and APIC features (timer, IPI) during the next days. Regards, Manuel |
|
From: Daniel R. <cos...@gm...> - 2006-02-01 15:32:07
|
Hello Manuel > Why does each CPU set up an own GDT, IDT and page tables? The entries in > all the GDT's will be identically, so it would be sufficient to use only > one. You have some point here, a single gdt/idt per system should indeed be sufficient.. > But I can't see the advantage in having multiple IDT's (and also multiple > interrupt stubs, calling the same interrupt handler). I've read somewhere that, on uniprocessor machines, it can actually be usefull to create one stub for each interrupt to save the time that it would take to check the PIC registers in order to find out which interrupt was fired. With a multi-processor system this however is of course no problem any more as the local APIC is located on the CPU itself so that its registers can be read-out very fast. I'll thus split CreateIDTEntry() into two procedures (create a new stub, link interrupt with stub) so that either of the two methodes may be used in the future. > Finally, multiple page tables allow all CPU's to see the same virtual > memory layout while having their data at different locations within > physical memory, but I wonder whether this justifies the memory overhead > causes by the page tables. It's actually only a single page-table (4kb) per cpu that is meant to describe the first 4mb of kernel-space. These 4mb would have a different mapping on each node and might therefore be used to store per processor information like, for example, a structure containing pointers to all of the cpu's hal-object: 0xE8000000 - kernel image + image_size - my hal structures + hal_size - cpu 0 hal structures + hal_size - cpu 1 hal structures + hal_size - cpu n hal structures If a systemcall is triggered the cpu may easily get the location of it's hal structures as their address is, due to the different mappings on each cpu, static throughout the whole system. I'm myself however not quite sure it this is really the most convenient way of retrieving this iformation. The two alternatives I could think of are to either store the structure relativ to the cpu's kernel stack-pointer (somewhat hackish) or to use the local APIC's id as some sort of an index (not sure how easy/fast it can be obtained). Any opinions about this ? > The kernel entry is not (yet) thread safe. As soon as an AP boots up and > enters main(), it will clobber some global variables (stack, nodestruct > and > so on) since they exist only once as part of the kernel. As the processor number is passed to the C entrypoint this could probably be avoided quite easily. You're however right that the framework as a whole isn't all that elaborated yet and I'll see if I can have a look at it this week-end. > I'll try to add some mp requirements (locks...) and APIC features (timer, > IPI) during the next days. Excellent.. regards, cosmo86 |
|
From: Stephen M. W. <ste...@br...> - 2006-02-01 16:15:46
|
On 01/02/06 10:31, Daniel Raffler wrote: > > I've read somewhere that, on uniprocessor machines, it can actually be > usefull > to create one stub for each interrupt to save the time that it would take > to > check the PIC registers in order to find out which interrupt was fired. > With a > multi-processor system this however is of course no problem any more as > the local > APIC is located on the CPU itself so that its registers can be read-out > very fast. Modern Intel CPUs (P III and later) all have their APIC on the same die as the CPU itself. The PIC is actually emulated by the IOAPIC. Anything manufactured this century and built on the Intel ia86 architecture has an IOAPIC, regardless of the number of CPUs. How much to we want to support ancient legacy hardware? -- Stephen M. Webb ste...@br... |
Thanks for helping keep SourceForge clean.
X