From thenktor at gmx.de Tue Mar 1 17:20:57 2011 From: thenktor at gmx.de (Thorsten =?iso-8859-15?q?M=FChlfelder?=) Date: Tue, 1 Mar 2011 18:20:57 +0100 Subject: [ARMedslack] ARMed Slack on Toshiba AC100 netbook? Message-ID: <201103011820.57394.thenktor@gmx.de> Hi, I wonder If anyone has tried ARMed Slack on a Toshiba AC100 netbook? http://www.engadget.com/2010/06/21/toshibas-ac100-8-hour-smartbook-runs-android-2-1-on-a-1ghz-tegr/ It's available in Germany for 199 ? and I know that it is possible to install Ubuntu on it. So anyone? :-) -- Thorsten M?hlfelder Salix OS: www.salixos.org From louigi600 at yahoo.it Sun Mar 13 06:13:17 2011 From: louigi600 at yahoo.it (Davide) Date: Sun, 13 Mar 2011 06:13:17 +0000 (GMT) Subject: [ARMedslack] Hello Message-ID: <265754.99875.qm@web29707.mail.ird.yahoo.com> Hi, my name is David and I'm new here so please forgive me if I ask odd questions in odd places. I got a second hand seagate dockstar that was sold to me in a semi bricked state: u-boot still works but kernel image is inconsistent so it no longer boots. I used a modified nokia dku-5 cabkle to fiddle with u-boot and install openwrt on it to check out that everything else is working and so far so good but having used x86 slackware for years I'd rather have slackware on my dockstar if I can choose. I'm wondering if the seagate dockstar is amongst the fully supported devices ? If it is then is the onboard flash used for storing boot loader, kernel and initrd and then the rest should go on mass storage (USB HDU/stick) ? Also is there support for using the onboard 256 Mb flash itself as target for the root filesystem (using jffs2 or some other flash tuned filesystem) ? If it is not then my plan is to use the miniroot via chroot on a usb stick and try to use that to make a permanent installation on my dockstar. Maybe I could use the already installed openwrt as an initrd itself. Will this be possible or will I run into some unthoughtful problem ? Best regards David From louigi600 at yahoo.it Sun Mar 13 06:42:32 2011 From: louigi600 at yahoo.it (Davide) Date: Sun, 13 Mar 2011 06:42:32 +0000 (GMT) Subject: [ARMedslack] TTl level serial adapter Message-ID: <791079.52409.qm@web29706.mail.ird.yahoo.com> Having a look on the archived I noticed that people are finding difficulty in getting shuch adapters. Really it's not a problem it's easy and cheap: go off to ebay and look for the cheapes nokia DKU-5 usb cable (I got 2 for less then 7 euro including shipping). When you get it cut off the mobile phone plug and 3 wires should come out: Blue = GND Yellow = RX White = TX I like to put the smallest probe clips I can find around so that I don't need to fiddle with connectors for each hardware I want to interface to. That's it ! The cable has a usb 2 serial converter in it and is designed for (I think 3.3v) ttl nevel opeation. I've used it on my dockstar successfully. The the converter inside it is well supported even under linux (pl2303: Prolific PL2303 USB to serial adaptor). Have fun David From claudio.cavalera at gmail.com Sun Mar 13 14:12:50 2011 From: claudio.cavalera at gmail.com (Claudio Cavalera) Date: Sun, 13 Mar 2011 15:12:50 +0100 Subject: [ARMedslack] Hello In-Reply-To: <265754.99875.qm@web29707.mail.ird.yahoo.com> References: <265754.99875.qm@web29707.mail.ird.yahoo.com> Message-ID: On Sun, Mar 13, 2011 at 07:13, Davide wrote: > Hi, > my name is David and I'm new here so please forgive me if I ask odd questions in odd places. > > I'm wondering if the seagate dockstar is amongst the fully supported devices ? Hello! If you look in the ML archive you should find lot of information about armed slack on the dockstar. I'm not sure it's officially supported, there was some plan to build a semi-automatic installer script like the one at jeff.doozan.com for debian but we are always short on time. I think the kernel needs some patches in any case if you want the led to work meaningfully, see for example at: http://dev.shyd.de/2011/01/seagate-dockstar-debian-squeeze/ Ciao, Claudio From louigi600 at yahoo.it Sun Mar 13 15:23:35 2011 From: louigi600 at yahoo.it (Davide) Date: Sun, 13 Mar 2011 15:23:35 +0000 (GMT) Subject: [ARMedslack] Hello In-Reply-To: Message-ID: <265521.23813.qm@web29714.mail.ird.yahoo.com> Grazie .... Si ho letto qialcosa ... quanto basta per capire l'antifona. Vabbe che sono solo 4Mb per adesso ma urge una funzione di ricerga negli archivi. Ho gia' perso una marea di tempo con lo zaurus ... avevo anche comincato a lavorare su una cosa che chiamavo Slackurus ;-) La moglie, il bimbo e il modo in cui si muoveva lo sviluppo del kernel per ARM mi fecero mollare poco dopo aver messo insieme i pezzi base. Per il mio dockstar credo che utilizzero il kernel openwrt per far partire una mini armed slack da chiavetta usb (mi pare che il second stage boot loader di openwrt permetta di partire da usb direttamente). Da li spero di poter arrivare ad avere un abiente che mi permettera di arrivare velocemente a quello che mi serve: nas + AP + router 3G. Ho gia' esperianza su ap + router ADSL autocostruiti. Par diverso tempo ho usato in casa una cosa che ho demoninato surap (SUper Router Access Point). Per quel proggetto ero partito da zero ma su' piattaforma x86. Bando alle ciance .... sto cercavdo di scaricare la aermedslack 13.1 in modo da poter aggiungere alla mini root tutto quello che mi serve per compilare eventuali altre parti che mi serviranno. Ciao e grazie Davide --- Dom 13/3/11, Claudio Cavalera ha scritto: > Da: Claudio Cavalera > Oggetto: Re: [ARMedslack] Hello > A: "Slackware ARM port" > Data: Domenica 13 marzo 2011, 15:12 > On Sun, Mar 13, 2011 at 07:13, Davide > > wrote: > > Hi, > > my name is David and I'm new here so please forgive me > if I ask odd questions in odd places. > > > > I'm wondering if the seagate dockstar is amongst the > fully supported devices ? > > Hello! > If you look in the ML archive you should find lot of > information about > armed slack on the dockstar. > I'm not sure it's officially supported, there was some plan > to build a > semi-automatic installer script like the one at > jeff.doozan.com for > debian but we are always short on time. > I think the kernel needs some patches in any case if you > want the led > to work meaningfully, see for example at: > http://dev.shyd.de/2011/01/seagate-dockstar-debian-squeeze/ > Ciao, > Claudio > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > From louigi600 at yahoo.it Sun Mar 13 15:26:44 2011 From: louigi600 at yahoo.it (Davide) Date: Sun, 13 Mar 2011 15:26:44 +0000 (GMT) Subject: [ARMedslack] Hello In-Reply-To: <265521.23813.qm@web29714.mail.ird.yahoo.com> Message-ID: <280247.56742.qm@web29716.mail.ird.yahoo.com> Sorry everyone. This email was meant to go directly to Claudio Cavalera. Sorry for disturbing everyone. --- Dom 13/3/11, Davide ha scritto: > Da: Davide > Oggetto: Re: [ARMedslack] Hello > A: "Slackware ARM port" > Data: Domenica 13 marzo 2011, 16:23 > > Grazie .... > > Si ho letto qialcosa ... quanto basta per capire > l'antifona. > Vabbe che sono solo 4Mb per adesso ma urge una funzione di > ricerga negli archivi. > > Ho gia' perso una marea di tempo con lo zaurus ... avevo > anche comincato a lavorare su una cosa che chiamavo > Slackurus ;-) > La moglie, il bimbo e il modo in cui si muoveva lo sviluppo > del kernel per ARM mi fecero mollare poco dopo aver messo > insieme i pezzi base. > > Per il mio dockstar credo che utilizzero il kernel openwrt > per far partire una mini armed slack da chiavetta usb (mi > pare che il second stage boot loader di openwrt permetta di > partire da usb direttamente). > Da li spero di poter arrivare ad avere un abiente che mi > permettera di arrivare velocemente a quello che mi serve: > nas + AP + router 3G. > > Ho gia' esperianza su ap + router ADSL autocostruiti. Par > diverso tempo ho usato in casa una cosa che ho demoninato > surap (SUper Router Access Point). Per quel proggetto ero > partito da zero ma su' piattaforma x86. > > Bando alle ciance .... sto cercavdo di scaricare la > aermedslack 13.1 in modo da poter aggiungere alla mini root > tutto quello che mi serve per compilare eventuali altre > parti che mi serviranno. > > Ciao e grazie > Davide > > > --- Dom 13/3/11, Claudio Cavalera > ha scritto: > > > Da: Claudio Cavalera > > Oggetto: Re: [ARMedslack] Hello > > A: "Slackware ARM port" > > Data: Domenica 13 marzo 2011, 15:12 > > On Sun, Mar 13, 2011 at 07:13, Davide > > > > wrote: > > > Hi, > > > my name is David and I'm new here so please > forgive me > > if I ask odd questions in odd places. > > > > > > I'm wondering if the seagate dockstar is amongst > the > > fully supported devices ? > > > > Hello! > > If you look in the ML archive you should find lot of > > information about > > armed slack on the dockstar. > > I'm not sure it's officially supported, there was some > plan > > to build a > > semi-automatic installer script like the one at > > jeff.doozan.com for > > debian but we are always short on time. > > I think the kernel needs some patches in any case if > you > > want the led > > to work meaningfully, see for example at: > > http://dev.shyd.de/2011/01/seagate-dockstar-debian-squeeze/ > > Ciao, > > Claudio > > _______________________________________________ > > 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 richard.lapointe at gmail.com Mon Mar 14 00:21:21 2011 From: richard.lapointe at gmail.com (Rich) Date: Sun, 13 Mar 2011 20:21:21 -0400 Subject: [ARMedslack] Hello In-Reply-To: <265754.99875.qm@web29707.mail.ird.yahoo.com> References: <265754.99875.qm@web29707.mail.ird.yahoo.com> Message-ID: <4D7D5F81.7060507@laprjns.com> David, There are of few of us running armslack on dockstars, but I don't think its officially support (yet). I have not heard of anyone installing the armedslack to the on-board flash. There are three ways that I manage to get armedslack installed on my dockstar using a usb drive. 1) Running the slack installer using tfpt using a serial cable by following these instructions, either for 13.1 or current: ftp://ftp.armedslack.org/armedslack/armedslack-13.1/INSTALL_KIRKWOOD.TXT ftp://ftp.armedslack.org/armedslack/armedslack-current/INSTALL_KIRKWOOD.TXT 2) Loading the mini root file system onto a usb drive. I didn't change root, but rather renamed both the kernel and initrd to uImage and uInitrd and rebooted. 3) Running the slack installer using ssh. See this mail list thread, but read through the complete thread http://lists.armedslack.org/2011-January/000703.html I like the installer because it goes thought setting up the network, root password, clock, but it's slow. I use both Jeff Doozan's uboot (http://jeff.doozan.com/debian/uboot/) and his rescue system (http://forum.doozan.com/read.php?4,3896) on my dockstar. I like the uboot because it all set up to boot off of usb drives and there is a uboot environment variable that you can use to pass boot options like the ones needed in installer method of #3 above. The rescue system get installed on the on-board flash and will boot if there are no bootable usb. Hope you find this helpful Rich On 03/13/2011 01:13 AM, Davide wrote: > Hi, > my name is David and I'm new here so please forgive me if I ask odd questions in odd places. > > I got a second hand seagate dockstar that was sold to me in a semi bricked state: u-boot still works but kernel image is inconsistent so it no longer boots. > On 03/13/2011 01:13 AM, Davide wrote: > >> Hi, >> my name is David and I'm new here so please forgive me if I ask odd questions in odd places. >> >> I got a second hand seagate dockstar that was sold to me in a semi bricked state: u-boot still works but kernel image is inconsistent so it no longer boots. >> >> I used a modified nokia dku-5 cabkle to fiddle with u-boot and install openwrt on it to check out that everything else is working and so far so good but having used x86 slackware for years I'd rather have slackware on my dockstar if I can choose. >> >> I'm wondering if the seagate dockstar is amongst the fully supported devices ? >> If it is then is the onboard flash used for storing boot loader, kernel and initrd and then the rest should go on mass storage (USB HDU/stick) ? >> Also is there support for using the onboard 256 Mb flash itself as target for the root filesystem (using jffs2 or some other flash tuned filesystem) ? >> >> If it is not then my plan is to use the miniroot via chroot on a usb stick and try to use that to make a permanent installation on my dockstar. >> Maybe I could use the already installed openwrt as an initrd itself. >> Will this be possible or will I run into some unthoughtful problem ? >> >> Best regards >> David >> >> >> >> >> >> >> >> _______________________________________________ >> ARMedslack mailing list >> ARMedslack at lists.armedslack.org >> http://lists.armedslack.org/mailman/listinfo/armedslack >> >> > I used a modified nokia dku-5 cabkle to fiddle with u-boot and install openwrt on it to check out that everything else is working and so far so good but having used x86 slackware for years I'd rather have slackware on my dockstar if I can choose. > > I'm wondering if the seagate dockstar is amongst the fully supported devices ? > If it is then is the onboard flash used for storing boot loader, kernel and initrd and then the rest should go on mass storage (USB HDU/stick) ? > Also is there support for using the onboard 256 Mb flash itself as target for the root filesystem (using jffs2 or some other flash tuned filesystem) ? > > If it is not then my plan is to use the miniroot via chroot on a usb stick and try to use that to make a permanent installation on my dockstar. > Maybe I could use the already installed openwrt as an initrd itself. > Will this be possible or will I run into some unthoughtful problem ? > > Best regards > David > > > > > > > > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > > From louigi600 at yahoo.it Mon Mar 14 07:48:23 2011 From: louigi600 at yahoo.it (Davide) Date: Mon, 14 Mar 2011 07:48:23 +0000 (GMT) Subject: [ARMedslack] Hello In-Reply-To: <4D7D5F81.7060507@laprjns.com> Message-ID: <661093.74599.qm@web29715.mail.ird.yahoo.com> Hi Rich Well I had a thaught about it and I think that what could suit me best would probabbly be the mini root. So here are a few more questions: 1) is the mini root tarball just a xz compressed tarball of / ? 2) how would I use the openwrt second stage boot loader to boot from a usb drive with the mini root on it ? 3) I see in the help that there is a bootusb (or usbboot or something to that meaning anyway) command: the help on it is not very helpfull so how would I use that to boot from mini root on usb drive ? 4) You mentioned just renaming kernel and initrd: is that part of what needs to be done to boot from usb ? 5) Are the slackware kirkwood kernel and initrd good for the dockstar or do they need to be recompiled/remade ? I hav experience on zaurus and know that kernels for c860 and c1000 are incompatible although the hardware difference is minimal. I like the installer to but for differente reasons ;-) I'm an olt time slackware user on x86 so reconfiguring system is not a problem for me but getting slackware on an unsupported patform on which I've not much experience is a different story :-D. Thanx in advance David --- Lun 14/3/11, Rich ha scritto: > Da: Rich > Oggetto: Re: [ARMedslack] Hello > A: armedslack at lists.armedslack.org > Data: Luned? 14 marzo 2011, 01:21 > David, > > There are of few of us running armslack on dockstars, but I > don't think > its officially support (yet).???I have not > heard of anyone installing > the armedslack to the on-board flash.? There are three > ways that I > manage to get armedslack installed on my dockstar using a > usb drive. > > 1) Running the slack installer using tfpt using a serial > cable by > following these instructions, either for 13.1 or current: > ? ? ? > ftp://ftp.armedslack.org/armedslack/armedslack-13.1/INSTALL_KIRKWOOD.TXT > ? ? ? > ftp://ftp.armedslack.org/armedslack/armedslack-current/INSTALL_KIRKWOOD.TXT > > 2) Loading the mini root file system onto a usb > drive.? I didn't change > root, but rather renamed both the kernel and initrd to > uImage and > uInitrd and rebooted. > > 3) Running the slack installer using ssh.? See this > mail list thread, > but read through the complete thread > ? ? http://lists.armedslack.org/2011-January/000703.html > > I like the installer because it goes thought setting up the > network, > root password, clock, but it's slow.? I use both Jeff > Doozan's uboot > (http://jeff.doozan.com/debian/uboot/) and > his rescue system > (http://forum.doozan.com/read.php?4,3896)? on my > dockstar.? I like the > uboot because it all set up to boot off of usb drives and > there is a > uboot environment variable that you can use to pass boot > options like > the ones needed in installer method of #3 above.? The > rescue system get > installed? on the on-board flash and will boot if > there are no bootable usb. > Hope you find this helpful > > Rich > > > > On 03/13/2011 01:13 AM, Davide wrote: > > Hi, > > my name is David and I'm new here so please forgive me > if I ask odd questions in odd places. > > > > I got a second hand seagate dockstar that was sold to > me in a semi bricked state: u-boot still works but kernel > image is inconsistent so it no longer boots. > > On 03/13/2011 01:13 AM, Davide wrote: > >? ? > >> Hi, > >> my name is David and I'm new here so please > forgive me if I ask odd questions in odd places. > >> > >> I got a second hand seagate dockstar that was sold > to me in a semi bricked state: u-boot still works but kernel > image is inconsistent so it no longer boots. > >> > >> I used a modified nokia dku-5 cabkle to fiddle > with u-boot and install openwrt on it to check out that > everything else is working and so far so good but having > used x86 slackware for years I'd rather have slackware on my > dockstar if I can choose. > >> > >> I'm wondering if the seagate dockstar is amongst > the fully supported devices ? > >> If it is then is the onboard flash used for > storing boot loader, kernel and initrd and then the rest > should go on mass storage (USB HDU/stick) ? > >> Also is there support for using the onboard 256 Mb > flash itself as target for the root filesystem (using jffs2 > or some other flash tuned filesystem) ? > >> > >> If it is not then my plan is to use the miniroot > via chroot on a usb stick and try to use that to make a > permanent installation on my dockstar. > >> Maybe I could use the already installed openwrt as > an initrd itself. > >> Will this be possible or will I run into some > unthoughtful problem ? > >> > >> Best regards > >> David > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> ARMedslack mailing list > >> ARMedslack at lists.armedslack.org > >> http://lists.armedslack.org/mailman/listinfo/armedslack > >> > >>? ? ? > > I used a modified nokia dku-5 cabkle to fiddle with > u-boot and install openwrt on it to check out that > everything else is working and so far so good but having > used x86 slackware for years I'd rather have slackware on my > dockstar if I can choose. > > > > I'm wondering if the seagate dockstar is amongst the > fully supported devices ? > > If it is then is the onboard flash used for storing > boot loader, kernel and initrd and then the rest should go > on mass storage (USB HDU/stick) ? > > Also is there support for using the onboard 256 Mb > flash itself as target for the root filesystem (using jffs2 > or some other flash tuned filesystem) ? > > > > If it is not then my plan is to use the miniroot via > chroot on a usb stick and try to use that to make a > permanent installation on my dockstar. > > Maybe I could use the already installed openwrt as an > initrd itself. > > Will this be possible or will I run into some > unthoughtful problem ? > > > > Best 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 thenktor at gmx.de Mon Mar 14 08:30:18 2011 From: thenktor at gmx.de (Thorsten =?iso-8859-1?q?M=FChlfelder?=) Date: Mon, 14 Mar 2011 09:30:18 +0100 Subject: [ARMedslack] Hello In-Reply-To: <4D7D5F81.7060507@laprjns.com> References: <265754.99875.qm@web29707.mail.ird.yahoo.com> <4D7D5F81.7060507@laprjns.com> Message-ID: <201103140930.18571.thenktor@gmx.de> Am Monday 14 March 2011 01:21:21 schrieb Rich: > I have not heard of anyone installing > the armedslack to the on-board flash. Probably because the on-board flash size is quite tiny. IIRC it's a 128 MB NAND flash. I think one can make ARMed slack to fit on it but there wouldn't be much room for additional packages. -- Thorsten M?hlfelder Salix OS: www.salixos.org From thenktor at gmx.de Mon Mar 14 08:37:02 2011 From: thenktor at gmx.de (Thorsten =?iso-8859-1?q?M=FChlfelder?=) Date: Mon, 14 Mar 2011 09:37:02 +0100 Subject: [ARMedslack] Hello In-Reply-To: <661093.74599.qm@web29715.mail.ird.yahoo.com> References: <661093.74599.qm@web29715.mail.ird.yahoo.com> Message-ID: <201103140937.02339.thenktor@gmx.de> Am Monday 14 March 2011 08:48:23 schrieb Davide: > 1) is the mini root tarball just a xz compressed tarball of / ? Correct. Just untar on a partition of your choice, make some config file adjustments and you are ready to go. A readme file exists. > 2) how would I use the openwrt second stage boot loader to boot from a usb > drive with the mini root on it ? > > 3) I see in the help that there is a bootusb (or usbboot or something to > that meaning anyway) command: the help on it is not very helpfull so how > would I use that to boot from mini root on usb drive ? > > 4) You mentioned just renaming kernel and initrd: is that part of what > needs to be done to boot from usb ? 4 depends on the boot loader you are using and if you use the pre-configured boot commands. > 5) Are the slackware kirkwood kernel and initrd good for the dockstar or do > they need to be recompiled/remade ? I hav experience on zaurus and know > that kernels for c860 and c1000 are incompatible although the hardware > difference is minimal. The kirkwood kernel works fine on the dockstar. Only the LED won't work. Therefore you'd need a patched kernel. -- Thorsten M?hlfelder Salix OS: www.salixos.org From louigi600 at yahoo.it Mon Mar 14 09:05:34 2011 From: louigi600 at yahoo.it (Davide) Date: Mon, 14 Mar 2011 09:05:34 +0000 (GMT) Subject: [ARMedslack] Hello In-Reply-To: <201103140930.18571.thenktor@gmx.de> Message-ID: <774987.52260.qm@web29707.mail.ird.yahoo.com> That's not coorect: the dockstar has 128 Mb ram and 256 or 512 Mb flash depending on model. It's a nice piece of hardware having also 3 standard usb 2 ports, Gigabit ethernet and 1.2Ghz processor. The SOC even has 2 sata ports but I've yer to find out if they have been traced out of the BGA onto the PCB. --- Lun 14/3/11, Thorsten M?hlfelder ha scritto: > Da: Thorsten M?hlfelder > Oggetto: Re: [ARMedslack] Hello > A: richard at laprjns.com, "Slackware ARM port" > Data: Luned? 14 marzo 2011, 09:30 > Am Monday 14 March 2011 01:21:21 > schrieb Rich: > > I have not heard of anyone installing > > the armedslack to the on-board flash.? > > Probably because the on-board flash size is quite tiny. > IIRC it's a 128 MB > NAND flash. I think one can make ARMed slack to fit on it > but there wouldn't > be much room for additional packages. > > > -- > Thorsten M?hlfelder > Salix OS: www.salixos.org > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > From thenktor at gmx.de Mon Mar 14 09:31:15 2011 From: thenktor at gmx.de (Thorsten =?iso-8859-1?q?M=FChlfelder?=) Date: Mon, 14 Mar 2011 10:31:15 +0100 Subject: [ARMedslack] Hello In-Reply-To: <774987.52260.qm@web29707.mail.ird.yahoo.com> References: <774987.52260.qm@web29707.mail.ird.yahoo.com> Message-ID: <201103141031.15380.thenktor@gmx.de> Am Monday 14 March 2011 10:05:34 schrieb Davide: > That's not coorect: the dockstar has 128 Mb ram and 256 or 512 Mb flash > depending on model. You are right. Mine has a 256 MB flash. There is a data partition with 219 MB that is empty and could be used for root. But still this is very small for an ARMed slack installation. -- Thorsten M?hlfelder Salix OS: www.salixos.org From m-lists at biscuit.org.uk Mon Mar 14 10:29:54 2011 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Mon, 14 Mar 2011 10:29:54 +0000 (GMT) Subject: [ARMedslack] Hello In-Reply-To: <201103140937.02339.thenktor@gmx.de> References: <661093.74599.qm@web29715.mail.ird.yahoo.com> <201103140937.02339.thenktor@gmx.de> Message-ID: > > 5) Are the slackware kirkwood kernel and initrd good for the dockstar or do > > they need to be recompiled/remade ? I hav experience on zaurus and know > > that kernels for c860 and c1000 are incompatible although the hardware > > difference is minimal. > > The kirkwood kernel works fine on the dockstar. Only the LED won't work. > Therefore you'd need a patched kernel. The one in -current doesn't, I think. I remember switching on the LED support a while ago. If not then it'll be on when I push out 2.6.38 later this week. -- Stuart Winter Slackware ARM: www.armedslack.org From louigi600 at yahoo.it Mon Mar 14 10:51:53 2011 From: louigi600 at yahoo.it (Davide) Date: Mon, 14 Mar 2011 10:51:53 +0000 (GMT) Subject: [ARMedslack] Hello In-Reply-To: <201103140937.02339.thenktor@gmx.de> Message-ID: <863951.86735.qm@web29705.mail.ird.yahoo.com> > > 4) You mentioned just renaming kernel and initrd: is > that part of what > > needs to be done to boot from usb ? > > 4 depends on the boot loader you are using and if you use > the pre-configured > boot commands. I'm using this: http://downloads.openwrt.org/snapshots/trunk/kirkwood/openwrt-kirkwood-dockstar-u-boot.bin Which means using the seagate uboot to load openwrt-kirkwood-dockstar-u-boot typing help when in the second uboot environment shows usb boot capabilites with useless help on it. I don't have the dockstar with me right nor to cut and paste a chunk of the terminal output and the version info directly from the system. If necessary I will supply it as soon as I get back home. From thenktor at gmx.de Mon Mar 14 10:53:11 2011 From: thenktor at gmx.de (Thorsten =?iso-8859-1?q?M=FChlfelder?=) Date: Mon, 14 Mar 2011 11:53:11 +0100 Subject: [ARMedslack] Hello In-Reply-To: References: <661093.74599.qm@web29715.mail.ird.yahoo.com> <201103140937.02339.thenktor@gmx.de> Message-ID: <201103141153.11910.thenktor@gmx.de> Am Monday 14 March 2011 11:29:54 schrieb Stuart Winter: > > > 5) Are the slackware kirkwood kernel and initrd good for the dockstar > > > or do they need to be recompiled/remade ? I hav experience on zaurus > > > and know that kernels for c860 and c1000 are incompatible although the > > > hardware difference is minimal. > > > > The kirkwood kernel works fine on the dockstar. Only the LED won't work. > > Therefore you'd need a patched kernel. > > The one in -current doesn't, I think. I remember switching on the LED > support a while ago. > If not then it'll be on when I push out 2.6.38 later this week. I'm running 2.6.36.3-kirkwood on my Dockstar. -- Thorsten M?hlfelder Salix OS: www.salixos.org From m-lists at biscuit.org.uk Mon Mar 14 11:04:54 2011 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Mon, 14 Mar 2011 11:04:54 +0000 (GMT) Subject: [ARMedslack] Hello In-Reply-To: <201103141153.11910.thenktor@gmx.de> References: <661093.74599.qm@web29715.mail.ird.yahoo.com> <201103140937.02339.thenktor@gmx.de> <201103141153.11910.thenktor@gmx.de> Message-ID: > > The one in -current doesn't, I think. I remember switching on the LED > > support a while ago. > > If not then it'll be on when I push out 2.6.38 later this week. > > I'm running 2.6.36.3-kirkwood on my Dockstar. OK - I probably added the support in 2.6.37 but I never uploaded those kernels. From thenktor at gmx.de Mon Mar 14 11:26:49 2011 From: thenktor at gmx.de (Thorsten =?iso-8859-1?q?M=FChlfelder?=) Date: Mon, 14 Mar 2011 12:26:49 +0100 Subject: [ARMedslack] Hello In-Reply-To: <863951.86735.qm@web29705.mail.ird.yahoo.com> References: <863951.86735.qm@web29705.mail.ird.yahoo.com> Message-ID: <201103141226.49978.thenktor@gmx.de> Am Monday 14 March 2011 11:51:53 schrieb Davide: > > > 4) You mentioned just renaming kernel and initrd: is > > > > that part of what > > > > > needs to be done to boot from usb ? > > > > 4 depends on the boot loader you are using and if you use > > the pre-configured > > boot commands. > > I'm using this: > http://downloads.openwrt.org/snapshots/trunk/kirkwood/openwrt-kirkwood-dock >star-u-boot.bin Which means using the seagate uboot to load > openwrt-kirkwood-dockstar-u-boot typing help when in the second uboot > environment shows usb boot capabilites with useless help on it. I don't > have the dockstar with me right nor to cut and paste a chunk of the > terminal output and the version info directly from the system. If necessary > I will supply it as soon as I get back home. OK, I have no idea what commands are activated at this u-boot. The usbload command loads the kernel from a given memory address. For better handling I'd recommend to use the ext2load command (available in Doozan's u-boot: http://jeff.doozan.com/debian/uboot/) Then you can save your kernel on a ext2/ext3 boot partition and easily access it from within linux, too. Doozan's bootloader also comes with preconfigured boot "scripts", that run the needed boot commands automatically (e.g. usbstart, ext2load, ...). You just have to use correct names for uImage and uInitrd on you ext2 boot partitions. IIRC I have changed these names in my own u-boot configuration, so someone else certainly can provide you the needed information. -- Thorsten M?hlfelder Salix OS: www.salixos.org From louigi600 at yahoo.it Tue Mar 15 08:19:13 2011 From: louigi600 at yahoo.it (Davide) Date: Tue, 15 Mar 2011 08:19:13 +0000 (GMT) Subject: [ARMedslack] dockstar SOC unused features pin praceout In-Reply-To: <201103141226.49978.thenktor@gmx.de> Message-ID: <944573.74839.qm@web29719.mail.ird.yahoo.com> After some research I foud a listing of the trace out of some unused features of the dockstar's SOC. It's in German but Google translate makes it readable :-) http://www.mikrocontroller.net/articles/Dockstar#PIN-Forschung Pity that my software RAID1 vision on the 2 sata ports went into fumes ! One can still do RAID1 on the usb drives but performance would not be the same. From thenktor at gmx.de Tue Mar 15 08:32:17 2011 From: thenktor at gmx.de (Thorsten =?iso-8859-1?q?M=FChlfelder?=) Date: Tue, 15 Mar 2011 09:32:17 +0100 Subject: [ARMedslack] dockstar SOC unused features pin praceout In-Reply-To: <944573.74839.qm@web29719.mail.ird.yahoo.com> References: <944573.74839.qm@web29719.mail.ird.yahoo.com> Message-ID: <201103150932.17274.thenktor@gmx.de> Am Tuesday 15 March 2011 09:19:13 schrieb Davide: > After some research I foud a listing of the trace out of some unused > features of the dockstar's SOC. It's in German but Google translate makes > it readable :-) > http://www.mikrocontroller.net/articles/Dockstar#PIN-Forschung As I'm German I have no problem with it :-D I remember a discussion about adding a RTC to the dockstar. Apparently they have found out a lot more now. -- Thorsten M?hlfelder Salix OS: www.salixos.org From louigi600 at yahoo.it Wed Mar 16 11:22:18 2011 From: louigi600 at yahoo.it (Davide) Date: Wed, 16 Mar 2011 11:22:18 +0000 (GMT) Subject: [ARMedslack] Hello In-Reply-To: <201103141226.49978.thenktor@gmx.de> Message-ID: <569112.47409.qm@web29719.mail.ird.yahoo.com> > > > > 4) You mentioned just renaming kernel and > initrd: is > > > > > > that part of what > > > > > > > needs to be done to boot from usb ? > > > > > > 4 depends on the boot loader you are using and if > you use > > > the pre-configured > > > boot commands. > > > > I'm using this: > > http://downloads.openwrt.org/snapshots/trunk/kirkwood/openwrt-kirkwood-dock > >star-u-boot.bin Which means using the seagate uboot to > load > > openwrt-kirkwood-dockstar-u-boot typing help when in > the second uboot > > environment shows usb boot capabilites with useless > help on it. I don't > > have the dockstar with me right nor to cut and paste a > chunk of the > > terminal output and the version info directly from the > system. If necessary > > I will supply it as soon as I get back home. > > OK, I have no idea what commands are activated at this > u-boot. > The usbload command loads the kernel from a given memory > address. For better > handling I'd recommend to use the ext2load command > (available in Doozan's > u-boot: http://jeff.doozan.com/debian/uboot/) > Then you can save your kernel on a ext2/ext3 boot partition > and easily access > it from within linux, too. Doozan's bootloader also comes > with preconfigured > boot "scripts", that run the needed boot commands > automatically (e.g. > usbstart, ext2load, ...). > You just have to use correct names for uImage and uInitrd > on you ext2 boot > partitions. IIRC I have changed these names in my own > u-boot configuration, > so someone else certainly can provide you the needed > information. > I had a look at jeff doozan's enhanced uboot installer script. I look like it replaces the original uboot on mtd0, is that correct ? While openwrt is using original uboot to start another version so that if you screw up you still have the original one to get things working again without need for jtag. Just incase someone else needs it here is what the 2 versions of ubuut currently on my dockstar do: U-Boot 1.1.4 (Jul 16 2009 - 21:02:16) Cloud Engines (3.4.16) U-Boot code: 00600000 -> 0067FFF0 BSS: -> 00690D60 Soc: 88F6281 A0 (DDR2) CPU running @ 1200Mhz L2 running @ 400Mhz SysClock = 400Mhz , TClock = 200Mhz DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6 DRAM CS[0] base 0x00000000 size 128MB DRAM Total size 128MB 16bit width Flash: 0 kB Addresses 8M - 0M are saved for the U-Boot usage. Mem malloc Initialization (8M - 7M): Done NAND:256 MB CPU : Marvell Feroceon (Rev 1) CLOUD ENGINES BOARD: REDSTONE:1.0 Streaming disabled Write allocate disabled USB 0: host mode PEX 0: interface detected no Link. Net: egiga0 [PRIME], egiga1 Hit any key to stop autoboot: 0 CE>> help ? - alias for 'help' base - print or set address offset boot - boot default, i.e., run 'bootcmd' bootd - boot default, i.e., run 'bootcmd' bootext2 dev:boot_part1,boot_part2 addr boot_image linux_dev_name bootm - boot application image from memory bootp - boot image via network using BootP/TFTP protocol bubt - Burn an image on the Boot Nand Flash. chpart - change active partition cmp - memory compare cmpm - Compare Memory cp - memory copy cpumap - Display CPU memory mapping settings. crc32 - checksum calculation date - get/set/reset date & time dclk - Display the MV device CLKs. dhcp - invoke DHCP client to obtain IP/boot params diskboot- boot from IDE device echo - echo args to console eeprom - EEPROM sub-system erase - erase FLASH memory ext2load- load binary file from a Ext2 filesystem ext2ls - list files in a directory (default /) fi - Find value in the memory. flinfo - print FLASH memory information fsinfo - print information about filesystems fsload - load binary file from a filesystem image g - start application at cached address 'addr'(default addr 0x40000) go - start application at address 'addr' help - print online help icrc32 - checksum calculation ide - IDE sub-system iloop - infinite loop on address range imd - i2c memory display imm[.b, .s, .w, .l] - i2c memory modify (auto-incrementing) imw - memory write (fill) inm - memory modify (constant address) iprobe - probe to discover valid I2C chip addresses ir - reading and changing MV internal register values. loop - infinite loop on address range ls - list files in a directory (default /) map - Diasplay address decode windows md - memory display me - PCI master enable mm - memory modify (auto-incrementing) mp - map PCI BAR mtdparts- define flash/nand partitions mtest - simple RAM test mv_diag - perform board diagnostics mw - memory write (fill) nand - NAND sub-system nboot - boot from NAND device nbubt - Burn a boot loader image on the Boot Nand Flash. nm - memory modify (constant address) pci - list and access PCI Configuration Space phyRead - Read PCI-E Phy register pciePhyWrite - Write PCI-E Phy register phyRead - Read Phy register phyWrite - Write Phy register ping - send ICMP ECHO_REQUEST to network host printenv- print environment variables protect - enable or disable FLASH write protection rarpboot- boot image via network using RARP/TFTP protocol reset - Perform RESET of the CPU resetenv - Return all environment variable to default. run - run commands in an environment variable saveenv - save environment variables to persistent storage se - PCI Slave enable setenv - set environment variables sflash - read, write or erase the external SPI Flash. sg - scanning the PHYs status sp - Scan PCI bus. tftpboot- boot image via network using TFTP protocol version - print monitor version CE>> printenv baudrate=115200 loads_echo=0 rootpath=/mnt/ARM_FS/ run_diag=yes console=console=ttyS0,115200 CASset=min MALLOC_len=1 ethprime=egiga0 bootargs_root=root=/dev/mtdblock2 ro ethmtu=1500 usb0Mode=host nandEcc=1bit ethact=egiga0 ethaddr=00:10:75:1A:1C:7E cesvcid=QV8XLT3L7BVZTBCMJWQ94G97SA ceserialno=2GEP07P1 ceboardver=REDSTONE:1.0 filesize=282f8 fileaddr=800000 netmask=255.255.0.0 ipaddr=169.254.254.253 serverip=169.254.254.254 bootcmd=nand read.e 0x800000 0x100000 0x40000; go 0x800000 stdin=serial stdout=serial stderr=serial mainlineLinux=no enaMonExt=no enaCpuStream=no enaWrAllo=no pexMode=RC disL2Cache=no setL2CacheWT=yes disL2Prefetch=yes enaICPref=yes enaDCPref=yes sata_dma_mode=yes netbsd_en=no vxworks_en=no bootdelay=3 disaMvPnp=no Environment size: 744/131068 bytes CE>> boot NAND read: device 0 offset 0x100000, size 0x40000 Reading data from 0x100000 -- 0% ... 262144 bytes read: OK ## Starting application at 0x00800000 ... U-Boot 2010.09 (Mar 10 2011 - 00:51:16) Marvell-Sheevaplug SoC: Kirkwood 88F6281_A0 DRAM: 128 MiB NAND: 256 MiB *** Warning - bad CRC or NAND, using default environment In: serial Out: serial Err: serial Net: egiga0 88E1116 Initialized on egiga0 Hit any key to stop autoboot: 0 Marvell>> help ? - alias for 'help' base - print or set address offset bdinfo - print Board Info structure boot - boot default, i.e., run 'bootcmd' bootd - boot default, i.e., run 'bootcmd' bootm - boot application image from memory bootp - boot image via network using BOOTP/TFTP protocol cmp - memory compare coninfo - print console devices and information cp - memory copy crc32 - checksum calculation dhcp - boot image via network using DHCP/TFTP protocol echo - echo args to console editenv - edit environment variable fatinfo - print information about filesystem fatload - load binary file from a dos filesystem fatls - list files in a directory (default /) go - start application at address 'addr' help - print command description/usage iminfo - print header information for application image imxtract- extract a part of a multi-image itest - return true/false on integer compare loadb - load binary file over serial line (kermit mode) loads - load S-Record file over serial line loady - load binary file over serial line (ymodem mode) loop - infinite loop on address range md - memory display mm - memory modify (auto-incrementing address) mtest - simple RAM read/write test mw - memory write (fill) nand - NAND sub-system nboot - boot from NAND device nfs - boot image via network using NFS protocol nm - memory modify (constant address) ping - send ICMP ECHO_REQUEST to network host printenv- print environment variables rarpboot- boot image via network using RARP/TFTP protocol reset - Perform RESET of the CPU run - run commands in an environment variable saveenv - save environment variables to persistent storage setenv - set environment variables sleep - delay execution for some time source - run script from memory tftpboot- boot image via network using TFTP protocol usb - USB sub-system usbboot - boot from USB device version - print monitor version Marvell>> printenv bootcmd=${x_bootcmd_kernel}; setenv bootargs ${x_bootargs} ${x_bootargs_root}; ${x_bootcmd_usb}; bootm 0x6400000; bootdelay=3 baudrate=115200 ipaddr=169.254.254.243 serverip=169.254.254.254 x_bootargs=console=ttyS0,115200 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) rw x_bootcmd_kernel=nand read 0x6400000 0x200000 0x300000 x_bootcmd_usb=usb start x_bootargs_root=root=/dev/mtdblock3 rw rootfstype=jffs2 stdin=serial stdout=serial stderr=serial ethaddr=02:50:43:0b:95:20 ethact=egiga0 Environment size: 543/131068 bytes Marvell>> From thenktor at gmx.de Wed Mar 16 12:01:47 2011 From: thenktor at gmx.de (Thorsten =?iso-8859-1?q?M=FChlfelder?=) Date: Wed, 16 Mar 2011 13:01:47 +0100 Subject: [ARMedslack] Hello In-Reply-To: <569112.47409.qm@web29719.mail.ird.yahoo.com> References: <569112.47409.qm@web29719.mail.ird.yahoo.com> Message-ID: <201103161301.47392.thenktor@gmx.de> Am Wednesday 16 March 2011 12:22:18 schrieb Davide: > I look like it replaces the original uboot on mtd0, is that correct ? I'm not sure anymore. I would have to investigate the script again first. > While openwrt is using original uboot to start another version so that if > you screw up you still have the original one to get things working again > without need for jtag. Yes, that's possible. AFAIK you just have to place the second u-boot to the NAND address where originally the kernel can be found. If it fails to load the second u-boot the first u-boot must be able to boot from usb to recover things. Otherwise without JTAG you are stuck, too. IIRC on mikrocontroller.net the layout of the JTAG connector can be found. > Just incase someone else needs it here is what the 2 versions of ubuut > currently on my dockstar do: U-Boot 1.1.4 (Jul 16 2009 - 21:02:16) Cloud > Engines (3.4.16) Is this the original one? > ext2load- load binary file from a Ext2 filesystem > ext2ls ?- list files in a directory (default /) This one can load the kernel of an ext2 file system. But I did not see any USB capabilities. > bootargs_root=root=/dev/mtdblock2 ro It expects root on mtd2. > bootcmd=nand read.e 0x800000 0x100000 0x40000; go 0x800000 It loads a kernel from NAND address 0x40000 to RAM and boots it: > CE>> boot > > NAND read: device 0 offset 0x100000, size 0x40000 > > Reading data from 0x100000 -- ? 0% ... > ?262144 bytes read: OK > ## Starting application at 0x00800000 ... Second one: > U-Boot 2010.09 (Mar 10 2011 - 00:51:16) > Marvell-Sheevaplug > > SoC: ? Kirkwood 88F6281_A0 > DRAM: ?128 MiB > NAND: ?256 MiB > *** Warning - bad CRC or NAND, using default environment > fatinfo - print information about filesystem > fatload - load binary file from a dos filesystem > fatls ? - list files in a directory (default /) Support loading kernel of a FAT partition but not of ext2 (no problem). > usb ? ? - USB sub-system > usbboot - boot from USB device It supports loading the kernel from USB devices. > bootcmd=${x_bootcmd_kernel}; setenv bootargs ${x_bootargs} > ${x_bootargs_root}; ${x_bootcmd_usb}; bootm 0x6400000; bootdelay=3 > baudrate=115200 > ipaddr=169.254.254.243 > serverip=169.254.254.254 > x_bootargs=console=ttyS0,115200 > mtdparts=orion_nand:1M(u-boot),1M at 1M(second_stage_u-boot),3M at 2M(kernel),32M >@5M(rootfs),219M at 37M(data) rw x_bootcmd_kernel=nand read 0x6400000 0x200000 > 0x300000 It loads a kernel from NAND address 0x300000... > x_bootcmd_usb=usb start ... starts the usb system (no idea why) .... > x_bootargs_root=root=/dev/mtdblock3 rw rootfstype=jffs2 ... and expects the root file system on mtd3 as jffs2. What you can do: Prepare a USB stick with a FAT boot partition. Place the kernel on it. Use usbstart and fatload to load the kernel to the RAM. Provide the right bootargs and your ARMed slack rootfs on the same USB stick. And run bootcmd. -- Thorsten M?hlfelder Salix OS: www.salixos.org From louigi600 at yahoo.it Wed Mar 16 12:45:53 2011 From: louigi600 at yahoo.it (Davide) Date: Wed, 16 Mar 2011 12:45:53 +0000 (GMT) Subject: [ARMedslack] Hello In-Reply-To: <201103161301.47392.thenktor@gmx.de> Message-ID: <463157.2920.qm@web29720.mail.ird.yahoo.com> > > I look like it replaces the original uboot on mtd0, is > that correct ? > > I'm not sure anymore. I would have to investigate the > script again first. > > > While openwrt is using original uboot to start another > version so that if > > you screw up you still have the original one to get > things working again > > without need for jtag. > > Yes, that's possible. AFAIK you just have to place the > second u-boot to the > NAND address where originally the kernel can be found. If > it fails to load > the second u-boot the first u-boot must be able to boot > from usb to recover > things. Otherwise without JTAG you are stuck, too. Not really: you can use uboot to write to load via tftp and write to nand: That's how I recovered from my dockstar invalid kernel CRC. For anyone intrested insructions are quite clear on this on openwrt serial console install. > IIRC on mikrocontroller.net the layout of the JTAG > connector can be found. Yea I saw that but I'd still regard that as being more difficult then plying with uboot from serial. > > > Just incase someone else needs it here is what the 2 > versions of ubuut > > currently on my dockstar do: U-Boot 1.1.4 (Jul 16 2009 > - 21:02:16) Cloud > > Engines (3.4.16) > > Is this the original one? Not sure: it's the uboot that I found on my dockstar when I got it second hand. Along with mtd1 content invalid (and hence no OS booting correctly). > > ext2load- load binary file from a Ext2 filesystem > > ext2ls ?- list files in a directory (default /) I tryed that but got nothing. meybe because this uboot does not support usb ... but then again where else would the dockstar have an ext2 filesystem ? directly on flash without any ware levelling dedicated hardware would not be a smart thing to do. > > This one can load the kernel of an ext2 file system. But I > did not see any USB > capabilities. > > > bootargs_root=root=/dev/mtdblock2 ro > > It expects root on mtd2. > > > bootcmd=nand read.e 0x800000 0x100000 0x40000; go > 0x800000 > > It loads a kernel from NAND address 0x40000 to RAM and > boots it: > > CE>> boot > > > > NAND read: device 0 offset 0x100000, size 0x40000 > > > > Reading data from 0x100000 -- ? 0% ... > > ?262144 bytes read: OK > > ## Starting application at 0x00800000 ... > > > Second one: > > U-Boot 2010.09 (Mar 10 2011 - 00:51:16) > > Marvell-Sheevaplug > > > > SoC: ? Kirkwood 88F6281_A0 > > DRAM: ?128 MiB > > NAND: ?256 MiB > > *** Warning - bad CRC or NAND, using default > environment > > > > fatinfo - print information about filesystem > > fatload - load binary file from a dos filesystem > > fatls ? - list files in a directory (default /) > > Support loading kernel of a FAT partition but not of ext2 > (no problem). > > > usb ? ? - USB sub-system > > usbboot - boot from USB device > > It supports loading the kernel from USB devices. > > > bootcmd=${x_bootcmd_kernel}; setenv bootargs > ${x_bootargs} > > ${x_bootargs_root}; ${x_bootcmd_usb}; bootm 0x6400000; > bootdelay=3 > > baudrate=115200 > > ipaddr=169.254.254.243 > > serverip=169.254.254.254 > > > x_bootargs=console=ttyS0,115200 > > > mtdparts=orion_nand:1M(u-boot),1M at 1M(second_stage_u-boot),3M at 2M(kernel),32M > >@5M(rootfs),219M at 37M(data) rw x_bootcmd_kernel=nand > read 0x6400000 0x200000 > > 0x300000 > It loads a kernel from NAND address 0x300000... > > > x_bootcmd_usb=usb start > ... starts the usb system (no idea why) .... > > > x_bootargs_root=root=/dev/mtdblock3 rw > rootfstype=jffs2 > ... and expects the root file system on mtd3 as jffs2. > > > What you can do: > Prepare a USB stick with a FAT boot partition. Place the > kernel on it. Use > usbstart and fatload to load the kernel to the RAM. > Provide the right bootargs and your ARMed slack rootfs on > the same USB stick. > And run bootcmd. I'll play with both uboot and see if I can boot armedslack in some way other then using openwrt as an initrd to start armedslack. If that fails I'll try jeff's enhanced uboot. Thanks for the help. From thenktor at gmx.de Wed Mar 16 13:29:33 2011 From: thenktor at gmx.de (Thorsten =?iso-8859-1?q?M=FChlfelder?=) Date: Wed, 16 Mar 2011 14:29:33 +0100 Subject: [ARMedslack] Hello In-Reply-To: <463157.2920.qm@web29720.mail.ird.yahoo.com> References: <463157.2920.qm@web29720.mail.ird.yahoo.com> Message-ID: <201103161429.33634.thenktor@gmx.de> Am Wednesday 16 March 2011 13:45:53 schrieb Davide: > > Yes, that's possible. AFAIK you just have to place the > > second u-boot to the > > NAND address where originally the kernel can be found. If > > it fails to load > > the second u-boot the first u-boot must be able to boot > > from usb to recover > > things. Otherwise without JTAG you are stuck, too. > > Not really: you can use uboot to write to load via tftp and write to nand: > That's how I recovered from my dockstar invalid kernel CRC. > For anyone intrested insructions are quite clear on this on openwrt serial > console install. Yes, forgot about the network method. Of course it has to be compiled in, too ;) > > IIRC on mikrocontroller.net the layout of the JTAG > > connector can be found. > > Yea I saw that but I'd still regard that as being more difficult then > plying with uboot from serial. Indeed. As long as I can play with serial/netconsole and a working u-boot I won't try JTAG. > > > ext2load- load binary file from a Ext2 filesystem > > > ext2ls ?- list files in a directory (default /) > > I tryed that but got nothing. meybe because this uboot does not support usb > ... but then again where else would the dockstar have an ext2 filesystem ? > directly on flash without any ware levelling dedicated hardware would not > be a smart thing to do. The included options are only a matter of configuration at compile time. And you are right: ext2 support without usb support seems to be useless. At least at the moment I canno imagine any useful scenario. > I'll play with both uboot and see if I can boot armedslack in some way > other then using openwrt as an initrd to start armedslack. If that fails > I'll try jeff's enhanced uboot. Some hints: Create first partition as fat on usb stick, second partition as ext4. The first will be the boot partition and contain your uImage. usb start ext2load usb 0:1 0x6400000 /uImage setenv bootargs root=/dev/sda2 rootfstype=ext4 run bootcmd Something like this... -- Thorsten M?hlfelder Salix OS: www.salixos.org From louigi600 at yahoo.it Wed Mar 16 18:42:40 2011 From: louigi600 at yahoo.it (Davide) Date: Wed, 16 Mar 2011 18:42:40 +0000 (GMT) Subject: [ARMedslack] Hello In-Reply-To: <201103161429.33634.thenktor@gmx.de> Message-ID: <216563.54119.qm@web29717.mail.ird.yahoo.com> > Some hints: > Create first partition as fat on usb stick, second > partition as ext4. The > first will be the boot partition and contain your uImage. > usb start > ext2load usb 0:1 0x6400000 /uImage > setenv bootargs root=/dev/sda2 rootfstype=ext4 > run bootcmd > > Something like this... > Cool this gives me some nice hints (but maybe it should be fatload is the the uImage is to be on a fat filesystem). Never the less what you wrote is much more comprehensive then what uboothas to say when I write "help ext2load". Another thing: I don't like to have ordinary journaled filesystems on flash devices (not talking about jffs* or other flash tuned filesystems). If I really need that then I try at least to keep the journal on a non flash device. This is a choice after a direct experience having burned out a 8Gb SDHC card after a short time running ext3 system on it without the noatime option. I was luky that transcend have lifetime guarantee and I got it changed with a brand new one that I now use with ext2 and noatime option. I know that 8Gb SDHC are'nt expensive now but at the time when I burned it they were the largest avalible. Thanks David From louigi600 at yahoo.it Thu Mar 17 09:17:45 2011 From: louigi600 at yahoo.it (Davide) Date: Thu, 17 Mar 2011 09:17:45 +0000 (GMT) Subject: [ARMedslack] Hello In-Reply-To: <201103161429.33634.thenktor@gmx.de> Message-ID: <35940.10161.qm@web29703.mail.ird.yahoo.com> Ok this is what I did: partitioned a usb stick with 50Mb fat (first partition) and the rest linux made fat 32 filesystem on first partition and copied kirkwood kernel and initrd there formatted second partition with ext2 and extracted miniroot to it edited fstab to reflect the work I did with partitioning then i but the stick in the dosckstar and boot to second uboot: Marvell>> setenv x_bootcmd_kernel 'fatload usb 0:1 0x6400000 uImage' Marvell>> setenv x_bootargs_root 'root=/dev/sda1 ro rootfstype=ext2' Marvell>> printenv bootcmd=${x_bootcmd_kernel}; setenv bootargs ${x_bootargs} ${x_bootargs_root}; ; bootdelay=3 baudrate=115200 ipaddr=169.254.254.243 serverip=169.254.254.254 x_bootargs=console=ttyS0,115200 mtdparts=orion_nand:1M(u-boot),1M at 1M(second_staw x_bootcmd_usb=usb start stdin=serial stdout=serial stderr=serial ethaddr=02:50:43:dd:a3:c7 ethact=egiga0 filesize=1FFE8C x_bootcmd_kernel=fatload usb 0:1 0x6400000 uImage x_bootargs_root=root=/dev/sda1 ro rootfstype=ext2 Environment size: 548/131068 bytes Marvell>> boot reading uImage Invalid FAT entry 2096780 bytes read (Re)start USB... USB: Register 10011 NbrPorts 1 USB EHCI 1.00 scanning bus for devices... 3 USB Device(s) found scanning bus for storage devices... 1 Storage Device(s) found ## Booting kernel from Legacy Image at 06400000 ... Image Name: Linux-2.6.33.5-kirkwood Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2096716 Bytes = 2 MiB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. That's the last line produced by the loaded kernel while booting. I suspect that it's not correctly logging to serial console and that it's also in kernel panic dew to not mounting root. One other thing: how do I get uboot to tell kernel to load initrd ? Regards David --- Mer 16/3/11, Thorsten M?hlfelder ha scritto: > Da: Thorsten M?hlfelder > Oggetto: Re: [ARMedslack] Hello > A: "Slackware ARM port" > Data: Mercoled? 16 marzo 2011, 14:29 > Am Wednesday 16 March 2011 13:45:53 > schrieb Davide: > > > Yes, that's possible. AFAIK you just have to > place the > > > second u-boot to the > > > NAND address where originally the kernel can be > found. If > > > it fails to load > > > the second u-boot the first u-boot must be able > to boot > > > from usb to recover > > > things. Otherwise without JTAG you are stuck, > too. > > > > Not really: you can use uboot to write to load via > tftp and write to nand: > > That's how I recovered from my dockstar invalid kernel > CRC. > > For anyone intrested insructions are quite clear on > this on openwrt serial > > console install. > > Yes, forgot about the network method. Of course it has to > be compiled in, > too ;) > > > > IIRC on mikrocontroller.net the layout of the > JTAG > > > connector can be found. > > > > Yea I saw that but I'd still regard that as being more > difficult then > > plying with uboot from serial. > > Indeed. As long as I can play with serial/netconsole and a > working u-boot I > won't try JTAG. > > > > > ext2load- load binary file from a Ext2 > filesystem > > > > ext2ls ?- list files in a directory > (default /) > > > > I tryed that but got nothing. meybe because this uboot > does not support usb > > ... but then again where else would the dockstar have > an ext2 filesystem ? > > directly on flash without any ware levelling dedicated > hardware would not > > be a smart thing to do. > > The included options are only a matter of configuration at > compile time. And > you are right: ext2 support without usb support seems to be > useless. At least > at the moment I canno imagine any useful scenario. > > > I'll play with both uboot and see if I can boot > armedslack in some way > > other then using openwrt as an initrd to start > armedslack. If that fails > > I'll try jeff's enhanced uboot. > > Some hints: > Create first partition as fat on usb stick, second > partition as ext4. The > first will be the boot partition and contain your uImage. > usb start > ext2load usb 0:1 0x6400000 /uImage > setenv bootargs root=/dev/sda2 rootfstype=ext4 > run bootcmd > > Something like this... > > > -- > Thorsten M?hlfelder > Salix OS: www.salixos.org > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > From thenktor at gmx.de Thu Mar 17 10:06:19 2011 From: thenktor at gmx.de (Thorsten =?iso-8859-1?q?M=FChlfelder?=) Date: Thu, 17 Mar 2011 11:06:19 +0100 Subject: [ARMedslack] Hello In-Reply-To: <569112.47409.qm@web29719.mail.ird.yahoo.com> References: <569112.47409.qm@web29719.mail.ird.yahoo.com> Message-ID: <201103171106.19884.thenktor@gmx.de> Am Wednesday 16 March 2011 12:22:18 schrieb Davide: > I had a look at jeff doozan's enhanced uboot installer script. > I look like it replaces the original uboot on mtd0, is that correct ? > > While openwrt is using original uboot to start another version so that if > you screw up you still have the original one to get things working again > without need for jtag. > Just noticed: I've used the old method from that page, that replaces /dev/mtd3 and chainloads the bootloader. But as Doozans bootloaders should be well tested now installation on mtd0 shouldn't be a problem. -- Thorsten M?hlfelder Salix OS: www.salixos.org From thenktor at gmx.de Thu Mar 17 10:25:39 2011 From: thenktor at gmx.de (Thorsten =?iso-8859-1?q?M=FChlfelder?=) Date: Thu, 17 Mar 2011 11:25:39 +0100 Subject: [ARMedslack] Hello In-Reply-To: <35940.10161.qm@web29703.mail.ird.yahoo.com> References: <35940.10161.qm@web29703.mail.ird.yahoo.com> Message-ID: <201103171125.39988.thenktor@gmx.de> Am Thursday 17 March 2011 10:17:45 schrieb Davide: > x_bootargs=console=ttyS0,115200 Seems to be OK. > x_bootcmd_kernel=fatload usb 0:1 0x6400000 uImage Where are you doing "usb start"? > x_bootargs_root=root=/dev/sda1 ro rootfstype=ext2 That probably should be /dev/sda2 because sda1 is your /boot partition. You have to specify this in fstab, too. > One other thing: how do I get uboot to tell kernel to load initrd ? I guess you can try like this: fatload usb 0:1 0x800000 uImage fatload usb 0:1 0x1100000 uInitrd bootm 0x800000 0x1100000 Which means: Load kernel to RAM address 0x800000, load initrd to 0x1100000 and then boot both. -- Thorsten M?hlfelder Salix OS: www.salixos.org From louigi600 at yahoo.it Thu Mar 17 12:15:49 2011 From: louigi600 at yahoo.it (Davide) Date: Thu, 17 Mar 2011 12:15:49 +0000 (GMT) Subject: [ARMedslack] Hello In-Reply-To: <201103171125.39988.thenktor@gmx.de> Message-ID: <318423.11961.qm@web29703.mail.ird.yahoo.com> --- Gio 17/3/11, Thorsten M?hlfelder ha scritto: > Da: Thorsten M?hlfelder > Oggetto: Re: [ARMedslack] Hello > A: "Slackware ARM port" > Data: Gioved? 17 marzo 2011, 11:25 > Am Thursday 17 March 2011 10:17:45 > schrieb Davide: > > x_bootargs=console=ttyS0,115200 > > Seems to be OK. > > > x_bootcmd_kernel=fatload usb 0:1 0x6400000 uImage > > Where are you doing "usb start"? If you look at the printenv ... to my understanding uboot does it on it's own: x_bootargs=console=ttyS0,115200 mtdparts=orion_nand:1M(u-boot),1M at 1M(second_staw x_bootcmd_usb=usb start but in any case I did that earlier along with fatls to see that the kernel could be seen by uboot. > > > x_bootargs_root=root=/dev/sda1 ro rootfstype=ext2 > > That probably should be /dev/sda2 because sda1 is your > /boot partition. You > have to specify this in fstab, too. Yes typo but can't see the kernel loading: no output on serial while kernel initializes things ... so something else is wrong too fstab on miniroot is ok: root at darkstar:~# cat /mnt/tmp/etc/fstab proc /proc proc defaults 0 0 # tmpfs /dev/shm tmpfs defaults 0 0 /dev/sda1 /boot vfat noatime,errors=remount-ro 0 1 /dev/sda2 / ext2 noatime,errors=remount-ro 0 1 root at darkstar:~# > > > One other thing: how do I get uboot to tell kernel to > load initrd ? > > I guess you can try like this: > fatload usb 0:1 0x800000 uImage > fatload usb 0:1 0x1100000 uInitrd > bootm 0x800000? 0x1100000 > > Which means: > Load kernel to RAM address 0x800000, load initrd to > 0x1100000 and then boot > both. > Marvell>> fatload usb 0:1 0x6400000 uimage reading uimage Invalid FAT entry 2096780 bytes read Marvell>> fatload usb 0:1 0x1100000 uinitrd reading uinitrd Invalid FAT entry 7706248 bytes read Marvell>> bootm 0x6400000 0x1100000 ## Booting kernel from Legacy Image at 06400000 ... Image Name: Linux-2.6.33.5-kirkwood Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2096716 Bytes = 2 MiB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 01100000 ... Image Name: Slackware ARM Initial RAM disk f Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 7706184 Bytes = 7.3 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Does not look any better :-( What next ? Does it say invalid fat entry because I've vfat on first partition ? Regards David From louigi600 at yahoo.it Thu Mar 17 14:13:37 2011 From: louigi600 at yahoo.it (Davide) Date: Thu, 17 Mar 2011 14:13:37 +0000 (GMT) Subject: [ARMedslack] Hello In-Reply-To: <318423.11961.qm@web29703.mail.ird.yahoo.com> Message-ID: <469711.57283.qm@web29710.mail.ird.yahoo.com> I downloaded miniroot current and did the exact same and it booted !!! I guess there is something wrong with 13.1's kirkwood kernel image. Here's me in the slackware current just after login: root at slackware:/# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda2 7662088 226700 7435388 3% / /dev/sda1 50459 9169 41291 19% /boot root at slackware:/# uname -a Linux slackware 2.6.38rc8-kirkwood #2 PREEMPT Sun Mar 13 14:56:12 GMT 2011 armv5tel Feroceon 88FR131 rev 1 (v5l) Seagate FreeAgent DockStar GNU/Linux root at slackware:/# cat /etc/slackware-version Slackware 13.37.0 root at slackware:/# The only thing I noticed wrong while system came up is: [ 25.669649] uncorrectable error : [ 25.672905] end_request: I/O error, dev mtdblock0, sector 1920 [ 25.678944] Buffer I/O error on device mtdblock0, logical block 240 [ 25.839517] uncorrectable error : [ 25.845664] end_request: I/O error, dev mtdblock0, sector 1920 [ 25.851715] Buffer I/O error on device mtdblock0, logical block 240 [ 25.860583] uncorrectable error : [ 25.863897] uncorrectable error : [ 25.867630] end_request: I/O error, dev mtdblock0, sector 0 [ 25.873419] Buffer I/O error on device mtdblock0, logical block 0 [ 25.879845] uncorrectable error : [ 25.883085] uncorrectable error : [ 25.886731] end_request: I/O error, dev mtdblock0, sector 8 This may be because mtdparts may be incorrect since I'm using openwrt second stage u-boot that may have passed wrong flash partitions to kernel. Hope it did not make a mess of the content. From m-lists at biscuit.org.uk Thu Mar 17 16:48:09 2011 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Thu, 17 Mar 2011 16:48:09 +0000 (GMT) Subject: [ARMedslack] Hello In-Reply-To: <469711.57283.qm@web29710.mail.ird.yahoo.com> References: <469711.57283.qm@web29710.mail.ird.yahoo.com> Message-ID: On Thu, 17 Mar 2011, Davide wrote: > I downloaded miniroot current and did the exact same and it booted !!! > I guess there is something wrong with 13.1's kirkwood kernel image. NOthing wrong with 13.1's kirkwood kernel - works fine on the SheevaPlug, Guru and OpenRD client. I don't know what the support was like for the Dockstar for that kernel though (or if it was even in there at all!) > The only thing I noticed wrong while system came up is: > [ 25.669649] uncorrectable error : > [ 25.672905] end_request: I/O error, dev mtdblock0, sector 1920 > [ 25.678944] Buffer I/O error on device mtdblock0, logical block 240 > [ 25.839517] uncorrectable error : > [ 25.845664] end_request: I/O error, dev mtdblock0, sector 1920 > [ 25.851715] Buffer I/O error on device mtdblock0, logical block 240 > [ 25.860583] uncorrectable error : > [ 25.863897] uncorrectable error : > [ 25.867630] end_request: I/O error, dev mtdblock0, sector 0 > [ 25.873419] Buffer I/O error on device mtdblock0, logical block 0 > [ 25.879845] uncorrectable error : > [ 25.883085] uncorrectable error : > [ 25.886731] end_request: I/O error, dev mtdblock0, sector 8 > > This may be because mtdparts may be incorrect since I'm using openwrt second stage u-boot that may have passed wrong flash partitions to kernel. > Hope it did not make a mess of the content. http://www.spinics.net/lists/arm-kernel/msg62881.html AFAIK it's nothing to worry about, but read up on it by following the info in there. -- Stuart Winter Slackware ARM: www.armedslack.org From thenktor at gmx.de Thu Mar 17 17:17:15 2011 From: thenktor at gmx.de (Thorsten =?iso-8859-1?q?M=FChlfelder?=) Date: Thu, 17 Mar 2011 18:17:15 +0100 Subject: [ARMedslack] Hello In-Reply-To: References: <469711.57283.qm@web29710.mail.ird.yahoo.com> Message-ID: <201103171817.15716.thenktor@gmx.de> Am Thursday 17 March 2011 17:48:09 schrieb Stuart Winter: > On Thu, 17 Mar 2011, Davide wrote: > > I downloaded miniroot current and did the exact same and it booted !!! > > I guess there is something wrong with 13.1's kirkwood kernel image. > > NOthing wrong with 13.1's kirkwood kernel - works fine on the SheevaPlug, > Guru and OpenRD client. I don't know what the support was like for the > Dockstar for that kernel though (or if it was even in there at all!) I can confirm that I had the 13.1 kernel running on my dockstar without problems. > > The only thing I noticed wrong while system came up is: > > [ 25.669649] uncorrectable error : > > [ 25.672905] end_request: I/O error, dev mtdblock0, sector 1920 > > [ 25.678944] Buffer I/O error on device mtdblock0, logical block 240 > > [ 25.839517] uncorrectable error : > > [ 25.845664] end_request: I/O error, dev mtdblock0, sector 1920 > > [ 25.851715] Buffer I/O error on device mtdblock0, logical block 240 > > [ 25.860583] uncorrectable error : > > [ 25.863897] uncorrectable error : > > [ 25.867630] end_request: I/O error, dev mtdblock0, sector 0 > > [ 25.873419] Buffer I/O error on device mtdblock0, logical block 0 > > [ 25.879845] uncorrectable error : > > [ 25.883085] uncorrectable error : > > [ 25.886731] end_request: I/O error, dev mtdblock0, sector 8 > > > > This may be because mtdparts may be incorrect since I'm using openwrt > > second stage u-boot that may have passed wrong flash partitions to > > kernel. Hope it did not make a mess of the content. > > http://www.spinics.net/lists/arm-kernel/msg62881.html > > AFAIK it's nothing to worry about, but read up on it by following the info > in there. I have the same errors and I've assumed that they are bad block related. The link confirmed that in some way (OOB holds bad block information and some other data as well). But I've wondered why the mtd partitions are touched at bootup, even they are not mounted. Was this issue introduced with new kernels? On another device I'm using a 2.6.24 and 2.6.29 kernel and I'm writing u-boot and u-boot-env from within Linux to the NAND, but u-boot does not complain about anything (as noted in your link). -- Thorsten M?hlfelder Salix OS: www.salixos.org From louigi600 at yahoo.it Thu Mar 17 18:23:13 2011 From: louigi600 at yahoo.it (Davide) Date: Thu, 17 Mar 2011 18:23:13 +0000 (GMT) Subject: [ARMedslack] Hello In-Reply-To: <201103171817.15716.thenktor@gmx.de> Message-ID: <800671.38448.qm@web29710.mail.ird.yahoo.com> Well I checked md5sum on the 13.1 miniroot tarball and it was ok. I got the kernel and initrd from /boot in the miniroot after extraction so I'm giessung they should be ok. Not sure if 13.1 kernel has changed since you two tried but I can assure you that kernel gets loaded and booted but then nothing else: 7706248 bytes read ## Booting kernel from Legacy Image at 06400000 ... Image Name: Linux-2.6.33.5-kirkwood Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2096716 Bytes = 2 MiB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 01100000 ... Image Name: Slackware ARM Initial RAM disk f Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 7706184 Bytes = 7.3 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. This is the last thing that my doickstar does untill hard reset with 13.1 kernel 2.6.33.5-kirkwood I noticed that this is not the default 13.1 kernel on x86 which is 2.6.33.4 so things may have changed since then. I can assure you that I cut and pasted the very same instructions in order to boot from u-boot so there is ither something wrong with the kernel or something wrong with my dockstar. Here are the instructions I'm using (which have now been saved to flash as it looks save for booting with 2.6.38rc8-kirkwood: setenv x_bootcmd_kernel 'fatload usb 0:1 0x6400000 uimage' setenv x_bootcmd_initrd 'fatload usb 0:1 0x1100000 uinitrd' setenv x_bootargs_root 'root=LABEL=usbroot ro rootfstype=ext2' setenv x_bootargs 'console=ttyS0,115200 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) ro' setenv bootcmd '${x_bootcmd_usb}; ${x_bootcmd_kernel}; ${x_bootcmd_initrd}; setenv bootargs ${x_bootargs} ${x_bootargs_root}; bootm 0x6400000 0x1100000;' boot This works with 2.6.38rc8-kirkwood but not with 2.6.33.5-kirkwood. One other thing I've not checked out is if with the 13.1 kernel it's only the serial console that is dead ... but the led on the usb stick seems dead too so my giess is that there is more to it then just the serial console. Regards David --- Gio 17/3/11, Thorsten M?hlfelder ha scritto: > Da: Thorsten M?hlfelder > Oggetto: Re: [ARMedslack] Hello > A: "Slackware ARM port" > Data: Gioved? 17 marzo 2011, 18:17 > Am Thursday 17 March 2011 17:48:09 > schrieb Stuart Winter: > > On Thu, 17 Mar 2011, Davide wrote: > > > I downloaded miniroot current and did the exact > same and it booted !!! > > > I guess there is something wrong with 13.1's > kirkwood kernel image. > > > > NOthing wrong with 13.1's kirkwood kernel - works fine > on the SheevaPlug, > > Guru and OpenRD client.? I don't know what the > support was like for the > > Dockstar for that kernel though (or if it was even in > there at all!) > > I can confirm that I had the 13.1 kernel running on my > dockstar without > problems. > > > > The only thing I noticed wrong while system came > up is: > > > [???25.669649] uncorrectable error > : > > > [???25.672905] end_request: I/O > error, dev mtdblock0, sector 1920 > > > [???25.678944] Buffer I/O error on > device mtdblock0, logical block 240 > > > [???25.839517] uncorrectable error > : > > > [???25.845664] end_request: I/O > error, dev mtdblock0, sector 1920 > > > [???25.851715] Buffer I/O error on > device mtdblock0, logical block 240 > > > [???25.860583] uncorrectable error > : > > > [???25.863897] uncorrectable error > : > > > [???25.867630] end_request: I/O > error, dev mtdblock0, sector 0 > > > [???25.873419] Buffer I/O error on > device mtdblock0, logical block 0 > > > [???25.879845] uncorrectable error > : > > > [???25.883085] uncorrectable error > : > > > [???25.886731] end_request: I/O > error, dev mtdblock0, sector 8 > > > > > > This may be because mtdparts may be incorrect > since I'm using openwrt > > > second stage u-boot that may have passed wrong > flash partitions to > > > kernel. Hope it did not make a mess of the > content. > > > > http://www.spinics.net/lists/arm-kernel/msg62881.html > > > > AFAIK it's nothing to worry about, but read up on it > by following the info > > in there. > > I have the same errors and I've assumed that they are bad > block related. The > link confirmed that in some way (OOB holds bad block > information and some > other data as well). But I've wondered why the mtd > partitions are touched at > bootup, even they are not mounted. > Was this issue introduced with new kernels? On another > device I'm using a > 2.6.24 and 2.6.29 kernel and I'm writing u-boot and > u-boot-env from within > Linux to the NAND, but u-boot does not complain about > anything (as noted in > your link). > > -- > Thorsten M?hlfelder > Salix OS: www.salixos.org > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > From m-lists at biscuit.org.uk Fri Mar 18 13:13:17 2011 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Fri, 18 Mar 2011 13:13:17 +0000 (GMT) Subject: [ARMedslack] Hello In-Reply-To: <800671.38448.qm@web29710.mail.ird.yahoo.com> References: <800671.38448.qm@web29710.mail.ird.yahoo.com> Message-ID: > Not sure if 13.1 kernel has changed since you two tried but I can assure > you that kernel gets loaded and booted but then nothing else: The kernel for 13.1 hasn't changed since it was released as 2.6.33.5. > I noticed that this is not the default 13.1 kernel on x86 which is 2.6.33.4 so things may have changed since then. Slackware ARM uses which ever the most recent kernel is that works best for the ARM platforms supported -- it doesn't follow Slackware x86 at all: if they happen to be using the same version at the same time, it's purely coincidental. > This works with 2.6.38rc8-kirkwood but not with 2.6.33.5-kirkwood. One > other thing I've not checked out is if with the 13.1 kernel it's only > the serial console that is dead ... but the led on the usb stick seems > dead too so my giess is that there is more to it then just the serial Well it works now so it's ok :-) Perhaps your dockstar is a slightly different version which is better catered for in the 2.6.38 kernel. From louigi600 at yahoo.it Fri Mar 18 16:57:15 2011 From: louigi600 at yahoo.it (Davide) Date: Fri, 18 Mar 2011 16:57:15 +0000 (GMT) Subject: [ARMedslack] usb wifi dongle that supports master mode In-Reply-To: Message-ID: <869313.6783.qm@web29711.mail.ird.yahoo.com> On now that I've the basics going I'm now moving to the wireless part. My armedslack dockstar wants to become access point but none of the usb wifi dongles I have seem to work currently in master mode. Today I brought a new one d-link g122 that should have been rt73 ... but the one I got was rt2870. I went back to the shop and managed to get it changed for a sitecom wl-608 but whenn I got home I found out that it's the same damn chip-set rt2870. I don't think they are going to let me change it again. I'm hoping one of you dudes can tell me what to buy with a reasonable degree of certainty that I get the expected chip-set. Anyone have any ideas ? Are there patches to get master mode on zd1211 or rt2870 ? Some time pre mac80211 zd1211 used to work in master mode, maybe not too reiably, but instead of getting fixed it got removed :-( Thanks in advance David From carlo.caione at gmail.com Fri Mar 18 17:29:03 2011 From: carlo.caione at gmail.com (Carlo Caione) Date: Fri, 18 Mar 2011 18:29:03 +0100 Subject: [ARMedslack] usb wifi dongle that supports master mode In-Reply-To: <869313.6783.qm@web29711.mail.ird.yahoo.com> References: <869313.6783.qm@web29711.mail.ird.yahoo.com> Message-ID: <4D83965F.1060208@gmail.com> On 18/03/2011 17:57, Davide wrote: > On now that I've the basics going I'm now moving to the wireless part. [cut] Please, don't hijack the thread. New subject -> new thread. Thank you, -- Carlo Caione From richard.lapointe at gmail.com Sat Mar 19 15:42:57 2011 From: richard.lapointe at gmail.com (Rich) Date: Sat, 19 Mar 2011 11:42:57 -0400 Subject: [ARMedslack] Hello In-Reply-To: <201103171106.19884.thenktor@gmx.de> References: <569112.47409.qm@web29719.mail.ird.yahoo.com> <201103171106.19884.thenktor@gmx.de> Message-ID: <4D84CF01.1000701@laprjns.com> On 03/17/2011 06:06 AM, Thorsten M?hlfelder wrote: > Am Wednesday 16 March 2011 12:22:18 schrieb Davide: > >> I had a look at jeff doozan's enhanced uboot installer script. >> I look like it replaces the original uboot on mtd0, is that correct ? >> >> While openwrt is using original uboot to start another version so that if >> you screw up you still have the original one to get things working again >> without need for jtag. >> >> > Just noticed: I've used the old method from that page, that replaces /dev/mtd3 > and chainloads the bootloader. > But as Doozans bootloaders should be well tested now installation on mtd0 > shouldn't be a problem. > > I've been using Doozan mtd0 uboot for months now without problems. As far as I can see the only risk is a power lost during the the loading of the new boot. Then you would need jtag to recover from this. I've reinstalled it several times (>10) without problems; Haven't tripped over the power cord during reinstall yet! Rich Lapointe From richard.lapointe at gmail.com Sat Mar 19 16:16:47 2011 From: richard.lapointe at gmail.com (Rich) Date: Sat, 19 Mar 2011 12:16:47 -0400 Subject: [ARMedslack] Hello In-Reply-To: <800671.38448.qm@web29710.mail.ird.yahoo.com> References: <800671.38448.qm@web29710.mail.ird.yahoo.com> Message-ID: <4D84D6EF.3020802@laprjns.com> Regarding the 13.1 failing to boot problem. I think all of us dockstar users with the exception of Thorston had the same problem. I believe it is related to the fact that the dockstar doesn't have a real time clock and hence all the installed files get bad time stamps. So on first boot it fails a fdisk check and just stalls there waiting for user input, but since you can't see this without a serial connection, it appears that it never booted up. The difference with current is that it now includes e2fsck.conf in /etc which allows fdisk to ignore bad time stamps. I willing to bet if you add this file to the 13.1 install it would boot also. Rich Lapointe On 03/17/2011 02:23 PM, Davide wrote: > Well I checked md5sum on the 13.1 miniroot tarball and it was ok. > I got the kernel and initrd from /boot in the miniroot after extraction so I'm giessung they should be ok. > > Not sure if 13.1 kernel has changed since you two tried but I can assure you that kernel gets loaded and booted but then nothing else: > 7706248 bytes read > ## Booting kernel from Legacy Image at 06400000 ... > Image Name: Linux-2.6.33.5-kirkwood > Image Type: ARM Linux Kernel Image (uncompressed) > Data Size: 2096716 Bytes = 2 MiB > Load Address: 00008000 > Entry Point: 00008000 > Verifying Checksum ... OK > ## Loading init Ramdisk from Legacy Image at 01100000 ... > Image Name: Slackware ARM Initial RAM disk f > Image Type: ARM Linux RAMDisk Image (gzip compressed) > Data Size: 7706184 Bytes = 7.3 MiB > Load Address: 00000000 > Entry Point: 00000000 > Verifying Checksum ... OK > Loading Kernel Image ... OK > OK > > Starting kernel ... > > Uncompressing Linux... done, booting the kernel. > > This is the last thing that my doickstar does untill hard reset with 13.1 kernel 2.6.33.5-kirkwood > > I noticed that this is not the default 13.1 kernel on x86 which is 2.6.33.4 so things may have changed since then. > I can assure you that I cut and pasted the very same instructions in order to boot from u-boot so there is ither something wrong with the kernel or something wrong with my dockstar. > > Here are the instructions I'm using (which have now been saved to flash as it looks save for booting with 2.6.38rc8-kirkwood: > setenv x_bootcmd_kernel 'fatload usb 0:1 0x6400000 uimage' > setenv x_bootcmd_initrd 'fatload usb 0:1 0x1100000 uinitrd' > setenv x_bootargs_root 'root=LABEL=usbroot ro rootfstype=ext2' > setenv x_bootargs 'console=ttyS0,115200 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) ro' > setenv bootcmd '${x_bootcmd_usb}; ${x_bootcmd_kernel}; ${x_bootcmd_initrd}; setenv bootargs ${x_bootargs} ${x_bootargs_root}; bootm 0x6400000 0x1100000;' > boot > > This works with 2.6.38rc8-kirkwood but not with 2.6.33.5-kirkwood. > One other thing I've not checked out is if with the 13.1 kernel it's only the serial console that is dead ... but the led on the usb stick seems dead too so my giess is that there is more to it then just the serial console. > > Regards > David > --- Gio 17/3/11, Thorsten M?hlfelder ha scritto: > > >> Da: Thorsten M?hlfelder >> Oggetto: Re: [ARMedslack] Hello >> A: "Slackware ARM port" >> Data: Gioved? 17 marzo 2011, 18:17 >> Am Thursday 17 March 2011 17:48:09 >> schrieb Stuart Winter: >> >>> On Thu, 17 Mar 2011, Davide wrote: >>> >>>> I downloaded miniroot current and did the exact >>>> >> same and it booted !!! >> >>>> I guess there is something wrong with 13.1's >>>> >> kirkwood kernel image. >> >>> NOthing wrong with 13.1's kirkwood kernel - works fine >>> >> on the SheevaPlug, >> >>> Guru and OpenRD client. I don't know what the >>> >> support was like for the >> >>> Dockstar for that kernel though (or if it was even in >>> >> there at all!) >> >> I can confirm that I had the 13.1 kernel running on my >> dockstar without >> problems. >> >> >>>> The only thing I noticed wrong while system came >>>> >> up is: >> >>>> [ 25.669649] uncorrectable error >>>> >> : >> >>>> [ 25.672905] end_request: I/O >>>> >> error, dev mtdblock0, sector 1920 >> >>>> [ 25.678944] Buffer I/O error on >>>> >> device mtdblock0, logical block 240 >> >>>> [ 25.839517] uncorrectable error >>>> >> : >> >>>> [ 25.845664] end_request: I/O >>>> >> error, dev mtdblock0, sector 1920 >> >>>> [ 25.851715] Buffer I/O error on >>>> >> device mtdblock0, logical block 240 >> >>>> [ 25.860583] uncorrectable error >>>> >> : >> >>>> [ 25.863897] uncorrectable error >>>> >> : >> >>>> [ 25.867630] end_request: I/O >>>> >> error, dev mtdblock0, sector 0 >> >>>> [ 25.873419] Buffer I/O error on >>>> >> device mtdblock0, logical block 0 >> >>>> [ 25.879845] uncorrectable error >>>> >> : >> >>>> [ 25.883085] uncorrectable error >>>> >> : >> >>>> [ 25.886731] end_request: I/O >>>> >> error, dev mtdblock0, sector 8 >> >>>> This may be because mtdparts may be incorrect >>>> >> since I'm using openwrt >> >>>> second stage u-boot that may have passed wrong >>>> >> flash partitions to >> >>>> kernel. Hope it did not make a mess of the >>>> >> content. >> >>> http://www.spinics.net/lists/arm-kernel/msg62881.html >>> >>> AFAIK it's nothing to worry about, but read up on it >>> >> by following the info >> >>> in there. >>> >> I have the same errors and I've assumed that they are bad >> block related. The >> link confirmed that in some way (OOB holds bad block >> information and some >> other data as well). But I've wondered why the mtd >> partitions are touched at >> bootup, even they are not mounted. >> Was this issue introduced with new kernels? On another >> device I'm using a >> 2.6.24 and 2.6.29 kernel and I'm writing u-boot and >> u-boot-env from within >> Linux to the NAND, but u-boot does not complain about >> anything (as noted in >> your link). >> >> -- >> 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 > > From louigi600 at yahoo.it Sat Mar 19 18:12:40 2011 From: louigi600 at yahoo.it (Davide) Date: Sat, 19 Mar 2011 18:12:40 +0000 (GMT) Subject: [ARMedslack] Hello In-Reply-To: <4D84D6EF.3020802@laprjns.com> Message-ID: <864856.18087.qm@web29716.mail.ird.yahoo.com> That's not what was going on on my dockstar as I was on the serial console and I saw nothing. Whatever was the issue I think it must be something specific to my dockstar setup or even me screwing up something. Whatever it was I'm up and running with current and I'm happy about that apart some minor problems with vim not cutting and pasting correctly. I'm now moving on to the interesting things I want to implement on my dockstar. Thanks a milion to everybody for the hints and sorry for asking some irrelevant questions. --- Sab 19/3/11, Rich ha scritto: > Da: Rich > Oggetto: Re: [ARMedslack] Hello > A: armedslack at lists.armedslack.org > Data: Sabato 19 marzo 2011, 17:16 > Regarding the 13.1 failing to boot > problem.? I think all of us dockstar > users with the exception of Thorston had the same > problem.? I believe it > is related to the fact that the dockstar doesn't have a > real time clock > and hence all the installed files get bad time > stamps.? So on first boot > it fails a fdisk check and just stalls there waiting for > user input, but > since you can't see this without? a serial connection, > it appears that > it never booted up.???The difference with > current is that it now > includes e2fsck.conf in /etc which allows fdisk to ignore > bad time > stamps.? I willing to bet if you add this file to the > 13.1 install it > would boot also. > > Rich Lapointe > > > On 03/17/2011 02:23 PM, Davide wrote: > > Well I checked md5sum on the 13.1 miniroot tarball and > it was ok. > > I got the kernel and initrd from /boot in the miniroot > after extraction so I'm giessung they should be ok. > > > > Not sure if 13.1 kernel has changed since you two > tried but I can assure you that kernel gets loaded and > booted but then nothing else: > > 7706248 bytes read > > ## Booting kernel from Legacy Image at 06400000 ... > >? ???Image > Name:???Linux-2.6.33.5-kirkwood > >? ???Image > Type:???ARM Linux Kernel Image > (uncompressed) > >? ???Data Size:? ? > 2096716 Bytes = 2 MiB > >? ???Load Address: 00008000 > >? ???Entry Point:? 00008000 > >? ???Verifying Checksum ... OK > > ## Loading init Ramdisk from Legacy Image at 01100000 > ... > >? ???Image > Name:???Slackware ARM Initial RAM disk f > >? ???Image > Type:???ARM Linux RAMDisk Image (gzip > compressed) > >? ???Data Size:? ? > 7706184 Bytes = 7.3 MiB > >? ???Load Address: 00000000 > >? ???Entry Point:? 00000000 > >? ???Verifying Checksum ... OK > >? ???Loading Kernel Image ... OK > > OK > > > > Starting kernel ... > > > > Uncompressing Linux... done, booting the kernel. > > > > This is the last thing that my doickstar does untill > hard reset with 13.1 kernel 2.6.33.5-kirkwood > > > > I noticed that this is not the default 13.1 kernel on > x86 which is 2.6.33.4 so things may have changed since > then. > > I can assure you that I cut and pasted the very same > instructions in order to boot from u-boot so there is ither > something wrong with the kernel or something wrong with my > dockstar. > > > > Here are the instructions I'm using (which have now > been saved to flash as it looks save for booting > with???2.6.38rc8-kirkwood: > > setenv x_bootcmd_kernel 'fatload usb 0:1 0x6400000 > uimage' > > setenv x_bootcmd_initrd 'fatload usb 0:1 0x1100000 > uinitrd' > > setenv x_bootargs_root 'root=LABEL=usbroot ro > rootfstype=ext2' > > setenv x_bootargs 'console=ttyS0,115200 > 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) > ro' > > setenv bootcmd '${x_bootcmd_usb}; ${x_bootcmd_kernel}; > ${x_bootcmd_initrd}; setenv bootargs ${x_bootargs} > ${x_bootargs_root}; bootm 0x6400000 0x1100000;' > > boot > > > > This works with 2.6.38rc8-kirkwood but not with > 2.6.33.5-kirkwood. > > One other thing I've not checked out is if with the > 13.1 kernel it's only the serial console that is dead ... > but the led on the usb stick seems dead too so my giess is > that there is more to it then just the serial console. > > > > Regards > > David > > --- Gio 17/3/11, Thorsten M?hlfelder? > ha scritto: > > > >? ? > >> Da: Thorsten M?hlfelder > >> Oggetto: Re: [ARMedslack] Hello > >> A: "Slackware ARM port" > >> Data: Gioved? 17 marzo 2011, 18:17 > >> Am Thursday 17 March 2011 17:48:09 > >> schrieb Stuart Winter: > >>? ? ? > >>> On Thu, 17 Mar 2011, Davide wrote: > >>>? ? ? ? > >>>> I downloaded miniroot current and did the > exact > >>>>? ? ? ? ? > >> same and it booted !!! > >>? ? ? > >>>> I guess there is something wrong with > 13.1's > >>>>? ? ? ? ? > >> kirkwood kernel image. > >>? ? ? > >>> NOthing wrong with 13.1's kirkwood kernel - > works fine > >>>? ? ? ? > >> on the SheevaPlug, > >>? ? ? > >>> Guru and OpenRD client.? I don't know > what the > >>>? ? ? ? > >> support was like for the > >>? ? ? > >>> Dockstar for that kernel though (or if it was > even in > >>>? ? ? ? > >> there at all!) > >> > >> I can confirm that I had the 13.1 kernel running > on my > >> dockstar without > >> problems. > >> > >>? ? ? > >>>> The only thing I noticed wrong while > system came > >>>>? ? ? ? ? > >> up is: > >>? ? ? > >>>> [???25.669649] > uncorrectable error > >>>>? ? ? ? ? > >> : > >>? ? ? > >>>> [???25.672905] end_request: > I/O > >>>>? ? ? ? ? > >> error, dev mtdblock0, sector 1920 > >>? ? ? > >>>> [???25.678944] Buffer I/O > error on > >>>>? ? ? ? ? > >> device mtdblock0, logical block 240 > >>? ? ? > >>>> [???25.839517] > uncorrectable error > >>>>? ? ? ? ? > >> : > >>? ? ? > >>>> [???25.845664] end_request: > I/O > >>>>? ? ? ? ? > >> error, dev mtdblock0, sector 1920 > >>? ? ? > >>>> [???25.851715] Buffer I/O > error on > >>>>? ? ? ? ? > >> device mtdblock0, logical block 240 > >>? ? ? > >>>> [???25.860583] > uncorrectable error > >>>>? ? ? ? ? > >> : > >>? ? ? > >>>> [???25.863897] > uncorrectable error > >>>>? ? ? ? ? > >> : > >>? ? ? > >>>> [???25.867630] end_request: > I/O > >>>>? ? ? ? ? > >> error, dev mtdblock0, sector 0 > >>? ? ? > >>>> [???25.873419] Buffer I/O > error on > >>>>? ? ? ? ? > >> device mtdblock0, logical block 0 > >>? ? ? > >>>> [???25.879845] > uncorrectable error > >>>>? ? ? ? ? > >> : > >>? ? ? > >>>> [???25.883085] > uncorrectable error > >>>>? ? ? ? ? > >> : > >>? ? ? > >>>> [???25.886731] end_request: > I/O > >>>>? ? ? ? ? > >> error, dev mtdblock0, sector 8 > >>? ? ? > >>>> This may be because mtdparts may be > incorrect > >>>>? ? ? ? ? > >> since I'm using openwrt > >>? ? ? > >>>> second stage u-boot that may have passed > wrong > >>>>? ? ? ? ? > >> flash partitions to > >>? ? ? > >>>> kernel. Hope it did not make a mess of > the > >>>>? ? ? ? ? > >> content. > >>? ? ? > >>> http://www.spinics.net/lists/arm-kernel/msg62881.html > >>> > >>> AFAIK it's nothing to worry about, but read up > on it > >>>? ? ? ? > >> by following the info > >>? ? ? > >>> in there. > >>>? ? ? ? > >> I have the same errors and I've assumed that they > are bad > >> block related. The > >> link confirmed that in some way (OOB holds bad > block > >> information and some > >> other data as well). But I've wondered why the > mtd > >> partitions are touched at > >> bootup, even they are not mounted. > >> Was this issue introduced with new kernels? On > another > >> device I'm using a > >> 2.6.24 and 2.6.29 kernel and I'm writing u-boot > and > >> u-boot-env from within > >> Linux to the NAND, but u-boot does not complain > about > >> anything (as noted in > >> your link). > >> > >> -- > >> 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 > > > >? ? > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > From richard.lapointe at gmail.com Sat Mar 19 22:21:05 2011 From: richard.lapointe at gmail.com (Rich) Date: Sat, 19 Mar 2011 18:21:05 -0400 Subject: [ARMedslack] TTl level serial adapter In-Reply-To: <791079.52409.qm@web29706.mail.ird.yahoo.com> References: <791079.52409.qm@web29706.mail.ird.yahoo.com> Message-ID: <4D852C51.4060204@laprjns.com> Yes, but not all of the cheap CA-45/ DKU-5 cables use the same color wires. My CA-45 has blue, red and orange wires. After cutting off the mobile phone plug, confirm which pin on the plug goes to which wire with a continuity tester. Here's a pin out reference: http://buffalo.nas-central.org/wiki/File:CA-42_DKU-5_pinout.jpg Pin 4, 3.3V is not needed, just the pin 6 RX data, pin 7 TX DATA, and PIN 8 3http://buffalo.nas-central.org/wiki/File:CA-42_DKU-5_pinout.jpg GND Rich On 03/13/2011 01:42 AM, Davide wrote: > Having a look on the archived I noticed that people are finding difficulty in getting shuch adapters. > > Really it's not a problem it's easy and cheap: > go off to ebay and look for the cheapes nokia DKU-5 usb cable (I got 2 for less then 7 euro including shipping). > When you get it cut off the mobile phone plug and 3 wires should come out: > Blue = GND > Yellow = RX > White = TX > > I like to put the smallest probe clips I can find around so that I don't need to fiddle with connectors for each hardware I want to interface to. > > That's it ! > > The cable has a usb 2 serial converter in it and is designed for (I think 3.3v) ttl nevel opeation. I've used it on my dockstar successfully. > > The the converter inside it is well supported even under linux (pl2303: Prolific PL2303 USB to serial adaptor). > > Have fun > David > > > > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > > From louigi600 at yahoo.it Sun Mar 20 01:53:05 2011 From: louigi600 at yahoo.it (Davide) Date: Sun, 20 Mar 2011 01:53:05 +0000 (GMT) Subject: [ARMedslack] rc.wireless problem In-Reply-To: <4D852C51.4060204@laprjns.com> Message-ID: <754060.91859.qm@web29708.mail.ird.yahoo.com> Hi all. I noticed this thing that drove me a little mad. the slackware rc.wireless scritp checks out if a device is wireless by this function in the script: is_wireless_device () { #[ -x $IWPATH/iwconfig ] || return 1 #LC_ALL=C $IWPATH/iwconfig $1 2>&1 | \ # grep -Eiq "no wireless extensions|no such device" || return 0 #return 1 if [ ! -d /sys/class/net/${1}/wireless ]; then # no wireless interface return 1 else # interface has wireless extensions return 0 fi } Well it appears that the sys tree may be missing /sys/class/net/${1}/wireless (at least with kirkwood current kernel). Most people would not notice this issue untill you try to get a wireless NIC to be correctly configures right after you plug it in. Not sure if this is an architecture port issue, a kernel issue or a dockstar specific issue but I changed that function towork around the problem: is_wireless_device () { if [ $($IWCOMMAND |grep -c "IEEE 802") -eq 0 ]; then # no wireless interface return 1 else # interface has wireless extensions return 0 fi } This relies on what iwconfig has to say about the NIC, which in case it's an architecture difference, should work regardless of the underlying ARCH so long as iwconfig is working properly. Regards David From quax at lin2go.com Sun Mar 20 02:31:11 2011 From: quax at lin2go.com (Manfred =?utf-8?b?TcO8bGxlcg==?=) Date: Sun, 20 Mar 2011 02:31:11 +0000 (UTC) Subject: [ARMedslack] ARMed Slack on Toshiba AC100 netbook? References: <201103011820.57394.thenktor@gmx.de> Message-ID: Thorsten M?hlfelder gmx.de> writes: > > I wonder If anyone has tried ARMed Slack on a Toshiba AC100 netbook? > Hi Thorsten, at the very moment I've started porting FluxFlux to ARMed Slack using the ac100 as dev machine. I'm at a very early stage, but I think this netbook is a very good start to be prepared for the release of tegra 4. Regards, Manfred aka Quax From unixjohn1969 at gmail.com Tue Mar 22 19:54:09 2011 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Tue, 22 Mar 2011 15:54:09 -0400 Subject: [ARMedslack] rc.wireless problem In-Reply-To: <754060.91859.qm@web29708.mail.ird.yahoo.com> References: <754060.91859.qm@web29708.mail.ird.yahoo.com> Message-ID: <4D88FE61.1030803@gmail.com> On 03/19/2011 09:53 PM, Davide wrote: > Well it appears that the sys tree may be missing /sys/class/net/${1}/wireless (at least with kirkwood current kernel). > Most people would not notice this issue untill you try to get a wireless NIC to be correctly configures right after you plug it in. > Not sure if this is an architecture port issue, a kernel issue or a dockstar specific issue but I changed that function towork around the problem: All I can report is that on a GuruPlug with the built in wireless (running as an access point), I have neither the /sys/class/net/wireless directory nor does it show up with your check using iwconfig root at guruslack:/sys/class/net# l total 0 lrwxrwxrwx 1 root root 0 Mar 22 15:48 eth0 -> ../../devices/platform/mv643xx_eth_port.0/net/eth0/ lrwxrwxrwx 1 root root 0 Mar 22 15:48 eth1 -> ../../devices/platform/mv643xx_eth_port.1/net/eth1/ lrwxrwxrwx 1 root root 0 Mar 22 15:48 eth2 -> ../../devices/platform/orion-ehci.0/usb1/1-1/1-1.2/1-1.2:1.0/net/eth2/ lrwxrwxrwx 1 root root 0 Mar 22 15:48 lo -> ../../devices/virtual/net/lo/ lrwxrwxrwx 1 root root 0 Mar 22 15:48 uap0 -> ../../devices/virtual/net/uap0/ root at guruslack:/sys/class/net# iwconfig lo no wireless extensions. eth0 no wireless extensions. eth1 no wireless extensions. eth2 no wireless extensions. uap0 no wireless extensions. root at guruslack:/sys/class/net# uap0 is the wireless device. -- === 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 louigi600 at yahoo.it Wed Mar 23 07:15:54 2011 From: louigi600 at yahoo.it (Davide) Date: Wed, 23 Mar 2011 07:15:54 +0000 (GMT) Subject: [ARMedslack] rc.wireless problem In-Reply-To: <4D88FE61.1030803@gmail.com> Message-ID: <998223.33553.qm@web29707.mail.ird.yahoo.com> > > Well it appears that the sys tree may be missing > /sys/class/net/${1}/wireless (at least with kirkwood current > kernel). > > Most people would not notice this issue untill you try > to get a wireless NIC to be correctly configures right after > you plug it in. > > Not sure if this is an architecture port issue, a > kernel issue or a dockstar specific issue but I changed that > function towork around the problem: > > All I can report is that on a GuruPlug with the built in > wireless (running as an access point), I have neither the > /sys/class/net/wireless directory nor does it show up with > your check using iwconfig > > root at guruslack:/sys/class/net# l > total 0 > lrwxrwxrwx 1 root root 0 Mar 22 15:48 eth0 -> > ../../devices/platform/mv643xx_eth_port.0/net/eth0/ > lrwxrwxrwx 1 root root 0 Mar 22 15:48 eth1 -> > ../../devices/platform/mv643xx_eth_port.1/net/eth1/ > lrwxrwxrwx 1 root root 0 Mar 22 15:48 eth2 -> > ../../devices/platform/orion-ehci.0/usb1/1-1/1-1.2/1-1.2:1.0/net/eth2/ > lrwxrwxrwx 1 root root 0 Mar 22 15:48 lo -> > ../../devices/virtual/net/lo/ > lrwxrwxrwx 1 root root 0 Mar 22 15:48 uap0 -> > ../../devices/virtual/net/uap0/ > root at guruslack:/sys/class/net# iwconfig > lo? ? ? ? no wireless extensions. > > eth0? ? ? no wireless extensions. > > eth1? ? ? no wireless extensions. > > eth2? ? ? no wireless extensions. > > uap0? ? ? no wireless extensions. > > root at guruslack:/sys/class/net# > > uap0 is the wireless device. > But that means you have already done something to the interface to put it in master mode. What does iwconfig say amout it before you do that ? The part I modified is to be run while bringing up the device at boot time ... I made more arrangements to the scripts in order to bring up the interface in AP mode: if you're intrested I can hand them over. Anyway if before putting that to master mode iwconfig reports correctly it's ok ... if it's still wrong one could try with iw. What does iw have to say about it (supposing it's phy0) iw dev uap0 info and iw phy phy0 info Regards David From rw at rlworkman.net Thu Mar 24 04:37:28 2011 From: rw at rlworkman.net (Robby Workman) Date: Wed, 23 Mar 2011 23:37:28 -0500 Subject: [ARMedslack] Netgear Stora Message-ID: <20110323233728.34e49e13@liberty.rlwhome.lan> Well, as those of you in the IRC channel [1], I recently acquired a Netgear Stora [2], which is a consumer grade NAS appliance. It runs a 2.6.22.18 kernel with RedHat userland, and it's terribly crippled and locked down and allegedly backdoored, and the only way to administer it is through a web interface that quite frankly sucks goat balls. However, ArmedSlack runs just fine on it after a bit of cajoling (with a bit of guidance at the OpenStora [3] forums [4]). You'll want to get a serial cable for it (you can make one, modify the JTAG/UART box for GuruPlug devices, or buy one from "bigbrett" on the previously mentioned forum - I can confirm that his work fine). Once you boot with the serial cable attached, you'll need to set arcNumber=1680 (that's actually not correct, but Stora support isn't in the mainline kernels, and all of the patchsets are too old to apply, and 1680 seems to work fine - ymmv), and as usual, set mainlineLinux=yes From there, use INSTALL_KIRKWOOD.TXT (in the armedslack tree) to boot the installer environment. Bring up the network and mount your NFS share where the armedslack tree lives. Flash the kernel uImage (no need for initrd) to /dev/mtd1: # flash_eraseall /dev/mtd1 # nandwrite -p /dev/mtd1 uImage Now you need to put a ubi image on mtd2. I tried (and failed) (SEVERAL times) to create a ubi image that could be flashed to mtd2; I don't know where I'm going wrong, since I've successfully created one for a GuruPlug, but regardless, I failed, sooo... [5] Let's get a ubi filesystem on mtd2: # ubiformat /dev/mtd2 -O 2048 # ubiattach /dev/ubi_ctrl -m 2 -O 2048 # ubimkvol -N rootfs -m /dev/ubi0 # mount -t ubifs ubi0:rootfs /mnt # tar xf /path/to/rootfs.tar.gz -C /mnt # ** edit inside /mnt as needed ** Finally, you'll see this in the uboot environment: bootargs_root=ubi.mtd=2,2048 root=ubi0:rootfs rootfstype=ubifs init=/linuxrc You'll want to change that to this: bootargs_root=ubi.mtd=2,2048 root=ubi0:rootfs rootfstype=ubifs Unless I've forgotten something, a reboot should result in ArmedSlack running on the machine... :-) [1] #armedslack on freenode [2] http://www.newegg.com/Product/Product.aspx?Item=N82E16822122083&cm_re=stora-_-22-122-083-_-Product [3] http://www.openstora.com/wiki/index.php?title=Main_Page [4] http://www.openstora.com/phpBB3/ [5] Here's the method used to create (broken) ubi images: (obviously /shared/rootfs will differ) # mkfs.ubifs \ -x zlib \ -r /shared/rootfs \ -m 2048 \ -e 129024 \ -c 2047 \ -o ubifs.img # ubinize \ -m 2048 \ -p 128KiB \ -s 512 \ -o rootfs.stora.img \ ubi.cfg # ubiformat \ /dev/mtd2 \ -s 512 \ -O 2048 \ -f /shared/rootfs.stora.img From louigi600 at yahoo.it Thu Mar 24 06:41:49 2011 From: louigi600 at yahoo.it (Davide) Date: Thu, 24 Mar 2011 06:41:49 +0000 (GMT) Subject: [ARMedslack] executing at commands on modem from udev helper scripts In-Reply-To: <998223.33553.qm@web29707.mail.ird.yahoo.com> Message-ID: <307422.89180.qm@web29718.mail.ird.yahoo.com> I put up on my x86 slackware laptop a pppd helper script so that the provider is detected from the sim of my mobile internet key (which is esseintially a usm bodem) and a pppd session automatically started if a peer is setu up for that provider. The same scrips is not working on armedslack-current running on my dockstar. It appears that on my dockstar the modem is not avalible untill all the udev scrips have finished. I postponed the pppd helper script to 99-ppphelper.rules and even wrote c programs (while doing this with ordinary shell script on x86) to write AT commands to modem and read return values from modem but it's a no go. I put in a sleep 20 in the helper script and noticed that while the helper script is still running the /dev/tty..... (ACM0 or USB0 depending on which usb stick I use) special characted device is not avalible for my modem untill udev is done. Anybody know what's going on and/or have any idea how to work around the problem ? Regards David From louigi600 at yahoo.it Thu Mar 24 20:52:37 2011 From: louigi600 at yahoo.it (Davide) Date: Thu, 24 Mar 2011 20:52:37 +0000 (GMT) Subject: [ARMedslack] atd trouble In-Reply-To: <307422.89180.qm@web29718.mail.ird.yahoo.com> Message-ID: <739082.3870.qm@web29720.mail.ird.yahoo.com> Can't seem to get atd running in background on armedslack-current. It will run in foreground (also in debug mode) but produces nothing useful for debugging why it will not run as daemon. All I could get is exit code 1. Any idea how to fix this ? Regards David From louigi600 at yahoo.it Thu Mar 24 21:03:22 2011 From: louigi600 at yahoo.it (Davide) Date: Thu, 24 Mar 2011 21:03:22 +0000 (GMT) Subject: [ARMedslack] R: atd trouble In-Reply-To: <739082.3870.qm@web29720.mail.ird.yahoo.com> Message-ID: <685308.22700.qm@web29705.mail.ird.yahoo.com> Oh ... it won't run in background when started manually ... but when started at boot time by rc.M it seems to work. Odd but as long as it works :-D Sorry folks David PS: incidently at job was my workaround to the udev trouble for not being able to user usb modem device while helper scripts are running. --- Gio 24/3/11, Davide ha scritto: > Da: Davide > Oggetto: [ARMedslack] atd trouble > A: "Slackware ARM port" > Data: Gioved? 24 marzo 2011, 21:52 > Can't seem to get atd running in > background on armedslack-current. > It will run in foreground (also in debug mode) but produces > nothing useful for debugging why it will not run as daemon. > All I could get is exit code 1. > > Any idea how to fix this ? > > Regards > David > > > > ? ? ? > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > From thenktor at gmx.de Sun Mar 27 14:31:09 2011 From: thenktor at gmx.de (Thorsten =?ISO-8859-1?B?TfxobGZlbGRlcg==?=) Date: Sun, 27 Mar 2011 16:31:09 +0200 Subject: [ARMedslack] ARMed Slack repository with dependency support Message-ID: <20110327163109.6bb184e2@pinkfloyd.tm-net> Hi, there is a ARMed Slack repository with dependency support available at our Salix OS server: http://salix.enialis.net/arm/armedslack-current/ You can use it with a package manager like slapt-get. slapt-get and it's dependencies are available here: http://salix.enialis.net/arm/current/slapt-get/ Just install all of them and you are ready to go: slapt-get --add-keys slapt-get -u slapt-get -i whatever-you-want PS: this slapt-get version is patched to use the faster spkg package tool instead of pkgtools. -- Thorsten M?hlfelder Salix OS: www.salixos.org From pino.otto at gmail.com Sun Mar 27 14:51:52 2011 From: pino.otto at gmail.com (Giovanni) Date: Sun, 27 Mar 2011 16:51:52 +0200 Subject: [ARMedslack] ARMed Slack repository with dependency support In-Reply-To: <20110327163109.6bb184e2@pinkfloyd.tm-net> References: <20110327163109.6bb184e2@pinkfloyd.tm-net> Message-ID: Wow! Great news. I will try it on my Slackware Pandaboard. Best regards, alien jo 2011/3/27 Thorsten M?hlfelder > Hi, > > there is a ARMed Slack repository with dependency support available at > our Salix OS server: > http://salix.enialis.net/arm/armedslack-current/ > > You can use it with a package manager like slapt-get. slapt-get and > it's dependencies are available here: > http://salix.enialis.net/arm/current/slapt-get/ > > Just install all of them and you are ready to go: > slapt-get --add-keys > slapt-get -u > slapt-get -i whatever-you-want > > PS: this slapt-get version is patched to use the faster spkg package > tool instead of pkgtools. > > -- > Thorsten M?hlfelder > Salix OS: www.salixos.org > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > -------------- next part -------------- An HTML attachment was scrubbed... URL: From louigi600 at yahoo.it Mon Mar 28 17:06:47 2011 From: louigi600 at yahoo.it (Davide) Date: Mon, 28 Mar 2011 18:06:47 +0100 (BST) Subject: [ARMedslack] dockstar /etc/mtab inconsistent with /proc/mounts on current In-Reply-To: Message-ID: <610438.51065.qm@web29705.mail.ird.yahoo.com> Hi. While fiddling with rc.S to have / in RO I noticed that /etc/mtab is inconsistent with the content of /proc/mounts. I replaced /etc/mtab with a link to /proc/mounts and things seem to be ok again ... not 100% sure that it's ok to leave it this way. Anyone else spotted the same thing ? I can report that this does not happen on my x86 slackware current. Regards David -------------- next part -------------- An HTML attachment was scrubbed... URL: From geoff at ohdoughnut.com Mon Mar 28 20:25:59 2011 From: geoff at ohdoughnut.com (Geoff Walton) Date: Mon, 28 Mar 2011 16:25:59 -0400 Subject: [ARMedslack] dockstar /etc/mtab inconsistent with /proc/mounts on current In-Reply-To: <610438.51065.qm@web29705.mail.ird.yahoo.com> References: <610438.51065.qm@web29705.mail.ird.yahoo.com> Message-ID: Unless you have done something like got /etc on a different volume than / which creates its own problems then you obviously can't write to / etc. I have done slackware86 on nfs before with a readonly rootfs and I did have the same problem. I soved it by creating a link just the same way you did. I don't think there are any issues with it. I am surpriesed you did not encounter this on the x86 distribution, but I was working with Slackware 11.0 at the so maybe something has changed. On Mon, Mar 28, 2011 at 1:06 PM, Davide wrote: > Hi. > While fiddling with rc.S to have / in RO I noticed that /etc/mtab is > inconsistent with the content of /proc/mounts. > I replaced /etc/mtab with a link to /proc/mounts and things seem to be ok > again ... not 100% sure that it's ok to leave it this way. > Anyone else spotted the same thing ? > I can report that this does not happen on my x86 slackware current. > > Regards > David > > _______________________________________________ > 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 Tue Mar 29 07:19:38 2011 From: louigi600 at yahoo.it (Davide) Date: Tue, 29 Mar 2011 08:19:38 +0100 (BST) Subject: [ARMedslack] dockstar /etc/mtab inconsistent with /proc/mounts on current In-Reply-To: Message-ID: <744972.3684.qm@web29708.mail.ird.yahoo.com> Well on my x86 the inconsistency is not so bad to become a problem: root at hp:~# cat /etc/mtab????????????? /dev/root / ext4 rw,relatime,barrier=1,data=ordered 0 0 proc /proc proc rw 0 0 sysfs /sys sysfs rw 0 0 usbfs /proc/bus/usb usbfs rw 0 0 /dev/sda1 /boot ext4 rw 0 0 tmpfs /dev/shm tmpfs rw 0 0 root at hp:~# cat /proc/mounts rootfs / rootfs rw 0 0 /dev/root / ext4 rw,relatime,barrier=1,data=ordered 0 0 devtmpfs /dev devtmpfs rw,relatime,size=515692k,nr_inodes=128923,mode=755 0 0 proc /proc proc rw,relatime 0 0 sysfs /sys sysfs rw,relatime 0 0 devpts /dev/pts devpts rw,relatime,gid=5,mode=620 0 0 fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0 usbfs /proc/bus/usb usbfs rw,relatime 0 0 /dev/sda1 /boot ext4 rw,relatime,barrier=1,data=ordered 0 0 tmpfs /dev/shm tmpfs rw,relatime 0 0 root at hp:~# On the dockstar none of the pseudo filesystems and tmpfs showed up in the mtab. This meant that doinfg a remount on any tmpfs you would physically remount it over and have 2 tmpfs over one another. This is definitely annoying and useless I know that other distro do the link thing too but I can't recall if they also do something else along with that (like changing default mount behavior not to try write in mtab as it's a link to something that is kernel maintained). Whatever I've more urgent issues in making root readonly to be 100% ctash proof. Regards David --- Lun 28/3/11, Geoff Walton ha scritto: Da: Geoff Walton Oggetto: Re: [ARMedslack] dockstar /etc/mtab inconsistent with /proc/mounts on current A: "Slackware ARM port" Data: Luned? 28 marzo 2011, 22:25 Unless you have done something like got /etc on a different volume than / which creates its own problems then you obviously can't write to?/ etc.? I have done slackware86 on nfs before with a readonly rootfs and I did have the same problem.? I soved it by creating a link just the same way you did.? I don't think there are any issues with it.? I am surpriesed you did not encounter this on the x86 distribution, but I was working with Slackware 11.0 at the so maybe something has changed. ? On Mon, Mar 28, 2011 at 1:06 PM, Davide wrote: Hi. While fiddling with rc.S to have / in RO I noticed that /etc/mtab is inconsistent with the content of /proc/mounts. I replaced /etc/mtab with a link to /proc/mounts and things seem to be ok again ... not 100% sure that it's ok to leave it this way. Anyone else spotted the same thing ? I can report that this does not happen on my x86 slackware current. Regards David _______________________________________________ ARMedslack mailing list ARMedslack at lists.armedslack.org http://lists.armedslack.org/mailman/listinfo/armedslack -----Segue allegato----- _______________________________________________ ARMedslack mailing list ARMedslack at lists.armedslack.org http://lists.armedslack.org/mailman/listinfo/armedslack -------------- next part -------------- An HTML attachment was scrubbed... URL: From m-lists at biscuit.org.uk Tue Mar 29 08:32:57 2011 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Tue, 29 Mar 2011 09:32:57 +0100 (BST) Subject: [ARMedslack] dockstar /etc/mtab inconsistent with /proc/mounts on current In-Reply-To: <744972.3684.qm@web29708.mail.ird.yahoo.com> References: <744972.3684.qm@web29708.mail.ird.yahoo.com> Message-ID: > On the dockstar none of the pseudo filesystems and tmpfs showed up in > the mtab. This meant that doinfg a remount on any tmpfs you would > physically remount it over and have 2 tmpfs over one another. This is > definitely annoying and useless > > I know that other distro do the link thing too but I can't recall if > they also do something else along with that (like changing default mount > behavior not to try write in mtab as it's a link to something that is > kernel maintained). Whatever I've more urgent issues in making root > readonly to be 100% ctash proof. The inconsistancy happens for meon x86_64 too, and also on my ARM boxes. However I have never had any problem with this before and have never noticed it on any platform. There are some mailing list threads about people making mtab a symlink to /proc/mounts -- I haven't read them all, but if you haven't, it'd probably be worth a read -- this isn't a new thing! From louigi600 at yahoo.it Thu Mar 31 17:45:10 2011 From: louigi600 at yahoo.it (Davide) Date: Thu, 31 Mar 2011 18:45:10 +0100 (BST) Subject: [ARMedslack] play with leds on current In-Reply-To: Message-ID: <858747.77410.qm@web29709.mail.ird.yahoo.com> I know most of you can do this better for yourselves ... but it might be handy for those who don't want to enter manually 3 echo's to some odd file in /sys just to make a led blink at a desired rate. Here is the script I made for my lazy self: (BTW the MYOPTIONS array also self generates the help message and the options to be parsed ... just use it with no arguments or with -h and get help on how to use it ) #!/bin/bash DEBUG=0 MYOPTIONS=( "I,,\t\t:Turn ON,-" "O,,\t\t:Turn OFF,-" "b,:,\t:Blink with blinkrate in miliseconds,-" "t,:,\t:Set trigger ,-" "h,,\t\t:Show this help message,0" ) export MYOPTIONS NAME=$(basename $0) dump_options () { echo "Dumping all options : " I=0 while [ $I -lt ${#MYOPTIONS[*]} ] do echo "${MYOPTIONS[$I]}" |/usr/bin/awk -F, '{printf(" -%s=%s\n",$1,$4)}' I=$(/usr/bin/expr $I + 1) done } usage () { cat < Seagate Dockstar led manager OPTIONS EOF I=0 while [ $I -lt ${#MYOPTIONS[*]} ] do OPTION=$(echo "${MYOPTIONS[$I]}" |/usr/bin/cut -d "," -f 1) PARM=$(echo "${MYOPTIONS[$I]}" |/usr/bin/cut -d "," -f 2) HTXT=$(echo "${MYOPTIONS[$I]}" |/usr/bin/cut -d "," -f 3) [ "$PARM" = ":" ] && echo -e "-$OPTION $HTXT" || echo -e "-$OPTION $HTXT" I=$(/usr/bin/expr $I + 1) done echo if [ "$*" != "" ] then echo "Error: $*" exit 1 else exit 0 fi } get_myoptions_array_element () { I=0 SEARCH_OPTION=$(echo "$1" |/usr/bin/tr -d "-") while [ $I -lt ${#MYOPTIONS[*]} ] do OPTION=$(echo "${MYOPTIONS[$I]}" |/usr/bin/cut -d "," -f 1) [ "$OPTION" = "$SEARCH_OPTION" ] && break I=$(/usr/bin/expr $I + 1) done echo $I } get_myoptions_value () { I=0 SEARCH_OPTION=$(echo "$1" |/usr/bin/tr -d "-") while [ $I -lt ${#MYOPTIONS[*]} ] do OPTION=$(echo "${MYOPTIONS[$I]}" |/usr/bin/cut -d "," -f 1) VALUE=$(echo "${MYOPTIONS[$I]}" |/usr/bin/cut -d "," -f 4) [ "$OPTION" = "$SEARCH_OPTION" ] && (echo $VALUE ; break) I=$(/usr/bin/expr $I + 1) done } get_myoptions_entry () { I=0 SEARCH_OPTION=$(echo "$1" |/usr/bin/tr -d "-") while [ $I -lt ${#MYOPTIONS[*]} ] do OPTION=$(echo "${MYOPTIONS[$I]}" |/usr/bin/cut -d "," -f 1) VALUE=$(echo "${MYOPTIONS[$I]}" |/usr/bin/cut -d "," -f -3) [ "$OPTION" = "$SEARCH_OPTION" ] && (echo $VALUE ; break) I=$(/usr/bin/expr $I + 1) done } set_myoptions_value () { AE=$(get_myoptions_array_element $1) VAL=$(get_myoptions_entry $1) NEWE="${VAL},$2" MYOPTIONS[$AE]=$NEWE export MYOPTIONS } set_trigger () { echo "$2" > ${1}/trigger } set_blink () { echo "$2" > ${1}/delay_on echo "$3" > ${1}/delay_off } led_on () { MAX_BRIGHT=$(cat ${1}/max_brightness) echo "none" > ${1}/trigger echo "$MAX_BRIGHT" > ${1}/brightness } led_off () { echo "none" > ${1}/trigger echo "0" > ${1}/brightness } ######################## #MAIN ######################## [ $DEBUG -eq 1 ] && echo -n "Composing optistring for getopt ... " GETOPT_STRING=$(I=0 while [ $I -lt ${#MYOPTIONS[*]} ] do OPTION=$(echo "${MYOPTIONS[$I]}" |/usr/bin/cut -d "," -f 1) PARM=$(echo "${MYOPTIONS[$I]}" |/usr/bin/cut -d "," -f 2) echo -en "${OPTION}$PARM" I=$(/usr/bin/expr $I + 1) done ) [ $DEBUG -eq 1 ] && echo $GETOPT_STRING /usr/bin/getopt $GETOPT_STRING $* >/dev/null 2>/dev/null || \ usage unknown option or insufficient parameters: $* GPO=$(/usr/bin/getopt $GETOPT_STRING $* 2>/dev/null |/usr/bin/tr -d "'") set -- $GPO [ $DEBUG -eq 1 ] && echo "Getopt Parsed Options: $*" [ $DEBUG -eq 1 ] && echo "$# : $*" [ $DEBUG -eq 1 ] && echo -n "Beginning to parse options internally ... " [ "$1" = "--" ] && usage "Insufficient parameters" while [ $# -ge 1 ] do case $1 in -I) set_myoptions_value I 1; set_myoptions_value O 0; shift;; -O) set_myoptions_value O 1; set_myoptions_value I 0; shift;; -b) set_myoptions_value b $2; shift 2 ;; -t) set_myoptions_value t $2; shift 2 ;; -h) usage ;; --) shift ; break ;; *) usage $1 unknown option ;; esac done [ $DEBUG -eq 1 ] && echo "Done" [ $# -lt 1 ] && usage "Insufficient parameters" case $1 in green) LED_DIR="/sys/class/leds/dockstar:green:health" ;; orange) LED_DIR="/sys/class/leds/dockstar:orange:misc" ;; *) usage "Nos such led avalible" esac [ "$(get_myoptions_value t)" != "-" ] && \ set_trigger $LED_DIR $(get_myoptions_value t) if [ "$(get_myoptions_value b)" != "-" ] then ON_TIME=$(echo "$(get_myoptions_value b)" |/usr/bin/cut -d: -f1) OFF_TIME=$(echo "$(get_myoptions_value b)" |/usr/bin/cut -d: -f2) set_trigger $LED_DIR timer /usr/bin/sleep 0.1 set_blink $LED_DIR $ON_TIME $OFF_TIME fi [ "$(get_myoptions_value I)" = "1" ] && led_on $LED_DIR [ "$(get_myoptions_value O)" = "1" ] && led_off $LED_DIR