Hi! Thanks for your comments on the document, by the way. Regarding the following comment:
> We should support multiboot as well for legacy X86 BIOSes. There are headers about that can do this. This is a great point - this way legacy BIOSes only need something like GRUB (or a bootloader implementing the Multiboot spec) to boot RTEMS' x86-64 port, right? Do you think it's okay to lay this out as a bonus feature? It seems simple enough, but I think the scope of the project as-is at the moment seems just right, in that it leaves a little room for unexpected time-consuming Heisen-bugs. On Mon, Mar 26, 2018 at 4:08 AM Chris Johns <chr...@rtems.org> wrote: > On 20/03/2018 18:10, Amaan Cheval wrote: > > On Tue, Mar 20, 2018 at 11:44 AM Chris Johns <chr...@rtems.org> wrote: > >> On 20/03/2018 16:21, Amaan Cheval wrote: > >>> On Tue, Mar 20, 2018 at 8:23 AM Chris Johns <chr...@rtems.org> wrote: > >>>> On 19/03/2018 18:36, Amaan Cheval wrote: > >>> (Assuming that by tables you meant the Local Vector Table, etc., and not > >>> the ACPI's MADT, which is relevant to SMP in that it contains a list of > >>> LAPICs, thereby letting us find how many cores are available.) > > > >> I was thinking about the SMP tables. SMP is not part of this work at the > > moment > >> so what ever is needed in this area to make the BSP work. Is the Local > > Vector > >> Table included in the list of tables? > > > > Oh, did you mean the MP Table / ACPI MADT as mentioned in the 2nd bullet > > here? (From volume 3 of Intel's IA32 and 64 manual.) > > https://i.imgur.com/elZIlfy.png > It has been a while since I looked at this. Is there a table for interrupts and > interrupts beyond the master/slave legacy PICs? The way I understand it is: - There are local APICs per core (making up a CPU) - Local APICs have local events such as APIC timers, perf counters, I/O devices, etc. - the Local Vector Table is used to configure each of these local interrupt sources - Multiple local APICs can talk to each other through the system/APIC bus (model-specific) through Inter-Processor Interrupts - The I/O APIC is connected to the system/APIC bus, and allows external devices (including PCI) and system hardware to communicate with the local APICs (individual CPUs on an SMP system) - To use the I/O APIC, you need to parse either MP Tables or tables through ACPI (determining how devices map to the I/O APIC's input pins, to tease out where lines are being shared, and how interrupts may be redirected) - The Interrupt Descriptor Table (IDT; protected mode) or Interrupt Vector Table (IVT; real mode) are then used to actually call the ISR that was registered (depending on specific configuration and the type of interrupt/exception, of course) I believe the distinction you're looking for is one about configuring more than just the legacy master/slave PIC, which should be accomplished merely by our use of the APIC (even if complete setup and interfacing with the I/O APIC is not in the scope of this proposal, the project sets up future improvements nicely). > > One of those tables will need to be parsed to configure boot for SMP > > systems correctly, yes. I thought you meant the tables that need to be > > setup for the local APIC to be initialized and used correctly (which is > > also necessary to be able to send Startup Inter-Proessor Interrupts (SIPI) > > for SMP boot to work). > I think interrupts to access to various PCI devices beyond the slave PIC is all > we need for now. Do you think of this as a key deliverable? To me, it was a bonus feature, given that setting this up correctly is apparently a lot of work; see the following forum post, for example: https://forum.osdev.org/viewtopic.php?f=1&t=21745&start=0#p174219 Getting this to work correctly would also mean parsing MP tables, or accessing tables through ACPI (which is also a bonus feature for the scope of this GSoC proposal). Does that sound okay? > Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
