OSDev.org

I have been coding a new kernel in FreeBASIC. The basic set of commands such as memset(), memsetw(), memcpy() and strlen work within temp_vital.bi and I have a fully functioning GDT in gdt.bi. The project originally started out as the FreeBASIC barebones tutorial but has changed a lot since!

I have become stumped on the IDT/ISR implementation. All source code is available here:
http://code.google.com/p/scorchos/sourc ... es/lantern

I have gone through the code within idt.bi and isr.bi eliminating all syntax errors (I discovered a rogue 'ret' statement in some inline assembly which was causing my test virtual machine to reset constantly for instance!).

Within the ISR I have broken down the ASM source for the ISRs you see in the bkerndev tutorial into FreeBASIC subroutines containing inline assembly followed by a call to a subroutine named 'isr_common_stub()' (containing yet more inline ASM). Could this potentially be the issue? (I am swotting up a bit on my ASM knowledge just in case!). Other than that I can't see what is wrong with the IDT/ISR code - I have an implementation for the structure of a stack frame and both an IDT entry and IDT pointer. The IDT loads successfully into 'lidt'.

The reason I know my IDT implementation doesn't work is because I have tried using: within 'kernel.bas' in the main() function and recieved no response what-so-ever on boot!

If anyone has a few moments spare to take a look at this code I would very much appreciate that. I will post any further developments here to try and eliminate further issues.

ScorchOS wrote:The reason I know my IDT implementation doesn't work is because I have tried using: (...) recieved no response what-so-ever on boot!

If there's anything wrong with the IDT, almost always you get some exception, causing a triple fault. That nothing at all happens may point to some other problems.


JAL

ScorchOS, if you are using bochs, you could post log.
It can help us for debugging.

That's a floating point division (which you generally don't want in a kernel).... With the result being infinity converted back to a integer (which is not what you want at all)

try i \ 0 (integer division) rather than i / 0 (division with rounding)

@kop99: I'm using QEMU as my emulator at the moment (I've never tried Bochs), but if I continue to have problems I will try it out to see if it produces more useful output. Thanks for the tip

@combuster: I tried using your i = i\0. It does indeed work better (if you try i = 1\0 for instance the FreeBASIC compiler refuses to build the kernel on the basis it's a divide by zero). However, this currently just causes the machine to triple-fault and keep resetting rather than invoke an ISR. This suggests that I am causing a div\0 error but that my IDT is not linking to the ISRs properly?

@JAL: That is very true. It seems that now as I'm causing an error the ISR is not being invoked, which suggests a problem with the IDT. I will try experimenting to see if I'm not pointing to the functions correctly or whether there is a fundamental design issue with the IDT itself.

Thank you everyone for your help so far. I'm willing to welcome all ideas at this stage!

ScorchOS, here is your idt pointer structure. idt pointer structure is 6byte.
But in i386 arch, generally it might be 8byte aligned.
Make sure idt_ptr structure is 6byte aligned!

That would make a lot of sense! I've just checked here:
http://www.freebasic.net/index.php/deta ... y=rls&id=9

Apparently the default for FreeBASIC type-field varies between releases, but in the latest release they've elected to have them 4 Byte aligned by default! The solution to this seems to be to make use of 'Field'. For instance:
Unfortunately however the machine still triple-faults and continues to reset I'm also a little concerned, as I'm not even entirely sure if the GDT works (on the basis I haven't defined type-alignments there either!)

If on the other hand type-alignment is now correct there may be a more intrinsic design problem (or my bitwise maths is wrong somewhere!). Thanks for your help kop99. If all else fails I'll try a recode using the knowledge acquired from this thread.

ScorchOS, you are right.
Your gdt_ptr structure is also not aligned.
Alignment problem might cause unpredictable crash.

Field=1 means packed structures, Field=6 will most likely keep 4(!) bytes between size and offset in order to align the struct on a 6-byte boundary

And as far as the documentation goes, said alignment is invalid.

@combuster: Thanks for the tip! I have never used the 'Field' attribute before, hence the school-boy error

@kop99 - I have also byte-aligned the GDT UDTs and unfortunately still no joy

I have been rewriting the GDT (to eliminate that as an issue and to be more consistent with the IDT code). In so doing I have stumbled across a slight conundrum. The FreeBASIC compier does not appear to enjoy my use of bitwise OR:
which produces 'kernel.asm:98 Error: Invalid '[' in mnemonic'

I have uploaded the new GDT code to the SVN source as 'gdt2.bi' (requires a small edit in system.bi to include in the build). I have also taken a look at this wiki article for the correct use of the Or operator.

(I have also tried manually declaring 'OR' as an operator:) (I'm not sure however whether I have used the correct data types)

RESOLVED! The key problem with the idea was my memset() calculation.

The diff output shows that the code which was: should have been: IDTs now worked fine but the ISRs I was linking to was causing QEMU to crash, so I've now drastically simplified the file. There is now an isr_install() routine as before but now there is only one word of inline assembly used in one subroutine: The GDT issue was actually a typo in some inline ASM

The div\0 error now works and I'm now coding up the rest of the ISR. Thanks everyone for your help!

ScorchOS wrote:RESOLVED

Congrats.


JAL