Brilliant, I think that resolves it all. Let me know if you have any other questions I may have missed or anything is unclear, though!
My next steps are: - Get my QEMU environment setup with OVMF and document it on the wiki - Continue to read Intel's manual on system programming (volume 3) - Read / skim UEFI specification - Read / skim FreeBSD's code for UEFI, APIC support, SMP, etc. - Read more of RTEMS' no_cpu code, and the BSP porting guide - Create a stub port and BSP simply to link with testsuite, as Joel suggested to surface any issues with the tools - Figure out how testing on community hardware (such as your Minnow Board, ITX Atom, etc.) will work, through iPXE and HTTP, and confirm that it does. (I'll likely send out an email to the community in a new topic to solicit more possible volunteers for hardware tests than just Chris J later.) I'll let you guys know once I make significant progress on any of these fronts here - if you think of anything else I should be doing in the meanwhile (such as any tickets that might help me get more relevant experience with RTEMS, or any reading material I haven't already listed in my proposal), let me know! Thank you so much for all your help, everyone! Truly appreciated! :D On Mon, Mar 26, 2018 at 9:56 AM Chris Johns <chr...@rtems.org> wrote: > 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
