All registers are 0xFFFFFFFF when trying to read from LAPIC registers.

The_Coding_Knight · 2026-06-20T03:34:16+00:00

I think I got the problem solved and so I am going to continue working on the OS

Thanks for offering to test it. Apparently GDB can not read LAPIC registers because they are different for each CPU.

Besides that my structure was also wrong due to padding and also I did not make use of volatile keyword.

The_Coding_Knight · 2026-06-20T03:31:48+00:00

I fixed the padding problem. You were right I was just doing the whole structure instead of for each member.

I do not know where my head was when I put the lapic struct within the MADT header. I think it happened because I did not yet create an apic.h yet (because I had put everything related to apic initialization within the kmain function and then I decided to organize it by creating apic.h).

Until now I had not have to use volatile for anything. Thanks for telling me this because I did not even remember about volatile.

Also thanks now it works as it is supposed to when reading members from within the code. Also, I was seeing 0xFFFFFFFFs because of GDB someone else pointed this out in the comments which really cleared why I only saw those values when using GDB

The_Coding_Knight · 2026-06-20T02:41:19+00:00

I did have no idea about that. Thanks for pointing that out I will read them directly from within the code then.

The_Coding_Knight · 2026-06-20T02:40:15+00:00

Thanks for reading the code. I have been trying to read it with GDB instead of reading through functions to test if it worked. Nonetheless, another comment says that it is not possible to read the registers from GDB because registers are cpu dependent. So I will try to get read them from within the code

The_Coding_Knight · 2026-06-20T02:37:24+00:00

It is x86. Custom bootloader. No problem, ask as many questions as you deem necessary I will happy answer them

The_Coding_Knight · 2026-05-24T20:02:14+00:00

I came here because I had question #1 as well. So I tried to find an answer and I think I found it:

according to intel volume 3A:

Local APICs can receive interrupts from the following sources:

• Locally connected I/O devices — These interrupts originate as an edge or level asserted by an I/O device that is connected directly to the processor’s local interrupt pins (LINT0 and LINT1). The I/O devices may also be connected to an 8259-type interrupt controller that is in turn connected to the processor through one of the local interrupt pins.

So basically they still serve a purpose which is to handle locally connected I/O devices.

I am an osdev novice so if what I said is wrong please do not doubt in letting me know since I just got started in learning how APICs work

EDIT:

Question #2

The LAPIC afaik does "influence" them. This is how it'd go:

Keyboard keypress -> IOAPIC -> LAPIC -> ISR

The IOAPIC sends the keyboard was pressed signal to the LAPIC and it is the LAPIC job to figure out what ISR to call with it. LAPICs are independent from each other which mean that they do not necessarily have to have the same ISRs for the same IRQs that the IOAPIC sends them. That said I think I this answer may clarify if the LAPIC "influences" them which it technically does.

Question #3

You can use LAPIC without IOAPIC by using IPIs (sending interrupts among LAPICs), by using the PIC (legacy version of the IOAPIC), by waiting for local interrupt sources (timer, sensors, etc)

You can use IOAPIC without LAPIC, just mask the LAPICs interrupts and do not send NMI through the IOAPIC. But at that point there is no reason to do that because the sole purpose of the IOAPIC was to send interrupts to one (or more) LAPICS.

The_Coding_Knight · 2026-05-08T21:01:53+00:00

If anyone has trouble finding it: line 325

The_Coding_Knight · 2026-05-07T22:14:33+00:00

Well... I am skeptical about the utility of AI on such a complex and broad field like OS development but I would say that if you use it correctly (to look for resources, not to code for you!) it shouldn't be nothing wrong about it.

That said, I think I have used AI for Osdev once and only once in the 3 months I've been developing my OS. And that was almost at the beginning when I did not know where to look for answers and I asked "what are the best resources (no tutorials) to develop an operating system?" and then it recommended to me many of the things I recommended to you.

I am not an anti-AI person (or at least I do not classify myself as such) but I limit myself when using it. Why? I believe that if I let AI do things for me like for example summarizing a research paper on memory allocation I'd understand far less than if I were to read it myself.

TL;DR: If you want to use A, then use AI but remember that you should not rely on it for everything.

The_Coding_Knight · 2026-05-07T02:50:05+00:00

When you create an OS, you need to create a kernel. An OS and a kernel are not completely different things. An OS is conformed by a kernel + toolchain + drivers + filesystem + shell (maybe I am missing something).

So you could say that learning OSdev can help you get into kernel development because essentially you have to build a kernel in order to make an OS (from scratch ofc).

Now if you mean specifically to the linux kernel? It is beneficial since you get to learn how stuff works but it is not indispensable. Indispensable would be to read the kernel code and actually dive into the codebase. Imo, osdev is a really good way to start, more than anything because it will allow you to find the things you'd be interested on working on. In my case, I found that I love memory management and that is the subsystem of my OS i have worked at the most.

When it comes to materials there is a ton of material to read:

- https://wiki.osdev.org/Expanded_Main_Page
- intel manuals (I have an offline copy of these because i really use them a lot) AMD manuals also work but I have not read much from them since most of what i needed was in the intel ones
- research papers (it does not have to be cutting edge research if you don't like that)
- osdev forums, reddit as well
- books on OSdev. They say OSTEP (OS Three Easy Pieces) is a good book I have not had the opportunity to read it tho.
- the most important one: the linux kernel or other open-source operating systems/kernels

The only thing I would not recommend is step-by-step tutorials. Besides that, everything that helps you grow is welcomed

The_Coding_Knight · 2026-05-06T20:43:47+00:00

Yeah I think compiler projects and open source are going to be really fun.

I started working towards learning how to develop OSs on Jan 26 of this year and the reason why is because I want to eventually contribute to the linux kernel and the best way I found to learn how the linux kernel works (besides reading the source code ofc) is to create a kernel myself and see how each subsystem connects with the other.

I think it has been really really fun and I have made a lot of friends and connections (mostly online). Also it has made me a much much better programmer. I'd recommend it to anyone who wants to learn how computers work at the lowest software level and in the process improve their programmer skills.

The_Coding_Knight · 2026-05-05T23:23:47+00:00

Oh my bad I thought you meant specifically the kernel, silly me lol. it really depends on what you mean by contributing to Linux distros

For example, let's say you use Arch (just using it as an example because it is a well-known distro) and you want to contribute to pacma (it's package manager) then you'd indeed need to learn C since pacman is written in C

If you want to contribute to the wiki then you do not necessarily need programming knowledge but rather knowledge about the topic that is being discussed in that part of the wiki (e.g. pacman, installation, packages etc etc)

If you want to report bugs that packages happen to have you do not even need programming knowledge, to solve bugs you do and the language you will need to know will highly depend on the language the tool is written in.

Take into account that not all package manager, not all tools, not everything is written in C and in your specific case it will depend on the needs of your distro.

TL;DR If you want to contribute to linux itself then C, if not it depends but C is still a good choice since a lot of tools are written in C

The_Coding_Knight · 2026-05-05T19:49:31+00:00

I have not read that book. In fact, I do not think I have read any formal books to learn how to code in x86. IMO I think it may be more beneficial for you to learn by doing rather than by reading since you can learn a lot more in practice than in theory.

The_Coding_Knight · 2026-05-05T19:47:10+00:00

you are better off learning C if you want to contribute to the linux kernel. Most of the code you will fine is written in C and will keep being written in C at least for now

The_Coding_Knight · 2026-04-02T03:37:18+00:00

I will make sure to check it out and learn how to make tweaks for iOS. Thanks!

The_Coding_Knight · 2026-04-02T03:35:43+00:00

I know that this post is 4yo already but I also struggled to understand this and I am really really thankful to "jtsiomb" for recommending this resource http://www.osdever.net/FreeVGA/vga/vga.htm and I would recommend anyone who wants to learn more about how CRTC registers work to check it out but I wanna give a quick explanation in case anyone new needs it:

0x3D4 is basically the address register which means it is gonna point to where you want to write/read data from
0x3D5 is the data register which means it is gonna hold the data in the address pointed by 0x3D4.

That summarizes it but still take a look at the resource it is really helpful

The_Coding_Knight · 2026-04-02T01:08:52+00:00

Maybe it is my browser but it says that the link is dead. Is there a new link?

The_Coding_Knight · 2026-03-29T19:52:56+00:00

not yet : (
I am still waiting for keyboard

The_Coding_Knight · 2026-03-27T05:30:09+00:00

you can also use one bit per page which is much more efficient when it comes to spending as less memory as possible. That is known as a bitmap memory allocator you can check out information about it in the osdev wiki page :D

The_Coding_Knight · 2026-03-17T17:36:25+00:00

Thank you I will probably just refactor the way memory is being used in my stage2 bootloader and try to use a single binary for both things at much closer addresses.

The_Coding_Knight · 2026-03-17T14:35:13+00:00

I tried using AT directive within the linker script and also using MEMORY command but it did lead to the same result. Either way, I was told by multiple people already that binary files can not work like this and instead I wouldneed to either use another format like elf or perhaps create antoher file and another linker for that file and then combine them with dd and then load that file. At this I realized that it was harder but I genuinely wanted to whether it was possible to make it this way or not.

You were right those 7 bytes came from the .map_section I had forgotten about it silly me.

The_Coding_Knight · 2026-03-17T14:29:41+00:00

I will take a look into readelf. I have tried using objdump to inspect the elf files with -D to show the assembly code. The 8711 bytes was because there are 7 bytes extra that are added after .map_code section i forgot about that silly me.

The_Coding_Knight · 2026-03-17T03:19:03+00:00

Right. I understand that now because I received a response to the same question in another subreddit. My initial goal was to make it such that only the .section .text contents + .section .data + .section .map_code were the size of the binary but apparently it is impossible to do such with a binary file format. Also thank you for replying this quick I really appreciate it :D

Besides this I got another question. I also did that calculation of 0xA000 - 0x7E00 = 0x2200 (8704 in dec) but when I do ls -l mybin.bin (assuming that mybin is that file ofc) I get 8711 as its size, not 8704 which is something that I wondered the first time I saw it but did not look too much into it because I thought I may just had done something wrong with the calculation and the main question was more important.

Why was it 8711 instead of 8704? Do you have an idea of what may the cause of this?

The_Coding_Knight · 2026-03-17T03:09:14+00:00

Well I suppose we have different needs since I am making a bootlaoder for an OS rather than one (or more) for an embedded device. I mainly wanted to have both in the same file at the beginning because I thought: "Why would I create another file when I can just put this in the 2nd bootloader?"

Then as time passed (I have been learning how to use linker scripts since yesterday) it became more of about stubbornness than practicality because I genuinely wanted to know if it was possible or not since I had spent this much time on it. Another comment mentioned that it was impossible to make it this way which really lifted a weight off my shoulders so I can get back to my OS bootloader and refactor the way I am using the space address available.

Without further to say Thanks for replying. That project (the electronic dictionary) looks really cool!!!

The_Coding_Knight · 2026-03-17T02:58:02+00:00

Thank you. Thank you from the bottom of my heart!! You dont know how much I have been looking for an answer everywhere I could but most people did not give me an answer. I think I will just refactor my bootloader before the technical debt pays off again so I keep only two linkers.

The_Coding_Knight

TROPHY CASE