From laurens at daemon.be Wed Jul 1 20:58:06 2009 From: laurens at daemon.be (Laurens Vets) Date: Wed, 01 Jul 2009 22:58:06 +0200 Subject: [armedslack] Site news archive Message-ID: <4A4BCDDE.6040806@daemon.be> Hi list, Is there an archive somewhere of the news that has appeared on the armedslack.org website? From m-lists at biscuit.org.uk Thu Jul 2 07:04:17 2009 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Thu, 2 Jul 2009 08:04:17 +0100 (BST) Subject: [armedslack] Site news archive In-Reply-To: <4A4BCDDE.6040806@daemon.be> References: <4A4BCDDE.6040806@daemon.be> Message-ID: Hi > Is there an archive somewhere of the news that has appeared on the > armedslack.org website? http://www.armedslack.org/index.html-oldnews -- Stuart Winter www.armedslack.org From dave at chronolytics.com Mon Jul 6 01:09:01 2009 From: dave at chronolytics.com (David F. Carlson) Date: Sun, 5 Jul 2009 21:09:01 -0400 (EDT) Subject: [armedslack] EABI Message-ID: <200907060109.n661918m031797@chronolytics.com> I am glad to see that you would like to do an EABI ARMed slack. I have been doing slackware since 1993 (0.99pl13 rulez). I have been doing ARM since 2004 (on QNX). I recently build the gcc/glibc for EABI using codesourcery as a base toolchain. I would like to "help" with the EABI although I am most interested in S3C6410 (arm1176jzf-s) and not so much "legacy" armv4 etc. My most recent toy is running Ubuntu -- but I like the slack. Let me know how/if you want help. David F. Carlson Chronolytics, Inc. Rochester, NY mailto:dave at chronolytics.com http://www.chronolytics.com "The faster I go, the behinder I get." --Lewis Carroll From m-lists at biscuit.org.uk Mon Jul 6 12:31:28 2009 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Mon, 6 Jul 2009 13:31:28 +0100 (BST) Subject: [armedslack] EABI In-Reply-To: <200907060109.n661918m031797@chronolytics.com> References: <200907060109.n661918m031797@chronolytics.com> Message-ID: Hi David, > I am glad to see that you would like to do an EABI ARMed slack. I started building the base packages on the weekend and have got pretty far. I should be able to boot into a new Slackware ARM EABI OS within a few more days. After that I'll need to rebuild everything a few times since these are just bootstrap versions. > I recently build the gcc/glibc for EABI using codesourcery as a base toolchain. > > I would like to "help" with the EABI although I am most interested in > S3C6410 (arm1176jzf-s) and not so much "legacy" armv4 etc. My most > recent toy is running Ubuntu -- but I like the slack. Slackware ARM is built for the lowest denominator on the market which is "armv4". I did consider using armv5 but there are so many devices which would be excluded, that I decided to set the base at armv4. The Kernels are always optomised for the specific device, and my thoughts are that if someone wants to, they can rebuild some of the userspace stuff using -march=armv5 pretty easily. What I'm having trouble with at the moment is the "target triplet" name of the toolchain. It ought to be "arm-slackware-linux" as it is for the Slackware 12.2 but the only way I've found to make the new gcc output for the EABI is to name the toolchain "arm-slackware-linux-gnueabi". There must be a way of changing the gcc specs, or passing a config option when building gcc (you can use --arch=armv4t to tell it to output binaries for armv4t by default), but I haven't figured out how to tell it to output EABI yet. If anybody knows how to make this work, please let me know! From dave at chronolytics.com Mon Jul 6 16:23:57 2009 From: dave at chronolytics.com (David F. Carlson) Date: Mon, 6 Jul 2009 12:23:57 -0400 (EDT) Subject: [armedslack] EABI In-Reply-To: Message-ID: <200907061623.n66GNvp3018797@chronolytics.com> According to Stuart Winter: > > What I'm having trouble with at the moment is the "target triplet" > name of the toolchain. > It ought to be "arm-slackware-linux" as it is for the Slackware 12.2 > but the only way I've found to make the new gcc output for the EABI > is to name the toolchain "arm-slackware-linux-gnueabi". > There must be a way of changing the gcc specs, or passing a config > option when building gcc (you can use --arch=armv4t to tell it to > output binaries for armv4t by default), but I haven't figured out > how to tell it to output EABI yet. > If anybody knows how to make this work, please let me know! > I believe that the "triplet" is such that linux-gnueabi is a single tuple (not 2 as the dash '-' would imply.) My builds copied from my boostraped from codesourcery is: arm-none-linux-gnueabi Building as arm-linux-gnueabi barfs that you need a triple. arm-slackware-linux-gnueabi is the correct answer. Like in the ancient days before the new glibc that toolchain was -- i386-slackware-linux-gnuaout (that would be slackware from sometime in 1995!) David F. Carlson Chronolytics, Inc. Rochester, NY mailto:dave at chronolytics.com http://www.chronolytics.com "The faster I go, the behinder I get." --Lewis Carroll From dave at chronolytics.com Mon Jul 6 16:38:42 2009 From: dave at chronolytics.com (David F. Carlson) Date: Mon, 6 Jul 2009 12:38:42 -0400 (EDT) Subject: [armedslack] EABI In-Reply-To: Message-ID: <200907061638.n66GcgZU018903@chronolytics.com> According to Stuart Winter: > > Slackware ARM is built for the lowest denominator on the market > which is "armv4". I did consider using armv5 but there are so many > devices which would be excluded, that I decided to set the base at armv4. > The Kernels are always optomised for the specific device, and my > thoughts are that if someone wants to, they can rebuild some of the > userspace stuff using -march=armv5 pretty easily. Stuart, The hassle with this (if I am correct) is that the EABI supports FPE and VFP -- but at compile time only. The glibc either builds the setjmp, fp_context.h, etc. to work with "old" float or new float. "The" EABI is really 2 ABIs. So, the armv4 EABI precludes running on armv6 (and would thus not be terribly useful (to me!). What the handheld.org folks do is build 3 Ubuntu variants: armv5el armv5el-vfp armv6el-vfp That is a lot of work though... Are there any other vfp people on the list that will be "lost" if the armedslack is fpe only? David F. Carlson Chronolytics, Inc. Rochester, NY mailto:dave at chronolytics.com http://www.chronolytics.com "The faster I go, the behinder I get." --Lewis Carroll From m-lists at biscuit.org.uk Tue Jul 7 10:30:54 2009 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Tue, 7 Jul 2009 11:30:54 +0100 (BST) Subject: [armedslack] EABI In-Reply-To: <200907061638.n66GcgZU018903@chronolytics.com> References: <200907061638.n66GcgZU018903@chronolytics.com> Message-ID: > The hassle with this (if I am correct) is that the EABI supports FPE and > VFP -- but at compile time only. I was checking the Debian gcc build script for gcc http://ftp.de.debian.org/debian/pool/main/g/gcc-4.3/gcc-4.3_4.3.3-13.diff.gz zcat gcc-4.3_4.3.3-13.diff.gz|patch -p1 less debian/rules2 And we'll find: ifneq (,$(findstring arm-vfp,$(DEB_TARGET_GNU_CPU))) CONFARGS += --with-fpu=vfp endif ifneq (,$(findstring arm-linux-gnueabi,$(DEB_TARGET_GNU_TYPE))) CONFARGS += --disable-sjlj-exceptions ifeq ($(distribution),Ubuntu) CONFARGS += --with-arch=armv5t --with-tune=cortex-a8 #CONFARGS += --with-float=softfp --with-fpu=vfp #CONFARGS += --enable-multilib endif endif If you look at the actual build log: https://buildd.debian.org/fetch.cgi?&pkg=gcc-4.3&ver=4.3.3-13&arch=armel&stamp=1246174992&file=log we can see that Debian armel isn't build using vfp. Does this then mean that Debian's only armel port does not work on your armv6 cpu? This is how I'm currently configuring gcc-4.3.3 for -current EABI: case $ARCH in arm) export SLKCFLAGS="-O2 -march=armv4t" # "--with-arch" sets the gcc defaults export ARCH_CONFARGS="--disable-libssp --disable-sjlj-exceptions --enable-mpfr --with-arch=armv4t" TARGET=$ARCH-slackware-linux-gnueabi # build gcc mkdir gcc.build.lnx cd gcc.build.lnx BOOT_CFLAGS="$SLKCFLAGS" \ STAGE1_CFLAGS="$SLKCFLAGS" \ CFLAGS="$SLKCFLAGS" \ CXXFLAGS="$SLKCFLAGS" \ LIBCFLAGS="$SLKCFLAGS" \ LIBCXXFLAGS="$SLKCFLAGS" \ GCJFLAGS="$SLKCFLAGS" \ ../gcc-$VERSION/configure $ARCH_CONFARGS \ --prefix=/usr \ --libdir=/usr/lib$LIBDIRSUFFIX \ --enable-bootstrap \ --enable-checking=release \ --with-system-zlib \ --disable-libunwind-exceptions \ --enable-shared \ --enable-languages=c,c++,fortran,java,objc \ --enable-threads=posix \ --enable-__cxa_atexit \ --with-gnu-ld \ --verbose \ --host=$TARGET \ --build=$TARGET \ --target=$TARGET || failconfig > armv5el > armv5el-vfp > armv6el-vfp > > That is a lot of work though... > > Are there any other vfp people on the list that will be "lost" if the armedslack is fpe only? I was reading this and starting to understand it a little: http://wiki.debian.org/ArmEabiPort >From what I understand, this isn't a problem? It may be that the distribution isn't optimised as a whole, but particular packages can be if necessary? I certainly can do one port, but not maintain any more than 1 -- the old ABI port stops (apart from security fixes) at Slackware 12.2. -- Stuart Winter www.armedslack.org From dave at chronolytics.com Wed Jul 8 11:45:05 2009 From: dave at chronolytics.com (David F. Carlson) Date: Wed, 8 Jul 2009 07:45:05 -0400 (EDT) Subject: [armedslack] EABI In-Reply-To: Message-ID: <200907081145.n68Bj5H1014564@chronolytics.com> What a mess. I am not sure the thumb interworking is worth the hassle. But the 5 or 6 different floating points all determined at compile time -- oi what a mess. Nice debian article though. Thanks. This is my gcc build spec: Target: arm-none-linux-gnueabi Configured with: ../configure -v --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-clocale=gnu --enable-mpfr --disable-libssp --disable-libmudflap --disable-libgomp --enable-checking=release --enable-nls --enable-threads=posix -with-gnu-as --with-gnu-ld --disable-libstdcxx-pch --enable-__cxa_atexit --build=i686-pc-linux-gnu --target=arm-none-linux-gnueabi --host=i686-pc-linux-gnu --enable-multilib --disable-libunwind-exceptions --with-arch=armv6 --with-tune=arm1176jzf-s --with-float=softfp --with-fpu=vfp --disable-sjlj-exceptions --enable-languages=c,c++ Thread model: posix gcc version 4.2.2 It seems to work (for me :-). I downloaded the existing 12.2 tree. I can't get it to build. Lots of scripts that know where you build ($HOME, etc). I have not built very much slackware from source and crossdev seems even trickier. Whining aside, I would be glad to be build armv6 if you can get the build scripts to work EABI-style. According to Stuart Winter: > > > The hassle with this (if I am correct) is that the EABI supports FPE and > > VFP -- but at compile time only. > > I was checking the Debian gcc build script for gcc > http://ftp.de.debian.org/debian/pool/main/g/gcc-4.3/gcc-4.3_4.3.3-13.diff.gz > zcat gcc-4.3_4.3.3-13.diff.gz|patch -p1 > less debian/rules2 > > And we'll find: > > ifneq (,$(findstring arm-vfp,$(DEB_TARGET_GNU_CPU))) > CONFARGS += --with-fpu=vfp > endif > > ifneq (,$(findstring arm-linux-gnueabi,$(DEB_TARGET_GNU_TYPE))) > CONFARGS += --disable-sjlj-exceptions > ifeq ($(distribution),Ubuntu) > CONFARGS += --with-arch=armv5t --with-tune=cortex-a8 > #CONFARGS += --with-float=softfp --with-fpu=vfp > #CONFARGS += --enable-multilib > endif > endif > > If you look at the actual build log: > https://buildd.debian.org/fetch.cgi?&pkg=gcc-4.3&ver=4.3.3-13&arch=armel&stamp=1246174992&file=log > > we can see that Debian armel isn't build using vfp. > Does this then mean that Debian's only armel port does not work on your > armv6 cpu? > > This is how I'm currently configuring gcc-4.3.3 for -current EABI: > > case $ARCH in > arm) export SLKCFLAGS="-O2 -march=armv4t" > # "--with-arch" sets the gcc defaults > export ARCH_CONFARGS="--disable-libssp --disable-sjlj-exceptions --enable-mpfr --with-arch=armv4t" > > TARGET=$ARCH-slackware-linux-gnueabi > > # build gcc > mkdir gcc.build.lnx > cd gcc.build.lnx > BOOT_CFLAGS="$SLKCFLAGS" \ > STAGE1_CFLAGS="$SLKCFLAGS" \ > CFLAGS="$SLKCFLAGS" \ > CXXFLAGS="$SLKCFLAGS" \ > LIBCFLAGS="$SLKCFLAGS" \ > LIBCXXFLAGS="$SLKCFLAGS" \ > GCJFLAGS="$SLKCFLAGS" \ > ../gcc-$VERSION/configure $ARCH_CONFARGS \ > --prefix=/usr \ > --libdir=/usr/lib$LIBDIRSUFFIX \ > --enable-bootstrap \ > --enable-checking=release \ > --with-system-zlib \ > --disable-libunwind-exceptions \ > --enable-shared \ > --enable-languages=c,c++,fortran,java,objc \ > --enable-threads=posix \ > --enable-__cxa_atexit \ > --with-gnu-ld \ > --verbose \ > --host=$TARGET \ > --build=$TARGET \ > --target=$TARGET || failconfig > > > armv5el > > armv5el-vfp > > armv6el-vfp > > > > That is a lot of work though... > > > > Are there any other vfp people on the list that will be "lost" if the armedslack is fpe only? > > I was reading this and starting to understand it a little: > http://wiki.debian.org/ArmEabiPort > > >From what I understand, this isn't a problem? It may be that the > distribution isn't optimised as a whole, but particular packages can be if > necessary? > > I certainly can do one port, but not maintain any more than 1 -- the old > ABI port stops (apart from security fixes) at Slackware 12.2. > > > -- > Stuart Winter > www.armedslack.org > David F. Carlson Chronolytics, Inc. Rochester, NY mailto:dave at chronolytics.com http://www.chronolytics.com "The faster I go, the behinder I get." --Lewis Carroll From m-lists at biscuit.org.uk Fri Jul 10 12:51:01 2009 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Fri, 10 Jul 2009 13:51:01 +0100 (BST) Subject: [armedslack] EABI In-Reply-To: <200907081145.n68Bj5H1014564@chronolytics.com> References: <200907081145.n68Bj5H1014564@chronolytics.com> Message-ID: > What a mess. I am not sure the thumb interworking is worth the hassle. > But the 5 or 6 different floating points all determined at compile time > -- oi what a mess. I've got a working set of packages and have booted into the new EABI OS and am now rebuilding natively what I have so far. Having already fixed some build failures, I can see that if I was to try and avoid suffixing the target name with "gnueabi" that I'd have a lot of patching to do since the presence of "eabi" in the target name is what many configure scripts use to determine whether to build for EABI. I'm very curious to know whether with the kernel for your arm device (btw what is it again? a dev board ?) would work with the new ARMedslack EABI packages. I can make what I have available soon for you to try. > I downloaded the existing 12.2 tree. I can't get it to build. Lots of > scripts that know where you build ($HOME, etc). I have not built very > much slackware from source and crossdev seems even trickier. Heh yeah the ARMedslack build system needs a little configuration although not a lot. If you want to use armedslack's build scripts, read this: ftp://ftp.armedslack.org/armedslack/armedslack-12.2/source/README_SOURCE.txt the Slackware source tree it refers to is simply an rsync of a Slackware mirror. eg rsync -Pavv ftp.slackware.org.uk::slackware/slackware-12.2 . Note however, that some of ARMedslack 12.2's packages are taken from slackware-current (to be 13.0) - so I maintain an updated slackware-12.2 tree locally. There aren't many of these packages though so it's not a big deal. What *is* a big deal is copying all of the sources and patches around whenever a package is updated in Slackware, so until ARMedslack's build scripts are merged into Slackware, it's a lot easier to build against a tree :-) > Whining aside, I would be glad to be build armv6 if you can get the > build scripts to work EABI-style. Once I've got a working base (probably 1-2 weeks from now), I'll upload what I've got. It'll only be a very minimal set of packages whilst I work my way through updating the AS-12.2 tree (I'll add in the new packages from Slackware 13.0 later). I don't maintain a changelog for the initial work since it takes a lot of package rebuilds to finish the bootstrap stage, but once that's done I can upload the -current in its raw form for you to look at if you're keen. From partha21 at gmail.com Sat Jul 11 10:32:17 2009 From: partha21 at gmail.com (Ajay Prabandham) Date: Sat, 11 Jul 2009 16:02:17 +0530 Subject: [armedslack] Am interested in knowing about current ARMedslack projects Message-ID: <95ff8f9c0907110332w6e481dfv54c2ab14b1273b23@mail.gmail.com> Hi All, Let me first introduce myself : I am Ajay Prabandham, and I am from Hyderabad, India. I have over 6 years of experience in the IT Industry (although mainly in application development). I have started taking active interest in linux kernel programming. I came across your website when i was searching the net for linux kernel projects. Can you please let me know if you are looking for kernel developers? My current knowledge (though quite small :-) ) is in file systems, TCP/IP and device drivers. I will await your reply... Thanks and Regards, Ajay -- Ajay Prakash Prabandham partha21 at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry.merle at free.fr Sat Jul 11 14:02:38 2009 From: thierry.merle at free.fr (Thierry MERLE) Date: Sat, 11 Jul 2009 16:02:38 +0200 Subject: [armedslack] Am interested in knowing about current ARMedslack projects In-Reply-To: <95ff8f9c0907110332w6e481dfv54c2ab14b1273b23@mail.gmail.com> References: <95ff8f9c0907110332w6e481dfv54c2ab14b1273b23@mail.gmail.com> Message-ID: <20090711160238.6c3060df@lugdush.houroukhai.org> Hi Ajay, On Sat, 11 Jul 2009 16:02:17 +0530 Ajay Prabandham wrote: > Hi All, > Let me first introduce myself : I am Ajay Prabandham, and I am > from Hyderabad, India. I have over 6 years of experience in the IT Industry > (although mainly in application development). I have started taking active > interest in linux kernel programming. I came across your website when i was > searching the net for linux kernel projects. > > Can you please let me know if you are looking for kernel developers? My > current knowledge (though quite small :-) ) is in file systems, TCP/IP and > device drivers. > Well, if you really want to contribute to the kernel drivers, and you are open to contribute to anything, you should join first to the linux driver project (www.linuxdriverproject.org), you will see that they need lots of developers. See particularly the DriversNeeded page where you will find drivers that need to be implemented. But to my mind the best way to start is to implement a driver for an unsupported device you have at home, look at kernel sources Documentation/ sub-directory to find out which part of the kernel is supposed to support this device, and join the specific mailing-list for your device (for example webcam, TV tuner=> video4linux); this is the best way to start in kernel development. You will contribute indirectly to the armedslack project since it is based on the linux kernel. Thanks for you willingness to contribute to this big project! Regards, Thierry From gmbertani at gmail.com Fri Jul 17 09:04:32 2009 From: gmbertani at gmail.com (giuseppe massimo bertani) Date: Fri, 17 Jul 2009 11:04:32 +0200 Subject: [armedslack] Nintendo DS Message-ID: <267153020907170204t6c154028s2f479417ca8226de@mail.gmail.com> Hello all, are there possibilities to run this distro on a Nintendo DS with Supercard and enough storage mass plugged into? -------------- next part -------------- An HTML attachment was scrubbed... URL: From m-lists at biscuit.org.uk Fri Jul 17 16:37:56 2009 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Fri, 17 Jul 2009 17:37:56 +0100 (BST) Subject: [armedslack] Nintendo DS In-Reply-To: <267153020907170204t6c154028s2f479417ca8226de@mail.gmail.com> References: <267153020907170204t6c154028s2f479417ca8226de@mail.gmail.com> Message-ID: Hi > are there possibilities to run this distro on a Nintendo DS with > Supercard and enough storage mass plugged into? I had a quick look at the standard Nintendo DS -- 4MB RAM; the Supercard adds 256MB. My initial feeling is that you'd need to put a lot of work into get Slackware running on this device; it'd be better to stick with "DSLinux" since it's aimed specifically at the DS. However, if you're experienced in bootstrapping Linux onto devices then by all means give it a go -- I'd love to see it running there and I can help a little bit; *but* in Linux 2.6.30.1: root at stokely:/usr/src/linux/arch/arm# grep -ri nintendo . root at stokely:/usr/src/linux/arch/arm# I don't see any mention of Nintendo in the kernel.org kernel which in my past experience with ARM, is a big "KEEP AWAY SPEND YOUR TIME ELSEWHERE" sign ;-) because I've been burnt before by not having upstream support for my ARM devices. I see that dslinux have patches against Linux 2.6.14 in their git tree though: http://dslinux.gits.kiev.ua/trunk/linux-2.6.x/arch/arm/Kconfig *but* I can warn you already that ARMedslack's glibc has a minimal Kernel version os 2.6.22, so you'd need to rebuild glibc. However, if you *did* decide to give it a go and got yourself a Kernel for the nintendo DS, I could build a glibc that required an earlier Kernel. But all that said, the NintendoDS has a very slow ARM cpu, so that alone would lose my interest ;-) -- Stuart Winter Slackware ARM: www.armedslack.org From novalazy at gmail.com Tue Jul 21 01:33:19 2009 From: novalazy at gmail.com (Peter Wang) Date: Tue, 21 Jul 2009 11:33:19 +1000 Subject: [armedslack] at package Message-ID: <20090721013319.GA1485@plug.localdomain> Hi, Just reporting that the `at' package has wrong ownership and permissions on various files so that normal users can't issue at jobs. I replicated the permissions from the Slackware 12.2 package and then it works fine. Thanks a lot for armedslack! Peter From m-lists at biscuit.org.uk Tue Jul 21 08:46:50 2009 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Tue, 21 Jul 2009 09:46:50 +0100 (BST) Subject: [armedslack] at package In-Reply-To: <20090721013319.GA1485@plug.localdomain> References: <20090721013319.GA1485@plug.localdomain> Message-ID: Hi Peter > Just reporting that the `at' package has wrong ownership and permissions > on various files so that normal users can't issue at jobs. I replicated > the permissions from the Slackware 12.2 package and then it works fine. Oh thanks! I'll put out an updated package today. > Thanks a lot for armedslack! No worries - thanks for the report! -- Stuart Winter Slackware ARM: www.armedslack.org