From psychicistnonconformist at gmail.com Tue Mar 27 19:03:01 2007 From: psychicistnonconformist at gmail.com (Sunil Amitkumar Janki) Date: Tue, 27 Mar 2007 21:03:01 +0200 Subject: [armedslack] Armedslack installer Message-ID: <46096A65.2030905@gmail.com> Hi Stuart and others, I have managed to install Armedslack in QEMU ARM via Debian and am running it now! It runs at about 100 MHz on my AMD Athlon 1.2 GHz so it's competitive with Intel Pentiums. I now have a reason to get rid of all of my older x86 hardware and replace it with QEMU running Armedslack. We should probably get the installer running on QEMU as well, though. What's more important is that I am building armv3 packages in QEMU now. So if you're interested in that please contact me for more information (and the packages!). Regards, Sunil Janki (a.k.a psychicist) From m-lists at biscuit.org.uk Tue Mar 27 20:56:51 2007 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Tue, 27 Mar 2007 21:56:51 +0100 (BST) Subject: [armedslack] Armedslack installer In-Reply-To: <46096A65.2030905@gmail.com> References: <46096A65.2030905@gmail.com> Message-ID: Hi Sunil > It runs at about 100 MHz on my AMD Athlon 1.2 GHz so > it's competitive with Intel Pentiums. Cool. I get about 500 bogomips on 3.4GHz Pentium D which is comparable to the 600MHz Xscale Iyonix hardware I have. > We should probably get the installer running on QEMU > as well, though. No need! It already does -- has for a long long time. That is how I install my QEMU images -- through the installer. Now, I do have to set the date using ntpdate (or whatever) and reboot into the installed system about 5 times after the initial installation (due to fsck time checks (due to lack of RTC support)) but other than that the installer works fine. > What's more important is that I am building armv3 packages > in QEMU now. So if you're interested in that please contact > me for more information (and the packages!). At the moment I have armedslack-current reasonably up to date with Slackware-current. I am currently working on building modular X, which is turning out to be a bit of a pain to get packaged, plus I haven't got X working yet either. By the way - you don't need to build for armv3 if you are only intending on using QEMU or some new ARM hardware -- I build for armv3 because of a problem with the StrongARM RiscPC. If you want to have a go at getting X working inside QEMU then that'd be cool. Would it help if I just uploaded armedslack-current as is? s. -- Stuart Winter www.armedslack.org From psychicistnonconformist at gmail.com Wed Mar 28 08:24:26 2007 From: psychicistnonconformist at gmail.com (Sunil Amitkumar Janki) Date: Wed, 28 Mar 2007 10:24:26 +0200 Subject: [armedslack] Armedslack installer In-Reply-To: References: <46096A65.2030905@gmail.com> Message-ID: <460A263A.5070601@gmail.com> Stuart Winter wrote: > At the moment I have armedslack-current reasonably up to date > with Slackware-current. I am currently working on building > modular X, which is turning out to be a bit of a pain to get packaged, > plus I haven't got X working yet either. > I have already synced slackware-current so everything is already in place from a source code perspective. I am glad they have already tackled the problem of building modular X on Slackware Current. > By the way - you don't need to build for armv3 if you are only intending > on using QEMU or some new ARM hardware -- I build for armv3 because of > a problem with the StrongARM RiscPC. > I could probably build packages with ARM926EJ-S optimisations for QEMU. But I also have a Dell Axim X3 PDA here that I would like to run Armedslack on. So for now I will build armv3 packages to establish a base platform that benefits as many people as possible. The reason that I recompiled Slackware 10.1 for AMD Athlon was to see what patches were needed to completely optimise Slackware for a specific processor model on some processor architecture. I will build optimised packages for the different targets afterwards. I see you have managed to get some older software to build again. I haven't even managed to get some of them optimised for AMD Athlon. The thing I would like to see is getting all of the different Slackware versions for different architectures into a single source tree. Then you would only have to put something like "export ARCH=armv3", "export ARCH=x86_64", "export ARCH=powerpc", "export ARCH=s390" or "export ARCH=sparc" in root's .bash_profile for each different architecture. > If you want to have a go at getting X working inside QEMU then that'd be > cool. Would it help if I just uploaded armedslack-current as is? It would certainly help if you uploaded armedslack-current as it is now. That would prevent me from duplicating all the work you have already done. As far as I have seen building packages for ARM or SPARC is not really different from building packages for i486 of x86_64. I only got errors on "fxload" and "gnuboy" because they can only be built with 2.4 kernel headers. By the way I have contacted Lemote (http://www.lemote.com) for a few Fu Long test systems. These run the Godson/Loongson 2E cpu. It is a MIPS EL cpu running at 660 MHz and 3 to 7 watts of power at the moment. 2F is expected to up the speed to 1 GHz and lower the power envelope by 50%. I intend to port Slackware to it, but that will probably take a few months. More information can be found here: http://en.wikipedia.org/wiki/Loongson. That will probably as near as I will ever get to a MIPS-based architecture because SGI hardware is still too unaffordable and too slow for me. It would also be great if affordable ARM Cortex based machines would become available for the market. That would be a great platform to run Armedslack on. When searching for ARM Cortex desktop I found this press release: http://www.arm.com/news/16539.html. It says ARM platforms are even more economical than other architectures (with the exception of Hitachi SH4). With the release of X86_64 processors and Playstation 3 I really get a feeling that x86 compatibility because of Windows is holding back the entire industry. Multiplatform Linux distributions like Debian, Slackware and Gentoo could change this. Kind regards, Sunil From m-lists at biscuit.org.uk Sat Mar 31 16:32:02 2007 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sat, 31 Mar 2007 17:32:02 +0100 (BST) Subject: [armedslack] Armedslack installer In-Reply-To: <460A263A.5070601@gmail.com> References: <46096A65.2030905@gmail.com> <460A263A.5070601@gmail.com> Message-ID: On Wed, 28 Mar 2007, Sunil Amitkumar Janki wrote: > I have already synced slackware-current so everything is already in place from > a source code perspective. I am glad they have already tackled the problem of > building modular X on Slackware Current. Yeah well, the build script doesn't build in the correct order - so you need to figure that out, then use the build script to make the packages. I think I have figured out a way to do it but I'm not entirely sure. I will find out soon enough. I have uploaded the latest armedslack-current -- but it's missing a lot of X packages. I'm going to do another rebuild to get those packages in, but X still doesn't work inside QEMU. We'll get there though :-) > The thing I would like to see is getting all of the different Slackware > versions for > different architectures into a single source tree. Then you would only have to > put > something like "export ARCH=armv3", "export ARCH=x86_64", "export > ARCH=powerpc", > "export ARCH=s390" or "export ARCH=sparc" in root's .bash_profile for each > different architecture. This was my original idea but you always need arch specific tweaks, and since there's usually only one or a few people working on the port, everyone does their own thing and simply takes from Slackware. I personally find that my way works best for me - I have the original Slackware script, and another script that diffs the latest and the original. I then merge anything needed into ARMedslack's scripts. I just wouldn't have time to work with anybody else to maintain a master source tree for all archs. You sound like you're really into the porting business so it's good to have someone else testing and working on this stuff :-) I am currently looking to get more mirrors for ARMedslack; ftp.armedslack.org is essentially useless now - I cannot even get a login to the shell because the server is so overloaded doing mirroring for other stuff. ftp.slackware.pl is the most reachable uptodate host that I know of: rsync -P ftp.slackware.pl::armedslack//armedslack-current/ I have more updates to push but I can't push them at the moment! I'll speak to the admin of that server and ask him to mirror from the real master (not ftp.as) so they can get up to date. Cheers s. -- Stuart Winter www.armedslack.org From psychicistnonconformist at gmail.com Sat Mar 31 19:48:48 2007 From: psychicistnonconformist at gmail.com (Sunil Amitkumar Janki) Date: Sat, 31 Mar 2007 21:48:48 +0200 Subject: [armedslack] Armedslack Current In-Reply-To: References: <46096A65.2030905@gmail.com> <460A263A.5070601@gmail.com> Message-ID: <460EBB20.5020604@gmail.com> Stuart Winter wrote: > Yeah well, the build script doesn't build in the correct order - so you > need to figure that out, then use the build script to make the > packages. I think I have figured out a way to do it but I'm not entirely > sure. I will find out soon enough. > > I am not really fond of huge build scripts. Not because they're not nice or useful. But when (not if but when) they produce errors, you have to fix them and restart the entire build script > This was my original idea but you always need arch specific tweaks, and > since there's usually only one or a few people working on the port, > everyone does their own thing and simply takes from Slackware. > There is nothing wrong with that but what I meant to do was rebuild for a processor model on the same architecture so building and optimising for a certain processor (on possibly another architecture) would be easier the next time. > I personally find that my way works best for me - I have the original > Slackware script, and another script that diffs the latest and the > original. I then merge anything needed into ARMedslack's scripts. > I just wouldn't have time to work with anybody else to maintain a > master source tree for all archs. > That's almost the same way I do it except I copy the original Slackware script and add in any changes that I made previously if they're still relevant. And to get most of the patches upstream so they would be included in Slackware proper and benefit all other architectures that way. That of course depends on Patrick's approval. But I already have made my first real contribution to Slackware through the gcc build script that he has integrated almost unmodified into slackware-current. The other one was my advice to him to rebuild oprofile with gcc 3.4.6 for system consistency, something you didn't/don't seem very happy about :-) My rationale was that I had some software, mostly QT/KDE, linked to both libstdc++.so.5 and libstdc++.so.6 which caused crashes and they were resolved when rebuilt with the newer compiler. This did not occur with the default i486 builds but it did in my AMD Athlon optimised ones. > You sound like you're really into the porting business so it's good > to have someone else testing and working on this stuff :-) > That's what I meant to say. Make it as modular and generic as possible so you only have to provide processor model/architecture specific patches. The first time will be hardest. Each time after that it will be a lot easier. See the attached fuse build scripts for an example. Adding another processor model just adds another patch to the build directory. I have also added a (very long !) list of ARM targets that packages could be made for. I have a few more, but they're for x86, ppc, sparc and mips. I have consulted Wikipedia for this but since you're much more knowledgable about ARM architecture than me you could probably point out some errors. > I have more updates to push but I can't push them at the moment! > I'll speak to the admin of that server and ask him to mirror > from the real master (not ftp.as) so they can get up to date. > That would be nice, especially if you already have some X11 fixes :-). I'm running Windowmaker in Armedslack 11.0 with xorg.conf-fbdev BTW and it's pretty responsive. Firefox and KDE are too heavy but this would also be the case on a Pentium, so the emulation is pretty accurate in comparison to real hardware. I'll just try to install my local version of Armedslack Current in a QEMU VM and see how far I can get. Using QEMU sure beats buying an ARM Versatile board for $5000,--, it's just as fast and immensely cheaper. Regards, Sunil -------------- next part -------------- A non-text attachment was scrubbed... Name: fuse.tar.bz2 Type: application/x-bzip Size: 4096 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: targets-arm.flags URL: From m-lists at biscuit.org.uk Sat Mar 31 20:50:56 2007 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sat, 31 Mar 2007 21:50:56 +0100 (BST) Subject: [armedslack] Armedslack Current In-Reply-To: <460EBB20.5020604@gmail.com> References: <46096A65.2030905@gmail.com> <460A263A.5070601@gmail.com> <460EBB20.5020604@gmail.com> Message-ID: > I am not really fond of huge build scripts. Not because they're not nice or > useful. > But when (not if but when) they produce errors, you have to fix them and > restart > the entire build script Yeah I know but I do prefer large scripts - I get a sense of accomplishment, scrolling down a few hundred lines of code :-) With the X11.SlackBuild in -current, you can specify individual components to rebuild so it's not so bad. I also have 5 machines here doing distcc cross compilation from the qemu ARM machine. It's pretty cool, although I still would prefer to be running on my real ARM box - the Iyonix.; but Castle don't seem to be interested in making a 2.6port :( > There is nothing wrong with that but what I meant to do was rebuild for a > processor > model on the same architecture so building and optimising for a certain > processor > (on possibly another architecture) would be easier the next time. Oh OK - I have had a look. How would you differentiate package names from the resulting build? Originally I used 'foo-1.0-armv3-1.tgz' because I thought I would make an xscale specific set of packages, but somebody told me that even Debian don't do that, so I probably wouldn't have time. They turned out to be right. Although with little ARM gadgets, you'd probably just produce a specific set aimed solely at that individual gadget? > That of course depends on Patrick's approval. But I already have made my first > real > contribution to Slackware through the gcc build script that he has integrated > almost > unmodified into slackware-current Ohj so it was *you* who missed a \ off the end of one of the cp's for some docs ;-) I have talked to Pat ages ago about making the scripts more portable, and he's talked recently about using shell macros (like armedslack's scripts) in his own build scripts. I think I'll just keep with how I do things though. > The other one was my advice to him to rebuild oprofile with gcc 3.4.6 for > system > consistency, something you didn't/don't seem very happy about :-) Did I even build it at all? :-) I think I had to build that on the RiscPC originally because it required Linux 2.6 and that was the only machine I had 2.6 running on. Well if you have any input, feel free to suggest it. I can add in your other architectures into my build scripts if it helps - although you say you use your own. > See the attached fuse build scripts for an example. Adding another processor > model just adds another patch to the build directory. I have also added a > (very > long !) list of ARM targets that packages could be made for. I have a few > more, > but they're for x86, ppc, sparc and mips. Hm. I try to keep clear of patching the source because it means much more of a time consuming job for me - usually I just overload CFLAGS or use sed to update a Makefile. This full time job and life thing makes me optimise one of my hobbies as much as possible :) > I have consulted Wikipedia for this but since you're much more knowledgable > about ARM architecture than me you could probably point out some errors. Heh. Actually I used to get really confused about the ARM target names when I first started, and to be honest I'm still not sure of all of them - there are so many. I remember when I was first deciding which -march value to use, and was browsing usenet and checking what the NetBSD folks had been talking about. And then I made a bunch of packages with some suggestions which turned out to *sort of* work on the RiscPC, but the binaries produced really weird results. Eventually after discussions with a fee people, settled on the ones I use now. I have never done any tests to see how much difference compiling for xscale rather than armv3 makes. ARM Linux is just slow anyway - I doubt you'd really notice ;-) > That would be nice, especially if you already have some X11 fixes :-). > I'm running Windowmaker in Armedslack 11.0 with xorg.conf-fbdev BTW > and it's pretty responsive. Yeah I used WindowMaker on my 257MHz RiscPC and it worked. I also loaded up firefox and was surprised that it was actually usable! (Well, mostly). I do not have any X11 fixes aside from what I took out of Debian's most recent xorg 7.2 patch set. Since Debian have now discarded RiscPC support, I'm a bit concerned that there will be no new patches. However, I did check through their old patches and found that all but 1 or two have made it upstream. The real armedslack master tree is here: rsync -P bourbon.biscuit.org.uk::armedslack That'll be a lot faster than ftp.armedslack.org ever was. > Firefox and KDE are too heavy but this would also be the case on a Pentium, > so the emulation is pretty accurate in comparison to real hardware. > > I'll just try to install my local version of Armedslack Current in a QEMU VM > and > see how far I can get. Using QEMU sure beats buying an ARM Versatile board > for $5000,--, it's just as fast and immensely cheaper. Yeah - and just buy a faster PC and it'll be actually faster than a real Versatile board anyway! :-) The only thing I have found is that building Perl inside QEMU fails, where as it works on my real ARM box. I don't know why that is, but it's no big deal. I cheated and built the perl in armedslack-current on my 11.0 machine ;-P I'll rebuild it later on -current on the RiscPC. s.