x86_64 port and BSP (GSoC 2018)

[Chris Johns]

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.

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

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.

Chris