> > > 2012/4/12 Jeremy Bennett <[email protected]> > >> On Thu, 2012-04-12 at 14:13 +0200, Olof Kindgren wrote: >> > Hi everyone, >> > >> > There are a lot of things going with or1200, and recently there have >> > been more patches than we have had time to deal with. I know myself >> > that it is frustrating to submit patches without anyone acknowledging >> > them. Some of the proposed changes are also potentially breaking the >> > sw/hw ABI, which means we have to be really careful when we apply >> > them. >> >> Hi Olof, >> >> Breaking (as opposed to extending/completing) the ABI is bad news. There >> are now various OpenRISC products out there, and this does nothing for >> credibility. >> >> What is it that will break the ABI? >> >> Well, on a second thought, I don't think there are any real ABI breakers > now, but some things could potentially cause problems. > If I remember correctly, Jonas said that the changes to the version > registers that Julius proposed could break the ABI. I don't remember the > details anymore though. Could Julius or Jonas fill in the gaps here? We > have also had a long discussion about the r0 behaviour, and the issue of > ABI problems came up there too. In this case though the proposed solution > wouldn't break the ABI, but there might come up other times when we > actually have to break the ABI. > > > My proposal is that we try to focus our efforts on releasing a new >> > or1200 rel3 (or is it rel4). We have been talking about this for quite >> > some time now, but not really gotten any closer to finalizing this. >> > Therefore I started a basic roadmap page on the wiki >> > http://opencores.org/or1k/OR1200_Roadmap and for now assigned three >> > tasks for the next release. I know that it's more fun to add new >> > features, but I think it's more important to have proper release now. >> > If no one else objects, I would be willing to step up as release >> > manager for this release. Feel free to add items to the wiki, but keep >> > them under unassigned tasks until we have discussed them publicly. The >> > three items listed under the next release should of course also be >> > discussed, but this is my initial proposal, and I think it is plenty >> > of work just to fix those items. >> >> Well done volunteering to manage this release! I'm sure Julius will >> appreciate that. >> >> My two-pennyworth. Split out ORSoC as a separate project (just like >> minsoc), so you can focus on releasing the processor. >> >> I would say that this is a separate issue that has more to do with the > repository structure. This proposal is only focused on a properly tagged > release of the or1200 RTL. > > Splitting out ORPSoC is another task on the agenda however. ORPSoCv3 uses > the upstream or1200 and lives in a separate repo so that part is already > done, and for now I think we should let orpsocv2 stay where it is. It's not > the largest component in the repo and therefore not the most important to > move right now. > > It also makes sense to split out the tool chain, libraries and operating >> systems as a separate or1k-software project. >> >> > Yes. This is something we should look at real soon, but that is also for a > separate thread. I also liked your idea of starting out with or1ksim. > > -- > Olof Kindgren > ______________________________________________ > ORSoC > Website: www.orsoc.se > Email: [email protected] > ______________________________________________ > FPGA, ASIC, DSP - embedded SoC design >
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
