Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mallocation #30

Open
Sploder12 opened this issue Apr 21, 2023 · 3 comments
Open

Mallocation #30

Sploder12 opened this issue Apr 21, 2023 · 3 comments
Assignees

Comments

@Sploder12
Copy link
Member

Memory management!

Querying the BIOS to know what memory is available must be done to know what memory we have.
Once that is done, an allocator can be made using the free regions.

This will be difficult, and despite sharing the same concept of CSE220's malloc project,
it will be nothing like that project.

The OS should do all the bookkeeping itself (also unlike CSE 220's malloc).
It is recommended that allocation occurs in 4KiB blocks (pages).

@emilkovacev emilkovacev self-assigned this Apr 21, 2023
@emilkovacev emilkovacev mentioned this issue Sep 9, 2023
6 tasks
@emilkovacev
Copy link
Member

Ok, so I'm a bit stumped - I've been stuck on this issue for a while, in particular trying to get the 0x15 eax=0xe820 bios interrupt to work. I am executing the bios call right before the bootloader, in an attempt to detect upper segments of memory that are useable. It seems that in the following snippet of code (most of which is referenced from osdev.org):

Here's my fork

[bits 16]
detect_mem:
	mov di, 0x8004
	xor ebx, ebx
	xor bp, bp
	mov edx, 0x534D4150
	mov eax, 0xe820
	mov [es:di + 20], dword 1 ; force a valid ACPI 3.X entry
	mov ecx, 24 ; ask for 24 bytes
	int 0x15

The line with mov edx, 0x534D4150 seems to be crashing, before the instruction is even made (or if it is made at all). My guess is either that it's overriding a register either from the 0x13 interrupt or for something down the line that isn't reset. Are there any calls that depend on a specific value for edx that I can set it back to later?

This is my first exposure to writing code in a bootloader, so I'm really enjoying this :)

@Sploder12
Copy link
Member Author

Sploder12 commented Sep 30, 2023

On my machine the crash appears to come from executing garbage memory (It jumps to 0x1000 [_start] and proceeds to NOP slide a great distance [gdb displays zeros as add %al(%eax)] ). I agree with your suspicion, It seems some registers that aren't explicitly set for int 0x13 are being changed here (ES:BX maybe? Definitely dl) which is causing the OS to load somewhere in the aether (if at all).

^^^ for historical purposes (forgive me, it's late at night)

Yes, your suspicion is correct. dl needs to be reset.

Luckily dl is preserved in [BOOT_DRIVE] already!

@emilkovacev
Copy link
Member

Just an update: I'm able to get the first few hundred kilobytes mapped! I was able to verify the mapping using gdb, and I am working on getting it to work for many mappings. I believe we talked about using bitmaps, so I think I can get a simple page allocator in a week or so!

@emilkovacev emilkovacev mentioned this issue Nov 3, 2023
6 tasks
@emilkovacev emilkovacev mentioned this issue Feb 12, 2024
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants