Adress space switch in interrupt handlers

[AR]

The reason it may not work is that you have the "a.out kludge" bit set but the kludge is missing, also remeber to turn that off when using ELF.

[Freanan]

I left the bit turned off now, but it did not change.
Normally i would also have tried to output a little char to the edge of the screen to see if it gets at least further this time, but i just (hopefully temporarily) crashed my gentoo system on which i do coding...
So i'd say i check that and return to the thread when my comnputer runs properly again.
Or do you have more ideas what might cause the hanging..?


EDIT:
I tried it now. The first line of start code, which should outut a little b, is not reached, so the higherhhalf-version of my kernel is still not loaded....

[Freanan]

After having coded some memory management functions i have now returned to the higher half thingy (because before i put memory management togethe rinto a unit i want my memory layout to be finished)...
I decided to put all my nice old code aside and start from scratch with the higher half barebones tutorial (with the intention to make this run and add the old code afterwards).

My new code is very close to the barebones, i only have other filenames and my c-kernel-part is different (i used my proper text-outputting functions and so on).
The makefile differs a bit from the barebones one too, but not substantially.
Maybe the problem is that i just use normal gcc 3.something and no crosscompiler?

The problem is, it still does not work.
Bochs complains, my kernel image was too large to fit into memory.
I looked at it with objdump and there is heaps of seamingly useless debug info in there, but i assume bochs will not try to load those sections into memory anyway? It also seems that despite the makefille the .data section got in front of the .text section in the file...

Please help me with this!
Of course i can post any info and files you need

[AR]

Please get it right, BOCHS is an emulator, GRUB is the bootloader, *GRUB* is complaining, if BOCHS was complaining then it would probably PANIC.

The too big problem is usually caused by bad physical addresses in the linkscript, not using a cross-compiler may introduce problems that only you can try and resolve though.

[Freanan]

Oh, i am sorry - i meant grub - i just happen to confuse the two all the time when writing something.

The linkscript is copy-and-pasted from the website, i only added some lines to get the new section introduced by the gcc-lib that i am using for 64bit integers put in a place were they do not harm.
I will still check it, maybe i accidentially added something to an adress...

Probably i will also look into setting up a crosscompiler..

[AR]

The physical address is specified by AT(Address), if you added a new section and didn't AT() it then it will want to be at the same physical address as the virtual address (So unless you have 3.1GB of RAM it won't work).

[Freanan]

I added them to the .text section in the same fashion as .rodata is added in the original linker script from the barebones:

Code: Select all

    .text : AT(ADDR(.text) - 0xC0000000)
    {
        *(.text)
        *(.rodata)
    }

Is this wrong?

I think i will try to exactly redo the barebones tutorial without even the slight changes that i made...
Probably this will work and then i can still gradually add my old code.

[Freanan]

Starting really from scratch seems to have been a good idea.
I got the highehalf barebones running now and was able to add most of my old stuff.

I have one question left considering the barebones code, though:

The loader.asm file gives the adress of the multiboot info to the main-function as an argument.
But the multiboot info is a physical adress, which is mapped to high memory, so we probably have to add 0xC0000000 to each mbi-related adress...

Is this right? Maybe it was seen as obvious?
I think it would be good to add a hint in case my assumption is right.

[Colonel Kernel]

The loader.asm file gives the adress of the multiboot info to the main-function as an argument.
But the multiboot info is a physical adress, which is mapped to high memory, so we probably have to add 0xC0000000 to each mbi-related adress...

Is this right? Maybe it was seen as obvious?
I think it would be good to add a hint in case my assumption is right.

Thank you for finding a bug! I added appropriate warning comments to the code in the FAQ. You can't just add 0xC0000000 to the address though, since the multiboot spec doesn't guarantee that the info structure will be in the first 4 MB. You'll have to map it somewhere "by hand". Maybe if I have time later I'll add that to the HigherHalfBareBones. For now it's a TODO in the comments.

[Freanan]

Fine !


I am having some more problems trying to actually do the remapping of mbinfo
in my C-code.

I also decided to re-map the kernel space as well, because i preffer to have
it in 4k pages instead of one 4mb page and(!) because my mbinfo-mapping code
would crash without it.

After that the mbinfo-mapping code does not crash anymore, but it does not
work either.
Look at these fragment of the mapping functions, with the output that i get
included as comments:

Code: Select all

//fill in the adress of the mbinfo
mbi_page_table[entry]=(adress_t)mbi_page | 3;
putnum((adress_t)mbi_page | 3,16); //Output:2d003 ok

//fill in the page table to keep it
set_pagedirentry(table, page_dir, mbi_page_table, 3);
   
putnum(mbi_page_table[entry],16); //Output:ffffffff !!!
putnum(page_dir[table],16);       //Output:c0105003 ok
putnum(mbi_page_table,16);        //Output:c0105000 ok

I am sure that this is the place were the error occurs, as the writing of the
pages offset into the page table does obviously not work at all.
Still i have no clue why it does not work - it is totally sick!
I write mbi_page|3(=2d003 - which is right) to mbi_page_table[entry] and on
printing that it suddenly is ffffffff!

Please give me any clues what might be the reason for this....!