x86_64 port and BSP (GSoC 2018)

Thu May 3 07:09:01 UTC 2018

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.

> 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.

> 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.

> 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?

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.

> > 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!

> Chris

> >
> > Using this configure command:
> >
> > ../kernel/configure --prefix=$HOME/bin/rtems/5-x86_64
> > --target=x86_64-rtems5 --enable-rtemsbsp=no_bsp --enable-posix
> > --enable-tests --enable-maintainer-mode
> >
> > No errors were logged while running "make", and there are now 568
"*.exe"s
> > in the ./x86_64-rtems5/c/no_bsp/testsuites folders (using "find").
> >
> > Next up:
> >
> > - Restructure to use bsps dir
> > - Figure out specifics of linkcmds and bsp_specs (currently it's just a
> > hacky mashup of the one in no_bsp and pc386)
> > - Work out how
> >
> > [1] https://lists.rtems.org/pipermail/devel/2018-April/020883.html
> > [2] https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00007.html
> >