OSDev.org

This should probably be in General Programming, but this is with a view to OS dev.

I've been having serious problems with my paging setup code (which I have now deleted, but am convinced was perfectly correct). I'm convinced it was correct because I've now found that the following code just does not do anything like what it's supposed to.
However, using Bochs to test shows: that while the pointer does indeed point to 0xD0000, the value stored at that address is merely 0xFFFFFFFF - and the address after (and the address after that onto as far as I've tested it (up to 10000 words)).

What gives - am I missing something? It seems bizarre that the problem in the code was something so simple... Now of course, I will have to start from scratch with my paging code... But I have absolutely no idea as to why this isn't writing where it's meant to.

What gives - am I missing something? It seems bizarre that the problem in the code was something so simple... Now of course, I will have to start from scratch with my paging code... But I have absolutely no idea as to why this isn't writing where it's meant to.

may i suggest backup before rewriting a major componet

That is very very weird that its doing that
i know its probably useless but maybe try unsigned int *pd instead but I'm quite sure their the same(and don't know how that'd cause a problem)

Are you in protected mode without paging enabled when you do this? I know for a fact that those two lines should work (store the value 0x12345678 at logical address 0xd0000) because thats how pointers work. What commands did you use when examing memory in bochs? And what assembly did those two liens compile to in your kernel?

Yeah, backup would've been a good idea - but what I had wasn't too major. Only a couple dozen lines of code. Just moderately irritating that it's become evident that it wasn't even wrong.

Yes, this is in protected mode without paging having been set up. I was about 99% sure they should work, but I wondered if maybe I was just missing something obvious because I'm getting tired of looking at the same thing (a fresh pair of eyes is always a good thing for spotting small logic errors).

I used xp /1w 0x103020 to examine the address pointed to by the pointer - which returns 0xD0000. I then used xp /1w 0xD0000 to check that and got the return value of 0xFFFFFFFF.

The two lines won't compile directly, obviously, but having stepped through the code in Bochs, I can say that it seems to be doing the right thing. Here's what the instruction tracing gives for the appropriate section in Bochs, as I step through:
And while EAX gets loaded with the correct address, nothing seems to actually get written at that address.

1) Make sure that DS is correctly set up to point to your data segment.

2) When you say eax has the correct value, you're saying that eax = 0xD0000 ? And then when the next line has executed 0xD0000 hasn't changed? If that's the case, and DS is set up correctly, thats very strange...

1) It's certainly pointing where I want it to - segment 0x10. In bochs, the line of the dump_cpu says:
What does the valid=7 mean? So far as I can tell that looks like the correct descriptor setup.

2) Yep, EAX = 0xD0000 and after the instruction, that memory location hasn't changed at all.

Is the memory region at 0xD0000 safe to write to? I know if you write over the video card memory while it's not in use, it also comes back as 0xfffffff...

A quick search shows that that section of memory is used by the BIOS. (shadow area?)

Hm, that's a point that didn't occur to me. I'll check that out tomorrow. That certainly sounds very, very plausible.

Yep, that was indeed the problem, thanks. Got it working now.

A quick search shows that that section of memory is used by the BIOS. (shadow area?)

more acurately, its not used by the BIOS (0xE0000 - 0x100000 is reserved for portions of the BIOS to be copied into) but device ROM-- the region 0xC0000 - 0xE0000 is reserved for use by devices (mostly ROM, but some registers, and RAM also), such as the HDD controller, video ROM, some (older)network controllers, etc (video ROM is usually lower than 0xD0000, but HDD controller is (iirc) usually near that place

normally, you can read/write to real RAM underneath in the holes between devices, (however, just be sure you know exactly were the other devices are located -- it can be detected, but i dont remember how), but i dont know what bochs does with this

JAAman wrote: normally, you can read/write to real RAM underneath in the holes between devices, (however, just be sure you know exactly were the other devices are located -- it can be detected, but i dont remember how), but i dont know what bochs does with this

I would just mark C0000h-FFFFFh ROM area to make things simple. I would say, normally you can't use the unused areas rather then vise-versa. I haven't ran into a systen that return unused areas as RAM anyway.

PnP device ROM would be the easiest to detect, by scanning the PnP header somewhere within 2KB boundries. Well all of these structures such as PCI, lecacy device ROM structures is in the BIOS Boot specification. But I would just forget the troubles.