<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Mar 18, 2018 5:37 AM, "Gedare Bloom" <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="elided-text">On Sat, Mar 17, 2018 at 2:32 PM, Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<br>
><br>
><br>
> On Sat, Mar 17, 2018 at 1:09 PM, Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br>
>><br>
>> On Sat, Mar 17, 2018 at 11:58 AM, Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a>><br>
>> wrote:<br>
>> > First off, thank you so much for the prompt and detailed response! I<br>
>> > really<br>
>> > appreciate the help!<br>
>> ><br>
>> > On Sat, Mar 17, 2018 at 6:46 PM Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br>
>> ><br>
>> >> On Sat, Mar 17, 2018 at 2:24 AM, Amaan Cheval <<a href="mailto:amaan.cheval@gmail.com">amaan.cheval@gmail.com</a>><br>
>> > wrote:<br>
>> >> > Hey everyone!<br>
>> >> ><br>
>> >> > Here's a link to a draft of my proposal (also shared through the GSoC<br>
>> >> > website, and linked to on the wiki):<br>
>> >> ><br>
>> ><br>
>> > <a href="https://docs.google.com/document/d/1X79Yj0DNqvaDFqpJMUX4gF3WC550GDvVDS5QufvAnFE/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/<wbr>document/d/<wbr>1X79Yj0DNqvaDFqpJMUX4gF3WC550G<wbr>DvVDS5QufvAnFE/edit?usp=<wbr>sharing</a><br>
>> >> ><br>
>> >> > I'd appreciate all comments - even if you're just skimming, let me<br>
>> >> > know<br>
>> > if<br>
>> >> > you have something to say!<br>
>> >> ><br>
>> >> > I have a few questions too, which I'd appreciate help with:<br>
>> >> ><br>
>> >> > Regarding the proposal:<br>
>> >> ><br>
>> >> > - Does it seem like I'm committing too little / too much?<br>
>> ><br>
>> >> I don't think you have work planned in a good way. The scope of the<br>
>> >> second half is light, while the first half may be heavy. It is OK to<br>
>> >> have schedule slip, but it is better if you can try to balance the<br>
>> >> work over the phases. Also, note that GSoC is now a three-thirds<br>
>> >> instead of two-halves timeline.<br>
>> ><br>
>> > Noted. I've revised it a bit (same link). Would you mind having another<br>
>> > look?<br>
>><br>
><br>
> I have always thought the first part of this project would be to get<br>
> an UEFI "hello world" running on Qemu. That is the entry point to the<br>
> BSP and as Chris pointed out, there is a fair amount of work just<br>
> to ensure you can do prints to the optional video and later serial port.<br>
><br>
> Then that can be hooked to initialize RTEMS. Implement the context<br>
> switch code using setjmp/longjmp as guides.<br>
><br>
> With the idle thread that simulates a clock tick, you can run a lot of<br>
> the tests.<br>
><br>
> Then deal with the interrupt controller and clock tick.<br>
><br>
> Then add COM1.<br>
><br>
> All that should be doable and testable on qemu.<br>
><br>
>><br>
>> >> > - Are there any issues I've completely overlooked? Something I've<br>
>> >> > oversimplified / that I may not realize the scope / difficulty of?<br>
>> ><br>
>> >> Getting boot to work properly may be harder than you anticipate.<br>
>> ><br>
>> > That's a good point. I've made the target for phase 1 about getting stub<br>
>> > code there, boot/init code started, and patching the x86_64 tools up to<br>
>> > have them be feature-complete. (It's hard to gauge if that's a<br>
>> > satisfactory<br>
>> > goal given that I'm not quite sure of the current status of the tools -<br>
>> > this is why I'm hoping to resolve this ASAP.)<br>
>> ><br>
>> > Would you let me know if the deliverables seem more evenly distributed<br>
>> > and<br>
>> > realistic now?<br>
>> ><br>
>><br>
>> It does. I think Phase 3 remains light. I'd encourage you to flesh out<br>
>> the plan for one of the "bonus" areas for this phase. That way, if you<br>
>> reach it, you will be prepared to undertake it without having to think<br>
>> too hard about the design aspects.<br>
>><br>
>> >> Doing the ISR right means implementing the APIC support in a proper<br>
>> >> way.<br>
>> >> I think it will be a good idea for you to address SMP issues together<br>
>> >> with the UP implementation.<br>
>> ><br>
>> ><br>
>> > I agree, but I'd rather not commit to SMP support since that sounds like<br>
>> > it<br>
>> > might be too much - I can't know that, of course, but I think I'd rather<br>
>> > keep it a bonus activity that I'll be able to pull in when I'm more in<br>
>> > the<br>
>> > swing of things and better able to gauge the effort required.<br>
>><br>
><br>
> +1<br>
><br>
>><br>
>> >> > - It seems like Chris (cc'd) owns the x86_64 ticket - would Chris be<br>
>> >> > a<br>
>> >> > potential mentor, or is ticket ownership not indicative of who the<br>
>> > mentor<br>
>> >> > might be?<br>
>> ><br>
>> >> Yes, Chris or Joel are likely mentors, unless another interested party<br>
>> > pops up.<br>
>><br>
> This project will likely require help from multiple mentors with Chris<br>
> and I being the official mentor pair.<br>
><br>
>><br>
>> > I see! Do mentors usually mentor more than one student?<br>
>> ><br>
>><br>
>> Some do.<br>
>><br>
>> >> ><br>
>> >> > Misc:<br>
>> >> ><br>
>> >> > - I noticed that this project has been proposed in the past, at least<br>
>> >> > twice. Is there any constructive criticism from the proposals back<br>
>> >> > then<br>
>> >> > that I could learn from?<br>
>> ><br>
>> >> Not really. The previous proposals were weak, and this project was not<br>
>> >> a high priority back then.<br>
>> ><br>
>> > Ah. Is there anything I can do to strengthen my proposal, in that case,<br>
>> > besides the feedback you've already provided? I do already plan to<br>
>> > tackle<br>
>> > more tickets as time permits / get a head start on fixing / verifying<br>
>> > the<br>
>> > x86_64 tools up. Is there anything else I should also be doing? Any<br>
>> > other<br>
>> > resources I should be looking at?<br>
>> ><br>
>> > I just want to make sure that I know what I'm getting into and that you<br>
>> > guys aren't making a blind bet - anything I can do to prove to you and<br>
>> > me<br>
>> > that I'm actually capable of handling this task would be immensely<br>
>> > helpful.<br>
>> ><br>
>> ><br>
>> >> > - In the proposals, I've left some tasks about the x86_64 rtems-tools<br>
>> >> > highlighted in red because I'm hoping to test the tools before the<br>
>> > proposal<br>
>> >> > deadline to have a clearer idea for the timeline. The ticket[1] lists<br>
>> > some<br>
>> >> > tasks regarding the tools, but I'm not sure what the status of them<br>
>> >> > is<br>
>> > yet,<br>
>> >> > or how to carry the tasks out quite yet. I aim to tackle this as soon<br>
>> >> > as<br>
>> >> > possible, but if you can provide any guidance, I'd appreciate that.<br>
>> >> ><br>
>> ><br>
>> >> The x86_64 tools have a recipe in RSB, you can give it a try. The<br>
>> >> tasks identified there are in two categories:<br>
>> >> 1. GCC multilib support for FPU -- You should ask Joel to look into<br>
>> >> this for you. :)<br>
>> ><br>
>> > @Joel (cc'd) would you mind doing this? If you're busy / don't want to<br>
>> > (:P), would you mind letting me know how I can do it myself?<br>
>><br>
> Assuming you can handle the newlib additions, I will try to be the point<br>
> person for gcc, gdb, and binutils issues.<br>
><br>
> I don't know the multilib requirements at this point.<br>
><br>
>><br>
>> > I'd like to dig into the tools as soon as possible because it seems like<br>
>> > it<br>
>> > has the potential to significantly influence my timeline for this<br>
>> > project,<br>
>> > and knowing in advance I'll be better equipped to commit the right<br>
>> > amount.<br>
>> ><br>
>><br>
>> The reason I suggest Joel might look is because touching GCC code is a<br>
>> bit of a hassle (the first time).<br>
><br>
><br>
> x86_64 tools are built by the RSB. I think the tool situation is OK except<br>
> for<br>
> the newlib details below.<br>
><br>
>> >> 2. Newlib support for setjmp/longjmp, and anything else that should be<br>
>> >> in the libc. You should do this. Join newlib mailing list, check out<br>
>> >> the source, and find the current i386 and x86_64 implementations.<br>
>> >> (Hint: newlib.git/newlib/libc/<wbr>machine/[i386 x86_64]).<br>
><br>
><br>
> that<br>
> there is no newlib/libc/machine/x86_64 subdirectory so you definitely have<br>
> to bring over setjmp/longjmp from FreeBSD.<br>
><br>
> <a href="https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=tree;f=newlib/libc/machine;h=c554c10f50be1a01a967ed972ec55b03d1efbb10;hb=HEAD" rel="noreferrer" target="_blank">https://sourceware.org/git/<wbr>gitweb.cgi?p=newlib-cygwin.<wbr>git;a=tree;f=newlib/libc/<wbr>machine;h=<wbr>c554c10f50be1a01a967ed972ec55b<wbr>03d1efbb10;hb=HEAD</a><br>
><br>
<br>
</div>There is an x86_64 subdirectory there.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">I missed that on my phone. It has setjmp, longjmo and some mem* methods. So there should be no tool work unless we need a multilib.</div><div dir="auto"><br></div><div dir="auto">That sets the project up to getting to hello world as a first major milestone.</div><div dir="auto"><br></div><div dir="auto">FYI one step I do for new ports is to get to the point where I can link all tests with stubs or first quick cuts at the port and bsp. </div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="elided-text"><br>
> Usually you also want CPU specific mem* and str* implementations for speed<br>
> so anything FreeBSD has should be brought into newlib. I think it is under<br>
> the<br>
> amd64 directory here.<br>
><br>
> <a href="https://github.com/freebsd/freebsd/tree/master/lib/libc" rel="noreferrer" target="_blank">https://github.com/freebsd/<wbr>freebsd/tree/master/lib/libc</a><br>
><br>
>><br>
>><br>
><br>
><br>
>><br>
>> >> 3. TLS. There are multiple ways to implement it. I don't know what is<br>
>> >> preferred for this. See <a href="https://www.akkadia.org/drepper/tls.pdf" rel="noreferrer" target="_blank">https://www.akkadia.org/<wbr>drepper/tls.pdf</a> for a<br>
>> >> thorough background.<br>
>> ><br>
>> ><br>
>> > Thank you for the detailed resources! I'll add them to the project<br>
>> > ticket<br>
>> > as well for future reference.<br>
>> ><br>
>> > P.S. - I'd also like to say congrats to all the maintainers for having<br>
>> > such<br>
>> > a splendid community! It feels great to be a part of such a healthy<br>
>> > open-source ecosystem!<br>
>> ><br>
>> >> > Thanks!<br>
>> >> ><br>
>> >> > [1] <a href="https://devel.rtems.org/ticket/2898#Tools" rel="noreferrer" target="_blank">https://devel.rtems.org/<wbr>ticket/2898#Tools</a><br>
>> >> > ______________________________<wbr>_________________<br>
>> >> > devel mailing list<br>
>> >> > <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
>> >> > <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
><br>
><br>
</div></blockquote></div><br></div></div></div>