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. >> 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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
