On Fri, May 4, 2018 at 7:03 AM Chris Johns <chr...@rtems.org> wrote: > On 03/05/2018 17:09, Amaan Cheval wrote: > > On Thu, May 3, 2018 at 5:56 AM Chris Johns <chr...@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 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? > >> 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. 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? 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. > > > >> 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. No worries, cheers! Thanks for committing it! > Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
