x86_64 port and BSP (GSoC 2018)

Sun Mar 18 10:37:00 UTC 2018

On Sat, Mar 17, 2018 at 2:32 PM, Joel Sherrill <joel at rtems.org> wrote:
>
>
> 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/1X79Yj0DNqvaDFqpJMUX4gF3WC550GDvVDS5QufvAnFE/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
>

There is an x86_64 subdirectory there.

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