On Sat, Mar 17, 2018 at 2:32 PM, Joel Sherrill <j...@rtems.org> wrote: > > > On Sat, Mar 17, 2018 at 1:09 PM, Gedare Bloom <ged...@rtems.org> wrote: >> >> On Sat, Mar 17, 2018 at 11:58 AM, Amaan Cheval <amaan.che...@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 <ged...@rtems.org> wrote: >> > >> >> On Sat, Mar 17, 2018 at 2:24 AM, Amaan Cheval <amaan.che...@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@rtems.org >> >> > http://lists.rtems.org/mailman/listinfo/devel > > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
