Menu
▾
▴
linuxsh-dev
|
From: Stuart M. <stu...@st...> - 2002-02-27 23:54:16
|
Folks Following the release of an SH5 compiler and associated tools last week, I pleased to be able to say that we are also almost ready to release an SH5 Linux kernel. This work has been going for some time, in another group within ST, but it is only now that the tools are available, and the architecture is public, that we are able to release it. I say almost ready, because there are some last minute details to tidy up, but mainly because I'd like to get people's suggestions on where we should be putting this. First a bit of background: As far as a kernel is concerned, SH5 is not a variant of the current SH architecture, in the way that SH3 and SH4 are. It is a 64 bit processor, with more and wider registers, different caches, MMU, interrupt controller etc. The CPU supports two instruction sets, the new instruction set (called SH-Media) gives access to all the new facilities of the machine, however it also supports a second instruction set (SH-Compact) which is a subset of the SH4 instruction set, sufficient to support native execution of SH4 _user_ _mode_ binaries. This means that a new kernel must, at least in part, be written in SH-Media instructions. It could also use SH-Compact if desired, but we've chosen not to do this at the moment. And yes, Linux could support the native execution of SH4 binaries if somebody felt like doing the necessary work in the kernel. So for this reason we decided not to merge the SH5 code with the current SH3/4 kernel. We have created a new architecture called "sh5" in the kernel source code, which is completely separate from the current "sh" architecture. However it does share device drivers with the other SH devices, such as the SCIF. It could have been called sh64, but we decided against that as it is not really a 64 bit port - pointers and longs are still 32 bits. A full 64 bit port is still a possibility for the future. Work on this port started some time ago, and hasn't kept track with current kernel developments. So the port is still based on a 2.4.0-test4 kernel. One of the things we want to do in the not too distant future is upgrade to a more recent tree, but I'd rather release now and get people looking at it than wait any longer. So, the proposal: I'd like to get this code checked into a CVS repository on SourceForge as soon as possible. There are already several groups here who want access to the sources, so this is easier than just putting it up for FTP somewhere. Plus it allows other developers to join in as things develop. At the moment I think it may be better to create a new SourceForge project for this, rather than use the current LinuxSH one. This is mainly: - to try and reduce confusion - a lot of the current web content is not applicable to SH5, and adding qualifying statements would make it messy. - the kernel is currently only of interest to kernel hackers, its not ready for general consumption. - because the current SH5 code is based around the old kernel, and is still fairly immature, it doesn't make sense to put it in the "linux" directory in CVS. It could go in a separate directory in CVS though. - things are still very changable. Its quite possible major restructuring may still happen (renaming the architacture for example!), and we don't know at the moment how things will turn out. - I suspect the number of people interested in both ports is actually quite small - I may be wrong of course... and then at some point in the future when the kernel is more mature, and we know better what it will look like, we can think about merging it into the LinuxSH project. Comments please Stuart |
|
From: NIIBE Y. <gn...@m1...> - 2002-02-28 00:02:21
|
Congratulation, for the new adventure! I think that different repository makes sense at this time. I have a question (to Hitachi, perhaps, for us in Japan). Are there any (possibly cheap) eva board available? -- |
|
From: M. R. B. <mr...@0x...> - 2002-02-28 00:06:51
|
* NIIBE Yutaka <gn...@m1...> on Thu, Feb 28, 2002: >=20 > I have a question (to Hitachi, perhaps, for us in Japan). Are there > any (possibly cheap) eva board available? =46rom what I understand there is a looong waiting list :P. I guess ST is still trying to stabilize the SH5 core. M. R. |
|
From: Paul M. <le...@Ch...> - 2002-02-28 04:24:20
|
On Wed, Feb 27, 2002 at 11:54:02PM +0000, Stuart Menefy wrote: > Following the release of an SH5 compiler and associated tools last week, > I pleased to be able to say that we are also almost ready to release > an SH5 Linux kernel. >=20 Good to hear. Any idea when the SH8000's will be readily available? Speaking of the kernel, what's the status of your guys kgdb work? Are there only SH5 specific hacks and stubs in your tree? > This work has been going for some time, in another group within ST, but > it is only now that the tools are available, and the architecture is > public, that we are able to release it. >=20 Does this mean that any code that was developed using the NDA'd documentati= on can be pushed into CVS now? Also, are there any updates to the documentatio= n? If so, are these available without NDA? > I say almost ready, because there are some last minute details to tidy > up, but mainly because I'd like to get people's suggestions on where we > should be putting this. >=20 Since you're looking for comments and suggestions on how the source tree is done presently, is there some place where we can take a look at the tree the way it is now, so that more accurate feedback can be offered? > First a bit of background: >=20 > As far as a kernel is concerned, SH5 is not a variant of the current SH > architecture, in the way that SH3 and SH4 are. It is a 64 bit processor, > with more and wider registers, different caches, MMU, interrupt controller > etc. >=20 > The CPU supports two instruction sets, the new instruction set > (called SH-Media) gives access to all the new facilities of the machine, > however it also supports a second instruction set (SH-Compact) which > is a subset of the SH4 instruction set, sufficient to support native > execution of SH4 _user_ _mode_ binaries. This means that a new kernel > must, at least in part, be written in SH-Media instructions. It could > also use SH-Compact if desired, but we've chosen not to do this at the > moment. And yes, Linux could support the native execution of SH4 binaries > if somebody felt like doing the necessary work in the kernel. >=20 I suppose the use of SH-Media extensively makes the most sense for the init= ial port, but in the long run, doing as much as possibly in SH-Compact would probably be faster and cut down on the overall object/resultant kernel size= .. especially considering the differences in instruction sizes (and with -g turned on, saving as much space as possible is always a plus..). While this may not be worth thinking about right now, it still seems like something wo= rth looking into in the future.. > So for this reason we decided not to merge the SH5 code with the current > SH3/4 kernel. We have created a new architecture called "sh5" in the kern= el > source code, which is completely separate from the current "sh" > architecture. However it does share device drivers with the other SH > devices, such as the SCIF. >=20 > It could have been called sh64, but we decided against that as it > is not really a 64 bit port - pointers and longs are still 32 bits. > A full 64 bit port is still a possibility for the future. >=20 I'm not so sure that this is a good idea.. in the tradition of architecture naming schemes under linux things always follow the arch/arch64 approach. If the system is capable of sanely mapping things to 64-bit addresses witho= ut the system choking, then the arch64 thing seems to make more sense. If on t= he other hand, the system has issues with this, then it doesn't have much place in an arch64-type layout. From your indication of pointers being 32 bits, t= his would certainly seem to indicate that it's not ready for an sh64 convention. On the other hand, adding "sh5" completely goes against the natural order of things and should try to be avoided as vigorously as possible. While the SH5 might not follow typical SH3/4 convention, that hardly warrants the creation of a new arch directory. Under MIPS, many systems have completely different caches, MMU's, TLB handling, etc, etc. all of these things are dealt with i= n a rather sane fashion -- of which I'm trying to achieve the same goal with the SH tree for 2.5, though I'm still working on restructuring things. As long as the majority of things are done in SH-Compact, changes to things like entry.S should be rather minimalistic.. but it's hard to determine what the severity of the changes are without having any code to look at. > Work on this port started some time ago, and hasn't kept track with > current kernel developments. So the port is still based on a 2.4.0-test4 > kernel. One of the things we want to do in the not too distant future is > upgrade to a more recent tree, but I'd rather release now and get > people looking at it than wait any longer. >=20 Agreed, this seems like the best possible course of action. > So, the proposal: >=20 > I'd like to get this code checked into a CVS repository on SourceForge > as soon as possible. There are already several groups here who want > access to the sources, so this is easier than just putting it up for > FTP somewhere. Plus it allows other developers to join in as things > develop. >=20 > At the moment I think it may be better to create a new SourceForge > project for this, rather than use the current LinuxSH one. >=20 > This is mainly: > - to try and reduce confusion - a lot of the current web content is not > applicable to SH5, and adding qualifying statements would make it > messy. A lot of the LinuxSH website is out of date and needing to be revamped the = way it is. While it might not presently be the best place to discuss SH5, it certainly should be. If someone had the time to spend on cleaning up the website, that'd seem to be the best solution. Any volunteers? > - the kernel is currently only of interest to kernel hackers, its > not ready for general consumption. The 2.5 restructuring tree for the LinuxSH isn't suitable for mere mortals either, and shouldn't even be approached by anyone other then kernel hacker= s. Yet it sits in CVS just fine.=20 > - because the current SH5 code is based around the old kernel, and is > still fairly immature, it doesn't make sense to put it in the > "linux" directory in CVS. It could go in a separate directory in > CVS though. In my opinion, there isn't enough reason to divide this stuff out into a completely seperate project.. putting SH5 under its own module for the time being would be fine, but it would be nice to forward port this stuff to current 2.4, and merge it into the 2.4 branch of the drop-in tree, where it can then be used by everybody and the other module could be removed in its entirety. If there's interest in this, I'd have no problems taking care of updating t= he SH5 tree and merging it into the existing drop-in, if there are no other takers. > - things are still very changable. Its quite possible major > restructuring may still happen (renaming the architacture for example!= ), > and we don't know at the moment how things will turn out. I'd say concentrate on stable changes under the 2.4 branch if that's where this ends up going.. or just leave it in HEAD.. I'd prefer if major restructuring would be postponed until I'm done with the 2.5 restructuring= of the tree, otherwise we might end up duplicating efforts. Plus, it should ma= ke assimilating SH5 in a sane fashion a lot easier.. > and then at some point in the future when the kernel is more mature, > and we know better what it will look like, we can think about merging > it into the LinuxSH project. >=20 If you start maintaining it independantly of the LinuxSH project from the beginning, it's just going to be more of a nuisance when you try and do the merge later. At present, the code is in its infancy, things can still be changed, etc, etc. with these things in mind, it's the best time to merge t= his into the LinuxSH project and beat it into submission.. Either way.. lets have a look at the tree first, and then we can figure out what the best course of action might be. Or if anyone else has any similar insight on the matter, that could be helpful too. Regards, --=20 Paul Mundt <le...@ch...> |
|
From: Stuart M. <stu...@st...> - 2002-02-28 22:00:44
|
Folks On Wed, 27 Feb 2002 20:23:42 -0800 le...@Ch... wrote: > On Wed, Feb 27, 2002 at 11:54:02PM +0000, Stuart Menefy wrote: > > Following the release of an SH5 compiler and associated tools last week, > > I pleased to be able to say that we are also almost ready to release > > an SH5 Linux kernel. > > > Good to hear. Any idea when the SH8000's will be readily available? Short answer, I've no idea. SH8000 is Hitachi's part (and as fasr as I know is the only chip with an SH5 core at the moment). > Speaking of the kernel, what's the status of your guys kgdb work? Are there > only SH5 specific hacks and stubs in your tree? The kgdb stuff on www.linuxsh.st.com is for SH4 only. There is is currently no kgdb support in the SH5 tree. > > This work has been going for some time, in another group within ST, but > > it is only now that the tools are available, and the architecture is > > public, that we are able to release it. > > > Does this mean that any code that was developed using the NDA'd documentation > can be pushed into CVS now? Also, are there any updates to the documentation? > If so, are these available without NDA? Yep, all the docs which were used are now available without NDA. Boyd posted a note on how to get them a few months ago: http://sourceforge.net/mailarchive/forum.php?thread_id=261311&forum_id=5348 Unfortunatly SuperH still haven't posted them on their web site. > > I say almost ready, because there are some last minute details to tidy > > up, but mainly because I'd like to get people's suggestions on where we > > should be putting this. > > > Since you're looking for comments and suggestions on how the source tree is > done presently, is there some place where we can take a look at the tree the > way it is now, so that more accurate feedback can be offered? No. I'm just waiting for a couple of key updates from the developers, which they tell me will be available early next week. > > First a bit of background: > > > > As far as a kernel is concerned, SH5 is not a variant of the current SH > > architecture, in the way that SH3 and SH4 are. It is a 64 bit processor, > > with more and wider registers, different caches, MMU, interrupt controller > > etc. > > > > The CPU supports two instruction sets, the new instruction set > > (called SH-Media) gives access to all the new facilities of the machine, > > however it also supports a second instruction set (SH-Compact) which > > is a subset of the SH4 instruction set, sufficient to support native > > execution of SH4 _user_ _mode_ binaries. This means that a new kernel > > must, at least in part, be written in SH-Media instructions. It could > > also use SH-Compact if desired, but we've chosen not to do this at the > > moment. And yes, Linux could support the native execution of SH4 binaries > > if somebody felt like doing the necessary work in the kernel. > > > I suppose the use of SH-Media extensively makes the most sense for the initial > port, but in the long run, doing as much as possibly in SH-Compact would > probably be faster and cut down on the overall object/resultant kernel size .. > especially considering the differences in instruction sizes (and with -g > turned on, saving as much space as possible is always a plus..). While this > may not be worth thinking about right now, it still seems like something worth > looking into in the future.. Unfortunatly it's not so clear cut. Yes, the instructions are twice as big, but you shouldn't need as many do do the same thing: - the SH-Media instructions are three address (as opposed to SH3/4's two address) - you have access to a lot more general purpose registers - the instruction set handles branches better (less pipeline stalls) - the instruction set handles loading constants better (most are now encoded directly in the instruction). Plus loading instructions can be easily predicted, so you should rarely still the pipe for an I fetch, but data fetches are less predictable, and tend to result in stalls, so should be avoided as far as possible, especially on embedded devices which tend to have smaller caches. So even if you fetch more instructions, you should fetch less data, resulting in a net performance gain. In summary, using SH-Media instructions should be faster than SH-Compact, but may be slightly larger. > > So for this reason we decided not to merge the SH5 code with the current > > SH3/4 kernel. We have created a new architecture called "sh5" in the kernel > > source code, which is completely separate from the current "sh" > > architecture. However it does share device drivers with the other SH > > devices, such as the SCIF. > > > > It could have been called sh64, but we decided against that as it > > is not really a 64 bit port - pointers and longs are still 32 bits. > > A full 64 bit port is still a possibility for the future. > > > I'm not so sure that this is a good idea.. in the tradition of architecture > naming schemes under linux things always follow the arch/arch64 approach. > If the system is capable of sanely mapping things to 64-bit addresses without > the system choking, then the arch64 thing seems to make more sense. If on the > other hand, the system has issues with this, then it doesn't have much place > in an arch64-type layout. From your indication of pointers being 32 bits, this > would certainly seem to indicate that it's not ready for an sh64 convention. The 64 bit issue has several aspects: - the compiler - gcc should support both 64 and 32 bit modes, but 64 bit hasn't been tested much (here at least) - the architecture - this has been designed for 64 bit - the implementation - this is 32 bit. Many registers only have 32 bits implemented (eg PC) - the OS Again, its a difficult question. The decision was made that as the current implementaion of SH5 is 32 bit, there was no benefit in making the OS 64 bit, and probably a performance and memory size penalty in doing so. If an implementation with more then 32 bits is ever produced, then some work will be needed in the kernel to support it. It hasn't been forgotten about, and there are plenty of places in the code where typedef's and macros have been used to make moving to 64 bit easier. Whether this makes it a 64 bit port though, I'm not sure. > On the other hand, adding "sh5" completely goes against the natural order of > things and should try to be avoided as vigorously as possible. While the SH5 > might not follow typical SH3/4 convention, that hardly warrants the creation > of a new arch directory. Under MIPS, many systems have completely different > caches, MMU's, TLB handling, etc, etc. all of these things are dealt with in a > rather sane fashion -- of which I'm trying to achieve the same goal with the > SH tree for 2.5, though I'm still working on restructuring things. > > As long as the majority of things are done in SH-Compact, changes to things > like entry.S should be rather minimalistic.. but it's hard to determine what > the severity of the changes are without having any code to look at. Things like entry.S have to be in SH_Media. When the CPU takes a trap, it always reverts to SH-Media. Plus many of the registers and instructions you need to access to handle traps, caches etc are only available in SH-Media. A lot depends on your point of view. Personally, I feel that the SH5 effectivly a new CPU, which just happens to be able to run SH4 executables. In a similar way the ia64 is new CPU, which is capable of running i386 binaries (maybe..). I understand marketing people have a slightly different opinion, because they want to preserve the appearence of a SuperH family line, from SH1 through to SH5 and beyond. Its not an obvious decision either way. This is partly why I proposed the new project. We can get the code out in the open, thrash out issues like this, before comitting to a naming scheme and possibly merge, and ditch the sh5 project. > > So, the proposal: > > > > I'd like to get this code checked into a CVS repository on SourceForge > > as soon as possible. There are already several groups here who want > > access to the sources, so this is easier than just putting it up for > > FTP somewhere. Plus it allows other developers to join in as things > > develop. > > > > At the moment I think it may be better to create a new SourceForge > > project for this, rather than use the current LinuxSH one. > > > > This is mainly: > > > - the kernel is currently only of interest to kernel hackers, its > > not ready for general consumption. > > The 2.5 restructuring tree for the LinuxSH isn't suitable for mere mortals > either, and shouldn't even be approached by anyone other then kernel hackers. > Yet it sits in CVS just fine. > > > - because the current SH5 code is based around the old kernel, and is > > still fairly immature, it doesn't make sense to put it in the > > "linux" directory in CVS. It could go in a separate directory in > > CVS though. > > In my opinion, there isn't enough reason to divide this stuff out into a > completely seperate project.. putting SH5 under its own module for the time > being would be fine, but it would be nice to forward port this stuff to > current 2.4, and merge it into the 2.4 branch of the drop-in tree, where it > can then be used by everybody and the other module could be removed in its > entirety. > > If there's interest in this, I'd have no problems taking care of updating the > SH5 tree and merging it into the existing drop-in, if there are no other > takers. Its pretty high on our TODO list, but how long it will take to happen remains to be seen. I may need to take you up on that! > > > - things are still very changable. Its quite possible major > > restructuring may still happen (renaming the architacture for example!), > > and we don't know at the moment how things will turn out. > > I'd say concentrate on stable changes under the 2.4 branch if that's where > this ends up going.. or just leave it in HEAD.. I'd prefer if major > restructuring would be postponed until I'm done with the 2.5 restructuring of > the tree, otherwise we might end up duplicating efforts. Plus, it should make > assimilating SH5 in a sane fashion a lot easier.. > > > and then at some point in the future when the kernel is more mature, > > and we know better what it will look like, we can think about merging > > it into the LinuxSH project. > > > If you start maintaining it independantly of the LinuxSH project from the > beginning, it's just going to be more of a nuisance when you try and do the > merge later. At present, the code is in its infancy, things can still be > changed, etc, etc. with these things in mind, it's the best time to merge this > into the LinuxSH project and beat it into submission.. > > Either way.. lets have a look at the tree first, and then we can figure out > what the best course of action might be. Or if anyone else has any similar > insight on the matter, that could be helpful too. > > Regards, > > -- > Paul Mundt <le...@ch...> OK, so how about before we go any further I post it on an FTP server first, and then we can have a more informed discussion? Stuart -- Stuart Menefy stu...@st... STMicroelectronics Ltd ST Intranet: mo.bri.st.com Bristol, UK Rest of the World: www.linuxsh.st.com |
|
From: Paul M. <le...@Ch...> - 2002-02-28 22:56:26
|
On Thu, Feb 28, 2002 at 09:59:58PM +0000, Stuart Menefy wrote: > Short answer, I've no idea. SH8000 is Hitachi's part (and as fasr as I kn= ow > is the only chip with an SH5 core at the moment). >=20 So how does this relate to reference hardware? Does everyone have to go through Hitachi for reference hardware? And what about ST50, is there anyth= ing special about that? or hardware? > Unfortunatly it's not so clear cut. Yes, the instructions are twice as bi= g, > but you shouldn't need as many do do the same thing: > - the SH-Media instructions are three address (as opposed to SH3/4's two > address) > - you have access to a lot more general purpose registers > - the instruction set handles branches better (less pipeline stalls) > - the instruction set handles loading constants better (most are now > encoded directly in the instruction). > Plus loading instructions can be easily predicted, so you should rarely > still the pipe for an I fetch, but data fetches are less predictable, and > tend to result in stalls, so should be avoided as far as possible, > especially on embedded devices which tend to have smaller caches. So even > if you fetch more instructions, you should fetch less data, resulting in > a net performance gain. >=20 > In summary, using SH-Media instructions should be faster than SH-Compact, > but may be slightly larger. =20 >=20 That puts a slightly different spin on things.. it no doubt would probably = be faster from what you've described, but the object/binary size will also be considerably larger .. much in the way that mips32 is considerably larger in comparison to SH4 right now (since mips uses 32bit instructions as well). But, if you can get more done with less instructions, that seems to be a considerable win as well.. I guess we'll have to wait and see how things wo= rk out. > The 64 bit issue has several aspects: > - the compiler - gcc should support both 64 and 32 bit modes, but 64 bit= hasn't > been tested much (here at least) > - the architecture - this has been designed for 64 bit > - the implementation - this is 32 bit. Many registers only have 32 bits > implemented (eg PC) > - the OS >=20 > Again, its a difficult question. The decision was made that as the current > implementaion of SH5 is 32 bit, there was no benefit in making the OS 64 = bit, > and probably a performance and memory size penalty in doing so. If an > implementation with more then 32 bits is ever produced, then some work wi= ll > be needed in the kernel to support it. >=20 There rarely are any advantages to running the OS 64-bit. Even mips64 and friends still usually get away with a 32-bit userland .. much in the same w= ay that IRIX64 wasn't run on the majority of 64-bit platforms. There's usually more drawbacks then there are benefits with going this route.. > It hasn't been forgotten about, and there are plenty of places in the code > where typedef's and macros have been used to make moving to 64 bit easier. > Whether this makes it a 64 bit port though, I'm not sure. >=20 With the code structured the way it is, it would be interesting to play with doing things as a 64-bit port and still permit it running 32-bit.. mips64 duplicates some things around in this fashion, though things are usually preferrably running in 32-bit. > Things like entry.S have to be in SH_Media. When the CPU takes a trap, it > always reverts to SH-Media. Plus many of the registers and instructions y= ou > need to access to handle traps, caches etc are only available in SH-Media. >=20 That's what I was afraid of.. > A lot depends on your point of view. Personally, I feel that the SH5 effe= ctivly > a new CPU, which just happens to be able to run SH4 executables. In a sim= ilar > way the ia64 is new CPU, which is capable of running i386 binaries (maybe= ..). >=20 > I understand marketing people have a slightly different opinion, because = they > want to preserve the appearence of a SuperH family line, from SH1 through > to SH5 and beyond. >=20 > Its not an obvious decision either way. This is partly why I proposed the > new project. We can get the code out in the open, thrash out issues like = this, > before comitting to a naming scheme and possibly merge, and ditch the sh5 > project. >=20 That might not be a bad idea for initial work.. though keeping it in the LinuxSH CVS under its own module would still seem to be the more useful answer, since it can be scrapped later when its obsoleted. Plus, if no one = is interested in cleaning up the website the way it is now, it's still not hard to add a link to some SH5 space and toss all information regarding the state of the tree and such there. > > If there's interest in this, I'd have no problems taking care of updati= ng the > > SH5 tree and merging it into the existing drop-in, if there are no other > > takers. >=20 > Its pretty high on our TODO list, but how long it will take to happen rem= ains > to be seen. I may need to take you up on that! >=20 Lack of hardware makes testing a bit of a peculiarity, but as long as someo= ne else is willing to do testing, I'm more then willing to do the kernel work. > > Either way.. lets have a look at the tree first, and then we can figure= out > > what the best course of action might be. Or if anyone else has any simi= lar > > insight on the matter, that could be helpful too. > >=20 >=20 > OK, so how about before we go any further I post it on an FTP server > first, and then we can have a more informed discussion? >=20 Sounds like a plan. Regards, --=20 Paul Mundt <le...@ch...> |
|
From: Stuart M. <stu...@st...> - 2002-03-01 11:33:26
|
On Thu, 28 Feb 2002 14:55:10 -0800 le...@Ch... wrote: > On Thu, Feb 28, 2002 at 09:59:58PM +0000, Stuart Menefy wrote: > > Short answer, I've no idea. SH8000 is Hitachi's part (and as fasr as I know > > is the only chip with an SH5 core at the moment). > > > So how does this relate to reference hardware? Does everyone have to go > through Hitachi for reference hardware? And what about ST50, is there anything > special about that? or hardware? As far as I know the only reference boards are from Hitachi: ftp://ftp.hitachi.com/netshare/capp01/Cayman/ I have one, through SuperH, but whether they are 'available' I don't know. ST50 is ST's name for parts with an SH5 core. Currently there are none, all SH5 based parts have been fabed by Hitachi. > > > Either way.. lets have a look at the tree first, and then we can figure out > > > what the best course of action might be. Or if anyone else has any similar > > > insight on the matter, that could be helpful too. > > > > > > > OK, so how about before we go any further I post it on an FTP server > > first, and then we can have a more informed discussion? > > > Sounds like a plan. Watch this space... Stuart -- Stuart Menefy stu...@st... STMicroelectronics Ltd ST Intranet: mo.bri.st.com Bristol, UK Rest of the World: www.linuxsh.st.com |
|
From: Stuart M. <stu...@st...> - 2002-03-12 18:09:14
|
Folks I've uploaded a snapshot of the current SH5 tree to our FTP server: ftp://ftp.linuxsh.st.com/pub/linuxsh/sh5/linux-sh5-20020302.tar.bz2 for your perusal. This is structured as a drop in tree, against a standard linux-2.4.0-test4 tree. At the moment I'm actually tempted to try putting this into a BitKeeper project. As well as being an interesting test for BitKeeper, it has the big plus for us of avoiding the problems we still have with CVS/ssh through firewalls. Any comments (on any of this), let me know. Stuart -- Stuart Menefy stu...@st... STMicroelectronics Ltd ST Intranet: mo.bri.st.com Bristol, UK Rest of the World: www.linuxsh.st.com |
|
From: M. R. B. <mr...@0x...> - 2002-03-01 11:43:06
|
* Stuart Menefy <stu...@st...> on Fri, Mar 01, 2002: >=20 > As far as I know the only reference boards are from Hitachi: > ftp://ftp.hitachi.com/netshare/capp01/Cayman/ > I have one, through SuperH, but whether they are 'available' I don't know. >=20 Hmm, is this the correct link? ftp.hitachi.com doesn't resolve.... M. R. |
|
From: Stuart M. <stu...@st...> - 2002-03-01 11:50:27
|
On Fri, 1 Mar 2002 05:43:01 -0600 mr...@0x... wrote: > * Stuart Menefy <stu...@st...> on Fri, Mar 01, 2002: > > > > > As far as I know the only reference boards are from Hitachi: > > ftp://ftp.hitachi.com/netshare/capp01/Cayman/ > > I have one, through SuperH, but whether they are 'available' I don't know. > > > > Hmm, is this the correct link? ftp.hitachi.com doesn't resolve.... Apologies, that should have been: http://ftp.hsa.hitachi.com/netshare/capp01/Cayman/ Stuart -- Stuart Menefy stu...@st... STMicroelectronics Ltd ST Intranet: mo.bri.st.com Bristol, UK Rest of the World: www.linuxsh.st.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X