On 26/03/2018 14:49, Amaan Cheval wrote: > 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?
Yes as iPXE and others. > 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. I was thinking about as a point to remember. If it comes for free why not keep it. > > 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) This seems normal for SMP. > - 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) OK, this is what I saw and I went that is too much to do in a few hours so moved on. :) > - 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). We found with the newer BIOSs with UEFI some interrupts are mapped above the last slave PIC IRQ. It is just looking practically at the problem. > >>> 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 It is not key. A BSP framework we can easily add this is. > 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? > It seems fine. My questions and concerns are about understanding expectations. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
