Thanks for checking the tool status! TLS support for the tool seems okay to me as well - I see the TLS program header and the "T" flag for the ".tbss" section header, as you'd expect in the ELF. I haven't looked into the run-time support for TLS in RTEMS yet - is there something I need to dig into there?
How do we determine if we need multilib support? > 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. I've added a few bullets about SMP support and it's SMP-specific APIC related tasks. > 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. That's a good tip! I've added that to the phase 1 deliverable, since it seems like an important step - I'll aim to get here much sooner, though. > 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. The UEFI "hello world" would be achievable through a minimal BSP (primarily boot/init code) and stubs for the rest (console, idle thread clock, fake context-switching & ISR handling), right? > All that should be doable and testable on qemu. Sweet! A question about hardware requirements; how do you guys usually test and debug hardware problems? Is there any equipment I'll likely need or should look into (JTAG)? Besides, what should I verify about the computers I do have, besides them having UEFI firmware? On Sun, Mar 18, 2018 at 9:37 PM Joel Sherrill <j...@rtems.org> wrote: > > > On Mar 18, 2018 5:37 AM, "Gedare Bloom" <ged...@rtems.org> wrote: > > 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. > > > 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. > > That sets the project up to getting to hello world as a first major > milestone. > > 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. > > > > 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
