x86_64 port and BSP (GSoC 2018)

[Amaan Cheval]

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
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 <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>
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