x86_64 port and BSP (GSoC 2018)

Chris Johns chrisj at rtems.org
Thu May 3 00:25:56 UTC 2018


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?

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.

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.

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

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
> 



More information about the devel mailing list