x86_64 port and BSP (GSoC 2018)

Sat Mar 17 18:32:29 UTC 2018

On Sat, Mar 17, 2018 at 1:09 PM, Gedare Bloom <gedare at rtems.org> wrote:

> On Sat, Mar 17, 2018 at 11:58 AM, Amaan Cheval <amaan.cheval at gmail.com>
> wrote:
> > First off, thank you so much for the prompt and detailed response! I
> really
> > appreciate the help!
> >
> > On Sat, Mar 17, 2018 at 6:46 PM Gedare Bloom <gedare at rtems.org> wrote:
> >
> >> On Sat, Mar 17, 2018 at 2:24 AM, Amaan Cheval <amaan.cheval at gmail.com>
> > wrote:
> >> > Hey everyone!
> >> >
> >> > Here's a link to a draft of my proposal (also shared through the GSoC
> >> > website, and linked to on the wiki):
> >> >
> > https://docs.google.com/document/d/1X79Yj0DNqvaDFqpJMUX4gF3WC550G
> DvVDS5QufvAnFE/edit?usp=sharing
> >> >
> >> > I'd appreciate all comments - even if you're just skimming, let me
> know
> > if
> >> > you have something to say!
> >> >
> >> > I have a few questions too, which I'd appreciate help with:
> >> >
> >> > Regarding the proposal:
> >> >
> >> > - Does it seem like I'm committing too little / too much?
> >
> >> I don't think you have work planned in a good way. The scope of the
> >> second half is light, while the first half may be heavy. It is OK to
> >> have schedule slip, but it is better if you can try to balance the
> >> work over the phases. Also, note that GSoC is now a three-thirds
> >> instead of two-halves timeline.
> >
> > Noted. I've revised it a bit (same link). Would you mind having another
> > look?
>
>
I have always thought the first part of this project would be to get
an UEFI "hello world" running on Qemu. That is the entry point to the
BSP and as Chris pointed out, there is a fair amount of work just
to ensure you can do prints to the optional video and later serial port.

Then that can be hooked to initialize RTEMS. Implement the context
switch code using setjmp/longjmp as guides.

With the idle thread that simulates a clock tick, you can run a lot of
the tests.

Then deal with the interrupt controller and clock tick.

Then add COM1.

All that should be doable and testable on qemu.

> >> > - Are there any issues I've completely overlooked? Something I've
> >> > oversimplified / that I may not realize the scope / difficulty of?
> >
> >> Getting boot to work properly may be harder than you anticipate.
> >
> > That's a good point. I've made the target for phase 1 about getting stub
> > code there, boot/init code started, and patching the x86_64 tools up to
> > have them be feature-complete. (It's hard to gauge if that's a
> satisfactory
> > goal given that I'm not quite sure of the current status of the tools -
> > this is why I'm hoping to resolve this ASAP.)
> >
> > Would you let me know if the deliverables seem more evenly distributed
> and
> > realistic now?
> >
>
> It does. I think Phase 3 remains light. I'd encourage you to flesh out
> the plan for one of the "bonus" areas for this phase. That way, if you
> reach it, you will be prepared to undertake it without having to think
> too hard about the design aspects.
>
> >> Doing the ISR right means implementing the APIC support in a proper way.
> >> I think it will be a good idea for you to address SMP issues together
> >> with the UP implementation.
> >
> >
> > I agree, but I'd rather not commit to SMP support since that sounds like
> it
> > might be too much - I can't know that, of course, but I think I'd rather
> > keep it a bonus activity that I'll be able to pull in when I'm more in
> the
> > swing of things and better able to gauge the effort required.
>
>
+1

> >> > - It seems like Chris (cc'd) owns the x86_64 ticket - would Chris be a
> >> > potential mentor, or is ticket ownership not indicative of who the
> > mentor
> >> > might be?
> >
> >> Yes, Chris or Joel are likely mentors, unless another interested party
> > pops up.
>
> This project will likely require help from multiple mentors with Chris
and I being the official mentor pair.

> > I see! Do mentors usually mentor more than one student?
> >
>
> Some do.
>
> >> >
> >> > Misc:
> >> >
> >> > - I noticed that this project has been proposed in the past, at least
> >> > twice. Is there any constructive criticism from the proposals back
> then
> >> > that I could learn from?
> >
> >> Not really. The previous proposals were weak, and this project was not
> >> a high priority back then.
> >
> > Ah. Is there anything I can do to strengthen my proposal, in that case,
> > besides the feedback you've already provided? I do already plan to tackle
> > more tickets as time permits / get a head start on fixing / verifying the
> > x86_64 tools up. Is there anything else I should also be doing? Any other
> > resources I should be looking at?
> >
> > I just want to make sure that I know what I'm getting into and that you
> > guys aren't making a blind bet - anything I can do to prove to you and me
> > that I'm actually capable of handling this task would be immensely
> helpful.
> >
> >
> >> > - In the proposals, I've left some tasks about the x86_64 rtems-tools
> >> > highlighted in red because I'm hoping to test the tools before the
> > proposal
> >> > deadline to have a clearer idea for the timeline. The ticket[1] lists
> > some
> >> > tasks regarding the tools, but I'm not sure what the status of them is
> > yet,
> >> > or how to carry the tasks out quite yet. I aim to tackle this as soon
> as
> >> > possible, but if you can provide any guidance, I'd appreciate that.
> >> >
> >
> >> The x86_64 tools have a recipe in RSB, you can give it a try. The
> >> tasks identified there are in two categories:
> >> 1. GCC multilib support for FPU -- You should ask Joel to look into
> >> this for you. :)
> >
> > @Joel (cc'd) would you mind doing this? If you're busy / don't want to
> > (:P), would you mind letting me know how I can do it myself?
>
> Assuming you can handle the newlib additions, I will try to be the point
person for gcc, gdb, and binutils issues.

I don't know the multilib requirements at this point.

> > I'd like to dig into the tools as soon as possible because it seems like
> it
> > has the potential to significantly influence my timeline for this
> project,
> > and knowing in advance I'll be better equipped to commit the right
> amount.
> >
>
> The reason I suggest Joel might look is because touching GCC code is a
> bit of a hassle (the first time).
>

x86_64 tools are built by the RSB. I think the tool situation is OK except
for
the newlib details below.

>> 2. Newlib support for setjmp/longjmp, and anything else that should be
> >> in the libc. You should do this. Join newlib mailing list, check out
> >> the source, and find the current i386 and x86_64 implementations.
> >> (Hint: newlib.git/newlib/libc/machine/[i386 x86_64]).
>

that
there is no newlib/libc/machine/x86_64 subdirectory so you definitely have
to bring over setjmp/longjmp from FreeBSD.

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=tree;f=newlib/libc/machine;h=c554c10f50be1a01a967ed972ec55b03d1efbb10;hb=HEAD

Usually you also want CPU specific mem* and str* implementations for speed
so anything FreeBSD has should be brought into newlib. I think it is under
the
amd64 directory here.

https://github.com/freebsd/freebsd/tree/master/lib/libc

>
>

> >> 3. TLS. There are multiple ways to implement it. I don't know what is
> >> preferred for this. See https://www.akkadia.org/drepper/tls.pdf for a
> >> thorough background.
> >
> >
> > Thank you for the detailed resources! I'll add them to the project ticket
> > as well for future reference.
> >
> > P.S. - I'd also like to say congrats to all the maintainers for having
> such
> > a splendid community! It feels great to be a part of such a healthy
> > open-source ecosystem!
> >
> >> > Thanks!
> >> >
> >> > [1] https://devel.rtems.org/ticket/2898#Tools
> >> > _______________________________________________
> >> > devel mailing list
> >> > devel at rtems.org
> >> > http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180317/db41843d/attachment-0001.html>