From m-lists at biscuit.org.uk Sun May 1 06:19:55 2011 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sun, 1 May 2011 07:19:55 +0100 (BST) Subject: [ARMedslack] Slackware ARM on Small NAS (NS-K330) In-Reply-To: <510150.81618.qm@web29719.mail.ird.yahoo.com> References: <510150.81618.qm@web29719.mail.ird.yahoo.com> Message-ID: ftp://ftp.armedslack.org/armedslack/armedslack-current/source/README_SOURCE.txt Read that and download the slackware64-current tree (including sources) cd armedslack-current/source/l/glibc sed -i 's?armv4t?armv5te?g' glibc.SlackBuild Change the BUILD number in the arm/build script to whatever - increase it or make it your own stamp - eg 4_davide Start the build (under screen would be better incase your host machine dies!) On a sheevaplug the build takes about a day to build natively: ./arm/build Then your packages will appear in the armedslack-current/slackware/{a,l} directories. > I wanted to get all I can out of my dockstar if it works well I might even do that on my zauruses (C 760/860/1000). > The zauri should all be ARMv5 as husky boxer are PXA255 and Akita is PXA270. > While the dockstar I'm not sure but I think it's ARMv5 too. > > It would be the first time I look into rebuilding glibc in order to get better performance and actually I don't recall ever doing it at all so if I did I just followed the build scripts to build it. Any help is appreciated for this task. > > Regards > David > > > I think it has but I don't recall anybody having done it. > > > > What hardware? > > > > I'm quite interested in it because I'm still thinking about > > building > > armedslack for armv5te (it's armv4 at the moment). > > We need some valid test cases. > > > > On Sat, 30 Apr 2011, Davide wrote: > > > > > I'm interested in the recompiling glibc thing to > > regain speed on specific hardware: has this been discussed > > in the ML previously ? > > > > > > --- Gio 21/4/11, Stuart Winter > > ha scritto: > > > > > > > Da: Stuart Winter > > > > Oggetto: Re: [ARMedslack] Slackware ARM on Small > > NAS (NS-K330) > > > > A: "Slackware ARM port" > > > > Data: Gioved? 21 Aprile 2011, 17:49 > > > > > > > > > I don't know, but I don't think you'll be > > happy with > > > > it regardless. > > > > > The transfer speeds are going to be terribly > > slow - > > > > bottlenecking > > > > > due to the usb2 speeds *and* the general > > wimpiness of > > > > the hardware. > > > > > > > > Yeah having built the distribution on 287MHZ > > RiscPCs for a > > > > couple of years > > > > with 256MB RAM... I don't know how I kept > > going.? I > > > > guess because there > > > > wasn't any better or faster supported arm > > hardware at the > > > > time, so I > > > > didn't have anything to wish I could have ;-) > > > > > > > > I wouldn't bother with it. Some devices use lower > > speed ARM > > > > CPUs but their > > > > usage (and software) is tuned to the device to > > match the > > > > usage with the > > > > device's specs.? Slackware ARM is a generic > > > > distribution built to run > > > > on the widest range of products possible, at the > > expense of > > > > speed in some > > > > areas (which IMO can easily be re-gained by > > recompiling > > > > glibc and some > > > > other critical libraries; but that's another > > topic :) ). > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > -- > > Stuart Winter > > Slackware ARM: www.armedslack.org > > -----Segue allegato----- > > > > _______________________________________________ > > 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 > -- Stuart Winter Slackware ARM: www.armedslack.org From unixjohn1969 at gmail.com Sun May 1 08:17:30 2011 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Sun, 01 May 2011 04:17:30 -0400 Subject: [ARMedslack] Slackware ARM on Small NAS (NS-K330) In-Reply-To: References: <510150.81618.qm@web29719.mail.ird.yahoo.com> Message-ID: <4DBD171A.9060908@gmail.com> On 05/01/2011 02:19 AM, Stuart Winter wrote: > > ftp://ftp.armedslack.org/armedslack/armedslack-current/source/README_SOURCE.txt > Read that and download the slackware64-current tree (including sources) > > cd armedslack-current/source/l/glibc > sed -i 's?armv4t?armv5te?g' glibc.SlackBuild I have been actively doing this with alot of the libs and currently gcc and adding PKGARCH to scripts that dont have it and building armv5te packages. Once I get to re-build the libs and gcc with armv5te binaries (another day or so) I will tackle the rest of the basics, then run some benchmarks. Not sure if anything will jump out or if it will be the same... But I'm bored ;-) And I have 4 plugs chugging away at this. I love distcc! I'll let you know what comes of it. John -- === Never ask a geek why, just nod your head and slowly back away.=== +================================+==================================+ | John O'Donnell | | | (Sr. Systems Engineer, | http://juanisan.homeip.net | | Net Admin, Programmer, etc.) | E-Mail: unixjohn1969 at gmail.com | +================================+==================================+ No man is useless who has a friend, and if we are loved we are indispensable. -- Robert Louis Stevenson From mozes at slackware.com Sun May 1 12:22:24 2011 From: mozes at slackware.com (Stuart Winter) Date: Sun, 1 May 2011 05:22:24 -0700 (PDT) Subject: [ARMedslack] Slackware 13.37 ARM relesed! Message-ID: Hi! Slackware 13.37 ARM has been released today! Thanks for all of your help on here (and IRC) - much appreciated! All of the information required to install and downoad is linked off the web site: www.armedslack.org Cheers! s. -- Stuart Winter www.slackware.com/~mozes Slackware for ARM: www.armedslack.org From unixjohn1969 at gmail.com Sun May 1 12:59:09 2011 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Sun, 01 May 2011 08:59:09 -0400 Subject: [ARMedslack] Slackware 13.37 ARM relesed! In-Reply-To: References: Message-ID: <4DBD591D.5080507@gmail.com> On 05/01/2011 08:22 AM, Stuart Winter wrote: > > Hi! > > Slackware 13.37 ARM has been released today! HOOORAY! -- === Never ask a geek why, just nod your head and slowly back away.=== +================================+==================================+ | John O'Donnell | | | (Sr. Systems Engineer, | http://juanisan.homeip.net | | Net Admin, Programmer, etc.) | E-Mail: unixjohn1969 at gmail.com | +================================+==================================+ No man is useless who has a friend, and if we are loved we are indispensable. -- Robert Louis Stevenson From pino.otto at gmail.com Sun May 1 13:03:31 2011 From: pino.otto at gmail.com (Giovanni) Date: Sun, 1 May 2011 15:03:31 +0200 Subject: [ARMedslack] Slackware 13.37 ARM relesed! In-Reply-To: <4DBD591D.5080507@gmail.com> References: <4DBD591D.5080507@gmail.com> Message-ID: Congratulations! alien jo On Sun, May 1, 2011 at 2:59 PM, John O'Donnell wrote: > On 05/01/2011 08:22 AM, Stuart Winter wrote: > >> >> Hi! >> >> Slackware 13.37 ARM has been released today! >> > > HOOORAY! > > -- > === Never ask a geek why, just nod your head and slowly back away.=== > +================================+==================================+ > | John O'Donnell | | > | (Sr. Systems Engineer, | http://juanisan.homeip.net | > | Net Admin, Programmer, etc.) | E-Mail: unixjohn1969 at gmail.com | > +================================+==================================+ > No man is useless who has a friend, and if we are loved we are > indispensable. -- Robert Louis Stevenson > > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > -------------- next part -------------- An HTML attachment was scrubbed... URL: From louigi600 at yahoo.it Sun May 1 15:51:08 2011 From: louigi600 at yahoo.it (Davide) Date: Sun, 1 May 2011 16:51:08 +0100 (BST) Subject: [ARMedslack] Slackware ARM on Small NAS (NS-K330) In-Reply-To: Message-ID: <79975.32014.qm@web29701.mail.ird.yahoo.com> > ftp://ftp.armedslack.org/armedslack/armedslack-current/source/README_SOURCE.txt > Read that and download the slackware64-current tree > (including sources) What's the difference between ftp://ftp.slackware.com/pub/slackware/slackware64-current/source and ftp://ftp.slackware.org.uk/armedslack/armedslack-current/source/ Is it "Slackware ARM only includes the sources in situations when .... " ? At the time I worked on something I liked to call slackurus I had a different approach: I used to fix the slackbuild scripts so that I could use them for building binaries for zaurus by cross compilation and I had my own overlall build script that looked for packages to build and built them. But at that time either armedslack was not around or I did not know about it ... way back in 2004 ... well also many other things might have changed ;-) > cd armedslack-current/source/l/glibc > sed -i 's?armv4t?armv5te?g' glibc.SlackBuild Ok that will change just one thing in that buildscript: -march=armv4t to -march=armv5te > Change the BUILD number in the arm/build script to whatever > - increase it > or make it your own stamp - eg 4_davide > > Start the build (under screen would be better incase your > host machine > dies!) > > On a sheevaplug the build takes about a day to build > natively: > > ./arm/build > > Then your packages will appear in the > armedslack-current/slackware/{a,l} > directories. Will this build everiting ? Can I just rebuild glibc or is it necessary to rebuild every binary that links the new glibc ? I was hoping that since version will not be changing maybe I could do with just slipping in the new armv5 tuned glibc: am I wrong in hoping this ? > > I wanted to get all I can out of my dockstar if it > works well I might even do that on my zauruses (C > 760/860/1000). > > The zauri should all be ARMv5 as husky boxer are > PXA255 and Akita is PXA270. > > While the dockstar I'm not sure but I think it's ARMv5 > too. > > > > It would be the first time I look into rebuilding > glibc in order to get better performance and actually I > don't recall ever doing it at all so if I did I just > followed the build scripts to build it. Any help is > appreciated for this task. > > > > Regards > > David > > > > > I think it has but I don't recall anybody having > done it. > > > > > > What hardware? > > > > > > I'm quite interested in it because I'm still > thinking about > > > building > > > armedslack for armv5te (it's armv4 at the > moment). > > > We need some valid test cases. > > > > > > On Sat, 30 Apr 2011, Davide wrote: > > > > > > > I'm interested in the recompiling glibc > thing to > > > regain speed on specific hardware: has this been > discussed > > > in the ML previously ? > > > > > > > > --- Gio 21/4/11, Stuart Winter > > > ha scritto: > > > > > > > > > Da: Stuart Winter > > > > > Oggetto: Re: [ARMedslack] Slackware ARM > on Small > > > NAS (NS-K330) > > > > > A: "Slackware ARM port" > > > > > Data: Gioved? 21 Aprile 2011, 17:49 > > > > > > > > > > > I don't know, but I don't think > you'll be > > > happy with > > > > > it regardless. > > > > > > The transfer speeds are going to > be terribly > > > slow - > > > > > bottlenecking > > > > > > due to the usb2 speeds *and* the > general > > > wimpiness of > > > > > the hardware. > > > > > > > > > > Yeah having built the distribution on > 287MHZ > > > RiscPCs for a > > > > > couple of years > > > > > with 256MB RAM... I don't know how I > kept > > > going.? I > > > > > guess because there > > > > > wasn't any better or faster supported > arm > > > hardware at the > > > > > time, so I > > > > > didn't have anything to wish I could > have ;-) > > > > > > > > > > I wouldn't bother with it. Some devices > use lower > > > speed ARM > > > > > CPUs but their > > > > > usage (and software) is tuned to the > device to > > > match the > > > > > usage with the > > > > > device's specs.? Slackware ARM is a > generic > > > > > distribution built to run > > > > > on the widest range of products > possible, at the > > > expense of > > > > > speed in some > > > > > areas (which IMO can easily be > re-gained by > > > recompiling > > > > > glibc and some > > > > > other critical libraries; but that's > another > > > topic :) ). > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > > -- > > > Stuart Winter > > > Slackware ARM: www.armedslack.org > > > -----Segue allegato----- > > > > > > _______________________________________________ > > > 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 > > > > -- > Stuart Winter > Slackware ARM: www.armedslack.org > -----Segue allegato----- > > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > Regards David From louigi600 at yahoo.it Sun May 1 15:52:30 2011 From: louigi600 at yahoo.it (Davide) Date: Sun, 1 May 2011 16:52:30 +0100 (BST) Subject: [ARMedslack] R: Slackware 13.37 ARM relesed! In-Reply-To: Message-ID: <426694.20695.qm@web29712.mail.ird.yahoo.com> Cool ... thanks to all that contributed. David --- Dom 1/5/11, Stuart Winter ha scritto: > Da: Stuart Winter > Oggetto: [ARMedslack] Slackware 13.37 ARM relesed! > A: "Slackware ARM mailing list" > Data: Domenica 1 maggio 2011, 14:22 > > Hi! > > Slackware 13.37 ARM has been released today! > > Thanks for all of your help on here (and IRC) - much > appreciated! > > All of the information required to install and downoad is > linked off > the web site: www.armedslack.org > > > Cheers! > s. > > -- > 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 > From m-lists at biscuit.org.uk Sun May 1 17:33:49 2011 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sun, 1 May 2011 18:33:49 +0100 (BST) Subject: [ARMedslack] Slackware ARM on Small NAS (NS-K330) In-Reply-To: <79975.32014.qm@web29701.mail.ird.yahoo.com> References: <79975.32014.qm@web29701.mail.ird.yahoo.com> Message-ID: > What's the difference between > ftp://ftp.slackware.com/pub/slackware/slackware64-current/source > and > ftp://ftp.slackware.org.uk/armedslack/armedslack-current/source/ > > Is it "Slackware ARM only includes the sources in situations when .... " ? Yes. [mozes at bourbon armedslack-13.37] $ du -sh source/ 513M source/ [mozes at bourbon armedslack-13.37] $ du -sh ../slackware64-current/source/ 2.5G ../slackware64-current/source/ [mozes at bourbon armedslack-13.37] $ Most of the MBs in armedslack's sources are firefox, seamonkey and kernels. > At the time I worked on something I liked to call slackurus I had a > different approach: I used to fix the slackbuild scripts so that I could > use them for building binaries for zaurus by cross compilation and I had > my own overlall build script that looked for packages to build and built > them. But at that time either armedslack was not around or I did not > know about it ... way back in 2004 ... well also many other things might > have changed ;-) The way I did it was based on trial, error and doing my best to do as little as possible to update the packages in order to build them. There are other bits that aren't in the public tree which are used to show the differences in the x86 tree how it is now, and how it was when I last built the package. Updating the source files means two things: - You have to keep copying them - could be scripted, but then what about new patches? what about the old ones? some bits would be scriptable but it's just easier not to. - You then need to spend ages uploading the sources. The way I have done it has worked with minimal effort since 2002 :-) > > armedslack-current/slackware/{a,l} > > directories. > > Will this build everiting ? Can I just rebuild glibc or is it necessary > to rebuild every binary that links the new glibc ? I was hoping that > since version will not be changing maybe I could do with just slipping > in the new armv5 tuned glibc: am I wrong in hoping this ? It'll build glibc - the glibc packages (solibs & zoneinfo) that are in the a/ series, and the main glibc packages (including the header files) in l/ Look in the slackware directories or just read the build script - it's easy to figure it out. You don't need to rebuild everything that links against glibc (ie everything in the entire distribution). You're rebuilding glibc with optimisations - you're not changing the ABI or anything like that! You might want to rebuild bash too. I've got a feeling you should also rebuild zlib. -- Stuart Winter Slackware ARM: www.armedslack.org From louigi600 at yahoo.it Sun May 1 17:45:55 2011 From: louigi600 at yahoo.it (Davide) Date: Sun, 1 May 2011 18:45:55 +0100 (BST) Subject: [ARMedslack] Slackware ARM on Small NAS (NS-K330) In-Reply-To: Message-ID: <224172.36880.qm@web29714.mail.ird.yahoo.com> Forgot to mention another thing: I've put up a qemu environment on a machine running dual core centrino @ 1.83Ghz with 1Gb of ram. I know there's a lot better around but that's what I get at work and my own PC has not been upgraded since 2002 and mu netbook is no better then that too. Would it make sense to compile with a virtual machine under qemu (let's say I can give it some 750Mb of ram) or would it be better to comple directly on the dockstar ? I know there are better ways to do this but for the moment these are my best 2 choices. Regards David > ftp://ftp.armedslack.org/armedslack/armedslack-current/source/README_SOURCE.txt > Read that and download the slackware64-current tree > (including sources) > > cd armedslack-current/source/l/glibc > sed -i 's?armv4t?armv5te?g' glibc.SlackBuild > > Change the BUILD number in the arm/build script to whatever > - increase it > or make it your own stamp - eg 4_davide > > Start the build (under screen would be better incase your > host machine > dies!) > > On a sheevaplug the build takes about a day to build > natively: > > ./arm/build > > Then your packages will appear in the > armedslack-current/slackware/{a,l} > directories. > > > I wanted to get all I can out of my dockstar if it > works well I might even do that on my zauruses (C > 760/860/1000). > > The zauri should all be ARMv5 as husky boxer are > PXA255 and Akita is PXA270. > > While the dockstar I'm not sure but I think it's ARMv5 > too. > > > > It would be the first time I look into rebuilding > glibc in order to get better performance and actually I > don't recall ever doing it at all so if I did I just > followed the build scripts to build it. Any help is > appreciated for this task. > > > > Regards > > David > > > > > I think it has but I don't recall anybody having > done it. > > > > > > What hardware? > > > > > > I'm quite interested in it because I'm still > thinking about > > > building > > > armedslack for armv5te (it's armv4 at the > moment). > > > We need some valid test cases. > > > > > > On Sat, 30 Apr 2011, Davide wrote: > > > > > > > I'm interested in the recompiling glibc > thing to > > > regain speed on specific hardware: has this been > discussed > > > in the ML previously ? > > > > > > > > --- Gio 21/4/11, Stuart Winter > > > ha scritto: > > > > > > > > > Da: Stuart Winter > > > > > Oggetto: Re: [ARMedslack] Slackware ARM > on Small > > > NAS (NS-K330) > > > > > A: "Slackware ARM port" > > > > > Data: Gioved? 21 Aprile 2011, 17:49 > > > > > > > > > > > I don't know, but I don't think > you'll be > > > happy with > > > > > it regardless. > > > > > > The transfer speeds are going to > be terribly > > > slow - > > > > > bottlenecking > > > > > > due to the usb2 speeds *and* the > general > > > wimpiness of > > > > > the hardware. > > > > > > > > > > Yeah having built the distribution on > 287MHZ > > > RiscPCs for a > > > > > couple of years > > > > > with 256MB RAM... I don't know how I > kept > > > going.? I > > > > > guess because there > > > > > wasn't any better or faster supported > arm > > > hardware at the > > > > > time, so I > > > > > didn't have anything to wish I could > have ;-) > > > > > > > > > > I wouldn't bother with it. Some devices > use lower > > > speed ARM > > > > > CPUs but their > > > > > usage (and software) is tuned to the > device to > > > match the > > > > > usage with the > > > > > device's specs.? Slackware ARM is a > generic > > > > > distribution built to run > > > > > on the widest range of products > possible, at the > > > expense of > > > > > speed in some > > > > > areas (which IMO can easily be > re-gained by > > > recompiling > > > > > glibc and some > > > > > other critical libraries; but that's > another > > > topic :) ). > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > > -- > > > Stuart Winter > > > Slackware ARM: www.armedslack.org > > > -----Segue allegato----- > > > > > > _______________________________________________ > > > 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 > > > > -- > Stuart Winter > Slackware ARM: www.armedslack.org > -----Segue allegato----- > > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > From m-lists at biscuit.org.uk Sun May 1 17:59:53 2011 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sun, 1 May 2011 18:59:53 +0100 (BST) Subject: [ARMedslack] Slackware ARM on Small NAS (NS-K330) In-Reply-To: <224172.36880.qm@web29714.mail.ird.yahoo.com> References: <224172.36880.qm@web29714.mail.ird.yahoo.com> Message-ID: QEMU is limited to 256MB RAM for the ARM emulation, and it'll be way slower than a dockstar. On my 3.4GHz PentiumD, QEMU ARM isn't something I'd want to use unless I really had to - which is why I shelled out some more ?? and bought another sheevaplug to maintain 13.37 on! .. and I don't like spending money (unless it's someone else's)! ;-) On Sun, 1 May 2011, Davide wrote: > Forgot to mention another thing: I've put up a qemu environment on a machine running dual core centrino @ 1.83Ghz with 1Gb of ram. > I know there's a lot better around but that's what I get at work and my own PC has not been upgraded since 2002 and mu netbook is no better then that too. > Would it make sense to compile with a virtual machine under qemu (let's say I can give it some 750Mb of ram) or would it be better to comple directly on the dockstar ? > > I know there are better ways to do this but for the moment these are my best 2 choices. > > Regards > David > > > ftp://ftp.armedslack.org/armedslack/armedslack-current/source/README_SOURCE.txt > > Read that and download the slackware64-current tree > > (including sources) > > > > cd armedslack-current/source/l/glibc > > sed -i 's?armv4t?armv5te?g' glibc.SlackBuild > > > > Change the BUILD number in the arm/build script to whatever > > - increase it > > or make it your own stamp - eg 4_davide > > > > Start the build (under screen would be better incase your > > host machine > > dies!) > > > > On a sheevaplug the build takes about a day to build > > natively: > > > > ./arm/build > > > > Then your packages will appear in the > > armedslack-current/slackware/{a,l} > > directories. > > > > > I wanted to get all I can out of my dockstar if it > > works well I might even do that on my zauruses (C > > 760/860/1000). > > > The zauri should all be ARMv5 as husky boxer are > > PXA255 and Akita is PXA270. > > > While the dockstar I'm not sure but I think it's ARMv5 > > too. > > > > > > It would be the first time I look into rebuilding > > glibc in order to get better performance and actually I > > don't recall ever doing it at all so if I did I just > > followed the build scripts to build it. Any help is > > appreciated for this task. > > > > > > Regards > > > David > > > > > > > I think it has but I don't recall anybody having > > done it. > > > > > > > > What hardware? > > > > > > > > I'm quite interested in it because I'm still > > thinking about > > > > building > > > > armedslack for armv5te (it's armv4 at the > > moment). > > > > We need some valid test cases. > > > > > > > > On Sat, 30 Apr 2011, Davide wrote: > > > > > > > > > I'm interested in the recompiling glibc > > thing to > > > > regain speed on specific hardware: has this been > > discussed > > > > in the ML previously ? > > > > > > > > > > --- Gio 21/4/11, Stuart Winter > > > > ha scritto: > > > > > > > > > > > Da: Stuart Winter > > > > > > Oggetto: Re: [ARMedslack] Slackware ARM > > on Small > > > > NAS (NS-K330) > > > > > > A: "Slackware ARM port" > > > > > > Data: Gioved? 21 Aprile 2011, 17:49 > > > > > > > > > > > > > I don't know, but I don't think > > you'll be > > > > happy with > > > > > > it regardless. > > > > > > > The transfer speeds are going to > > be terribly > > > > slow - > > > > > > bottlenecking > > > > > > > due to the usb2 speeds *and* the > > general > > > > wimpiness of > > > > > > the hardware. > > > > > > > > > > > > Yeah having built the distribution on > > 287MHZ > > > > RiscPCs for a > > > > > > couple of years > > > > > > with 256MB RAM... I don't know how I > > kept > > > > going.? I > > > > > > guess because there > > > > > > wasn't any better or faster supported > > arm > > > > hardware at the > > > > > > time, so I > > > > > > didn't have anything to wish I could > > have ;-) > > > > > > > > > > > > I wouldn't bother with it. Some devices > > use lower > > > > speed ARM > > > > > > CPUs but their > > > > > > usage (and software) is tuned to the > > device to > > > > match the > > > > > > usage with the > > > > > > device's specs.? Slackware ARM is a > > generic > > > > > > distribution built to run > > > > > > on the widest range of products > > possible, at the > > > > expense of > > > > > > speed in some > > > > > > areas (which IMO can easily be > > re-gained by > > > > recompiling > > > > > > glibc and some > > > > > > other critical libraries; but that's > > another > > > > topic :) ). > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > > > > > > > -- > > > > Stuart Winter > > > > Slackware ARM: www.armedslack.org > > > > -----Segue allegato----- > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > -- > > Stuart Winter > > Slackware ARM: www.armedslack.org > > -----Segue allegato----- > > > > _______________________________________________ > > 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 > -- Stuart Winter Slackware ARM: www.armedslack.org From louigi600 at yahoo.it Sun May 1 18:12:55 2011 From: louigi600 at yahoo.it (Davide) Date: Sun, 1 May 2011 19:12:55 +0100 (BST) Subject: [ARMedslack] Slackware ARM on Small NAS (NS-K330) In-Reply-To: Message-ID: <253552.52611.qm@web29702.mail.ird.yahoo.com> > > What's the difference between > > ftp://ftp.slackware.com/pub/slackware/slackware64-current/source > > and > > ftp://ftp.slackware.org.uk/armedslack/armedslack-current/source/ > > > > Is it "Slackware ARM only includes the sources in > situations when .... " ? > > Yes. > [mozes at bourbon armedslack-13.37] $ du -sh source/ > 513M? ? source/ > [mozes at bourbon armedslack-13.37] $ du -sh > ../slackware64-current/source/ > 2.5G? ? ../slackware64-current/source/ > [mozes at bourbon armedslack-13.37] $ > > Most of the MBs in armedslack's sources are firefox, > seamonkey and > kernels. > > > At the time I worked on something I liked to call > slackurus I had a > > different approach: I used to fix the slackbuild > scripts so that I could > > use them for building binaries for zaurus by cross > compilation and I had > > my own overlall build script that looked for packages > to build and built > > them. But at that time either armedslack was not > around or I did not > > know about it ... way back in 2004 ... well also many > other things might > > have changed ;-) > > The way I did it was based on trial, error and doing my > best to do as > little as possible to update the packages in order to build > them. > There are other bits that aren't in the public tree which > are used to show > the differences in the x86 tree how it is now, and how it > was when I last > built the package. > Updating the source files means two things: > - You have to keep copying them - could be scripted, but > then what about > ???new patches? what about the old ones? > some bits would be scriptable but > ???it's just easier not to. > - You then need to spend ages uploading the sources. > > The way I have done it has worked with minimal effort since > 2002 :-) Don't get me wrong ... I don't want to change how you do things I was just telling how I went about it. But if armedslack was around since 2002 I wasted a lot of time with the slackurus thing I played with and never actually finished. I know that you can't fit armedslack in a the zaurus internal flash .... but I was already using SD as storage for root filesystem and in amy case I could have borrowed tons of packages. Actually if I can get a satisfactory kernel I might dig up again my C1000 and use it around the place instead of my netbook ;-) > > > > armedslack-current/slackware/{a,l} > > > directories. > > > > Will this build everiting ? Can I just rebuild glibc > or is it necessary > > to rebuild every binary that links the new glibc ? I > was hoping that > > since version will not be changing maybe I could do > with just slipping > > in the new armv5 tuned glibc: am I wrong in hoping > this ? > > > It'll build glibc - the glibc packages (solibs & > zoneinfo) that are in the > a/ series, and the main glibc packages (including the > header files) in l/ > Look in the slackware directories or just read the build > script - it's > easy to figure it out. > > You don't need to rebuild everything that links against > glibc (ie > everything in the entire distribution). You're rebuilding > glibc with > optimisations - you're not changing the ABI or anything > like that! > You might want to rebuild bash too.? I've got a > feeling you should also > rebuild zlib. Maybe I should let John run ahead to see if he gets some good kick out of it .... for the moment I've enough of my spare time going into the busybox micro system (wife is already complaining that I'm not helping enough with the kid). > > -- > Stuart Winter > Slackware ARM: www.armedslack.org > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > From m-lists at biscuit.org.uk Sun May 1 19:02:00 2011 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sun, 1 May 2011 20:02:00 +0100 (BST) Subject: [ARMedslack] Slackware ARM on Small NAS (NS-K330) In-Reply-To: <253552.52611.qm@web29702.mail.ird.yahoo.com> References: <253552.52611.qm@web29702.mail.ird.yahoo.com> Message-ID: > > The way I have done it has worked with minimal effort since > > 2002 :-) > > Don't get me wrong ... I don't want to change how you do things I was > just telling how I went about it. Me too! :-) > But if armedslack was around since > 2002 I wasted a lot of time with the slackurus thing I played with and > never actually finished. Heh. It's a lot of effort isn't it and a *lot* of time. I have no idea how much time I've spent on this since 2002. I was even working on it when I was backpacking in Australia - although I don't think I'd released anything then -- it looks like 11.0 in 2007 was the first time I'd released although it'd been publically in -current form since 2004: that's probably why you didn't find anything when you looked. > I know that you can't fit armedslack in a the > zaurus internal flash .... You just reminded me that I didn't update the minirootfs for 13.37! /me updates the release instruction docs! The miniroot for -current expands to 213MB-- the SD Card is smaller? > > rebuild zlib. > > Maybe I should let John run ahead to see if he gets some good kick out > of it .... for the moment I've enough of my spare time going into the > busybox micro system (wife is already complaining that I'm not helping > enough with the kid). Can do -- I can also do it. -current for x86 won't be started for a while yet, so my SPs have nothing to do. I've got to upgrade my ancient systems from 13.something to .37 tomorrow, rebuild the x-toolchains and then I'll start a build of glibc going and I'll upload it somewhere. Can anybody suggest any valid benchmark tests though? I'm going to have a look at lmbench now -- Stuart Winter Slackware ARM: www.armedslack.org From louigi600 at yahoo.it Mon May 2 04:49:35 2011 From: louigi600 at yahoo.it (Davide) Date: Mon, 2 May 2011 05:49:35 +0100 (BST) Subject: [ARMedslack] Slackware ARM on Small NAS (NS-K330) In-Reply-To: Message-ID: <390762.22160.qm@web29712.mail.ird.yahoo.com> > > But if armedslack was around since > > 2002 I wasted a lot of time with the slackurus thing I > played with and > > never actually finished. > > Heh. It's a lot of effort isn't it and a *lot* of time. > I have no idea how much time I've spent on this since 2002. > I was even > working on it when I was backpacking in Australia - > although I don't think > I'd released anything then -- it looks like 11.0 in 2007 > was the first > time I'd released although it'd been publically in -current > form since > 2004: that's probably why you didn't find anything when you > looked. That cheers me up because I was blaming myself for not looking hard enough. I know what you mean ... I spent tons of time and I never even got trough it! You've been at it for many releases ... thanks a million for the effort you put in. > > I know that you can't fit armedslack in a the > > zaurus internal flash .... > > You just reminded me that I didn't update the minirootfs > for 13.37! > /me updates the release instruction docs! > > The miniroot for -current expands to 213MB-- the SD Card is > smaller? No and the internal flash is 265Mb but the bare miniroot is too leen to be used on a netbook replacement ... but it's a cool starting point. Has anyone managed to build tinyx from recent xorg sources ? I'd like to try that and fluxbox or icevm as window manager on my Z. > > > > rebuild zlib. > > > > Maybe I should let John run ahead to see if he gets > some good kick out > > of it .... for the moment I've enough of my spare time > going into the > > busybox micro system (wife is already complaining that > I'm not helping > > enough with the kid). > > Can do -- I can also do it. -current for x86 won't be > started for a while > yet, so my SPs have nothing to do.? I've got to > upgrade my ancient systems > from 13.something to .37 tomorrow, rebuild the x-toolchains > and then I'll > start a build of glibc going and I'll upload it somewhere. That would be really nice of you ... I'd be happy to do some benchmarking for you. > Can anybody suggest any valid benchmark tests though? > I'm going to have a look at lmbench now Maybe should pick some benchmark tool and just flunk the mass storage info, as everyone has different storage arrangements, and gust look closely at how cpu is performing ? Would it be any good to time how long it takes to compile the armedslack-current kernel ? But to eliminate io related differences everyone paticipating should then compile twice (once with old glibc and once with new glibc). Regards David From louigi600 at yahoo.it Tue May 3 06:43:08 2011 From: louigi600 at yahoo.it (Davide) Date: Tue, 3 May 2011 07:43:08 +0100 (BST) Subject: [ARMedslack] R: micro root rescue system In-Reply-To: <652402.23698.qm@web29718.mail.ird.yahoo.com> Message-ID: <985482.72498.qm@web29720.mail.ird.yahoo.com> I struck another little problem while trying to keep things as much slackware as possible: busybox default shell (the most complete one) seems to have no support for arrays. Slackware's /etc/rc.d/rc.inet1.conf is all array config file. In order to at least keep the same parameter names with no array index I moved to making ifcfg. whose contents would be the unindexed variables for each interface. Now this is a bit redhatish but I was unable to think of any other slackware like solution with no arrays. Anyone have any idea ? Regards David --- Ven 22/4/11, Davide ha scritto: > Da: Davide > Oggetto: [ARMedslack] micro root rescue system > A: "Slackware ARM port" > Data: Venerd? 22 Aprile 2011, 11:45 > Sorry for starting a new thread on > something that was started elsewhere .... but maybe the > shoot-off needs better attention with a new thread. > > >> This is a mix of a few I built myself and some > gotten from current. > >> This is what I'll be working with and should fit > in a compressed > >> jffs2 image 64Mb big. > >> root at slackware:/usr/src/surap_packages# du -ms * | > sort -n > >> 1 ? busybox-1.18.4-arm-1.tgz > >> 1? ? dropbear-0.53.1-arm-1.tgz > >> 1 ? hostapd-0.7.3-arm-1.tgz > >> 1? ? iptables-1.4.10-arm-1.tgz > >> 1 ???iw-0.9.20-arm-1.tgz > >> 1 ???ppp-2.4.5-arm-1.tgz > >> 1 ???udev-165-arm-2.tgz > >> 1? ? usb_modeswitch-1.1.6-arm-1.tgz > >> 1? ? wireless-tools-29-arm-2.tgz > >> 2? ? httpd-2.2.17-arm-2.tgz > >> 2? ? kernel-firmware-2.6.38.3-noarch-1.tgz > >> 5? ? glibc-solibs-2.13-arm-1.tgz > >> 8? ? kernel_kirkwood-2.6.38.3-arm-1.tgz > >> 10?? php-5.3.5-arm-1.tgz > >> > 15???kernel-modules-kirkwood-2.6.38.3_kirkwood-arm-1.tgz > >> root at slackware:/usr/src/surap_packages# du -ms . > >> 43? ? ? . > >> root at slackware:/usr/src/surap_packages# > >> > >> Since booting from jffs2 image does not require > initrd ... and maybe > >> one can do without documentation .... I'll see if > I can fit that in a > >> 32Mb image. > >> > > Build a custom kernel with few modules ;) > > I will strip all unnecessary modules for a rescue system, > remove initrd, strip documentation and carve down as much as > possible ... if it won't fit I'll consider thttpd and some > lighter web scripting language. Maybe web stuff is not > really necessary for a rescue system anyway. > > Now I've a question. > there are 2 ways to do this: > 1) repackage the single packages and append some suffix to > distinguish them from the standard packages, possibly modify > the build scripts for them so that future maintenance will > be easier, > > 2) just shove everything needed somewhere and remove all > that is not needed and then build the jffs2 image. > > Now if this micro root system is just going to be my > personal AP/3g/NAS/router/rescue the second way will take > much less effort, on the other hand if you like the idea of > having an armedslack micro root system that will be more > then just a rescue system and possibly fit in a 32Mb > compressed image; well then we should go about the first > way. > I say we because I'm just a user and even if I do most of > the dirty work I'll need assistance from the ARMedslack team > to do some of the required actions if this is of any > interest to ARMedslack community. > > I've no reservation in sharing my work as I consider all my > work GPL + it's mainly just administration so the question > really is: Does armedslack want a smart micro root system ? > > Best regards > David Rao > > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > From louigi600 at yahoo.it Tue May 3 22:25:54 2011 From: louigi600 at yahoo.it (Davide) Date: Tue, 3 May 2011 23:25:54 +0100 (BST) Subject: [ARMedslack] qemu-network-tun.sh modified script In-Reply-To: <4DBA7583.2000400@gmail.com> Message-ID: <430772.43270.qm@web29710.mail.ird.yahoo.com> I fixed a few other things: the static network now get properly restarted will not kill blindly all dhcp clients ... only the instance running on eth0 will only set sysctl options if they are avalible #!/bin/sh [ -f /proc/sys/net/ipv4/ip_forward ] && sysctl -w net.ipv4.ip_forward=1 [ -f /proc/sys/dev/rtc/max-user-freq ] && \ sysctl -w dev.rtc.max-user-freq=1024 if [ $(ifconfig |grep "Link encap" |grep -c "^br0") -lt 1 ] then if [ $(ps -eo pid,cmd |grep -v grep |grep dhcpcd |grep -c eth0) -ge 1 ] then RESTART_NET="dhcpcd -t 10 br0" kill -9 $(ps -eo pid,cmd |grep -v grep |grep dhcpcd |grep eth0 |awk '{print $1}') else RESTART_NET="ifconfig br0 $(ip addr show dev eth0 |grep inet |awk '{print $2}')" ifconfig eth0 0.0.0.0 down fi brctl addbr br0 brctl stp br0 off brctl setfd br0 1 brctl addif br0 eth0 $RESTART_NET fi /sbin/ifconfig $1 0.0.0.0 promisc up /sbin/brctl addif br0 $1 sleep 1 brctl show --- Ven 29/4/11, John O'Donnell ha scritto: > Da: John O'Donnell > Oggetto: Re: [ARMedslack] qemu-network-tun.sh modified script > A: "Slackware ARM port" > Data: Venerd? 29 Aprile 2011, 10:23 > On 04/29/2011 04:06 AM, Davide > wrote: > > If anyone else finds this handy this works with dhcp > client on both host and guest and also gets rid of all > rc.local requirements. > > On the guest os you will need to config interface once > system is up (static or via dhcp) > > Needs fixing for static ip reconfiguration/rerouting > on host system after bridge creation. > > > > I apologize for my non standard indentation ... > > Also if anyone cares, I wrote a script like that over a > year ago to lanuch a private network for many VMs (all Linux > distros - many versions) to compile software for a company I > was at.? It is configured a private network so some > assembly is required.? But I made most of it > configurable up top so it could be on a public > adapter.? I developed it on Slack (of course) then > deployed it to a Suse production box.? I had set up NFS > on the host with the source code.? The source would get > copied to its own branch for the machine it was compiling > for, fire up the VM, compile over NFS, create package on NFS > host (rpm/tgz/txz/deb/etc), then die, rinse and repeat. > > #!/bin/sh > # Start/stop qemu's private network > # Revised: 12/16/2009 JJO > ### BEGIN INIT INFO > # Provides: qemunet > # Required-Start: $network > # Required-Stop: $network > # Default-Start: 3 5 > # Default-Stop: 0 1 2 6 > # Description: Start the qemu private network > ### END INIT INFO > > ETHIP=10.10.10.1 > GATEWAY= > ETHBC=10.10.10.255 > BRIDGE=br0 > ETH=dummy0 > TAP=tap0 > > # A little SuSE sanity check > [ -f /etc/SuSE-release ] && /sbin/rmmod dummy0 > >/dev/null 2>&1 > > # Start the qemu private network > qemunet_start() { > ? # Make sure the qemu private network isnt already > running > ? PROBLEM=FALSE > ? for IF in $ETH $TAP $BRIDGE; do > ? ? /sbin/ifconfig | grep $IF >/dev/null > 2>&1 > ? ? [ $? = 0 ] && PROBLEM=TRUE > ? done > ? if [ $PROBLEM = TRUE ]; then > ? ? echo "All or part of the qemu private network > is already running!" > ? ? echo "Cowardly refusing to start it > again!? BYE!" > ? ? exit 1 > ? fi > > ? echo "Starting the qemu private network..." > ? # Make sure the kernel module is loaded > ? /sbin/lsmod | grep dummy >/dev/null 2>&1 > ? [ $? = 1 ] && /sbin/modprobe dummy > > ? # First take interface down, then bring it up with > IP 0.0.0.0 > ? /sbin/ifconfig $ETH down > ? /sbin/ifconfig $ETH 0.0.0.0 promisc up > > ? # Bring up the tap device (name specified as first > argument, by QEMU) > ? /usr/sbin/openvpn --mktun --dev $TAP > ? /sbin/ifconfig $TAP 0.0.0.0 promisc up > > ? # create the bridge between eth0 and the tap device > ? /sbin/brctl addbr $BRIDGE > ? /sbin/brctl addif $BRIDGE $ETH > ? /sbin/brctl addif $BRIDGE $TAP > ? # only a single bridge so loops are not possible, > turn off spanning tree protocol > ? /sbin/brctl stp $BRIDGE off > > ? # Bring up the bridge with ETHIP and add the default > route > ? /sbin/ifconfig br0 $ETHIP netmask 255.255.255.0 > broadcast $ETHBC > ? [ -n "$GATEWAY" ] && /sbin/route add default > gw $GATEWAY > } > > # Stop the qemu private network > qemunet_stop() { > ? echo "Stopping the qemu private network..." > ? # Bring down interface and br0 > ? /sbin/ifconfig $ETH down > ? /sbin/ifconfig $BRIDGE down > ? /sbin/rmmod dummy > > ? # Delete the bridge > ? /sbin/brctl delbr $BRIDGE > > ? # delete the tap device > ? /usr/sbin/openvpn --rmtun --dev $TAP > } > > # Restart the qemu private network > qemunet_restart() { > ? qemunet_stop > ? sleep 1 > ? qemunet_start > } > > # Check if the qemu private network is up and running > qemunet_status() { > ? echo -n "Checking the qemu private network: " > > ? # Check the qemu private inetwork > ? for IF in $ETH $TAP $BRIDGE; do > ? ? /sbin/ifconfig | grep $IF >/dev/null > 2>&1 > ? ? if [ $? = 1 ]; then > ? ? ? echo -n "$IF is down" > ? ? else > ? ? ? echo -n "$IF is up" > ? ? fi > ? ? if [ $IF = $BRIDGE ]; then > ? ? ? echo "." > ? ? else > ? ? ? echo -n ", " > ? ? fi > ? done > } > > case "$1" in > 'start') qemunet_start ;; > 'stop')? qemunet_stop ;; > 'restart') qemunet_restart ;; > 'status')? qemunet_status ;; > *) echo "usage $0 start|stop|restart|status" > esac > > -- === Never ask a geek why, just nod your head and slowly > back away.=== > +================================+==================================+ > |? John O'Donnell? ? ? ? ? > ? ? ? |? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? ? ? | > |? (Sr. Systems Engineer,? ? ? ? > |? ? http://juanisan.homeip.net? ? > | > |? Net Admin, Programmer, etc.)? |? E-Mail: > unixjohn1969 at gmail.com? > | > +================================+==================================+ > No man is useless who has a friend, and if we are loved we > are > indispensable.? -- Robert Louis Stevenson > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > From louigi600 at yahoo.it Tue May 3 22:57:25 2011 From: louigi600 at yahoo.it (Davide) Date: Tue, 3 May 2011 23:57:25 +0100 (BST) Subject: [ARMedslack] R: R: micro root rescue system In-Reply-To: <985482.72498.qm@web29720.mail.ird.yahoo.com> Message-ID: <852222.13196.qm@web29715.mail.ird.yahoo.com> Ok I've the first working image with all the basics working. This is what's in the image: root at hp:/mnt/hd/usr/src/surap_packages# ls at-3.1.12-arm-1.tgz iptables-1.4.10-arm-1.tgz busybox-1.18.4-arm-1.tgz iw-0.9.20-arm-1.tgz dnsmasq-2.52-arm-1.tgz kernel-firmware-2.6.38.3-noarch-1.tgz dropbear-0.53.1-arm-1.tgz kernel_2.6.38.3-microkirkwood-arm-1.tgz php-5.3.5-arm-1.tgz glibc-solibs-2.13-arm-1.tgz ppp-2.4.5-arm-1.tgz hostapd-0.7.3-arm-1.tgz udev-165-arm-2.tgz httpd-2.2.17-arm-2.tgz usb_modeswitch-1.1.6-arm-1.tgz wireless-tools-29-arm-2.tgz root at hp:/mnt/hd/usr/src/surap_packages# and a few other required libs picked manually The compressed and unsummed jffs2 is 41Mb big root at hp:/mnt/hd/usr/src/surap_packages# du -ms ../surap_busybox.jffs2 41 ../surap_busybox.jffs2 root at hp:/mnt/hd/usr/src/surap_packages# usb_modeswitch will not work because it needs tclsh and I don't want to add it unless it's really necessary. I'll try working around the problem with pure busybox ash scripting ... if that's not possible I'll write a small c program to help out ash. Regards David --- Mar 3/5/11, Davide ha scritto: > Da: Davide > Oggetto: [ARMedslack] R: micro root rescue system > A: "Slackware ARM port" > Data: Marted? 3 maggio 2011, 08:43 > I struck another little problem while > trying to keep things as much slackware as possible: > busybox default shell (the most complete one) seems to have > no support for arrays. Slackware's /etc/rc.d/rc.inet1.conf > is all array config file. > > In order to at least keep the same parameter names with no > array index I moved to making ifcfg. whose > contents would be the unindexed variables for each > interface. Now this is a bit redhatish but I was unable to > think of any other slackware like solution with no arrays. > > Anyone have any idea ? > > Regards > David > > --- Ven 22/4/11, Davide > ha scritto: > > > Da: Davide > > Oggetto: [ARMedslack] micro root rescue system > > A: "Slackware ARM port" > > Data: Venerd? 22 Aprile 2011, 11:45 > > Sorry for starting a new thread on > > something that was started elsewhere .... but maybe > the > > shoot-off needs better attention with a new thread. > > > > >> This is a mix of a few I built myself and > some > > gotten from current. > > >> This is what I'll be working with and should > fit > > in a compressed > > >> jffs2 image 64Mb big. > > >> root at slackware:/usr/src/surap_packages# du > -ms * | > > sort -n > > >> 1 ? busybox-1.18.4-arm-1.tgz > > >> 1? ? dropbear-0.53.1-arm-1.tgz > > >> 1 ? hostapd-0.7.3-arm-1.tgz > > >> 1? ? iptables-1.4.10-arm-1.tgz > > >> 1 ???iw-0.9.20-arm-1.tgz > > >> 1 ???ppp-2.4.5-arm-1.tgz > > >> 1 ???udev-165-arm-2.tgz > > >> 1? ? usb_modeswitch-1.1.6-arm-1.tgz > > >> 1? ? wireless-tools-29-arm-2.tgz > > >> 2? ? httpd-2.2.17-arm-2.tgz > > >> 2? ? kernel-firmware-2.6.38.3-noarch-1.tgz > > >> 5? ? glibc-solibs-2.13-arm-1.tgz > > >> 8? ? kernel_kirkwood-2.6.38.3-arm-1.tgz > > >> 10?? php-5.3.5-arm-1.tgz > > >> > > > 15???kernel-modules-kirkwood-2.6.38.3_kirkwood-arm-1.tgz > > >> root at slackware:/usr/src/surap_packages# du > -ms . > > >> 43? ? ? . > > >> root at slackware:/usr/src/surap_packages# > > >> > > >> Since booting from jffs2 image does not > require > > initrd ... and maybe > > >> one can do without documentation .... I'll > see if > > I can fit that in a > > >> 32Mb image. > > >> > > > Build a custom kernel with few modules ;) > > > > I will strip all unnecessary modules for a rescue > system, > > remove initrd, strip documentation and carve down as > much as > > possible ... if it won't fit I'll consider thttpd and > some > > lighter web scripting language. Maybe web stuff is > not > > really necessary for a rescue system anyway. > > > > Now I've a question. > > there are 2 ways to do this: > > 1) repackage the single packages and append some > suffix to > > distinguish them from the standard packages, possibly > modify > > the build scripts for them so that future maintenance > will > > be easier, > > > > 2) just shove everything needed somewhere and remove > all > > that is not needed and then build the jffs2 image. > > > > Now if this micro root system is just going to be my > > personal AP/3g/NAS/router/rescue the second way will > take > > much less effort, on the other hand if you like the > idea of > > having an armedslack micro root system that will be > more > > then just a rescue system and possibly fit in a 32Mb > > compressed image; well then we should go about the > first > > way. > > I say we because I'm just a user and even if I do most > of > > the dirty work I'll need assistance from the > ARMedslack team > > to do some of the required actions if this is of any > > interest to ARMedslack community. > > > > I've no reservation in sharing my work as I consider > all my > > work GPL + it's mainly just administration so the > question > > really is: Does armedslack want a smart micro root > system ? > > > > Best regards > > David Rao > > > > _______________________________________________ > > 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 louigi600 at yahoo.it Wed May 4 08:47:09 2011 From: louigi600 at yahoo.it (Davide) Date: Wed, 4 May 2011 09:47:09 +0100 (BST) Subject: [ARMedslack] qemu-network-tun.sh modified script In-Reply-To: <430772.43270.qm@web29710.mail.ird.yahoo.com> Message-ID: <804079.25588.qm@web29706.mail.ird.yahoo.com> That last one did not kill right the dhcp client on eth0. This should fix it: #!/bin/sh [ -f /proc/sys/net/ipv4/ip_forward ] && sysctl -w net.ipv4.ip_forward=1 [ -f /proc/sys/dev/rtc/max-user-freq ] && sysctl -w dev.rtc.max-user-freq=1024 if [ $(ifconfig |grep "Link encap" |grep -c "^br0") -lt 1 ] then if [ $(ps -eo pid,cmd |grep -v grep |grep dhcpcd |grep -c eth0) -ge 1 ] then RESTART_NET="dhcpcd -t 10 br0" dhcpcd -k eth0 else RESTART_NET="ifconfig br0 $(ip addr show dev eth0 |grep inet |awk '{print $2}')" ifconfig eth0 0.0.0.0 down fi brctl addbr br0 brctl stp br0 off brctl setfd br0 1 brctl addif br0 eth0 $RESTART_NET fi /sbin/ifconfig $1 0.0.0.0 promisc up /sbin/brctl addif br0 $1 sleep 1 brctl show --- Mer 4/5/11, Davide ha scritto: > Da: Davide > Oggetto: Re: [ARMedslack] qemu-network-tun.sh modified script > A: "Slackware ARM port" > Data: Mercoled? 4 maggio 2011, 00:25 > I fixed a few other things: > the static network now get properly restarted > > will not kill blindly all dhcp clients ... only the > instance running on eth0 > > will only set sysctl options if they are avalible > > #!/bin/sh > [ -f /proc/sys/net/ipv4/ip_forward ] && sysctl -w > net.ipv4.ip_forward=1 > [ -f /proc/sys/dev/rtc/max-user-freq ] && \ > ? sysctl -w dev.rtc.max-user-freq=1024 > > if [ $(ifconfig |grep "Link encap" |grep -c "^br0") -lt 1 > ] > then > ? if [ $(ps -eo pid,cmd |grep -v grep |grep dhcpcd > |grep -c eth0) -ge 1 ] > ? then > ? ? RESTART_NET="dhcpcd -t 10 br0" > ? ? kill -9? $(ps -eo pid,cmd |grep -v grep > |grep dhcpcd |grep eth0 |awk '{print $1}') > ? else > ? ? RESTART_NET="ifconfig br0 $(ip addr show dev > eth0 |grep inet |awk '{print $2}')" > ? ? ifconfig eth0 0.0.0.0 down > ? fi > > ? brctl addbr br0 > ? brctl stp br0 off > ? brctl setfd br0 1 > ? brctl addif br0 eth0 > > ? $RESTART_NET > > fi > > /sbin/ifconfig $1 0.0.0.0 promisc up > /sbin/brctl addif br0 $1 > sleep 1 > brctl show > > --- Ven 29/4/11, John O'Donnell > ha scritto: > > > Da: John O'Donnell > > Oggetto: Re: [ARMedslack] qemu-network-tun.sh modified > script > > A: "Slackware ARM port" > > Data: Venerd? 29 Aprile 2011, 10:23 > > On 04/29/2011 04:06 AM, Davide > > wrote: > > > If anyone else finds this handy this works with > dhcp > > client on both host and guest and also gets rid of > all > > rc.local requirements. > > > On the guest os you will need to config interface > once > > system is up (static or via dhcp) > > > Needs fixing for static ip > reconfiguration/rerouting > > on host system after bridge creation. > > > > > > I apologize for my non standard indentation ... > > > > Also if anyone cares, I wrote a script like that over > a > > year ago to lanuch a private network for many VMs (all > Linux > > distros - many versions) to compile software for a > company I > > was at.? It is configured a private network so some > > assembly is required.? But I made most of it > > configurable up top so it could be on a public > > adapter.? I developed it on Slack (of course) then > > deployed it to a Suse production box.? I had set up > NFS > > on the host with the source code.? The source would > get > > copied to its own branch for the machine it was > compiling > > for, fire up the VM, compile over NFS, create package > on NFS > > host (rpm/tgz/txz/deb/etc), then die, rinse and > repeat. > > > > #!/bin/sh > > # Start/stop qemu's private network > > # Revised: 12/16/2009 JJO > > ### BEGIN INIT INFO > > # Provides: qemunet > > # Required-Start: $network > > # Required-Stop: $network > > # Default-Start: 3 5 > > # Default-Stop: 0 1 2 6 > > # Description: Start the qemu private network > > ### END INIT INFO > > > > ETHIP=10.10.10.1 > > GATEWAY= > > ETHBC=10.10.10.255 > > BRIDGE=br0 > > ETH=dummy0 > > TAP=tap0 > > > > # A little SuSE sanity check > > [ -f /etc/SuSE-release ] && /sbin/rmmod > dummy0 > > >/dev/null 2>&1 > > > > # Start the qemu private network > > qemunet_start() { > > ? # Make sure the qemu private network isnt already > > running > > ? PROBLEM=FALSE > > ? for IF in $ETH $TAP $BRIDGE; do > > ? ? /sbin/ifconfig | grep $IF >/dev/null > > 2>&1 > > ? ? [ $? = 0 ] && PROBLEM=TRUE > > ? done > > ? if [ $PROBLEM = TRUE ]; then > > ? ? echo "All or part of the qemu private network > > is already running!" > > ? ? echo "Cowardly refusing to start it > > again!? BYE!" > > ? ? exit 1 > > ? fi > > > > ? echo "Starting the qemu private network..." > > ? # Make sure the kernel module is loaded > > ? /sbin/lsmod | grep dummy >/dev/null 2>&1 > > ? [ $? = 1 ] && /sbin/modprobe dummy > > > > ? # First take interface down, then bring it up with > > IP 0.0.0.0 > > ? /sbin/ifconfig $ETH down > > ? /sbin/ifconfig $ETH 0.0.0.0 promisc up > > > > ? # Bring up the tap device (name specified as first > > argument, by QEMU) > > ? /usr/sbin/openvpn --mktun --dev $TAP > > ? /sbin/ifconfig $TAP 0.0.0.0 promisc up > > > > ? # create the bridge between eth0 and the tap > device > > ? /sbin/brctl addbr $BRIDGE > > ? /sbin/brctl addif $BRIDGE $ETH > > ? /sbin/brctl addif $BRIDGE $TAP > > ? # only a single bridge so loops are not possible, > > turn off spanning tree protocol > > ? /sbin/brctl stp $BRIDGE off > > > > ? # Bring up the bridge with ETHIP and add the > default > > route > > ? /sbin/ifconfig br0 $ETHIP netmask 255.255.255.0 > > broadcast $ETHBC > > ? [ -n "$GATEWAY" ] && /sbin/route add > default > > gw $GATEWAY > > } > > > > # Stop the qemu private network > > qemunet_stop() { > > ? echo "Stopping the qemu private network..." > > ? # Bring down interface and br0 > > ? /sbin/ifconfig $ETH down > > ? /sbin/ifconfig $BRIDGE down > > ? /sbin/rmmod dummy > > > > ? # Delete the bridge > > ? /sbin/brctl delbr $BRIDGE > > > > ? # delete the tap device > > ? /usr/sbin/openvpn --rmtun --dev $TAP > > } > > > > # Restart the qemu private network > > qemunet_restart() { > > ? qemunet_stop > > ? sleep 1 > > ? qemunet_start > > } > > > > # Check if the qemu private network is up and running > > qemunet_status() { > > ? echo -n "Checking the qemu private network: " > > > > ? # Check the qemu private inetwork > > ? for IF in $ETH $TAP $BRIDGE; do > > ? ? /sbin/ifconfig | grep $IF >/dev/null > > 2>&1 > > ? ? if [ $? = 1 ]; then > > ? ? ? echo -n "$IF is down" > > ? ? else > > ? ? ? echo -n "$IF is up" > > ? ? fi > > ? ? if [ $IF = $BRIDGE ]; then > > ? ? ? echo "." > > ? ? else > > ? ? ? echo -n ", " > > ? ? fi > > ? done > > } > > > > case "$1" in > > 'start') qemunet_start ;; > > 'stop')? qemunet_stop ;; > > 'restart') qemunet_restart ;; > > 'status')? qemunet_status ;; > > *) echo "usage $0 start|stop|restart|status" > > esac > > > > -- === Never ask a geek why, just nod your head and > slowly > > back away.=== > > > +================================+==================================+ > > |? John O'Donnell? ? ? ? ? > > ? ? ? |? ? ? ? ? > > ? ? ? ? ? ? ? ? > > ? ? ? ? | > > |? (Sr. Systems Engineer,? ? ? ? > > |? ? http://juanisan.homeip.net? ? > > | > > |? Net Admin, Programmer, etc.)? |? E-Mail: > > unixjohn1969 at gmail.com? > > | > > > +================================+==================================+ > > No man is useless who has a friend, and if we are > loved we > > are > > indispensable.? -- Robert Louis Stevenson > > _______________________________________________ > > 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 mozes at slackware.com Wed May 4 14:48:54 2011 From: mozes at slackware.com (Stuart Winter) Date: Wed, 4 May 2011 07:48:54 -0700 (PDT) Subject: [ARMedslack] Miniroot of 13.37 available Message-ID: Hi The mini root for 13.37 has been uploaded: ftp://ftp.armedslack.org/armedslack/armedslack-devtools/minirootfs/roots/ Cheers s. -- Stuart Winter www.slackware.com/~mozes Slackware for ARM: www.armedslack.org From louigi600 at yahoo.it Thu May 5 08:15:21 2011 From: louigi600 at yahoo.it (Davide) Date: Thu, 5 May 2011 09:15:21 +0100 (BST) Subject: [ARMedslack] R: R: R: micro root rescue system In-Reply-To: <852222.13196.qm@web29715.mail.ird.yahoo.com> Message-ID: <753767.17772.qm@web29702.mail.ird.yahoo.com> Busybox has an internal micro web server root at surap:~# busybox httpd --help BusyBox v1.18.4 (2011-04-20 14:04:26 BST) multi-call binary. Usage: httpd [-ifv[v]] [-c CONFFILE] [-p [IP:]PORT] [-u USER[:GRP]] [-r REALM] [-h HOME] or httpd -d/-e/-m STRING Listen for incoming HTTP requests Options: -i Inetd mode -f Don't daemonize -v[v] Verbose -p [IP:]PORT Bind to IP:PORT (default *:80) -u USER[:GRP] Set uid/gid after binding to port -r REALM Authentication Realm for Basic Authentication -h HOME Home directory (default .) -c FILE Configuration file (default {/etc,HOME}/httpd.conf) -m STRING MD5 crypt STRING -e STRING HTML encode STRING -d STRING URL decode STRING I'll be getting rid of apache in the microroot system --- Mer 4/5/11, Davide ha scritto: > Da: Davide > Oggetto: [ARMedslack] R: R: micro root rescue system > A: "Slackware ARM port" > Data: Mercoled? 4 maggio 2011, 00:57 > Ok I've the first working image with > all the basics working. > > This is what's in the image: > root at hp:/mnt/hd/usr/src/surap_packages# ls > at-3.1.12-arm-1.tgz? ? ? ? ? > ? iptables-1.4.10-arm-1.tgz > busybox-1.18.4-arm-1.tgz? ? > ???iw-0.9.20-arm-1.tgz > dnsmasq-2.52-arm-1.tgz? ? ? > ???kernel-firmware-2.6.38.3-noarch-1.tgz > dropbear-0.53.1-arm-1.tgz? ? ? > kernel_2.6.38.3-microkirkwood-arm-1.tgz > php-5.3.5-arm-1.tgz? ? ? ? ? > ? glibc-solibs-2.13-arm-1.tgz? > ppp-2.4.5-arm-1.tgz? ? ? ? ? > ? hostapd-0.7.3-arm-1.tgz? ? ? > udev-165-arm-2.tgz? ? ? ? ? > ???httpd-2.2.17-arm-2.tgz? ? > ??? > usb_modeswitch-1.1.6-arm-1.tgz wireless-tools-29-arm-2.tgz > root at hp:/mnt/hd/usr/src/surap_packages# > and a few other required libs picked manually > > The compressed and unsummed jffs2 is 41Mb big > > root at hp:/mnt/hd/usr/src/surap_packages# du -ms > ../surap_busybox.jffs2 > 41? ? ? ../surap_busybox.jffs2 > root at hp:/mnt/hd/usr/src/surap_packages# > > usb_modeswitch will not work because it needs tclsh and I > don't want to add it unless it's really necessary. I'll try > working around the problem with pure busybox ash scripting > ... if that's not possible I'll write a small c program to > help out ash. > > Regards > David > > --- Mar 3/5/11, Davide > ha scritto: > > > Da: Davide > > Oggetto: [ARMedslack] R:? micro root rescue > system > > A: "Slackware ARM port" > > Data: Marted? 3 maggio 2011, 08:43 > > I struck another little problem while > > trying to keep things as much slackware as possible: > > busybox default shell (the most complete one) seems to > have > > no support for arrays. Slackware's > /etc/rc.d/rc.inet1.conf > > is all array config file. > > > > In order to at least keep the same parameter names > with no > > array index I moved to making ifcfg. > whose > > contents would be the unindexed variables for each > > interface. Now this is a bit redhatish but I was > unable to > > think of any other slackware like solution with no > arrays. > > > > Anyone have any idea ? > > > > Regards > > David > > > > --- Ven 22/4/11, Davide > > ha scritto: > > > > > Da: Davide > > > Oggetto: [ARMedslack] micro root rescue system > > > A: "Slackware ARM port" > > > Data: Venerd? 22 Aprile 2011, 11:45 > > > Sorry for starting a new thread on > > > something that was started elsewhere .... but > maybe > > the > > > shoot-off needs better attention with a new > thread. > > > > > > >> This is a mix of a few I built myself > and > > some > > > gotten from current. > > > >> This is what I'll be working with and > should > > fit > > > in a compressed > > > >> jffs2 image 64Mb big. > > > >> root at slackware:/usr/src/surap_packages# > du > > -ms * | > > > sort -n > > > >> 1 ? busybox-1.18.4-arm-1.tgz > > > >> 1? ? dropbear-0.53.1-arm-1.tgz > > > >> 1 ? hostapd-0.7.3-arm-1.tgz > > > >> 1? ? iptables-1.4.10-arm-1.tgz > > > >> 1 ???iw-0.9.20-arm-1.tgz > > > >> 1 ???ppp-2.4.5-arm-1.tgz > > > >> 1 ???udev-165-arm-2.tgz > > > >> 1? ? usb_modeswitch-1.1.6-arm-1.tgz > > > >> 1? ? wireless-tools-29-arm-2.tgz > > > >> 2? ? httpd-2.2.17-arm-2.tgz > > > >> 2? ? > kernel-firmware-2.6.38.3-noarch-1.tgz > > > >> 5? ? glibc-solibs-2.13-arm-1.tgz > > > >> 8? ? > kernel_kirkwood-2.6.38.3-arm-1.tgz > > > >> 10?? php-5.3.5-arm-1.tgz > > > >> > > > > > > 15???kernel-modules-kirkwood-2.6.38.3_kirkwood-arm-1.tgz > > > >> root at slackware:/usr/src/surap_packages# > du > > -ms . > > > >> 43? ? ? . > > > >> root at slackware:/usr/src/surap_packages# > > > >> > > > >> Since booting from jffs2 image does not > > require > > > initrd ... and maybe > > > >> one can do without documentation .... > I'll > > see if > > > I can fit that in a > > > >> 32Mb image. > > > >> > > > > Build a custom kernel with few modules ;) > > > > > > I will strip all unnecessary modules for a > rescue > > system, > > > remove initrd, strip documentation and carve down > as > > much as > > > possible ... if it won't fit I'll consider thttpd > and > > some > > > lighter web scripting language. Maybe web stuff > is > > not > > > really necessary for a rescue system anyway. > > > > > > Now I've a question. > > > there are 2 ways to do this: > > > 1) repackage the single packages and append some > > suffix to > > > distinguish them from the standard packages, > possibly > > modify > > > the build scripts for them so that future > maintenance > > will > > > be easier, > > > > > > 2) just shove everything needed somewhere and > remove > > all > > > that is not needed and then build the jffs2 > image. > > > > > > Now if this micro root system is just going to be > my > > > personal AP/3g/NAS/router/rescue the second way > will > > take > > > much less effort, on the other hand if you like > the > > idea of > > > having an armedslack micro root system that will > be > > more > > > then just a rescue system and possibly fit in a > 32Mb > > > compressed image; well then we should go about > the > > first > > > way. > > > I say we because I'm just a user and even if I do > most > > of > > > the dirty work I'll need assistance from the > > ARMedslack team > > > to do some of the required actions if this is of > any > > > interest to ARMedslack community. > > > > > > I've no reservation in sharing my work as I > consider > > all my > > > work GPL + it's mainly just administration so > the > > question > > > really is: Does armedslack want a smart micro > root > > system ? > > > > > > Best regards > > > David Rao > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > From thenktor at gmx.de Thu May 5 08:32:52 2011 From: thenktor at gmx.de (Thorsten =?iso-8859-1?q?M=FChlfelder?=) Date: Thu, 5 May 2011 10:32:52 +0200 Subject: [ARMedslack] Improving USB audio sound quality on the Dockstar Message-ID: <201105051032.52207.thenktor@gmx.de> Hi, I'm using a high quality USB audio device (Burr-Brown Japan PCM2702) with my Dockstar. I've configured mpd to use the hardware interface without dmix because dmix seems to be broken on the ARM platform. But there is one problem left: sometimes clicks and pops can be heard. They appear randomly up to 2 times a minute. My impression is that hard disk data transfer causes them, because using "hdparm -t" makes the situation worse. On the Dockstar all USB devices are connected via hub to the same USB controller: # lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB Bus 001 Device 003: ID 0bc2:2120 Seagate RSS LLC Bus 001 Device 005: ID 08bb:2702 Texas Instruments Japan Speakers Is it possible to give the USB audio data transfers a higher priority? -- Thorsten M?hlfelder Salix OS: www.salixos.org From thenktor at gmx.de Thu May 5 08:40:52 2011 From: thenktor at gmx.de (Thorsten =?iso-8859-1?q?M=FChlfelder?=) Date: Thu, 5 May 2011 10:40:52 +0200 Subject: [ARMedslack] Improving USB audio sound quality on the Dockstar In-Reply-To: <201105051032.52207.thenktor@gmx.de> References: <201105051032.52207.thenktor@gmx.de> Message-ID: <201105051040.52158.thenktor@gmx.de> Am Thursday 05 May 2011 10:32:52 schrieb Thorsten M?hlfelder: > Hi, > > I'm using a high quality USB audio device (Burr-Brown Japan PCM2702) with > my Dockstar. I've configured mpd to use the hardware interface without dmix > because dmix seems to be broken on the ARM platform. > > But there is one problem left: sometimes clicks and pops can be heard. They > appear randomly up to 2 times a minute. My impression is that hard disk > data transfer causes them, because using "hdparm -t" makes the situation > worse. On the Dockstar all USB devices are connected via hub to the same > USB controller: > # lsusb > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB > Bus 001 Device 003: ID 0bc2:2120 Seagate RSS LLC > Bus 001 Device 005: ID 08bb:2702 Texas Instruments Japan Speakers > > Is it possible to give the USB audio data transfers a higher priority? Another idea is that network traffic may cause this because eth0 has higher priority IRQ than USB: thorsten at dreamtheater:~$ cat /proc/interrupts CPU0 1: 68571661 orion_irq orion_tick 5: 2 orion_irq mv_xor.0 6: 2 orion_irq mv_xor.1 7: 2 orion_irq mv_xor.2 8: 2 orion_irq mv_xor.3 11: 94038944 orion_irq eth0 19: 37108202 orion_irq ehci_hcd:usb1 22: 0 orion_irq mv_crypto 33: 290 orion_irq serial 46: 25 orion_irq mv643xx_eth Err: 0 -- Thorsten M?hlfelder Salix OS: www.salixos.org From atelszewski at gmail.com Thu May 5 08:42:30 2011 From: atelszewski at gmail.com (Andrzej Telszewski) Date: Thu, 05 May 2011 10:42:30 +0200 Subject: [ARMedslack] Improving USB audio sound quality on the Dockstar In-Reply-To: <201105051032.52207.thenktor@gmx.de> References: <201105051032.52207.thenktor@gmx.de> Message-ID: <4DC262F6.8040606@gmail.com> On 05/05/2011 10:32 AM, Thorsten M?hlfelder wrote: > Hi, > > I'm using a high quality USB audio device (Burr-Brown Japan PCM2702) with my > Dockstar. I've configured mpd to use the hardware interface without dmix > because dmix seems to be broken on the ARM platform. > > But there is one problem left: sometimes clicks and pops can be heard. They > appear randomly up to 2 times a minute. My impression is that hard disk data > transfer causes them, because using "hdparm -t" makes the situation worse. On > the Dockstar all USB devices are connected via hub to the same USB > controller: > # lsusb > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB > Bus 001 Device 003: ID 0bc2:2120 Seagate RSS LLC > Bus 001 Device 005: ID 08bb:2702 Texas Instruments Japan Speakers > > Is it possible to give the USB audio data transfers a higher priority? > Hi, You might try 'chrt', but you need to find the process(es) ID(s) responsible for all the audio stuff. Eventually, check here: http://subversion.ffado.org/wiki/IrqPriorities but it's rather about real-time Linux. -- Pozdrawiam, Best regards, Andrzej Telszewski From claudio.cavalera at gmail.com Thu May 5 12:48:50 2011 From: claudio.cavalera at gmail.com (Claudio Cavalera) Date: Thu, 5 May 2011 14:48:50 +0200 Subject: [ARMedslack] Improving USB audio sound quality on the Dockstar In-Reply-To: <4DC262F6.8040606@gmail.com> References: <201105051032.52207.thenktor@gmx.de> <4DC262F6.8040606@gmail.com> Message-ID: On 05/05/2011, Andrzej Telszewski wrote: > On 05/05/2011 10:32 AM, Thorsten M?hlfelder wrote: >> Hi, >> >> I'm using a high quality USB audio device (Burr-Brown Japan PCM2702) with >> my >> Dockstar. I've configured mpd to use the hardware interface without dmix >> because dmix seems to be broken on the ARM platform. >> >> But there is one problem left: sometimes clicks and pops can be heard. >> They >> appear randomly up to 2 times a minute. My impression is that hard disk >> data >> transfer causes them, because using "hdparm -t" makes the situation worse. >> On >> the Dockstar all USB devices are connected via hub to the same USB >> controller: >> # lsusb >> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB >> Bus 001 Device 003: ID 0bc2:2120 Seagate RSS LLC >> Bus 001 Device 005: ID 08bb:2702 Texas Instruments Japan Speakers >> >> Is it possible to give the USB audio data transfers a higher priority? >> > > Hi, > > You might try 'chrt', but you need to find the process(es) ID(s) > responsible for all the audio stuff. Eventually, check here: > > http://subversion.ffado.org/wiki/IrqPriorities > > but it's rather about real-time Linux. > > -- > Pozdrawiam, > Best regards, > Andrzej Telszewski > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > From thenktor at gmx.de Thu May 5 23:29:24 2011 From: thenktor at gmx.de (Thorsten =?ISO-8859-1?B?TfxobGZlbGRlcg==?=) Date: Fri, 6 May 2011 01:29:24 +0200 Subject: [ARMedslack] File system on my Freeagent Dockstar got corrupted In-Reply-To: References: <201102180948.38762.thenktor@gmx.de> Message-ID: <20110506012924.28fa12ce@pinkfloyd.tm-net> Am Fri, 18 Feb 2011 09:20:44 +0000 (GMT) schrieb Stuart Winter : > The problem could be anywhere -- perhaps take out the disc from the > usb caddy and put it onto a bare IDE interface and try SMART? > The disc or USB caddy could be faulty. I'm quite sure now that the USB disk is faulty. After running for some month now a similiar error occured: Dockstar was still running, the DSL connection was up and it did route to the internet. But all daemons apparently have crashed: no ssh login anymore, no dhcpd service and http server crashed, too. When I plug the disk to my PC or notebook I'm getting these messages in /var/log/messages in an endless loop: ay 5 20:54:33 pinkfloyd kernel: [ 440.520511] sd 15:0:0:0: [sdd] Attached SCSI disk May 5 20:54:36 pinkfloyd kernel: [ 442.989369] sd 15:0:0:0: [sdd] Unhandled sense code May 5 20:54:36 pinkfloyd kernel: [ 442.989373] sd 15:0:0:0: [sdd] Result: hostbyte=0x00 driverbyte=0x08 May 5 20:54:36 pinkfloyd kernel: [ 442.989376] sd 15:0:0:0: [sdd] Sense Key : 0x3 [current] May 5 20:54:36 pinkfloyd kernel: [ 442.989379] sd 15:0:0:0: [sdd] ASC=0x11 ASCQ=0x0 May 5 20:54:36 pinkfloyd kernel: [ 442.989381] sd 15:0:0:0: [sdd] CDB: cdb[0]=0x28: 28 00 00 41 73 4c 00 00 07 00 May 5 20:54:39 pinkfloyd kernel: [ 445.794887] sd 15:0:0:0: [sdd] Unhandled sense code May 5 20:54:39 pinkfloyd kernel: [ 445.794890] sd 15:0:0:0: [sdd] Result: hostbyte=0x00 driverbyte=0x08 May 5 20:54:39 pinkfloyd kernel: [ 445.794893] sd 15:0:0:0: [sdd] Sense Key : 0x3 [current] May 5 20:54:39 pinkfloyd kernel: [ 445.794896] sd 15:0:0:0: [sdd] ASC=0x11 ASCQ=0x0 May 5 20:54:39 pinkfloyd kernel: [ 445.794898] sd 15:0:0:0: [sdd] CDB: cdb[0]=0x28: 28 00 00 41 73 4c 00 00 07 00 -- Thorsten M?hlfelder Salix OS: www.salixos.org From louigi600 at yahoo.it Fri May 6 06:59:14 2011 From: louigi600 at yahoo.it (Davide) Date: Fri, 6 May 2011 07:59:14 +0100 (BST) Subject: [ARMedslack] File system on my Freeagent Dockstar got corrupted In-Reply-To: <20110506012924.28fa12ce@pinkfloyd.tm-net> Message-ID: <495369.85852.qm@web29715.mail.ird.yahoo.com> This is probably not the cause of your problems but it's something you want to keep in mind anyway: Running non flash oriented journaled file-systems on flash based devices can ware them out very quickly especially if you are using MLB flash based device with a typical 10000 cycle rewrite capability. To minimize damage on flash devices at least make sure you mount the file-system with noatime option to avoid rewriting an entire erase block just because something accessed a file. Best regards David --- Ven 6/5/11, Thorsten M?hlfelder ha scritto: > Da: Thorsten M?hlfelder > Oggetto: Re: [ARMedslack] File system on my Freeagent Dockstar got corrupted > A: armedslack at lists.armedslack.org > Data: Venerd? 6 maggio 2011, 01:29 > Am Fri, 18 Feb 2011 09:20:44 +0000 > (GMT) > schrieb Stuart Winter : > > > The problem could be anywhere -- perhaps take out the > disc from the > > usb caddy and put it onto a bare IDE interface and try > SMART? > > The disc or USB caddy could be faulty. > > I'm quite sure now that the USB disk is faulty. After > running for some > month now a similiar error occured: > Dockstar was still running, the DSL connection was up and > it did route > to the internet. But all daemons apparently have crashed: > no ssh login > anymore, no dhcpd service and http server crashed, too. > > When I plug the disk to my PC or notebook I'm getting these > messages > in /var/log/messages in an endless loop: > ay? 5 20:54:33 pinkfloyd kernel: [? 440.520511] > sd 15:0:0:0: [sdd] Attached SCSI disk > May? 5 20:54:36 pinkfloyd kernel: [? 442.989369] > sd 15:0:0:0: [sdd] Unhandled sense code > May? 5 20:54:36 pinkfloyd kernel: [? 442.989373] > sd 15:0:0:0: [sdd] Result: hostbyte=0x00 driverbyte=0x08 > May? 5 20:54:36 pinkfloyd kernel: [? 442.989376] > sd 15:0:0:0: [sdd] Sense Key : 0x3 [current] > May? 5 20:54:36 pinkfloyd kernel: [? 442.989379] > sd 15:0:0:0: [sdd] ASC=0x11 ASCQ=0x0 > May? 5 20:54:36 pinkfloyd kernel: [? 442.989381] > sd 15:0:0:0: [sdd] CDB: cdb[0]=0x28: 28 00 00 41 73 4c 00 00 > 07 00 > May? 5 20:54:39 pinkfloyd kernel: [? 445.794887] > sd 15:0:0:0: [sdd] Unhandled sense code > May? 5 20:54:39 pinkfloyd kernel: [? 445.794890] > sd 15:0:0:0: [sdd] Result: hostbyte=0x00 driverbyte=0x08 > May? 5 20:54:39 pinkfloyd kernel: [? 445.794893] > sd 15:0:0:0: [sdd] Sense Key : 0x3 [current] > May? 5 20:54:39 pinkfloyd kernel: [? 445.794896] > sd 15:0:0:0: [sdd] ASC=0x11 ASCQ=0x0 > May? 5 20:54:39 pinkfloyd kernel: [? 445.794898] > sd 15:0:0:0: [sdd] CDB: cdb[0]=0x28: 28 00 00 41 73 4c 00 00 > 07 00 > > > -- > Thorsten M?hlfelder > Salix OS: www.salixos.org > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > From louigi600 at yahoo.it Fri May 6 07:19:36 2011 From: louigi600 at yahoo.it (Davide) Date: Fri, 6 May 2011 08:19:36 +0100 (BST) Subject: [ARMedslack] R: R: R: R: micro root rescue system In-Reply-To: <753767.17772.qm@web29702.mail.ird.yahoo.com> Message-ID: <978643.55414.qm@web29703.mail.ird.yahoo.com> I put the image on diet and now it fits in 32 Mb (without summery on the jffs2 image): root at hp:/mnt/hd/usr/src# du -ks rootfs_surap_busybox.jffs2 31892 rootfs_surap_busybox.jffs2 root at hp:/mnt/hd/usr/src# This is what's in the system: root at hp:/mnt/hd/usr/src/surap_packages# du -ms * |sort -n 1 apr-util-1.3.10-arm-1.tgz 1 at-3.1.12-arm-1.tgz 1 busybox-1.18.4-arm-1.tgz 1 dnsmasq-2.52-arm-1.tgz 1 dropbear-0.53.1-arm-1.tgz 1 hostapd-0.7.3-arm-1.tgz 1 iptables-1.4.10-arm-1.tgz 1 iw-0.9.20-arm-1.tgz 1 ppp-2.4.5-arm-1.tgz 1 sqlite-3.7.3-arm-1.tgz 1 udev-165-arm-2.tgz 1 usb_modeswitch-1.1.6-arm-1.tgz 1 wireless-tools-29-arm-2.tgz 2 kernel-firmware-2.6.38.3-noarch-1.tgz 3 php-5.3.6-arm-1.tgz 5 microroot_libs-arm-1.tgz 12 kernel_2.6.38.3-microkirkwood-arm-1.tgz I've not got around to get all the pppd helping stuff, master mode upun wifi gongle plugin ... etc stuff working but the base system is working and could be used as a slackware like rescue system. The busybox build is pretty much a complete buld and has nearly everything enebled including nand utilities. Anyone intrested ? --- Gio 5/5/11, Davide ha scritto: > Da: Davide > Oggetto: [ARMedslack] R: R: R: micro root rescue system > A: "Slackware ARM port" > Data: Gioved? 5 maggio 2011, 10:15 > Busybox has an internal micro web > server > root at surap:~# busybox httpd --help > BusyBox v1.18.4 (2011-04-20 14:04:26 BST) multi-call > binary. > > Usage: httpd [-ifv[v]] [-c CONFFILE] [-p [IP:]PORT] [-u > USER[:GRP]] [-r REALM] [-h HOME] > or httpd -d/-e/-m STRING > > Listen for incoming HTTP requests > > Options: > ? ? ? ? -i? ? ? ? > ? ? ? Inetd mode > ? ? ? ? -f? ? ? ? > ? ? ? Don't daemonize > ? ? ? ? -v[v]? ? ? > ? ???Verbose > ? ? ? ? -p [IP:]PORT? ? Bind > to IP:PORT (default *:80) > ? ? ? ? -u > USER[:GRP]???Set uid/gid after binding to > port > ? ? ? ? -r REALM? ? ? > ? Authentication Realm for Basic Authentication > ? ? ? ? -h HOME? ? ? > ???Home directory (default .) > ? ? ? ? -c FILE? ? ? > ???Configuration file (default > {/etc,HOME}/httpd.conf) > ? ? ? ? -m STRING? ? > ???MD5 crypt STRING > ? ? ? ? -e STRING? ? > ???HTML encode STRING > ? ? ? ? -d STRING? ? > ???URL decode STRING > > I'll be getting rid of apache in the microroot system > > --- Mer 4/5/11, Davide > ha scritto: > > > Da: Davide > > Oggetto: [ARMedslack] R:? R:? micro root > rescue system > > A: "Slackware ARM port" > > Data: Mercoled? 4 maggio 2011, 00:57 > > Ok I've the first working image with > > all the basics working. > > > > This is what's in the image: > > root at hp:/mnt/hd/usr/src/surap_packages# ls > > at-3.1.12-arm-1.tgz? ? ? ? ? > > ? iptables-1.4.10-arm-1.tgz > > busybox-1.18.4-arm-1.tgz? ? > > ???iw-0.9.20-arm-1.tgz > > dnsmasq-2.52-arm-1.tgz? ? ? > > ???kernel-firmware-2.6.38.3-noarch-1.tgz > > dropbear-0.53.1-arm-1.tgz? ? ? > > kernel_2.6.38.3-microkirkwood-arm-1.tgz > > php-5.3.5-arm-1.tgz? ? ? ? ? > > ? glibc-solibs-2.13-arm-1.tgz? > > ppp-2.4.5-arm-1.tgz? ? ? ? ? > > ? hostapd-0.7.3-arm-1.tgz? ? ? > > udev-165-arm-2.tgz? ? ? ? ? > > ???httpd-2.2.17-arm-2.tgz? ? > > ??? > > usb_modeswitch-1.1.6-arm-1.tgz > wireless-tools-29-arm-2.tgz > > root at hp:/mnt/hd/usr/src/surap_packages# > > and a few other required libs picked manually > > > > The compressed and unsummed jffs2 is 41Mb big > > > > root at hp:/mnt/hd/usr/src/surap_packages# du -ms > > ../surap_busybox.jffs2 > > 41? ? ? ../surap_busybox.jffs2 > > root at hp:/mnt/hd/usr/src/surap_packages# > > > > usb_modeswitch will not work because it needs tclsh > and I > > don't want to add it unless it's really necessary. > I'll try > > working around the problem with pure busybox ash > scripting > > ... if that's not possible I'll write a small c > program to > > help out ash. > > > > Regards > > David > > > > --- Mar 3/5/11, Davide > > ha scritto: > > > > > Da: Davide > > > Oggetto: [ARMedslack] R:? micro root rescue > > system > > > A: "Slackware ARM port" > > > Data: Marted? 3 maggio 2011, 08:43 > > > I struck another little problem while > > > trying to keep things as much slackware as > possible: > > > busybox default shell (the most complete one) > seems to > > have > > > no support for arrays. Slackware's > > /etc/rc.d/rc.inet1.conf > > > is all array config file. > > > > > > In order to at least keep the same parameter > names > > with no > > > array index I moved to making > ifcfg. > > whose > > > contents would be the unindexed variables for > each > > > interface. Now this is a bit redhatish but I was > > unable to > > > think of any other slackware like solution with > no > > arrays. > > > > > > Anyone have any idea ? > > > > > > Regards > > > David > > > > > > --- Ven 22/4/11, Davide > > > ha scritto: > > > > > > > Da: Davide > > > > Oggetto: [ARMedslack] micro root rescue > system > > > > A: "Slackware ARM port" > > > > Data: Venerd? 22 Aprile 2011, 11:45 > > > > Sorry for starting a new thread on > > > > something that was started elsewhere .... > but > > maybe > > > the > > > > shoot-off needs better attention with a new > > thread. > > > > > > > > >> This is a mix of a few I built > myself > > and > > > some > > > > gotten from current. > > > > >> This is what I'll be working with > and > > should > > > fit > > > > in a compressed > > > > >> jffs2 image 64Mb big. > > > > >> > root at slackware:/usr/src/surap_packages# > > du > > > -ms * | > > > > sort -n > > > > >> 1 ? busybox-1.18.4-arm-1.tgz > > > > >> 1? ? dropbear-0.53.1-arm-1.tgz > > > > >> 1 ? hostapd-0.7.3-arm-1.tgz > > > > >> 1? ? iptables-1.4.10-arm-1.tgz > > > > >> 1 ???iw-0.9.20-arm-1.tgz > > > > >> 1 ???ppp-2.4.5-arm-1.tgz > > > > >> 1 ???udev-165-arm-2.tgz > > > > >> 1? ? > usb_modeswitch-1.1.6-arm-1.tgz > > > > >> 1? ? wireless-tools-29-arm-2.tgz > > > > >> 2? ? httpd-2.2.17-arm-2.tgz > > > > >> 2? ? > > kernel-firmware-2.6.38.3-noarch-1.tgz > > > > >> 5? ? glibc-solibs-2.13-arm-1.tgz > > > > >> 8? ? > > kernel_kirkwood-2.6.38.3-arm-1.tgz > > > > >> 10?? php-5.3.5-arm-1.tgz > > > > >> > > > > > > > > > > 15???kernel-modules-kirkwood-2.6.38.3_kirkwood-arm-1.tgz > > > > >> > root at slackware:/usr/src/surap_packages# > > du > > > -ms . > > > > >> 43? ? ? . > > > > >> > root at slackware:/usr/src/surap_packages# > > > > >> > > > > >> Since booting from jffs2 image does > not > > > require > > > > initrd ... and maybe > > > > >> one can do without documentation > .... > > I'll > > > see if > > > > I can fit that in a > > > > >> 32Mb image. > > > > >> > > > > > Build a custom kernel with few modules > ;) > > > > > > > > I will strip all unnecessary modules for a > > rescue > > > system, > > > > remove initrd, strip documentation and carve > down > > as > > > much as > > > > possible ... if it won't fit I'll consider > thttpd > > and > > > some > > > > lighter web scripting language. Maybe web > stuff > > is > > > not > > > > really necessary for a rescue system > anyway. > > > > > > > > Now I've a question. > > > > there are 2 ways to do this: > > > > 1) repackage the single packages and append > some > > > suffix to > > > > distinguish them from the standard > packages, > > possibly > > > modify > > > > the build scripts for them so that future > > maintenance > > > will > > > > be easier, > > > > > > > > 2) just shove everything needed somewhere > and > > remove > > > all > > > > that is not needed and then build the jffs2 > > image. > > > > > > > > Now if this micro root system is just going > to be > > my > > > > personal AP/3g/NAS/router/rescue the second > way > > will > > > take > > > > much less effort, on the other hand if you > like > > the > > > idea of > > > > having an armedslack micro root system that > will > > be > > > more > > > > then just a rescue system and possibly fit > in a > > 32Mb > > > > compressed image; well then we should go > about > > the > > > first > > > > way. > > > > I say we because I'm just a user and even if > I do > > most > > > of > > > > the dirty work I'll need assistance from > the > > > ARMedslack team > > > > to do some of the required actions if this > is of > > any > > > > interest to ARMedslack community. > > > > > > > > I've no reservation in sharing my work as I > > consider > > > all my > > > > work GPL + it's mainly just administration > so > > the > > > question > > > > really is: Does armedslack want a smart > micro > > root > > > system ? > > > > > > > > Best regards > > > > David Rao > > > > > > > > > _______________________________________________ > > > > 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 > > > > > _______________________________________________ > > 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 thenktor at gmx.de Fri May 6 07:42:59 2011 From: thenktor at gmx.de (Thorsten =?ISO-8859-1?B?TfxobGZlbGRlcg==?=) Date: Fri, 6 May 2011 09:42:59 +0200 Subject: [ARMedslack] File system on my Freeagent Dockstar got corrupted In-Reply-To: <495369.85852.qm@web29715.mail.ird.yahoo.com> References: <20110506012924.28fa12ce@pinkfloyd.tm-net> <495369.85852.qm@web29715.mail.ird.yahoo.com> Message-ID: <20110506094259.17ec2089@pinkfloyd.tm-net> Am Fri, 6 May 2011 07:59:14 +0100 (BST) schrieb Davide : > This is probably not the cause of your problems but it's something > you want to keep in mind anyway: Running non flash oriented journaled > file-systems on flash based devices can ware them out very quickly No that's not the problem because this is a Seagate Freeagent Go hard disk. > especially if you are using MLB flash based device with a typical > 10000 cycle rewrite capability. To minimize damage on flash devices > at least make sure you mount the file-system with noatime option to > avoid rewriting an entire erase block just because something accessed > a file. The error message indicates that the USB part of the hard disk is broken. Unfortunately I cannot open the USB case without damaging a warranty seal, so I cannot save my data. I have to find a Windows PC now to run the Seagate test tools. This is mandatory for a warranty request. > --- Ven 6/5/11, Thorsten M?hlfelder ha scritto: > > > Da: Thorsten M?hlfelder > > Oggetto: Re: [ARMedslack] File system on my Freeagent Dockstar got > > corrupted A: armedslack at lists.armedslack.org > > Data: Venerd? 6 maggio 2011, 01:29 > > Am Fri, 18 Feb 2011 09:20:44 +0000 > > (GMT) > > schrieb Stuart Winter : > > > > > The problem could be anywhere -- perhaps take out the > > disc from the > > > usb caddy and put it onto a bare IDE interface and try > > SMART? > > > The disc or USB caddy could be faulty. > > > > I'm quite sure now that the USB disk is faulty. After > > running for some > > month now a similiar error occured: > > Dockstar was still running, the DSL connection was up and > > it did route > > to the internet. But all daemons apparently have crashed: > > no ssh login > > anymore, no dhcpd service and http server crashed, too. > > > > When I plug the disk to my PC or notebook I'm getting these > > messages > > in /var/log/messages in an endless loop: > > ay? 5 20:54:33 pinkfloyd kernel: [? 440.520511] > > sd 15:0:0:0: [sdd] Attached SCSI disk > > May? 5 20:54:36 pinkfloyd kernel: [? 442.989369] > > sd 15:0:0:0: [sdd] Unhandled sense code > > May? 5 20:54:36 pinkfloyd kernel: [? 442.989373] > > sd 15:0:0:0: [sdd] Result: hostbyte=0x00 driverbyte=0x08 > > May? 5 20:54:36 pinkfloyd kernel: [? 442.989376] > > sd 15:0:0:0: [sdd] Sense Key : 0x3 [current] > > May? 5 20:54:36 pinkfloyd kernel: [? 442.989379] > > sd 15:0:0:0: [sdd] ASC=0x11 ASCQ=0x0 > > May? 5 20:54:36 pinkfloyd kernel: [? 442.989381] > > sd 15:0:0:0: [sdd] CDB: cdb[0]=0x28: 28 00 00 41 73 4c 00 00 > > 07 00 > > May? 5 20:54:39 pinkfloyd kernel: [? 445.794887] > > sd 15:0:0:0: [sdd] Unhandled sense code > > May? 5 20:54:39 pinkfloyd kernel: [? 445.794890] > > sd 15:0:0:0: [sdd] Result: hostbyte=0x00 driverbyte=0x08 > > May? 5 20:54:39 pinkfloyd kernel: [? 445.794893] > > sd 15:0:0:0: [sdd] Sense Key : 0x3 [current] > > May? 5 20:54:39 pinkfloyd kernel: [? 445.794896] > > sd 15:0:0:0: [sdd] ASC=0x11 ASCQ=0x0 > > May? 5 20:54:39 pinkfloyd kernel: [? 445.794898] > > sd 15:0:0:0: [sdd] CDB: cdb[0]=0x28: 28 00 00 41 73 4c 00 00 > > 07 00 > > > > > > -- > > Thorsten M?hlfelder > > Salix OS: www.salixos.org > > _______________________________________________ > > 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 -- Thorsten M?hlfelder Salix OS: www.salixos.org From louigi600 at yahoo.it Fri May 6 09:26:56 2011 From: louigi600 at yahoo.it (Davide) Date: Fri, 6 May 2011 10:26:56 +0100 (BST) Subject: [ARMedslack] qemu raw image partition offset calculation Message-ID: <330868.8181.qm@web29720.mail.ird.yahoo.com> It's often handy to know the physical offset of the first partition of a qemu raw disk image. If you do not use raw images you can convert it to raw ... do what you need and convert it back. I've not yet found a reliable way of mounting non raw images from ordinary linux OS. You can use this trick to populate a qemu disk image with an armedslack miniroot sistem image directky from your linux x86 box. Unfortunatelly the offset depends on the geometry of the disk image. Here's how I guess the correct offset: the firs block of the firs partition is located in: the first sector of the second track it will be located in * 512 example: fdisk -l qemu_hdu.raw Disk qemu_hdu.raw: 0 MB, 0 bytes 5 heads, 54 sectors/track, 0 cylinders Units = cylinders of 270 * 512 = 138240 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System qemu_hdu.raw1 1 1016 137133 83 Linux the firs partition of this image (qemu_hdu.raw1) will begin: (54 * 512) = 27648 Ho do you go about creating the filesystem from the x86 linux box: What folows creates an ext2 filesystem on the first partition of the qemu raw disk image and subsequently mount is so that you can polulate it. # losetup -o /dev/loop0 qemu_hdu.raw # mke2fs -b 4096 -i 16384 -m 1 -L surap_root /dev/loop0 # mount /dev/loop0 /mnt/tmp/ Hope this helps David From louigi600 at yahoo.it Mon May 9 05:41:30 2011 From: louigi600 at yahoo.it (Davide) Date: Mon, 9 May 2011 06:41:30 +0100 (BST) Subject: [ARMedslack] Trouble with udev on busybox based system Message-ID: <535837.61163.qm@web29719.mail.ird.yahoo.com> Ok this is a little off topic but since I'm trying to make it look as close as possible to a slackware system I thaught it could fit here anyway. Although I did my best to adapt all the scripts around /etc/rc.d and /lib/udev to work correctly with busybox (sh and slightly different PATH): udev is not doing it's work correctly. udevd start apparently correctly but none of the modules that should be loaded automatically actually get loaded. For instance in order to see the Ethernet nic I;ve to load manually mv643xx_eth, or if I want to use a usb flash stick I've to do quite a bit of manual module loading. Having a look at armedslack's rc.modules I see that basically it's empty as far as dockstar is concerned so all the modules do get auto loaded correctly. No as far as kernel is concerned I'm using the exact same setup on the busybox environment that is on the armedslack miniroot system on onboard flash (I stopped using the kernel I compiled) and both boot without initrd so no module loading can be done by initrd. Anyone have any idea how I could go about debugging this issue ? or even better have any idea howto fix it ? Regards David From m-lists at biscuit.org.uk Mon May 9 06:22:14 2011 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Mon, 9 May 2011 07:22:14 +0100 (BST) Subject: [ARMedslack] qemu raw image partition offset calculation In-Reply-To: <330868.8181.qm@web29720.mail.ird.yahoo.com> References: <330868.8181.qm@web29720.mail.ird.yahoo.com> Message-ID: Yep this is all good stuff. ftp://ftp.armedslack.org/armedslack/armedslack-devtools/sheevaplug/qemu-to-sheeva.txt I haven't digested everything you've put down but the above URL is how I bootstrapped armedslack onto the sheevaplug -- converting a qemu installation back to a bootable hard disk. On Fri, 6 May 2011, Davide wrote: > It's often handy to know the physical offset of the first partition of a qemu raw disk image. > If you do not use raw images you can convert it to raw ... do what you need and convert it back. > I've not yet found a reliable way of mounting non raw images from ordinary linux OS. > You can use this trick to populate a qemu disk image with an armedslack miniroot sistem image directky from your linux x86 box. > > Unfortunatelly the offset depends on the geometry of the disk image. > Here's how I guess the correct offset: > > the firs block of the firs partition is located in: > the first sector of the second track > it will be located in * 512 > > example: > fdisk -l qemu_hdu.raw > Disk qemu_hdu.raw: 0 MB, 0 bytes > 5 heads, 54 sectors/track, 0 cylinders > Units = cylinders of 270 * 512 = 138240 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disk identifier: 0x00000000 > > Device Boot Start End Blocks Id System > qemu_hdu.raw1 1 1016 137133 83 Linux > > the firs partition of this image (qemu_hdu.raw1) will begin: > (54 * 512) = 27648 > > > > Ho do you go about creating the filesystem from the x86 linux box: > > What folows creates an ext2 filesystem on the first partition of the > qemu raw disk image and subsequently mount is so that you can polulate it. > > # losetup -o /dev/loop0 qemu_hdu.raw > # mke2fs -b 4096 -i 16384 -m 1 -L surap_root /dev/loop0 > # mount /dev/loop0 /mnt/tmp/ > > Hope this helps > David > > > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > -- Stuart Winter Slackware ARM: www.armedslack.org From louigi600 at yahoo.it Mon May 9 06:30:23 2011 From: louigi600 at yahoo.it (Davide) Date: Mon, 9 May 2011 07:30:23 +0100 (BST) Subject: [ARMedslack] qemu raw image partition offset calculation In-Reply-To: Message-ID: <745792.91142.qm@web29712.mail.ird.yahoo.com> Not sure what you're not digesting but if I can help make things more clear I will ... just tell me what's not so clear. I wanted to do hings in the other direction: from a miniroot fs image (or my microroot system) to a qemu disk image so that I can do testing without having the dockstar around in the office. I had trouble starting from a blank disk image created with the qemu-img tool and populating it with what I wanted without going trough any installation. Regards David --- Lun 9/5/11, Stuart Winter ha scritto: > Da: Stuart Winter > Oggetto: Re: [ARMedslack] qemu raw image partition offset calculation > A: "Slackware ARM port" > Data: Luned? 9 maggio 2011, 08:22 > > Yep this is all good stuff. > ftp://ftp.armedslack.org/armedslack/armedslack-devtools/sheevaplug/qemu-to-sheeva.txt > > I haven't digested everything you've put down but the above > URL is how I > bootstrapped armedslack onto the sheevaplug -- converting a > qemu > installation back to a bootable hard disk. > > On Fri, 6 May 2011, Davide wrote: > > > It's often handy to know the physical offset of the > first partition of a qemu raw disk image. > > If you do not use raw images you can convert it to raw > ... do what you need and convert it back. > > I've not yet found a reliable way of mounting non raw > images from ordinary linux OS. > > You can use this trick to populate a qemu disk image > with an armedslack miniroot sistem image directky from your > linux x86 box. > > > > Unfortunatelly the offset depends on the geometry of > the disk image. > > Here's how I guess the correct offset: > > > > the firs block of the firs partition is located in: > > the first sector of the second track > > it will be located in * 512 > > > > example: > > fdisk -l qemu_hdu.raw > > Disk qemu_hdu.raw: 0 MB, 0 bytes > > 5 heads, 54 sectors/track, 0 cylinders > > Units = cylinders of 270 * 512 = 138240 bytes > > Sector size (logical/physical): 512 bytes / 512 bytes > > I/O size (minimum/optimal): 512 bytes / 512 bytes > > Disk identifier: 0x00000000 > > > >? ? ? ? Device Boot? ? > ? Start? ? ? ???End? > ? ? Blocks???Id? System > > qemu_hdu.raw1? ? ? ? ? ? > ???1? ? ? ? 1016? > ? ? 137133???83? Linux > > > > the firs partition of this image (qemu_hdu.raw1) will > begin: > > (54 * 512) = 27648 > > > > > > > > Ho do you go about creating the filesystem from the > x86 linux box: > > > > What folows creates an ext2 filesystem on the first > partition of the > > qemu raw disk image and subsequently mount is so that > you can polulate it. > > > > # losetup -o > /dev/loop0? qemu_hdu.raw > > # mke2fs -b 4096 -i 16384 -m 1 -L surap_root > /dev/loop0 > > # mount /dev/loop0 /mnt/tmp/ > > > > Hope this helps > > David > > > > > > _______________________________________________ > > ARMedslack mailing list > > ARMedslack at lists.armedslack.org > > http://lists.armedslack.org/mailman/listinfo/armedslack > > > > -- > Stuart Winter > Slackware ARM: www.armedslack.org > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > From louigi600 at yahoo.it Mon May 9 06:32:48 2011 From: louigi600 at yahoo.it (Davide) Date: Mon, 9 May 2011 07:32:48 +0100 (BST) Subject: [ARMedslack] R: Trouble with udev on busybox based system In-Reply-To: <535837.61163.qm@web29719.mail.ird.yahoo.com> Message-ID: <260328.98545.qm@web29719.mail.ird.yahoo.com> Ok ... I started udevd with --debug and dumped stderr to somewhere I could read it. This is what came out (the intresting part): 5584.430610 [1032] udev_rules_apply_to_event: RUN '/sbin/modprobe -bv $env{MODA LIAS}' /lib/udev/rules.d/80-drivers.rules:5 5584.430746 [1032] util_run_program: '/sbin/modprobe -bv usb:vFFEEp0100d0100dc0 0dsc00dp00ic08isc06ip50' started 5584.435842 [1032] util_run_program: '/sbin/modprobe' (stderr) '/sbin/modprobe: invalid option -- 'b'' 5584.459928 [1032] util_run_program: '/sbin/modprobe' (stderr) 'BusyBox v1.18.4 (2011-04-20 14:04:26 BST)' 5584.460090 [1032] util_run_program: '/sbin/modprobe' (stderr) ' multi-call bin ary.' 5584.460178 [1032] util_run_program: '/sbin/modprobe' (stderr) '' 5584.460204 [1032] util_run_program: '/sbin/modprobe' (stderr) 'Usage: ' 5584.460278 [1032] util_run_program: '/sbin/modprobe' (stderr) 'modprobe' 5584.460379 [1032] util_run_program: '/sbin/modprobe' (stderr) ' ' 5584.460464 [1032] util_run_program: '/sbin/modprobe' (stderr) '[-qfwrsv] MODUL E [symbol=value]...' 5584.460489 [1032] util_run_program: '/sbin/modprobe' (stderr) '' 5584.460509 [1032] util_run_program: '/sbin/modprobe' (stderr) 'Options:' 5584.460530 [1032] util_run_program: '/sbin/modprobe' (stderr) ' -r Remove MODULE (stacks) or do autoclean' 5584.460550 [1032] util_run_program: '/sbin/modprobe' (stderr) ' -q It looks like udev is modprobing with options busybox modprobe does not understand. Is this stuff hard coded in the source or is it in some script ? Regards David --- Lun 9/5/11, Davide ha scritto: > Da: Davide > Oggetto: [ARMedslack] Trouble with udev on busybox based system > A: armedslack at lists.armedslack.org > Data: Luned? 9 maggio 2011, 07:41 > Ok this is a little off topic but > since I'm trying to make it look as close as possible to a > slackware system I thaught it could fit here anyway. > > Although I did my best to adapt all the scripts around > /etc/rc.d and /lib/udev to work correctly with busybox (sh > and slightly different PATH): udev is not doing it's work > correctly. > > udevd start apparently correctly but none of the modules > that should be loaded automatically actually get loaded. > For instance in order to see the Ethernet nic I;ve to load > manually mv643xx_eth, or if I want to use a usb flash stick > I've to do quite a bit of manual module loading. > Having a look at armedslack's rc.modules I see that > basically it's empty as far as dockstar is concerned so all > the modules do get auto loaded correctly. > No as far as kernel is concerned I'm using the exact same > setup on the busybox environment that is on the armedslack > miniroot system on onboard flash (I stopped using the kernel > I compiled) and both boot without initrd so no module > loading can be done by initrd. > > Anyone have any idea how I could go about debugging this > issue ? or even better have any idea howto fix it ? > > Regards > David > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > From louigi600 at yahoo.it Mon May 9 06:42:38 2011 From: louigi600 at yahoo.it (Davide) Date: Mon, 9 May 2011 07:42:38 +0100 (BST) Subject: [ARMedslack] R: R: Trouble with udev on busybox based system In-Reply-To: <260328.98545.qm@web29719.mail.ird.yahoo.com> Message-ID: <361449.46558.qm@web29710.mail.ird.yahoo.com> Could not grep modprobe in the udev scripts nor in the binary (with the aid of strings) ... so I looked in the rules.d and there it was. But busybox modprobe does not support blacklists ... hope it won't hurt. Regards David --- Lun 9/5/11, Davide ha scritto: > Da: Davide > Oggetto: [ARMedslack] R: Trouble with udev on busybox based system > A: "Slackware ARM port" > Data: Luned? 9 maggio 2011, 08:32 > Ok ... I started udevd with --debug > and dumped stderr to somewhere I could read it. This is what > came out (the intresting part): > 5584.430610 [1032] udev_rules_apply_to_event: RUN > '/sbin/modprobe -bv $env{MODA > LIAS}' /lib/udev/rules.d/80-drivers.rules:5 > 5584.430746 [1032] util_run_program: '/sbin/modprobe -bv > usb:vFFEEp0100d0100dc0 > 0dsc00dp00ic08isc06ip50' started > 5584.435842 [1032] util_run_program: '/sbin/modprobe' > (stderr) '/sbin/modprobe: > invalid option -- 'b'' > 5584.459928 [1032] util_run_program: '/sbin/modprobe' > (stderr) 'BusyBox v1.18.4 > (2011-04-20 14:04:26 BST)' > 5584.460090 [1032] util_run_program: '/sbin/modprobe' > (stderr) ' multi-call bin > ary.' > 5584.460178 [1032] util_run_program: '/sbin/modprobe' > (stderr) '' > 5584.460204 [1032] util_run_program: '/sbin/modprobe' > (stderr) 'Usage: ' > 5584.460278 [1032] util_run_program: '/sbin/modprobe' > (stderr) 'modprobe' > 5584.460379 [1032] util_run_program: '/sbin/modprobe' > (stderr) ' ' > 5584.460464 [1032] util_run_program: '/sbin/modprobe' > (stderr) '[-qfwrsv] MODUL > E [symbol=value]...' > 5584.460489 [1032] util_run_program: '/sbin/modprobe' > (stderr) '' > 5584.460509 [1032] util_run_program: '/sbin/modprobe' > (stderr) 'Options:' > 5584.460530 [1032] util_run_program: '/sbin/modprobe' > (stderr) '? ? ? ? -r > ? ? ? ? Remove MODULE (stacks) or do > autoclean' > 5584.460550 [1032] util_run_program: '/sbin/modprobe' > (stderr) '? ? ? ? -q > > It looks like udev is modprobing with options busybox > modprobe does not understand. > > Is this stuff hard coded in the source or is it in some > script ? > > Regards > David > > --- Lun 9/5/11, Davide > ha scritto: > > > Da: Davide > > Oggetto: [ARMedslack] Trouble with udev on busybox > based system > > A: armedslack at lists.armedslack.org > > Data: Luned? 9 maggio 2011, 07:41 > > Ok this is a little off topic but > > since I'm trying to make it look as close as possible > to a > > slackware system I thaught it could fit here anyway. > > > > Although I did my best to adapt all the scripts > around > > /etc/rc.d and /lib/udev to work correctly with busybox > (sh > > and slightly different PATH): udev is not doing it's > work > > correctly. > > > > udevd start apparently correctly but none of the > modules > > that should be loaded automatically actually get > loaded. > > For instance in order to see the Ethernet nic I;ve to > load > > manually mv643xx_eth, or if I want to use a usb flash > stick > > I've to do quite a bit of manual module loading. > > Having a look at armedslack's rc.modules I see that > > basically it's empty as far as dockstar is concerned > so all > > the modules do get auto loaded correctly. > > No as far as kernel is concerned I'm using the exact > same > > setup on the busybox environment that is on the > armedslack > > miniroot system on onboard flash (I stopped using the > kernel > > I compiled) and both boot without initrd so no module > > loading can be done by initrd. > > > > Anyone have any idea how I could go about debugging > this > > issue ? or even better have any idea howto fix it ? > > > > Regards > > David > > _______________________________________________ > > 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 louigi600 at yahoo.it Mon May 9 08:58:15 2011 From: louigi600 at yahoo.it (Davide) Date: Mon, 9 May 2011 09:58:15 +0100 (BST) Subject: [ARMedslack] R: R: R: Trouble with udev on busybox based system In-Reply-To: <361449.46558.qm@web29710.mail.ird.yahoo.com> Message-ID: <837343.25750.qm@web29708.mail.ird.yahoo.com> Ok that got some module loading working automatically: the ethernet nic now comes up correctly at boot time and some usb stuff is also activated. But when I plug in a usb storage stick the device file does not get cteated and not all the modules get pulled in. Any ideas ? Regards David --- Lun 9/5/11, Davide ha scritto: > Da: Davide > Oggetto: [ARMedslack] R: R: Trouble with udev on busybox based system > A: "Slackware ARM port" > Data: Luned? 9 maggio 2011, 08:42 > Could not grep modprobe in the udev > scripts nor in the binary (with the aid of strings) ... so I > looked in the rules.d and there it was. > > But busybox modprobe does not support blacklists ... hope > it won't hurt. > > Regards > David > > --- Lun 9/5/11, Davide > ha scritto: > > > Da: Davide > > Oggetto: [ARMedslack] R:? Trouble with udev on > busybox based system > > A: "Slackware ARM port" > > Data: Luned? 9 maggio 2011, 08:32 > > Ok ... I started udevd with --debug > > and dumped stderr to somewhere I could read it. This > is what > > came out (the intresting part): > > 5584.430610 [1032] udev_rules_apply_to_event: RUN > > '/sbin/modprobe -bv $env{MODA > > LIAS}' /lib/udev/rules.d/80-drivers.rules:5 > > 5584.430746 [1032] util_run_program: '/sbin/modprobe > -bv > > usb:vFFEEp0100d0100dc0 > > 0dsc00dp00ic08isc06ip50' started > > 5584.435842 [1032] util_run_program: '/sbin/modprobe' > > (stderr) '/sbin/modprobe: > >? invalid option -- 'b'' > > 5584.459928 [1032] util_run_program: '/sbin/modprobe' > > (stderr) 'BusyBox v1.18.4 > >? (2011-04-20 14:04:26 BST)' > > 5584.460090 [1032] util_run_program: '/sbin/modprobe' > > (stderr) ' multi-call bin > > ary.' > > 5584.460178 [1032] util_run_program: '/sbin/modprobe' > > (stderr) '' > > 5584.460204 [1032] util_run_program: '/sbin/modprobe' > > (stderr) 'Usage: ' > > 5584.460278 [1032] util_run_program: '/sbin/modprobe' > > (stderr) 'modprobe' > > 5584.460379 [1032] util_run_program: '/sbin/modprobe' > > (stderr) ' ' > > 5584.460464 [1032] util_run_program: '/sbin/modprobe' > > (stderr) '[-qfwrsv] MODUL > > E [symbol=value]...' > > 5584.460489 [1032] util_run_program: '/sbin/modprobe' > > (stderr) '' > > 5584.460509 [1032] util_run_program: '/sbin/modprobe' > > (stderr) 'Options:' > > 5584.460530 [1032] util_run_program: '/sbin/modprobe' > > (stderr) '? ? ? ? -r > > ? ? ? ? Remove MODULE (stacks) or do > > autoclean' > > 5584.460550 [1032] util_run_program: '/sbin/modprobe' > > (stderr) '? ? ? ? -q > > > > It looks like udev is modprobing with options busybox > > modprobe does not understand. > > > > Is this stuff hard coded in the source or is it in > some > > script ? > > > > Regards > > David > > > > --- Lun 9/5/11, Davide > > ha scritto: > > > > > Da: Davide > > > Oggetto: [ARMedslack] Trouble with udev on > busybox > > based system > > > A: armedslack at lists.armedslack.org > > > Data: Luned? 9 maggio 2011, 07:41 > > > Ok this is a little off topic but > > > since I'm trying to make it look as close as > possible > > to a > > > slackware system I thaught it could fit here > anyway. > > > > > > Although I did my best to adapt all the scripts > > around > > > /etc/rc.d and /lib/udev to work correctly with > busybox > > (sh > > > and slightly different PATH): udev is not doing > it's > > work > > > correctly. > > > > > > udevd start apparently correctly but none of the > > modules > > > that should be loaded automatically actually get > > loaded. > > > For instance in order to see the Ethernet nic > I;ve to > > load > > > manually mv643xx_eth, or if I want to use a usb > flash > > stick > > > I've to do quite a bit of manual module loading. > > > Having a look at armedslack's rc.modules I see > that > > > basically it's empty as far as dockstar is > concerned > > so all > > > the modules do get auto loaded correctly. > > > No as far as kernel is concerned I'm using the > exact > > same > > > setup on the busybox environment that is on the > > armedslack > > > miniroot system on onboard flash (I stopped using > the > > kernel > > > I compiled) and both boot without initrd so no > module > > > loading can be done by initrd. > > > > > > Anyone have any idea how I could go about > debugging > > this > > > issue ? or even better have any idea howto fix it > ? > > > > > > Regards > > > David > > > _______________________________________________ > > > 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 > > > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > From m-lists at biscuit.org.uk Mon May 9 09:05:57 2011 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Mon, 9 May 2011 10:05:57 +0100 (BST) Subject: [ARMedslack] qemu raw image partition offset calculation In-Reply-To: <745792.91142.qm@web29712.mail.ird.yahoo.com> References: <745792.91142.qm@web29712.mail.ird.yahoo.com> Message-ID: Heh. I should wait a few hours after getting up to look at emails :-) On Mon, 9 May 2011, Davide wrote: > Not sure what you're not digesting but if I can help make things more clear I will ... just tell me what's not so clear. > > I wanted to do hings in the other direction: from a miniroot fs image > (or my microroot system) to a qemu disk image so that I can do testing > without having the dockstar around in the office. > > I had trouble starting from a blank disk image created with the qemu-img > tool and populating it with what I wanted without going trough any installation. From louigi600 at yahoo.it Mon May 9 13:32:57 2011 From: louigi600 at yahoo.it (Davide) Date: Mon, 9 May 2011 14:32:57 +0100 (BST) Subject: [ARMedslack] R: R: R: R: Trouble with udev on busybox based system In-Reply-To: <837343.25750.qm@web29708.mail.ird.yahoo.com> Message-ID: <843687.66404.qm@web29702.mail.ird.yahoo.com> Loking with more care at the verbose outout of udevd I found that things start to go wrong when this is issued: util_run_program: '/sbin/modprobe -v usb:v4586p1026d0050dc00dsc00dp00ic08isc06ip50' I tried at a command prompt and I get no error but also no module is loaded. I'm not actually sure what this should load because there is no module named just "usb" and I can't find any alias with that either. --- Lun 9/5/11, Davide ha scritto: > Da: Davide > Oggetto: [ARMedslack] R: R: R: Trouble with udev on busybox based system > A: "Slackware ARM port" > Data: Luned? 9 maggio 2011, 10:58 > Ok that got some module loading > working automatically: > the ethernet nic now comes up correctly at boot time and > some usb stuff is also activated. > But when I plug in a usb storage stick the device file does > not get cteated and not all the modules get pulled in. > > Any ideas ? > > Regards > David > > > --- Lun 9/5/11, Davide > ha scritto: > > > Da: Davide > > Oggetto: [ARMedslack] R:? R:? Trouble with > udev on busybox based system > > A: "Slackware ARM port" > > Data: Luned? 9 maggio 2011, 08:42 > > Could not grep modprobe in the udev > > scripts nor in the binary (with the aid of strings) > ... so I > > looked in the rules.d and there it was. > > > > But busybox modprobe does not support blacklists ... > hope > > it won't hurt. > > > > Regards > > David > > > > --- Lun 9/5/11, Davide > > ha scritto: > > > > > Da: Davide > > > Oggetto: [ARMedslack] R:? Trouble with udev on > > busybox based system > > > A: "Slackware ARM port" > > > Data: Luned? 9 maggio 2011, 08:32 > > > Ok ... I started udevd with --debug > > > and dumped stderr to somewhere I could read it. > This > > is what > > > came out (the intresting part): > > > 5584.430610 [1032] udev_rules_apply_to_event: > RUN > > > '/sbin/modprobe -bv $env{MODA > > > LIAS}' /lib/udev/rules.d/80-drivers.rules:5 > > > 5584.430746 [1032] util_run_program: > '/sbin/modprobe > > -bv > > > usb:vFFEEp0100d0100dc0 > > > 0dsc00dp00ic08isc06ip50' started > > > 5584.435842 [1032] util_run_program: > '/sbin/modprobe' > > > (stderr) '/sbin/modprobe: > > >? invalid option -- 'b'' > > > 5584.459928 [1032] util_run_program: > '/sbin/modprobe' > > > (stderr) 'BusyBox v1.18.4 > > >? (2011-04-20 14:04:26 BST)' > > > 5584.460090 [1032] util_run_program: > '/sbin/modprobe' > > > (stderr) ' multi-call bin > > > ary.' > > > 5584.460178 [1032] util_run_program: > '/sbin/modprobe' > > > (stderr) '' > > > 5584.460204 [1032] util_run_program: > '/sbin/modprobe' > > > (stderr) 'Usage: ' > > > 5584.460278 [1032] util_run_program: > '/sbin/modprobe' > > > (stderr) 'modprobe' > > > 5584.460379 [1032] util_run_program: > '/sbin/modprobe' > > > (stderr) ' ' > > > 5584.460464 [1032] util_run_program: > '/sbin/modprobe' > > > (stderr) '[-qfwrsv] MODUL > > > E [symbol=value]...' > > > 5584.460489 [1032] util_run_program: > '/sbin/modprobe' > > > (stderr) '' > > > 5584.460509 [1032] util_run_program: > '/sbin/modprobe' > > > (stderr) 'Options:' > > > 5584.460530 [1032] util_run_program: > '/sbin/modprobe' > > > (stderr) '? ? ? ? -r > > > ? ? ? ? Remove MODULE (stacks) or do > > > autoclean' > > > 5584.460550 [1032] util_run_program: > '/sbin/modprobe' > > > (stderr) '? ? ? ? -q > > > > > > It looks like udev is modprobing with options > busybox > > > modprobe does not understand. > > > > > > Is this stuff hard coded in the source or is it > in > > some > > > script ? > > > > > > Regards > > > David > > > > > > --- Lun 9/5/11, Davide > > > ha scritto: > > > > > > > Da: Davide > > > > Oggetto: [ARMedslack] Trouble with udev on > > busybox > > > based system > > > > A: armedslack at lists.armedslack.org > > > > Data: Luned? 9 maggio 2011, 07:41 > > > > Ok this is a little off topic but > > > > since I'm trying to make it look as close > as > > possible > > > to a > > > > slackware system I thaught it could fit > here > > anyway. > > > > > > > > Although I did my best to adapt all the > scripts > > > around > > > > /etc/rc.d and /lib/udev to work correctly > with > > busybox > > > (sh > > > > and slightly different PATH): udev is not > doing > > it's > > > work > > > > correctly. > > > > > > > > udevd start apparently correctly but none of > the > > > modules > > > > that should be loaded automatically actually > get > > > loaded. > > > > For instance in order to see the Ethernet > nic > > I;ve to > > > load > > > > manually mv643xx_eth, or if I want to use a > usb > > flash > > > stick > > > > I've to do quite a bit of manual module > loading. > > > > Having a look at armedslack's rc.modules I > see > > that > > > > basically it's empty as far as dockstar is > > concerned > > > so all > > > > the modules do get auto loaded correctly. > > > > No as far as kernel is concerned I'm using > the > > exact > > > same > > > > setup on the busybox environment that is on > the > > > armedslack > > > > miniroot system on onboard flash (I stopped > using > > the > > > kernel > > > > I compiled) and both boot without initrd so > no > > module > > > > loading can be done by initrd. > > > > > > > > Anyone have any idea how I could go about > > debugging > > > this > > > > issue ? or even better have any idea howto > fix it > > ? > > > > > > > > Regards > > > > David > > > > > _______________________________________________ > > > > 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 > > > > > _______________________________________________ > > 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 louigi600 at yahoo.it Mon May 9 14:01:47 2011 From: louigi600 at yahoo.it (Davide) Date: Mon, 9 May 2011 15:01:47 +0100 (BST) Subject: [ARMedslack] R: R: R: R: R: Trouble with udev on busybox based system In-Reply-To: <843687.66404.qm@web29702.mail.ird.yahoo.com> Message-ID: <185195.66820.qm@web29716.mail.ird.yahoo.com> I copied over to this system armedslack modprobe ant it eliminates the problem. I think I should be telling the busybox mailing list about this as it may be a busybox bug. Sorry for making noise. David --- Lun 9/5/11, Davide ha scritto: > Da: Davide > Oggetto: [ARMedslack] R: R: R: R: Trouble with udev on busybox based system > A: "Slackware ARM port" > Data: Luned? 9 maggio 2011, 15:32 > Loking with more care at the verbose > outout of udevd I found that things start to go wrong when > this is issued: > util_run_program: '/sbin/modprobe -v > usb:v4586p1026d0050dc00dsc00dp00ic08isc06ip50' > > I tried at a command prompt and I get no error but also no > module is loaded. > > I'm not actually sure what this should load because there > is no module named just "usb" and I can't find any alias > with that either. > > > > > --- Lun 9/5/11, Davide > ha scritto: > > > Da: Davide > > Oggetto: [ARMedslack] R: R: R: Trouble with udev on > busybox based system > > A: "Slackware ARM port" > > Data: Luned? 9 maggio 2011, 10:58 > > Ok that got some module loading > > working automatically: > > the ethernet nic now comes up correctly at boot time > and > > some usb stuff is also activated. > > But when I plug in a usb storage stick the device file > does > > not get cteated and not all the modules get pulled > in. > > > > Any ideas ? > > > > Regards > > David > >? > > > > --- Lun 9/5/11, Davide > > ha scritto: > > > > > Da: Davide > > > Oggetto: [ARMedslack] R:? R:? Trouble with > > udev on busybox based system > > > A: "Slackware ARM port" > > > Data: Luned? 9 maggio 2011, 08:42 > > > Could not grep modprobe in the udev > > > scripts nor in the binary (with the aid of > strings) > > ... so I > > > looked in the rules.d and there it was. > > > > > > But busybox modprobe does not support blacklists > ... > > hope > > > it won't hurt. > > > > > > Regards > > > David > > > > > > --- Lun 9/5/11, Davide > > > ha scritto: > > > > > > > Da: Davide > > > > Oggetto: [ARMedslack] R:? Trouble with udev > on > > > busybox based system > > > > A: "Slackware ARM port" > > > > Data: Luned? 9 maggio 2011, 08:32 > > > > Ok ... I started udevd with --debug > > > > and dumped stderr to somewhere I could read > it. > > This > > > is what > > > > came out (the intresting part): > > > > 5584.430610 [1032] > udev_rules_apply_to_event: > > RUN > > > > '/sbin/modprobe -bv $env{MODA > > > > LIAS}' /lib/udev/rules.d/80-drivers.rules:5 > > > > 5584.430746 [1032] util_run_program: > > '/sbin/modprobe > > > -bv > > > > usb:vFFEEp0100d0100dc0 > > > > 0dsc00dp00ic08isc06ip50' started > > > > 5584.435842 [1032] util_run_program: > > '/sbin/modprobe' > > > > (stderr) '/sbin/modprobe: > > > >? invalid option -- 'b'' > > > > 5584.459928 [1032] util_run_program: > > '/sbin/modprobe' > > > > (stderr) 'BusyBox v1.18.4 > > > >? (2011-04-20 14:04:26 BST)' > > > > 5584.460090 [1032] util_run_program: > > '/sbin/modprobe' > > > > (stderr) ' multi-call bin > > > > ary.' > > > > 5584.460178 [1032] util_run_program: > > '/sbin/modprobe' > > > > (stderr) '' > > > > 5584.460204 [1032] util_run_program: > > '/sbin/modprobe' > > > > (stderr) 'Usage: ' > > > > 5584.460278 [1032] util_run_program: > > '/sbin/modprobe' > > > > (stderr) 'modprobe' > > > > 5584.460379 [1032] util_run_program: > > '/sbin/modprobe' > > > > (stderr) ' ' > > > > 5584.460464 [1032] util_run_program: > > '/sbin/modprobe' > > > > (stderr) '[-qfwrsv] MODUL > > > > E [symbol=value]...' > > > > 5584.460489 [1032] util_run_program: > > '/sbin/modprobe' > > > > (stderr) '' > > > > 5584.460509 [1032] util_run_program: > > '/sbin/modprobe' > > > > (stderr) 'Options:' > > > > 5584.460530 [1032] util_run_program: > > '/sbin/modprobe' > > > > (stderr) '? ? ? ? -r > > > > ? ? ? ? Remove MODULE (stacks) or do > > > > autoclean' > > > > 5584.460550 [1032] util_run_program: > > '/sbin/modprobe' > > > > (stderr) '? ? ? ? -q > > > > > > > > It looks like udev is modprobing with > options > > busybox > > > > modprobe does not understand. > > > > > > > > Is this stuff hard coded in the source or is > it > > in > > > some > > > > script ? > > > > > > > > Regards > > > > David > > > > > > > > --- Lun 9/5/11, Davide > > > > ha scritto: > > > > > > > > > Da: Davide > > > > > Oggetto: [ARMedslack] Trouble with udev > on > > > busybox > > > > based system > > > > > A: armedslack at lists.armedslack.org > > > > > Data: Luned? 9 maggio 2011, 07:41 > > > > > Ok this is a little off topic but > > > > > since I'm trying to make it look as > close > > as > > > possible > > > > to a > > > > > slackware system I thaught it could > fit > > here > > > anyway. > > > > > > > > > > Although I did my best to adapt all > the > > scripts > > > > around > > > > > /etc/rc.d and /lib/udev to work > correctly > > with > > > busybox > > > > (sh > > > > > and slightly different PATH): udev is > not > > doing > > > it's > > > > work > > > > > correctly. > > > > > > > > > > udevd start apparently correctly but > none of > > the > > > > modules > > > > > that should be loaded automatically > actually > > get > > > > loaded. > > > > > For instance in order to see the > Ethernet > > nic > > > I;ve to > > > > load > > > > > manually mv643xx_eth, or if I want to > use a > > usb > > > flash > > > > stick > > > > > I've to do quite a bit of manual > module > > loading. > > > > > Having a look at armedslack's > rc.modules I > > see > > > that > > > > > basically it's empty as far as dockstar > is > > > concerned > > > > so all > > > > > the modules do get auto loaded > correctly. > > > > > No as far as kernel is concerned I'm > using > > the > > > exact > > > > same > > > > > setup on the busybox environment that > is on > > the > > > > armedslack > > > > > miniroot system on onboard flash (I > stopped > > using > > > the > > > > kernel > > > > > I compiled) and both boot without > initrd so > > no > > > module > > > > > loading can be done by initrd. > > > > > > > > > > Anyone have any idea how I could go > about > > > debugging > > > > this > > > > > issue ? or even better have any idea > howto > > fix it > > > ? > > > > > > > > > > Regards > > > > > David > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > From louigi600 at yahoo.it Mon May 16 12:43:12 2011 From: louigi600 at yahoo.it (Davide) Date: Mon, 16 May 2011 13:43:12 +0100 (BST) Subject: [ARMedslack] alternative uboot environment Message-ID: <10693.86589.qm@web29705.mail.ird.yahoo.com> I did a little fiddling with jeff's uboot environment setup and changed it so that it looks for a bootable partition in the firs 7 usb drives. This allows you to have your linux install on different partitions. Just 3 conditions must be met: 1) the linux install partition must have everything needed to boot in it (kernel initrd /etc /bin /sbin) 2) uImage and uinitrd must be in the same place (whether it be in / or in /boot) 3) /etc must live in your linux install or the detection of valid linux partition will fail and pass on If you have more then one valid boot partition present amongst your usb drives the first valid partition will be used (scan is done in reverse order so that last scanned will be firs in bus). Take care for the really long usb_scan ... it must be all in one line untill I find out how to put packslashes without mangling it up for uboor setenv. #set ethaddr to the mac address you want to use or to match what's on your label #set arcNumber to match your hardware #set mtdparts to match your flash partitioning scheme # #all the things below are only relative to when usb booting fails #set flash_root_fs to where you want root to be mounted if usb booting fails (default is /dev/mtdblock3) #set flash_root_fstype to what sort of filesystem is used on the above root_fs mtd partition (default is jffs2) #set flash_kernel_offest to where the kernel is to be gotten from flash (default is 0x200000) #set flash_kernel_size to the size of the partition where your kernel resides in flash (default is 300000) #set flash_kernel_load_addr to where kernel is to be loaded to if usb boot fails (default is 0x6400000) setenv bootdelay 3 setenv baudrate 115200 setenv console console=ttyS0,115200 setenv stdin serial setenv stdout serial setenv stderr serial setenv mtdparts mtdparts=orion_nand:1M(u-boot),1M at 1M(second_stage_u-boot),3M at 2M(kernel),32M at 5M(rootfs),219M at 37M(data) setenv mtdids nand0=orion_nand setenv partition nand0,2 setenv led_init green blinking setenv led_exit green off setenv led_error orange blinking setenv ethact egiga0 setenv ethaddr 00:10:75:1A:1C:7E setenv arcNumber 2998 setenv usb_boot_0 'setenv root_fs root=/dev/sda${usb_dev_part}'; setenv usb_boot_1 'setenv root_fs root=/dev/sdb${usb_dev_part}'; setenv usb_boot_2 'setenv root_fs root=/dev/sdc${usb_dev_part}' setenv usb_boot_3 'setenv root_fs root=/dev/sdd${usb_dev_part}'; setenv usb_boot_4 'setenv root_fs root=/dev/sde${usb_dev_part}'; setenv usb_boot_5 'setenv root_fs root=/dev/sdf${usb_dev_part}' setenv usb_boot_6 'setenv root_fs root=/dev/sdg${usb_dev_part}' setenv usb_dev_list 6 5 4 3 2 1 0 setenv usb_dev_part 1 setenv set_usb_bootargs 'setenv bootargs ${console} ${mtdparts} ${root_fs} ro ${root_fstype}' setenv usb_scan 'usb start; setenv usb_boot_dev none; for dev in $usb_dev_list; do for part in $usb_part_list; do if ext2ls usb ${dev}:$part /etc; then setenv usb_boot_dir; ext2ls usb ${dev}:$part /boot && seten v usb_boot_dir /boot; if ext2load usb ${dev}:$part 0x800000 ${usb_boot_dir}/uImage; then setenv usb_dev_part $part; setenv usb_boot_dev $dev; setenv usb_boot_address 0x800000; setenv root_fstype rootfstype=ext2; run usb_boot_$dev ; run set_usb_bootargs; fi; ext2load usb ${dev}:$usb_dev_part 0x1100000 ${usb_boot_dir}/uinitrd; && setenv usb_boot_address 0x800000 0x1100000; fi; done; done; if test "$usb_boot_dev" = "none"; then echo "No USB bootable device found"; else echo "USB device ${usb_boot_dev}:$usb_dev_part is bootable"; bootm $usb_boot_address; fi;' setenv flash_root_fs root=/dev/mtdblock3 setenv flash_root_fstype rootfstype=jffs2 setenv flash_kernel_offest 0x200000 setenv flash_kernel_size 0x300000 setenv flash_kernel_load_addr 0x6400000 setenv set_flash_bootargs 'setenv bootargs ${console} ${mtdparts} ${flash_root_fs} ro ${flash_root_fstype}' setenv boot_flash_kernel 'nand read $flash_kernel_load_addr $flash_kernel_offest $flash_kernel_size; bootm $flash_kernel_load_addr' setenv bootcmd 'run usb_scan; run set_flash_bootargs; run boot_flash_kernel' From brennan.newman at gmail.com Mon May 16 22:23:48 2011 From: brennan.newman at gmail.com (Brennan Newman) Date: Mon, 16 May 2011 17:23:48 -0500 Subject: [ARMedslack] Bad Data CRC error Message-ID: Hello, I am getting a Bad Data CRC error when booting from my sheevaplug, I just received it from Globalscale and it boots with the default debian that is loaded onto the nand fine. I don't know where else to go from here. Marvell>> bootm 0x00800000 0x01100000 ## Booting image at 00800000 ... Image Name: Linux-2.6.38.4-kirkwood Created: 2011-04-22 11:50:56 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2033128 Bytes = 1.9 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... Bad Data CRC Marvell>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From brennan.newman at gmail.com Tue May 17 01:51:03 2011 From: brennan.newman at gmail.com (Brennan Newman) Date: Mon, 16 May 2011 20:51:03 -0500 Subject: [ARMedslack] Bad CRC error Message-ID: I figured it out, when I transfered from FTP it transfered in ascii and not binary. -------------- next part -------------- An HTML attachment was scrubbed... URL: From louigi600 at yahoo.it Mon May 23 08:24:20 2011 From: louigi600 at yahoo.it (Davide) Date: Mon, 23 May 2011 09:24:20 +0100 (BST) Subject: [ARMedslack] R: R: R: R: R: micro root rescue system In-Reply-To: <978643.55414.qm@web29703.mail.ird.yahoo.com> Message-ID: <750365.33671.qm@web29710.mail.ird.yahoo.com> Ok since armedslack does not want a microroot system I put it up as part of my clash progect as clash New Generation (clashNG). You can see it bothe on freshmeat and sourceforge: http://freshmeat.net/projects/clash https://sourceforge.net/projects/bclash/ It still need a lot of documentation but I put up a wiki on sourceforge that I hope helps and with a bit of luck I can get others to help make better and more accurate documentation: http://sourceforge.net/apps/trac/bclash/wiki I know that Pat does not like other distros to say that they are Slackware based thta's whi it's not so evident that a lot of work on this arm clashNG comes right out of armedslack. If anybody feels about this just tell me the correct level of evidence and I'll show it up. Regards David --- Ven 6/5/11, Davide ha scritto: > Da: Davide > Oggetto: [ARMedslack] R: R: R: R: micro root rescue system > A: "Slackware ARM port" > Data: Venerd? 6 maggio 2011, 09:19 > I put the image on diet and now it > fits in 32 Mb (without summery on the jffs2 image): > > root at hp:/mnt/hd/usr/src# du -ks rootfs_surap_busybox.jffs2 > > 31892???rootfs_surap_busybox.jffs2 > root at hp:/mnt/hd/usr/src# > > This is what's in the system: > root at hp:/mnt/hd/usr/src/surap_packages# du -ms * |sort -n > 1? ? ???apr-util-1.3.10-arm-1.tgz > 1? ? ???at-3.1.12-arm-1.tgz > 1? ? ???busybox-1.18.4-arm-1.tgz > 1? ? ???dnsmasq-2.52-arm-1.tgz > 1? ? ???dropbear-0.53.1-arm-1.tgz > 1? ? ???hostapd-0.7.3-arm-1.tgz > 1? ? ???iptables-1.4.10-arm-1.tgz > 1? ? ???iw-0.9.20-arm-1.tgz > 1? ? ???ppp-2.4.5-arm-1.tgz > 1? ? ???sqlite-3.7.3-arm-1.tgz > 1? ? ???udev-165-arm-2.tgz > 1? ? > ???usb_modeswitch-1.1.6-arm-1.tgz > 1? ? > ???wireless-tools-29-arm-2.tgz > 2? ? > ???kernel-firmware-2.6.38.3-noarch-1.tgz > 3? ? ???php-5.3.6-arm-1.tgz > 5? ? ???microroot_libs-arm-1.tgz > 12? ? ? > kernel_2.6.38.3-microkirkwood-arm-1.tgz > > I've not got around to get all the pppd helping stuff, > master mode upun wifi gongle plugin ... etc stuff working > but the base system is working and could be used as a > slackware like rescue system. > > The busybox build is pretty much a complete buld and has > nearly everything enebled including nand utilities.? > > Anyone intrested ? > > --- Gio 5/5/11, Davide > ha scritto: > > > Da: Davide > > Oggetto: [ARMedslack] R:? R:? R:? micro > root rescue system > > A: "Slackware ARM port" > > Data: Gioved? 5 maggio 2011, 10:15 > > Busybox has an internal micro web > > server > > root at surap:~# busybox httpd --help > > BusyBox v1.18.4 (2011-04-20 14:04:26 BST) multi-call > > binary. > > > > Usage: httpd [-ifv[v]] [-c CONFFILE] [-p [IP:]PORT] > [-u > > USER[:GRP]] [-r REALM] [-h HOME] > > or httpd -d/-e/-m STRING > > > > Listen for incoming HTTP requests > > > > Options: > > ? ? ? ? -i? ? ? ? > > ? ? ? Inetd mode > > ? ? ? ? -f? ? ? ? > > ? ? ? Don't daemonize > > ? ? ? ? -v[v]? ? ? > > ? ???Verbose > > ? ? ? ? -p [IP:]PORT? ? Bind > > to IP:PORT (default *:80) > > ? ? ? ? -u > > USER[:GRP]???Set uid/gid after binding to > > port > > ? ? ? ? -r REALM? ? ? > > ? Authentication Realm for Basic Authentication > > ? ? ? ? -h HOME? ? ? > > ???Home directory (default .) > > ? ? ? ? -c FILE? ? ? > > ???Configuration file (default > > {/etc,HOME}/httpd.conf) > > ? ? ? ? -m STRING? ? > > ???MD5 crypt STRING > > ? ? ? ? -e STRING? ? > > ???HTML encode STRING > > ? ? ? ? -d STRING? ? > > ???URL decode STRING > > > > I'll be getting rid of apache in the microroot system > > > > --- Mer 4/5/11, Davide > > ha scritto: > > > > > Da: Davide > > > Oggetto: [ARMedslack] R:? R:? micro root > > rescue system > > > A: "Slackware ARM port" > > > Data: Mercoled? 4 maggio 2011, 00:57 > > > Ok I've the first working image with > > > all the basics working. > > > > > > This is what's in the image: > > > root at hp:/mnt/hd/usr/src/surap_packages# ls > > > at-3.1.12-arm-1.tgz? ? ? ? ? > > > ? iptables-1.4.10-arm-1.tgz > > > busybox-1.18.4-arm-1.tgz? ? > > > ???iw-0.9.20-arm-1.tgz > > > dnsmasq-2.52-arm-1.tgz? ? ? > > > ???kernel-firmware-2.6.38.3-noarch-1.tgz > > > dropbear-0.53.1-arm-1.tgz? ? ? > > > kernel_2.6.38.3-microkirkwood-arm-1.tgz > > > php-5.3.5-arm-1.tgz? ? ? ? ? > > > ? glibc-solibs-2.13-arm-1.tgz? > > > ppp-2.4.5-arm-1.tgz? ? ? ? ? > > > ? hostapd-0.7.3-arm-1.tgz? ? ? > > > udev-165-arm-2.tgz? ? ? ? ? > > > ???httpd-2.2.17-arm-2.tgz? ? > > > ??? > > > usb_modeswitch-1.1.6-arm-1.tgz > > wireless-tools-29-arm-2.tgz > > > root at hp:/mnt/hd/usr/src/surap_packages# > > > and a few other required libs picked manually > > > > > > The compressed and unsummed jffs2 is 41Mb big > > > > > > root at hp:/mnt/hd/usr/src/surap_packages# du -ms > > > ../surap_busybox.jffs2 > > > 41? ? ? ../surap_busybox.jffs2 > > > root at hp:/mnt/hd/usr/src/surap_packages# > > > > > > usb_modeswitch will not work because it needs > tclsh > > and I > > > don't want to add it unless it's really > necessary. > > I'll try > > > working around the problem with pure busybox ash > > scripting > > > ... if that's not possible I'll write a small c > > program to > > > help out ash. > > > > > > Regards > > > David > > > > > > --- Mar 3/5/11, Davide > > > ha scritto: > > > > > > > Da: Davide > > > > Oggetto: [ARMedslack] R:? micro root > rescue > > > system > > > > A: "Slackware ARM port" > > > > Data: Marted? 3 maggio 2011, 08:43 > > > > I struck another little problem while > > > > trying to keep things as much slackware as > > possible: > > > > busybox default shell (the most complete > one) > > seems to > > > have > > > > no support for arrays. Slackware's > > > /etc/rc.d/rc.inet1.conf > > > > is all array config file. > > > > > > > > In order to at least keep the same > parameter > > names > > > with no > > > > array index I moved to making > > ifcfg. > > > whose > > > > contents would be the unindexed variables > for > > each > > > > interface. Now this is a bit redhatish but I > was > > > unable to > > > > think of any other slackware like solution > with > > no > > > arrays. > > > > > > > > Anyone have any idea ? > > > > > > > > Regards > > > > David > > > > > > > > --- Ven 22/4/11, Davide > > > > ha scritto: > > > > > > > > > Da: Davide > > > > > Oggetto: [ARMedslack] micro root > rescue > > system > > > > > A: "Slackware ARM port" > > > > > Data: Venerd? 22 Aprile 2011, 11:45 > > > > > Sorry for starting a new thread on > > > > > something that was started elsewhere > .... > > but > > > maybe > > > > the > > > > > shoot-off needs better attention with a > new > > > thread. > > > > > > > > > > >> This is a mix of a few I > built > > myself > > > and > > > > some > > > > > gotten from current. > > > > > >> This is what I'll be working > with > > and > > > should > > > > fit > > > > > in a compressed > > > > > >> jffs2 image 64Mb big. > > > > > >> > > root at slackware:/usr/src/surap_packages# > > > du > > > > -ms * | > > > > > sort -n > > > > > >> 1 ? busybox-1.18.4-arm-1.tgz > > > > > >> 1? ? > dropbear-0.53.1-arm-1.tgz > > > > > >> 1 ? hostapd-0.7.3-arm-1.tgz > > > > > >> 1? ? > iptables-1.4.10-arm-1.tgz > > > > > >> 1 ???iw-0.9.20-arm-1.tgz > > > > > >> 1 ???ppp-2.4.5-arm-1.tgz > > > > > >> 1 ???udev-165-arm-2.tgz > > > > > >> 1? ? > > usb_modeswitch-1.1.6-arm-1.tgz > > > > > >> 1? ? > wireless-tools-29-arm-2.tgz > > > > > >> 2? ? httpd-2.2.17-arm-2.tgz > > > > > >> 2? ? > > > kernel-firmware-2.6.38.3-noarch-1.tgz > > > > > >> 5? ? > glibc-solibs-2.13-arm-1.tgz > > > > > >> 8? ? > > > kernel_kirkwood-2.6.38.3-arm-1.tgz > > > > > >> 10?? php-5.3.5-arm-1.tgz > > > > > >> > > > > > > > > > > > > > > > 15???kernel-modules-kirkwood-2.6.38.3_kirkwood-arm-1.tgz > > > > > >> > > root at slackware:/usr/src/surap_packages# > > > du > > > > -ms . > > > > > >> 43? ? ? . > > > > > >> > > root at slackware:/usr/src/surap_packages# > > > > > >> > > > > > >> Since booting from jffs2 image > does > > not > > > > require > > > > > initrd ... and maybe > > > > > >> one can do without > documentation > > .... > > > I'll > > > > see if > > > > > I can fit that in a > > > > > >> 32Mb image. > > > > > >> > > > > > > Build a custom kernel with few > modules > > ;) > > > > > > > > > > I will strip all unnecessary modules > for a > > > rescue > > > > system, > > > > > remove initrd, strip documentation and > carve > > down > > > as > > > > much as > > > > > possible ... if it won't fit I'll > consider > > thttpd > > > and > > > > some > > > > > lighter web scripting language. Maybe > web > > stuff > > > is > > > > not > > > > > really necessary for a rescue system > > anyway. > > > > > > > > > > Now I've a question. > > > > > there are 2 ways to do this: > > > > > 1) repackage the single packages and > append > > some > > > > suffix to > > > > > distinguish them from the standard > > packages, > > > possibly > > > > modify > > > > > the build scripts for them so that > future > > > maintenance > > > > will > > > > > be easier, > > > > > > > > > > 2) just shove everything needed > somewhere > > and > > > remove > > > > all > > > > > that is not needed and then build the > jffs2 > > > image. > > > > > > > > > > Now if this micro root system is just > going > > to be > > > my > > > > > personal AP/3g/NAS/router/rescue the > second > > way > > > will > > > > take > > > > > much less effort, on the other hand if > you > > like > > > the > > > > idea of > > > > > having an armedslack micro root system > that > > will > > > be > > > > more > > > > > then just a rescue system and possibly > fit > > in a > > > 32Mb > > > > > compressed image; well then we should > go > > about > > > the > > > > first > > > > > way. > > > > > I say we because I'm just a user and > even if > > I do > > > most > > > > of > > > > > the dirty work I'll need assistance > from > > the > > > > ARMedslack team > > > > > to do some of the required actions if > this > > is of > > > any > > > > > interest to ARMedslack community. > > > > > > > > > > I've no reservation in sharing my work > as I > > > consider > > > > all my > > > > > work GPL + it's mainly just > administration > > so > > > the > > > > question > > > > > really is: Does armedslack want a > smart > > micro > > > root > > > > system ? > > > > > > > > > > Best regards > > > > > David Rao > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > From louigi600 at yahoo.it Thu May 26 17:05:46 2011 From: louigi600 at yahoo.it (Davide) Date: Thu, 26 May 2011 18:05:46 +0100 (BST) Subject: [ARMedslack] Build 2.6.38.7 for kirkwood Message-ID: <636246.2398.qm@web29713.mail.ird.yahoo.com> If anyone likes to try it tarball containing /boot /lib/{firmware/modules} is available on sourceforge: http://sourceforge.net/projects/bclash/files/clashNG/ARM/kernel-kirkwood-2.6.38.7-arm.tgz/download Be warned that I removed some stuff that I regard as not being necessary for clashNG. I tested it for booting both from jffs2 (no initrd needed) and from usb storage (initrd required but provided).