From mozes at slackware.com Wed Jun 20 17:14:35 2007 From: mozes at slackware.com (Stuart Winter) Date: Wed, 20 Jun 2007 10:14:35 -0700 (PDT) Subject: [armedslack] EABI ? Message-ID: Hi I've been doing some thinking and ARMedslack probably has to move to the new ABI, which essentially means starting from scratch once again. And I could also consider soft vs hard float (although from the bug reports in gcc and some others, hard float still seems easier). Any thoughts? Slackware 12.0 will be released shortly so I might finish up to that, and then think about making an EABI version. Or I might just skip releasing anything about 12.0 at all and just build for EABI now since there's still kde and xap which would need rebuilding anyway. Hmm. From psychicistnonconformist at gmail.com Wed Jun 20 18:28:46 2007 From: psychicistnonconformist at gmail.com (Sunil Amitkumar Janki) Date: Wed, 20 Jun 2007 20:28:46 +0200 Subject: [armedslack] EABI ? In-Reply-To: References: Message-ID: <467971DE.7070208@gmail.com> Stuart Winter wrote: > I've been doing some thinking and ARMedslack probably > has to move to the new ABI, which essentially means > starting from scratch once again. > Do you remember my post some time ago about the EABI because it would accelerate floating point emulation by a factor of 10? Now it seems it will be reality out of necessity. > And I could also consider soft vs hard float (although from the bug > reports in gcc and some others, hard float still seems easier). > A transition like this is always painful so will we have to experience the same thing again when enabling soft float? I will be in the same position later this year when Loongson 2F will be released with full MIPS64R2 compatibility. The current 2E is only MIPS3 compatible so I'm postponing a 64-bit Slackware MIPS release until 2F systems are available. > Any thoughts? > Slackware 12.0 will be released shortly so I might finish up > to that, and then think about making an EABI version. > Or I might just skip releasing anything about 12.0 at all and > just build for EABI now since there's still kde and xap which > would need rebuilding anyway. > I think it's better to do some kind of release of 12.0 anyway. It could be the last release that runs on some older hardware particularly if the old ABI isn't supported anymore in Glibc 2.6 or 2.7. I have had problems building Qt3/KDE3 with optimisations on Slackware Current MIPS with GCC 4.1.2 so I have used GCC 3.4.6 for that. Building these works fine but now I'm finding that libstdc++.so.6.0.3 from GCC 3.4.6 and libstdc++.so.6.0.8 are in conflict with each other. So at runtime it's one or the other or you will experience crashes and weird bugs. Maybe I shouldn't build KDE with optimisations at all. While seeing all of this I'm thinking of compiling Qt3/KDE3 unoptimised or statically (if possible) or preferably just going straight to KDE 4 Beta releases. I have also posted a question on the Qt blog asking whether there will be another release in the Qt3 release series before it's EOL'ed July 1st, probably not :-( . Furthermore I have tried to build OpenOffice.org 2.2.1 for MIPS but I haven't succeeded yet. After figuring this out I'll post the build script for ARM as well. Regards, Sunil From m-lists at biscuit.org.uk Fri Jun 22 10:37:35 2007 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Fri, 22 Jun 2007 11:37:35 +0100 (BST) Subject: [armedslack] EABI ? In-Reply-To: <467971DE.7070208@gmail.com> References: <467971DE.7070208@gmail.com> Message-ID: > I think it's better to do some kind of release of 12.0 anyway. It > could be the last release that runs on some older hardware > particularly if the old ABI isn't supported anymore in Glibc 2.6 > or 2.7. The only thing is that the whole point of the project was to run Slackware on my ageing StrongARM (which needs armv3) RiscPC -- which EABI does not support. Hmm. I'll have to think about this. On the other hand, if Linux 2.6 was ported to the Iyonix I would be happy since I could use that as a desktop machine and with the speedups from rebuilding as EABI, it'd probably be much more usable (can you tell I am not a scientist? :-) ) I could maintain the Old ABI version for a while but there'd come a point that I could not be able to build new software and so on, and I prefer to keep up with Slackware developments. [..] > Furthermore I have tried to build OpenOffice.org 2.2.1 for MIPS but > I haven't succeeded yet. After figuring this out I'll post the build script > for ARM as well. I wonder if Openoffice has been maintained for ARM? I know Peter Naulls ported it for the PsionNetbook project but I don't know if it was maintained afterwards (I know he wouldn't have). -- Stuart Winter www.armedslack.org From psychicistnonconformist at gmail.com Sat Jun 23 09:08:49 2007 From: psychicistnonconformist at gmail.com (Sunil Amitkumar Janki) Date: Sat, 23 Jun 2007 11:08:49 +0200 Subject: [armedslack] EABI ? In-Reply-To: References: <467971DE.7070208@gmail.com> Message-ID: <467CE321.6070307@gmail.com> Stuart Winter wrote: > The only thing is that the whole point of the project was to run > Slackware on my ageing StrongARM (which needs armv3) RiscPC -- which EABI > does not support. Hmm. I'll have to think about this. > I don't know what the reasons are to completely abandon the old ABI but isn't it possible to make these older ARM versions functional with the new EABI? That would extend the useful life of the hardware enormously. I don't like throwing away working hardware, I still have some i486 and Pentiums lying around, and neither should you. > On the other hand, if Linux 2.6 was ported to the Iyonix I would be happy > since I could use that as a desktop machine and with the speedups from > rebuilding as EABI, it'd probably be much more usable > (can you tell I am not a scientist? :-) ) > It's really a shame the patch for 2.4 was never integrated into the kernel proper and/or updated for 2.6. That would have alleviated the process a lot and you could be running the newer Slackware releases on your Iyonix. Now for the time being you could just install those in chroots and build software that way. I initially built Slackware MIPS that way from the installed Debian system, just until the point that it could become self-hosting after six days of building and rebuilding using LFS as a guideline. I have been looking into your 2.4.27 kernel diff but it's huge and it's really time-consuming to try to make sense of it and split it up into smaller pieces that I could understand, not that I'm in the least knowledgeable about kernel matters anyway :-). If you could point out which pieces, a.o drivers, are important to get 2.6 running on your Iyonix PC that would help a lot and I could focus on those things that have to be added or ported from the functional 2.4 kernel. I have a 2.6 kernel booting on my Dell Axim X3 PDA with an Xscale PXA26x processor so most of the pieces are pretty much there already. > I could maintain the Old ABI version for a while but there'd come a > point that I could not be able to build new software and so on, and I > prefer to keep up with Slackware developments. > This will of course only work in the short term. In the long run it's not beneficial and could even be considered a waste of time since it could be spent at fixing the fundamental problems instead so you could indeed keep up with the latest Slackware developments. > I wonder if Openoffice has been maintained for ARM? I know Peter Naulls > ported it for the PsionNetbook project but I don't know if it was > maintained afterwards (I know he wouldn't have). You know, Lemote have ported OpenOffice 2.0.4 to MIPS, and since the included Debian system has a Chinese version installed and it works that's proof that it's possible to port OpenOffice to any architecture, including ARM. The CEO has sent me the patch to get it to build on MIPS, but sadly the build process doesn't work at the moment on Slackware MIPS. I'm still trying to figure out why it doesn't but as a last resort I'm considering building it on the included Debian (in a chroot) if that yields a working OpenOffice build. I could do the same for ARM but where is the cheap ARM hardware that should be abounding now that the Windows and the x86 hardware that can run it is becoming less and less valuable and relevant? Apart from Castle's Iyonix I have only found this website with embedded boards: http://www.toradex.com/e/computer_boards.php. It's really time for an Acorn Risc Machines renaissance and seeing what Lemote have done with their miniature Fu Long computer I am really interested in an ARM equivalent as well. Regards, Sunil From mozes at slackware.com Sat Jun 23 09:22:58 2007 From: mozes at slackware.com (Stuart Winter) Date: Sat, 23 Jun 2007 02:22:58 -0700 (PDT) Subject: [armedslack] New updates uploaded Message-ID: Hi folks I've uploaded new updates -- there's mostly left to do: kde/ - upgrades xap/ - upgrades & recompiles testing of the installer I removed mozilla-firefox for the time being because it compiles but segfaults as soon as it's launched - so that needs a bit of TLC. I also had patch the hal RC script to make it exit because HAL causes the LSI SCSI Driver inside QEMU to barf and ext3 looks like it just ate a bad curry. Other than that, hopefuly stuff works ;) From m-lists at biscuit.org.uk Sat Jun 23 12:08:47 2007 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sat, 23 Jun 2007 13:08:47 +0100 (BST) Subject: [armedslack] EABI ? In-Reply-To: <467CE321.6070307@gmail.com> References: <467971DE.7070208@gmail.com> <467CE321.6070307@gmail.com> Message-ID: > I don't know what the reasons are to completely abandon the old ABI but > isn't it possible to make these older ARM versions functional with the > new EABI? >From the reading I have done of the Debian EABI port, I am lead to believe that the answer is no. Debian are supporting ARMv4 -- but I'm not sure whether that's because they're dropping armv3 support anyway for their little endian old ABI port, or not. I've asked on #debian-arm on irc and I'll see what response I get. > That would extend the useful life of the hardware enormously. I don't > like throwing away working hardware, I still have some i486 and Pentiums > lying around, and neither should you. Heh. Well, The RiscPC isn't exactly the height of excellence in the range of hardware -- I think it's just that I spent so much money on it when I bought it, that subconciously I'm protecting my investment ;-) I'm barely using the RiscPC now apart from to test the installer every now and then once I've done enough package updates -- everthing happens inside QEMU. > It's really a shame the patch for 2.4 was never integrated into the > kernel proper and/or updated for 2.6. That would have alleviated the > process a lot and you could be running the newer Slackware releases on > your Iyonix. Now for the time being you could just install those in > chroots and build software that way. I cannot chroot into it though because we need a 2.6 Kernel with the glibc in armedslack-current. The Iyonix is reduced to a build host for -noarch packages and a few other native-only distribution building scripts which I didn't get around to modifying to run on another host yet;other than that I may as well turn it off! :-( > I initially built Slackware MIPS that way from the installed Debian > system, just until the point that it could become self-hosting after six > days of building and rebuilding using LFS as a guideline. That's one way of doing it -- good old Debian :-) Ah yeah. Thinking about the EABI port I started wondering how I actually managed to get the original armedslack bootstrapped. I think scratchbox helped a lot since it had a number of tools and libraries already available. It's amazing how much stuff, even just during the build process, relies on things you'd not realise - like perl, ruby and so on. > I have been looking into your 2.4.27 kernel diff but it's huge and it's > really time-consuming to try to make sense of it and split it up into > smaller pieces that I could understand, not that I'm in the least > knowledgeable about kernel matters anyway :-). Yeah - Jim had a look at it at one point too and came to the conclusion that most of it was Debian junk. Why the hell Peter ported it against a Debian kernel, I don't know. I spoke to Wookey (one of the Debian devels) and he said he thinks there would not be a lot to do for the Iyonix with the latest 2.6 kernels. But I'm not even a C programmer so there is no point in me looking at it -- it'd be like going to those modern art exhibitions where someone's parcel taped a load of lego men to some egg boxes and poured moulten nutella over them. I'm like "Well it looks interesting but I'm not really sure what they're trying to do there". Jim also said that you'd definitley need one of the Iyonixes to port it with. When Peter was doing the intial port he was always using the serial console since the graphics driver wasn't working. Castle may lend or give someone a machine if they could port it-- maybe -- I have never asked. > I could do the same for ARM but where is the cheap ARM hardware that > should be abounding now that the Windows and the x86 hardware that can > run it is becoming less and less valuable and relevant? I know what you mean but most of the ARM boards/devices are embedded stuff with limited RAM and storage which isn't good for compiling anything... or they cost a small fortune. > It's really time for an Acorn Risc Machines renaissance and seeing what > Lemote have done with their miniature Fu Long computer I am really > interested in an ARM equivalent as well. :-) I've decided that what I'll do is release armedslack-12.0 (Slackware 12) and get it working properly, rather than continually chasing -current. And once 12.0's working properly, I'll move to making -current with EABI- even if it means that the RiscPC cannot be used anymore. -- Stuart Winter www.armedslack.org From alanh at fairlite.demon.co.uk Mon Jun 25 12:37:28 2007 From: alanh at fairlite.demon.co.uk (Alan Hourihane) Date: Mon, 25 Jun 2007 13:37:28 +0100 Subject: [armedslack] EABI ? In-Reply-To: References: <467971DE.7070208@gmail.com> <467CE321.6070307@gmail.com> Message-ID: <1182775048.7862.15.camel@localhost> On Sat, 2007-06-23 at 13:08 +0100, Stuart Winter wrote: > > I don't know what the reasons are to completely abandon the old ABI but > > isn't it possible to make these older ARM versions functional with the > > new EABI? > > From the reading I have done of the Debian EABI port, I am lead to > believe that the answer is no. Debian are supporting ARMv4 -- but I'm > not sure whether that's because they're dropping armv3 support anyway for > their little endian old ABI port, or not. I've asked on #debian-arm on > irc and I'll see what response I get. > > > That would extend the useful life of the hardware enormously. I don't > > like throwing away working hardware, I still have some i486 and Pentiums > > lying around, and neither should you. > > Heh. Well, The RiscPC isn't exactly the height of excellence in > the range of hardware -- I think it's just that I spent so much > money on it when I bought it, that subconciously I'm protecting > my investment ;-) > > I'm barely using the RiscPC now apart from to test the installer every > now and then once I've done enough package updates -- everthing > happens inside QEMU. > > > > It's really a shame the patch for 2.4 was never integrated into the > > kernel proper and/or updated for 2.6. That would have alleviated the > > process a lot and you could be running the newer Slackware releases on > > your Iyonix. Now for the time being you could just install those in > > chroots and build software that way. > > I cannot chroot into it though because we need a 2.6 Kernel with the > glibc in armedslack-current. The Iyonix is reduced to a build host > for -noarch packages and a few other native-only distribution building > scripts which I didn't get around to modifying to run on another host > yet;other than that I may as well turn it off! :-( > > > I initially built Slackware MIPS that way from the installed Debian > > system, just until the point that it could become self-hosting after six > > days of building and rebuilding using LFS as a guideline. > > That's one way of doing it -- good old Debian :-) > Ah yeah. Thinking about the EABI port I started wondering how I actually > managed to get the original armedslack bootstrapped. I think scratchbox > helped a lot since it had a number of tools and libraries already > available. It's amazing how much stuff, even just during the build > process, relies on things you'd not realise - like perl, ruby and so on. > > > I have been looking into your 2.4.27 kernel diff but it's huge and it's > > really time-consuming to try to make sense of it and split it up into > > smaller pieces that I could understand, not that I'm in the least > > knowledgeable about kernel matters anyway :-). > > Yeah - Jim had a look at it at one point too and came to the conclusion > that most of it was Debian junk. Why the hell Peter ported it against > a Debian kernel, I don't know. I spoke to Wookey (one of the Debian > devels) and he said he thinks there would not be a lot to do for the > Iyonix with the latest 2.6 kernels. But I'm not even a C programmer so > there is no point in me looking at it -- it'd be like going to those > modern art exhibitions where someone's parcel taped a load of lego men > to some egg boxes and poured moulten nutella over them. I'm like "Well it > looks interesting but I'm not really sure what they're trying to do > there". > > Jim also said that you'd definitley need one of the Iyonixes to port it > with. When Peter was doing the intial port he was always using the > serial console since the graphics driver wasn't working. > Castle may lend or give someone a machine if they could port it-- maybe -- > I have never asked. > > > I could do the same for ARM but where is the cheap ARM hardware that > > should be abounding now that the Windows and the x86 hardware that can > > run it is becoming less and less valuable and relevant? > > I know what you mean but most of the ARM boards/devices are embedded stuff > with limited RAM and storage which isn't good for compiling anything... or > they cost a small fortune. > > > It's really time for an Acorn Risc Machines renaissance and seeing what > > Lemote have done with their miniature Fu Long computer I am really > > interested in an ARM equivalent as well. > > :-) > > I've decided that what I'll do is release armedslack-12.0 (Slackware 12) > and get it working properly, rather than continually chasing -current. > And once 12.0's working properly, I'll move to making -current with > EABI- even if it means that the RiscPC cannot be used anymore. Ugh. That's unfortunate if it can't. I'll need to switch to another distro with old ABI support. Here's hoping it can. Alan. From jawkins at armedslack.org Tue Jun 26 15:40:28 2007 From: jawkins at armedslack.org (Jim Hawkins) Date: Tue, 26 Jun 2007 16:40:28 +0100 (BST) Subject: [armedslack] New updates uploaded In-Reply-To: References: Message-ID: On Sat, 23 Jun 2007, Stuart Winter wrote: > I also had patch the hal RC script to make it exit because HAL causes > the LSI SCSI Driver inside QEMU to barf and ext3 looks like it just ate > a bad curry. Are you using a 2.6.21 kernel? Apparently the ARM versatile PCI code is buggy and causes the SCSI driver to break in 2.6.21. Cheers, Jim From m-lists at biscuit.org.uk Wed Jun 27 09:43:56 2007 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Wed, 27 Jun 2007 10:43:56 +0100 (BST) Subject: [armedslack] New updates uploaded In-Reply-To: References: Message-ID: > Are you using a 2.6.21 kernel? Apparently the ARM versatile PCI code is > buggy and causes the SCSI driver to break in 2.6.21. Linux mutley 2.6.20-versatile #1 Tue Feb 13 01:01:22 GMT 2007 armv5tejl GNU/Linux I think it happened when I upgraded hal -- but I could not be sure because /etc/rc.d/rc.hald was chmod 644 and only chmod 755'd after the most recent build. So it could be that it was never running at all. I'll try it on the RiscPC soon. I intend on upgrading the Kernel once 2.6.22 is released. -- Stuart Winter www.armedslack.org