On 12/18/12, Olof Kindgren <[email protected]> wrote: > 2012/12/18 Jeremy Bennett <[email protected]>: >> On Mon, 2012-12-17 at 21:28 +0000, Julius Baxter wrote: >>> --- >>> newlib/libc/machine/or1k/include/spr-defs.h | 9 +++++++++ >>> 1 files changed, 9 insertions(+), 0 deletions(-) >>> >>> diff --git a/newlib/libc/machine/or1k/include/spr-defs.h >>> b/newlib/libc/machine/or1k/include/spr-defs.h >>> index 09ae4fa..54e6ec5 100644 >>> --- a/newlib/libc/machine/or1k/include/spr-defs.h >>> +++ b/newlib/libc/machine/or1k/include/spr-defs.h >>> @@ -201,6 +201,15 @@ >>> #define SPR_VR2_CPUID_OFF 24 >>> #define SPR_VR2_VER_OFF 0 >>> >>> +/* >>> + * CPU implementation unique identifiers >>> + */ >>> +#define SPR_VR2_CPUID_OR1KSIM 0x00 >>> +#define SPR_VR2_CPUID_MOR1KX 0x01 >>> +#define SPR_VR2_CPUID_OR1200 0x12 >>> +#define SPR_VR2_CPUID_ALTOR32 0x32 >>> +#define SPR_VR2_CPUID_OR10 0x10 >>> + >>> /* >>> * Bit definitions for the Architecture Version register >>> * >> >> Hi Julius, >> >> This file also appears (in multiple places - sigh) in Or1ksim. Will you >> bring that in to line? >> >> Best wishes, >> >> >> 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.openrisc.net/listinfo/openrisc > > My thoughts exactly. I've been thinking that we maybe should create an > or1k-headers or an or1k-utilitues package that our libc > implementations, or1ksim and other things can depend on. Not sure how > other architectures handle this.
Hey guys There's a reason I'm updating this copy. It's because this one gets installed with the newlib tool chain and is available to everything which uses the cross compiler. So we can remove all copies in things like ORPSoC, and other software libraries and rely on this copy. Although, what about other things like the Linux kernel, U-boot, etc. can they use the copy installed with the newlib tool chain? Then there's the issue of the one in or1ksim, which is used to compile the simulator itself. We could either figure out how to point to the one in the cross compiler install, or just maintain another copy, which should be fine to do. So yes, I intend on updating the one in or1ksim to be identical to this one. > > Meanwhile, I think we should do as with or1200 and keep our copies in > sync. I tried to sync them up a while ago, but IIRC there was > something that prevented me from making them identical across or1ksim > and newlib. If changes are made to our spr-defs, we should also make > sure that the bug reports on the topic are up to date. There's a couple of timer definitions which I think got out of step, but that should be easy enough to fix. Keeping the copies in sync should be easy enough to do. Cheers Jules _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
