On Thu, Apr 12, 2012 at 4:25 PM, Jeremy Bennett <[email protected]> wrote: > 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 This is true - we've been getting some good stuff from the likes of Ruben and John and others and I've been a bit remiss in not finding the time to properly push them through the process and get them into the repository. It's been mainly a matter of time, but also I'm not certain of the process for this stuff. I mean, we get patches and they look fine to me - is my ACK enough for me to push it onto the repo? Have we established this yet? I'd like to think so - this will make me more likely to apply stuff which looks good and runs OK as soon as I get around to having a go at it (which is usually within a day for RTL patches.) > > 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? > I think we came up with some changes for versioning which we were happy with, and which shouldn't change the ABI. Same with the GPR0 clarifications, and the SR[DSX] behaviour during system call, etc. The issue here is not the OR1200, it's updating the arch spec. Plus, we'll need a bit of a synchronous update of both the models (RTL and or1ksim) and arch spec to implement the versioning stuff. Perhaps I can just collate the necessary changes, publish something to the mailing list covering the changed text in the arch spec and go ahead and update the "draft" spec in the repo. (Something needs to be done about that, too.) I think we got bogged down in discussion of a text-based format for the arch spec document (like the OR1200 has now) last time and how we're going to handle changes to it, but I say for now i'll work on the updated text and just post it to the mailing list for ACK. But as far as I recall, we had agreed on solutions. Maybe a wiki page on this... >> 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. Totally. As I said, I think I've been a bit remiss in organising releases of things like tool chains and RTL, and have instead focussed on playing with the development of newer versions of these things. > > My two-pennyworth. Split out ORSoC as a separate project (just like > minsoc), so you can focus on releasing the processor. > > It also makes sense to split out the tool chain, libraries and operating > systems as a separate or1k-software project. > I agree, we need to split things out. I think we covered this in another thread, but despite calls for it to remain under the one repository, I think if they're separate it'll be easier to manage (smaller repositories). Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
