x86_64 port and BSP (GSoC 2018)

Amaan Cheval amaan.cheval at gmail.com
Mon Mar 26 10:07:41 UTC 2018

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 <chrisj at 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
> > enough, but I think the scope of the project as-is at the moment seems
> > 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 <chrisj at rtems.org> wrote:
> >
> >> On 20/03/2018 18:10, Amaan Cheval wrote:
> >>> On Tue, Mar 20, 2018 at 11:44 AM Chris Johns <chrisj at rtems.org> wrote:
> >>>> On 20/03/2018 16:21, Amaan Cheval wrote:
> >>>>> On Tue, Mar 20, 2018 at 8:23 AM Chris Johns <chrisj at rtems.org>
> >>>>>> 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
> >>> Vector
> >>>> Table included in the list of tables?
> >>>
> >>> Oh, did you mean the MP Table / ACPI MADT as mentioned in the 2nd
> >>> 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
> > local interrupt sources
> > - Multiple local APICs can talk to each other through the system/APIC
> > (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
> > APICs (individual CPUs on an SMP system)
> > - To use the I/O APIC, you need to parse either MP Tables or tables
> > 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
> > 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
> > than just the legacy master/slave PIC, which should be accomplished
> > by our use of the APIC (even if complete setup and interfacing with the
> > 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
> 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
> >>> 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
> > is all
> >> we need for now.
> >
> > Do you think of this as a key deliverable? To me, it was a bonus
> > given that setting this up correctly is apparently a lot of work; see
> > 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
> > of this GSoC proposal).
> >
> > Does that sound okay?
> >

> It seems fine. My questions and concerns are about understanding

> Chris

More information about the devel mailing list