x86_64 port and BSP (GSoC 2018)

Mon Mar 19 07:36:07 UTC 2018

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 <joel at rtems.org> wrote:

>
>
> On Mar 18, 2018 5:37 AM, "Gedare Bloom" <gedare at rtems.org> wrote:
>
> 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.
>
>
> 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 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/20180319/c341b0be/attachment-0001.html>