The "Pragmatic Programmer" was written by two guys who have done enough firmware projects to understand what works and what doesn't.
Their main rule is that you NEVER copy data in a database. Everything is stored in one designated location and anyone who needs it has to get it from there. Openrisc violates this rule and your post is a good example of the troubles that this can create. minsoc did it right in that they grab their processor from it's original location. Orpsocv2 messed up by making a copy. I think that there may even be some others around as well. We must fix this but doing so will be a challenge. We must get all known fixes put back into the original or1200 along with a test suite that proves that it works. Then oprsocv2 and others must remove their copies and start using the original. I am willing to work on this, Anyone else? John Eaton On Tue, Jan 17, 2012 at 6:46 AM, [email protected] < [email protected]> wrote: > Hi all: > > I'm looking at this patch, applied not long ago: > > ORPSoC: Fix Bug 76 - Incorrect unsigned integer less-than compare with > COMP3 option enabled > OR1200 RTL fix and software test added. > > This patch landed in the OpenCores Subversion repository at this location: > > /openrisc/trunk/orpsocv2/rtl/verilog/or1200 > > However, I just realised that there is another copy of the OpenRISC core > RTL at this location: > > /openrisc/trunk/or1200/rtl/verilog > > This copy does not seem to have been patched though. > > I think I've read in this forum that there is a similar issue with the GCC > toolchain, there are at least 2 copies, is that right? > > I am confused about which copies I should be using at the moment. > > Thanks, > R. Diez > > > > > _______________________________________________ > OpenRISC mailing list > [email protected] > http://lists.openrisc.net/listinfo/openrisc > >
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
