OSDev.org

foliagecanine wrote:Is this referring to AMD64 Architecture Programmer's Manual section 7.7.4 (MTRRs and Page Cache Controls)?

foliagecanine wrote:Are there specific paging flags (Cachedisable, writethrough) that need to be set on memory used by AHCI (and others)?

foliagecanine wrote:How do you know which flags are necessary?

foliagecanine wrote:

Code: Select all

pfa_init((void *)0x00500001);
...
pfa_deinit_region(0, 0x00500000);

instead of what you have currently (I assume that the memory layout should be Paging stuff, then Kernel, then stack, then heap)

foliagecanine wrote: 2. If a bit in the PI comes up as a 1, check to make sure the hba_mem->ssts (SATA Status) has the Present Bits (bits 8 and 9) and IPM Active Bit (bit 0) active.

for(int bit = 0; bit < 32; bit++)
    {
        if(ahci_device.hba_mem->pi & (1 << bit)) // bit is set: device exists
        {
            uint32_t status = ahci_device.hba_mem->ports[bit].ssts;
            if((status & (1 << 0)) && (status & (1 << 8)) && (status & (1 << 9)))
            {
                tty_printf("Valid device found at bit %u\n", bit);
            }
        }
    }

Bonfra wrote:hba_mem does not have a field ssts, so I think that you refer to the hba_mem->ports[bit].ssts

uint32_t ssts = hba_mem->ports[bit].ssts;
if ((ssts&0x00F0)==0x10&&(ssts&0x000F)==3)
    // Device is present and ready

foliagecanine wrote:First of all, something is wrong with your page frame allocator.

Code: Select all

page0: 0x0000
page1: 0x1000
page2: 0x2000

when your code clearly says

Code: Select all

//first page is always set. This insures allocs cant be 0
bitmap_set(0);

foliagecanine wrote: Second, and MOST IMPORTANTLY,

Code: Select all

        for(int i = starting_device; i < registered_devices; i++)
            configure_device(devices[i].port);

You're passing an hba_port_t* where an hba_device_t* should be. It should be

Code: Select all

        for(int i = starting_device; i < registered_devices; i++)
            configure_device(&devices[i]);

Once this code is changed it outputs the hex

foliagecanine wrote:Well, for one thing, it's not a great idea to alloc memory below 1MiB.
The BIOS usually stores some important data structures here (ACPI stuff for instance).

foliagecanine wrote: Second, you should REALLY improve your page fault handler.
The system gives you the address that caused the page fault in CR2 as well as the error code and return address at the top of the stack (you'll need to put the return address back on the stack though).

foliagecanine wrote: Third, both VirtualBox and VMware can't get past "VBR Loaded."

Bonfra wrote:

foliagecanine wrote:Second, you should REALLY improve your page fault handler.
The system gives you the address that caused the page fault in CR2 as well as the error code and return address at the top of the stack (you'll need to put the return address back on the stack though).

I've treated the page fault as a normal exception, just like a division by zero. Theoretically, with the system I have now, I should create on the fly a new page in that memory when the fault is raised right?

Bonfra wrote:The bootloader is designed to run from an HDD, (or in my case a USB in emulation mode) so if you load it as iso it would not work. I didn't test it on these two emulators but maybe this is something I need to specify in the readme file of the repo

Bonfra wrote:I noticed that sometimes it raises a Page Fault but other times it is a General Protection Fault

foliagecanine wrote: I converted the .img to a .vmdk so that it would run on VMware/VirtualBox, but they both had the same problem.

foliagecanine wrote: Really, the reason I say you should improve it is so that you can see exactly where the fault happened, what memory access caused it, and why.

foliagecanine wrote: It would be very helpful if you read and print out CR2.

    uint64_t cr2;
    asm("mov rax, cr2");
    asm("mov %0, rax" :: "m"(cr2));
    tty_printf("CR2: %X\n", cr2);

foliagecanine wrote: If you are using 64-bit, why are the registers not being printed out with 16 hex characters?

foliagecanine wrote: And what hex address does "cffd40:10286" mean?

foliagecanine wrote: And yes, as far as I know VirtualBox does have an option to debug with GDB.