2012/4/14 Jeremy Bennett <[email protected]> > On Sat, 2012-04-14 at 04:15 +0100, Julius Baxter wrote: > > 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 Julius, > > I put some explicit details on the process for Or1ksim. This is based on > our common practice for some time, and is similar to other community > based projects. > > Assuming this also works for the RTL, you I presume are a maintainer of > the OR1200 project, so if you OK it, you or anyone with > "write-after-approval" permission can commit it. It would be useful to > agree who the maintainers are for the OR1200 RTL and spec and who has > "write-after-approval" - we need a MAINTAINERS file in the OR1200 > directory. Only thing to avoid is approving your own patches. > > <snip> > > > > 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. > > OK - ABI clarifications, not changes. > > > 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... > > Sounds good. It's what Wiki "talk" pages are for. > > > Jeremy > > -- > Tel: +44 (1590) 610184 > Cell: +44 (7970) 676050 > SkypeID: jeremybennett > Email: [email protected] > Web: www.embecosm.com > > _______________________________________________ > Openrisc mailing list > [email protected] > http://lists.opencores.org/listinfo/openrisc > > > _______________________________________________ > OpenRISC mailing list > [email protected] > http://lists.openrisc.net/listinfo/openrisc >
Hi all, Just wanted to inform that I have branched out rev 794 to an or1200_rel3 branch. I have started to identify the changes since or1200_rel2 and put in a ChangeLog. This will probably take a while, since there are a lot of stuff that has been changed since the last release, but it will get there eventually. -- 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
