x86_64 port and BSP (GSoC 2018)

Mon May 14 11:14:24 UTC 2018

Regarding naming, how about we settle on something like
"bsps/amd64/amd64_generic", borrowing from how the riscv target is
structured?

On Tue, May 8, 2018 at 9:02 AM, Chris Johns <chrisj at rtems.org> wrote:
> 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