OSDev.org

The same problem still happens, even minus those two last lines.

Sourcecode for the latest Citadel build can be found here:
http://homepages.ihug.co.nz/~scroodle/citadel-src-240506.tar.gz

My IOWAIT is badly implemented.
All im doing is setting a Unsigned integer to 50k and looping it down to zero.
Ill implement a 'real' io_wait soonish.

the Makefile is setup for my crosscompiler (in /usr/cross, i586-elf)
gcc.3.3

However, if you change the GCC lines in the Makefile, to your systems GCC and just include all the 'dont include nonstandard crap' options, you should be able to compile Citadel fine.

Also, I use NASM for the Assembly.

Well,I must be off to University.
Ill leave this PIC problem mulling around in my skull, hopefully me, myself or one of you lovely people will solve the bug.

Just looked and I see a file named 220506 but not 240506. I'm assuming thats what you mean.

Alrighty, my mistake.
I uploaded the source to the wrong directory.
Try again, the source should be there now.

http://homepages.ihug.co.nz/~scroodle/citadel-src-240506.tar.gz

BUSSSS Waiit BUsssSSsss!!!
*runs*

I'm not getting any crashes, just an infinite loop in k_timer_wait, which is broken anyway. The variable you are testing (k_timer_clicks) should be volatile if it will be changed during an interrupt because otherwise the compiler might cache the value in a register and therefore miss any changes.

Even with this corrected I'm just stuck in an infinite loop. A breakpoint immediately following the loop is never reached. I am also getting no output on the screen.

I would suggest attacking the code with some comments, and organizing your source code directory. Once compiled I have 36 files names citidal_*, so it's impossible to dig around and try to find something since the names are almost identical.

My advice would be to use GRUB if possible, organise your code into "include", "src" and "build" (for the object files) dirs, and comment your source files. Only then will you have a chance of anyone finding whatever the bug is.

I am compiling with GCC 3.4.5 for i686 and using my own bochsrc. Thats the only way to get your code to run on my machine as you're using an old compiler, trying to target only i586 and using an older/newer version of bochs (my bochs can't even read your bochsrc.txt).

No video output?
Thats odd.
Do you know what loop it is you are getting stuck in?
And if you are actually entering the Kernel?

The Floppy drive reading code in Assembler has a basic loop, im not sure if it works entirely correctly.

*Downloads own Source code*

Volatile? could it be the volatile settings that I have wrong in different places in code?

I dont use volatile in MANY places.
Like, im almost all of my Inline Assembly, I dont have volatile infront of the actual ASM.

However, the no video output shocks me.
If you can discover the code its getting trapped on, itd be useful.

Also, if you could - Send me your Bochsrc, that way I can see if its a setting you have set.

I use Bochs 2.2.6, GCC 3.3, BinUtils 2.16.
I agree, I should organize my Source tree, into well... a source tree.

Ive been planning on attacking my source with comments, etc all morning.

Im not sure how ill ... work the Makefile thing.

Id want the PORTs and such to be in an IO directory, Video stuff to be in a VIDEO directory, etc.

A makefile being in the root of the Source tree which calls the make of others...
*shrug* Ill figure it out .

Ohhh right, in the Timer?
As far as I know, the PIC is being set correctly, thats why I dont understand why the IRQs arent being called.

But.. the wait loop will go forever... becasue... the timer isnt being incremented, because the IRQ for the PIT Timer isnt being called... because, presumably, the PIC isnt programmed right?

Also, my IO WAIT function isnt properly implemented.

About Volatile, Ill research it.
But, if you could explain a little about, thatd be handy.

I decided to go through, documenting my code (Thanks Paul!)
and I discovered a whole BUNCH of bugs.

For starters, My Memcpy / Memset routines.
pointertoMemory[x] = whatIWantToSetItTo;

WRONGGG...
Needs to be:
*pointerToMemory[x] = ValueToSetItTo..

Lots of little bugs like that.

Also, with my k_inPortb / k_outPortb.
I think I had incorrect GCC Inline Asm.

Before and Afters:

K_OUTPORT BEFORE:
void k_outPortb(unsigned short port, unsigned char data)
   {
      __asm__ ("outb %%al, %%dx" : : "a" (data), "d" (port));
   }


K_OUTPORT AFTER:
void k_outPortb(unsigned short port, unsigned char data)
   {
      __asm__ __volatile__ ("outb %1, %0" : : "dN" (port), "a" (data));
   }



K_INPORT BEFORE:
unsigned char k_inPortb(unsigned short port)
   {
      unsigned char dataGrabbed;
      __asm__ ("inb %%dx, %%al" : "=a" (dataGrabbed) : "d" (port));
      return dataGrabbed;
   }

K_INPORT AFTER:
unsigned char k_inPortb(unsigned short port)
   {
      unsigned char dataGrabbed;
      __asm__ __volatile__ ("inb %1, %0" : "=a" (dataGrabbed) : "dN" (port));
      return dataGrabbed;
   }

So, Hopefully when I DO get to recompile the source, things will work smoother now. (Hopefully the PIC WILL be programmed correctly now that (I hope) the Ports routines are fixed?. Sure hope so. Memcpy / Memset routines will work properly too. Perhaps I should stop coding without sleep. Hmm.

I will make the variable, k_timer_clicks Volatile.

int k_timer_clicks to int k_timer_clicks __attribute__(volatile)?

hmm.

Hi,

paulbarker wrote: Maybe you find this strange, but what works best for me is the exact opposite of what Brendan suggests: I write a dirty implementation in a scratch directory first, then write a proper design and finally re-write the implementation into the main kernel tree.

I think we're talking of different levels (e.g. overall design vs. selecting algorithms, etc).

Booting is possibly a good example - does the bootloader load the kernel (where the kernel contains device drivers, etc to access other files once the bootloader is gone), does the bootloader load a boot image containing all files that the kernel might need, or is there support for a file system built in the bootloader that the kernel can use?

For an example, I've written out the steps taken by my OS during boot for people to read. The message was too long for this message board so I've put it on my project's forum (which is probably a more appropriate place for it anyway), see:

http://bcos.zapto.org/frm/viewtopic.php?p=25#25

If you read it you'll understand why it needs to be designed - it doesn't just happen.


Cheers,

Brendan

Hi,

mystran wrote:

Brendan wrote:My micro-kernel design has IPC, the scheduler, physical memory management, virtual memory management, low level IRQ handlers, I/O port access, ISA DMA chip access, a timer (PIT), exception handling, critical error handling and a system log.

How do you handle virtual memory (specifically swapout and sharing, kernel out-of-memory situations and such) without having a hdd-driver in kernel? Or is that possible in your setup?

I've got about three models so far, I don't quite like any of them... so I'd like to hear what other people do.

First, I don't support shared memory in any way (it's not appropriate for my OS design).

For swap space and memory mapped files, the kernel marks the page as "not present - file I/O in progress" and sends a special request message to the swap or VFS. Then the thread is set to "blocked waiting for VMM file I/O" so that it doesn't get any CPU time.

When the swap or VFS sends back a special reply message the kernel's "sendMessage()" function detects that it's a special message and unblocks any threads that are waiting for it (there might be more than one by this time). The message data (the physical address of the page containing the requested disk data) is stored in each thread's "thread control block" when each thread is unblocked, and the sendmessage() code doesn't put the message on the receiver's message queue like it otherwise would.

It's a bit of an ugly hack (it breaks my "purely asynchronous IPC" model), but that is unavoidable (it's the only type of operation that is unavoidably synchronous).


Cheers,

Brendan

GAAaaAHAHhH!!?!? PIC Remapping STILL isnt working.
I wonder, could it be a problem with my GDT / IDT?

Ive tripple mega ultra checked the Remap code with OSDever PIC code, and the OSFAQ code and other PIC guides online.

... and it always gives me Divide by Zero.
Even though, I have no divide by zeros in my source. (Im not causing the exception myself).

Also, it only happens when I turn on Interrupts.


*sniffle sob*
On the bright side, ive reorganized the source, so now its in a nice Source-tree. *cheers*

Im in the process of commenting the source, so.. that anyone who decides to help me will be able to follow my code .

Any ideas why the Remap code isnt working?
Its virtually identical to what ive posted above.

OMFG?!
I found it.
GOD im an idiot.
Its remapping fine!
I just forgot to set the IRQ Handlers... I set the IRQ handlers... to call the Exception ISRs... GOD IM AN IDIOT.

GAH!!??!...

Moral learnt: get more sleep, so I dont overlook idiodic mistakes like this in future.

*nod grin*

Ive got IRQs working nicely now.
All Interrupts start off as Disabled though.

I added routines, so ... when you assign a Handler (driver?) to whatever Interrupt, itll enable the interrupt.

When you remove the driver, itll disable it.
Just so I dont have to put up with random freezes or halts because there isnt a driver.. or a handler assigned to a interrupt firing.

Time to code some Memory management, and maybe a Disk driver.
Yay!