DOUBLE FAULT EXCEPTION HANDLING

this is a very cool feature of the cpu.
imagine you accidentally overflow your stack. what now?
well, a page fault exception is likely to occur!
but what if you do not have a page fault exception handler yet?
the answer: the double fault. its kind of a catch all statement that catches all exceptions that their handler is not present. or there was an error while handlinfg a certain exception.
so back to out stack overflow example, if our stack is full now and a double fault was triggered, how will we to to the handler function if we do not have a stack to push the data into? (return addr register data etc..)
we need to preform what is called a stack switch, we switch the stack to a predifeind valid one before each time we enter a double fault handler!

the new stack addr is stored in a data structure called the ist inside the tss inside the gdt (a lot of acronyms lol)
im not gonna explain these data structures but just know they contain crucial data for the operating system proper operation
and (bonus fact) in x86 times (32 bit) the gdt was the primary source of memory security and memory management (now all of that is passed to the paging mechanism)

the image shown here is an example of a propper kernel panic after a double fault! if i didnt handle it properlly the cpu would trigger a triple fault which most cpus just treat by rebooting the machine

WORKING ON CPU EXCEPTIONS/ INTERRUPTS

ive set up the idt with the x84_64 crate that handles stack alignment/ register saving and some more inconvieniences
and ive successfully binded a handler function to the breakpoint interrupt

ADDED VGA OUTPUT

i created a virtual buffer thats mapped to the vga buffer to write ascii to and created print! println! and dbg! macros

TESTING SETUP

i have setup a bare bones testing environment with a custom print_serial! function that (only in testing) prints output from the kernel straight to my console

Changelog

• added debug macro
• added unit testing support + printing to console
• global var use
• added print! and println! macro
• Initial commit

OPTIMIZATIONS

added some optimiztions
regarding the delay to keep up with hardware frequency

and demo’ed the project
link to demo

TO BE CONTINUED!!

i am currently working with my friend to create a userspace library to interact with the oled display (draw in specific pixels, draw circles or maybe even a raycasting/raymarching renderer)

DEBUGGING, FIXING, AND MORE DEBUGGING!

after a long dubbiging session and a frustrating clash with the rust pr_info!() function (that will fucking corrupt your memory if you dont put a \n at the end)
i got the screen to work!
and by working i DO NOT mean only lighting up and showing random pixles- i mean i can write to the oleds misc device file and it will display it on the oled!
this is a demo vid of the display

so basically the driver is done but there are some optimizations to be done so next devlog will prb be the last before shipping

AHHHHHHH THE SCREEN IS ONNNN

the module has succesfully loaded to kernel and opened a misc device under /dev, now it has also sent the init sequence to turn on the screen!!!!!
(the screen shows random data because nothing has been written to it yet)

also i forgot to mention in the last devlog:

i implemented the write function that hooks write syscalls to the misc device and sends the data to my i2c handler to be written onto the screen (not tested yet but fully implemented)

kind of a stupid minor devlog

BUT I GOT THE MISC DEVICE UP AND RUNNING RAAAHHHH

GATEWAY TO USERLAND IS WIDE OPEN

INIT FUNCTION

so i finished writing the init function- most of the time spent since the last devlog wasnt on the function itself rather researching my oled display and its requirements
also i had to research how a communication sequence looks like for this specific oled, the communication itself happens over i2c but the specific detaild about how and when to send data differs from display to display,

Changelog

• converted userspace buffer to kernel memory on write callback & other small fixes
• Add GNU General Public License v3
• Update README.md
• Update README with project details
• Add initial project description to README
• initial commit

PROJECT UPDATE!

since the last devlog i had implemented the basic i2c interactions:

• i2c start
• i2c stop
• write byte
  this paper was really helpful
  i have also set up a device file to let userspace processes interact with my driver.
  basically the driver “hooks” all write calls to that specific file in the /dev folder and passes the buffer to my driver (i also need to copy the buffer to kernel memeory) and then it writes to the screen.

the image below is the first basic 8 byte transfer that happnens when initialising an i2c connection.

FIRST GPIO INTERACTION

so, most of the progress i did was out-of-editor so time isnt really logged accuratly BUT:
i finally loaded my first kernel module that interacts successfully with the physical gpios

gpio 2 and 3 are on my default and i wrote a module to turn 2 off.
so gpio interaction is set up and ready to develop

also:

when using the rpipins tool (the one used in the image above) for mapping out all the gpio pins, i came across a bug that causes the app to crash so i lowkey fixed it and opened a pull request to merge my fix.

FINISHED DEVELOPMENT ENV SETUP!!

ok, so i had to do a lot of stuff before starting to work on the driver itself!

• i had to recompile the raspberry pi linux kernel because it did not have rust support (i develop the driver in rust)
• i also had to config my ide to recognise the kernel crate (which is not by default in crates.io) so i had to clone the tree locally
• created a script to automate deployment (compilation - > copy module with scp to raspi-> ssh to raspi->remove previous module ->load new module)

loaded my first kernel module!!

the image attached is the kernel logs!!!
(ofc the output was through an ssh connection to the raspi)

FAAAAAHHHH

it is currently 5 am.
i spent 2 hours debugging this single fibbonacci program.
because im developing arm64 support for my compiler and my processor is x86_64- i have to use an emulator

the process of debugging through an emulator is pure toture

• i have to run the emulator with a flag to make the program pause at start and be ready for gdb to attach at a specific port
• then i need to run a cross debugger and set the architecture to arm64
• then i need to connect to said port to start debugging the executable
  the problem was this :
  

in my arm64 asm generator i accidentally swapped the w0 and w1 registers
w0 -is the right side of the expression
w1- is the left side of the expression
which i documented for myself at the head of this function:

so i was acc checking if w0<w1 (right<left)
instead of w1<w0 (left<right)
when checking “lower than” expression
(bug was also present in higher than expressions)

then it finally worked:

some other changes i made

fixed some other bugs i caught on static analysis relating to function prologues and epilogues

working on AArch64 support

• finished arm64 code generation
• currently testing it

ALSO: i had to learn arm for this, so its been a bit of time since the last devlog!

arm asm is way more annoying than the “regular” x86 architecture, all instructions are limited to 32 bits and with it comes challenges mainly revolving around immidiate value loading and other stuff like literal addresses

but! arm also has some pretty neat features like three operand instructions, meaning i can take 2 registers add them together and put the calculated value in another register- all in one instruction
this saved me a bit of lines of code but not that significant

some patches

• removed annoying stderr message each time the compiler enters sync mode

FINAL DEVLOG(BEFORE SHIPPING)

shoc- now available on npm!!!
full documentation is available on the github repo in the link below, documentation contains guide on how you can install the compiler , how to use it & how to write in the language

what did i do since the last devlog?

i just finished testing and and fixing bugs in the assembly part and in the program itself
also added shabatchk function to the compiled asm- it checks if its sabbath today and if it is it will not run (no work is permitted on sabbath)
i also have a repo in my github account that contains the notepad++ config for the user defined language - it provides syntax highlighting for shoresh and a nice development env

planning do add:

i will add support for arm64 linux native asm a
and i will prb add arrays sometime soon

github repo

CODE GENERATION & I\O &BUG FIXES

fixed some bugs in semantic validation(concerning stack alignment in x64 architecture asm)

implemented some of the code generation(to x86_64 GAS intel syntax asm) functions (not all of them)
with the most important one being the AstExpression and made a recursive algorithm to traverse the AST tree and convert it to asm code
the algorithm itself isnt the most efficent because it uses the stack to store intermediate values during calculation and i will prb implement a register map to use the registers instead of the stack (until they are all in use ofc)

i also added io functions to let you input a number to a variable, a function that lets you print an expression and a function that lets you print a string

printing and input is handled by libc

ADDED UNARY EXPRESSIONS AND FIXED SOME BUGS

i added the possibility to use unary expressions like -,! inside my expression parser
the image shown is a debugging functions output that prints out the structred nodes that define the program
the highlighted part is the not operator (לא in hebrew) being parsed correctry
the expression is printed in prefix notation or how some may call it - “polish notation”
i also fixed a bug in the typeCheker that caused the type checker to not check the validity of the expressions it passes to the function