Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
“Debugging is actually all about finding the bug. About understanding why the bug was there to begin with. About knowing that it’s existence was no accident.”
Mr.robot1 -
Found this little gem in the AMD64 reference manual:
"When PCIDs are enabled the system software can store 12-bit PCIDs in CR3 for different address spaces. Subsequently, when system software switches address spaces (**by writing the page table base pointer in CR3[62:12]**), the processor **may use TLB mappings previously stored for that address space and PCID**".
later:
"Updates to the CR3 register cause the entire TLB to be invalidated except for global pages."
So let me get this straight: PCIDs allow you to reuse TLB entries (instead of flushing the entire TLB) when writing a new address space to CR3 but writing to CR3 always flushes the entire TLB anyways
Just why 🤦♂️7 -
!rant
I'm developing an OS. I tried running it on the laptop that's on the ground. Everything works fine except text mode. There is no output when running it in text mode(not the high resolution one shown on image). Since the OS sends all data that is printed to the first serial port I might as well read the output from the serial ports. Since the laptop I use for development doesn't have any serial ports I had to use the older Windows 98 PC. For unknown reasons I could not get any output from the serial ports so I gave up.
tl;dr I wasted some time trying to debug my OS.
Image of my debugging setup(taken with the latest potato).
13 -
Yesterday my cousin called me to fix his scanner, he said that it didn't work anymore. When i went to his house to check it out, the scanner worked properly! In the 99% of cases, the problem is between the device and the chair2
-
Just wasted 2 hours of my life because turns out the C calling convention is really not standardized and depends on the target platform
Wouldn't advise doing cross boundry efiabi->sysv64 calls 🤦♂️5 -
When some random Assembly code I got off the OSDev Wiki actually booted on real hardware. This is where I'm meant to be.1
-
I started dealing with the problems of life as I do with the programming ones: i divide the problems into subproblems
-
I've been laughed at a lot for thinking this way, but I'm honestly frustrated by how little information exists on the web for people who want to take Operating System development a step further. I mean, the OSDev Community is amazing and offers pretty, much everything one needs to know at the system level. But my issue is: What if someone didn't want to use existing compilers and assemblers like GCC and NASM, and do everything from total scratch? I mean, the original Unix came from somewhere, right? I know you're going to think "Why not? It works.". Well, I just think it's crazy how few people (such as Linus and the GNU foundation) are out there that have the ability to create such things without help from existing software tools. Sure, it could take me decades of careful practice and experience, but my passion is for creating software at this level and becoming one of those people is very strong. I just wish I knew where to begin and who to learn from.4
-
Today i was trying to solve a problem on my graphs algorithm (find the shortest path) but i was not able to do almost anything, so i asked for help to a friend.
He started to try to help me, but after a long reasoning we both stopped to understand what we were doing.
After a while, i've decided to run the code totally random and... it worked! And that's not all, it worked better than we were trying to do!
What a lucky shot😎
(Sorry if there are some errors, english isn't my first language)3 -
Avoid ACPICA if at all possible. It's one garbage tier cluster fuck of bad design, horrible documentation and downright misleading and wrong code
It's meant to consist of an ASL compiler, disassembler, debugger, dumper, various user space utitilies and a kernel resident OSPM implementation *if* you can figure out what belongs to what. Even just compiling this pile of trash is a mystery in itself. Think you need the source files in source/common? EEEEH, wrong. Well, at least partially since most of them seem to be for the user space stuff..? Other ones *are* needed on the other hand. At least the disassembler and/or debugger and/or dumper components seem to reference them. Not that I could figure out how to compile those anyways. The real path to your goal seems to be to ignore a seemingly arbitrary subset of source and header files until your linker stops complaining
There's also a bunch of configuration defines, some of which *you* define, some defined *for* you, based on again others. Of course most of them do stupid shit. Enabling the debugger automatically enables debug logging. Enabling the disassembler force enables debug allocation tracking... What?
The code itself isn't of much help either. Looking in "os_specific/service_layers" you find what looks to be reference implementations of acpica functions in certain os' like windows and unix. Of course I had a look because AcpiOsReadMemory is supposed to read physical memory and I don't know how I would even implement that. But hey, osunixxf.c (xf for interface... of course) should tell me. I'll let you see for yourself in the attached image. Apparently it does fuck all and just returns AE_OK. No error, no logging, no nothing. Just ok. As you can imagine, AcpiOsWriteMemory doesn't do much more either.
...okay so maybe physical memory accesses aren't actually used and these functions are some sort of relic from past times? Nope! They are absolutely necessary for doing low level device interaction. WTF. So finally I went to the linux source and checked how *they* implemented them, and just as I thought, these functions are anything but no-ops...
...So for what fucking reason do these stupid interface implementations even exist but to purposefully mislead you?? They aren't used for fucking anything! As far as I know Windows doesn't even *use* ACPICA and Linux have their own fork with working implementations... They just sit there, just to tell you how to NOT do it
So that's some of my thoughts about ACPICA. Note that I haven't even used it as a library yet, I just got it to compile and link and it already fucked with me this much.
There's also so much more I didn't mention like that you *have* to modify the acpica source in order to get your own platform header working (else #error) eventhough the docs explicitely instruct you not too but you get the point
Don't use ACPICA if you don't have to. Save your sanity for something that's worth it
-
I just bought a laptop (without OS, so i can put on linux without buying a useless windows license) on Amazon and now i can't wait for that2
-
There are two kinds of people:
-Who thinks that to make a tree you need the seed
-Who thinks that to make a tree you need Huffman1 -
Well, first off I want to actually pass my college classes. You know, the classes I barely find interest in that seem to be very minimal in my coding skills.
Next, take up or join a project for the summer. You know, get my name out there.
Third, make money
Fourth, make something significant in the OSdev community. I absolutely love low-level dev. Now (to myself) Let's do this! -
Just Sharing !!?!?
One of my friend was working in Android and he used to tell me at that time Cross Platform wouldn't work as native languages are the best.
Now he is working on flutter and he tell me React Native/ Ionic wouldn't work as in next year flutter will be on the top !!?!3 -
Just started to learn to properly use a linker and honestly...
linker scripts really aren't that great 😐3 -
Get ready to launch a feature. Just about to make a pull request. Business be like, oh wait. Something came up, we need to wait a week. Fuuuuuuuuuuuck.
-
Ok... Able to pry myself away from fallout 76 and fire up for some programming...
Van't decide whether I want to build my game engines debug and root dev tools how I thought, thinking of building the engine to almost behave like a VM but not quite, it still is compiled just like a normal game but has a built in developer terminal that actually acts like an extra operating system/BIOS that can be left to boot the games assets and everything like you would have for an end user or the startup can be interupted to initialise the terminal prior to everything being loaded...
Following the osdev Wiki tutorials to actually build the dev terminal itself but just unsure whether or not to impliment this system the way I think or not... Opinions?1 -
VESA is driving me crazy.
I'm trying to set my video mode via VESA functions which works, the QEMU window size changes, ton of more space.
Problem now however is that I have no idea where in the name of god the goddamn framebuffer starts.
Apparently it's address is located withing the mode info block which I have successfully queried and stored in ES:DI.
Problem now is getting this info block into my 32-bit kernel.
I tried smacking it on the stack which only produces hot garbage.
Essentially it goes like this
[...make sure pointer to block is stored within ES:DI...]
mov ebx, [ES:DI]
[Switch to 32 bit mode, ebx is not erased by doing so]
;Set up stack
mov ebp, 0x90000
mov esp, ebp
call kernel_main
jmp $
kernel_main takes this pointer as an argument, hence why I've pushed it onto stack:
main(uint32_t *ptr);
When I try accessing it however by doing the following:
vbe_mode_info_block* info_block = (vbe_mode_info_block)ptr;
And then try accessing the in the member 'framebuffer' using 'info_block->framebuffer' it's giving me hot garbage.
I'm probably doing something obvious wrong.
Frustrating.
I'm gonna try passing ES and DI seperately and converting them to a real mode address by doing addr = (ES*0x10)+DI;
MAYBE MAYBE MAYBE2 -
I literally don't understand the purpose of a "higher half kernel"
What does it matter where my kernel is mapped in virtual memory?
"It is traditional and generally good to have your kernel mapped in every user process" what the hell does that even mean??
Mapping my kernel into userspace is something is explicitely don't want to do. Like at all. Ever
And in physical memory it matters even less where it is.
I'm so confused right now3 -
Helped SO's parents with web dev I'm a bid to get to know them better. Figure the rest. Don't help family. Atleast not for free. Rather, just don't, unless you're okay with multiple change requests.
-
Writing the general memory allocator for my hobby os. It's kludgy, but it works.
I add a single for-loop that executes well after that.
The frame allocator can't initialize.
fml
Top Tags
Weekly Rant
View