From owner-linux-arm-outgoing@vger.rutgers.edu Sun Jan 19 01:02:46 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id BAA25224 for ; Sun, 19 Jan 1997 01:02:35 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <66085-20847>; Sun, 19 Jan 1997 03:02:49 +0200 Received: by vger.rutgers.edu id <213035-11748>; Sat, 18 Jan 1997 19:52:59 -0500 From: rmk92@ecs.soton.ac.uk Message-Id: <2596.199701190100@raistlin.armlinux.org> Subject: Re: Cross-building Debian packages To: linux-arm@vger.rutgers.edu, arm-linux@tardis.ed.ac.uk, dwalker@art.acorn.co.uk Date: Sun, 19 Jan 1997 01:00:10 +0000 (GMT) In-Reply-To: from "Philip Blundell" at Jan 18, 97 03:03:11 pm X-Phone: +44 (0)1737 360654 Reply-To: rmk92@ecs.soton.ac.uk X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO Philip Blundell writes: > ARM. I'm not sure that I shall though, bearing in mind that I'm not > entirely sure I want to get entangled with Debian, and I'm rapidly losing > patience with Linux/ARM in general, given that Russell seems to have > little or no inclination to send me a copy of his stuff on disk, having > been prevaricating for a _very_ long time now. *NOTE* this was written extremely quickly, and without thought. Hence it is blunt and to the point. It may or may not be absolutely correct, and there may be parts that I regret putting in. However, this is currently my situation. It is not a lack of inclination - it's a lack of time. I have just changed jobs, from a frustrating job due to lack of documentation on several companies parts (which basically meant that it dragged the job out), to a 7 day 10 hr week job, which does not leave much time to work on Linux. There is the possibility of a business trip up to Scotland in around two weeks, and during that time I will be totally out of touch, AND THERE IS NOTHING I CAN DO ABOUT THIS. The source code for the kernel has changed quite a bit since I put the bits on Phil's Syquest, so that requires updating. However, if he would like me to write the disk with an as yet untested set of source code, then I can do that right now and send it to him. I am devoting all *NON WORKING* hours to Linux (9pm - midnight/1am), so I am doing the best possible, probably at severe risk to my personnal health to keep this project going. I am sure that you can see that I am (and have been) under considerable pressure recently. Maybe I ought to totally drop the idea of ARM Linux then? Maybe I don't have the time to continue it? Maybe not. Maybe in a month's time or so, I'll be able to reduce the hours that I'm currently working. Plus, I am getting mails from people trying to download the new kernels that appear to be on the web site, dispite the fact that the downloading page says quite clearly that it is in the process of being uploaded. Maybe this should be corrected - it will be uploaded when it is ready. Ok, the directories are present on the FTP site, but I can assure you that they are empty for now. Please note that some of the kernel sources have already been combined into Linus' kernel source tree, and I hope that this can continue. (I'm sorry Phil - this isn't specifically directed at you - I'm under severe pressure at the moment, and this is just another thing sitting on my todo pile. I will get round to it, I can assure you). What I may end up doing is releasing a very limited set of known kernels (the ones that I am running right now), and allowing Philip to upload the compiler tools such that other people can work on the binaries. This would be a great help to the project, since various binaries are becomming quite old now. At the same time, this would relieve me of the massive amount of work required to produce a meaningful distribution. How about it? To sum up, I have a very large workload on at the moment that is preventing me from progressing the kernel and distribution as fast as I would like. This workload should reduce in the near future, whereby I hope to get something at least together. _____ |_____| ------------------------------------------------- ---+---+- | | Russell King rmk92@ecs.soton.ac.uk --- --- | | | | http://whirligig.ecs.soton.ac.uk/~rmk92/home.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | * who wishes that he was in Hong Kong * --- | +-+-+ ------------------------------------------------- /\\\ | From owner-linux-arm-outgoing@vger.rutgers.edu Sun Jan 19 01:30:52 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id BAA25247 for ; Sun, 19 Jan 1997 01:30:51 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <66133-15266>; Sun, 19 Jan 1997 03:31:16 +0200 Received: by vger.rutgers.edu id <212997-11751>; Sat, 18 Jan 1997 20:21:23 -0500 Date: Sun, 19 Jan 1997 01:25:48 +0000 (GMT) From: Philip Blundell X-Sender: pjb27@hammer.thor.cam.ac.uk To: rmk92@ecs.soton.ac.uk cc: linux-arm@vger.rutgers.edu Subject: Re: Cross-building Debian packages In-Reply-To: <2596.199701190100@raistlin.armlinux.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO On Sun, 19 Jan 1997 rmk92@ecs.soton.ac.uk wrote: > Please note that some of the kernel sources have already been combined into > Linus' kernel source tree, and I hope that this can continue. Incidentally, has there been any movement on the cache-flushing front? P. From owner-linux-arm-outgoing@vger.rutgers.edu Sun Jan 19 13:52:36 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id NAA25836 for ; Sun, 19 Jan 1997 13:52:35 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <66412-262>; Sun, 19 Jan 1997 15:53:17 +0200 Received: by vger.rutgers.edu id <213033-11751>; Sun, 19 Jan 1997 08:43:27 -0500 Date: Sun, 19 Jan 1997 13:52:19 +0000 (GMT) From: Philip Blundell X-Sender: pjb27@hammer.thor.cam.ac.uk To: Charles Esson cc: linux-arm@vger.rutgers.edu Subject: Re: Arm Linux In-Reply-To: <32E1EC78.7C22@cvs.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO On Sun, 19 Jan 1997, Charles Esson wrote: > development board ( Digital are now selling the QR-21A81-02 for > AUD$3205), and what, I find out the port delay it is not a slow modem > but a lack of resources, not complaining mind you. There are actually various things delaying the port, and some of them are rather inter-related. I've Cc'd this back to the mailing list. Firstly, there's lack of time. Russell, as he said in his last note (and, to do him justice, he hasn't made any secret of this before) is very busy. Secondly, there's lack of developers. This is partly because very few people seem to have actually stepped forwards and said `I will do such-and-such work'. Partly it's because Russell doesn't manage to release sources very often, and so even those are willing have a hard time doing anything useful. Thirdly, there's lack of general resources. The only ARM-based hardware I have at my disposal right now is an old A5000, and that's not a good machine to develop on. I hope to get hold of an ARM700 card and a StrongARM of some sort in due course, but it may take some time. Luckily I _do_ have an Alpha and a Pentium that I can cross-compile on in the interim. Russell doesn't have a fast Internet link. For what it's worth, this (in no particular order) is my mental list of things that I think would be current worthwhile projects for somebody to take on. Obviously that's not to say that nothing else is worthwhile, but these are the ones that I believe would make things significantly better. 1. Kernel stuff - ARM6 support. This ought not to be very difficult, given that we have ARM3 and StrongARM already (and a good fraction of the ARM6 stuff is in there anyway). There are plenty of people with either RiscPCs or other ARM6-based hardware who would like to run Linux. - More and better device drivers. This is an ongoing one, obviously. I think Dave Gilbert is handling the old `Archimedes' hardware at the moment. - Merge with Linus' source tree. I think work is ongoing by Russell on this, and the major obstacle at the moment is probably Linus' lack of spare time. 2. General user-space stuff - X. The Xserver for Archimedes hardware isn't really rocket science, since VIDC just gives you a flat framebuffer. At the moment I think we only have quite an old version, and it would be nice to have the latest XFree86 ported (they really ought to think about changing the name eventually...). - Debian. Bruce Perens has shown some interest in having a Debian port for the ARM, and it seems like a good idea. 3. Tools and stuff. - gcc. At the moment GCC doesn't generate such good code for the ARM as Norcroft does, and this is a bit of a shame. - binutils. Last time I looked, binutils for the ARM was buggy. - ELF. Linux is moving to ELF, and we don't want to be left behind. ELF is important for shared libraries, especially... - glibc, or libc.so.6, is the new Linux shared library. It needs to be ported to the ARM. 4. Weird stuff. - Some sort of emulator to allow RISC OS binaries to run might be a fun thing to have. So, there's much to do. Do any of those things call out to anybody reading this and say `Implement me!'? If so, let me know. phil From owner-linux-arm-outgoing@vger.rutgers.edu Sun Jan 19 18:00:33 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id SAA26119 for ; Sun, 19 Jan 1997 18:00:32 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <67499-20847>; Sun, 19 Jan 1997 19:55:44 +0200 Received: by vger.rutgers.edu id <213035-11748>; Sun, 19 Jan 1997 12:45:19 -0500 Date: Sun, 19 Jan 1997 14:56:53 +0000 From: Joseph Heenan To: linux-arm@vger.rutgers.edu Subject: Re: Arm Linux Message-ID: In-Reply-To: Reply-To: j.heenan@odie.fluff.org Organization: X X-Mailer: Messenger v0.28 for RISC OS X-Posting-Agent: RISC OS Newsbase 0.58-pre-5-timelimited Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO In message Philip Blundell wrote: [some brutally trimmed text:] > Secondly, there's lack of developers. This is partly because very few > people seem to have actually stepped forwards and said `I will do > such-and-such work'. Partly it's because Russell doesn't manage to > release sources very often, and so even those are willing have a hard time > doing anything useful. I'd like to do something - but I can't even run linux at the moment (ARM 700). I have a pentium sitting next to me than I could use to cross compile things, but that's kind of hindered by not having any source. I have not idea what's involved in getting it to work on a 700 - I can't see it been too much, like you say, but I don't want to stand up and say "I'll do this", and then find it's way outside of my capabilities. > Russell doesn't have a fast Internet link. I have a zip drive that I can connect upto a PC at uni - if people want things uploading, I can do it if it's sent to me on a zipdisc... > - ARM6 support. This ought not to be very difficult, given that > we have ARM3 and StrongARM already (and a good fraction of the > ARM6 stuff is in there anyway). There are plenty of people with > either RiscPCs or other ARM6-based hardware who would like to > run Linux. *waves hand in air* > - X. The Xserver for Archimedes hardware isn't really rocket > science, since VIDC just gives you a flat framebuffer. At the > moment I think we only have quite an old version, and it would > be nice to have the latest XFree86 ported (they really ought to > think about changing the name eventually...). How much is involved in this? (Low-level VIDC hacking?) > - Debian. Bruce Perens has shown some interest in having a Debian > port for the ARM, and it seems like a good idea. I'd assume (perhaps wrongly) that this is mostly just a question of grabbing the sources and compiling things. I could perhaps do this, depending on what sort of timescale things are going to happen on. > - gcc. At the moment GCC doesn't generate such good code for the > ARM as Norcroft does, and this is a bit of a shame. This isn't just arm-linux, though - and I thought there was already someone working on this. > 4. Weird stuff. > > - Some sort of emulator to allow RISC OS binaries to run might be > a fun thing to have. fun, yes. Whether it could actually have any practical value or not is another matter ;-) As far as I can see, from what's on the ftp site, I can't do anything without having access to an A5000, and I don't :-( -- Joseph Heenan email: esuvf@csv.warwick.ac.uk, J.Heenan@ftp.barnet.ac.uk From owner-linux-arm-outgoing@vger.rutgers.edu Sun Jan 19 22:27:35 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id WAA26492 for ; Sun, 19 Jan 1997 22:27:34 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <68395-8831>; Mon, 20 Jan 1997 00:28:28 +0200 Received: by vger.rutgers.edu id <213189-11751>; Sun, 19 Jan 1997 17:18:09 -0500 Message-ID: <32E2A04B.225C@cvs.com.au> Date: Mon, 20 Jan 1997 09:29:31 +1100 From: Charles Esson Reply-To: charlese@cvs.com.au Organization: Colour Vision Systems X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: pjb27@cam.ac.uk CC: linux-arm@vger.rutgers.edu, rmk92@ecs.soton.ac.uk Subject: Re: Arm Linux Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO I brought a RISC PC 700, my interest is the strong-arm so if the ARM710 CPU that was pulled out to put in the strong-arm is yours if it is of any use to you. I brought the RISC PC 700 in the hope that there would be a port to it, and I could use this as the base for my efforts. My real interest is to get it running on our hardware. I've spent 20 years supporting and writing real time operating systems, assemblers and applications for the 68k and in the dim past the PDP11. My interest is the software hardware interface. My linux experience is close to nil, but time will fix that. I slept on it last night and concluded this has just got to happen. The strong-arm is a great chip, 0.5 watts, 220 mips. This is just unheard of performance and opens up so many possibilities, further the Arm instruction set is something to be admired. Linux is great opportunity for the computer industry. A good, well supported operating system with source available would be a great boost to the real time industry. So if I look at the list, and ask what I am able and interested in doing. Kernel -ARM 6 No -Missing drivers for the QR-21A81-02, I will write as our hardware design will be based on this card. -Merge with Linus source tree, obviously no. General -X I will need this but it would not be something I would do with joy. -Debian. I've had a long hard think about this, and it would seem like a dam good idea as it would help the arm along in the general market. But looking under he tools there are more immediate problems. Tools -gcc If the problem is translation of the intermediate code to assembler, perhaps. If the problem is the compiler itself, no it would require specialized knowledge that I don't have and are unwilling to learn. This however is something we could live with in the short term -binutils. Maybe. -ELF. To my mind if the kernel is up and running then this is the next cab of the rank, and I will put up my hand. I have this horrible feeling however that this will involve mods to the gcc backend. -glibc, or libc.so.6. If someone else wants to do the ELF stuff, I will put up my hand for this one, but as I understand it, one of the advantages of ELF is the simplification of library support, making ELF the first problem. Well that’s about where I sit, the biggest problem I see is that someone has to organize who does what so there isn’t a duplication of effort, and we have to move to a team approach so the job gets done. Another 2 pence worth. -- Charles Esson Colour Vision Systems 11 Park Street, Bacchus March, Victoria, Australia 3340. Phone: 61 53 673155, Fax: 61 53 674480 From owner-linux-arm-outgoing@vger.rutgers.edu Sun Jan 19 23:16:19 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id XAA26575 for ; Sun, 19 Jan 1997 23:16:19 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <68365-8831>; Mon, 20 Jan 1997 01:16:40 +0200 Received: by vger.rutgers.edu id <213035-11748>; Sun, 19 Jan 1997 18:06:35 -0500 Date: Sun, 19 Jan 1997 23:15:25 +0000 (GMT) From: Philip Blundell X-Sender: pjb27@hammer.thor.cam.ac.uk To: Charles Esson cc: linux-arm@vger.rutgers.edu Subject: Re: Arm Linux In-Reply-To: <32E2A04B.225C@cvs.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO On Mon, 20 Jan 1997, Charles Esson wrote: > I slept on it last night and concluded this has just got to happen. The > strong-arm is a great chip, 0.5 watts, 220 mips. This is just unheard of > performance and opens up so many possibilities, further the Arm That's true. > -Merge with Linus source tree, obviously no. No, that will have to be Russell really. > -gcc If the problem is translation of the intermediate code to > assembler, perhaps. If the problem is the compiler itself, no it would > require specialized knowledge that I don't have and are unwilling to > learn. This however is something we could live with in the short term Yes. I'm not too keen on digging around in the compiler myself really - compilers aren't exactly my area of interest. As you say, it can wait; it's good enough for now. > -ELF. To my mind if the kernel is up and running then this is the next > cab of the rank, and I will put up my hand. I have this horrible feeling > however that this will involve mods to the gcc backend. Yes. This will probably need changes to gcc and binutils. However, it's not just a Linux problem and we might be able to liase with the NetBSD people. Ditto with X, actually. > -glibc, or libc.so.6. If someone else wants to do the ELF stuff, I will > put up my hand for this one, but as I understand it, one of the > advantages of ELF is the simplification of library support, making ELF > the first problem. Yes. glibc is something I'd envisaged doing myself, but I'm always keen for other people to help. ELF isn't a prerequisite to _start_ the work, but it will be required sooner rather than later. > Well that’s about where I sit, the biggest problem I see is that someone > has to organize who does what so there isn’t a duplication of effort, > and we have to move to a team approach so the job gets done. Quite. I'm quite prepared to keep track of who's doing what. There seem to be precious few people who _are_ prepared to do any programming, so I don't imagine it will be too arduous. phil From owner-linux-arm-outgoing@vger.rutgers.edu Mon Jan 20 01:28:42 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id BAA26859 for ; Mon, 20 Jan 1997 01:28:41 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <68288-13071>; Mon, 20 Jan 1997 03:27:44 +0200 Received: by vger.rutgers.edu id <213045-11748>; Sun, 19 Jan 1997 20:17:43 -0500 Date: Mon, 20 Jan 1997 01:26:42 +0000 (GMT) From: Philip Blundell X-Sender: pjb27@hammer.thor.cam.ac.uk To: j.heenan@odie.barnet.ac.uk cc: linux-arm@vger.rutgers.edu Subject: Re: Arm Linux In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO On Sun, 19 Jan 1997, Joseph Heenan wrote: > I'd like to do something - but I can't even run linux at the moment > (ARM 700). I have a pentium sitting next to me than I could use to > cross compile things, but that's kind of hindered by not having any > source. Hopefully, source we _will_ have soon. If Russell sends me the disk then I can put up on an ftp site for other people to download. > I have not idea what's involved in getting it to work on a 700 - > I can't see it been too much, like you say, but I don't want to stand > up and say "I'll do this", and then find it's way outside of my > capabilities. I think it ought to be well within the capabilities of somebody who knows a reasonable amount about the ARM family, has the hardware, and has some experience of the kernel. > I have a zip drive that I can connect upto a PC at uni - if people > want things uploading, I can do it if it's sent to me on a zipdisc... Yes; I have a SyQuest drive in my (Internet-connected) machine. > > - X. The Xserver for Archimedes hardware isn't really rocket > > science, since VIDC just gives you a flat framebuffer. At the > > How much is involved in this? > (Low-level VIDC hacking?) Not even much of that. As things stand, the screen mode is set up by RISC OS and left alone by Linux. It would be nice to have a way to change it, but it's not vital. > I'd assume (perhaps wrongly) that this is mostly just a question of > grabbing the sources and compiling things. I could perhaps do this, > depending on what sort of timescale things are going to happen on. Basically yes. There are things like alignment errors that will need to be fixed up -- as far as I know, the ARM3 is currently unique among Linux machines in that it absolutely _cannot_ do an unaligned access. The Intel will do the access happily; the Alpha and the SPARC (and the ARM6+ with MMU on, I think) will fault and you can emulate it in software, but the ARM3 will silently discard the low address lines. Other than that, someone will need to write an installation system and the rest is just a question, as you say, of compiling things up. > This isn't just arm-linux, though - and I thought there was already > someone working on this. Indeed. With this (and X as well) we should liase with the NetBSD people. > fun, yes. Whether it could actually have any practical value or not > is another matter ;-) It could do. Things like BBC BASIC and Norcroft C might be beneficial to be able to run under Linux, and I don't think it even ought to be too tricky. > As far as I can see, from what's on the ftp site, I can't do anything > without having access to an A5000, and I don't :-( That certainly does seem to be the state of play at the moment. P. From owner-linux-arm-outgoing@vger.rutgers.edu Mon Jan 20 12:15:34 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id MAA27568 for ; Mon, 20 Jan 1997 12:15:33 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <66378-13071>; Mon, 20 Jan 1997 14:14:27 +0200 Received: by vger.rutgers.edu id <213240-11748>; Mon, 20 Jan 1997 07:04:20 -0500 From: Joseph Heenan Message-Id: <28500.199701201213@lupin.csv.warwick.ac.uk> Subject: Re: Arm Linux To: pjb27@cam.ac.uk (Philip Blundell) Date: Mon, 20 Jan 1997 12:13:12 +0000 (GMT) Cc: linux-arm@vger.rutgers.edu In-Reply-To: from "Philip Blundell" at Jan 20, 97 01:26:42 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO > > I'd like to do something - but I can't even run linux at the moment > > (ARM 700). I have a pentium sitting next to me than I could use to > > cross compile things, but that's kind of hindered by not having any > > source. > > Hopefully, source we _will_ have soon. If Russell sends me the disk then > I can put up on an ftp site for other people to download. ah. That would be /very/ useful. Then I can pester someone about how to get a cross-compiler working :-) > > > - X. The Xserver for Archimedes hardware isn't really rocket > > > science, since VIDC just gives you a flat framebuffer. At the > > > > How much is involved in this? > > (Low-level VIDC hacking?) > > Not even much of that. As things stand, the screen mode is set up by RISC > OS and left alone by Linux. It would be nice to have a way to change it, > but it's not vital. oh right - something like this is somewhat lower on my priorities than actually getting the thing runnning in the first place, though ;-) > [Debian and compiling it] > > Basically yes. There are things like alignment errors that will need to > be fixed up -- as far as I know, the ARM3 is currently unique among Linux > machines in that it absolutely _cannot_ do an unaligned access. The Intel > will do the access happily; the Alpha and the SPARC (and the ARM6+ with > MMU on, I think) will fault and you can emulate it in software, but the > ARM3 will silently discard the low address lines. Other than that, > someone will need to write an installation system and the rest is just a > question, as you say, of compiling things up. Perhaps I've got the wrong end of the stick here - I'd assumed debian would be a lot of C sources that just need perhaps the odd bit of inline assembler rewriting. Surely the C compiler should handle all the platform specific things, apart from inline assembler? > > This isn't just arm-linux, though - and I thought there was already > > someone working on this. > > Indeed. With this (and X as well) we should liase with the NetBSD people. Agreed. > > fun, yes. Whether it could actually have any practical value or not > > is another matter ;-) > It could do. Things like BBC BASIC and Norcroft C might be beneficial to > be able to run under Linux, and I don't think it even ought to be too > tricky. Basic sounds like quite a good idea. Shame it's copyright, really - a basic interpretter running under general unix has some sort of appeal to it :-) I'm sure gcc will get to the point of generating code as good as Norcroft again at some point - and Norcroft isn't without its own problems. :-) -- Joseph Heenan, Computer Systems Engineering Student, Warwick Uni email - esuvf@csv.warwick.ac.uk jogu@odie.barnet.ac.uk www - http://www.csv.warwick.ac.uk/~esuvf/ From owner-linux-arm-outgoing@vger.rutgers.edu Mon Jan 20 12:26:33 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id MAA27605 for ; Mon, 20 Jan 1997 12:26:32 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <66071-19794>; Mon, 20 Jan 1997 14:26:03 +0200 Received: by vger.rutgers.edu id <213040-11751>; Mon, 20 Jan 1997 07:16:00 -0500 Date: Mon, 20 Jan 1997 12:25:15 +0000 (GMT) From: Philip Blundell X-Sender: pjb27@hammer.thor.cam.ac.uk To: Joseph Heenan cc: linux-arm@vger.rutgers.edu Subject: Re: Arm Linux In-Reply-To: <28500.199701201213@lupin.csv.warwick.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO On Mon, 20 Jan 1997, Joseph Heenan wrote: > Perhaps I've got the wrong end of the stick here - I'd assumed > debian would be a lot of C sources that just need perhaps the odd > bit of inline assembler rewriting. Surely the C compiler should handle > all the platform specific things, apart from inline assembler? No. To take a contrived example, imagine you have this: unsigned char foo[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 }; unsigned int *bar; bar = (unsigned int *)(foo+1); printf("bar = %08x\n", *bar); On Intel, this gives: kings-cross:~$ ./align bar = 05040302 kings-cross:~$ On Alpha, this gives: paddington:~$ ./align align(1964): unaligned trap at 0000000120000a74: 000000011ffff711 28 2 bar = 05040302 paddington:~$ But on an old ARM, you will get `bar = 0x04030201'. The reason is that the dereference of `bar' compiles to an LDR instruction. In general, the compiler can't know the alignment at compile-time, so there's not a lot else it *can* do. Old ARM machines silently discard the low two address bits when you ask them to do a word access. This differs, as I said before, from the Intel (where you get the correct access performed, albeit more slowly) and the Alpha/SPARC/etc (where you get a fault, and your OS has to patch up in software). This sort of thing doesn't crop up *that* often, but it does happen, and code will go wrong when it does. There is *very* little inline assembler in most things, and I doubt much porting work will be needed in general. A lot of autoconf scripts will probably need to be taught about Linux/ARM, but other than that... > Basic sounds like quite a good idea. Shame it's copyright, really - > a basic interpretter running under general unix has some sort of appeal > to it :-) Yes. OTOH, although it's copyright, if it's in ROM it can be used fairly freely. Someone sufficiently sick could probably write a snippet of code to be run as root that rummages around the RISC OS ROMs and pulls out the BASIC module. P. From owner-linux-arm-outgoing@vger.rutgers.edu Mon Jan 20 12:48:45 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id MAA27700 for ; Mon, 20 Jan 1997 12:48:43 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <66306-8831>; Mon, 20 Jan 1997 14:47:36 +0200 Received: by vger.rutgers.edu id <213091-11748>; Mon, 20 Jan 1997 07:35:21 -0500 Message-Id: <199701201340.NAA23883@spider> Subject: Re: Arm Linux To: linux-arm@vger.rutgers.edu Date: Mon, 20 Jan 1997 13:40:17 +0000 (GMT) Reply-To: John.Tytgat@barco.com From: John.Tytgat@barco.com (John Tytgat) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO From: ADMVAX::SMTP%"pjb27@cam.ac.uk" 20-JAN-1997 13:36:37.10 To: OCTAAF::_JOTY CC: Subj: Re: Arm Linux Date: Mon, 20 Jan 1997 12:25:15 +0000 (GMT) From: Philip Blundell X-Sender: pjb27@hammer.thor.cam.ac.uk To: Joseph Heenan Cc: linux-arm@vger.rutgers.edu Subject: Re: Arm Linux In-Reply-To: <28500.199701201213@lupin.csv.warwick.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk On Mon, 20 Jan 1997, Joseph Heenan wrote: > Perhaps I've got the wrong end of the stick here - I'd assumed > debian would be a lot of C sources that just need perhaps the odd > bit of inline assembler rewriting. Surely the C compiler should handle > all the platform specific things, apart from inline assembler? No. To take a contrived example, imagine you have this: unsigned char foo[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 }; unsigned int *bar; bar = (unsigned int *)(foo+1); printf("bar = %08x\n", *bar); On Intel, this gives: kings-cross:~$ ./align bar = 05040302 kings-cross:~$ On Alpha, this gives: paddington:~$ ./align align(1964): unaligned trap at 0000000120000a74: 000000011ffff711 28 2 bar = 05040302 paddington:~$ But on an old ARM, you will get `bar = 0x04030201'. The reason is that the dereference of `bar' compiles to an LDR instruction. In general, the compiler can't know the alignment at compile-time, so there's not a lot else it *can* do. Old ARM machines silently discard the low two address bits when you ask them to do a word access. This differs, as I said before, from the Intel (where you get the correct access performed, albeit more slowly) and the Alpha/SPARC/etc (where you get a fault, and your OS has to patch up in software). This sort of thing doesn't crop up *that* often, but it does happen, and code will go wrong when it does. There is *very* little inline assembler in most things, and I doubt much porting work will be needed in general. A lot of autoconf scripts will probably need to be taught about Linux/ARM, but other than that... > Basic sounds like quite a good idea. Shame it's copyright, really - > a basic interpretter running under general unix has some sort of appeal > to it :-) Yes. OTOH, although it's copyright, if it's in ROM it can be used fairly freely. Someone sufficiently sick could probably write a snippet of code to be run as root that rummages around the RISC OS ROMs and pulls out the BASIC module. P. From owner-linux-arm-outgoing@vger.rutgers.edu Mon Jan 20 13:19:17 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id NAA27829 for ; Mon, 20 Jan 1997 13:19:16 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <65911-8831>; Mon, 20 Jan 1997 15:17:35 +0200 Received: by vger.rutgers.edu id <213188-11748>; Mon, 20 Jan 1997 08:07:26 -0500 Message-Id: <199701201411.OAA23965@spider> Subject: Re: Arm Linux To: linux-arm@vger.rutgers.edu Date: Mon, 20 Jan 1997 14:11:08 +0000 (GMT) Reply-To: John.Tytgat@barco.com From: John.Tytgat@barco.com (John Tytgat) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO [Sorry about the previous non-reply...] On Mon, 20 Jan 1997, Philip Blundell wrote: > But on an old ARM, you will get `bar = 0x04030201'. The reason is that > the dereference of `bar' compiles to an LDR instruction. In general, the > compiler can't know the alignment at compile-time, so there's not a lot > else it *can* do. Old ARM machines silently discard the low two address > bits when you ask them to do a word access. This differs, as I said > before, from the Intel (where you get the correct access performed, albeit > more slowly) and the Alpha/SPARC/etc (where you get a fault, and your OS > has to patch up in software). Wouldn't it be the best that a StrongARM owner traces code like this (as the StrongARM can abort on such constructs when configured) ? Regards, John. From owner-linux-arm-outgoing@vger.rutgers.edu Mon Jan 20 22:02:13 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id WAA29307 for ; Mon, 20 Jan 1997 22:02:12 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <67801-19794>; Tue, 21 Jan 1997 00:01:14 +0200 Received: by vger.rutgers.edu id <213030-11751>; Mon, 20 Jan 1997 16:50:35 -0500 Date: Mon, 20 Jan 1997 21:48:31 +0000 (GMT) From: Philip Blundell X-Sender: pjb27@hammer.thor.cam.ac.uk To: John Tytgat cc: linux-arm@vger.rutgers.edu Subject: Re: Arm Linux In-Reply-To: <199701201411.OAA23965@spider> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO On Mon, 20 Jan 1997, John Tytgat wrote: > On Mon, 20 Jan 1997, Philip Blundell wrote: > > else it *can* do. Old ARM machines silently discard the low two address > > bits when you ask them to do a word access. This differs, as I said > > Wouldn't it be the best that a StrongARM owner traces code like this (as > the StrongARM can abort on such constructs when configured) ? Well, yes, and so can the ARM710 when you turn the MMU on (Linux does). The kernel doesn't tend to do this, so it's only user-space stuff you have to worry about. And there are plenty of other machines out there that report unaligned traps. There's no need to force a StrongARM person to trace every program out there -- if ARM3 people start reporting weird lossage, an alignment error is just something to bear in mind. P. From pjb27@thor.cam.ac.uk Tue Jan 21 17:17:54 1997 Return-Path: Received: from hammer.thor.cam.ac.uk (thorexim@hammer.thor.cam.ac.uk [131.111.8.39]) by odie.barnet.ac.uk (8.8.2/8.8.0) with SMTP id RAA30806 for ; Tue, 21 Jan 1997 17:17:53 GMT Received: from pjb27 by hammer.thor.cam.ac.uk with smtp (Exim 1.592 #2) id 0vmjpk-0002Rg-00; Tue, 21 Jan 1997 17:18:04 +0000 X-Received: from lilac.csi.cam.ac.uk [131.111.8.44] (exim) by hammer.thor.cam.ac.uk with smtp (Exim 1.592 #2) id 0vmjp1-0002QO-00; Tue, 21 Jan 1997 17:17:19 +0000 X-Received: from odie.barnet.ac.uk [194.82.202.98] (willy) by lilac.csi.cam.ac.uk with esmtp (Exim 1.58 #1) id 0vmjp2-0002MB-00; Tue, 21 Jan 1997 17:17:20 +0000 X-Received: (from willy@localhost) by odie.barnet.ac.uk (8.8.2/8.8.0) id RAA30799 for pjb27@cam.ac.uk; Tue, 21 Jan 1997 17:16:51 GMT From: Matthew Wilcox Message-Id: <199701211716.RAA30799@odie.barnet.ac.uk> Subject: Re: Arm Linux To: pjb27@cam.ac.uk (Philip Blundell) Date: Tue, 21 Jan 1997 17:16:51 +0000 (GMT) In-Reply-To: from "Philip Blundell" at Jan 19, 97 01:52:19 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit ReSent-Date: Tue, 21 Jan 1997 17:17:58 +0000 (GMT) ReSent-From: Philip Blundell ReSent-To: willy@odie.barnet.ac.uk ReSent-Message-ID: Resent-Sender: Philip Blundell Status: RO > - gcc. At the moment GCC doesn't generate such good code for the > ARM as Norcroft does, and this is a bit of a shame. > > - binutils. Last time I looked, binutils for the ARM was buggy. > > - ELF. Linux is moving to ELF, and we don't want to be left > behind. ELF is important for shared libraries, I'd like to generally get more involved with all the compiler stuff. I need to improve my C and I want to make some contribution back to GNU. I have the 2.6.3 sources at home & I've been reading the docs but I want to understand GCC better before I make any firm commitments to doing anything. > - Some sort of emulator to allow RISC OS binaries to run might be > a fun thing to have. Knowing me, this is the sort of project which I would start. And then never get finished. I could help here if other people are willing to work with me, but I'm not taking it on myself. Rewriting RISC OS in C designed to run on top of a fully-fledged unix sounds like quite a good idea anyway ;-) P.S. I think I may have sent you something destined for the list by accident. Would it be possible to forward it back to me? From pjb27@thor.cam.ac.uk Tue Jan 21 17:19:14 1997 Return-Path: Received: from hammer.thor.cam.ac.uk (thorexim@hammer.thor.cam.ac.uk [131.111.8.39]) by odie.barnet.ac.uk (8.8.2/8.8.0) with SMTP id RAA30813 for ; Tue, 21 Jan 1997 17:19:14 GMT Received: from pjb27 by hammer.thor.cam.ac.uk with smtp (Exim 1.592 #2) id 0vmjr9-0002VM-00; Tue, 21 Jan 1997 17:19:31 +0000 Date: Tue, 21 Jan 1997 17:19:31 +0000 (GMT) From: Philip Blundell X-Sender: pjb27@hammer.thor.cam.ac.uk To: Matthew Wilcox Subject: Re: Arm Linux In-Reply-To: <199701211716.RAA30799@odie.barnet.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Philip Blundell Status: RO On Tue, 21 Jan 1997, Matthew Wilcox wrote: > I'd like to generally get more involved with all the compiler stuff. I > need to improve my C and I want to make some contribution back to GNU. I > have the 2.6.3 sources at home & I've been reading the docs but I want to > understand GCC better before I make any firm commitments to doing > anything. Right. You probably want to get the 2.7.2 sources, just for the sake of being up to date. I must find out how imminent 2.8 is as well. > Knowing me, this is the sort of project which I would start. And then > never get finished. I could help here if other people are willing to work > with me, but I'm not taking it on myself. Rewriting RISC OS in C designed > to run on top of a fully-fledged unix sounds like quite a good idea anyway > ;-) Mmm. Well, I'd be interested in doing that myself, but at fairly low priority (glibc is top of my list right now). Interesting though a RISC OS emulator would be, I think it probably ought to wait for a while. > P.S. I think I may have sent you something destined for the list by > accident. Would it be possible to forward it back to me? I have done. phil From owner-linux-arm-outgoing@vger.rutgers.edu Tue Jan 21 22:47:50 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id WAA31296 for ; Tue, 21 Jan 1997 22:47:44 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <66007-26991>; Wed, 22 Jan 1997 00:47:16 +0200 Received: by vger.rutgers.edu id <213285-2094>; Tue, 21 Jan 1997 17:36:12 -0500 Message-Id: From: df@eyrie.demon.co.uk (Derek Fawcus) Subject: Alignment Check (was Re: Arm Linux) To: linux-arm@vger.rutgers.edu Date: Tue, 21 Jan 1997 00:16:12 +0100 (GMT) Cc: pjb27@cam.ac.uk, John.Tytgat@barco.com In-Reply-To: from "Philip Blundell" at Jan 20, 97 09:48:31 pm X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO Philip Blundell wrote: > On Mon, 20 Jan 1997, John Tytgat wrote: > > On Mon, 20 Jan 1997, Philip Blundell wrote: > > > else it *can* do. Old ARM machines silently discard the low two address > > > bits when you ask them to do a word access. This differs, as I said > > > > Wouldn't it be the best that a StrongARM owner traces code like this (as > > the StrongARM can abort on such constructs when configured) ? > > Well, yes, and so can the ARM710 when you turn the MMU on (Linux does). Well, according to the datasheet - so can the ARM610. So basically anyone with an ARM6 or above can do this. Probably more useful - (for the debian ppl), is the fact that the 80x86 family (for x >= 4), can also do alignment checks. All one needs to do is turn on bit 18 (AC) in the EFLAGS register, and then change the masks that the kernel uses to it won't turn it off again. DF -- Derek Fawcus df@eyrie.demon.co.uk From pjb27@thor.cam.ac.uk Wed Jan 22 01:33:51 1997 Return-Path: Received: from hammer.thor.cam.ac.uk (thorexim@hammer.thor.cam.ac.uk [131.111.8.39]) by odie.barnet.ac.uk (8.8.2/8.8.0) with SMTP id BAA31554 for ; Wed, 22 Jan 1997 01:33:51 GMT Received: from pjb27 by hammer.thor.cam.ac.uk with smtp (Exim 1.592 #2) id 0vmrZr-0007E3-00; Wed, 22 Jan 1997 01:34:11 +0000 Date: Wed, 22 Jan 1997 01:34:11 +0000 (GMT) From: Philip Blundell X-Sender: pjb27@hammer.thor.cam.ac.uk To: Matthew Wilcox cc: Charles Esson Subject: Re: arm linux In-Reply-To: <32E55ACC.4FE1@cvs.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Philip Blundell Status: RO On Wed, 22 Jan 1997, you wrote: > Aren't Cygnus Support supposed to be adding support for ELF to GCC? I wasn't aware that Cygnus were doing _any_ work for the ARM. But I could be wrong. Do you have any more details? P. From owner-linux-arm-outgoing@vger.rutgers.edu Wed Jan 22 02:43:06 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id CAA31623 for ; Wed, 22 Jan 1997 02:43:05 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <66249-19574>; Wed, 22 Jan 1997 04:41:57 +0200 Received: by vger.rutgers.edu id <213468-2093>; Tue, 21 Jan 1997 21:29:53 -0500 Date: Wed, 22 Jan 1997 01:19:04 +0000 (GMT) From: Philip Blundell X-Sender: pjb27@hammer.thor.cam.ac.uk To: linux-arm@vger.rutgers.edu Subject: Re: Arm Linux (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO This is from Russell. Philip Blundell writes: > 1. Kernel stuff > - ARM6 support. This ought not to be very difficult, given that > we have ARM3 and StrongARM already (and a good fraction of the > ARM6 stuff is in there anyway). There are plenty of people with > either RiscPCs or other ARM6-based hardware who would like to > run Linux. It should not very difficult - I have been redesigning the processor support in ARM Linux, and now have it done the correct way ;) A single Linux kernel should now be able to run on a RiscPC with ARM610/ARM710/SA110 processors. This appears to have temporarly broken the A5K and ARC code, and is under investigation when I have time. I have been borrowing someones ARM710 card, and I know that Linux now boots (I allow it to run 'til the end of the kernel initialisation only). The data abort handler code needs to be coded though (I don't have any information on this though), and some way of handling the IMPlementation specific bit in the page tables (= Updatable on the ARM610). The ARM610 port I believe is just another case of the above - the ARM610 and ARM710 I believe are very much alike. > - Merge with Linus' source tree. I think work is ongoing by > Russell on this, and the major obstacle at the moment is > probably Linus' lack of spare time. I have sorted out the memory management level code, however, I have to upload a new set of patches (sometime) for Alan to look into). > 2. General user-space stuff > - X. The Xserver for Archimedes hardware isn't really rocket > science, since VIDC just gives you a flat framebuffer. At the > moment I think we only have quite an old version, and it would > be nice to have the latest XFree86 ported (they really ought to > think about changing the name eventually...). The ARM Linux X source is not really based on XF86, except for setting up the keyboard and switching VTs on startup. My X port as it stands does not require XF86 in any way, and I believe that XF86 will only make it larger for older machines, and therefore slower due to swapping. This is the main problem on older machines. RiscPC's, X appears to fly. There is one improvement that I have planned for it, but I believe that it may cause more hastles than it is worth - allowing the X server to store the current key mappings (normally read out of the kernel) in a file. This would mean that it should startup quicker than it currently does. Oh - I am currenly seeing quite a few applications where the performance is severely reduced - perl for instance. Perl appears to take ages to do anything meaningful. > - Debian. Bruce Perens has shown some interest in having a Debian > port for the ARM, and it seems like a good idea. Indeed. This would be a great help - I can then concentrate solely on the kernel aspects (and maybe a few Acorn specific user level bits), rather than the whole project. > 3. Tools and stuff. > - ELF. Linux is moving to ELF, and we don't want to be left > behind. ELF is important for shared libraries, especially... I'd prefer to hold off on this until a standard appears. The reason is that it requires registration, and there are some complex issues that have to be addressed. I do have some tools that will read ELF arm in a very minor way, but it would be totally incorrect to create our own standard until one appears from ARM Ltd. The reason for this is that if we implement our own, and a standard does appear, then there will be major incompatabilities in the library and object files. > - glibc, or libc.so.6, is the new Linux shared library. It needs > to be ported to the ARM. This can be done after we have ELF support (since the latest libc versions are ELF only). Also, the 2.1.x kernels come into this category. The 2.1.x kernels have an altered memory management checking system (it no longer verifies addresses before using them [will this cause problems on old hardware?], instead they build up tables of possible faulting instructions. This will be extremely difficult for the ARM - we have an unrolled user memcpy routines in the kernel == loads of different addresses for faulting instructions, and the problem of how to generate the tables without ELF). So which great person decided to go all out for ELF? Is he mad? ELF will cause fundamental problems on the ARM3 machines - ELF appears to require a physical page to be mapped in twice, which is absolutely impossible on the ARM3 and older. On the StrongARM, it may be possible, but it'll mean being careful with the caches. It may cause cache consistency problems on the ARM6/ARM7 though since they use a combined data & instruction cache. > 4. Weird stuff. > - Some sort of emulator to allow RISC OS binaries to run might be > a fun thing to have. I think that this may be more of a disadvantage than an advantage. There will obviously be several SWI's that just cannot be implemented - OS_EnterOS, OS_Memory, OS_SetMemMapEntries, OS_IntOff etc. I believe that basic may require at least OS_EnterOS, but that may be wrong. _____ |_____| ------------------------------------------------- ---+---+- | | Russell King rmk92@ecs.soton.ac.uk --- --- | | | | http://whirligig.ecs.soton.ac.uk/~rmk92/home.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | * who wishes that he was in Hong Kong * --- | +-+-+ ------------------------------------------------- /\\\ | From owner-linux-arm-outgoing@vger.rutgers.edu Wed Jan 22 02:43:07 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id CAA31625 for ; Wed, 22 Jan 1997 02:43:06 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <65670-19574>; Wed, 22 Jan 1997 04:42:02 +0200 Received: by vger.rutgers.edu id <213477-2093>; Tue, 21 Jan 1997 21:30:23 -0500 Date: Wed, 22 Jan 1997 01:29:44 +0000 (GMT) From: Philip Blundell X-Sender: pjb27@hammer.thor.cam.ac.uk To: rmk cc: linux-arm@vger.rutgers.edu Subject: Re: Arm Linux In-Reply-To: <178.199701220042@caramon.armlinux.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO On Wed, 22 Jan 1997, rmk wrote: > It should not very difficult - I have been redesigning the processor support > in ARM Linux, and now have it done the correct way ;) :) > page tables (= Updatable on the ARM610). The ARM610 port I believe is just > another case of the above - the ARM610 and ARM710 I believe are very much > alike. They are. As far as I can tell the only difference is the cache size, and someone from NetBSD posted that there is some difference in abort handling as well. I've got both data sheets here, but I haven't trawled through them with a fine-toothed comb to see if there are any other differences. > I have sorted out the memory management level code, however, I have to upload > a new set of patches (sometime) for Alan to look into). Right. Well, no great rush. > > 3. Tools and stuff. > > - ELF. Linux is moving to ELF, and we don't want to be left > > behind. ELF is important for shared libraries, especially... > > I'd prefer to hold off on this until a standard appears. The reason is that > it requires registration, and there are some complex issues that have to be > addressed. I do have some tools that will read ELF arm in a very minor way, > but it would be totally incorrect to create our own standard until one appears > from ARM Ltd. I think we should work with ARM Ltd to produce a standard, if need be. IMHO, ELF is important. There is no point investing effort in dead technology. > The reason for this is that if we implement our own, and a standard does > appear, then there will be major incompatabilities in the library and > object files. Yes, but if we run with a.out now, then all library and object files will be utterly useless when ELF does appear. > > - glibc, or libc.so.6, is the new Linux shared library. It needs > > to be ported to the ARM. > > This can be done after we have ELF support (since the latest libc versions are > ELF only). I know. OTOH, preliminary work can be started before we have ELF. For example, ARM-code versions of many functions must be written - anybody who enjoys writing optimised assembler is welcome to pitch in to this effort. It is important that we have a stable C library. If we are still running from a ported libc 4, that is not good enough - even if you've been amazingly dilligent, the chances are that it still contains bugs, and that performance is going to be less than that of glibc. It also lacks many features, like threads, and introduces a compatibility nightmare (right now, I'm going through the pain of making code compile for glibc -- I don't want to have to do this in reverse for the ARM at a later date). > Also, the 2.1.x kernels come into this category. The 2.1.x kernels have an > altered memory management checking system (it no longer verifies addresses > before using them [will this cause problems on old hardware?] I was thinking about this the other week. I believe we should be OK. Can you provide any examples of scenarios that will go wrong? > instead they build up tables of possible faulting instructions. This > will be extremely difficult for the ARM - we have an unrolled user > memcpy routines in the kernel == loads of different addresses for > faulting instructions, and the problem of how to generate the tables > without ELF). I believe the first of these has already been addressed (by davem, I think) - you can give a _range_ of faulting instructions. I think this should cover virtually every case, since exceptions only tend to turn up in constructs like: if (copy_from_user(...)) return -EINVAL; where the only instructions that can fault are the user-space accesses, and any one of them faulting means the same thing. If there are any more complex uses of exceptions we may have to think more carefully, but I don't think there is any fundamental problem. The second is more of an issue, and is yet another reason why I believe we should go for ELF. > So which great person decided to go all out for ELF? Is he mad? He was probably just fed up with building a.out shared libraries. In the real world you _cannot_ insist that everybody pick a unique base address for their library. It totally stifles development. > ELF will cause fundamental problems on the ARM3 machines - ELF appears to > require a physical page to be mapped in twice, which is absolutely impossible > on the ARM3 and older. That's bad. I shall have to have a think about that one. > > 4. Weird stuff. > > - Some sort of emulator to allow RISC OS binaries to run might be > > a fun thing to have. > > I think that this may be more of a disadvantage than an advantage. There > will obviously be several SWI's that just cannot be implemented - OS_EnterOS, > OS_Memory, OS_SetMemMapEntries, OS_IntOff etc. I believe that basic may > require at least OS_EnterOS, but that may be wrong. Yes, obviously. I wasn't suggesting we implement the whole of RISC OS, but I believe something that can run simple applications would be doable, entertaining and potentially useful. I can't see how it could be a disadvantage. phil From owner-linux-arm-outgoing@vger.rutgers.edu Wed Jan 22 02:53:37 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id CAA31637 for ; Wed, 22 Jan 1997 02:53:36 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <66362-19574>; Wed, 22 Jan 1997 04:51:37 +0200 Received: by vger.rutgers.edu id <213683-2093>; Tue, 21 Jan 1997 21:40:13 -0500 From: rmk Message-Id: <186.199701220046@caramon.armlinux.org> Subject: Re: Arm Linux To: linux-arm@vger.rutgers.edu Date: Wed, 22 Jan 1997 00:46:32 +0000 (GMT) In-Reply-To: <32E4799F.475@cvs.com.au> from "Charles Esson" at Jan 21, 97 07:09:03 pm X-Phone: +44 (0)1737 360654 Reply-To: rmk92@ecs.soton.ac.uk X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO Charles Esson writes: > It's a pity that Russell is away for two weeks as his comments are > obviously needed. I didn't say that I'd be away - I said that I was working long hours, and there was the possibility of having to go away on business. However, dispite my workload, I can still read email in the evenings [at obscure and probably health damaging times]. _____ |_____| ------------------------------------------------- ---+---+- | | Russell King rmk92@ecs.soton.ac.uk --- --- | | | | http://whirligig.ecs.soton.ac.uk/~rmk92/home.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | * who wishes that he was in Hong Kong * --- | +-+-+ ------------------------------------------------- /\\\ | From owner-linux-arm-outgoing@vger.rutgers.edu Wed Jan 22 09:18:59 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id JAA31996 for ; Wed, 22 Jan 1997 09:18:58 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <65594-26991>; Wed, 22 Jan 1997 11:18:47 +0200 Received: by vger.rutgers.edu id <213091-2093>; Wed, 22 Jan 1997 04:07:58 -0500 From: Matthew Wilcox Message-Id: <199701220917.JAA31988@odie.barnet.ac.uk> Subject: Re: Arm Linux (fwd) To: linux-arm@vger.rutgers.edu Date: Wed, 22 Jan 1997 09:17:22 +0000 (GMT) In-Reply-To: from "Philip Blundell" at Jan 22, 97 01:19:04 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO > > 4. Weird stuff. > > - Some sort of emulator to allow RISC OS binaries to run might be > > a fun thing to have. > > I think that this may be more of a disadvantage than an advantage. There > will obviously be several SWI's that just cannot be implemented - OS_EnterOS, > OS_Memory, OS_SetMemMapEntries, OS_IntOff etc. I believe that basic may > require at least OS_EnterOS, but that may be wrong. Can't be implemented in a naive manner, maybe. It would be feasible to write a RISC OS emulator that kept track of what state a virtual processor had and decided whether or not to allow certain accesses on that basis. For example, interrupts would have to be implemented by the use of signals, calling os_intoff would simply disable signals from being delivered until os_inton was called again. The trick is deciding at what level we want to emulate a RISC OS environment - booting RISC OS on the ARMulator is one possibility, but it would be extremely slow (and requires additions to the ARMulator to emulate iomd, vidc et al). A replacement kernel that handles loading extension modules is another possibility - but rather tricky. Writing replacement modules that implement the RISC OS API is the cleanest solution, but it's the biggest job to do. The main problem as I see it is the 26/32 bitness - does Linux/ARM run in 32 bit modes on capable processors? Is it possible for different processes to be run in 26 bit mode? I'd like to know more about the design of the kernel and its implementation on the ARM. Does anyone have any good references for an overview of the kernel? I have the source, but it's rather tricky to understand the design from that. From owner-linux-arm-outgoing@vger.rutgers.edu Wed Jan 22 09:26:57 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id JAA32031 for ; Wed, 22 Jan 1997 09:26:56 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <65747-26991>; Wed, 22 Jan 1997 11:26:41 +0200 Received: by vger.rutgers.edu id <212997-2093>; Wed, 22 Jan 1997 04:15:54 -0500 From: Matthew Wilcox Message-Id: <199701220925.JAA32008@odie.barnet.ac.uk> Subject: Unaligned accesses To: John.Tytgat@barco.com Date: Wed, 22 Jan 1997 09:25:02 +0000 (GMT) Cc: linux-arm@vger.rutgers.edu In-Reply-To: <199701201340.NAA23883@spider> from "John Tytgat" at Jan 20, 97 01:40:17 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO > > But on an old ARM, you will get `bar = 0x04030201'. The reason is that > the dereference of `bar' compiles to an LDR instruction. In general, the > compiler can't know the alignment at compile-time, so there's not a lot > else it *can* do. Old ARM machines silently discard the low two address > bits when you ask them to do a word access. This differs, as I said > before, from the Intel (where you get the correct access performed, albeit > more slowly) and the Alpha/SPARC/etc (where you get a fault, and your OS > has to patch up in software). To be pedantic.. you will get 'bar = 0x01040302'. It's the MEMC's fault rather than the ARM's fault - it could pull the ABRT line high and allow the OS to patch up in software. Or it could do two memory accesses and give the word that you wanted. But it does neither of these things. And it's a bit late to demand a new version of the MEMC from ARMltd! From owner-linux-arm-outgoing@vger.rutgers.edu Wed Jan 22 13:22:42 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id NAA32259 for ; Wed, 22 Jan 1997 13:22:41 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <67520-26991>; Wed, 22 Jan 1997 15:22:04 +0200 Received: by vger.rutgers.edu id <213214-2094>; Wed, 22 Jan 1997 08:10:59 -0500 Date: Wed, 22 Jan 1997 13:18:12 +0000 (GMT) From: Philip Blundell X-Sender: pjb27@hammer.thor.cam.ac.uk To: rmk cc: linux-arm@vger.rutgers.edu Subject: Re: Arm Linux In-Reply-To: <178.199701220042@caramon.armlinux.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO On Wed, 22 Jan 1997, rmk wrote: > Also, the 2.1.x kernels come into this category. The 2.1.x kernels have an > altered memory management checking system (it no longer verifies addresses > before using them [will this cause problems on old hardware?], instead they > build up tables of possible faulting instructions. This will be extremely > difficult for the ARM - we have an unrolled user memcpy routines in the kernel > == loads of different addresses for faulting instructions, and the problem of > how to generate the tables without ELF). > > So which great person decided to go all out for ELF? Is he mad? A more serious problem with 2.1, actually, which we need ELF to fix, is that it starts to make heavier use of special sections (via gcc __asm__ magic). Exception fixup stuff goes in a new section, so that it's taken out of line, and there are moves afoot to put all the kernel initialisation code in another section so it can be thrown away after boot time. I have a feeling Richard's new modules code does some stuff with ELF as well. P. From owner-linux-arm-outgoing@vger.rutgers.edu Wed Jan 22 14:01:55 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id OAA32297 for ; Wed, 22 Jan 1997 14:01:54 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <67697-26991>; Wed, 22 Jan 1997 16:01:22 +0200 Received: by vger.rutgers.edu id <213041-2094>; Wed, 22 Jan 1997 08:50:37 -0500 From: e.j.r.leyssens@student.utwente.nl X-Authentication-Warning: cal013212.student.utwente.nl: eli owned process doing -bs Date: Wed, 22 Jan 1997 14:58:58 +0100 (MET) X-Sender: eli@cal013212.student.utwente.nl To: linux-arm@vger.rutgers.edu Subject: Writing adfs-fs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO I've recently started out writing an adfs-fs for linux. I have now come to the point where I can see it isn't going to be one of 'those projects you never finish' so before really putting huge amounts of time into it I'd like to know whether a) somebody else is writing one too, and how far they've gotten already b) somebody else HAS already written one. Cheers, -- Eli-Jean Leyssens, alias Pervect of Topix email: e.j.r.leyssens@student.utwente.nl --- It's an OS Bill, but not as we know it --- From owner-linux-arm-outgoing@vger.rutgers.edu Wed Jan 22 14:16:26 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id OAA32311 for ; Wed, 22 Jan 1997 14:16:25 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <67507-19574>; Wed, 22 Jan 1997 16:16:14 +0200 Received: by vger.rutgers.edu id <213189-2094>; Wed, 22 Jan 1997 09:05:21 -0500 Message-Id: <199701221508.PAA00373@spider> Subject: Re: Writing adfs-fs To: linux-arm@vger.rutgers.edu Date: Wed, 22 Jan 1997 15:08:35 +0000 (GMT) Reply-To: John.Tytgat@barco.com From: John.Tytgat@barco.com (John Tytgat) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO > I've recently started out writing an adfs-fs for linux. I have now come to > the point where I can see it isn't going to be one of 'those projects you > never finish' so before really putting huge amounts of time into it I'd like > to know whether a) somebody else is writing one too, and how far they've > gotten already b) somebody else HAS already written one. Interesting, but I'm wondering why you call it 'adfs-fs' and not e.g. 'FileCore-fs' or something alike. I hope you're not going to limit yourself to ADFS disks only... If you need technical information about FileCore, perhaps you can have a word with the author of 'fsck'/'fsck2', an italian person AFAIK. Regards, John. John.Tytgat@barco.com From pjb27@thor.cam.ac.uk Wed Jan 22 23:26:41 1997 Return-Path: Received: from hammer.thor.cam.ac.uk (thorexim@hammer.thor.cam.ac.uk [131.111.8.39]) by odie.barnet.ac.uk (8.8.2/8.8.0) with SMTP id XAA00365 for ; Wed, 22 Jan 1997 23:26:41 GMT Received: from pjb27 by hammer.thor.cam.ac.uk with smtp (Exim 1.592 #2) id 0vnC4U-0004qc-00; Wed, 22 Jan 1997 23:27:10 +0000 Date: Wed, 22 Jan 1997 23:27:10 +0000 (GMT) From: Philip Blundell X-Sender: pjb27@hammer.thor.cam.ac.uk To: Matthew Wilcox cc: John.Tytgat@barco.com, linux-arm@vger.rutgers.edu Subject: Re: Unaligned accesses In-Reply-To: <199701220925.JAA32008@odie.barnet.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Philip Blundell Status: RO On Wed, 22 Jan 1997, Matthew Wilcox wrote: > > But on an old ARM, you will get `bar = 0x04030201'. The reason is that > To be pedantic.. you will get 'bar = 0x01040302'. It's the MEMC's fault Uh, yeah, brain out of gear there. But the point is valid -- you won't get what you'd naively expect (and what you get on other architectures), and - worse - you have no way of knowing that the result you've just picked up is duff. P. From owner-linux-arm-outgoing@vger.rutgers.edu Thu Jan 23 03:33:02 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id DAA00591 for ; Thu, 23 Jan 1997 03:32:58 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <68145-2441>; Thu, 23 Jan 1997 05:31:57 +0200 Received: by vger.rutgers.edu id <213393-25000>; Wed, 22 Jan 1997 22:20:08 -0500 From: Matthew Wilcox Message-Id: <199701221610.QAA32436@odie.barnet.ac.uk> Subject: Re: Writing adfs-fs To: John.Tytgat@barco.com Date: Wed, 22 Jan 1997 16:09:59 +0000 (GMT) Cc: linux-arm@vger.rutgers.edu In-Reply-To: <199701221508.PAA00373@spider> from "John Tytgat" at Jan 22, 97 03:08:35 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO > If you need technical information about FileCore, perhaps you can have > a word with the author of 'fsck'/'fsck2', an italian person AFAIK. I think sufficient information is contained in the PRM volume 2 to write a filecorefs. Sergio Monesi is the name of the guy you're thinking of (and Simon Proven probably knows more about Filecore than any other person alive ;-) Of course, the advantage to having this is huge: being able to mount ones filecore partition under linux, much as one can mount ones dos partition under linux.. From owner-linux-arm-outgoing@vger.rutgers.edu Thu Jan 23 03:34:01 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id DAA00596 for ; Thu, 23 Jan 1997 03:34:01 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <68099-6429>; Thu, 23 Jan 1997 05:33:33 +0200 Received: by vger.rutgers.edu id <213399-24999>; Wed, 22 Jan 1997 22:22:07 -0500 From: e.j.r.leyssens@student.utwente.nl X-Authentication-Warning: cal013212.student.utwente.nl: eli owned process doing -bs Date: Wed, 22 Jan 1997 18:08:16 +0100 (MET) X-Sender: eli@cal013212.student.utwente.nl To: linux-arm@vger.rutgers.edu Subject: Re: Writing adfs-fs In-Reply-To: <199701221508.PAA00373@spider> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO On Wed, 22 Jan 1997, John Tytgat wrote: > > I've recently started out writing an adfs-fs for linux. I have now come to > > the point where I can see it isn't going to be one of 'those projects you > > never finish' so before really putting huge amounts of time into it I'd like > > to know whether a) somebody else is writing one too, and how far they've > > gotten already b) somebody else HAS already written one. > > Interesting, but I'm wondering why you call it 'adfs-fs' and not > e.g. 'FileCore-fs' or something alike. I hope you're not going to > limit yourself to ADFS disks only... > > If you need technical information about FileCore, perhaps you can have > a word with the author of 'fsck'/'fsck2', an italian person AFAIK. Now that you mention it, yes, it would probably better be named FileCore-fs as that is what I'm writing As far as the technical information is concerned, I've got the PRMs right here with me and have already done several disc utilities so I know what I'm doing. Thanks for the advice anyways. Cheers, -- Eli-Jean Leyssens, alias Pervect of Topix email: e.j.r.leyssens@student.utwente.nl --- It's an OS Bill, but not as we know it --- From owner-linux-arm-outgoing@vger.rutgers.edu Thu Jan 23 03:45:53 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id DAA00609 for ; Thu, 23 Jan 1997 03:45:52 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <67459-29227>; Thu, 23 Jan 1997 05:45:26 +0200 Received: by vger.rutgers.edu id <213404-24999>; Wed, 22 Jan 1997 22:26:28 -0500 Date: Wed, 22 Jan 1997 23:27:10 +0000 (GMT) From: Philip Blundell X-Sender: pjb27@hammer.thor.cam.ac.uk To: Matthew Wilcox cc: John.Tytgat@barco.com, linux-arm@vger.rutgers.edu Subject: Re: Unaligned accesses In-Reply-To: <199701220925.JAA32008@odie.barnet.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO On Wed, 22 Jan 1997, Matthew Wilcox wrote: > > But on an old ARM, you will get `bar = 0x04030201'. The reason is that > To be pedantic.. you will get 'bar = 0x01040302'. It's the MEMC's fault Uh, yeah, brain out of gear there. But the point is valid -- you won't get what you'd naively expect (and what you get on other architectures), and - worse - you have no way of knowing that the result you've just picked up is duff. P. From owner-linux-arm-outgoing@vger.rutgers.edu Thu Jan 23 05:01:52 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id FAA00691 for ; Thu, 23 Jan 1997 05:01:51 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <68154-6429>; Thu, 23 Jan 1997 06:57:40 +0200 Received: by vger.rutgers.edu id <213315-328>; Wed, 22 Jan 1997 22:59:18 -0500 Date: Wed, 22 Jan 1997 15:05:42 +0000 (GMT) From: Philip Blundell X-Sender: pjb27@hammer.thor.cam.ac.uk To: linux-arm@vger.rutgers.edu Subject: Re: Arm Linux In-Reply-To: <178.199701220042@caramon.armlinux.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO On Wed, 22 Jan 1997, rmk wrote: > ELF will cause fundamental problems on the ARM3 machines - ELF appears to > require a physical page to be mapped in twice, which is absolutely impossible > on the ARM3 and older. On the StrongARM, it may be possible, but it'll mean > being careful with the caches. It may cause cache consistency problems on the > ARM6/ARM7 though since they use a combined data & instruction cache. On a more philosophical point, I don't believe we should sacrifice features or performance on new machines for the sake of retaining ARM3 compatibility. Linux on my A5000 is never going to be more than an amusing toy, whereas Linux on the 610/710/StrongARM has real-world applications. Thus, if it _does_ turn out that we can't implement ELF on the ARM3, tough - people with old machines will have to stick to a.out and take the consequences, but we should still develop ELF for the benefit of those with the newer technology. P. From owner-linux-arm-outgoing@vger.rutgers.edu Thu Jan 23 21:26:17 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id VAA02510 for ; Thu, 23 Jan 1997 21:26:17 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <67566-29227>; Thu, 23 Jan 1997 23:25:51 +0200 Received: by vger.rutgers.edu id <213030-328>; Thu, 23 Jan 1997 16:14:24 -0500 Message-Id: <199701232027.UAA22838@woodlea.wintermute.co.uk> Comments: Authenticated sender is From: "Graham Mitchell" To: rmk , linux-arm@vger.rutgers.edu Date: Thu, 23 Jan 1997 20:32:04 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Arm Linux Reply-to: gmitch@woodlea.co.uk X-mailer: Pegasus Mail for Win32 (v2.42a) Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO > However, dispite my workload, I can still read email in the evenings > [at obscure and probably health damaging times]. Welcome to the real world.....:(( For the first time that i can remember, I'm reading my email before midnight. Must have something to do with the fact that 3rd Rock is coming on.....:)) Graham Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. From rmk92@ecs.soton.ac.uk Thu Jan 23 23:20:59 1997 Return-Path: Received: from acacia.sucs.soton.ac.uk (acacia.sucs.soton.ac.uk [152.78.128.232]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id XAA02682 for ; Thu, 23 Jan 1997 23:20:59 GMT From: rmk92@ecs.soton.ac.uk Received: from bright.ecs.soton.ac.uk (bright.ecs.soton.ac.uk [152.78.64.201]) by acacia.sucs.soton.ac.uk (8.8.2/server) with SMTP id XAA04815 for ; Thu, 23 Jan 1997 23:21:40 GMT Received: from caramon.armlinux.org (annex4) by bright.ecs.soton.ac.uk; Thu, 23 Jan 97 23:20:55 GMT Received: from raistlin.armlinux.org by caramon.armlinux.org; Thu, 23 Jan 1997 22:49:09 GMT Message-Id: <2276.199701232249@raistlin.armlinux.org> Subject: Re: Arm Linux (fwd) To: willy@odie.barnet.ac.uk (Matthew Wilcox) Date: Thu, 23 Jan 1997 22:49:01 +0000 (GMT) In-Reply-To: <199701220917.JAA31988@odie.barnet.ac.uk> from "Matthew Wilcox" at Jan 22, 97 09:17:22 am X-Phone: +44 (0)1737 360654 Reply-To: rmk92@ecs.soton.ac.uk X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Matthew Wilcox writes: > The trick is deciding at what level we want to emulate a RISC OS > environment - booting RISC OS on the ARMulator is one possibility, but it > would be extremely slow (and requires additions to the ARMulator to > emulate iomd, vidc et al). Dave Gilbert has a version of the ARMulator (with bug fixes) that allows RiscOS 2 to run. The ARMulator appears to have some very serious bugs, and in fact, Linux trips up on some of them at the moment. This idea I believe may well be the most viable. > A replacement kernel that handles loading extension modules is another > possibility - but rather tricky. Writing replacement modules that > implement the RISC OS API is the cleanest solution, but it's the biggest > job to do. Linux already handles loadable modules! Even dynamic loading and removing of modules. This would provide a neat way of providing this, and may even allow some of the RiscOS modules to be used. However, since the system is 32bit, any device drivers would have to be re-written. Memory mapping would be an interesting issue. > The main problem as I see it is the 26/32 bitness - does Linux/ARM run in > 32 bit modes on capable processors? Is it possible for different > processes to be run in 26 bit mode? On the ARM, you don't have 'virtual machines' as you do on the 386. The kernel does run in 32 bit, but the binaries run in 26 bit. 32 bit binaries will be implemented eventually though. Note also, that the StrongARM does not support 26-bit exception handlers, but I believe this to be irrelevent. I have heard rumors that 26-bit support will be dropped completely later. One of the problems is that the ARM does not fault priviledged instructions as the x86 hardware does. If it did, then there would be a strong possibility of using most of the RiscOS proms as they stand. _____ |_____| ------------------------------------------------- ---+---+- | | Russell King rmk92@ecs.soton.ac.uk --- --- | | | | http://whirligig.ecs.soton.ac.uk/~rmk92/home.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | * who wishes that he was in Hong Kong * --- | +-+-+ ------------------------------------------------- /\\\ | From owner-linux-arm-outgoing@vger.rutgers.edu Thu Jan 23 23:25:30 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id XAA02689 for ; Thu, 23 Jan 1997 23:25:29 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <68375-2486>; Fri, 24 Jan 1997 01:24:06 +0200 Received: by vger.rutgers.edu id <212997-330>; Thu, 23 Jan 1997 18:12:18 -0500 From: rmk92@ecs.soton.ac.uk Message-Id: <1750.199701232228@raistlin.armlinux.org> Subject: Re: Unaligned accesses To: linux-arm@vger.rutgers.edu Date: Thu, 23 Jan 1997 22:28:29 +0000 (GMT) In-Reply-To: from "Philip Blundell" at Jan 22, 97 11:27:10 pm X-Phone: +44 (0)1737 360654 Reply-To: rmk92@ecs.soton.ac.uk X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO Philip Blundell writes: > Uh, yeah, brain out of gear there. But the point is valid -- you won't > get what you'd naively expect (and what you get on other architectures), > and - worse - you have no way of knowing that the result you've just > picked up is duff. If this talk about unaligned accesses is about the X server, then it is entirely irrelevent. The generic code will use aligned accesses whenever possible anyway, since one of the pieces of information that the Colour Frame Buffer requires is the number of pixels per word. The only improvement that can be made is to replace the low-level routines with assembly versions. Below, I have included the assembly code for the vertical/horizontal line drawing routines (cfbhrzvert.c). It has other areas that can provide a significant improvement: begin 644 /tmp/lines.zip M4$L#!!0``@`(`&:Q52!'E!KOX@,``,H<```,````8V9B:')Z=F5R="YS[5A+ MC]LV$#Y+OX*!KZXKZFT!!5+TT![42POT4FP%/6A#@%ZAY#1IT?_>&3X4R:ON MVK$3NX`/7(@$WOC;RRR:SGY_I>?OXW+ MYO#!A'4[R=NZ*RM6;"(S29)]L&9+= MH4#IFA%U>N!,2-7($+(*J^P6ENFT95<(.#A[_OA-*3 M6@GU2JA7;+U";5BJ#Y580E6$28O"$/XY.%^3M*_("M:S,C>$[P"XB<#B'$U8$H&U?";O!^V'1JB*FJ6"!R\RI^\$:_XP8TR;\3@J"/9B M$)RC((BK`,G*.C_,SK$%;RF80.F&29Q`DAKLZ!7ACJ`SK`AZ"%6.S(O=2$C8 M.RD)/DF\2'F^520"[=B?GR8#O3@()H$1264]*4KK&Z#/;VB\X^,;*KLG>81, M0,<4:Y^06E,I9C&ZC&-%T:W&T-_"K>U#ZXMHP:5$KZ@B4RB\(UM-(4_2!7/N MW5E9]QJQO"-B>2\22R&1AZ M&/H?&()'XI17VW8@HZS+G^WQ8?0N?AB]%Q_&SWS2_Z.7_8WQ0?:RXNOFO>QI MO:OW>N^*`//>%1$F[20J:&;HKG3>T,YZG$F+6Z6?^D[5RXU-CKJOD4RZC0@M M>912'T5Q47\O,NZ(87A"P1$S#AW9(F2J2W04*]"NI,C<)VR'3C#Q$B*].J)] M=43GZHCNU1&]JR/ZUT*<$32<$_38@F2ULUB(YKU$.*NN^B=\Z%^:$'&XE3^$ MCH\ABJ+8SZ7]'H^<5A>TIQ\*.+ MZ\#67:X#XX\J'.Z-ZL(E3M![<,*^!R><>W#"O0AWZ M%U!+`0(4`Q0``@`(`&:Q52!'E!KOX@,``,H<```,``````````$```"`@0`` D``!C9F)H Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id AAA02776 for ; Fri, 24 Jan 1997 00:02:38 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <68149-29227>; Fri, 24 Jan 1997 02:00:36 +0200 Received: by vger.rutgers.edu id <213214-328>; Thu, 23 Jan 1997 18:46:09 -0500 Date: Thu, 23 Jan 1997 23:55:16 +0000 (GMT) From: Philip Blundell X-Sender: pjb27@hammer.thor.cam.ac.uk To: rmk92@ecs.soton.ac.uk cc: linux-arm@vger.rutgers.edu Subject: Re: Unaligned accesses In-Reply-To: <1750.199701232228@raistlin.armlinux.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO On Thu, 23 Jan 1997 rmk92@ecs.soton.ac.uk wrote: > If this talk about unaligned accesses is about the X server, then it is > entirely irrelevent. The generic code will use aligned accesses whenever > possible anyway, since one of the pieces of information that the Colour > Frame Buffer requires is the number of pixels per word. It's not. There is much user-space software out there, some of it quite fundamental (eg fdisk) that does unaligned accesses. This is quite a problem for us -- Alpha people and the like can fix the ones that happen often and ignore the rest, because they just take a tiny performance hit. But on the ARM there is the possibility to actually get wrong data from an unaligned access, and this is something that people who are going to port packages need to watch out for. It's not likely to apply to anything that was developed with the ARM in mind, like your X server. P. From owner-linux-arm-outgoing@vger.rutgers.edu Fri Jan 24 00:53:55 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id AAA02813 for ; Fri, 24 Jan 1997 00:53:54 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <68001-6429>; Fri, 24 Jan 1997 02:51:30 +0200 Received: by vger.rutgers.edu id <213162-330>; Thu, 23 Jan 1997 19:35:23 -0500 Date: Fri, 24 Jan 1997 00:42:02 +0000 (GMT) From: Philip Blundell X-Sender: pjb27@hammer.thor.cam.ac.uk To: linux-arm@vger.rutgers.edu Subject: ELF Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO Apparently there _is_ an ELF standard for the ARM. I hope to get hold of it tomorrow. More news when we have it. phil From owner-linux-arm-outgoing@vger.rutgers.edu Fri Jan 24 02:25:17 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id CAA02891 for ; Fri, 24 Jan 1997 02:25:16 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <67790-2486>; Fri, 24 Jan 1997 04:24:12 +0200 Received: by vger.rutgers.edu id <213030-328>; Thu, 23 Jan 1997 21:08:23 -0500 Message-ID: <32E81A2E.27FE@cvs.com.au> Date: Fri, 24 Jan 1997 13:20:08 +1100 From: Charles Esson Reply-To: charlese@cvs.com.au Organization: Colour Vision Systems X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: pjb27@cam.ac.uk CC: linux-arm@vger.rutgers.edu Subject: ELF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO Been reading up on ELF. One of the requirements for ELF is position independent code. The FSF C++ hasn't got the ARM in the list of processors that it can produce position independent code for. Does anyone have any comments. -- Charles Esson Colour Vision Systems 11 Park Street, Bacchus March, Victoria, Australia 3340. Phone: 61 53 673155, Fax: 61 53 674480 From owner-linux-arm-outgoing@vger.rutgers.edu Fri Jan 24 11:22:04 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id LAA03387 for ; Fri, 24 Jan 1997 11:22:03 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <66188-6429>; Fri, 24 Jan 1997 13:21:56 +0200 Received: by vger.rutgers.edu id <213037-330>; Fri, 24 Jan 1997 06:10:23 -0500 Date: Fri, 24 Jan 1997 11:20:57 +0000 (GMT) From: Philip Blundell X-Sender: pjb27@hammer.thor.cam.ac.uk To: Charles Esson cc: linux-arm@vger.rutgers.edu Subject: Re: ELF In-Reply-To: <32E81A2E.27FE@cvs.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO On Fri, 24 Jan 1997, Charles Esson wrote: > One of the requirements for ELF is position independent code. The FSF > C++ hasn't got the ARM in the list of processors that it can produce > position independent code for. This is true. We always thought that ELF would require some changes to gcc and binutils. P. From owner-linux-arm-outgoing@vger.rutgers.edu Mon Jan 27 22:29:09 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id WAA10145 for ; Mon, 27 Jan 1997 22:29:08 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <67789-28739>; Tue, 28 Jan 1997 00:28:36 +0200 Received: by vger.rutgers.edu id <213037-245>; Mon, 27 Jan 1997 17:26:43 -0500 Message-ID: <32ED2C3D.3DE3@cvs.com.au> Date: Tue, 28 Jan 1997 09:29:17 +1100 From: Charles Esson Reply-To: charlese@cvs.com.au Organization: Colour Vision Systems X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: pjb27@cam.ac.uk CC: linux-arm@vger.rutgers.edu Subject: Arm-linux Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO The reply from Mark !!!!!!!!!!!!!!!!!!!!!!!!!!!! Hi, Hmmm I cannot comment on ARMLinux as I am not involved with it or use it. This seems just to be a question of whether NetBSD/arm32 has ELF support or not.I know Linux in general has moved over to ELF and I assume that ARMLinux will follow the same trend. RiscBSD currently does not use ELF and currently there is no need for us to implement ELF support other than to provide support for running Linux binaries in Linux compatibility mode. I don't know all the reasons that Linux switched to ELF but I understand that shared libraries was one of the reasons. Currently we see no problems with using a.out for shared libraries. (Note: We do not implement a.out shared libraries the way Linux did rather we use position independant code.) NetBSD does have ELF support for some platforms and when ELF is available for GCC/arm we will have support for it but at the moment it is not something I am putting any time into to implement as it will not give us anything we don't have with a.out. If this does not answer all your questions please drop me a line. Cheers, Mark !!!!!!!!!!!!!!!!!!!!!!!!!!!! I spent the weekend looking at binutils. Arm support seems to be reasonable complete. You mentioned that it was buggy. Could you please supply more details. I also spent time looking at gcc, I still don't think it supports position independent code but Mark's reply would suggest other wise I will ask ( If I am going to make a fool of myself I may as well do a good job). -- Charles Esson Colour Vision Systems 11 Park Street, Bacchus March, Victoria, Australia 3340. Phone: 61 53 673155, Fax: 61 53 674480 From owner-linux-arm-outgoing@vger.rutgers.edu Tue Jan 28 11:07:08 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id LAA11029 for ; Tue, 28 Jan 1997 11:07:07 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <68468-28739>; Tue, 28 Jan 1997 13:06:21 +0200 Received: by vger.rutgers.edu id <213265-245>; Tue, 28 Jan 1997 06:04:31 -0500 Date: Tue, 28 Jan 1997 11:05:26 +0000 (GMT) From: Ale Terlevich To: Charles Esson Cc: pjb27@cam.ac.uk, linux-arm@vger.rutgers.edu Subject: Re: Arm-linux In-Reply-To: <32ED2C3D.3DE3@cvs.com.au> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO > I spent the weekend looking at binutils. Arm support seems to be > reasonable complete. You mentioned that it was buggy. Could you please > supply more details. I also spent time looking at gcc, I still don't > think it supports position independent code but Mark's reply would > suggest other wise I will ask ( If I am going to make a fool of myself I I think you misunderstood. What he means is that when gcc supports pic for arm32, netbsd/arm32 will get no advantage to going over to ELF from a.out. gcc 3.7.2.1 does NOT support pic. RiscBSD doesn't currently have shared libs for this reason. Last time Mark mentioned this on the RiscBSD mailing list he implied possible -fpic support by gcc 3.8. Hope this helps, Ale. From owner-linux-arm-outgoing@vger.rutgers.edu Wed Jan 29 12:34:04 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id MAA13138 for ; Wed, 29 Jan 1997 12:34:03 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <65925-17218>; Wed, 29 Jan 1997 14:33:59 +0200 Received: by vger.rutgers.edu id <213374-249>; Wed, 29 Jan 1997 07:31:53 -0500 Date: Wed, 29 Jan 1997 12:33:01 +0000 (GMT) From: Philip Blundell X-Sender: pjb27@hammer.thor.cam.ac.uk To: Charles Esson cc: linux-arm@vger.rutgers.edu Subject: Re: Arm-linux In-Reply-To: <32ED2C3D.3DE3@cvs.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO On Tue, 28 Jan 1997, Charles Esson wrote: > I spent the weekend looking at binutils. Arm support seems to be > reasonable complete. You mentioned that it was buggy. Could you please > supply more details. I also spent time looking at gcc, I still don't > think it supports position independent code but Mark's reply would > suggest other wise I will ask ( If I am going to make a fool of myself I > may as well do a good job). Not off the top of my head. I think most of the binutils bugs were quite small -- things like the linker reporting unresolved symbols wrongly, and I have a feeling there was a problem with the assembler screwing things up occasionally (it dumped literals in the middle of the code). When I get time I'll have a proper look at the binutils and try to draw up a wish list. I think you're right about gcc not having support for PIC on the ARM -- Mark was probably talking about NetBSD in general using PIC for shared libraries, not specifically the ARM port. P. From owner-linux-arm-outgoing@vger.rutgers.edu Wed Jan 29 13:17:26 1997 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id NAA13206 for ; Wed, 29 Jan 1997 13:17:26 GMT Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <67733-16353>; Wed, 29 Jan 1997 15:16:59 +0200 Received: by vger.rutgers.edu id <213369-249>; Wed, 29 Jan 1997 08:14:50 -0500 Date: Wed, 29 Jan 1997 13:16:23 GMT From: "Neil A. Carson" Reply-To: Neil To: pjb27@cam.ac.uk Cc: linux-arm@vger.rutgers.edu Message-Id: <970129131623.29239@rmcs.cranfield.ac.uk> Subject: Re: Arm-linux Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO Hi, > > I spent the weekend looking at binutils. Arm support seems to be > > reasonable complete. You mentioned that it was buggy. Could you please > > supply more details. I also spent time looking at gcc, I still don't > > think it supports position independent code but Mark's reply would > > suggest other wise I will ask ( If I am going to make a fool of myself I > > may as well do a good job). > Not off the top of my head. I think most of the binutils bugs were quite > small -- things like the linker reporting unresolved symbols wrongly, and > I have a feeling there was a problem with the assembler screwing things up > occasionally (it dumped literals in the middle of the code). > When I get time I'll have a proper look at the binutils and try to draw up > a wish list. I think you're right about gcc not having support for PIC on > the ARM -- Mark was probably talking about NetBSD in general using PIC for > shared libraries, not specifically the ARM port. To clear this one up (what Mark actually meant): gcc on the ARM does not at the moment have support for position independant code. This will be changing though we can't say when or how at the moment (not allowed). NetBSD in general does indeed use PIC for the shared libraries, rather than the linux-style fixed address ones, and is supported on lots of other ports of the OS, so clearly we will be fixing this soon to avoid the binary-bloat. Yours aye, Neil -- * Neil A Carson * The Royal Military College of Science, Shrivenham * e-mail carson@rmcs.cranfield.ac.uk * Address: Kitchener Mess, RMCS, Shrivenham SN6 8LA. Tel: (0370) 593183 From owner-linux-arm-outgoing@vger.rutgers.edu Fri Jan 16 14:50:58 1998 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id OAA11226 for ; Fri, 16 Jan 1998 14:50:56 GMT Received: from vger.rutgers.edu ([128.6.190.2]:48184 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <1986-18750>; Fri, 16 Jan 1998 16:49:43 +0200 Received: by vger.rutgers.edu id <971030-241>; Fri, 16 Jan 1998 09:24:40 -0500 Received: from out5.ibm.net ([165.87.194.245]:2821 "EHLO out5.ibm.net" ident: "NO-IDENT-SERVICE") by vger.rutgers.edu with ESMTP id <970899-241>; Fri, 16 Jan 1998 09:21:39 -0500 Received: from cvs.com.au (slip-32-100-15-122.fl.us.ibm.net [32.100.15.122]) by out5.ibm.net (8.8.5/8.6.9) with ESMTP id OAA105486; Fri, 16 Jan 1998 14:12:36 GMT Message-ID: <34BF6B53.BBB32604@cvs.com.au> Date: Fri, 16 Jan 1998 09:14:44 -0500 From: Charles Esson Reply-To: charlese@cvs.com.au Organization: Colour Vision Systems X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: "Ka'Plaagh" , "linux-arm@vger.rutgers.edu" Subject: Re: FORTH References: <199801161202.MAA29271@linux.reo.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orcpt: rfc822;linux-arm@vger.rutgers.edu Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO Ka'Plaagh wrote: > I don't think that it's strange, we used forth on the EBSA285. I presume that > you're using the work that Neal Crook did (he also did the EBSA110 forth stuff) > > Dave > > I didn't even know about it, and I wish I had. I have just spent 4 months getting wimpFORTH into shape for a port from riskOS to a stand alone version. It is now very neat, with no magic numbers, producing separate dictionary and memory area code ( so the dictionary can be MMU protected) and was ready for multitasking on the SA110. The SA1100 with it's task register changed that. While the version for the SA110 used registers for the base address of the user area ( a task specific memory block) and the global memory area. I think the SA1100 makes it possible to move this problem to the MMU tables, without having to do anything more than writing a new value to the task register on a task switch. I must say that task switch register is the simplest and neatest thing I have seen in years. It makes it possible to use a MMU to protect the applications from themselves and each other with very minimal overhead. A real plus for real time control. I take my hat off to the hardware gods at digital. As I am waiting impatiently for the delivery of brutus, the next job is the downloading of Neal's stuff and having a look. Regards unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu From owner-linux-arm-outgoing@vger.rutgers.edu Fri Jan 16 15:05:07 1998 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id PAA11265 for ; Fri, 16 Jan 1998 15:05:07 GMT Received: from vger.rutgers.edu ([128.6.190.2]:54089 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <2853-6684>; Fri, 16 Jan 1998 17:03:31 +0200 Received: by vger.rutgers.edu id <971123-241>; Fri, 16 Jan 1998 09:46:08 -0500 Received: from server21.digital.fr ([193.56.15.21]:3093 "EHLO server21.digital.fr" ident: "TIMEDOUT") by vger.rutgers.edu with ESMTP id <971055-241>; Fri, 16 Jan 1998 09:37:32 -0500 Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by server21.digital.fr (8.7.5/8.7) with ESMTP id PAA26522; Fri, 16 Jan 1998 15:40:19 +0100 (MET) Received: from vbormc.vbo.dec.com (vbormc.vbo.dec.com [16.36.208.94]) by mail.vbo.dec.com (8.8.6/8.7) with ESMTP id PAA10739; Fri, 16 Jan 1998 15:40:19 +0100 (MET) Received: from linux.reo.dec.com (linux.reo.dec.com [16.36.0.79]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id QAA07763; Fri, 16 Jan 1998 16:21:02 +0100 Received: from linux.reo.dec.com (localhost [127.0.0.1]) by linux.reo.dec.com (8.8.5/8.7.1) with ESMTP id OAA01011; Fri, 16 Jan 1998 14:38:19 GMT Message-Id: <199801161438.OAA01011@linux.reo.dec.com> To: charlese@cvs.com.au cc: "linux-arm@vger.rutgers.edu" Subject: Re: FORTH In-reply-to: Your message of "Fri, 16 Jan 1998 09:14:44 EST." <34BF6B53.BBB32604@cvs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Jan 1998 14:38:19 +0000 From: "Ka'Plaagh" X-Orcpt: rfc822;linux-arm@vger.rutgers.edu Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO OK, I'll keep a watching brief. Right now we're righting the bootloader/flash management code so that angel on brutus can boot images out of the second banks of flash. These banks are programmable, the base pair are not. I would suggest that you hack/write forth to take advantage of this. I can update your angel images etc when we've done this work and I am interested in your forth work. I'm also interested in Linux on the 1100... Dave ---------------------------------------------------------------------- David A Rusling Consulting Engineer European Semiconductor Applications Digital Equipment Co Ltd., Engineering PO Box 121, Imperial Way, Worton Grange Reading RG2 0TU Linux, Alpha, StrongArm, PCI Tel: UK-(0)1734-204380 Fax: UK-(0)1734-203133 ---------------------------------------------------------------------- unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu From owner-linux-arm-outgoing@vger.rutgers.edu Fri Jan 16 16:31:42 1998 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id QAA12015 for ; Fri, 16 Jan 1998 16:31:40 GMT Received: from vger.rutgers.edu ([128.6.190.2]:49980 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <13300-6684>; Fri, 16 Jan 1998 18:28:29 +0200 Received: by vger.rutgers.edu id <970903-241>; Fri, 16 Jan 1998 11:22:43 -0500 Received: from nexusel.demon.co.uk ([158.152.30.195]:8321 "HELO globe" ident: "NO-IDENT-SERVICE") by vger.rutgers.edu with SMTP id <970983-241>; Fri, 16 Jan 1998 11:21:45 -0500 Received: from spring.nexus.co.uk [192.0.0.3] (root) by globe with smtp (Exim 1.73 #1) id 0xtESM-0001zR-00; Fri, 16 Jan 1998 16:17:18 +0000 Received: from localhost (spring.nexus.co.uk) [127.0.0.1] (pb) by spring.nexus.co.uk with esmtp (Exim 1.82 #1) id 0xtESK-00025I-00; Fri, 16 Jan 1998 16:17:16 +0000 X-Mailer: exmh version 2.0zeta 7/24/97 To: hjl@gnu.org, linux-arm@vger.rutgers.edu Subject: Re: binutils 2.8.1.0.19 In-reply-to: Your message of "Fri, 16 Jan 1998 10:21:20 GMT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Jan 1998 16:17:16 +0000 From: Philip Blundell Message-Id: X-Orcpt: rfc822;linux-arm@vger.rutgers.edu Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO Philip Blundell writes: >Pat Beirne sent me this small patch. It is needed for BFD to generate >working ELF code on the ARM. That patch was no good (and my apologies to Pat, who wasn't actually the guilty author, contrary to what I wrote above). I forgot that changing the reloc type has some other repercussions, and there were a few generated files that had apparently got missed somehow. Here's another one. With this I can generate apparently-working ELF files (as in ld doesn't dump core) though I haven't checked it out fully yet. If somebody would like to give it a go and let me know what happens, I'd appreciate it. I will try to make a new gcc patch against the 2.8.0 release this weekend, and see what needs to be done to make glibc support arm-elf. p. Index: gnu/binutils/bfd/ChangeLog.linux diff -u gnu/binutils/bfd/ChangeLog.linux:1.4 gnu/binutils/bfd/ChangeLog.linux:1.5 --- gnu/binutils/bfd/ChangeLog.linux:1.4 Fri Jan 16 10:19:05 1998 +++ gnu/binutils/bfd/ChangeLog.linux Fri Jan 16 15:55:55 1998 @@ -1,5 +1,8 @@ Fri Jan 16 10:06:19 1998 Philip Blundell + * bfd-in2.h: regenerated. + * libbfd.h: likewise. + * elf32-arm.c: Use REL relocs not RELA. Thu Dec 25 23:42:21 1997 Philip Blundell Index: gnu/binutils/bfd/bfd-in2.h diff -u gnu/binutils/bfd/bfd-in2.h:1.2 gnu/binutils/bfd/bfd-in2.h:1.3 --- gnu/binutils/bfd/bfd-in2.h:1.2 Thu Dec 18 11:18:43 1997 +++ gnu/binutils/bfd/bfd-in2.h Fri Jan 16 15:55:56 1998 @@ -1244,6 +1244,7 @@ bfd_arch_arc, /* Argonaut RISC Core */ #define bfd_mach_arc_base 0 bfd_arch_m32r, /* Mitsubishi M32R/D */ +#define bfd_mach_m32r 0 /* backwards compatibility */ bfd_arch_mn10200, /* Matsushita MN10200 */ bfd_arch_mn10300, /* Matsushita MN10300 */ bfd_arch_last @@ -1828,6 +1829,10 @@ BFD_RELOC_ARM_THUMB_IMM, BFD_RELOC_ARM_THUMB_SHIFT, BFD_RELOC_ARM_THUMB_OFFSET, + BFD_RELOC_ARM_GOTPC, + BFD_RELOC_ARM_GOT12, + BFD_RELOC_ARM_GOT32, + BFD_RELOC_ARM_JMPSLOT, /* Hitachi SH relocs. Not all of these appear in object files. */ BFD_RELOC_SH_PCDISP8BY2, Index: gnu/binutils/bfd/elf32-arm.c diff -u gnu/binutils/bfd/elf32-arm.c:1.1 gnu/binutils/bfd/elf32-arm.c:1.2 --- gnu/binutils/bfd/elf32-arm.c:1.1 Fri Jan 16 10:00:05 1998 +++ gnu/binutils/bfd/elf32-arm.c Fri Jan 16 15:55:57 1998 @@ -23,7 +23,7 @@ #include "libbfd.h" #include "elf-bfd.h" -#define USE_RELA /* we want RELA relocations, not REL */ +#define USE_REL /* we want REL relocations, not RELA */ /* ARM relocations */ enum arm_reloc_type @@ -170,11 +170,25 @@ arelent *cache_ptr; Elf32_Internal_Rela *dst; { - if (!arm_elf_howto_table[ R_ARM_ADDR32 ]) /* Initialize howto table if needed */ + abort(); +} + +static void +arm_elf_info_to_howto_rel (abfd, cache_ptr, dst) + bfd *abfd; + arelent *cache_ptr; + Elf32_Internal_Rel *dst; +{ + enum arm_reloc_type type; + + /* Initialize howto table if needed */ + if (!arm_elf_howto_table[R_ARM_ADDR32]) arm_elf_howto_init (); - BFD_ASSERT (ELF32_R_TYPE (dst->r_info) < (unsigned int) R_ARM_max); - cache_ptr->howto = arm_elf_howto_table[ELF32_R_TYPE (dst->r_info)]; + type = (enum reloc_type) ELF32_R_TYPE (dst->r_info); + BFD_ASSERT (type < R_ARM_max); + + cache_ptr->howto = arm_elf_howto_table[(int) type]; } static reloc_howto_type * @@ -190,14 +204,14 @@ switch ((int)code) { - default: - return (reloc_howto_type *)NULL; - case BFD_RELOC_NONE: arm_reloc = R_ARM_NONE; break; case BFD_RELOC_32: arm_reloc = R_ARM_ADDR32; break; case BFD_RELOC_16: arm_reloc = R_ARM_ADDR16; break; case BFD_RELOC_8: arm_reloc = R_ARM_ADDR8; break; case BFD_RELOC_ARM_PCREL_BRANCH: arm_reloc = R_ARM_PCREL_BRANCH; break; + + default: + return (reloc_howto_type *)NULL; } return arm_elf_howto_table[ (int)arm_reloc ]; @@ -290,6 +304,7 @@ #define ELF_ARCH bfd_arch_arm #define elf_info_to_howto arm_elf_info_to_howto +#define elf_info_to_howto_rel arm_elf_info_to_howto_rel #define bfd_elf32_bfd_reloc_type_lookup arm_elf_reloc_type_lookup #include "elf32-target.h" Index: gnu/binutils/bfd/libbfd.h diff -u gnu/binutils/bfd/libbfd.h:1.2 gnu/binutils/bfd/libbfd.h:1.3 --- gnu/binutils/bfd/libbfd.h:1.2 Thu Dec 18 11:18:59 1997 +++ gnu/binutils/bfd/libbfd.h Fri Jan 16 15:55:58 1998 @@ -348,6 +348,11 @@ PARAMS ((bfd *, asymbol **, asection *, bfd_vma, boolean *, const char **, const char **, unsigned int *, PTR *)); +/* Find the nearest line using DWARF 2 debugging information. */ +extern boolean _bfd_dwarf2_find_nearest_line + PARAMS ((bfd *, asection *, asymbol **, bfd_vma, const char **, + const char **, unsigned int *)); + /* A routine to create entries for a bfd_link_hash_table. */ extern struct bfd_hash_entry *_bfd_link_hash_newfunc PARAMS ((struct bfd_hash_entry *entry, @@ -728,6 +733,10 @@ "BFD_RELOC_ARM_THUMB_IMM", "BFD_RELOC_ARM_THUMB_SHIFT", "BFD_RELOC_ARM_THUMB_OFFSET", + "BFD_RELOC_ARM_GOTPC", + "BFD_RELOC_ARM_GOT12", + "BFD_RELOC_ARM_GOT32", + "BFD_RELOC_ARM_JMPSLOT", "BFD_RELOC_SH_PCDISP8BY2", "BFD_RELOC_SH_PCDISP12BY2", "BFD_RELOC_SH_IMM4", unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu From owner-linux-arm-outgoing@vger.rutgers.edu Wed Jan 21 01:23:45 1998 Return-Path: Received: from nic.funet.fi ([128.214.248.6] (may be forged)) by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id BAA02351 for ; Wed, 21 Jan 1998 01:23:39 GMT Received: from vger.rutgers.edu ([128.6.190.2]:37637 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <2783-617>; Wed, 21 Jan 1998 02:02:30 +0200 Received: by vger.rutgers.edu id <970839-11737>; Tue, 20 Jan 1998 18:44:25 -0500 Received: from snowcrash.cymru.net ([163.164.160.3]:1278 "EHLO snowcrash.cymru.net" ident: "NO-IDENT-SERVICE") by vger.rutgers.edu with ESMTP id <970799-11737>; Tue, 20 Jan 1998 17:56:23 -0500 Received: from caramon.armlinux.org (dialup2.cymru.net [163.164.160.66]) by snowcrash.cymru.net (8.8.7/8.7.1) with ESMTP id XAA01800 for ; Tue, 20 Jan 1998 23:00:59 GMT Received: from raistlin.armlinux.org (raistlin [192.168.0.3]) by caramon.armlinux.org (8.7.4/8.7.3) with ESMTP id XAA24644 for ; Tue, 20 Jan 1998 23:02:09 GMT From: Russell King Received: (from rmk@localhost) by raistlin.armlinux.org (8.7.4/8.7.3) id XAA00747 for linux-arm@vger.rutgers.edu; Tue, 20 Jan 1998 23:02:07 GMT Message-Id: <199801202302.XAA00747@raistlin.armlinux.org> Subject: New Release of Kernel source code for 2.0.33 To: linux-arm@vger.rutgers.edu Date: Tue, 20 Jan 1998 23:02:06 +0000 (GMT) X-Location: london.england.earth.mulky-way.universe Reply-To: rmk@ecs.soton.ac.uk X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Orcpt: rfc822;linux-arm@vger.rutgers.edu Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO Hi all! A new release of the 2.0.33 kernel source code is now on the FTP site - it fixes: * the build problem with a couple of the Makefiles * removes some asm code in include/linux/adfs_fs.h * ether3/etherh initialisation problem (and probably other hardware as well). Enjoy! (And if you find any other problems, let me know!) _____ |_____| ------------------------------------------------- ---+---+- | | Russell King rmk@ecs.soton.ac.uk --- --- | | | | http://www.arm.uk.linux.org/~rmk/home.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ ------------------------------------------------- /\\\ | unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu From owner-linux-arm-outgoing@vger.rutgers.edu Wed Jan 21 09:04:38 1998 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id JAA05095 for ; Wed, 21 Jan 1998 09:04:38 GMT Received: from vger.rutgers.edu ([128.6.190.2]:29039 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <9911-617>; Wed, 21 Jan 1998 10:56:34 +0200 Received: by vger.rutgers.edu id <970900-11737>; Wed, 21 Jan 1998 03:46:02 -0500 Received: from lenzie-atm.cent.gla.ac.uk ([130.209.113.18]:58703 "EHLO lenzie.cent.gla.ac.uk" ident: "NO-IDENT-SERVICE") by vger.rutgers.edu with ESMTP id <970912-11737>; Wed, 21 Jan 1998 03:44:01 -0500 Received: from localhost (9606585c@localhost sender 9606585c) by lenzie.cent.gla.ac.uk (8.8.4/UK-2.2a/cent-sparc) with SMTP id IAA26920 for ; Wed, 21 Jan 1998 08:48:51 GMT Date: Wed, 21 Jan 1998 08:48:51 +0000 (GMT) From: James Craig <9606585c@udcf.gla.ac.uk> X-Sender: 9606585c@lenzie.cent.gla.ac.uk To: linux-arm@vger.rutgers.edu Subject: Re: New Release of Kernel source code for 2.0.33 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Orcpt: rfc822;linux-arm@vger.rutgers.edu Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO On Tue, 20 Jan 1998, Russell King wrote: > Hi all! > > A new release of the 2.0.33 kernel source code is now on the FTP site - it fixes: > > * the build problem with a couple of the Makefiles > * removes some asm code in include/linux/adfs_fs.h Is that all of the asm code removed from include/linux/adfs_fs.h now? If so, great - I've had the ix86 floppy drivers modified to read 1K sectors for a few years now; I'll have to redo the patches for the current kernel version, but hopefully I'll be able to get the PC reading ADFS disks properly at last! :) -- James Craig <9606585c@udcf.gla.ac.uk> unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu From owner-linux-arm-outgoing@vger.rutgers.edu Wed Jan 21 09:56:16 1998 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id JAA05500 for ; Wed, 21 Jan 1998 09:56:15 GMT Received: from vger.rutgers.edu ([128.6.190.2]:2624 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <2637-620>; Wed, 21 Jan 1998 11:44:16 +0200 Received: by vger.rutgers.edu id <970922-11737>; Wed, 21 Jan 1998 04:30:50 -0500 Received: from snowcrash.cymru.net ([163.164.160.3]:1359 "EHLO snowcrash.cymru.net" ident: "NO-IDENT-SERVICE") by vger.rutgers.edu with ESMTP id <970927-11737>; Wed, 21 Jan 1998 04:23:23 -0500 Received: (from alan@localhost) by snowcrash.cymru.net (8.8.7/8.7.1) id JAA10399; Wed, 21 Jan 1998 09:28:05 GMT From: Alan Cox Message-Id: <199801210928.JAA10399@snowcrash.cymru.net> Subject: Re: New Release of Kernel source code for 2.0.33 To: 9606585c@udcf.gla.ac.uk (James Craig) Date: Wed, 21 Jan 1998 09:27:49 +0000 (GMT) Cc: linux-arm@vger.rutgers.edu In-Reply-To: from "James Craig" at Jan 21, 98 08:48:51 am Content-Type: text X-Orcpt: rfc822;linux-arm@vger.rutgers.edu Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO > If so, great - I've had the ix86 floppy drivers modified to read 1K > sectors for a few years now; I'll have to redo the patches for the > current kernel version, but hopefully I'll be able to get the PC reading > ADFS disks properly at last! :) Please do get those supported. I've submitted the ADFS work on to Linus and hopefully he'll take it now its free of arm assembler. unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu From owner-linux-arm-outgoing@vger.rutgers.edu Wed Jan 21 10:26:11 1998 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id KAA05754 for ; Wed, 21 Jan 1998 10:26:10 GMT Received: from vger.rutgers.edu ([128.6.190.2]:13940 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <1500-617>; Wed, 21 Jan 1998 12:18:55 +0200 Received: by vger.rutgers.edu id <970932-11737>; Wed, 21 Jan 1998 05:10:28 -0500 Received: from nexusel.demon.co.uk ([158.152.30.195]:18805 "HELO globe" ident: "NO-IDENT-SERVICE") by vger.rutgers.edu with SMTP id <970943-11737>; Wed, 21 Jan 1998 05:05:10 -0500 Received: from spring.nexus.co.uk [192.0.0.3] (root) by globe with smtp (Exim 1.73 #1) id 0xux01-0008BP-00; Wed, 21 Jan 1998 10:03:09 +0000 Received: from localhost (spring.nexus.co.uk) [127.0.0.1] (pb) by spring.nexus.co.uk with esmtp (Exim 1.82 #1) id 0xux00-0000xk-00; Wed, 21 Jan 1998 10:03:08 +0000 To: linux-arm@vger.rutgers.edu Subject: linuxthreads Date: Wed, 21 Jan 1998 10:03:08 +0000 From: Philip Blundell Message-Id: X-Orcpt: rfc822;linux-arm@vger.rutgers.edu Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO Hi. In case anybody wants to play with glibc, I put a small patch for LinuxThreads at http://www.tazenda.demon.co.uk/phil/armlinux/linuxthreads-diff-971218.gz It should apply to any recent linuxthreads snapshot. p. unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu From owner-linux-arm-outgoing@vger.rutgers.edu Wed Jan 21 10:34:01 1998 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id KAA05835 for ; Wed, 21 Jan 1998 10:34:00 GMT Received: from vger.rutgers.edu ([128.6.190.2]:28520 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <13634-621>; Wed, 21 Jan 1998 12:12:48 +0200 Received: by vger.rutgers.edu id <970974-11737>; Wed, 21 Jan 1998 04:57:32 -0500 Received: from lenzie-atm.cent.gla.ac.uk ([130.209.113.18]:41456 "EHLO lenzie.cent.gla.ac.uk" ident: "NO-IDENT-SERVICE") by vger.rutgers.edu with ESMTP id <970947-11737>; Wed, 21 Jan 1998 04:50:42 -0500 Received: from localhost (9606585c@localhost sender 9606585c) by lenzie.cent.gla.ac.uk (8.8.4/UK-2.2a/cent-sparc) with SMTP id JAA06788; Wed, 21 Jan 1998 09:55:19 GMT Date: Wed, 21 Jan 1998 09:55:18 +0000 (GMT) From: James Craig <9606585c@udcf.gla.ac.uk> X-Sender: 9606585c@lenzie.cent.gla.ac.uk To: Alan Cox cc: linux-arm@vger.rutgers.edu Subject: Re: New Release of Kernel source code for 2.0.33 In-Reply-To: <199801210928.JAA10399@snowcrash.cymru.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Orcpt: rfc822;linux-arm@vger.rutgers.edu Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO On Wed, 21 Jan 1998, Alan Cox wrote: > > If so, great - I've had the ix86 floppy drivers modified to read 1K > > sectors for a few years now; I'll have to redo the patches for the > > current kernel version, but hopefully I'll be able to get the PC reading > > ADFS disks properly at last! :) > > Please do get those supported. I've submitted the ADFS work on to Linus > and hopefully he'll take it now its free of arm assembler. Shouldn't be a major problem; The past few times I've done it I've been able to read the actual stuff off ADFS disks with no problems, but I haven't had time or the experience of writing Linux FSs to code up an ADFS implementation. I've got exams right at this minute, so I'm not likely to release anything much for about a week - after that, I should be able to get the patches up and running again fairly quickly. The code's always been a quick hack, but I'll do my best to tidy it up this time. :) -- James Craig <9606585c@udcf.gla.ac.uk> unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu From owner-linux-arm-outgoing@vger.rutgers.edu Wed Jan 21 11:03:11 1998 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id LAA06112 for ; Wed, 21 Jan 1998 11:03:10 GMT Received: from vger.rutgers.edu ([128.6.190.2]:18969 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <2027-617>; Wed, 21 Jan 1998 12:47:29 +0200 Received: by vger.rutgers.edu id <970928-11737>; Wed, 21 Jan 1998 05:37:06 -0500 Received: from lenzie-atm.cent.gla.ac.uk ([130.209.113.18]:50267 "EHLO lenzie.cent.gla.ac.uk" ident: "NO-IDENT-SERVICE") by vger.rutgers.edu with ESMTP id <970934-11737>; Wed, 21 Jan 1998 05:33:22 -0500 Received: from localhost (9606585c@localhost sender 9606585c) by lenzie.cent.gla.ac.uk (8.8.4/UK-2.2a/cent-sparc) with SMTP id KAA04141; Wed, 21 Jan 1998 10:37:14 GMT Date: Wed, 21 Jan 1998 10:37:13 +0000 (GMT) From: James Craig <9606585c@udcf.gla.ac.uk> X-Sender: 9606585c@lenzie.cent.gla.ac.uk To: Alan Cox cc: linux-arm@vger.rutgers.edu Subject: Re: New Release of Kernel source code for 2.0.33 In-Reply-To: <199801210928.JAA10399@snowcrash.cymru.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Orcpt: rfc822;linux-arm@vger.rutgers.edu Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO On Wed, 21 Jan 1998, Alan Cox wrote: > > If so, great - I've had the ix86 floppy drivers modified to read 1K > > sectors for a few years now; I'll have to redo the patches for the > > current kernel version, but hopefully I'll be able to get the PC reading > > ADFS disks properly at last! :) > > Please do get those supported. I've submitted the ADFS work on to Linus > and hopefully he'll take it now its free of arm assembler. Also just noticed - the 2.1.80 kernel (released today, AFAIK), contains: a) ARM support! (Yay!!!) b) ADFS Filesystem stuff. c) General good things left, right, and centre. :) Looks like we might finally be moving into the mainstream of linux development! :) Anyway, I'll get that floppy driver fixed up RSN. :) -- James Craig <9606585c@udcf.gla.ac.uk> unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu From owner-linux-arm-outgoing@vger.rutgers.edu Wed Jan 21 13:08:54 1998 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id NAA07297 for ; Wed, 21 Jan 1998 13:08:51 GMT Received: from vger.rutgers.edu ([128.6.190.2]:10531 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <2052-617>; Wed, 21 Jan 1998 15:05:30 +0200 Received: by vger.rutgers.edu id <970934-11737>; Wed, 21 Jan 1998 07:58:24 -0500 Received: from irwell.zetnet.co.uk ([194.247.47.48]:29228 "EHLO irwell.zetnet.co.uk" ident: "root") by vger.rutgers.edu with ESMTP id <970900-11737>; Wed, 21 Jan 1998 07:51:51 -0500 Received: from Michael (man-072.dialup.zetnet.co.uk [194.247.41.89]) by irwell.zetnet.co.uk (8.8.7/8.8.5) with SMTP id MAA29714 for ; Wed, 21 Jan 1998 12:56:38 GMT Date: Wed, 21 Jan 1998 12:47:36 +0000 (GMT) From: Michael Howard Subject: Package Installation To: Linux Mailing List Illegal-Object: Syntax error in Message-ID: value found on vger.rutgers.edu: Message-ID: ^-illegal end of message identification MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Organization: Organisation name, location. Telephone/Fax? X-Mailer: ANT RISCOS Marcel [ver 1.26] X-Orcpt: rfc822;linux-arm@vger.rutgers.edu Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Message-Id: <19980121125832Z970934-11737+2805@vger.rutgers.edu> Status: RO Hi All, Which command is used to install packages which failed during initial installation. Under Systen V I would use 'pkgadd' but it doesn't appear to be on my Linux installation. Possibly failed during installation? Cheers Mick. -- Mick Howard snogmon@zetnet.co.uk Warrington England unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu From owner-linux-arm-outgoing@vger.rutgers.edu Wed Jan 21 19:57:50 1998 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id TAA10393 for ; Wed, 21 Jan 1998 19:57:49 GMT Received: from vger.rutgers.edu ([128.6.190.2]:20091 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <17300-617>; Wed, 21 Jan 1998 21:55:21 +0200 Received: by vger.rutgers.edu id <970837-11737>; Wed, 21 Jan 1998 14:20:50 -0500 Received: from excite.whowhere.com ([209.1.236.13]:37262 "EHLO excite" ident: "NO-IDENT-SERVICE") by vger.rutgers.edu with ESMTP id <971033-11737>; Wed, 21 Jan 1998 13:11:44 -0500 Received: by mailexcite.com id <21727-348>; Wed, 21 Jan 1998 10:15:13 -0800 To: linux-arm@vger.rutgers.edu Date: Wed, 21 Jan 1998 10:15:06 -0700 From: "Kris Kelvin" Message-ID: Mime-Version: 1.0 Cc: arm-linux@tardis.ed.ac.uk X-Sent-Mail: off X-Expiredinmiddle: true X-Mailer: MailCity Service Subject: EBSA-285 X-Sender-Ip: 129.128.28.141 Organization: MailExcite (http://www.mailexcite.com) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orcpt: rfc822;linux-arm@vger.rutgers.edu Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO Hi. I am completely new to these lists and I wasn't able to find an archive of what has been discussed here so far, so please forgive me if you think I have polluted your mailboxes. I have just received the EBSA-285 evaluation board and I wonder if anybody has managed to install Linux on it yet. If so, I will be grateful for any comments and suggestions. Thanks, Kris --- Kris Kelvin Free web-based email, Forever, From anywhere! http://www.mailexcite.com unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu From owner-linux-arm-outgoing@vger.rutgers.edu Thu Jan 22 01:13:34 1998 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id BAA12764 for ; Thu, 22 Jan 1998 01:13:32 GMT Received: from vger.rutgers.edu ([128.6.190.2]:42572 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <12880-620>; Thu, 22 Jan 1998 03:10:48 +0200 Received: by vger.rutgers.edu id <971365-11737>; Wed, 21 Jan 1998 18:53:48 -0500 Received: from mailhub.nc.com ([207.88.25.3]:6343 "HELO mailhub.nc.com" ident: "proxy") by vger.rutgers.edu with SMTP id <971579-11737>; Wed, 21 Jan 1998 17:25:13 -0500 Received: (from proxy@localhost) by mailhub.nc.com (8.6.12/8.6.9) id OAA31938; Wed, 21 Jan 1998 14:29:28 -0800 Received: from riscbsd1.client.nc.com(172.17.8.88) by mailhub.nc.com via smap (V2.0) id xma031916; Wed, 21 Jan 98 14:29:07 -0800 Message-ID: <34C671E7.41C67EA6@causality.com> Date: Wed, 21 Jan 1998 22:08:39 +0000 From: "Neil A. Carson" Organization: Causality Limited (London, UK) X-Mailer: Mozilla 3.01 (X11; I; NetBSD 1.2G arm32) MIME-Version: 1.0 To: Anthony Rumble CC: Dave Gilbert , linux-arm@vger.rutgers.edu Subject: Re: Getting an EBSA board.. or possibly DNARD board References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orcpt: rfc822;linux-arm@vger.rutgers.edu Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO You can order an EBSA _or_ a DNARD from Digitals distributors, but expect to pay evaluation-cost prices. Neil unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu From owner-linux-arm-outgoing@vger.rutgers.edu Thu Jan 22 01:14:57 1998 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id BAA12905 for ; Thu, 22 Jan 1998 01:14:56 GMT Received: from vger.rutgers.edu ([128.6.190.2]:42572 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <9504-619>; Thu, 22 Jan 1998 03:13:00 +0200 Received: by vger.rutgers.edu id <970990-11737>; Wed, 21 Jan 1998 18:54:33 -0500 Received: from snowcrash.cymru.net ([163.164.160.3]:1981 "EHLO snowcrash.cymru.net" ident: "NO-IDENT-SERVICE") by vger.rutgers.edu with ESMTP id <971621-11737>; Wed, 21 Jan 1998 17:49:28 -0500 Received: from caramon.armlinux.org (dialup1.cymru.net [163.164.160.65]) by snowcrash.cymru.net (8.8.7/8.7.1) with ESMTP id WAA23949; Wed, 21 Jan 1998 22:54:18 GMT Received: from raistlin.armlinux.org (raistlin [192.168.0.3]) by caramon.armlinux.org (8.7.4/8.7.3) with ESMTP id WAA26066; Wed, 21 Jan 1998 22:14:23 GMT From: Russell King - ARM Linux Admin Received: (from linux@localhost) by raistlin.armlinux.org (8.7.4/8.7.3) id WAA00761; Wed, 21 Jan 1998 22:14:05 GMT Message-Id: <199801212214.WAA00761@raistlin.armlinux.org> Subject: Re: Package Installation To: snogmon@zetnet.co.uk (Michael Howard) Date: Wed, 21 Jan 1998 22:14:05 +0000 (GMT) Cc: linux-arm@vger.rutgers.edu In-Reply-To: <19980121125832Z970934-11737+2805@vger.rutgers.edu> from "Michael Howard" at Jan 21, 98 12:47:36 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Orcpt: rfc822;linux-arm@vger.rutgers.edu Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO Michael Howard writes: > Which command is used to install packages which failed during initial > installation. Under Systen V I would use 'pkgadd' but it doesn't appear to > be on my Linux installation. Possibly failed during installation? rpm -i package-file To get info on installed packages: rpm -qia (for all) or rpm -qi To get a list of installed packages: rpm -qa _____ |_____| ------------------------------------------------- ---+---+- | | Russell King rmk@ecs.soton.ac.uk --- --- | | | | http://www.arm.uk.linux.org/~rmk/home.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ ------------------------------------------------- /\\\ | unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu From owner-arm-linux@tardis.ed.ac.uk Thu Jan 22 01:44:45 1998 Return-Path: Received: from tardis.ed.ac.uk (majordom@brigadier.tardis.ed.ac.uk [193.62.81.14]) by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id BAA13180 for ; Thu, 22 Jan 1998 01:44:44 GMT Received: (from majordom@localhost) by tardis.ed.ac.uk (8.8.7/8.8.7/TardisMailhub) id BAA20850 for arm-linux-outgoing; Thu, 22 Jan 1998 01:35:26 GMT X-Authentication-Warning: brigadier.tardis.ed.ac.uk: majordom set sender to owner-arm-linux using -f Received: from odie.barnet.ac.uk (willy@odie.barnet.ac.uk [194.82.202.98]) by tardis.ed.ac.uk (8.8.7/8.8.7/TardisMailhub) with ESMTP id BAA20845 for ; Thu, 22 Jan 1998 01:35:19 GMT Received: (from willy@localhost) by odie.barnet.ac.uk (8.8.6/8.8.6) id BAA13008; Thu, 22 Jan 1998 01:34:49 GMT From: Matthew Wilcox Message-Id: <199801220134.BAA13008@odie.barnet.ac.uk> Subject: Re: EBSA-285 To: kris_kelvin@mailexcite.com (Kris Kelvin) Date: Thu, 22 Jan 1998 01:34:49 +0000 (GMT) Cc: linux-arm@vger.rutgers.edu, arm-linux@tardis.ed.ac.uk In-Reply-To: from "Kris Kelvin" at Jan 21, 98 10:15:06 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-arm-linux@tardis.ed.ac.uk Precedence: bulk Status: RO > I am completely new to these lists and I wasn't able to > find an archive of what has been discussed here so > far, so please forgive me if you think I have polluted > your mailboxes. The archive is located at ftp.barnet.ac.uk:/pub/Acorn/armlinux/ I may rename the individual files within there - I got criticised for using 2-digit years ;-) At any rate, they're split by month and updated by me on an ad-hoc basis. (if anyone knows how to train elm to work with symlinks, do let me know..) From owner-linux-arm-outgoing@vger.rutgers.edu Thu Jan 22 08:17:55 1998 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id IAA15638 for ; Thu, 22 Jan 1998 08:17:54 GMT Received: from vger.rutgers.edu ([128.6.190.2]:15720 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <11853-617>; Thu, 22 Jan 1998 10:16:56 +0200 Received: by vger.rutgers.edu id <971053-11737>; Thu, 22 Jan 1998 03:10:54 -0500 Received: from [194.200.140.119] ([194.200.140.119]:2613 "EHLO arthur.digi.co.uk" ident: "SOCKWRITE-65") by vger.rutgers.edu with ESMTP id <971056-11737>; Thu, 22 Jan 1998 03:10:41 -0500 Received: from chris.digi.co.uk ([194.200.140.100]) by arthur.digi.co.uk (8.8.5/8.8.5) with SMTP id IAA05714 for ; Thu, 22 Jan 1998 08:17:12 GMT Message-Id: <2.2.32.19980122081727.006f151c@194.200.140.6> X-Sender: chrisc@194.200.140.6 X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 Jan 1998 08:17:27 +0000 To: linux-arm@vger.rutgers.edu From: Chris Chorley Subject: Drive Compatibility X-Orcpt: rfc822;linux-arm@vger.rutgers.edu Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO Does ARM Linux have any restrictions on the drives it will install from (RPC/SA-110) ? Is scsi or ide cdrom ok ? Any particular scsi card or make of cdrom ? The reason for asking is the trouble I had getting Red Hat Linux install to recognise a scsi card/cdrom on an Intel-486 box. Chris. unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu From alan@snowcrash.cymru.net Thu Jan 22 09:36:54 1998 Return-Path: Received: from snowcrash.cymru.net (snowcrash.cymru.net [163.164.160.3]) by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id JAA16102 for ; Thu, 22 Jan 1998 09:36:53 GMT Received: (from alan@localhost) by snowcrash.cymru.net (8.8.7/8.7.1) id JAA30127; Thu, 22 Jan 1998 09:37:14 GMT From: Alan Cox Message-Id: <199801220937.JAA30127@snowcrash.cymru.net> Subject: Re: EBSA-285 To: willy@odie.barnet.ac.uk (Matthew Wilcox) Date: Thu, 22 Jan 1998 09:37:12 +0000 (GMT) Cc: kris_kelvin@mailexcite.com, linux-arm@vger.rutgers.edu, arm-linux@tardis.ed.ac.uk In-Reply-To: <199801220134.BAA13008@odie.barnet.ac.uk> from "Matthew Wilcox" at Jan 22, 98 01:34:49 am Content-Type: text Status: RO > At any rate, they're split by month and updated by me on an ad-hoc basis. > (if anyone knows how to train elm to work with symlinks, do let me know..) No but there's a great tool called Mhonarc which you fire all the mail archives through and get a per thread hyperlinked web site out of .. From owner-linux-arm-outgoing@vger.rutgers.edu Thu Jan 22 09:44:28 1998 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id JAA16321 for ; Thu, 22 Jan 1998 09:44:27 GMT Received: from vger.rutgers.edu ([128.6.190.2]:48197 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <14183-619>; Thu, 22 Jan 1998 11:42:57 +0200 Received: by vger.rutgers.edu id <970837-11737>; Thu, 22 Jan 1998 04:37:08 -0500 Received: from stingray.ivision.co.uk ([195.50.91.40]:44036 "HELO stingray.ivision.co.uk" ident: "NO-IDENT-SERVICE") by vger.rutgers.edu with SMTP id <970934-11737>; Thu, 22 Jan 1998 04:36:41 -0500 Received: from pretender.ivision.co.uk [195.50.91.43] by stingray.ivision.co.uk with smtp (Exim 1.62 #1) id 0xvJ8w-00075p-00; Thu, 22 Jan 1998 09:41:50 +0000 Message-Id: <3.0.5.32.19980122094022.008019d0@stingray.ivision.co.uk> X-Sender: manarpop@stingray.ivision.co.uk X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 22 Jan 1998 09:40:22 +0000 To: linux-arm@vger.rutgers.edu From: Manar Hussain Subject: Re: EBSA-285 In-Reply-To: <199801220937.JAA30127@snowcrash.cymru.net> References: <199801220134.BAA13008@odie.barnet.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orcpt: rfc822;linux-arm@vger.rutgers.edu Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO >No but there's a great tool called Mhonarc which you fire all the mail >archives through and get a per thread hyperlinked web site out of .. If anyone has an archive in mbox format I'd be happy to set up a continually updated web archive (much like Mhonarc but using our own software). Manar unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu From owner-linux-arm-outgoing@vger.rutgers.edu Thu Jan 22 11:33:44 1998 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id LAA17068 for ; Thu, 22 Jan 1998 11:33:43 GMT Received: from vger.rutgers.edu ([128.6.190.2]:50776 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <13674-619>; Thu, 22 Jan 1998 13:30:06 +0200 Received: by vger.rutgers.edu id <970948-11737>; Thu, 22 Jan 1998 06:23:48 -0500 Received: from odie.barnet.ac.uk ([194.82.202.98]:15456 "EHLO odie.barnet.ac.uk" ident: "willy") by vger.rutgers.edu with ESMTP id <970970-11737>; Thu, 22 Jan 1998 06:23:06 -0500 Received: (from willy@localhost) by odie.barnet.ac.uk (8.8.6/8.8.6) id LAA17034; Thu, 22 Jan 1998 11:27:39 GMT From: Matthew Wilcox Message-Id: <199801221127.LAA17034@odie.barnet.ac.uk> Subject: Re: Drive Compatibility To: chris.chorley@digi.co.uk (Chris Chorley) Date: Thu, 22 Jan 1998 11:27:37 +0000 (GMT) Cc: linux-arm@vger.rutgers.edu In-Reply-To: <2.2.32.19980122081727.006f151c@194.200.140.6> from "Chris Chorley" at Jan 22, 98 08:17:27 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Orcpt: rfc822;linux-arm@vger.rutgers.edu Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO > Does ARM Linux have any restrictions on the drives it will install from > (RPC/SA-110) ? > > Is scsi or ide cdrom ok ? > > Any particular scsi card or make of cdrom ? If you look on the ARM Linux web site (http://www.arm.uk.linux.org/~rmk/armlinux.html) then you'll see a section on supported device drivers. More specifically, try ~rmk/armlinux/kerndevs.html. unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu From owner-linux-arm-outgoing@vger.rutgers.edu Fri Jan 23 12:38:31 1998 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id MAA28078 for ; Fri, 23 Jan 1998 12:38:26 GMT Received: from vger.rutgers.edu ([128.6.190.2]:9994 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <9320-617>; Fri, 23 Jan 1998 14:26:01 +0200 Received: by vger.rutgers.edu id <970961-11737>; Fri, 23 Jan 1998 07:04:35 -0500 Received: from cptsg4.univ-mrs.fr ([139.124.7.104]:12570 "HELO cptsg4" ident: "NO-IDENT-SERVICE") by vger.rutgers.edu with SMTP id <971148-11737>; Fri, 23 Jan 1998 06:43:20 -0500 Received: from cptsg4 (localhost [127.0.0.1]) by cptsg4 (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id MAA27611 for ; Fri, 23 Jan 1998 12:46:21 +0100 Message-ID: <34C8830C.41C6@cpt.univ-mrs.fr> Date: Fri, 23 Jan 1998 12:46:20 +0100 From: Vincent PENNE Organization: Centre de Physique Theorique de Marseille X-Mailer: Mozilla 2.01S (X11; I; IRIX64 6.2 IP28) MIME-Version: 1.0 To: linux-arm@vger.rutgers.edu Subject: missing stuffs in gcc Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orcpt: rfc822;linux-arm@vger.rutgers.edu Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO There seems not to be any C++ support with gcc, is it normal ? Also, trying to compile wxWindow, it didn't work because the directory /usr/include/linux is missing (it should contain the original errno.h for example). Where can I find these files ? Vincent. -- /==========================================================\ | Vincent PENNE, Centre de Physique Theorique | |Tel. (0033)4 91 26 95 04 CNRS - LUMINY - Case 907 | |Fax. (0033)4 91 26 95 53 F-13288 MARSEILLE CEDEX 9 | |Email: penne@cpt.univ-mrs.fr FRANCE | |http://www.cpt.univ-mrs.fr | \==========================================================/ unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu From owner-linux-arm-outgoing@vger.rutgers.edu Fri Jan 23 13:59:09 1998 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id NAA28689 for ; Fri, 23 Jan 1998 13:59:08 GMT Received: from vger.rutgers.edu ([128.6.190.2]:36635 "EHLO vger.rutgers.edu" ident: "TIMEDOUT") by nic.funet.fi with ESMTP id <21170-617>; Fri, 23 Jan 1998 15:57:32 +0200 Received: by vger.rutgers.edu id <970986-11737>; Fri, 23 Jan 1998 08:46:03 -0500 Received: from hermes.ex.ac.uk ([144.173.6.14]:29333 "EHLO exeter.ac.uk" ident: "NO-IDENT-SERVICE") by vger.rutgers.edu with ESMTP id <970980-11737>; Fri, 23 Jan 1998 08:42:57 -0500 Received: from hebe [144.173.6.23] by hermes via SMTP (NAA27902); Fri, 23 Jan 1998 13:48:06 GMT Date: Fri, 23 Jan 1998 13:48:06 +0000 (GMT) From: Phil Norman X-Sender: py95pcfn@hebe To: Vincent PENNE cc: linux-arm@vger.rutgers.edu Subject: Re: missing stuffs in gcc In-Reply-To: <34C8830C.41C6@cpt.univ-mrs.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Orcpt: rfc822;linux-arm@vger.rutgers.edu Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO On Fri, 23 Jan 1998, Vincent PENNE wrote: > There seems not to be any C++ support with gcc, is it normal ? > Also, trying to compile wxWindow, it didn't work because the directory > /usr/include/linux is missing (it should contain the original errno.h > for example). Where can I find these files ? You'll need the source code to linux for this, though there may be a less disc-space-eating way to do it. It says in one of the Documents that you should put some symbolic links in from /usr/include/ into some of the /usr/src/linux/include/ directories. (The linux source should be put into /usr/src/linux btw). AFAICR the links are something like this: /usr/include/linux -> /usr/src/linux/include/linux /usr/include/scsi -> /usr/src/linux/include/scsi /usr/include/asm -> /usr/src/linux/include/asm I'm not entirely sure about whether these links are right - someone please correct me if I'm screamingly wrong. After that everything should be hunky-dory and ticketty boo. Good luck, Phil -- Phil Norman, mailing from Exeter Uni. Programs available for download from my web page. email: p.c.f.norman@ex.ac.uk web: http://newton.ex.ac.uk/general/ug/norman unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu From owner-linux-arm-outgoing@vger.rutgers.edu Fri Jan 23 14:44:13 1998 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id OAA29052 for ; Fri, 23 Jan 1998 14:44:12 GMT Received: from vger.rutgers.edu ([128.6.190.2]:47195 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <9776-619>; Fri, 23 Jan 1998 16:43:30 +0200 Received: by vger.rutgers.edu id <970879-11737>; Fri, 23 Jan 1998 09:37:13 -0500 Received: from lenzie-atm.cent.gla.ac.uk ([130.209.113.18]:60336 "EHLO lenzie.cent.gla.ac.uk" ident: "NO-IDENT-SERVICE") by vger.rutgers.edu with ESMTP id <970873-11737>; Fri, 23 Jan 1998 09:36:37 -0500 Received: from localhost (9606585c@localhost sender 9606585c) by lenzie.cent.gla.ac.uk (8.8.4/UK-2.2a/cent-sparc) with SMTP id OAA28512; Fri, 23 Jan 1998 14:41:22 GMT Date: Fri, 23 Jan 1998 14:41:20 +0000 (GMT) From: James Craig <9606585c@udcf.gla.ac.uk> X-Sender: 9606585c@lenzie.cent.gla.ac.uk To: Phil Norman cc: Vincent PENNE , linux-arm@vger.rutgers.edu Subject: Re: missing stuffs in gcc In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Orcpt: rfc822;linux-arm@vger.rutgers.edu Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO > /usr/include/linux -> /usr/src/linux/include/linux > /usr/include/scsi -> /usr/src/linux/include/scsi > /usr/include/asm -> /usr/src/linux/include/asm > > I'm not entirely sure about whether these links are right - someone > please correct me if I'm screamingly wrong. They certainly look OK to me, but if you just do a make config in your /usr/src/linux, then all the links are made for you. I'm not totally sure about the SCSI one - I've never had occasion to use it, so I wouldn't notice, but the linux one is definately right, and the asm one will be right after a make config (/usr/src/linux/include/asm is symlinked to /usr/src/linux/include/asm-arm or asm-i386 etc. by make config) It probably won't work before that - it just depends on how things are set up in the kernel distribution. -- James Craig <9606585c@udcf.gla.ac.uk> unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu From owner-linux-arm-outgoing@vger.rutgers.edu Sat Jan 24 20:42:10 1998 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id UAA08282 for ; Sat, 24 Jan 1998 20:42:08 GMT Received: from vger.rutgers.edu ([128.6.190.2]:28256 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <13002-619>; Sat, 24 Jan 1998 22:42:04 +0200 Received: by vger.rutgers.edu id <971114-257>; Sat, 24 Jan 1998 15:40:26 -0500 Received: from post-20.mail.demon.net ([194.217.242.27]:60194 "HELO post.mail.demon.net" ident: "NO-IDENT-SERVICE") by vger.rutgers.edu with SMTP id <971121-257>; Sat, 24 Jan 1998 15:39:50 -0500 Received: from treblig.demon.co.uk ([194.222.210.232]) by post.mail.demon.net id aa2028810; 24 Jan 98 20:27 GMT Date: Sat, 24 Jan 1998 20:23:15 +0000 (GMT) From: Dave Gilbert X-Sender: gilbertd@tardis.home.dave To: linux-arm@vger.rutgers.edu Subject: Patches to 2.0.33 for old Arc Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Orcpt: rfc822;linux-arm@vger.rutgers.edu Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO Hi, Russ and myself have just cut the following minor changes to allow 2.0.33 to be built for old Arc's. It now seems to be running fine on my A440 and should run on things like R260's etc as well (I'll try that later). One other issue that is known is that 'mkswap' doesn't work on the old machines (the ancient version I had been using does - but the current distribution doesn't). I'm sure that will be fixed very soon. Dave diff -r linux-2.0.33-arm-asOnWeb/arch/arm/boot/tools/build.c ../2.0.33/linux/arch/arm/boot/tools/build.c 27c27 < unsigned long my_header; --- > unsigned int my_header; diff -r linux-2.0.33-arm-asOnWeb/arch/arm/drivers/block/blk.h ../2.0.33/linux/arch/arm/drivers/block/blk.h 109c109 < if (!__err) set_device_ro((dev),get_fs_long((long *) (where))); return __err; } \ --- > if (!__err) set_device_ro((dev),get_user((long *) (where))); return __err; } \ 111c111 < if (!__err) put_fs_long(0!=is_read_only(dev),(long *) (where)); return __err; } --- > if (!__err) put_user(0!=is_read_only(dev),(long *) (where)); return __err; } diff -r linux-2.0.33-arm-asOnWeb/arch/arm/drivers/block/fd1772.c ../2.0.33/linux/arch/arm/drivers/block/fd1772.c 142a143 > #include diff -r linux-2.0.33-arm-asOnWeb/arch/arm/drivers/scsi/acornscsi.c ../2.0.33/linux/arch/arm/drivers/scsi/acornscsi.c 1663,1664c1663 < if (host->device[host->SCpnt->target].sync_state == SYNC_ASYNCHRONOUS || < host->device[host->SCpnt->target].sync_state == SYNC_NEGOCIATE) { --- > if (host->device[host->SCpnt->target].sync_state == SYNC_NEGOCIATE) { diff -r linux-2.0.33-arm-asOnWeb/arch/arm/lib/getconsdata.c ../2.0.33/linux/arch/arm/lib/getconsdata.c 21c21 < #if defined(CONFIG_PROC_ARMO) --- > #if defined(CONFIG_CPU_ARM2) || defined(CONFIG_CPU_ARM3) diff -r linux-2.0.33-arm-asOnWeb/arch/arm/mm/proc-arm2,3.S ../2.0.33/linux/arch/arm/mm/proc-arm2,3.S 11c11 < #include "constants.h" --- > #include "../lib/constants.h" diff -r linux-2.0.33-arm-asOnWeb/include/asm-arm/a.out.h ../2.0.33/linux/include/asm-arm/a.out.h 3a4,5 > #include > 6,13c8,15 < unsigned long a_info; /* Use macros N_MAGIC, etc for access */ < unsigned a_text; /* length of text, in bytes */ < unsigned a_data; /* length of data, in bytes */ < unsigned a_bss; /* length of uninitialized data area for file, in bytes */ < unsigned a_syms; /* length of symbol table data in file, in bytes */ < unsigned a_entry; /* start address */ < unsigned a_trsize; /* length of relocation info for text, in bytes */ < unsigned a_drsize; /* length of relocation info for data, in bytes */ --- > __u32 a_info; /* Use macros N_MAGIC, etc for access */ > __u32 a_text; /* length of text, in bytes */ > __u32 a_data; /* length of data, in bytes */ > __u32 a_bss; /* length of uninitialized data area for file, in bytes */ > __u32 a_syms; /* length of symbol table data in file, in bytes */ > __u32 a_entry; /* start address */ > __u32 a_trsize; /* length of relocation info for text, in bytes */ > __u32 a_drsize; /* length of relocation info for data, in bytes */ diff -r linux-2.0.33-arm-asOnWeb/include/asm-arm/arch-arc/io.h ../2.0.33/linux/include/asm-arm/arch-arc/io.h 61c61 < "strb %1, [%0, %2, lsl #2]" --- > "str %1, [%0, %2, lsl #2]" -------------------------------------------------------------------- / Dr. David Alan Gilbert | Running Linux on Alpha & ARM \ \ gro.gilbert @ treblig.org | ------- Happy in hex ------- / \____________________________|___ http://www.treblig.demon.co.uk __/ unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu From owner-linux-arm-outgoing@vger.rutgers.edu Mon Jan 26 12:30:03 1998 Return-Path: Received: from nic.funet.fi ([128.214.248.6] (may be forged)) by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id MAA24503 for ; Mon, 26 Jan 1998 12:29:57 GMT Received: from vger.rutgers.edu ([128.6.190.2]:46201 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <17487-621>; Mon, 26 Jan 1998 14:28:23 +0200 Received: by vger.rutgers.edu id <971261-257>; Mon, 26 Jan 1998 07:20:23 -0500 Received: from server21.digital.fr ([193.56.15.21]:1871 "EHLO server21.digital.fr" ident: "NO-IDENT-SERVICE") by vger.rutgers.edu with ESMTP id <971264-257>; Mon, 26 Jan 1998 07:09:21 -0500 Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by server21.digital.fr (8.7.5/8.7) with ESMTP id NAA02677 for ; Mon, 26 Jan 1998 13:10:26 +0100 (MET) Received: from vbormc.vbo.dec.com (vbormc.vbo.dec.com [16.36.208.94]) by mail.vbo.dec.com (8.8.6/8.7) with ESMTP id NAA05111 for ; Mon, 26 Jan 1998 13:10:28 +0100 (MET) Received: from linux.reo.dec.com (linux.reo.dec.com [16.36.0.79]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id NAA22058 for ; Mon, 26 Jan 1998 13:48:54 +0100 Received: from linux.reo.dec.com (localhost [127.0.0.1]) by linux.reo.dec.com (8.8.5/8.7.1) with ESMTP id MAA20114 for ; Mon, 26 Jan 1998 12:08:42 GMT Message-Id: <199801261208.MAA20114@linux.reo.dec.com> To: linux-arm@vger.rutgers.edu Subject: Building a toolset for ARM/Linux Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 Jan 1998 12:08:42 +0000 From: "Ka'Plaagh" X-Orcpt: rfc822;linux-arm@vger.rutgers.edu Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO All, I'm a little stuck building cross compilers/libraries and any help would be appreciated (like 'look there stupid'). So far, I followed the excellent CrossGCC FAQ and I have built binutils-2.7 + ARM patches. I am now trying to build gcc-2.7.2.2 + cross build patches + ARM patches. I've got to the part where it refuses to build the cross flavour of glibc (ligcc1.cross) 'cos it (the makefile) does not know how)...I'm now going off for lunch hoping that I can think of a better approach... Dave ps Oh, of course I'm building the cross tools on an Intel Linux system pps I'm also about to build egcs, but that's a seperate issue ---------------------------------------------------------------------- David A Rusling Consulting Engineer European Semiconductor Applications Digital Equipment Co Ltd., Engineering PO Box 121, Imperial Way, Worton Grange Reading RG2 0TU Linux, Alpha, StrongArm, PCI Tel: UK-(0)1734-204380 Fax: UK-(0)1734-203133 ---------------------------------------------------------------------- unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu From owner-linux-arm-outgoing@vger.rutgers.edu Mon Jan 26 13:46:59 1998 Return-Path: Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id NAA25117 for ; Mon, 26 Jan 1998 13:46:58 GMT Received: from vger.rutgers.edu ([128.6.190.2]:58446 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <2913-621>; Mon, 26 Jan 1998 15:42:28 +0200 Received: by vger.rutgers.edu id <970976-257>; Mon, 26 Jan 1998 08:36:14 -0500 Received: from odie.barnet.ac.uk ([194.82.202.98]:8260 "EHLO odie.barnet.ac.uk" ident: "willy") by vger.rutgers.edu with ESMTP id <971256-257>; Mon, 26 Jan 1998 08:31:19 -0500 Received: (from willy@localhost) by odie.barnet.ac.uk (8.8.6/8.8.6) id NAA24931; Mon, 26 Jan 1998 13:29:13 GMT From: Matthew Wilcox Message-Id: <199801261329.NAA24931@odie.barnet.ac.uk> Subject: Re: Building a toolset for ARM/Linux To: rusling@linux.reo.dec.com (Ka'Plaagh) Date: Mon, 26 Jan 1998 13:29:12 +0000 (GMT) Cc: linux-arm@vger.rutgers.edu In-Reply-To: <199801261208.MAA20114@linux.reo.dec.com> from "Ka'Plaagh" at Jan 26, 98 12:08:42 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Orcpt: rfc822;linux-arm@vger.rutgers.edu Sender: owner-linux-arm@vger.rutgers.edu Precedence: bulk Status: RO > I'm a little stuck building cross compilers/libraries and any help would be appreciated (like 'look there stupid'). So far, I followed the > excellent CrossGCC FAQ and I have built binutils-2.7 + ARM patches. I am now > trying to build gcc-2.7.2.2 + cross build patches + ARM patches. I've got to > the part where it refuses to build the cross flavour of glibc (ligcc1.cross) > 'cos it (the makefile) does not know how)...I'm now going off for lunch hoping > that I can think of a better approach... Here's two ideas. They may be totally bogus: Get gcc 2.8.0 and build its libgcc, then slot that into the 2.7.2.3 instead Grab the precompiled libgcc out of an armlinux rpm - i'd guess it's in the gcc set, but I haven't checked this. In either case, I think there's a file to touch to tell it you've built libgcc, but I'm not sure. By the way, you'd be better off using binutils 2.8.1.0.15 from sunsite - it has ARM support in it by default. unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu