De: "Alexei A. Frounze"
Objet: Re: Another "Jumping to a C kernel" problem
Date: samedi 19 juillet 2003 21:01
"eip"
news:ba28f56e.0307190828.646edf0a@posting.google.com...
> Hi,
> I have a bootsector that loads my kernel to 0x00:0x1000 (real mode
> address).
> Then it sets up a GDT, switches to Protected Mode and enables the A20
> line.
> This works fine, but i can't jump to my kernel!
> At the end my bootsector does a: jmp CODE_SEGMENT:0x1000 (protected
> mode address) which must be the right address where kernel has been
> loaded.
> Could anyone help me? As far as i know 0x00:0x1000 real mode is linear
> 0x1000.
Correct.
> Protected Mode CODE_SEGMENT:0x1000 is also linear 0x1000, isn't it!
Depends on the seg's base addr.
> Why does this
> not work, if my CODE_SEGMENT base address in the GDT is 0x00?
Wrong GDT descriptor for that segment, wrong GDTR (or wrong address supplied to LGDT!), wrong code bitness (PMode when enabled starts out as 16-bit mode! switching to 32 bits requires far-jumping to a 32-bit code segment), wrong selector in segment register, etc. A *single* mistake or typo usually breaks
the things. Check all these listed things step by step paying attention to what you need and to what you actually wrote in the code. If you have any doubts, you better check the documentation. Blind assumptions lead to bugs.
> By the way: How can i get an "image" from memory? For example, i would
> like
> to see the first MB of my memory when my bootsector was executed, to
> see if
> my kernel is really loaded at the right position.
Just write a program for that.
I wonder why almost everybody does things in the hardest, wrong way.
Examples:
1. Going into OS dev knowing little to nothing about the topic and having low programming and problem solving skills. Is it sort of a popular thing to do?
2. Going into PMode knowing little or nothing about the x86 CPU and the assembler language, the language of the CPU.
3. Putting together different codes in such a way that they can't be debugged at all: stuffing a boot sector with BIOS-based disk I/O code, PMode
enabling code, all of which aren't 100 per cent bug-free and put the whole program's functionality under a big question. Why the heck all the newbies can't make a boot floppy (aka rescue disk or whatever) with their windows which would allow them to boot in real mode in the DOS7 thing, where it's easy to load and run any program from any disk w/o going into BIOS and boot troubles. Why is it assumed that booting off a floppy is easier? Or is it again the freakish temptation to show how damn cool the newbie is by having his stupid "hello world"-like OS (which isn't an OS) starting up from a floppy? Why so little understanding is put into all these issues? How do all of you think it'll be possible to develop big portions of software in a such hard and time-consuming way by putting all crap together and feeding it to the CPU in the bootsector? It's not just you, "eip", it's what the vast majority of newbies showing up here do. I've stated that OS dev isn't a piece of cake, I've done that numerous times, and the reality hasn't changed since I first said that here. OK, you might not read that, but what was your thinking when you started? Was there any at all? Do you happen to have any plans for the OS you're "developing"? And why are you doing that in first place?
4. Not using plenty of good tools, not using their modes that can be helpful when something is wrong but isn't apparent from the source code. Examples:
- file viewers with built-in disassemblers like HIEW and BIEW - very helpful to see what actual addresses are contained in the binary that you want to
boot or load at a certain address, helpful to do size optimizations -- each instruction when disassemblied has opcodes next to the mnemonic - map files that can be generated by linkers. The map files again show addresses your segments, functions and data variables received - HLL -> ASM conversion modes available in HLL compilers. Can be extremely useful for those new to ASM, who'd better see what their say C code turns into after compilation. Borland's and GNU's C/C++ compilers do have the -S command line switch that allows to compile a C/C++ src file into ASM file, so you can study what your CPU is gonna execute. This is again helpful when understanding the calling conventions, e.g. how data is passed as arguments to the functions via stack, who and how manages the stack (caller or callee), how the return values are returned (e.g. in what registers or where on stack)
- the most obvious things like Ralf Brown's Interrupt List (aka RBIL) and the many similar BIOS/DOS interrupt references like Tech Help and HelpPC - a must for everyone.
- it's silly to mention, but the truth is that intel's documents are *the most* detailed references on the intel CPUs. It's *the first* source for all technical information regarding the CPU and programming it. All protected mode things are described there, all addressing modes and segmentation are described there, all interrupt management is described there, how the stack of the CPU works is described there (many don't know even this!), how FPU, MMX, SSE works (well, intel's docs aren't math textbooks -- they have never been intended to teach you math, so you better learn math elsewhere or don't even pretend to get away without math understanding when doing math stuff).
And there are optimizatiom docs too. You must actually be happy that intel provides you such documentation free of charge. So sit back and read with attention. If you don't get certain things, don't skip. You better repeat reading that same piece of text until you actually get it. See other places in the doc that describe the meaning of the same or similar terms and techniques. Nobody shouldn't teach you how to use books and documents. If you want it, do it. If you're not ready for it, either give up and go for an extra beer or forget about everything else and learn the prerequisites so you can move further.
Sounds like a parental or teacher's guidance? That's what is, though I'm neither you parent nor your hi's teacher. If you *really* want something, find ways to get it and remember that the result depends on how hard you work towards the result. If you don't believe any of this, well, either the time will prove you wrong or you're just hopeless and nothing can change you but... you know what changes everybody... it happens to everyone in the end but that'll be far too late to do anything about things done in the past. :)
Come on, just get things done right!
Good Luck
--
Alexei A. Frounze
http://alexfru.narod.ru/
http://members.tripod.com/protected_mode/