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. > 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. > 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? 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. > > 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! > Chris > > > > Using this configure command: > > > > ../kernel/configure --prefix=$HOME/bin/rtems/5-x86_64 > > --target=x86_64-rtems5 --enable-rtemsbsp=no_bsp --enable-posix > > --enable-tests --enable-maintainer-mode > > > > No errors were logged while running "make", and there are now 568 "*.exe"s > > in the ./x86_64-rtems5/c/no_bsp/testsuites folders (using "find"). > > > > Next up: > > > > - Restructure to use bsps dir > > - Figure out specifics of linkcmds and bsp_specs (currently it's just a > > hacky mashup of the one in no_bsp and pc386) > > - Work out how > > > > [1] https://lists.rtems.org/pipermail/devel/2018-April/020883.html > > [2] https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00007.html > > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel