Hi, Congratulations to the coreboot team for selection in GSOC 2016.
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 <j...@rtems.org> wrote: > > On Feb 9, 2016 10:37 PM, "Saket Sinha" <saket.sinh...@gmail.com> wrote: >> >> Hi Joel, >> >> Thanks for your inputs. >> >> >> >> On Wed, Feb 10, 2016 at 1:06 AM, Joel Sherrill <j...@rtems.org> wrote: >> > >> > >> > On Tue, Feb 9, 2016 at 12:08 PM, Saket Sinha <saket.sinh...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
