Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
I am writing bootstrap code for my OS and it is not working. Sounds familiar ? But I hope with your help it is just a temporary problem
The problem is :
After loading bootstrap code and switching to the protected mode the system just throws Invalid Opcode interrupt. The code works fine with Qemu and Bochs emulators, but refuses to work with real hardware. In the bug hunting quest I have implemented minimal problem detection code. It first loads bootstrap code, then switches to the protected mode, then just writes 4 megabytes of 0xff values starting from address 0x191000. Values are written with REP STOSD instruction. After values are written my code calculates the sum of all DWORDs in the filled memory range. The system behaves in a very strange manner - the screen becames gray (obviously memory screen area is written by some means) and summation result (some random number) is different from the expected sum of 1M of minus ones. Emulators give me nice sum and black screen - the code just works fine.
Additional information - interruppts are off (using CLI instruction), string operation direction flag is set to zero (CLD instruction), all 256 interrupts are pointed to the same code, which just displays interrupt number and halts. The tested systems are two notebooks, one with dual core AMD Turion and another with Intel Atom processors. Memory map was read with INT e820 and it tells the mentioned memory region is free for use.
May it be ACPI system interference ? Or is there some not specified in memory map regions mapped to some PCI hardware, for example ? Or is it some system management mode activity ? Where to dig to catch the bug ?
embryo wrote:
May it be ACPI system interference ? Or is there some not specified in memory map regions mapped to some PCI hardware, for example ? Or is it some system management mode activity ? Where to dig to catch the bug ?
Right, so you encounter a bug in your code and immediently assume it's someone else's fault.
There shouldn't be any memory mapped hardware in that region or ACPI tables or SMM interference. There area you've chosen is free to use if it use if it exists.
Can you post the problematic code? Maybe we can spot the bug?
TachyonOS - Violates causality on 95% of attempts. Runs at approximately 1.5c.
bluemoon wrote:Are you sure A20 is properly initialized so that your 1MB test data is not overwriting your code and video memory?
No, I am not sure. My logic was simple - Intel's manual haven't mentioned anything like A20 initialization for switching to protected mode. But now I will read about A20, at least one possibility will be cleared for me.
That is because A20 is a feature specific to the IBM PC, and not universally across x86 processors. The practical relevance is mentioned on the Bootloader page though.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
I have enabled A20 line and now everything works fine ! The problem was in the murky Intel's guide where A20 only mentioned in the context of real mode or legacy systems.
Thanks to all, who regarded my question as being worth to answer to
But why such important step as A20 enablement is missed so many books ? And A20 description often sounds misleading - it could be enabled and used in real mode for giving you the memory above 1M - when it should be - without A20 enablement NO system can work even in protected mode with memory above 1M !
embryo wrote:(...) A20 enablement is missed so many books
Any references? I'm not the book buying type but it's good to be aware of known caveats in other people's work.
it could be enabled and used in real mode for giving you the memory above 1M - when it should be
And break DOS apps along with it.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
embryo wrote:without A20 enablement NO system can work even in protected mode with memory above 1M !
Without the A20 gate enabled, you can get into protected mode, but each "odd" megabyte is aliased to the previous "even" one. It works, it just doesn't work well at all.
Combuster wrote:That is because A20 is a feature specific to the IBM PC, and not universally across x86 processors. The practical relevance is mentioned on the Bootloader page though.
Which makes me wonder if x86 Macintoshes follow the PC architecture close enough to deal with the whole A20 line kerfuffle, and if so, what kind of x86 system exists that doesn't?
embryo wrote:(...) A20 enablement is missed so many books
Any references?
Intel 64 and IA-32 Architectures Software Developer's Manual. There are only 3 references in the book's index to the A20 keyword. Those references deal with real mode/virtualization/compatibility. Last subject (compatibility) tells that p6 family MAY wraparound in real address mode. Is it the case for protected mode ? Intel keeps silence about it.
Just a primitive logic tells me that when in the manual I see words about protected mode as a native mode of the processor and the same manual tells me step by step procedure how to switch to that mode and there is no mentioning of A20 line - something is very bad in the world of low level programming.
embryo wrote:I have enabled A20 line and now everything works fine ! The problem was in the murky Intel's guide where A20 only mentioned in the context of real mode or legacy systems.
Thanks to all, who regarded my question as being worth to answer to
But why such important step as A20 enablement is missed so many books ? And A20 description often sounds misleading - it could be enabled and used in real mode for giving you the memory above 1M - when it should be - without A20 enablement NO system can work even in protected mode with memory above 1M !
No. If you read carefully in the intel manual(on A20M# pin) or the wiki, the A20 line only mask the #20 bit, so you can still access odd megabytes above 1M.
Note that on some newer processer, especially mobile processor, A20M# pin may be obsoleted and not exist at all - which effectively as always enabled.
Blacklight wrote:Which makes me wonder if x86 Macintoshes follow the PC architecture close enough to deal with the whole A20 line kerfuffle, and if so, what kind of x86 system exists that doesn't?
If you attempt to enable A20 on x86 mac, the machine locks up completely.
embryo wrote:(...) A20 enablement is missed so many books
Any references?
Intel 64 and IA-32 Architectures Software Developer's Manual.
One manual is a bit underrated for being called "so many books"...
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
bluemoon wrote:you can still access odd megabytes above 1M.
Yes, I can. But remembering the guide from processor manufacturer which tells nothing about A20 importance - isn't it just misleading ? And all other sources of information I have read state something fuzzy about A20. Even wiki.osdev.org first tells some history about old and dirty hack then speaks about real mode and after few paragraphs assuming very careful reading mentions "it should be enabled". Should be enabled when ? In real mode ? If the reading was - you must enable A20 for using processor in any mode (protected and long included) - would it be less misleading ?
bluemoon wrote:on some newer processer, especially mobile processor, A20M# pin may be obsoleted and not exist at all - which effectively as always enabled.
And this piece of knowledge is not contradicts with the written above - A20 must be enabled. And if it can be enabled by default that means only one thing - you must always check if it is enabled and if not - you must enable it or will get some wierd behavior.
I doubt that any useful system design would relay on only odd megabytes available. And if it was a hack, it still is a hack and it always will be a hack - why just not to tell strict - you must enable it ? And for hackers there could be some remark about "very useful" mode of only odd megabytes available. Things should be as simple as possible, why there is a need in such complication ?
Combuster wrote:One manual is a bit underrated for being called "so many books"...
I hope the post above gives some additional information. I have spent a lot of time catching the bug and being confident that protected mode switch is recomended by the technology source and should be trusted, another books I have read just repeat steps from Intel. But no reading was about "you must enable it".
However your reference to the Bootloader wiki page states strict that A20 should be enabled. I have missed this page until too late.
It is not the manufacture's fault by not teaching you everything, A20, or cache behavior with 3rd party IO device, or how much glass of water you need to drink per day.
To be an OSdev'er you should proactively get and read as many materials as you can.
Regarding A20, for instant, it is considered well known fact. The wiki provide insight on why it is introduced and how to operate it.
The processor manual, on the other hand, described the A20M# behavior, this is however out of scope for processor manual to talk with how to operate such pin, since it may involve 3rd party controller from motherboard or KBC.
OK enough rambling, A20 is only a one-shot trouble, get over it.
