x86_64 BSP as GSOC2016 project
Saket Sinha
saket.sinha89 at gmail.com
Mon Feb 29 20:00:55 UTC 2016
On Tue, Mar 1, 2016 at 1:14 AM, Saket Sinha <saket.sinha89 at gmail.com> wrote:
> Hi,
>
> Congratulations to the coreboot team for selection in GSOC 2016.
Sorry for the typo. I meant the RTEMS team. I worked for Coreboot last
year so still relate to with GSOC everytime mistakenly.
>
> I am interested in working on x86_64 BSP as GSOC2016 project with
> RTEMS and with initial guidance from Joel as to how to get started, I
> am working on the same.
>
> Looking forward to working with the community for the same.
> Regards,
> Saket Sinha
>
>
> On Wed, Feb 10, 2016 at 7:08 PM, Joel Sherrill <joel at rtems.org> wrote:
>>
>> On Feb 9, 2016 10:37 PM, "Saket Sinha" <saket.sinha89 at gmail.com> wrote:
>>>
>>> Hi Joel,
>>>
>>> Thanks for your inputs.
>>>
>>>
>>>
>>> On Wed, Feb 10, 2016 at 1:06 AM, Joel Sherrill <joel at rtems.org> wrote:
>>> >
>>> >
>>> > On Tue, Feb 9, 2016 at 12:08 PM, Saket Sinha <saket.sinha89 at gmail.com>
>>> > wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >> I think this is early for this but I need to enquire if x86_64_BSP (
>>> >> https://devel.rtems.org/wiki/Developer/Projects/Open/x86_64_BSP )
>>> >> could be taken as a GSOC project this year.
>>> >>
>>> >
>>> > Yes. Assuming you mean the x86_64 bit port and accompanying BSP.
>>> >
>>> > If you noticed my post yesterday, we have tripped across a new embedded
>>> > PC
>>> > without legacy PCI BIOS support.
>>> >
>>>
>>> Could you provide the link. I am not able to locate it on mailing list
>>> or your blog.
>>
>> I only posted a question this week had anyone attempted to use RTEMS on a PC
>> without legacy BIOS. I think the answer is no.
>>
>> I have done a little searching for how to use the newer UEFI services to
>> replace those we use the video and PCI but so far have only found high level
>> information.
>>
>> Sorry. This one is a known need with only early research. I was going to dig
>> into the FreeBSD source next.
>>
>>> > Beyond the obvious port, for the purposes of your effort, there are
>>> > a couple of bugs and some modernization needed by the pc386 BSP which
>>> > you will likely have to address.
>>> >
>>> > + PCI BIOS uses legacy support. Needs to support new and old for 32-bit
>>> > and new only for 64 bit.
>>> > + Better APIC support. pc386 uses legacy PIC and some LPIC for SMP.
>>> > Probably Ok for both 32 and 64 bit to support APIC only.
>>> > + i386 does not have Thread Local Support. Both should have it.
>>> > + i386 has a ticket for SMP synchronization during context switch.
>>> > The code does not use atomics. Should be fixed and x86_64 follow the
>>> > correct pattern.
>>> >
>>>
>>> So now my question is that could these be solved on an emulator like
>>> qemu-x86, atleast for an initial POC ?
>>> I mean is a x86_64 hardware required for it( though I have a Minnowmax
>>> board.)
>>>
>>
>> I think qemu can be used for all of this. You can certainly do the APIC
>> support without addressing the legacy video and PCI BIOS.
>>
>> Similar for the TLS and SMP issue.
>>
>> I believe the entire thing could be brought up and debugged on qemu with
>> checkouts on real HW. Either the Minnow or even a desktop PC with the right
>> BIOS settings. None of this is particularly new. APIC dates back at least a
>> decade.
>>
>>>
>>> > Basically x86_64 should assume a modern (non-legacy) PC and pc386
>>> > needs updating to support newer systems. Common hardware platform
>>> > so hopefully the software is standard.
>>> >
>>> > I was going to write this up as a "PC386 Modernization" Project but some
>>> > of it makes sense as a side-effect of your project. That project idea
>>> > also
>>> > included killing AT bus NICs which you wouldn't have any reason to get
>>> > near.
>>> >
>>> > You need a subtask list (e.g. todo list) and we need to help you flesh
>>> > it
>>> > out. I only hit a few non-obvious highlights.
>>> >
>>>
>>> Let me know how to dig deeper on this. Looking at the code, right but
>>> than exactly what sections ?
>>>
>>
>> libbsp/shared/i386/pci is the current legacy PCI code.
>>
>> The IRQ code should also be under shared.
>>
>> I will have to feel to see where the video probe that is failing is located.
>>
>> The nice thing is that each of these three can be completed in the context
>> of the current BSP.
>>
>>> Regards,
>>> Saket Sinha
More information about the devel
mailing list