x86_64 port and BSP (GSoC 2018)

Tue May 8 03:32:22 UTC 2018

On 05/05/2018 04:07, Amaan Cheval wrote:
> 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 would prefer we have a single BSP. If we reach a point these differences are
important I would be super impressed.

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

When I look at an OS I tend to get the amd64 build for any x86_64
implementation, maybe this is just my view of things.

These offer amd64 ...

http://mirror.internode.on.net/pub/ubuntu/releases/18.04/
http://mirror.internode.on.net/pub/FreeBSD/releases/
http://mirror.internode.on.net/pub/NetBSD/NetBSD-7.1.2/
http://mirror.internode.on.net/pub/debian/dists/Debian9.4/main/

CentOS and Fedora are different and offer x86_64:

http://mirror.internode.on.net/pub/centos/7.4.1708/isos/x86_64/
http://mirror.internode.on.net/pub/fedora/linux/releases/28/Everything/x86_64/

macOS (darwin) is x86_64:

$ uname -a
Darwin mohua 17.5.0 Darwin Kernel Version 17.5.0: Mon Mar  5 22:24:32 PST 2018;
root:xnu-4570.51.1~1/RELEASE_X86_64 x86_64

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

Contrib as opposed too what other type of sources? I think we will have a lot of
contributed code in this BSP given the mature base of existing code. My concern
is everything ends up under that directory. :)

The 'pc' name does tend to imply it only runs on a PC which may not or should
not be true. It will run on a minow board as well.

Joel do you have a view?

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

I do not know yet. I am sure we will discover things as we go.

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

Libbsd is a framework to support FreeBSD services on RTEMS. This BSP is about
the x86_64 support and what it needs to boot and run an RTEMS kernel. We need to
provide just enough to make this happen and to be self contained.

We may bring into the BSP tables, data or functions libbsd may need to access to
work but I feel that is for later if we get time. I am sure we will not get the
balance right at this point in time so while we should consider this it should
not be a priority for this effort.

Chris