x86_64 port and BSP (GSoC 2018)

[Amaan Cheval]

On Fri, May 4, 2018 at 7:03 AM Chris Johns <chrisj at rtems.org> wrote:

> On 03/05/2018 17:09, Amaan Cheval wrote:
> > On Thu, May 3, 2018 at 5:56 AM Chris Johns <chrisj at rtems.org> wrote:
> >
> >> On 01/05/2018 23:09, Amaan Cheval wrote:
> >>> Quick update: My x86_64 stub port compiles and can be linked to all
> > default
> >>> tests now! _dance_
> >>>
> >>> I've pushed the stub port for the x86_64 to my fork on Github; the
> > commits
> >>> are horribly messy (I did most of the work aiming for the stub to be
one
> >>> commit, then later I realized several commits would make more sense
for
> >>> when I'll have to rebase and catch up with master - TL;DR: ignore the
> >>> commits, I'll squash and make them make more sense later).
> >>>
> >>>
> >
https://github.com/AmaanC/rtems/tree/ac/stub-x86-link-tests-pre-bspreorg-bak
> >>>
> >
> >> Thanks. Updating to master would be good, lots has changed.
> >
> >> Why ...
> >
> >>   bsps/x86_64/i386
> >>   bsps/x86_64/i386/pc386
> >
> >> .. ? Can the BSP's layout be simplified to something flatter?
> >
> >
> > Definitely - the work so far has been very hacky, leaving a mess all
over
> > the place to just make note of issues that I'll need to look into in
more
> > detail. With the rebase to master, I'll be making these changes with a
lot
> > more thought.

> Excellent and thanks.

> >
> >> I see FreeBSD has amd64, x86 and i386 in src/sys. I do not know what
the
> >> differences are? I run FreeBSD amd64 on Intel devices.
> >
> >
> > Not sure of the differences, really. I noticed that earlier too, but
I'll
> > have to dig into that later.
> >

> I briefly looked and it seems the amd64 was more complete.

> Do you think we should have bsps/x86_64/amd64 as the BSP?

> I think the more generic name of 'amd64' is better than 'pc' plus it
aligns us
> with the naming other platforms use.


Given that amd64/x86_64 refer to the ISAs, not specific processors, I think
it's up between these for me:

- amd64/pc
- x86_64/pc

I don't feel strongly about this, but I think the generic "x86_64/pc" may
be more technically accurate given that there are some very subtle
differences between x86-64 and AMD64, and this port will be tested on
generic 64-bit Intel processors.

https://en.wikipedia.org/wiki/X86-64#Differences_between_AMD64_and_Intel_64

What do you think?

> >> Is there a build of x86_64 hardware that is _not_ a PC? I think it
makes
> > sense
> >> to assume for now we support just a PC and so we can have x86_64/pc. To
> > clarify
> >> this statement, I am sure there are a number VME, CompactPCI and other
> >> industrial boards which I suspect will be a PC architecture to the
> > operating
> >> systems running on them.
> >
> >> I would prefer you commit files from the i386/.. tree as they are
merged,
> > tested
> >> and cleaned up rather than dumping in the existing PC BSP into the new
> > BSP. For
> >> example I would prefer we consider:
> >
> >>   https://github.com/freebsd/freebsd/tree/master/sys/dev/vt
> >
> >> for the console for this BSP. The code will have FreeBSD kernel
> > dependencies
> >> which can be wrapped or compiled out. Please consider following the
rules
> > we use
> >> for adding and changing FreeBSD source in libbsd, it would help us
track
> > FreeBSD
> >> in the future. I would also consider adding this code to x86_64/dev/vt
> > and have
> >> the x86_64/pc BSP reference it.

What do you think about x86_64/contrib/dev/vt etc. instead and then have
x86_64/pc reference it? Sounds good to me.

If that complicates things too much with the build system, I'll make sure
to follow the guidelines here, at least:
https://devel.rtems.org/wiki/Developer/Coding/ThirdPartyCode

Would you let me know if there's anything more to keep in mind than
mentioned there?

Also, I'm not quite sure what belongs in libbsd vs. in the rtems repo under
a specific BSP - do you foresee me needing to make any contributions to
libbsd during the course of this project? I can't think of anything, since
even the FreeBSD code I'll adapt will likely be pretty arch/BSP specific,
but I figured I'd confirm.

> >
> >> Please check the existing shared BSP code and use what is there before
> > anything
> >> else. The i386/pc BSP is old and not a good reference base.
> >
> >
> > Got it. Sorry about that! Is there any one particular BSP which does
serve
> > as a good reference base?

> The arm bsps and the leon3 are important to RTEMS given the user base so
I would
> have a look at those.

> > I only had i386/pc386 dumped in there as a copy to easily make
> > modifications to and copy from if required - the real code I'll be
working
> > on (and will need to clean up a fair bit) is x86_64/no_bsp right now. I
> > just wanted that made as a stub that I can start working on ASAP, as
> > opposed to a well thought out version that will need an undetermined
time
> > to reach a stage where it can be compiled fully and tested.

> OK and thanks.

> >
> >>> It depends on the x86_64 tools being updated, so we need the patch
I've
> >>> already made[1] to rtems-source-builder, along with one I'll make
after
> > my
> >>> patch to gcc[2] adding crti.o and crtn.o is accepted.
> >
> >> Can you please resend [1] with the https://gcc.gnu.org/ reference
being as
> >> simple as possible to the commit? I think you sent me something which
was
> >> smaller and simpler.
> >
> >
> > What I sent was basically explaining why I can't simply reference the
> > commit - the reason being that the commit changes the ChangeLog file as
> > well:
> >
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff_plain;h=602fa1e9d3ea5e87d4d6e17e3e91fc2647e42da3
> >
> > Given that the gcc 7.3 release we currently use doesn't include the
> > ChangeLog reference lines after, the patch fails to apply. This means we
> > need to use just the file-level patch, hence the blobdiff I've used. The
> > commit message includes a link to the commit, but I can update the cfg
> > file's comment to also include a link to the commit if that helps. Let
me
> > know!

> Oh I see and sorry I did not understand this before. I will push the
patch as
> posted. Thank you for the patch and nice explanation.


No worries, cheers! Thanks for committing it!

> Chris