I read through the wiki entries and I just had a few questions that I don't think were covered anywhere.
First is, upon execution of loader at 7c00, the IF flag is clear correct? I would assume so based upon the fact that we need to setup stack segment, but just to be clear.
Second question. For PIC mode (or virtual wire for backward compatibility) I see that the BIOS sets the vector offset of the master PIC to 0x8, but would that IRQ not conflict with the double fault exception as well? Should I just remap it again myself?
3rd and final I am familiar with APIC programming due to several past projects I worked on, one thing I didn't find covered with the 8259 PIC is interrupt priority. Obviously interrupts are masked until we write to EOI, but is there a priority level based upon the vector number?
Thanks.
Little new to bootloader development. Quick initial question
Re: Little new to bootloader development. Quick initial ques
You should not make assumptions about IF flag in this case.devsau wrote:First is, upon execution of loader at 7c00, the IF flag is clear correct?
You don't need to disable interrupts to setup stack. Just load SS, then SP. Every loading of SS automatically disables interrupts for the next instruction.devsau wrote:I would assume so based upon the fact that we need to setup stack segment, but just to be clear.
Re: Little new to bootloader development. Quick initial ques
Actually all three of these are easy to find.devsau wrote:I read through the wiki entries and I just had a few questions that I don't think were covered anywhere.
You shouldn't make any assumptions about hardware whatsoever.First is, upon execution of loader at 7c00, the IF flag is clear correct? I would assume so based upon the fact that we need to setup stack segment, but just to be clear.
Yes, that's exactly what you do. Why do you think you disable interrupts when entering protected mode?Second question. For PIC mode (or virtual wire for backward compatibility) I see that the BIOS sets the vector offset of the master PIC to 0x8, but would that IRQ not conflict with the double fault exception as well? Should I just remap it again myself?
Yes. In real/pmode, it's irq 0 first, and I don't remember or feel like looking up the rest. In long mode, it starts as that but is changeable.3rd and final I am familiar with APIC programming due to several past projects I worked on, one thing I didn't find covered with the 8259 PIC is interrupt priority. Obviously interrupts are masked until we write to EOI, but is there a priority level based upon the vector number?
You're welcomeThanks.
Programming is 80% Math, 20% Grammar, and 10% Creativity <--- Do not make fun of my joke!
If you're new, check this out.
If you're new, check this out.
- Griwes
- Member
- Posts: 374
- Joined: Sat Jul 30, 2011 10:07 am
- Libera.chat IRC: Griwes
- Location: Wrocław/Racibórz, Poland
- Contact:
Re: Little new to bootloader development. Quick initial ques
That's the far less relevant part of the problem. See differences between IVT and IDT - specifically, firing *any* interrupt before IDT is set up will cause #GP, because IDT limit is 0, which will cause #GP causing #DF because IDT limit is 0, which will cause #GP causing #TF, because IDT limit is 0.m12 wrote:Yes, that's exactly what you do. Why do you think you disable interrupts when entering protected mode?Second question. For PIC mode (or virtual wire for backward compatibility) I see that the BIOS sets the vector offset of the master PIC to 0x8, but would that IRQ not conflict with the double fault exception as well? Should I just remap it again myself?
Get your facts straight before answering next time.
Yes, you should, it is mentioned in about every tutorial or resource that mentions PIC and interrupts.Second question. For PIC mode (or virtual wire for backward compatibility) I see that the BIOS sets the vector offset of the master PIC to 0x8, but would that IRQ not conflict with the double fault exception as well? Should I just remap it again myself?
Reaver Project :: Repository :: Ohloh project page
<klange> This is a horror story about what happens when you need a hammer and all you have is the skulls of the damned.
<drake1> as long as the lock is read and modified by atomic operations
<klange> This is a horror story about what happens when you need a hammer and all you have is the skulls of the damned.
<drake1> as long as the lock is read and modified by atomic operations
Re: Little new to bootloader development. Quick initial ques
Hi,
To fix the "unknown stack" problem you have to setup a known stack.
Cheers,
Brendan
The IF flag should actually be set (IRQs enabled); and there should be a stack. The problem is that you don't know how large the stack is or where the stack is. For a (deliberately "worst case") example; the BIOS might use exactly 1234 bytes for its IRQ handlers and might have a 1234 byte stack just above your boot code, so if you push anything on the stack your code gets trashed as soon as an IRQ occurs. Of course a far more likely problem is that your boot code wants to load something (e.g. a kernel) from disk and trashes its own stack.devsau wrote:I read through the wiki entries and I just had a few questions that I don't think were covered anywhere.
First is, upon execution of loader at 7c00, the IF flag is clear correct? I would assume so based upon the fact that we need to setup stack segment, but just to be clear.
To fix the "unknown stack" problem you have to setup a known stack.
For 8086 the CPU doesn't disable IRQs for the instruction following a load of SS (only later CPUs do that). My normal approach is to assume the CPU might be an ancient 8086 (and explicitly disable IRQs when setting up a known stack); then (later) check if the CPU is too old for the OS (and display an error and refuse to boot if it is). Of course this may be considered "excessively cautious".Yoda wrote:You don't need to disable interrupts to setup stack. Just load SS, then SP. Every loading of SS automatically disables interrupts for the next instruction.
The IRQ priority is based on "PIC input number", and is fixed/hard-wired; and due to the way the slave PIC is connected to the master PIC (via. "PIC input number 2") it's a little strange. The priority of IRQs (from highest priority IRQ to lowest priority IRQ) is: IRQ 0, 1, 8, 9, 10, 11, 12, 13, 14, 15, 3, 4, 5, 6, 7.devsau wrote:3rd and final I am familiar with APIC programming due to several past projects I worked on, one thing I didn't find covered with the 8259 PIC is interrupt priority. Obviously interrupts are masked until we write to EOI, but is there a priority level based upon the vector number?
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re: Little new to bootloader development. Quick initial ques
Yes, this is really excessive caution because, first, you will hardly find working PC/XT, second, even if you find it, you won't blame modern OS if it will just hang instead of spitting error message about your ancient hardware, and third, it is even too difficult to write good first stage bootloader without using 386 code.Brendan wrote:Of course this may be considered "excessively cautious".
Re: Little new to bootloader development. Quick initial ques
Hi,
Cheers,
Brendan
I've been doing "assume 8086 until initial CPU detection" for a long time. It's not too difficult; but if you're going to use 80386+ code anyway, then you should be using the LSS instruction.Yoda wrote:Yes, this is really excessive caution because, first, you will hardly find working PC/XT, second, even if you find it, you won't blame modern OS if it will just hang instead of spitting error message about your ancient hardware, and third, it is even too difficult to write good first stage bootloader without using 386 code.Brendan wrote:Of course this may be considered "excessively cautious".
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re: Little new to bootloader development. Quick initial ques
What does that matter? Clear it anyway - and a cld might be a good idea as well.devsau wrote:First is, upon execution of loader at 7c00, the IF flag is clear correct? I would assume so based upon the fact that we need to setup stack segment, but just to be clear.
When the 8086 was first launched Intel reserved the first 32 interrupts for their own use, but IBM decided they could ignore that, and for many years they got away with it - until protected mode OSes came along. Nowadays you should reprogram the PIC if you are going to have a protected mode OS.devsau wrote:Second question. For PIC mode (or virtual wire for backward compatibility) I see that the BIOS sets the vector offset of the master PIC to 0x8, but would that IRQ not conflict with the double fault exception as well? Should I just remap it again myself?
IRQ0 has the highest priority, and IRQ7 the lowest.devsau wrote:3rd and final I am familiar with APIC programming due to several past projects I worked on, one thing I didn't find covered with the 8259 PIC is interrupt priority. Obviously interrupts are masked until we write to EOI, but is there a priority level based upon the vector number?
Re: Little new to bootloader development. Quick initial ques
thanks for all the responses guys