From m-lists at biscuit.org.uk Thu Oct 1 08:24:15 2009 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Thu, 1 Oct 2009 09:24:15 +0100 (BST) Subject: [ARMedslack] Freerunner In-Reply-To: <801756.66698.qm@web52402.mail.re2.yahoo.com> References: <801756.66698.qm@web52402.mail.re2.yahoo.com> Message-ID: Hi > i might have already asked this,,,???? is there a chance that SlackARM? > will run on the openmoko freerunner? The Slackware ARM packages user land packages, in the main, will be fine on the system - although perhaps may require some additional tweaking. I think the majority of work would be the installation and resolving all of the requirements and parameters required to boot the system. I have had a brief look through: http://wiki.debian.org/DebianOnFreeRunner If somebody is interested in making an out of box experience, including installation documentation, then let me know. From linuxxr at yahoo.com Thu Oct 1 14:57:21 2009 From: linuxxr at yahoo.com (brian kelley) Date: Thu, 1 Oct 2009 07:57:21 -0700 (PDT) Subject: [ARMedslack] Freerunner In-Reply-To: Message-ID: <273587.95514.qm@web52407.mail.re2.yahoo.com> thanks Stuart????????? !!!! --- On Thu, 10/1/09, Stuart Winter wrote: From: Stuart Winter Subject: [ARMedslack] Freerunner To: "Slackware ARM port" Date: Thursday, October 1, 2009, 3:24 AM Hi > i might have already asked this,,,???? is there a chance that SlackARM? > will run on the openmoko freerunner? The Slackware ARM packages user land packages, in the main, will be fine on the system - although perhaps may require some additional tweaking. I think the majority of work would be the installation and resolving all of the requirements and parameters required to boot the system. I have had a brief look through: http://wiki.debian.org/DebianOnFreeRunner If somebody is interested in making an out of box experience, including installation documentation, then let me know. -----Inline Attachment Follows----- _______________________________________________ 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 Oct 1 15:36:42 2009 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Thu, 1 Oct 2009 16:36:42 +0100 (BST) Subject: [ARMedslack] Freerunner In-Reply-To: <273587.95514.qm@web52407.mail.re2.yahoo.com> References: <273587.95514.qm@web52407.mail.re2.yahoo.com> Message-ID: On Thu, 1 Oct 2009, brian kelley wrote: > thanks Stuart????????? !!!! Are you volunteering? :-) From linuxxr at yahoo.com Thu Oct 1 16:16:40 2009 From: linuxxr at yahoo.com (brian kelley) Date: Thu, 1 Oct 2009 09:16:40 -0700 (PDT) Subject: [ARMedslack] Freerunner In-Reply-To: Message-ID: <423803.44521.qm@web52401.mail.re2.yahoo.com> i would love to?? but my skills are lacking --- On Thu, 10/1/09, Stuart Winter wrote: From: Stuart Winter Subject: Re: [ARMedslack] Freerunner To: "Slackware ARM port" Date: Thursday, October 1, 2009, 10:36 AM On Thu, 1 Oct 2009, brian kelley wrote: > thanks Stuart????????? !!!! Are you volunteering? :-) -----Inline Attachment Follows----- _______________________________________________ ARMedslack mailing list ARMedslack at lists.armedslack.org http://lists.armedslack.org/mailman/listinfo/armedslack -------------- next part -------------- An HTML attachment was scrubbed... URL: From linuxxr at yahoo.com Thu Oct 1 16:18:01 2009 From: linuxxr at yahoo.com (brian kelley) Date: Thu, 1 Oct 2009 09:18:01 -0700 (PDT) Subject: [ARMedslack] Freerunner In-Reply-To: Message-ID: <826060.17598.qm@web52411.mail.re2.yahoo.com> i have trouble? with basic linux skills because i know nothing --- On Thu, 10/1/09, Stuart Winter wrote: From: Stuart Winter Subject: Re: [ARMedslack] Freerunner To: "Slackware ARM port" Date: Thursday, October 1, 2009, 10:36 AM On Thu, 1 Oct 2009, brian kelley wrote: > thanks Stuart????????? !!!! Are you volunteering? :-) -----Inline Attachment Follows----- _______________________________________________ ARMedslack mailing list ARMedslack at lists.armedslack.org http://lists.armedslack.org/mailman/listinfo/armedslack -------------- next part -------------- An HTML attachment was scrubbed... URL: From dermoth at aei.ca Thu Oct 8 23:26:45 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Thu, 08 Oct 2009 19:26:45 -0400 Subject: [ARMedslack] Question/suggestions regarding ARMedslack Message-ID: <4ACE7535.9090502@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I just joined this mailing list as I was looking at building cheap enterprise-grade VPN devices out of SheevaPlugs (implementing HA, Atateful failovers, Firewall, QoS on a single vlan-tagged interface). Being a long-time Slackware user ARMedslack was obviously the 1st distro I looked at for this project (there's also ?ngstr?m that looks nice... for it). First of all looking at the -current branch it appears the latest kernel used is 2.6.31.1. Is there any plan at using the 2.6.32 kernel for the next release, even though it's still in -rc stage ATM? Looking at it it seems it has a few patches for Kirkwood, most importantly (at least for me) hardware crypto support which is probably a good ides to have for a VPN (also useful when using crypto disks which seems even more popular..). I sure can compile it but but I though maybe it could be considered a showstopper for the 13.0 release since this port hasn't released it yet... Secondly, trough the documentation it appears the packages get compiled in a SheevaPlug or in Qemu (I don't have any plug in my hands yet). I would feel much more comfortable using a cross-compile environment - I used to run one from a PowerPC (YDL) for my OpenWRT router and it was pretty nice. If there's no documentation specific to ARMEdslack I will build one as I'd like to create images from my dev platform (x86) and use them straight in Qemu/Sheeva (I'll probably hack the installer too...). Also it looks like the kernel support UBIFS but there's no instructions for using it. IMHO it should not only be documented but also the recommended filesystem as it is much better in many technical aspects. I would help testing it but I don't have the HW yet :(... Even my first Qemu installation is a bit rough - I ven't managed to run the setup successfully yet (it skipped the "A" section, and segfaulted on the 2nd try) evn though I used the latest version - the host is a bit old though; slack 11.0. PS: Could the mailing list be linked to from the main ARMedslack page? I'm not sure if I missed something but I had to do a Google search to find it. Thanks - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKznU16dZ+Kt5BchYRAuBlAKCZb68qV/VAZbmUUid4zYkSQqF6pgCgxY63 fStdsHjxJVkXDlBsVelgJi8= =Qdxn -----END PGP SIGNATURE----- From m-lists at biscuit.org.uk Fri Oct 9 08:22:37 2009 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Fri, 9 Oct 2009 09:22:37 +0100 (BST) Subject: [ARMedslack] Question/suggestions regarding ARMedslack In-Reply-To: <4ACE7535.9090502@aei.ca> References: <4ACE7535.9090502@aei.ca> Message-ID: Hi Thomas > enterprise-grade VPN devices out of SheevaPlugs (implementing HA, > Atateful failovers, Firewall, QoS on a single vlan-tagged interface). Cool. Have you looked at the OpenRD which has 2Gbit interfaces? They're more expensive than the SheevaPlug and the kernel support isn't finished yet, but I plan to make ARMedslack installable on that too. > used is 2.6.31.1. Is there any plan at using the 2.6.32 kernel for the > next release, There won't be a Slackware ARM 13.0 release because the EABI port is too new and untested -- I only completed it last month; whilst it's been totally stable for me during development, I expect there to be problems I don't yet know about. Slackware 13.1 may be the next release if I think it's stable enough by that time. For the time being, Slackware ARM -current will keep in sync with Intel -current. Slackware ARM usually has the latest stable kernel though, which usually isn't in sync with Slackware x86 because as you say, the newer Kernels usually contain ARM fixes. > would feel much more comfortable using a cross-compile environment - I > used to run one from a PowerPC (YDL) for my OpenWRT router and it was > pretty nice. If there's no documentation specific to ARMEdslack I will > build one as I'd like to create images from my dev platform (x86) and > use them straight in Qemu/Sheeva (I'll probably hack the installer too...). I'm not sure what you mean here. Why would you need to do anything to the installer? The installer is not related to any compilation environment. ARMedslack's packages are compiled on a SheevaPlug (or what ever machine is free which is the correct release and has the most up to date installation), and using distcc is sent to a cluster of x86 machines running a cross compiler that has the identical versions of glibc, binutils and gcc as the Slackware ARM host. So I get the benefits of having fast compilation times and having the packages work correctly. If you're building an entire OS, cross compiling really isn't much fun because many packages' build systems aren't made to cross compile so you'd have to modify them. The best part is when the Makefile tries to execute a binary just compiled in order to process some data -- an example of which is ncurses. This is why the first ARMedslack was built inside of "Scratchbox" - www.scratchbox.org I don't know of any distribution apart from Emdebian, which does not build their packages natively. > Also it looks like the kernel support UBIFS but there's no instructions > for using it. IMHO it should not only be documented but also the > recommended filesystem as it is much better in many technical aspects. You're talking about installation of the OS onto the NAND flash on the SheevaPlug? I don't know how to support that for a couple of reasons: 1. I didn't spend enough time looking 2. The NAND on the SheevaPlug is 512MB in size which isn't enough to put a full installation of Slackware (~4GB) on to. A full installation is the recommended way to install Slackware. Therefore I'd have to maintain a list of packages of a slimmed down installation. If somebody wanted to maintain a list of packages that could fit inside 512MB and still leave enough space for the running system, then the "tag files" could be added to the installer image and presented as an installation option. I'd *like* to be able to do it because I believe it'd be useful but I don't have time to maintain it. > PS: Could the mailing list be linked to from the main ARMedslack page? > I'm not sure if I missed something but I had to do a Google search to > find it. It is on the front page of www.armedslack.org. -- Stuart Winter Slackware ARM: www.armedslack.org From dermoth at aei.ca Fri Oct 9 11:23:04 2009 From: dermoth at aei.ca (Thomas Guyot-Sionnest) Date: Fri, 09 Oct 2009 07:23:04 -0400 Subject: [ARMedslack] Question/suggestions regarding ARMedslack In-Reply-To: References: <4ACE7535.9090502@aei.ca> Message-ID: <4ACF1D18.1080508@aei.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/10/09 04:22 AM, Stuart Winter wrote: > Hi Thomas > >> enterprise-grade VPN devices out of SheevaPlugs (implementing HA, >> Atateful failovers, Firewall, QoS on a single vlan-tagged interface). > > Cool. Have you looked at the OpenRD which has 2Gbit interfaces? > They're more expensive than the SheevaPlug and the kernel support isn't > finished yet, but I plan to make ARMedslack installable on that too. Yeah, the client version + case is $300; that's pretty expensive compared to the $99 Sheevaplug which has a target retail price of $40-$60! Besides, I'd use a second Gbit port and a RS232 one but I don't need all those USB, [e]SATA, VGA & other ports! If I want a serial port for HA I can use a cheap usb dongle too... >> would feel much more comfortable using a cross-compile environment - I >> used to run one from a PowerPC (YDL) for my OpenWRT router and it was >> pretty nice. If there's no documentation specific to ARMEdslack I will >> build one as I'd like to create images from my dev platform (x86) and >> use them straight in Qemu/Sheeva (I'll probably hack the installer too...). > > I'm not sure what you mean here. Why would you need to do anything to the > installer? The installer is not related to any compilation environment. The idea is to build usable images straight from the build computer (x86). If there's anything build into the installer to automate the proces I'll use that (I'm not talking about tagfiles but rather all the rest). > ARMedslack's packages are compiled on a SheevaPlug (or what ever machine > is free which is the correct release and has the most up to date > installation), and using distcc is sent to a cluster of x86 machines > running a cross compiler that has the identical versions of glibc, > binutils and gcc as the Slackware ARM host. So I get the benefits of > having fast compilation times and having the packages work correctly. > > If you're building an entire OS, cross compiling really isn't much fun > because many packages' build systems aren't made to cross compile so you'd > have to modify them. The best part is when the Makefile tries to execute > a binary just compiled in order to process some data -- an example of > which is ncurses. This is why the first ARMedslack was built inside of > "Scratchbox" - www.scratchbox.org Oh... Yeah.. Openwrt is pretty basic (fits in like <1MB MTD partition!!), obviously there's no ncurses! ;) distcc is a very nice solution - I haven't though of it :) > I don't know of any distribution apart from Emdebian, which does not build > their packages natively. ?ngstr?m, and any distribution based on OpenEmbedded. http://www.angstrom-distribution.org/ >> Also it looks like the kernel support UBIFS but there's no instructions >> for using it. IMHO it should not only be documented but also the >> recommended filesystem as it is much better in many technical aspects. > > You're talking about installation of the OS onto the NAND flash on the > SheevaPlug? I don't know how to support that for a couple of reasons: > 1. I didn't spend enough time looking > 2. The NAND on the SheevaPlug is 512MB in size which isn't enough to > put a full installation of Slackware (~4GB) on to. A full > installation is the recommended way to install Slackware. > Therefore I'd have to maintain a list of packages of a slimmed > down installation. I strip down my installs all the time - who needs a GUI on a server? ;) I have my default set of tagfiles for that purpose... > If somebody wanted to maintain a list of packages that could fit inside > 512MB and still leave enough space for the running system, then the "tag > files" could be added to the installer image and presented as an > installation option. I can do that, just not right now though. > I'd *like* to be able to do it because I believe it'd be useful > but I don't have time to maintain it. Once it's done it's pretty easy to maintain - you just have to follow packages removal, addition & splits and make sure it still fits. >> PS: Could the mailing list be linked to from the main ARMedslack page? >> I'm not sure if I missed something but I had to do a Google search to >> find it. > > It is on the front page of www.armedslack.org. Oh.. Just found the tiny section :). I'm not a web designer but I believe it could help is there was links (to page anchors) on the side or on the top... Thanks - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKzx0Y6dZ+Kt5BchYRAnUDAJ9H9GC08gQsd9nt/HFwdE2pphmluACg0pIW pY6O0LMRw7MkbsxpHNad5Vo= =W70X -----END PGP SIGNATURE----- From m-lists at biscuit.org.uk Fri Oct 9 11:56:47 2009 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Fri, 9 Oct 2009 12:56:47 +0100 (BST) Subject: [ARMedslack] Question/suggestions regarding ARMedslack In-Reply-To: <4ACF1D18.1080508@aei.ca> References: <4ACE7535.9090502@aei.ca> <4ACF1D18.1080508@aei.ca> Message-ID: > Yeah, the client version + case is $300; that's pretty expensive > compared to the $99 Sheevaplug which has a target retail price of > $40-$60! Besides, I'd use a second Gbit port and a RS232 one but I don't > need all those USB, [e]SATA, VGA & other ports! If I want a serial port > for HA I can use a cheap usb dongle too... Agreed. I didn't know the SP retail price was so low!! If they drop in price more, I might buy another one. I have 2 already, and open OpenRD. > > installer? The installer is not related to any compilation environment. > > The idea is to build usable images straight from the build computer > (x86). If there's anything build into the installer to automate the > proces I'll use that (I'm not talking about tagfiles but rather all the > rest). Aah right I understand, I think. You want to prepare stock images that can be written to the SheevaPlug NAND flash so you can roll out your product. The Slackware installer doesn't support what you want to do -- we did start a project but none of the team have time to do it and do it well. What you could do is: ftp://ftp.armedslack.org/armedslack/armedslack-devtools/slackkit/sansinstaller Look at that script, and produce your own tag files for each package series ("a", "ap" and so on); and call installpkg with -tagfile. I'd guess that for the majority of packages you'd be installing for your purpose, you'd not run into many problems doing this process on the x86. The only problems I know of are when the package's post install scripts run the ARM binaries to update a system config file, or make an initial database or something. But what you could do if this *is* a problem, is install ARMedslack onto a USB disc as the instructions say, and run the process on there, producing a UBIFS image. Then you can re-use the UBIFS image. I'm guessing this is the sort of thing you want to do? > distcc is a very nice solution - I haven't though of it :) Yeah, I still build ARMedslack 12.2's security fixes without distcc since the cluster is setup for -current; distcc is a life saver. This is how my cross compile toolchain is: ftp://ftp.armedslack.org/armedslack/armedslack-devtools/x-toolchain/ then you just need to setup the environment inside ARMedslack to use distcc. > > It is on the front page of www.armedslack.org. > > Oh.. Just found the tiny section :). I'm not a web designer but I > believe it could help is there was links (to page anchors) on the side > or on the top... Someone else made that single page about 8 years ago. I'm not a designer either. I was tempted to replace the site with a .txt file ;-) From linuxxr at yahoo.com Fri Oct 9 17:41:23 2009 From: linuxxr at yahoo.com (brian kelley) Date: Fri, 9 Oct 2009 10:41:23 -0700 (PDT) Subject: [ARMedslack] Question/suggestions regarding ARMedslack In-Reply-To: Message-ID: <694398.36618.qm@web52401.mail.re2.yahoo.com> i think the openmoko freerunner is what u need to develop on:) --- On Fri, 10/9/09, Stuart Winter wrote: From: Stuart Winter Subject: Re: [ARMedslack] Question/suggestions regarding ARMedslack To: "Slackware ARM port" Date: Friday, October 9, 2009, 3:22 AM Hi Thomas > enterprise-grade VPN devices out of SheevaPlugs (implementing HA, > Atateful failovers, Firewall, QoS on a single vlan-tagged interface). Cool.? Have you looked at the OpenRD which has 2Gbit interfaces? They're more expensive than the SheevaPlug and the kernel support isn't finished yet, but I plan to make ARMedslack installable on that too. > used is 2.6.31.1. Is there any plan at using the 2.6.32 kernel for the > next release, There won't be a Slackware ARM 13.0 release because the EABI port is too new and untested -- I only completed it last month; whilst it's been totally stable for me during development, I expect there to be problems I don't yet know about. Slackware 13.1 may be the next release if I think it's stable enough by that time.? For the time being, Slackware ARM -current will keep in sync with Intel -current. Slackware ARM usually has the latest stable kernel though, which usually isn't in sync with Slackware x86 because as you say, the newer Kernels usually contain ARM fixes. > would feel much more comfortable using a cross-compile environment - I > used to run one from a PowerPC (YDL) for my OpenWRT router and it was > pretty nice. If there's no documentation specific to ARMEdslack I will > build one as I'd like to create images from my dev platform (x86) and > use them straight in Qemu/Sheeva (I'll probably hack the installer too...). I'm not sure what you mean here.? Why would you need to do anything to the installer?? The installer is not related to any compilation environment. ARMedslack's packages are compiled on a SheevaPlug (or what ever machine is free which is the correct release and has the most up to date installation), and using distcc is sent to a cluster of x86 machines running a cross compiler that has the identical versions of glibc, binutils and gcc as the Slackware ARM host.? So I get the benefits of having fast compilation times and having the packages work correctly. If you're building an entire OS, cross compiling really isn't much fun because many packages' build systems aren't made to cross compile so you'd have to modify them.? The best part is when the Makefile tries to execute a binary just compiled in order to process some data -- an example of which is ncurses.? This is why the first ARMedslack was built inside of "Scratchbox" - www.scratchbox.org I don't know of any distribution apart from Emdebian, which does not build their packages natively. > Also it looks like the kernel support UBIFS but there's no instructions > for using it. IMHO it should not only be documented but also the > recommended filesystem as it is much better in many technical aspects. You're talking about installation of the OS onto the NAND flash on the SheevaPlug?? I don't know how to support that for a couple of reasons: 1. I didn't spend enough time looking 2. The NAND on the SheevaPlug is 512MB in size which isn't enough to ? ? put a full installation of Slackware (~4GB) on to.? A full ? ? installation is the recommended way to install Slackware. ? ? Therefore I'd have to maintain a list of packages of a slimmed ? ? down installation. If somebody wanted to maintain a list of packages that could fit inside 512MB and still leave enough space for the running system, then the "tag files" could be added to the installer image and presented as an installation option. I'd *like* to be able to do it because I believe it'd be useful but I don't have time to maintain it. > PS: Could the mailing list be linked to from the main ARMedslack page? > I'm not sure if I missed something but I had to do a Google search to > find it. It is on the front page of www.armedslack.org. -- 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: