From m-lists at biscuit.org.uk Tue Feb 2 13:41:39 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Tue, 2 Feb 2010 13:41:39 +0000 (GMT) Subject: [ARMedslack] armedslack hang on emqbit In-Reply-To: <6efe08af1001310330j5721628bn8dcf37762da2bd45@mail.gmail.com> References: <6efe08af1001310330j5721628bn8dcf37762da2bd45@mail.gmail.com> Message-ID: > I try replace debian by armedslack on my free-ecb-at91 > > http://wiki.emqbit.com/free-ecb-at91 > > but system hang most likely on running /sbin/init How have you installed ARMedslack onto the device? From m-lists at biscuit.org.uk Tue Feb 2 13:44:31 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Tue, 2 Feb 2010 13:44:31 +0000 (GMT) Subject: [ARMedslack] How to crosscompile for armedslack? In-Reply-To: <6efe08af1001301305h5f9aa93eva5d31056e72bf54d@mail.gmail.com> References: <6efe08af1001301305h5f9aa93eva5d31056e72bf54d@mail.gmail.com> Message-ID: > I need recompile few packages for armedslack, such as qt. > > I can crosscompile fore bare metal, but for linux i'm confused. http://doc.trolltech.com/4.4/qt-embedded-crosscompiling.html All of ARMedslack is built natively, but uses distcc running on several X86 machines with an ARM cross compiler to speed up the process. I'd build it natively if you can. It's far easier, just slower. From vitaly.v.ch at gmail.com Tue Feb 2 17:25:25 2010 From: vitaly.v.ch at gmail.com (Vitaly V. Ch) Date: Tue, 2 Feb 2010 19:25:25 +0200 Subject: [ARMedslack] armedslack hang on emqbit In-Reply-To: References: <6efe08af1001310330j5721628bn8dcf37762da2bd45@mail.gmail.com> Message-ID: <6efe08af1002020925v4635ceb4i5829228a047347cb@mail.gmail.com> I write kernel via darrell-loader and create rootfs on my x86 slackware host. then I write root fs on sd card and try boot. system hung after kernel mount root fs. debian installed in same way work success but i'm interested in armedslack. \\wbr Vitaly Chernookiy On Tue, Feb 2, 2010 at 3:41 PM, Stuart Winter wrote: > > > I try replace debian by armedslack on my free-ecb-at91 > > > > http://wiki.emqbit.com/free-ecb-at91 > > > > but system hang most likely on running /sbin/init > > How have you installed ARMedslack onto the device? > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitaly.v.ch at gmail.com Tue Feb 2 17:31:13 2010 From: vitaly.v.ch at gmail.com (Vitaly V. Ch) Date: Tue, 2 Feb 2010 19:31:13 +0200 Subject: [ARMedslack] How to crosscompile for armedslack? In-Reply-To: References: <6efe08af1001301305h5f9aa93eva5d31056e72bf54d@mail.gmail.com> Message-ID: <6efe08af1002020931l77e61efm18d9734fdf3c1dbc@mail.gmail.com> On Tue, Feb 2, 2010 at 3:44 PM, Stuart Winter wrote: > > > I need recompile few packages for armedslack, such as qt. > > > > I can crosscompile fore bare metal, but for linux i'm confused. > > http://doc.trolltech.com/4.4/qt-embedded-crosscompiling.html Thanks, it's interesting. > > All of ARMedslack is built natively, but uses distcc running on several > X86 machines with an ARM cross compiler to speed up the process. > > I'd build it natively if you can. It's far easier, just slower. > Hm. I will think > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitaly.v.ch at gmail.com Tue Feb 2 20:36:42 2010 From: vitaly.v.ch at gmail.com (Vitaly V. Ch) Date: Tue, 2 Feb 2010 22:36:42 +0200 Subject: [ARMedslack] armedslack hang on emqbit In-Reply-To: <6efe08af1002020925v4635ceb4i5829228a047347cb@mail.gmail.com> References: <6efe08af1001310330j5721628bn8dcf37762da2bd45@mail.gmail.com> <6efe08af1002020925v4635ceb4i5829228a047347cb@mail.gmail.com> Message-ID: <6efe08af1002021236h7336b880i31d94dab0e405173@mail.gmail.com> rootfs is created in way like tinstall.sh. also i'm notice then rootfs armedslack-devtools/armel/rootfs/armel-root-fs.tar.bz2 is also unbootable, but Must. I can boot only debian On Tue, Feb 2, 2010 at 7:25 PM, Vitaly V. Ch wrote: > I write kernel via darrell-loader and create rootfs on my x86 slackware > host. then I write root fs on sd card and try boot. system hung after kernel > mount root fs. debian installed in same way work success but i'm interested > in armedslack. > > > \\wbr Vitaly Chernookiy > > > On Tue, Feb 2, 2010 at 3:41 PM, Stuart Winter wrote: > >> >> > I try replace debian by armedslack on my free-ecb-at91 >> > >> > http://wiki.emqbit.com/free-ecb-at91 >> > >> > but system hang most likely on running /sbin/init >> >> How have you installed ARMedslack onto the device? >> _______________________________________________ >> ARMedslack mailing list >> ARMedslack at lists.armedslack.org >> http://lists.armedslack.org/mailman/listinfo/armedslack >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m-lists at biscuit.org.uk Wed Feb 3 11:38:33 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Wed, 3 Feb 2010 11:38:33 +0000 (GMT) Subject: [ARMedslack] armedslack hang on emqbit In-Reply-To: <6efe08af1002020925v4635ceb4i5829228a047347cb@mail.gmail.com> References: <6efe08af1001310330j5721628bn8dcf37762da2bd45@mail.gmail.com> <6efe08af1002020925v4635ceb4i5829228a047347cb@mail.gmail.com> Message-ID: OK. Have you tried booting back into Debian, NFS mounting your x86 chroot into the Slackware root fs? does the rootfs work ? Since you've made the rootfs on x86 Slackware, how did you do this? did you use installpkg? On Tue, 2 Feb 2010, Vitaly V. Ch wrote: > I write kernel via darrell-loader and create rootfs on my x86 slackware > host. then I write root fs on sd card and try boot. system hung after kernel > mount root fs. debian installed in same way work success but i'm interested > in armedslack. > > > \\wbr Vitaly Chernookiy > > On Tue, Feb 2, 2010 at 3:41 PM, Stuart Winter wrote: > > > > > > I try replace debian by armedslack on my free-ecb-at91 > > > > > > http://wiki.emqbit.com/free-ecb-at91 > > > > > > but system hang most likely on running /sbin/init > > > > How have you installed ARMedslack onto the device? > > _______________________________________________ > > ARMedslack mailing list > > ARMedslack at lists.armedslack.org > > http://lists.armedslack.org/mailman/listinfo/armedslack > > > -- Stuart Winter Slackware ARM: www.armedslack.org From m-lists at biscuit.org.uk Wed Feb 3 11:40:33 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Wed, 3 Feb 2010 11:40:33 +0000 (GMT) Subject: [ARMedslack] armedslack hang on emqbit In-Reply-To: <6efe08af1002021236h7336b880i31d94dab0e405173@mail.gmail.com> References: <6efe08af1001310330j5721628bn8dcf37762da2bd45@mail.gmail.com> <6efe08af1002020925v4635ceb4i5829228a047347cb@mail.gmail.com> <6efe08af1002021236h7336b880i31d94dab0e405173@mail.gmail.com> Message-ID: On Tue, 2 Feb 2010, Vitaly V. Ch wrote: > rootfs is created in way like tinstall.sh. also i'm notice then rootfs > armedslack-devtools/armel/rootfs/armel-root-fs.tar.bz2 is also unbootable, Oh this is ancient stuff - it's not Slackware - just a collection of stuff I was using when creating the eabi port. I don't have a rootfs for ARMedslack available yet; but if there's demand then I could write a script to create one! -- Stuart Winter Slackware ARM: www.armedslack.org From vitaly.v.ch at gmail.com Wed Feb 3 21:28:31 2010 From: vitaly.v.ch at gmail.com (Vitaly V. Ch) Date: Wed, 3 Feb 2010 23:28:31 +0200 Subject: [ARMedslack] armedslack hang on emqbit In-Reply-To: References: <6efe08af1001310330j5721628bn8dcf37762da2bd45@mail.gmail.com> <6efe08af1002020925v4635ceb4i5829228a047347cb@mail.gmail.com> <6efe08af1002021236h7336b880i31d94dab0e405173@mail.gmail.com> Message-ID: <6efe08af1002031328h4e2ac44ey3a46743643783031@mail.gmail.com> On Wed, Feb 3, 2010 at 1:40 PM, Stuart Winter wrote: > > On Tue, 2 Feb 2010, Vitaly V. Ch wrote: > > > rootfs is created in way like tinstall.sh. also i'm notice then rootfs > > armedslack-devtools/armel/rootfs/armel-root-fs.tar.bz2 is also > unbootable, > > Oh this is ancient stuff - it's not Slackware - just a collection of > stuff I was using when creating the eabi port. > I found this stuff pretty :) > > I don't have a rootfs for ARMedslack available yet; but if there's demand > then I could write a script to create one! > I'm wrong. I can successfully boot only when I use debian 4.0 root fs from Your repositoriy at armedslack-devtools/armel/rootfs/armel-root-fs.tar.bz2. Any other rootfs fail to boot. \\wbr Vitaly Chernookiy > > -- > Stuart Winter > Slackware ARM: www.armedslack.org > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitaly.v.ch at gmail.com Thu Feb 4 08:12:53 2010 From: vitaly.v.ch at gmail.com (Vitaly V. Ch) Date: Thu, 4 Feb 2010 10:12:53 +0200 Subject: [ARMedslack] armedslack hang on emqbit In-Reply-To: <6efe08af1002031328h4e2ac44ey3a46743643783031@mail.gmail.com> References: <6efe08af1001310330j5721628bn8dcf37762da2bd45@mail.gmail.com> <6efe08af1002020925v4635ceb4i5829228a047347cb@mail.gmail.com> <6efe08af1002021236h7336b880i31d94dab0e405173@mail.gmail.com> <6efe08af1002031328h4e2ac44ey3a46743643783031@mail.gmail.com> Message-ID: <6efe08af1002040012r5fa067ddi42ca45e1b76aa0ad@mail.gmail.com> At now I'm find root of troubles: incompatibility my patched kernels and glibc from armedslack. PS: I'm last maintainer of BCSLinux and maintainer of iZumLinux. Both Slackware based. \\wbr Vitaly Chernookiy On Wed, Feb 3, 2010 at 11:28 PM, Vitaly V. Ch wrote: > > > On Wed, Feb 3, 2010 at 1:40 PM, Stuart Winter wrote: > >> >> On Tue, 2 Feb 2010, Vitaly V. Ch wrote: >> >> > rootfs is created in way like tinstall.sh. also i'm notice then rootfs >> > armedslack-devtools/armel/rootfs/armel-root-fs.tar.bz2 is also >> unbootable, >> >> Oh this is ancient stuff - it's not Slackware - just a collection of >> stuff I was using when creating the eabi port. >> > > I found this stuff pretty :) > >> >> I don't have a rootfs for ARMedslack available yet; but if there's demand >> then I could write a script to create one! >> > > I'm wrong. I can successfully boot only when I use debian 4.0 root fs from > Your repositoriy at armedslack-devtools/armel/rootfs/armel-root-fs.tar.bz2. > > Any other rootfs fail to boot. > > \\wbr Vitaly Chernookiy > >> >> -- >> >> Stuart Winter >> Slackware ARM: www.armedslack.org >> _______________________________________________ >> ARMedslack mailing list >> ARMedslack at lists.armedslack.org >> http://lists.armedslack.org/mailman/listinfo/armedslack >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m-lists at biscuit.org.uk Thu Feb 4 08:29:48 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Thu, 4 Feb 2010 08:29:48 +0000 (GMT) Subject: [ARMedslack] armedslack hang on emqbit In-Reply-To: <6efe08af1002040012r5fa067ddi42ca45e1b76aa0ad@mail.gmail.com> References: <6efe08af1001310330j5721628bn8dcf37762da2bd45@mail.gmail.com> <6efe08af1002020925v4635ceb4i5829228a047347cb@mail.gmail.com> <6efe08af1002021236h7336b880i31d94dab0e405173@mail.gmail.com> <6efe08af1002031328h4e2ac44ey3a46743643783031@mail.gmail.com> <6efe08af1002040012r5fa067ddi42ca45e1b76aa0ad@mail.gmail.com> Message-ID: > At now I'm find root of troubles: incompatibility my patched kernels and > glibc from armedslack. You are not using armedslack 12.2 are you ? This would explain why there's an incompatability: 12.2 is old ABI so if your Kernel is EABI without the Old ABI support, it won't work. > PS: I'm last maintainer of BCSLinux and maintainer of iZumLinux. Both > Slackware based. Welcome to the show! :) From vitaly.v.ch at gmail.com Thu Feb 4 08:50:12 2010 From: vitaly.v.ch at gmail.com (Vitaly V. Ch) Date: Thu, 4 Feb 2010 10:50:12 +0200 Subject: [ARMedslack] armedslack hang on emqbit In-Reply-To: References: <6efe08af1001310330j5721628bn8dcf37762da2bd45@mail.gmail.com> <6efe08af1002020925v4635ceb4i5829228a047347cb@mail.gmail.com> <6efe08af1002021236h7336b880i31d94dab0e405173@mail.gmail.com> <6efe08af1002031328h4e2ac44ey3a46743643783031@mail.gmail.com> <6efe08af1002040012r5fa067ddi42ca45e1b76aa0ad@mail.gmail.com> Message-ID: <6efe08af1002040050s9534639s7289b06c89c3c86f@mail.gmail.com> On Thu, Feb 4, 2010 at 10:29 AM, Stuart Winter wrote: > > > > At now I'm find root of troubles: incompatibility my patched kernels and > > glibc from armedslack. > > You are not using armedslack 12.2 are you ? > I'm use armedslack-current. > This would explain why there's an incompatability: 12.2 is old ABI so if > your Kernel is EABI without the Old ABI support, it won't work. > My at91 board initially have patches only for 2.6.21 kernels. But glibc from slackware-current does not support this low version of kernel. Yesterday I written patch for 2.6.27 kernels. And today I will try to run this version of kernel. \\wbr Vitaly Chernookiy > > > PS: I'm last maintainer of BCSLinux and maintainer of iZumLinux. Both > > Slackware based. > > Welcome to the show! :) > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m-lists at biscuit.org.uk Thu Feb 4 10:56:33 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Thu, 4 Feb 2010 10:56:33 +0000 (GMT) Subject: [ARMedslack] armedslack hang on emqbit In-Reply-To: <6efe08af1002040050s9534639s7289b06c89c3c86f@mail.gmail.com> References: <6efe08af1001310330j5721628bn8dcf37762da2bd45@mail.gmail.com> <6efe08af1002020925v4635ceb4i5829228a047347cb@mail.gmail.com> <6efe08af1002021236h7336b880i31d94dab0e405173@mail.gmail.com> <6efe08af1002031328h4e2ac44ey3a46743643783031@mail.gmail.com> <6efe08af1002040012r5fa067ddi42ca45e1b76aa0ad@mail.gmail.com> <6efe08af1002040050s9534639s7289b06c89c3c86f@mail.gmail.com> Message-ID: > > You are not using armedslack 12.2 are you ? > > > I'm use armedslack-current. Ok Good :-) > My at91 board initially have patches only for 2.6.21 kernels. But glibc from > slackware-current does not support this low version of kernel. Yesterday I > written patch for 2.6.27 kernels. And today I will try to run this version > of kernel. Ah! Yes because Slackware ARM EABI is a new port, and the SheevaPlug support appeared in Linux 2.6.30 and by the time I got around to making a release, Linux 2.6.31 was out, glibc in -current is built against "--enable-kernel=2.6.31 " Once you've built a newer kernel you should be able to boot into your installation. You've got me thinking of a mini rootfs now though! I think it'd be pretty useful to have in order to bootstrap onto newer devices: currently I do it manually. From m-lists at biscuit.org.uk Fri Feb 5 23:02:44 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Fri, 5 Feb 2010 23:02:44 +0000 (GMT) Subject: [ARMedslack] Slackware-current ARM mini root fs Message-ID: Hi! I couldn't stop myself! I've made a mini root fs of Slackware-current ARM: ftp://ftp.armedslack.org/armedslack/armedslack-devtools/minirootfs/ Enjoy! s. -- Stuart Winter Slackware ARM: www.armedslack.org From gwenhael.le.moine at gmail.com Sat Feb 6 09:00:28 2010 From: gwenhael.le.moine at gmail.com (Gwenhael Le Moine) Date: Sat, 6 Feb 2010 16:00:28 +0700 Subject: [ARMedslack] Slackware-current ARM mini root fs In-Reply-To: References: Message-ID: <314c6c8f1002060100k9fe86c0y712e5806374b6ce9@mail.gmail.com> 2010/2/6 Stuart Winter : > > Hi! > > I couldn't stop myself! > I've made a mini root fs of Slackware-current ARM: > > ftp://ftp.armedslack.org/armedslack/armedslack-devtools/minirootfs/ > > Enjoy! > s. Well this is just fantastic!! This, renewed motivation, some free time and the openembedded toolchain I had available made Armedslack on my zaurus (SL6000L) a reality \o/ Thanks Gwh From m-lists at biscuit.org.uk Sat Feb 6 12:54:18 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sat, 6 Feb 2010 12:54:18 +0000 (GMT) Subject: [ARMedslack] Slackware-current ARM mini root fs In-Reply-To: <314c6c8f1002060100k9fe86c0y712e5806374b6ce9@mail.gmail.com> References: <314c6c8f1002060100k9fe86c0y712e5806374b6ce9@mail.gmail.com> Message-ID: > This, renewed motivation, some free time and the openembedded > toolchain I had available made Armedslack on my zaurus (SL6000L) a Cool. Glad it's going to be of use :) I've uploaded a new mini root today which has added traceroute and a couple of other things, like the ability to change console keymaps. The new mini root fs file name is dated today. From gwenhael.le.moine at gmail.com Sat Feb 6 17:03:31 2010 From: gwenhael.le.moine at gmail.com (Gwenhael Le Moine) Date: Sun, 7 Feb 2010 00:03:31 +0700 Subject: [ARMedslack] Slackware-current ARM mini root fs In-Reply-To: References: <314c6c8f1002060100k9fe86c0y712e5806374b6ce9@mail.gmail.com> Message-ID: <314c6c8f1002060903x2c0508a0y2ef0f23aeff5444c@mail.gmail.com> 2010/2/6 Stuart Winter : > >> This, renewed motivation, some free time and the openembedded >> toolchain I had available made Armedslack on my zaurus (SL6000L) a > > Cool. ?Glad it's going to be of use :) > > I've uploaded a new mini root today which has added traceroute and a > couple of other things, like the ability to change console keymaps. > The new mini root fs file name is dated today. It greatly simplify the installation which is now just a 'tar xf' away:) I'm documenting what I'm doing, along with zaurus specific .SlackBuilds @ http://github.com/cycojesus/ArmedZed Now that it boots I'm configuring (keymap, ...) and installing more packages. The "first goal" (after configuration) is to install X and FBReader and make it usable as am ebook reader. Thanks again Gwh From niels.horn at gmail.com Sat Feb 6 17:12:13 2010 From: niels.horn at gmail.com (Niels Horn) Date: Sat, 6 Feb 2010 15:12:13 -0200 Subject: [ARMedslack] Slackware-current ARM mini root fs In-Reply-To: <314c6c8f1002060903x2c0508a0y2ef0f23aeff5444c@mail.gmail.com> References: <314c6c8f1002060100k9fe86c0y712e5806374b6ce9@mail.gmail.com> <314c6c8f1002060903x2c0508a0y2ef0f23aeff5444c@mail.gmail.com> Message-ID: <3f18b2311002060912p24b0f653m22136d37238f1fa3@mail.gmail.com> On Sat, Feb 6, 2010 at 3:03 PM, Gwenhael Le Moine wrote: > Now that it boots I'm configuring (keymap, ...) and installing more > packages. The "first goal" (after configuration) is to install X and > FBReader and make it usable as am ebook reader. There is an updated SlackBuild script for FBReader in the "approved" queue of SlackBuilds.org, waiting for the next batch of updates. If you can use that script to build FBReader, it would be nice, so that I can mark it as "arm-compatible" :) If you need help with it, contact me off-list. Niels From m-lists at biscuit.org.uk Sun Feb 7 10:18:14 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sun, 7 Feb 2010 10:18:14 +0000 (GMT) Subject: [ARMedslack] Slackware-current ARM mini root fs In-Reply-To: <3f18b2311002060912p24b0f653m22136d37238f1fa3@mail.gmail.com> References: <314c6c8f1002060100k9fe86c0y712e5806374b6ce9@mail.gmail.com> <314c6c8f1002060903x2c0508a0y2ef0f23aeff5444c@mail.gmail.com> <3f18b2311002060912p24b0f653m22136d37238f1fa3@mail.gmail.com> Message-ID: > There is an updated SlackBuild script for FBReader in the "approved" > queue of SlackBuilds.org, waiting for the next batch of updates. > If you can use that script to build FBReader, it would be nice, so > that I can mark it as "arm-compatible" :) I thought that slackbuilds.org wasn't catering for anything other than x86_64 or x86 (primarily because Robby et al don't have any way to verify the script on other platforms). It'd be good if packages can be marked ARM compatible though. I occasionally use scripts from there myself so it's no big deal to build it on ARM to test. From niels.horn at gmail.com Sun Feb 7 11:10:32 2010 From: niels.horn at gmail.com (Niels Horn) Date: Sun, 7 Feb 2010 09:10:32 -0200 Subject: [ARMedslack] Slackware-current ARM mini root fs In-Reply-To: References: <314c6c8f1002060100k9fe86c0y712e5806374b6ce9@mail.gmail.com> <314c6c8f1002060903x2c0508a0y2ef0f23aeff5444c@mail.gmail.com> <3f18b2311002060912p24b0f653m22136d37238f1fa3@mail.gmail.com> Message-ID: <3f18b2311002070310o48cbe1f2n7929dd8c11108db1@mail.gmail.com> On Sun, Feb 7, 2010 at 8:18 AM, Stuart Winter wrote: > >> There is an updated SlackBuild script for FBReader in the "approved" >> queue of SlackBuilds.org, waiting for the next batch of updates. >> If you can use that script to build FBReader, it would be nice, so >> that I can mark it as "arm-compatible" :) > > I thought that slackbuilds.org wasn't catering for anything other than > x86_64 or x86 (primarily because Robby et al don't have any way to > verify the script on other platforms). ?It'd be good if packages can be > marked ARM compatible though. ?I occasionally use scripts from there > myself so it's no big deal to build it on ARM to test. For now, SlackBuilds are only required to run on x86_64 or x86. But I have asked the admins about it in the past and they responded that if the maintainer tested the script on ARM (or s390), he/she can include it in the script as one of the architectures. And some people from SBo are buying SheevaPlugs, including me :) Niels From m-lists at biscuit.org.uk Sun Feb 7 11:49:45 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sun, 7 Feb 2010 11:49:45 +0000 (GMT) Subject: [ARMedslack] Slackware-current ARM mini root fs In-Reply-To: <3f18b2311002070310o48cbe1f2n7929dd8c11108db1@mail.gmail.com> References: <314c6c8f1002060100k9fe86c0y712e5806374b6ce9@mail.gmail.com> <314c6c8f1002060903x2c0508a0y2ef0f23aeff5444c@mail.gmail.com> <3f18b2311002060912p24b0f653m22136d37238f1fa3@mail.gmail.com> <3f18b2311002070310o48cbe1f2n7929dd8c11108db1@mail.gmail.com> Message-ID: > have asked the admins about it in the past and they responded that if > the maintainer tested the script on ARM (or s390), he/she can include > it in the script as one of the architectures. This would be great. I'm really curious about people will use ARMedslack for. For me, ARM has always been for Desktop machines (since ARM CPUs were manufactured for the Acorn archimedes range), so I consider ARMedslack aimed at desktops and server usage on those machines rather than hand held gadgets. > And some people from SBo are buying SheevaPlugs, including me :) Yes Robby's ordered his already - it should arrive pretty soon (although Globalscale take weeks to get the SPs delivered). From iyonix at woosh.co.nz Sun Feb 7 12:49:45 2010 From: iyonix at woosh.co.nz (Ron) Date: Mon, 08 Feb 2010 01:49:45 +1300 Subject: [ARMedslack] Slackware-current ARM mini root fs In-Reply-To: References: <314c6c8f1002060100k9fe86c0y712e5806374b6ce9@mail.gmail.com> <314c6c8f1002060903x2c0508a0y2ef0f23aeff5444c@mail.gmail.com> <3f18b2311002060912p24b0f653m22136d37238f1fa3@mail.gmail.com> <3f18b2311002070310o48cbe1f2n7929dd8c11108db1@mail.gmail.com> Message-ID: <27ddd8e550.Iyonix@ron1954.woosh.co.nz> In message Stuart Winter wrote: > > > have asked the admins about it in the past and they responded that if > > the maintainer tested the script on ARM (or s390), he/she can include > > it in the script as one of the architectures. > > This would be great. > > I'm really curious about people will use ARMedslack for. For me, ARM has > always been for Desktop machines (since ARM CPUs were manufactured for the > Acorn archimedes range), so I consider ARMedslack aimed at desktops and > server usage on those machines rather than hand held gadgets. Hi there, I am an Iyonix user, and I'm intending on using Linux on a SOC board via Ethernet. I was considering Sheevaplug, but there is future port of RISC OS on OMAP beagleboard going on, so I am looking at the IGEP (clone with ethernet) now. It could have dual purpose which is a safe place to be when buying a product. Being able to use Slackware as well as Ubuntu would be a bonus, maybe it'd run a bit slicker. Cheers, Ron From linuxxr at yahoo.com Sun Feb 7 16:17:19 2010 From: linuxxr at yahoo.com (Brian Kelley) Date: Sun, 7 Feb 2010 08:17:19 -0800 (PST) Subject: [ARMedslack] Slackware-current ARM mini root fs In-Reply-To: <27ddd8e550.Iyonix@ron1954.woosh.co.nz> Message-ID: <682706.11043.qm@web52401.mail.re2.yahoo.com> the openmoko freerunner is another good choice --- On Sun, 2/7/10, Ron wrote: From: Ron Subject: Re: [ARMedslack] Slackware-current ARM mini root fs To: armedslack at lists.polplex.co.uk Date: Sunday, February 7, 2010, 6:49 AM In message ? ? ? ? ? Stuart Winter wrote: > > > have asked the admins about it in the past and they responded that if > > the maintainer tested the script on ARM (or s390), he/she can include > > it in the script as one of the architectures. > > This would be great. > > I'm really curious about people will use ARMedslack for.? For me, ARM has > always been for Desktop machines (since ARM CPUs were manufactured for the > Acorn archimedes range), so I consider ARMedslack aimed at desktops and > server usage on those machines rather than hand held gadgets. Hi there, I am an Iyonix user, and I'm intending on using Linux on a SOC board via Ethernet. I was considering Sheevaplug, but there is future port of RISC OS on OMAP beagleboard going on, so I am looking at the IGEP (clone with ethernet) now. It could have dual purpose which is a safe place to be when buying a product. Being able to use Slackware as well as Ubuntu would be a bonus, maybe it'd run a bit slicker. Cheers, Ron _______________________________________________ ARMedslack mailing list ARMedslack at lists.armedslack.org http://lists.armedslack.org/mailman/listinfo/armedslack -------------- next part -------------- An HTML attachment was scrubbed... URL: From m-lists at biscuit.org.uk Sun Feb 7 19:47:11 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sun, 7 Feb 2010 19:47:11 +0000 (GMT) Subject: [ARMedslack] Slackware-current ARM mini root fs In-Reply-To: <27ddd8e550.Iyonix@ron1954.woosh.co.nz> References: <314c6c8f1002060100k9fe86c0y712e5806374b6ce9@mail.gmail.com> <314c6c8f1002060903x2c0508a0y2ef0f23aeff5444c@mail.gmail.com> <3f18b2311002060912p24b0f653m22136d37238f1fa3@mail.gmail.com> <3f18b2311002070310o48cbe1f2n7929dd8c11108db1@mail.gmail.com> <27ddd8e550.Iyonix@ron1954.woosh.co.nz> Message-ID: Hi Ron > I am an Iyonix user, and I'm intending on using Linux on a SOC board I have an Iyonix sitting idle in my front room -- did you ever get Linux running on it? I used the Iyonix for about a year to build ARMedslack but the support was never upstreamed :( But I was wondering whether anybody had been working on it -- you don't know do you? is the Iyonix worth while keeping or ebaying (assuming it'll reach any sensible price) > of RISC OS on OMAP beagleboard going on, so I am looking at the > IGEP (clone with ethernet) now. It could have dual purpose which is > a safe place to be when buying a product. Good to see that RISC OS keeps going! There's still life left in the old dog yet ;) From m-lists at biscuit.org.uk Sun Feb 7 20:03:01 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sun, 7 Feb 2010 20:03:01 +0000 (GMT) Subject: [ARMedslack] Slackware-current ARM mini root fs In-Reply-To: <682706.11043.qm@web52401.mail.re2.yahoo.com> References: <682706.11043.qm@web52401.mail.re2.yahoo.com> Message-ID: On Sun, 7 Feb 2010, Brian Kelley wrote: > the openmoko freerunner is another good choice http://www.globalscaletechnologies.com/c-4-guruplugs.aspx Have you seen these? From iyonix at woosh.co.nz Sun Feb 7 22:49:10 2010 From: iyonix at woosh.co.nz (Ron) Date: Mon, 08 Feb 2010 11:49:10 +1300 Subject: [ARMedslack] Slackware-current ARM mini root fs In-Reply-To: References: <314c6c8f1002060100k9fe86c0y712e5806374b6ce9@mail.gmail.com> <314c6c8f1002060903x2c0508a0y2ef0f23aeff5444c@mail.gmail.com> <3f18b2311002060912p24b0f653m22136d37238f1fa3@mail.gmail.com> <3f18b2311002070310o48cbe1f2n7929dd8c11108db1@mail.gmail.com> <27ddd8e550.Iyonix@ron1954.woosh.co.nz> Message-ID: <36be0fe650.Iyonix@ron1954.woosh.co.nz> In message Stuart Winter wrote: > > Hi Ron > > > I am an Iyonix user, and I'm intending on using Linux on a SOC board > > I have an Iyonix sitting idle in my front room -- did you ever get Linux > running on it? I used the Iyonix for about a year to build ARMedslack but > the support was never upstreamed :( > But I was wondering whether anybody had been working on it -- you don't > know do you? is the Iyonix worth while keeping or ebaying (assuming it'll > reach any sensible price) I used the original Debian release, it got old pretty fast. It had a 2.4 kernel and the graphics card support was no good for the newer FX5200 that we mostly upgraded to. We have had many benchmark releases lately. GCC 4.1.1 r2, Fat32fs, USB speedups and regular ROM upgrades. http://www.riscos.info/index.php/RISC_OS is not a bad place to start. You will need to reflash your Iyonix to 5.16 to fix the 2010 clock problem. Not sure what version you are at, there'll be other new drivers, modules etc to install. I think some people are looking at compiling from the Linux RISC OS emulator as well, But I think the bigger builds like Netsurf are set up for crosscompiling for the speed. > > Good to see that RISC OS keeps going! There's still life left in the old > dog yet ;) The Iyonix is no longer manufactured due to some key components not being leadfree. But with the move to ROOL, there are many things happening. Cheers, Ron From gwenhael.le.moine at gmail.com Mon Feb 8 00:53:31 2010 From: gwenhael.le.moine at gmail.com (Gwenhael Le Moine) Date: Mon, 8 Feb 2010 07:53:31 +0700 Subject: [ARMedslack] Slackware-current ARM mini root fs In-Reply-To: <3f18b2311002060912p24b0f653m22136d37238f1fa3@mail.gmail.com> References: <314c6c8f1002060100k9fe86c0y712e5806374b6ce9@mail.gmail.com> <314c6c8f1002060903x2c0508a0y2ef0f23aeff5444c@mail.gmail.com> <3f18b2311002060912p24b0f653m22136d37238f1fa3@mail.gmail.com> Message-ID: <314c6c8f1002071653u6f27bf6h710dca07f48150c9@mail.gmail.com> > There is an updated SlackBuild script for FBReader in the "approved" > queue of SlackBuilds.org, waiting for the next batch of updates. > If you can use that script to build FBReader, it would be nice, so > that I can mark it as "arm-compatible" :) > If you need help with it, contact me off-list. Hi, Both liblinebreak and FBReader built fine. I built liblinebreak 2.0 and FBReader 0.12.2 (both by just updating the $VERSION in the SlackBuild, I did that when I built on the x86_64 laptop and just copy to the zaurus to build on arm) liblinebreak was built with ARCH=$(uname -m) and FBReader ARCH=$(uname -m) UI=gtk I haven't tried to run it yet, I want to fix the touchscreen before so I can test and use X and FBReader. I ended up installing most packages except k kde t tcl, especially makepkg needs which ;) I'll go back to try and make the touchscreen functional now... Gwh From m-lists at biscuit.org.uk Mon Feb 8 09:01:03 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Mon, 8 Feb 2010 09:01:03 +0000 (GMT) Subject: [ARMedslack] Slackware-current ARM mini root fs In-Reply-To: <314c6c8f1002071653u6f27bf6h710dca07f48150c9@mail.gmail.com> References: <314c6c8f1002060100k9fe86c0y712e5806374b6ce9@mail.gmail.com> <314c6c8f1002060903x2c0508a0y2ef0f23aeff5444c@mail.gmail.com> <3f18b2311002060912p24b0f653m22136d37238f1fa3@mail.gmail.com> <314c6c8f1002071653u6f27bf6h710dca07f48150c9@mail.gmail.com> Message-ID: > I ended up installing most packages except k kde t tcl, especially > makepkg needs which ;) thanks - I've added which into the package list, so it'll be in the next update which will probably be next week. From gwenhael.le.moine at gmail.com Mon Feb 8 09:22:08 2010 From: gwenhael.le.moine at gmail.com (Gwenhael Le Moine) Date: Mon, 8 Feb 2010 16:22:08 +0700 Subject: [ARMedslack] Slackware-current ARM mini root fs In-Reply-To: References: <314c6c8f1002060100k9fe86c0y712e5806374b6ce9@mail.gmail.com> <314c6c8f1002060903x2c0508a0y2ef0f23aeff5444c@mail.gmail.com> <3f18b2311002060912p24b0f653m22136d37238f1fa3@mail.gmail.com> <314c6c8f1002071653u6f27bf6h710dca07f48150c9@mail.gmail.com> Message-ID: <314c6c8f1002080122j1914b15dr443b878ec10b97b6@mail.gmail.com> > thanks - I've added which into the package list, so it'll be in the next > update which will probably be next week. not a hard dependency for makepkg but I had to install findutils as well as most if not all .SlackBuild use find at some point. After these two (and d/*tgz), I blindly installed (almost) everything :P Gwh From m-lists at biscuit.org.uk Mon Feb 8 10:34:39 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Mon, 8 Feb 2010 10:34:39 +0000 (GMT) Subject: [ARMedslack] Slackware-current ARM mini root fs In-Reply-To: <314c6c8f1002080122j1914b15dr443b878ec10b97b6@mail.gmail.com> References: <314c6c8f1002060100k9fe86c0y712e5806374b6ce9@mail.gmail.com> <314c6c8f1002060903x2c0508a0y2ef0f23aeff5444c@mail.gmail.com> <3f18b2311002060912p24b0f653m22136d37238f1fa3@mail.gmail.com> <314c6c8f1002071653u6f27bf6h710dca07f48150c9@mail.gmail.com> <314c6c8f1002080122j1914b15dr443b878ec10b97b6@mail.gmail.com> Message-ID: > not a hard dependency for makepkg but I had to install findutils as > well as most if not all .SlackBuild use find at some point. > After these two (and d/*tgz), I blindly installed (almost) everything :P findutils is a useful addition. I must have just missed that one. I had deliberately excluded 'which' though because I didn't think it was necessary to the running of a system; but I didn't realise makepkg needed it. So you were able to install the rest of the packages: that's good news since that's one of the purposes of the mini root. -- Stuart Winter Slackware ARM: www.armedslack.org From niels.horn at gmail.com Mon Feb 8 13:44:56 2010 From: niels.horn at gmail.com (Niels Horn) Date: Mon, 8 Feb 2010 11:44:56 -0200 Subject: [ARMedslack] Slackware-current ARM mini root fs In-Reply-To: <314c6c8f1002071653u6f27bf6h710dca07f48150c9@mail.gmail.com> References: <314c6c8f1002060100k9fe86c0y712e5806374b6ce9@mail.gmail.com> <314c6c8f1002060903x2c0508a0y2ef0f23aeff5444c@mail.gmail.com> <3f18b2311002060912p24b0f653m22136d37238f1fa3@mail.gmail.com> <314c6c8f1002071653u6f27bf6h710dca07f48150c9@mail.gmail.com> Message-ID: <3f18b2311002080544l5c121317p8803d16b37f1f6fc@mail.gmail.com> On Sun, Feb 7, 2010 at 10:53 PM, Gwenhael Le Moine wrote: >> There is an updated SlackBuild script for FBReader in the "approved" >> queue of SlackBuilds.org, waiting for the next batch of updates. >> If you can use that script to build FBReader, it would be nice, so >> that I can mark it as "arm-compatible" :) >> If you need help with it, contact me off-list. > > Hi, > > Both liblinebreak and FBReader built fine. I built liblinebreak 2.0 > and FBReader 0.12.2 (both by just updating the $VERSION in the > SlackBuild, I did that when I built on the x86_64 laptop and just copy > to the zaurus to build on arm) > liblinebreak was built with ARCH=$(uname -m) and FBReader ARCH=$(uname > -m) UI=gtk > I haven't tried to run it yet, I want to fix the touchscreen before so > I can test and use X and FBReader. > > I ended up installing most packages except k kde t tcl, especially > makepkg needs which ;) > > I'll go back to try and make the touchscreen functional now... > > Gwh Good news! Keep me informed :) Niels From w.lohman at chello.nl Wed Feb 10 11:11:09 2010 From: w.lohman at chello.nl (Wybrand Lohman) Date: Wed, 10 Feb 2010 11:11:09 +0000 Subject: [ARMedslack] mini root fs && Openmoko Freerunner In-Reply-To: References: <314c6c8f1002060100k9fe86c0y712e5806374b6ce9@mail.gmail.com> <314c6c8f1002060903x2c0508a0y2ef0f23aeff5444c@mail.gmail.com> <3f18b2311002060912p24b0f653m22136d37238f1fa3@mail.gmail.com> <3f18b2311002070310o48cbe1f2n7929dd8c11108db1@mail.gmail.com> Message-ID: <4B72944D.5090801@chello.nl> Stuart Winter wrote: > > I'm really curious about people will use ARMedslack for. For me, ARM has > always been for Desktop machines (since ARM CPUs were manufactured for the > Acorn archimedes range), so I consider ARMedslack aimed at desktops and > server usage on those machines rather than hand held gadgets. > > Two things really. I intend to use it as a server platform. Now that the GuruPlug Plus (with two NIC's) comes out in April, it offers everything I need to replace my x86 server. And once those ARM based netbooks hit the market, as they've been promising for sooo long now :-( ARMedslack will find it's place on one of those. I also see some good possibilities in the SheevaPlug&ARMedslack combo. One thing for example is as an update server on the other side of a VPN, so to safe bandwidth. I know several locations where they use an x86 desktop running 24x7 for that. ARMedslack running on a SheevaPlug will offer greatly more efficiency and reliability and yet keep the price point below ?100,- TCO. How cool is that? :D Brian Kelley wrote: >the openmoko freerunner is another good choice I tried that, but I found it was not without difficulty. I have been able to get /something/ going on the Freerunner, but the device is so limited in terms of disk space, while it's also exotic in terms of hardware and method of install. A bit like what Stuart now did with building a mini rootfs (interesting development there) I build a roofts of my own to act as a sort of bridgehead allowing me to interface with the Freerunner. The thing is, you can't really install a very limited version of ARMedslack on a device like that. With all you can shave off, it'll still be too big. I took the initrd from the ARMedslack installer, which offers a busybox environment with dropbear and a nice collection of networking, maintenance and diagnosis tools in under 25MB or so. The stock kernel, although it didn't panic and kept booting, was spitting out errors like crazy. It needed some hefty adjustments, and the quickest route was to just 'steal' a kernel and it's modules from another Openmoko distro and put that in the image. But then you have a Freerunner that boots in 3 minutes or so, draining the battery and still does nothing more than offer an ssh login. For X, you need something like tinyX or one of it's variants. This needs to be compiled to accept the touch screen as it's primary input device. And then a WM on top that is capable of being steered by the touch screen. Neither of which I had any success in. But even if you do succeed in that, you still have no telephony capability on the Freerunner. Let alone that you can start optimizing it for the HUGE power efficiency that's needed. (Is there such a thing? Somehow 'huge' and 'efficient' seem contradictory to me) My personal opinion is that it /can/ be done. I was interested in it not so much for the smartphone side of the Freerunner, but more because as a handheld embedded device it could do all sorts of tricks. I wanted it to act as a sort of thin client, mounting a network share and pull it's software from there. That would negate the limited disk space, and offer maximum flexibility (perhaps at the cost of mobility). But you'd need to get the touch screen going, no mather what. To conclude. It's possible to start with ARMedslacks initrd, steal or recompile a kernel (+modules), add something like tinyX and a WM and get the device going. It's a tremendously good learning opportunity, if nothing else. But it's not really ARMedslack anymore by then, more ARMedLFS without a manual. I think the strength of Slackware is that it offers a very complete environment that allows you to build whatever you want, be it a router, headless server, multi-media system or a desktop as lean or bloated as you can imagine. But to cramp all that power and flexibility into an embedded device as the Freerunner wont be without difficulty. Sorry 'bout the long read. And with that, we return to the order of the day. Greets, Wybrand From linuxxr at yahoo.com Wed Feb 10 18:21:48 2010 From: linuxxr at yahoo.com (Brian Kelley) Date: Wed, 10 Feb 2010 10:21:48 -0800 (PST) Subject: [ARMedslack] mini root fs && Openmoko Freerunner In-Reply-To: <4B72944D.5090801@chello.nl> Message-ID: <798270.31911.qm@web52405.mail.re2.yahoo.com> maybe an sdcard install would be better?? to get around the 512 megs of nand,, then?? 16gigs+? is possible --- On Wed, 2/10/10, Wybrand Lohman wrote: From: Wybrand Lohman Subject: Re: [ARMedslack] mini root fs && Openmoko Freerunner To: "Slackware ARM port" Date: Wednesday, February 10, 2010, 5:11 AM Stuart Winter wrote: > > I'm really curious about people will use ARMedslack for.? For me, ARM has > always been for Desktop machines (since ARM CPUs were manufactured for the > Acorn archimedes range), so I consider ARMedslack aimed at desktops and > server usage on those machines rather than hand held gadgets. > >??? Two things really. I intend to use it as a server platform. Now that the GuruPlug Plus (with two NIC's) comes out in April, it offers everything I need to replace my x86 server. And once those ARM based netbooks hit the market, as they've been promising for sooo long now :-( ARMedslack will find it's place on one of those. I also see some good possibilities in the SheevaPlug&ARMedslack combo. One thing for example is as an update server on the other side of a VPN, so to safe bandwidth. I know several locations where they use an x86 desktop running 24x7 for that. ARMedslack running on a SheevaPlug will offer greatly more efficiency and reliability and yet keep the price point below ?100,- TCO. How cool is that? :D Brian Kelley wrote: >the openmoko freerunner is another good choice I tried that, but I found it was not without difficulty. I have been able to get /something/ going on the Freerunner, but the device is so limited in terms of disk space, while it's also exotic in terms of hardware and method of install. A bit like what Stuart now did with building a mini rootfs (interesting development there) I build a roofts of my own to act as a sort of bridgehead allowing me to interface with the Freerunner. The thing is, you can't really install a very limited version of ARMedslack on a device like that. With all you can shave off, it'll still be too big. I took the initrd from the ARMedslack installer, which offers a busybox environment with dropbear and a nice collection of networking, maintenance and diagnosis tools in under 25MB or so. The stock kernel, although it didn't panic and kept booting, was spitting out errors like crazy. It needed some hefty adjustments, and the quickest route was to just 'steal' a kernel and it's modules from another Openmoko distro and put that in the image. But then you have a Freerunner that boots in 3 minutes or so, draining the battery and still does nothing more than offer an ssh login. For X, you need something like tinyX or one of it's variants. This needs to be compiled to accept the touch screen as it's primary input device. And then a WM on top that is capable of being steered by the touch screen. Neither of which I had any success in. But even if you do succeed in that, you still have no telephony capability on the Freerunner. Let alone that you can start optimizing it for the HUGE power efficiency that's needed. (Is there such a thing? Somehow 'huge' and 'efficient' seem contradictory to me) My personal opinion is that it /can/ be done. I was interested in it not so much for the smartphone side of the Freerunner, but more because as a handheld embedded device it could do all sorts of tricks. I wanted it to act as a sort of thin client, mounting a network share and pull it's software from there. That would negate the limited disk space, and offer maximum flexibility (perhaps at the cost of mobility). But you'd need to get the touch screen going, no mather what. To conclude. It's possible to start with ARMedslacks initrd, steal or recompile a kernel (+modules), add something like tinyX and a WM and get the device going. It's a tremendously good learning opportunity, if nothing else. But it's not really ARMedslack anymore by then, more ARMedLFS without a manual. I think the strength of Slackware is that it offers a very complete environment that allows you to build whatever you want, be it a router, headless server, multi-media system or a desktop as lean or bloated as you can imagine. But to cramp all that power and flexibility into an embedded device as the Freerunner wont be without difficulty. Sorry 'bout the long read. And with that, we return to the order of the day. Greets, Wybrand _______________________________________________ ARMedslack mailing list ARMedslack at lists.armedslack.org http://lists.armedslack.org/mailman/listinfo/armedslack -------------- next part -------------- An HTML attachment was scrubbed... URL: From atelszewski at gmail.com Wed Feb 10 19:33:41 2010 From: atelszewski at gmail.com (Andrzej Telszewski) Date: Wed, 10 Feb 2010 20:33:41 +0100 Subject: [ARMedslack] mini root fs && Openmoko Freerunner In-Reply-To: <798270.31911.qm@web52405.mail.re2.yahoo.com> References: <798270.31911.qm@web52405.mail.re2.yahoo.com> Message-ID: <4B730A15.3000501@gmail.com> On 02/10/2010 07:21 PM, Brian Kelley wrote: > maybe an sdcard install would be better to get around the 512 megs of nand,, then 16gigs+ is possible > > --- On Wed, 2/10/10, Wybrand Lohman wrote: > > From: Wybrand Lohman > Subject: Re: [ARMedslack] mini root fs&& Openmoko Freerunner > To: "Slackware ARM port" > Date: Wednesday, February 10, 2010, 5:11 AM > > Stuart Winter wrote: >> >> I'm really curious about people will use ARMedslack for. For me, ARM has >> always been for Desktop machines (since ARM CPUs were manufactured for the >> Acorn archimedes range), so I consider ARMedslack aimed at desktops and >> server usage on those machines rather than hand held gadgets. ARM processors are used for embedded devices worldwide. If only ARMedslack fits onto specified board, it could be used for manufacturing processes control, etc. All in all it's Linux and Linux is used very much on embedded devices for any purpose you can imagine (even toaster if you want;)) ARMedslack isn't worse than any other Linux and for us, Slackers, it seems to be the dreamed solution. For example, I'm planning to build some intelligence into my home. ARMedslack + my board will be kind of bridge, that interconnects CAN, RS-485, RF and also provides the WWW access to control the building. >> >> > Two things really. I intend to use it as a server platform. Now that the GuruPlug Plus (with two NIC's) comes out in April, it offers everything I need to replace my x86 server. And once those ARM based netbooks hit the market, as they've been promising for sooo long now :-( ARMedslack will find it's place on one of those. > > I also see some good possibilities in the SheevaPlug&ARMedslack combo. One thing for example is as an update server on the other side of a VPN, so to safe bandwidth. I know several locations where they use an x86 desktop running 24x7 for that. ARMedslack running on a SheevaPlug will offer greatly more efficiency and reliability and yet keep the price point below ?100,- TCO. How cool is that? :D > > > Brian Kelley wrote: >> the openmoko freerunner is another good choice > > I tried that, but I found it was not without difficulty. I have been able to get /something/ going on the Freerunner, but the device is so limited in terms of disk space, while it's also exotic in terms of hardware and method of install. A bit like what Stuart now did with building a mini rootfs (interesting development there) I build a roofts of my own to act as a sort of bridgehead allowing me to interface with the Freerunner. > > The thing is, you can't really install a very limited version of ARMedslack on a device like that. With all you can shave off, it'll still be too big. I took the initrd from the ARMedslack installer, which offers a busybox environment with dropbear and a nice collection of networking, maintenance and diagnosis tools in under 25MB or so. > > The stock kernel, although it didn't panic and kept booting, was spitting out errors like crazy. It needed some hefty adjustments, and the quickest route was to just 'steal' a kernel and it's modules from another Openmoko distro and put that in the image. > But then you have a Freerunner that boots in 3 minutes or so, draining the battery and still does nothing more than offer an ssh login. For X, you need something like tinyX or one of it's variants. This needs to be compiled to accept the touch screen as it's primary input device. And then a WM on top that is capable of being steered by the touch screen. Neither of which I had any success in. > > But even if you do succeed in that, you still have no telephony capability on the Freerunner. Let alone that you can start optimizing it for the HUGE power efficiency that's needed. (Is there such a thing? Somehow 'huge' and 'efficient' seem contradictory to me) > > My personal opinion is that it /can/ be done. I was interested in it not so much for the smartphone side of the Freerunner, but more because as a handheld embedded device it could do all sorts of tricks. I wanted it to act as a sort of thin client, mounting a network share and pull it's software from there. That would negate the limited disk space, and offer maximum flexibility (perhaps at the cost of mobility). But you'd need to get the touch screen going, no mather what. > > To conclude. It's possible to start with ARMedslacks initrd, steal or recompile a kernel (+modules), add something like tinyX and a WM and get the device going. It's a tremendously good learning opportunity, if nothing else. But it's not really ARMedslack anymore by then, more ARMedLFS without a manual. > I think the strength of Slackware is that it offers a very complete environment that allows you to build whatever you want, be it a router, headless server, multi-media system or a desktop as lean or bloated as you can imagine. But to cramp all that power and flexibility into an embedded device as the Freerunner wont be without difficulty. > > Sorry 'bout the long read. And with that, we return to the order of the day. > > Greets, > Wybrand > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > > > > > > > > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack -- Pozdrawiam, Andrzej Telszewski From w.lohman at chello.nl Wed Feb 10 21:23:46 2010 From: w.lohman at chello.nl (Wybrand Lohman) Date: Wed, 10 Feb 2010 21:23:46 +0000 Subject: [ARMedslack] mini root fs && Openmoko Freerunner In-Reply-To: <798270.31911.qm@web52405.mail.re2.yahoo.com> References: <798270.31911.qm@web52405.mail.re2.yahoo.com> Message-ID: <4B7323E2.3070809@chello.nl> That would work very well if you don't mind loosing the native mechanism for flashing the device with firmware. So it kind of depends on what you want to build, but it is certainly possible to use an sdcard to gain more disk space for the rootfs. Brian Kelley wrote: > maybe an sdcard install would be better to get around the 512 megs of > nand,, then 16gigs+ is possible > > --- On *Wed, 2/10/10, Wybrand Lohman //* wrote: > > > From: Wybrand Lohman > Subject: Re: [ARMedslack] mini root fs && Openmoko Freerunner > To: "Slackware ARM port" > Date: Wednesday, February 10, 2010, 5:11 AM > > Stuart Winter wrote: > > > > I'm really curious about people will use ARMedslack for. For me, > ARM has > > always been for Desktop machines (since ARM CPUs were > manufactured for the > > Acorn archimedes range), so I consider ARMedslack aimed at > desktops and > > server usage on those machines rather than hand held gadgets. > > > > > Two things really. I intend to use it as a server platform. Now > that the GuruPlug Plus (with two NIC's) comes out in April, it > offers everything I need to replace my x86 server. And once those > ARM based netbooks hit the market, as they've been promising for > sooo long now :-( ARMedslack will find it's place on one of those. > > I also see some good possibilities in the SheevaPlug&ARMedslack > combo. One thing for example is as an update server on the other > side of a VPN, so to safe bandwidth. I know several locations > where they use an x86 desktop running 24x7 for that. ARMedslack > running on a SheevaPlug will offer greatly more efficiency and > reliability and yet keep the price point below ?100,- TCO. How > cool is that? :D > > > Brian Kelley wrote: > >the openmoko freerunner is another good choice > > I tried that, but I found it was not without difficulty. I have > been able to get /something/ going on the Freerunner, but the > device is so limited in terms of disk space, while it's also > exotic in terms of hardware and method of install. A bit like what > Stuart now did with building a mini rootfs (interesting > development there) I build a roofts of my own to act as a sort of > bridgehead allowing me to interface with the Freerunner. > > The thing is, you can't really install a very limited version of > ARMedslack on a device like that. With all you can shave off, > it'll still be too big. I took the initrd from the ARMedslack > installer, which offers a busybox environment with dropbear and a > nice collection of networking, maintenance and diagnosis tools in > under 25MB or so. > > The stock kernel, although it didn't panic and kept booting, was > spitting out errors like crazy. It needed some hefty adjustments, > and the quickest route was to just 'steal' a kernel and it's > modules from another Openmoko distro and put that in the image. > But then you have a Freerunner that boots in 3 minutes or so, > draining the battery and still does nothing more than offer an ssh > login. For X, you need something like tinyX or one of it's > variants. This needs to be compiled to accept the touch screen as > it's primary input device. And then a WM on top that is capable of > being steered by the touch screen. Neither of which I had any > success in. > > But even if you do succeed in that, you still have no telephony > capability on the Freerunner. Let alone that you can start > optimizing it for the HUGE power efficiency that's needed. (Is > there such a thing? Somehow 'huge' and 'efficient' seem > contradictory to me) > > My personal opinion is that it /can/ be done. I was interested in > it not so much for the smartphone side of the Freerunner, but more > because as a handheld embedded device it could do all sorts of > tricks. I wanted it to act as a sort of thin client, mounting a > network share and pull it's software from there. That would negate > the limited disk space, and offer maximum flexibility (perhaps at > the cost of mobility). But you'd need to get the touch screen > going, no mather what. > > To conclude. It's possible to start with ARMedslacks initrd, steal > or recompile a kernel (+modules), add something like tinyX and a > WM and get the device going. It's a tremendously good learning > opportunity, if nothing else. But it's not really ARMedslack > anymore by then, more ARMedLFS without a manual. > I think the strength of Slackware is that it offers a very > complete environment that allows you to build whatever you want, > be it a router, headless server, multi-media system or a desktop > as lean or bloated as you can imagine. But to cramp all that power > and flexibility into an embedded device as the Freerunner wont be > without difficulty. > > Sorry 'bout the long read. And with that, we return to the order > of the day. > > Greets, > Wybrand > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > > http://lists.armedslack.org/mailman/listinfo/armedslack > > > ------------------------------------------------------------------------ > > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > From niels.horn at gmail.com Mon Feb 15 12:37:42 2010 From: niels.horn at gmail.com (Niels Horn) Date: Mon, 15 Feb 2010 10:37:42 -0200 Subject: [ARMedslack] Building software on ArmedSlack Message-ID: <3f18b2311002150437h6d01b373m6d302a212d586804@mail.gmail.com> Hi, While trying to control my anxiety until the SheevaPlug arrives, I'm testing some possible uses for it on armedslack running on Qemu. I tried to adapt a few SlackBuild scripts to build programs on armedslack and took a look at the scripts from the armedslack-current source tree and others from the Slackware-current source tree. I noticed most of armedslack is built with the "-march=armv4t" flag. Slackware on the other hand uses "-march=armv4 -mtune=xscale" if the architecture is set to "arm" and "-march=armv4t" if set to "armel". What would be the best setting for the SheevaPlug / qemu-versatile? I've been using "-march=armv4" for now and the compiled packages are working fine. I would like to be able to build packages that work on both the SheevaPlug and in Qemu, so that I can use one as a test setup before deploying on the other. On the other hand, I would like to get the best performance possible. :) As an example, I built Hercules (the mainframe emulator) under armedslack and it runs reasonably under Qemu. I want to install it on my SheevaPlug, so that I can carry my "mainframe" with me. Just plug it in, connect a notebook with x3270 terminal software and wait to get some funny looks :) Niels From cedric.vincent at gmail.com Mon Feb 15 18:18:15 2010 From: cedric.vincent at gmail.com (=?UTF-8?Q?C=C3=A9dric_VINCENT?=) Date: Mon, 15 Feb 2010 19:18:15 +0100 Subject: [ARMedslack] Missing files in "uinitrd-kirkwood" to support root file-system on SDHC card Message-ID: Hi all, First of all, I would like to thank Stuart et al. for providing on ARM the best Linux distro ever made. Getting back to the topic of this mail; I'm running ARMedSlack on a SheevaPlug using a SDHC card for the root file-system, sadly the current "uinitrd-kirkwood" image does not have the "/dev/mmcblk*" nodes and the "mvsdio" driver. Stuart, do you think you could add those files in your "uinitrd-kirkwood" image? Please :) Respectfully, C?dric. -- Today is a gift, that's why we call it the present. From vitaly.v.ch at gmail.com Mon Feb 15 22:04:32 2010 From: vitaly.v.ch at gmail.com (Vitaly V. Ch) Date: Mon, 15 Feb 2010 22:04:32 +0000 Subject: [ARMedslack] armedslack hang on emqbit In-Reply-To: References: <6efe08af1001310330j5721628bn8dcf37762da2bd45@mail.gmail.com> <6efe08af1002020925v4635ceb4i5829228a047347cb@mail.gmail.com> <6efe08af1002021236h7336b880i31d94dab0e405173@mail.gmail.com> <6efe08af1002031328h4e2ac44ey3a46743643783031@mail.gmail.com> <6efe08af1002040012r5fa067ddi42ca45e1b76aa0ad@mail.gmail.com> <6efe08af1002040050s9534639s7289b06c89c3c86f@mail.gmail.com> Message-ID: <6efe08af1002151404l4d769650ye508ddb0ff546127@mail.gmail.com> Dear, At now I partially run armedslack on my system. I use 2.6.31.12 kernel. Main problem was debug patch for supporting my hardware. \\wbr Vitaly Chernookiy On Thu, Feb 4, 2010 at 10:56 AM, Stuart Winter wrote: > >> > You are not using armedslack 12.2 are you ? >> > >> I'm use armedslack-current. > > Ok Good :-) > >> My at91 board initially have patches only for 2.6.21 kernels. But glibc from >> slackware-current does not support this low version of kernel. Yesterday I >> written patch for 2.6.27 kernels. And today I will try to run this version >> of kernel. > > Ah! > > Yes because Slackware ARM EABI is a new port, and the SheevaPlug support > appeared in Linux 2.6.30 and by the time I got around to making a release, > Linux 2.6.31 was out, > > glibc in -current is built against > "--enable-kernel=2.6.31 " > > Once you've built a newer kernel you should be able to boot into your > installation. > > You've got me thinking of a mini rootfs now though! > I think it'd be pretty useful to have in order to bootstrap onto newer > devices: currently I do it manually. > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > From m-lists at biscuit.org.uk Mon Feb 15 22:54:28 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Mon, 15 Feb 2010 22:54:28 +0000 (GMT) Subject: [ARMedslack] Missing files in "uinitrd-kirkwood" to support root file-system on SDHC card In-Reply-To: References: Message-ID: Hi C?dric > First of all, I would like to thank Stuart et al. for providing on ARM > the best Linux distro ever made. Thanks. > SheevaPlug using a SDHC card for the root file-system, sadly the current > "uinitrd-kirkwood" image does not have the "/dev/mmcblk*" nodes and the > "mvsdio" driver. Stuart, do you think you could add those files in your > "uinitrd-kirkwood" image? Please :) I've added mvsdio into the initrd for the next kernel update (which will be when Pat uploads the truck load of updates waiting for -current). /dev entries are made by udev. root at zaden:~/ac/source/k# mtdinfo Count of MTD devices: 3 Present MTD devices: mtd0, mtd1, mtd2 Sysfs interface supported: yes root at zaden:~/ac/source/k# ls -la /dev/mt* crw-rw---- 1 root root 90, 0 2010-02-15 14:39 /dev/mtd0 crw-rw---- 1 root root 90, 1 2010-02-15 14:39 /dev/mtd0ro crw-rw---- 1 root root 90, 2 2010-02-15 14:39 /dev/mtd1 crw-rw---- 1 root root 90, 3 2010-02-15 14:39 /dev/mtd1ro crw-rw---- 1 root root 90, 4 2010-02-15 14:39 /dev/mtd2 crw-rw---- 1 root root 90, 5 2010-02-15 14:39 /dev/mtd2ro brw-rw---- 1 root disk 31, 0 2010-02-15 14:39 /dev/mtdblock0 brw-rw---- 1 root disk 31, 1 2010-02-15 14:39 /dev/mtdblock1 brw-rw---- 1 root disk 31, 2 2010-02-15 14:39 /dev/mtdblock2 root at zaden:~/ac/source/k# That's what I have on my sheevaplug. Do you know if anything else is required in the kernel config to put them there? -- Stuart Winter Slackware ARM: www.armedslack.org From m-lists at biscuit.org.uk Mon Feb 15 23:20:37 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Mon, 15 Feb 2010 23:20:37 +0000 (GMT) Subject: [ARMedslack] Building software on ArmedSlack In-Reply-To: <3f18b2311002150437h6d01b373m6d302a212d586804@mail.gmail.com> References: <3f18b2311002150437h6d01b373m6d302a212d586804@mail.gmail.com> Message-ID: Hi Niel > I noticed most of armedslack is built with the "-march=armv4t" flag. > Slackware on the other hand uses "-march=armv4 -mtune=xscale" if the > architecture is set to "arm" and "-march=armv4t" if set to "armel". This is old stuff for when I was planning on having two ports: arm would be "old abi" and armel "EABI". Now there is only one going forward, "arm" for EABI. -march=armv4 -mtune=xscale is for the Old ABI, ARMedslack 12.2 -march=armv4t is for EABI, -current. There are only a couple of the build scripts in Slackware which could be used directly without modification: xap/pidgin, xap/blackbox (in the next round of updates) and ap/linuxdoc-tools. It's not too much effort to update the Slackware build scripts to run on ARMedslack - typically all I do is merge the main content into my template scripts; it's rare to have to patch or modify. > I've been using "-march=armv4" for now and the compiled packages are > working fine. For 12.2 this is ok but -current should be armv4t. I actually can't remember why not to use armv4 on -current - I think I tried it once when I forgot to update a build script, and got weird results. > I would like to be able to build packages that work on both the > SheevaPlug and in Qemu, so that I can use one as a test setup before > deploying on the other. On the other hand, I would like to get the > best performance possible. :) The userland is all the same and both are armv5. The only different packages are the kernels which you need for ARM. QEMU: Linux slackware 2.6.32.7-versatile #2 PREEMPT Sun Jan 31 21:57:08 GMT 2010 armv5tejl GNU/Linux Sheevaplug: Linux zaden 2.6.32.8-kirkwood #2 PREEMPT Sun Feb 14 21:29:38 GMT 2010 armv5tel Feroceon 88FR131 rev 1 (v5l) Marvell SheevaPlug Reference Board GNU/Linux If you want the better performance, you could compile it for armv5t but I doubt you'd notice any difference. ARMedslack is compiled for armv4t because it's the lowest ARM CPU still just about sensible to use and there are many of them in the field. > As an example, I built Hercules (the mainframe emulator) under > armedslack and it runs reasonably under Qemu. You built an emulator inside an emulator?! what is your x86 hardware?! QEMU isn't exactly that fast for me even on a reasonable machine! -- Stuart Winter Slackware ARM: www.armedslack.org From niels.horn at gmail.com Tue Feb 16 02:49:40 2010 From: niels.horn at gmail.com (Niels Horn) Date: Tue, 16 Feb 2010 00:49:40 -0200 Subject: [ARMedslack] Building software on ArmedSlack In-Reply-To: References: <3f18b2311002150437h6d01b373m6d302a212d586804@mail.gmail.com> Message-ID: <3f18b2311002151849h46b3993du1da81957e3f33c88@mail.gmail.com> On Mon, Feb 15, 2010 at 9:20 PM, Stuart Winter wrote: > > Hi Niel > >> I noticed most of armedslack is built with the "-march=armv4t" flag. >> Slackware on the other hand uses "-march=armv4 -mtune=xscale" if the >> architecture is set to "arm" and "-march=armv4t" if set to "armel". > > This is old stuff for when I was planning on having two ports: arm would > be "old abi" and armel "EABI". > Now there is only one going forward, "arm" for EABI. > > -march=armv4 -mtune=xscale is for the Old ABI, ARMedslack 12.2 > -march=armv4t is for EABI, -current. > OK, that clarified it. :) > There are only a couple of the build scripts in Slackware which could be > used directly without modification: xap/pidgin, xap/blackbox (in the next > round of updates) and ap/linuxdoc-tools. > It's not too much effort to update the Slackware build scripts to run on > ARMedslack - typically all I do is merge the main content into my template > scripts; it's rare to have to patch or modify. > I took a look at the pidgin SlackBuild from Slackware-current. It would be very nice to have a unified standard between Slackware / ArmedSlack / Slack/390. (I use the first two and play with the third) to make things simpler. Since I maintain some packages on SlackBuild.org, having this "unified standard" interests me so that I can maintain my builds for all platforms. >> I've been using "-march=armv4" for now and the compiled packages are >> working fine. > > For 12.2 this is ok but -current should be armv4t. > I actually can't remember why not to use armv4 on -current - I think I > tried it once when I forgot to update a build script, and got weird > results. > Well, the (very few) packages I built are working under armedslack-current without problems. But I just tried a few simple things until now and Hercules was my first "big" project. >> I would like to be able to build packages that work on both the >> SheevaPlug and in Qemu, so that I can use one as a test setup before >> deploying on the other. On the other hand, I would like to get the >> best performance possible. :) > > The userland is all the same and both are armv5. ?The only different > packages are the kernels which you need for ARM. > OK, that makes things simpler. I guess 99% I can build using armv4t as this is the standard. > QEMU: > Linux slackware 2.6.32.7-versatile #2 PREEMPT Sun Jan 31 21:57:08 GMT 2010 > armv5tejl GNU/Linux > > Sheevaplug: > Linux zaden 2.6.32.8-kirkwood #2 PREEMPT Sun Feb 14 21:29:38 GMT 2010 > armv5tel Feroceon 88FR131 rev 1 (v5l) Marvell SheevaPlug Reference Board > GNU/Linux > > If you want the better performance, you could compile it for armv5t but I > doubt you'd notice any difference. ?ARMedslack is compiled for armv4t > because it's the lowest ARM CPU still just about sensible to use and there > are many of them in the field. > I will rebuild Hercules with armv5t. As it is an emulator, every microsecond counts. :) >> As an example, I built Hercules (the mainframe emulator) under >> armedslack and it runs reasonably under Qemu. > > You built an emulator inside an emulator?! ?what is your x86 hardware?! > QEMU isn't exactly that fast for me even on a reasonable machine! > Yes, but this was only to test the concept. The idea is to use Hercules on my SheevaPlug when it arrives. Then I can carry a mainframe around in my bag :D My x86 system is a "Dual GenuineIntel Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz", running Slackware64-current, with 4GB of memory and 1.2TB of hard drives. For the older mainframe operating systems like MVS (from decades ago), it actually works reasonably well even under Qemu. The idea of using Qemu is that it works nice with snapshots, so I can fall back to a stable installation if I mess things up. But OK, I am known to do unusual things with emulators and virtual machines :) Thanks for the information and keep up the good work! Niels From cedric.vincent at gmail.com Tue Feb 16 09:18:57 2010 From: cedric.vincent at gmail.com (=?UTF-8?Q?C=C3=A9dric_VINCENT?=) Date: Tue, 16 Feb 2010 10:18:57 +0100 Subject: [ARMedslack] Missing files in "uinitrd-kirkwood" to support root file-system on SDHC card In-Reply-To: References: Message-ID: On Mon, Feb 15, 2010 at 11:54 PM, Stuart Winter wrote: > I've added mvsdio into the initrd for the next kernel update (which will > be when Pat uploads the truck load of updates waiting for -current). Many thanks! > /dev entries are made by udev. I don't think the udev daemon already runs at this stage since I did not see the "/sbin/udev*" binaries into the default uinitrd-kirkwood ("/dev/sda[1-3]" nodes were statically created). Maybe you forgot to include those binaries since the "/init" script tries to launch the daemon (if it exists) moreover some configuration files are lying in the "/etc/udev" directory of this initrd image. > root at zaden:~/ac/source/k# mtdinfo > Count of MTD devices: ? ? ? ? ? 3 > Present MTD devices: ? ? ? ? ? ?mtd0, mtd1, mtd2 > Sysfs interface supported: ? ? ?yes > [...] > That's what I have on my sheevaplug. I guess MTD devices are only for the internal NAND Flash. [ 22.273872] NAND device: Manufacturer ID: 0xec, Chip ID: 0xdc (Samsung NAND 512MiB 3,3V 8-bit) [ 22.412637] Creating 3 MTD partitions on "orion_nand": [...] [ 22.417801] 0x000000000000-0x000000100000 : "u-boot" [...] [ 22.427088] 0x000000100000-0x000000500000 : "uImage" [...] [ 22.437437] 0x000000500000-0x000020000000 : "root" The SD card is managed by a MMC device (as for my Slackware-powered laptop): cedric at metalplug:/dev/shm/initrd$ dmesg | grep mmc [ 0.000000] Kernel command line: console=ttyS0,115200 root=/dev/mmcblk0p3 rootfs=ext2 [ 22.915533] mmc0: mvsdio driver initialized, lacking card detect (fall back to polling) [ 23.008888] mmc0: host does not support reading read-only switch. assuming write-enable. [ 23.021697] mmc0: new high speed SDHC card at address 0007 [ 23.041789] mmcblk0: mmc0:0007 SD08G 7.48 GiB [ 23.046402] mmcblk0: p1 p2 p3 cedric at metalplug:/dev/shm/initrd$ ls -l /dev/mmcblk0* brw-rw---- 1 root disk 179, 0 2010-02-15 17:58 /dev/mmcblk0 brw-rw---- 1 root disk 179, 1 2010-02-15 17:58 /dev/mmcblk0p1 brw-rw---- 1 root disk 179, 2 2010-02-15 17:58 /dev/mmcblk0p2 brw-rw---- 1 root disk 179, 3 2010-02-15 17:58 /dev/mmcblk0p3 Obviously, the nodes above were created by the udev daemon once the system has changed its root file-system from the initrd to the SD card. > Do you know if anything else is required in the kernel config to put them > there? In fact, I'm using the default uImage-kirkwood, I only have to add the "/dev/mmcblk*" nodes and the "mvsdio" module to the default uinitrd-kirkwood. Thanks, C?dric. From vitaly.v.ch at gmail.com Tue Feb 16 09:31:32 2010 From: vitaly.v.ch at gmail.com (Vitaly V. Ch) Date: Tue, 16 Feb 2010 11:31:32 +0200 Subject: [ARMedslack] HowTo run ArmedSlack on AT91RM9200 with root on SD Message-ID: <6efe08af1002160131j88d5242geab55db1e575736d@mail.gmail.com> 1. In most cases there are need to sold additional pullup resistor 10kOhm between MCI_CMD and Vcc. Without this resistor SD card will be non-accessible for software like linux kernel. (Source: Errata from Atmel). PS: on EmQbit this trouble *PARTIALLY* solved via patch, which enable internal pull-up resistor. \\wbr Vitaly Chernookiy From m-lists at biscuit.org.uk Tue Feb 16 10:46:31 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Tue, 16 Feb 2010 10:46:31 +0000 (GMT) Subject: [ARMedslack] Missing files in "uinitrd-kirkwood" to support root file-system on SDHC card In-Reply-To: References: Message-ID: Hi > cedric at metalplug:/dev/shm/initrd$ ls -l /dev/mmcblk0* > brw-rw---- 1 root disk 179, 0 2010-02-15 17:58 /dev/mmcblk0 > brw-rw---- 1 root disk 179, 1 2010-02-15 17:58 /dev/mmcblk0p1 > brw-rw---- 1 root disk 179, 2 2010-02-15 17:58 /dev/mmcblk0p2 > brw-rw---- 1 root disk 179, 3 2010-02-15 17:58 /dev/mmcblk0p3 The /dev entries are absent because the mkinird is created only for what is officially supported - installing onto a SCSI type device, which is what my build machines have. When the initrd is created, the mkinitrd script looks at the system and creates the /dev entries it needs to boot that particular system. I'm surprised I haven't bumped into this situation before! I thought I'd done quite well with producing generic initrd's ;-) [..] > In fact, I'm using the default uImage-kirkwood, I only have to add the > "/dev/mmcblk*" nodes and the "mvsdio" module to the default > uinitrd-kirkwood. The mvsdio module will be added. I considered adding static /dev entries in as part of the kernel.SlackBuild script, but would be a dirty hack and wouldn't work especially since not all mmc devices have 179 as their major device number. The best way to make this work is to either use udev in the initrd or use busybox's "mdev -s" (preferable since udev is a bit chunky and mdev is already there). I was looking at the "/init" script inside the initrd to figure out how to use mdev to populate /dev for us; as this will work for your installation and will solve more complex setups. Unfortunately I've just stiffed my spare sheevaplug so I can't test mdev today, so I'll do it tomorrow. -- Stuart Winter Slackware ARM: www.armedslack.org From m-lists at biscuit.org.uk Tue Feb 16 10:56:29 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Tue, 16 Feb 2010 10:56:29 +0000 (GMT) Subject: [ARMedslack] Building software on ArmedSlack In-Reply-To: <3f18b2311002151849h46b3993du1da81957e3f33c88@mail.gmail.com> References: <3f18b2311002150437h6d01b373m6d302a212d586804@mail.gmail.com> <3f18b2311002151849h46b3993du1da81957e3f33c88@mail.gmail.com> Message-ID: > I took a look at the pidgin SlackBuild from Slackware-current. It > would be very nice to have a unified standard between Slackware / > ArmedSlack / Slack/390. (I use the first two and play with the third) > to make things simpler. Since I maintain some packages on > SlackBuild.org, having this "unified standard" interests me so that I > can maintain my builds for all platforms. If you want a standard unified script: the examples of pidgin will be all you need - because I updated these scripts for Slackware and put the changes in :-) Pat's also been adding the auto $ARCH detection I added to the pidgin script, which the single "arm" architecture; but what's missing from the main build scripts are: $ARCHQUADLET="-gnueabi" and the CFLAGS of "-march=armv4t" I could ask him to add it in as he's going, but there are still occasions when I patch things or make modifications to get it to compile. Without write access to the tree to put in either patch files, or add bits of sed and stuff to the SlackBuilds, we'd end up with a fragmented armedslack tree - using bits of Slackware's source tree and then the odd script dotted around armedslack's. Fortunately I have scripts and copies of the previous build scripts in the master tree, which makes it easy to check what's changed and merge in the differences. > Yes, but this was only to test the concept. The idea is to use > Hercules on my SheevaPlug when it arrives. Then I can carry a > mainframe around in my bag :D Oh right, well that makes more sense. Wow, if the emulator of Hercules works OK in QEMU, it'll be a lot faster on the Sheevaplug. Are S/390s really that slow?! :) > The idea of using Qemu is that it works nice with snapshots, so I can > fall back to a stable installation if I mess things up. yeah tell me about it. I bricked my -current workhorse last week when I missed a configure option in the new version of e2fsprogs, then upgradepkg'd the result; the system started falling over. It took me almost a day to work out what had happened! Fortunately I have two machines running -current: one live and one stable so I can login and rebuild the packages and just reinstall the broken one using the installer. -- Stuart Winter Slackware ARM: www.armedslack.org From m-lists at biscuit.org.uk Tue Feb 16 11:04:35 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Tue, 16 Feb 2010 11:04:35 +0000 (GMT) Subject: [ARMedslack] Missing files in "uinitrd-kirkwood" to support root file-system on SDHC card In-Reply-To: References: Message-ID: > > The best way to make this work is to either use udev in the initrd or use > busybox's "mdev -s" (preferable since udev is a bit chunky and mdev is > already there). I was looking at the "/init" script inside the > initrd to figure out how to use mdev to populate /dev for us; as this will > work for your installation and will solve more complex setups. mkinitrd has a -u option to include udev. I've set the kernels rebuilding, so hopefully out will come initrd's containing udev, and the problem will be solved. -- Stuart Winter Slackware ARM: www.armedslack.org From cedric.vincent at gmail.com Tue Feb 16 11:27:46 2010 From: cedric.vincent at gmail.com (=?UTF-8?Q?C=C3=A9dric_VINCENT?=) Date: Tue, 16 Feb 2010 12:27:46 +0100 Subject: [ARMedslack] Missing files in "uinitrd-kirkwood" to support root file-system on SDHC card In-Reply-To: References: Message-ID: On Tue, Feb 16, 2010 at 12:04 PM, Stuart Winter wrote: >> >> The best way to make this work is to either use udev in the initrd or use >> busybox's "mdev -s" (preferable since udev is a bit chunky and mdev is >> already there). ?I was looking at the "/init" script inside the >> initrd to figure out how to use mdev to populate /dev for us; as this will >> work for your installation and will solve more complex setups. > > mkinitrd has a -u option to include udev. > > I've set the kernels rebuilding, so hopefully out will come > initrd's containing udev, and the problem will be solved. OK, thanks! Feel free to ask me to test any new setup. Cheers, C?dric. From niels.horn at gmail.com Tue Feb 16 12:02:58 2010 From: niels.horn at gmail.com (Niels Horn) Date: Tue, 16 Feb 2010 10:02:58 -0200 Subject: [ARMedslack] Building software on ArmedSlack In-Reply-To: References: <3f18b2311002150437h6d01b373m6d302a212d586804@mail.gmail.com> <3f18b2311002151849h46b3993du1da81957e3f33c88@mail.gmail.com> Message-ID: <3f18b2311002160402u71564630j123ab5d964cbf6de@mail.gmail.com> On Tue, Feb 16, 2010 at 8:56 AM, Stuart Winter wrote: > If you want a standard unified script: the examples of pidgin will be all > you need - because I updated these scripts for Slackware and put the > changes in :-) > Pat's also been adding the auto $ARCH detection I added to the pidgin > script, which the single "arm" architecture; but what's missing from > the main build scripts are: > ?$ARCHQUADLET="-gnueabi" > and the CFLAGS of "-march=armv4t" I took a quick look and it seems promising :) >> Yes, but this was only to test the concept. The idea is to use >> Hercules on my SheevaPlug when it arrives. Then I can carry a >> mainframe around in my bag :D > > Oh right, well that makes more sense. ?Wow, if the emulator of Hercules > works OK in QEMU, it'll be a lot faster on the Sheevaplug. > Are S/390s really that slow?! :) Well, MVS is from the 70s/80s, when processors were still in the 1-10 MHz range, so that's simple to emulate. Now, emulating a modern mainframe with z/OS running on it and hundreds of users connected is a whole other story :) But if I can get it to run nicely with three or four users just for demonstration, I'm happy! Mainframes have processor speeds nowadays that do not impress too much (a few GHz, just like our desktops), but they have *lots* of them and *LOTS* of memory. And special processors for special jobs, etc. Together with an OS IBM has been writing for about 50 years, they make fine workhorses. >> The idea of using Qemu is that it works nice with snapshots, so I can >> fall back to a stable installation if I mess things up. > > yeah tell me about it. ?I bricked my -current workhorse last week when I > missed a configure option in the new version of e2fsprogs, then > upgradepkg'd the result; the system started falling over. ?It took me > almost a day to work out what had happened! ?Fortunately I have two > machines running -current: one live and one stable so I can login and > rebuild the packages and just reinstall the broken one using the > installer. > That's the fun part of working with computers ;) Niels From m-lists at biscuit.org.uk Tue Feb 16 14:07:24 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Tue, 16 Feb 2010 14:07:24 +0000 (GMT) Subject: [ARMedslack] Missing files in "uinitrd-kirkwood" to support root file-system on SDHC card In-Reply-To: References: Message-ID: Hi C?dric. > OK, thanks! Feel free to ask me to test any new setup. The uinitrd is in here, as usual: ftp://slackware.mirror.zen.co.uk/testing/kernel_kirkwood-2.6.32.8-arm-1.tgz ftp://slackware.mirror.zen.co.uk/testing/kernel-modules-kirkwood-2.6.32.8_kirkwood-arm-1.tgz Can you test those please? -- Stuart Winter Slackware ARM: www.armedslack.org From cedric.vincent at gmail.com Tue Feb 16 14:30:24 2010 From: cedric.vincent at gmail.com (=?UTF-8?Q?C=C3=A9dric_VINCENT?=) Date: Tue, 16 Feb 2010 15:30:24 +0100 Subject: [ARMedslack] Missing files in "uinitrd-kirkwood" to support root file-system on SDHC card In-Reply-To: References: Message-ID: On Tue, Feb 16, 2010 at 3:07 PM, Stuart Winter wrote: > The uinitrd is in here, as usual: > ftp://slackware.mirror.zen.co.uk/testing/kernel_kirkwood-2.6.32.8-arm-1.tgz > ftp://slackware.mirror.zen.co.uk/testing/kernel-modules-kirkwood-2.6.32.8_kirkwood-arm-1.tgz > > Can you test those please? OK, I will test them as soon as I have a physical access to my device to adjust its u-boot configuration, that is, in a couple of hours ;) Cheers, C?dric. From cedric.vincent at gmail.com Tue Feb 16 18:25:28 2010 From: cedric.vincent at gmail.com (=?UTF-8?Q?C=C3=A9dric_VINCENT?=) Date: Tue, 16 Feb 2010 19:25:28 +0100 Subject: [ARMedslack] Missing files in "uinitrd-kirkwood" to support root file-system on SDHC card In-Reply-To: References: Message-ID: 2010/2/16 C?dric VINCENT : > On Tue, Feb 16, 2010 at 3:07 PM, Stuart Winter wrote: >> The uinitrd is in here, as usual: >> ftp://slackware.mirror.zen.co.uk/testing/kernel_kirkwood-2.6.32.8-arm-1.tgz >> ftp://slackware.mirror.zen.co.uk/testing/kernel-modules-kirkwood-2.6.32.8_kirkwood-arm-1.tgz >> >> Can you test those please? > > OK, I will test them as soon as I have a physical access to my device > to adjust its u-boot configuration, that is, in a couple of hours ;) It works fine (i.e. I'm using it as my default now), however I got many warnings like the following one: udevd[564]: BUS= will be removed in a future udev version, please use SUBSYSTEM= to match the event device, or SUBSYSTEMS= to match a parent device, in /lib/udev/rules.d/60-bluetooth.rules:XXX Maybe the configuration files are not in sync with the version of the daemon. Cheers, C?dric. From m-lists at biscuit.org.uk Wed Feb 17 08:39:04 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Wed, 17 Feb 2010 08:39:04 +0000 (GMT) Subject: [ARMedslack] Missing files in "uinitrd-kirkwood" to support root file-system on SDHC card In-Reply-To: References: Message-ID: Thanks for testing the packages. > udevd[564]: BUS= will be removed in a future udev version, please > use SUBSYSTEM= to match the event device, or SUBSYSTEMS= to match a > parent device, in /lib/udev/rules.d/60-bluetooth.rules:XXX > > Maybe the configuration files are not in sync with the version of the daemon. This is because the bluetooth configs from n/bluez-utils is out an old format. Bluez-utils is scheduled for an upgrade so this will resolve itself by the time the next batch of packages is out. I'm glad the initrd works! From mr.spuratic at gmail.com Thu Feb 18 01:39:57 2010 From: mr.spuratic at gmail.com (Conor McCarthy) Date: Thu, 18 Feb 2010 01:39:57 +0000 Subject: [ARMedslack] Missing files in "uinitrd-kirkwood" to support root file-system on SDHC card Message-ID: <48f5f5611002171739s18ae74efwedde1cabd1097a8f@mail.gmail.com> Hey all, I worked through this issue over the weekend (as fate would have it) though I was using an armedslack-current version from December. I don't see enough in the Changelogs to cover everything I hit, so here are the main problems I had. Hopefully this will be useful to someone. I'm using a sheevaplug, my aim was to leave the builtin ubuntu/flash alone, install just an updated Das u-boot (easy, v1.1.4), and then armedslack on a 4GB SDHC with a kernel image and initrd that can be loaded directly from SDHC with u-boot. I have a USB disk also, though I'm not booting from it right now. I used uinitrd-kirkwood-2.6.31.6 uImage-kirkword-2.6.31.6, also from December -current (files dated 2009-11-16). - mvsdio is omitted from initrd (tftp-ed it as a workaround) - "mdev -s" works just fine after that's added - the busybox (1.12.1) insmod doesn't support compressed modules gunzip works, so this fixes it when the initrd bails: find . -name ".ko.gz" -exec gunzip {} \; (AFAICT .ko.gz support was added in busybox 1.13.4) - the armedslack kernel modules binary package uses compressed modules, so you still hit this problem when you (re)build your own initrd image - for a sheevaplug I suspect udev in initrd is overkill, you only need a handful of modules and devices to make USB, network and SD/MMC available I scripted a wrapper for mkinitrd which re-makes the initrd with uncompressed modules, and re-writes load_kernel_modules accordingly. When I get around to rebuilding the kernel and modules myself, I'll probably just stick to uncompressed modules, since it's no hit for a compressed initrd image. The mkinitrd script will need some work to fully support compressed modules, or support decompressing them for initrd when the installed/live ones are compressed. I boot with something like: setenv bootargs_root root=/dev/mmcblk0p2 ro setenv bootcmd_mmc 'mmcinit; ext2load mmc 0 0x00800000 /uinitrd-kirkwood; ext2load mmc 0 0x00400000 /uImage-kirkwood' bootcmd_new=setenv bootargs $(bootargs_console) $(bootargs_root); run bootcmd_mmc; bootm 0x400000 0x800000 mmc0:1 is a small ext3 partition, later mounted as /boot mmc0:2 is / uinitrd-kirkwood and uImage-kirkwood are symlinks to the relevant initrd/kernel with version suffixes. I hope I've explained everything clearly. Regards, Conor. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedric.vincent at gmail.com Thu Feb 18 08:31:10 2010 From: cedric.vincent at gmail.com (=?UTF-8?Q?C=C3=A9dric_VINCENT?=) Date: Thu, 18 Feb 2010 09:31:10 +0100 Subject: [ARMedslack] Missing files in "uinitrd-kirkwood" to support root file-system on SDHC card In-Reply-To: <48f5f5611002171739s18ae74efwedde1cabd1097a8f@mail.gmail.com> References: <48f5f5611002171739s18ae74efwedde1cabd1097a8f@mail.gmail.com> Message-ID: On Thu, Feb 18, 2010 at 2:39 AM, Conor McCarthy wrote: > I don't see enough in the Changelogs to cover everything I hit, so > here are the main problems I had. Hopefully this will be useful to > someone. Thanks for sharing :) ! > - for a sheevaplug I suspect udev in initrd is overkill, you only > need a handful of modules and devices to make USB, network and > SD/MMC available I did not encounter any drawbacks with udev yet, moreover the inirtd could be use for another "kirkwood" device (which one?). I think you are right, mdev should be efficient enough here. > mmc0:1 is a small ext3 partition, later mounted as /boot > mmc0:2 is / Please, let me know if you are using specific mount options for your MMC partitions. For instance, I use an ext2 FS with the options "noatime" and "async" to reduce as much as possible write cycles. Regards, C?dric. From m-lists at biscuit.org.uk Thu Feb 18 11:27:33 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Thu, 18 Feb 2010 11:27:33 +0000 (GMT) Subject: [ARMedslack] Missing files in "uinitrd-kirkwood" to support root file-system on SDHC card In-Reply-To: <48f5f5611002171739s18ae74efwedde1cabd1097a8f@mail.gmail.com> References: <48f5f5611002171739s18ae74efwedde1cabd1097a8f@mail.gmail.com> Message-ID: > - the busybox (1.12.1) insmod doesn't support compressed modules > gunzip works, so this fixes it when the initrd bails: > find . -name ".ko.gz" -exec gunzip {} \; > (AFAICT .ko.gz support was added in busybox 1.13.4) The current initrd's use busybox 1.15.3 (which is what's in Slackware-current at the moment). I don't see anything in the menuconfig that indicates that it now includes gzip decompression support. I've added an option to mkinitrd to use the system versions from module-init-tools; which works in the installer and I've also had it confirmed that doing this makes it work in the initrd. So I'll go with this option for the time being. > - for a sheevaplug I suspect udev in initrd isoverkill, you only need a > handful of modules and devices to make USB, network and > SD/MMC available udev takes care of populating /dev with the required entries. Since it doesn't add a great deal of weight to the initrd, I'm happy to leave it in. I'm not overly keen on maintaining a manual list of what's required to boot the device in order to provide generic initrd's, but I don't see any other way at the moment. Fortunately the devices are limited by what hardware is available on them, so it's reasonably straight forward at the *moment* to maintain the list of kernel modules in kernel.SlackBuild. > modules myself, I'll probably just stick to uncompressed modules, > since it's no hit for a compressed initrd image. You should find that with the next round of updates, all of this is fixed. I'll send a message when these updates are available. > I hope I've explained everything clearly. Yes thanks for that. I'm very keen to have everything working out of the box. It's also worth,however, if you're using -current, to update the system since many of the problems are already fixed in newer packages. If I've added a kernel module that's of particular use, or made a change that's outside of a Slackware x86 update, I tend to mention it in the changelog; so it's worth looking out for those. -- Stuart Winter Slackware ARM: www.armedslack.org From m-lists at biscuit.org.uk Thu Feb 18 14:10:40 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Thu, 18 Feb 2010 14:10:40 +0000 (GMT) Subject: [ARMedslack] Missing files in "uinitrd-kirkwood" to support root file-system on SDHC card In-Reply-To: References: <48f5f5611002171739s18ae74efwedde1cabd1097a8f@mail.gmail.com> Message-ID: > Slackware-current at the moment). I don't see anything in the menuconfig > that indicates that it now includes gzip decompression support. Found it in the changelog though Good so that's another problem solved! :-) From mozes at slackware.com Thu Feb 18 14:26:37 2010 From: mozes at slackware.com (Stuart Winter) Date: Thu, 18 Feb 2010 06:26:37 -0800 (PST) Subject: [ARMedslack] Help building poppler Message-ID: Hi Poppler isn't building at the moment and it's stopping me building other stuff that links against it. I haven't tried building this on the public armedslack-current at the moment, but hopefully it'll fail there too ;) The build stuff is here: rsync -Pavv slackware.mirror.zen.co.uk::testing/poppler . libtool: link: g++ -Wall -Wno-write-strings -Woverloaded-virtual -g -O2 -o .libs/test-poppler-qt4 test-poppler-qt4.o ../../poppler/.libs/libpoppler.so ../../qt4/src/.libs/libpoppler-qt4.so -L/usr//lib /usr//lib/libfontconfig.so -L/usr/lib/qt/lib -lQtGui -lQtXml -lQtCore -lz -pthread -Wl,-rpath -Wl,/usr//lib ../../qt4/src/.libs/libpoppler-qt4.so: undefined reference to `qvsnprintf(char*, unsigned int, char const*, std::__va_list)' collect2: ld returned 1 exit status distcc[20324] ERROR: compile (null) on localhost failed Hopefully it will fail like that. I've tried rebuilding 0.12.2 which is currently in armedslack-current -- this fails with the same error. Help fixing that will be much appreciated! -- Stuart Winter www.slackware.com/~mozes Slackware for ARM: www.armedslack.org From cedric.vincent at gmail.com Sat Feb 20 08:44:05 2010 From: cedric.vincent at gmail.com (=?UTF-8?Q?C=C3=A9dric_VINCENT?=) Date: Sat, 20 Feb 2010 09:44:05 +0100 Subject: [ARMedslack] Help building poppler In-Reply-To: References: Message-ID: Hi Stuart, I didn't try to build Poppler yet, however I can see that the QtCore library in the current ARMedSlack does not provide the same signature/mangling for the function "qvsnprintf": cedric at metalplug:~$ readelf -sW /usr/lib/qt/lib/libQtCore.so | grep qvsnprintf 3215: 000adfa0 36 FUNC GLOBAL DEFAULT 10 _Z10qvsnprintfPcjPKcPv cedric at metalplug:~$ c++filt _Z10qvsnprintfPcjPKcPv qvsnprintf(char*, unsigned int, char const*, void*) Either you built libQtCore with a different version of GCC, or maybe the auto-configuration system of Poppler did not detect the right way to handle __va_list. For information, I saw the following warning when compiling another C++ project (Squid): note: the mangling of ?va_list? has changed in GCC 4.4 It means the linker will not be able to resolve the reference with the old signature/mangling anymore (for function that use va_list). As a conclusion, one has to recompile the library with the same version of the GCC compiler. Regards, C?dric. On Thu, Feb 18, 2010 at 3:26 PM, Stuart Winter wrote: > > Hi > > Poppler isn't building at the moment and it's stopping me building other > stuff that links against it. > > I haven't tried building this on the public armedslack-current at the > moment, but hopefully it'll fail there too ;) > > The build stuff is here: > ?rsync -Pavv slackware.mirror.zen.co.uk::testing/poppler . > > libtool: link: g++ -Wall -Wno-write-strings -Woverloaded-virtual -g -O2 -o > .libs/test-poppler-qt4 test-poppler-qt4.o > ../../poppler/.libs/libpoppler.so ../../qt4/src/.libs/libpoppler-qt4.so > -L/usr//lib /usr//lib/libfontconfig.so -L/usr/lib/qt/lib -lQtGui -lQtXml > -lQtCore -lz -pthread -Wl,-rpath -Wl,/usr//lib > ../../qt4/src/.libs/libpoppler-qt4.so: undefined reference to > `qvsnprintf(char*, unsigned int, char const*, std::__va_list)' > collect2: ld returned 1 exit status > distcc[20324] ERROR: compile (null) on localhost failed > > Hopefully it will fail like that. > > I've tried rebuilding 0.12.2 which is currently in armedslack-current -- > this fails with the same error. > > Help fixing that will be much appreciated! > > -- > Stuart Winter > www.slackware.com/~mozes > Slackware for ARM: www.armedslack.org > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > -- Today is a gift, that's why we call it the present. From niels.horn at gmail.com Sat Feb 20 09:55:35 2010 From: niels.horn at gmail.com (Niels Horn) Date: Sat, 20 Feb 2010 07:55:35 -0200 Subject: [ARMedslack] Help building poppler In-Reply-To: References: Message-ID: <3f18b2311002200155x1c0e4cd3m8918aa0e58bd476f@mail.gmail.com> 2010/2/20 C?dric VINCENT : > Hi Stuart, > > I didn't try to build Poppler yet, however I can see that the QtCore > library in the current ARMedSlack does not provide the same > signature/mangling for the function "qvsnprintf": > > ? ?cedric at metalplug:~$ readelf -sW /usr/lib/qt/lib/libQtCore.so | > grep qvsnprintf > ? ? ?3215: 000adfa0 ? ?36 FUNC ? ?GLOBAL DEFAULT ? 10 _Z10qvsnprintfPcjPKcPv > > ? ?cedric at metalplug:~$ c++filt _Z10qvsnprintfPcjPKcPv > ? ?qvsnprintf(char*, unsigned int, char const*, void*) > > Either you built libQtCore with a different version of GCC, or maybe > the auto-configuration system of Poppler did not detect the right way > to handle __va_list. > > For information, I saw the following warning when compiling another > C++ project (Squid): > > ? ?note: the mangling of ?va_list? has changed in GCC 4.4 > > It means the linker will not be able to resolve the reference with the > old signature/mangling anymore (for function that use va_list). As a > conclusion, one has to recompile the library with the same version of > the GCC compiler. > > Regards, > C?dric. > Yep, the name mangling has changed in gcc 4.4 for 'va_list' on the arm architecture. It's one of these "new features" introduced by the gcc people so that programmers and maintainers have fun! :) After compiling poppler, readelf -sW /tmp/poppler-0.12.3/qt4/src/.libs/libpoppler-qt4.so | grep qvsnprintf gave: 966: 00000000 0 NOTYPE GLOBAL DEFAULT UND _Z10qvsnprintfPcjPKcSt9__va_list 2475: 00000000 0 NOTYPE GLOBAL DEFAULT UND _Z10qvsnprintfPcjPKcSt9__va_list and c++filt _Z10qvsnprintfPcjPKcSt9__va_list shows: qvsnprintf(char*, unsigned int, char const*, std::__va_list) The solution was to recompile the qt library, so that the qvsnprintf function is mangled in the new way and can be linked to when compiling poppler. The really fun part is, that after recompiling qt, poppler will compile fine, but everything else that uses the function needs to be recompiled as well :) And that might include several parts of KDE... Niels From m-lists at biscuit.org.uk Sat Feb 20 10:06:37 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sat, 20 Feb 2010 10:06:37 +0000 (GMT) Subject: [ARMedslack] Help building poppler In-Reply-To: References: Message-ID: Hi C?dric Thanks for having a look. Niels Horn was also looking at this and we came to the same conclusion regarding gcc. However I don't know why, because the build log for the version of qt said it was built with the same gcc as poppler. > For information, I saw the following warning when compiling another > C++ project (Squid): > > note: the mangling of ?va_list? has changed in GCC 4.4 > > It means the linker will not be able to resolve the reference with the > old signature/mangling anymore (for function that use va_list). As a > conclusion, one has to recompile the library with the same version of > the GCC compiler. I'd tried recompiling qt as the first test but it didn't build because it needed patching to work with libpng 1.4 which is now in -current. qt's now been patched and recompiled, and poppler works. I still see the va_list mangling message above though. There have been many changes in Slackware at the moment and I expect to recompile many of the new packages once again before they go public. From m-lists at biscuit.org.uk Sat Feb 20 10:09:11 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sat, 20 Feb 2010 10:09:11 +0000 (GMT) Subject: [ARMedslack] Help building poppler In-Reply-To: <3f18b2311002200155x1c0e4cd3m8918aa0e58bd476f@mail.gmail.com> References: <3f18b2311002200155x1c0e4cd3m8918aa0e58bd476f@mail.gmail.com> Message-ID: > The really fun part is, that after recompiling qt, poppler will > compile fine, but everything else that uses the function needs to be > recompiled as well :) And that might include several parts of KDE... Pat knows the KDE in non public -current is broken because of the libpng update; I *think* KDE is planned to be upgraded. -- Stuart Winter Slackware ARM: www.armedslack.org From niels.horn at gmail.com Sat Feb 20 10:23:11 2010 From: niels.horn at gmail.com (Niels Horn) Date: Sat, 20 Feb 2010 08:23:11 -0200 Subject: [ARMedslack] Help building poppler In-Reply-To: References: <3f18b2311002200155x1c0e4cd3m8918aa0e58bd476f@mail.gmail.com> Message-ID: <3f18b2311002200223w51ee1808jd04e09470c9e2f86@mail.gmail.com> On Sat, Feb 20, 2010 at 8:09 AM, Stuart Winter wrote: >> The really fun part is, that after recompiling qt, poppler will >> compile fine, but everything else that uses the function needs to be >> recompiled as well :) And that might include several parts of KDE... > > Pat knows the KDE in non public -current is broken because of the libpng > update; I *think* KDE is planned to be upgraded. > > -- > Stuart Winter > Slackware ARM: www.armedslack.org > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > About those warnings... It is good that they appear for those of us who like to compile their own packages. Whenever one of those pops up, it's a good idea to check what it links to or what links to it, because if the other part of the link had not been recompiled yet, the link is broken. In the end, after recompiling everything that uses 'va_list', the problem will cease to exist... At least, until the next new feature of gcc ;) Niels From mr.spuratic at gmail.com Sun Feb 21 23:24:07 2010 From: mr.spuratic at gmail.com (Conor McCarthy) Date: Sun, 21 Feb 2010 23:24:07 +0000 Subject: [ARMedslack] Missing files in "uinitrd-kirkwood" to support root file-system on SDHC card In-Reply-To: References: <48f5f5611002171739s18ae74efwedde1cabd1097a8f@mail.gmail.com> Message-ID: <48f5f5611002211524v35f71f7cq92ed7eee3f94fba7@mail.gmail.com> 2010/2/18 C?dric VINCENT : [...] > > Please, let me know if you are using specific mount options for your > MMC partitions. For instance, I use an ext2 FS with the options > "noatime" and "async" to reduce as much as possible write cycles. I have added "noatime", "async" is the default with ext2 AFAIK, no harm being explicit of course. There's also "nodiratime", though I'm not entirely sure under what circumstances a directory atime is updated. Things I have done/will play with, once I've finished breaking things: - demote ext3 to ext2 (turn off journal, done, see ext3 FAQ) - relocate /var/run /var/tmp /tmp as tmpfs/ramfs - /var/man/cat* -- fix man page cache - relocate /var/cache/samba if using samba (tmpfs maybe) - keep (re)reading http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/ until I can decide if there's anything I need to do :) - ditto for Documentation/sysctl/vm.txt, maybe dropping the flush timeouts like dirty_writeback_centisecs and dirty_expire_centisecs Other useful things to reduce disk writes: - fix syslogd "MARK" (add "-m 0" to syslogd args in /etc/rc.d/rc.syslog) - move update/slocate db location (/var/lib/slocate) and/or set to run weekly, not daily The system is used for home LAN media/file storage, and will be used for light web/email soon. I have an external bus-powered USB disk (Toshiba PX1399E 500GB 2.5", works perfectly with the sheevaplug). I'd like the system to run without the disk, though generally it will be attached, so I may end up doing something "interesting" with the syslog setup. I'm hoping that day-to-day writes to SD will be 0. Regards, Conor. From niels.horn at gmail.com Mon Feb 22 00:04:33 2010 From: niels.horn at gmail.com (Niels Horn) Date: Sun, 21 Feb 2010 22:04:33 -0200 Subject: [ARMedslack] Missing files in "uinitrd-kirkwood" to support root file-system on SDHC card In-Reply-To: <48f5f5611002211524v35f71f7cq92ed7eee3f94fba7@mail.gmail.com> References: <48f5f5611002171739s18ae74efwedde1cabd1097a8f@mail.gmail.com> <48f5f5611002211524v35f71f7cq92ed7eee3f94fba7@mail.gmail.com> Message-ID: <3f18b2311002211604w30c56f41t94e266379f0e4f98@mail.gmail.com> On Sun, Feb 21, 2010 at 9:24 PM, Conor McCarthy wrote: > 2010/2/18 C?dric VINCENT : > [...] >> >> Please, let me know if you are using specific mount options for your >> MMC partitions. For instance, I use an ext2 FS with the options >> "noatime" and "async" to reduce as much as possible write cycles. > > I have added "noatime", "async" is the default with ext2 AFAIK, no > harm being explicit of course. There's also "nodiratime", though I'm > not entirely sure under what circumstances a directory atime is > updated. > > Things I have done/will play with, once I've finished breaking things: > - demote ext3 to ext2 (turn off journal, done, see ext3 FAQ) > - relocate /var/run /var/tmp /tmp as tmpfs/ramfs > - /var/man/cat* -- fix man page cache > - relocate /var/cache/samba if using samba (tmpfs maybe) > - keep (re)reading > ?http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/ > ?until I can decide if there's anything I need to do :) > - ditto for Documentation/sysctl/vm.txt, maybe dropping the flush > ?timeouts like dirty_writeback_centisecs and dirty_expire_centisecs > > Other useful things to reduce disk writes: > - fix syslogd "MARK" (add "-m 0" to syslogd args in /etc/rc.d/rc.syslog) > - move update/slocate db location (/var/lib/slocate) and/or set to run > ?weekly, not daily > > The system is used for home LAN media/file storage, and will be used > for light web/email soon. I have an external bus-powered USB disk > (Toshiba PX1399E 500GB 2.5", works perfectly with the sheevaplug). > I'd like the system to run without the disk, though generally it will be > attached, so I may end up doing something "interesting" with the > syslog setup. I'm hoping that day-to-day writes to SD will be 0. > > Regards, > ?Conor. > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > Conor, Good suggestions. I've been running OS's (mostly Slackware) on a bootable pendrive and tried to minimize write operations. Most things you mentioned I did before, but some are new (like the man page cache, syslogd "mark"). I plan on buying a USB drive before my SheevaPlug arrives, but for some setups running it from an SD card can be very interesting. Please keep me informed on your progress! Niels From cedric.vincent at gmail.com Mon Feb 22 09:02:58 2010 From: cedric.vincent at gmail.com (=?UTF-8?Q?C=C3=A9dric_VINCENT?=) Date: Mon, 22 Feb 2010 10:02:58 +0100 Subject: [ARMedslack] Missing files in "uinitrd-kirkwood" to support root file-system on SDHC card In-Reply-To: <48f5f5611002211524v35f71f7cq92ed7eee3f94fba7@mail.gmail.com> References: <48f5f5611002171739s18ae74efwedde1cabd1097a8f@mail.gmail.com> <48f5f5611002211524v35f71f7cq92ed7eee3f94fba7@mail.gmail.com> Message-ID: On Mon, Feb 22, 2010 at 12:24 AM, Conor McCarthy wrote: > There's also "nodiratime", though I'm not entirely sure under what > circumstances a directory atime is updated. By the way "noatime" implies "nodiratime". > Things I have done/will play with, once I've finished breaking things: > [...] Thank you so much! I add all these items to my TODO list ;) > I'm hoping that day-to-day writes to SD will be 0. Do you think it would be finally possible to mount the root file-system *read-only*?