From m-lists at biscuit.org.uk Thu Jul 1 14:59:54 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Thu, 1 Jul 2010 15:59:54 +0100 (BST) Subject: [ARMedslack] ARM Slackware on the BeagleBoard In-Reply-To: <76DC28D5-619E-4C15-853A-668284D9F8AB@smartfield.com> References: <76DC28D5-619E-4C15-853A-668284D9F8AB@smartfield.com> Message-ID: > I've had some success compiling and building packages (natively). Would > you want them for the extras for arm slack? I'd happily upload them. I only put what is in Slackware into "extra", or anything that's particularly ARM related. The best place for build scripts is slackbuilds.org. From manu2958 at gmail.com Tue Jul 6 01:49:11 2010 From: manu2958 at gmail.com (=?ISO-8859-1?Q?Manuel_F=2E_Mej=EDa_De_Alba?=) Date: Mon, 5 Jul 2010 20:49:11 -0500 Subject: [ARMedslack] Nokia internet tablet Message-ID: Hi List, Thaks in advance, Its posible install armedslack on my nokia n800 internet tablet ? if response is a yes, where i must start to read ? -- Manuel Felipe Mej?a De Alba. -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.oyler at smartfield.com Tue Jul 6 02:51:19 2010 From: john.oyler at smartfield.com (John Oyler) Date: Mon, 5 Jul 2010 21:51:19 -0500 Subject: [ARMedslack] Nokia internet tablet In-Reply-To: References: Message-ID: <835720B3-8CA7-4591-A5A2-EB97D27B3DC8@smartfield.com> I think that it should be possible. Perhaps even easy. I've had good luck getting Arm Slack running on several devices, generally you follow the linux instructions for the device, but substitute in the Slack miniroot filesystem. It's barebones, but once that's extracted to the ext2/3/4 partition of your boot device (usually an SD card), it'll come right up. At which point, you can mount the dvd, and use installpkg to flesh things out more. John O. On Jul 5, 2010, at 8:49 PM, Manuel F. Mej?a De Alba wrote: > Hi List, Thaks in advance, > > Its posible install armedslack on my nokia n800 internet tablet ? > if response is a yes, where i must start to read ? > > -- > Manuel Felipe Mej?a De Alba. > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack From mfmejiad at unal.edu.co Wed Jul 7 04:34:30 2010 From: mfmejiad at unal.edu.co (=?ISO-8859-1?Q?Manuel_F=2E__Mej=EDa_De_Alba?=) Date: Tue, 6 Jul 2010 23:34:30 -0500 Subject: [ARMedslack] Nokia internet tablet Message-ID: Thanks again. Some tutorial ? , is necessary flasher with some especial zImage? Where i can get it ? -- Manuel Felipe Mej?a De Alba. -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.oyler at smartfield.com Wed Jul 7 16:16:27 2010 From: john.oyler at smartfield.com (John Oyler) Date: Wed, 7 Jul 2010 11:16:27 -0500 Subject: [ARMedslack] Nokia internet tablet In-Reply-To: References: Message-ID: I'd cheat and use someone else's kernel for this. Probably the one that comes with Nokia, unless that's totally unsuitable. Copy it and its kernel modules directory into the appropriate place on Slack. If you've compiled kernels for linux before, you'd basically get the Slackware kernel source (which is vanilla, few or no patches applied), and then you'd have to track down whichever patches (might be more than one) were appropriate for the N800. Apply those, compile it. I've yet to do this for the BeagleBoard, it seems pretty hairy and I don't really need it myself. John O. On Jul 6, 2010, at 11:34 PM, Manuel F. Mej?a De Alba wrote: > Thanks again. > > Some tutorial ? , is necessary flasher with some especial zImage? Where i can get it ? > > -- > Manuel Felipe Mej?a De Alba. > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack From cedric.vincent at gmail.com Sat Jul 10 17:07:48 2010 From: cedric.vincent at gmail.com (=?UTF-8?Q?C=C3=A9dric_VINCENT?=) Date: Sat, 10 Jul 2010 19:07:48 +0200 Subject: [ARMedslack] UBI support is [partially] broken in Slackware/ARM 13.1 on SheevaPlug Message-ID: Hi all, It looks like I hit the following bug with Slackware/ARM 13.1 on my SheevaPlug: http://www.linux-mtd.infradead.org/faq/ubi.html#L_subpage_verify_fail "ubi_io_write: error -5 while writing 512 bytes to PEB 5:512" If you have a 2048 bytes per NAND page device, and have CONFIG_MTD_NAND_VERIFY_WRITE enabled in your kernel, you will need to turn it off. The code does not currently (as of 2.6.26) perform verification of sub-page writes correctly. As UBI is one of the few users of sub-page writes, not much else seems to be affected by this bug. As described in the previous quote, I'm now able to burn my favorite distro into the NAND Flash by using a kernel without the option "CONFIG_MTD_NAND_VERIFY_WRITE". Technically, this bug appears on the SheevaPlug when I run the command "ubiattach" after formatting the MTD device. Regards, C?dric. From m-lists at biscuit.org.uk Sun Jul 11 11:39:29 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sun, 11 Jul 2010 12:39:29 +0100 (BST) Subject: [ARMedslack] UBI support is [partially] broken in Slackware/ARM 13.1 on SheevaPlug In-Reply-To: References: Message-ID: Hi C?dric > CONFIG_MTD_NAND_VERIFY_WRITE enabled in your kernel, you will need I've changed this for the next build of -current's kernel, but won't fix it in 13.1 because writing to NAND isn't documented as a supported installation method. From cedric.vincent at gmail.com Sun Jul 11 14:45:18 2010 From: cedric.vincent at gmail.com (=?UTF-8?Q?C=C3=A9dric_VINCENT?=) Date: Sun, 11 Jul 2010 16:45:18 +0200 Subject: [ARMedslack] UBI support is [partially] broken in Slackware/ARM 13.1 on SheevaPlug In-Reply-To: References: Message-ID: > I've changed this for the next build of -current's kernel, but won't fix > it in 13.1 because writing to NAND isn't documented as a supported > installation method. OK, thanks! C?dric. From unixjohn1969 at gmail.com Mon Jul 12 00:43:58 2010 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Sun, 11 Jul 2010 20:43:58 -0400 Subject: [ARMedslack] UBI support is [partially] broken in Slackware/ARM 13.1 on SheevaPlug In-Reply-To: References: Message-ID: Thanks for finding this as I only test on SD or USB but all my final installs are to NAND. But I use custom kernels and I need tidbits like this. Thanks so much! ** This message has been delivered via a Google Android ** On Jul 11, 2010 10:45 AM, "C?dric VINCENT" wrote: > I've changed this for the next build of -current's kernel, but won't fix > it in 13.1 because writ... OK, thanks! C?dric. _______________________________________________ ARMedslack mailing list ARMedslack at lists.arm... -------------- next part -------------- An HTML attachment was scrubbed... URL: From m-lists at biscuit.org.uk Tue Jul 13 08:25:58 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Tue, 13 Jul 2010 09:25:58 +0100 (BST) Subject: [ARMedslack] UBI support is [partially] broken in Slackware/ARM 13.1 on SheevaPlug In-Reply-To: References: Message-ID: > Thanks for finding this as I only test on SD or USB but all my final > installs are to NAND. But I use custom kernels and I need tidbits like this. How are you creating the image to write to NAND? Are you using the mini root fs and adding packages, or using the installer? I'd like to be able to ship some "unsupported" (because the installer would need work in order to do any kind of NAND installation) documents, if it makes sense -- do you have anything documented that could be made publically available? From unixjohn1969 at gmail.com Tue Jul 13 18:19:21 2010 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Tue, 13 Jul 2010 14:19:21 -0400 Subject: [ARMedslack] UBI support is [partially] broken in Slackware/ARM 13.1 on SheevaPlug In-Reply-To: References: Message-ID: <4C3CAE29.7000005@gmail.com> Stuart Winter wrote: > >> Thanks for finding this as I only test on SD or USB but all my final >> installs are to NAND. But I use custom kernels and I need tidbits like this. > > How are you creating the image to write to NAND? > Are you using the mini root fs and adding packages, or using the > installer? > > I'd like to be able to ship some "unsupported" (because the > installer would need work in order to do any kind of NAND > installation) documents, if it makes sense -- do you have anything > documented that could be made publically available? I am not using any installer. I develop with your slackware install on a 4gb SD card (USB dongle) and when I am ready to roll my stuff together, I do a minimal install onto another card with what I need (no development), roll a JFFS2 on my Slackware desktop and make sure everything looks perfect then transfer that back to the development SD card (ftp/nfs/whatever) and burn it into NAND typically while the 4gb SD card is booted. I roll my own kernel and strip out anything but what I essentially need (typically no modules except maybe a future need), test booting from the 4gb SD card, then burn to NAND. I do not use initrd in my final installs and then the plug just stands alone like it's supposed to be. I can fit most stuff into 70mb leaving alot of the 512 NAND free for future. I have compiled qemu and run an Intel slackware on ARM (for proprietary software with no ARM counterpart) with the virtual disk in under 40mb. So that's 110mb total. That leaves room for web server files or a database, etc. Johnny O -- === 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 linuxxr at yahoo.com Wed Jul 14 03:48:33 2010 From: linuxxr at yahoo.com (Brian Kelley) Date: Tue, 13 Jul 2010 20:48:33 -0700 (PDT) Subject: [ARMedslack] UBI support is [partially] broken in Slackware/ARM 13.1 on SheevaPlug In-Reply-To: Message-ID: <887943.64540.qm@web52406.mail.re2.yahoo.com> an installable .jffs2 file is need to ease the install onto the openmoko freerunner --- On Tue, 7/13/10, Stuart Winter wrote: From: Stuart Winter Subject: Re: [ARMedslack] UBI support is [partially] broken in Slackware/ARM 13.1 on SheevaPlug To: "Slackware ARM port" Date: Tuesday, July 13, 2010, 3:25 AM > Thanks for finding this as I only test on SD or USB but all my final > installs are to NAND. But I use custom kernels and I need tidbits like this. How are you creating the image to write to NAND? Are you using the mini root fs and adding packages, or using the installer? I'd like to be able to ship some "unsupported" (because the installer would need work in order to do any kind of NAND installation) documents, if it makes sense -- do you have anything documented that could be made publically available? _______________________________________________ ARMedslack mailing list ARMedslack at lists.armedslack.org http://lists.armedslack.org/mailman/listinfo/armedslack -------------- next part -------------- An HTML attachment was scrubbed... URL: From m-lists at biscuit.org.uk Wed Jul 14 12:44:58 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Wed, 14 Jul 2010 13:44:58 +0100 (BST) Subject: [ARMedslack] UBI support is [partially] broken in Slackware/ARM 13.1 on SheevaPlug In-Reply-To: <887943.64540.qm@web52406.mail.re2.yahoo.com> References: <887943.64540.qm@web52406.mail.re2.yahoo.com> Message-ID: > an installable .jffs2 file is need to ease the install onto the openmoko > freerunner Such an image would require customisation though, as the miniroot fs does, wouldn't it? So what benefit would there be in providing a jffs2 file? Surely it'd be better to provide the mini rootfs; the users follow the instructions and then create a jffs2 file from the result. I forgot that to write to NAND you need a jffs2 image -- I cannot see the installer being modified to do this; quite frankly I have no idea how you could go about doing it automatically - I think there'd be too many variables to consider. However, instructions about making a jffs2 image from the mini rootfs image are welcomed, if applicable. From john.oyler at smartfield.com Wed Jul 14 13:56:41 2010 From: john.oyler at smartfield.com (John Oyler) Date: Wed, 14 Jul 2010 08:56:41 -0500 Subject: [ARMedslack] Has anyone gotten ARM Slack running on the TS-7500? Message-ID: <679024A4-3D77-4F62-A9EF-B787C7387A77@smartfield.com> http://www.embeddedarm.com/products/board-detail.php?tab=options&product=TS-7500 It's fairly nice, and the debian-based linux they ship with it is workable, but I'm itching to see Slackware running on it. Was wondering if anyone has had any experience with it. John O. From cedric.vincent at gmail.com Thu Jul 15 07:06:32 2010 From: cedric.vincent at gmail.com (=?UTF-8?Q?C=C3=A9dric_VINCENT?=) Date: Thu, 15 Jul 2010 09:06:32 +0200 Subject: [ARMedslack] UBI support is [partially] broken in Slackware/ARM 13.1 on SheevaPlug In-Reply-To: References: <887943.64540.qm@web52406.mail.re2.yahoo.com> Message-ID: On Wed, Jul 14, 2010 at 2:44 PM, Stuart Winter wrote: > However, instructions about making a jffs2 image from the mini rootfs > image are welcomed, if applicable. I don't know about JFFS2, but it is quite easy with UBIFS. Actually I just followed instructions from this wiki: http://www.plugcomputer.org/plugwiki/index.php/Enabling_UBIFS#Making_your_UBIFS_image with some help from the official FAQ to double-check some parameters: http://www.linux-mtd.infradead.org/faq/ubifs.html Regards, C?dric. From mozes at slackware.com Fri Jul 16 08:13:08 2010 From: mozes at slackware.com (Stuart Winter) Date: Fri, 16 Jul 2010 01:13:08 -0700 (PDT) Subject: [ARMedslack] Linux 2.6.35 problems In-Reply-To: References: Message-ID: Hi folks Has anyone tried compiling 2.6.35rc5 ? I wanted to build it to include the patch for OpenRD "Ultimate", and 2.6.35 also contains the Guruplug patches and other bits that were included in our 2.6.33 kernel. I've tried the kernel with and without these patches. I built it using the config file for 2.6.33.6, and make oldconfig. Booting the installer, or upgradepkg'g to the new packages results in: root at slackware:/etc/rc.d# uname -a Linux slackware 2.6.35rc5-kirkwood #2 PREEMPT Thu Jul 15 21:50:04 BST 2010 armv5tel GNU/Linux root at slackware:/etc/rc.d# modprobe dm-mod FATAL: Error inserting dm_mod (/lib/modules/2.6.35rc5-kirkwood/kernel/drivers/md/dm-mod.ko.gz): Invalid module format The problem persists if I gunzip them first, too. The problem first appears in dmesg as: [ 23.492643] mv_xor mv_xor.1: Marvell XOR: ( xor fill cpy ) [ 23.532649] mv_xor mv_xor.2: Marvell XOR: ( xor cpy ) [ 23.572644] mv_xor mv_xor.3: Marvell XOR: ( xor fill cpy ) [ 23.579243] TCP cubic registered [ 23.582490] NET: Registered protocol family 17 [ 23.586994] Gating clock of unused units [ 23.587004] before: 0x00cfc3dd [ 23.587011] after: 0x00cfc1dd [ 23.587600] registered taskstats version 1 [ 23.592314] rtc-mv rtc-mv: setting system clock to 2010-07-16 07:22:03 UTC ( 1279264923) [ 23.600575] Freeing init memory: 132K [ 23.648320] dm_mod: unknown relocation: 3 [ 23.679064] md_mod: unknown relocation: 3 [ 23.690284] nls_base: unknown relocation: 3 [ 23.702230] mbcache: unknown relocation: 3 [ 23.714177] mbcache: unknown relocation: 3 [ 23.738261] jbd2: unknown relocation: 3 [ 23.749331] nls_base: unknown relocation: 3 [ 23.760564] nls_base: unknown relocation: 3 [ 23.802296] sunrpc: unknown relocation: 3 [ 23.843788] reiserfs: unknown relocation: 3 [ 23.855491] exportfs: unknown relocation: 3 ... anybody got any ideas? From cedric.vincent at gmail.com Fri Jul 16 08:36:36 2010 From: cedric.vincent at gmail.com (=?UTF-8?Q?C=C3=A9dric_VINCENT?=) Date: Fri, 16 Jul 2010 10:36:36 +0200 Subject: [ARMedslack] Linux 2.6.35 problems In-Reply-To: References: Message-ID: Hi Stuart, It appears your Binutils has generated a relocation the kernel module loader does known about (R_ARM_REL32). AFAIK, nothing special has changed in this part of the kernel since v2.6.33: git/linux-2.6$ git log --pretty=oneline v2.6.33..v2.6.35-rc5 arch/arm/kernel/module.c arch/arm/include/asm/elf.h I would say the problem may come from the way your modules have been generated. Did you change your toolchain? Is there some new compilation/link flags? Regards, C?dric. From m-lists at biscuit.org.uk Fri Jul 16 08:47:07 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Fri, 16 Jul 2010 09:47:07 +0100 (BST) Subject: [ARMedslack] Linux 2.6.35 problems In-Reply-To: References: Message-ID: > I would say the problem may come from the way your modules have been > generated. Did you change your toolchain? Is there some new > compilation/link flags? No - it's the same as is available in -current at the moment. I build 2.6.33.6 on the same machine only a few days ago, and that works fine.. From cedric.vincent at gmail.com Fri Jul 16 09:19:08 2010 From: cedric.vincent at gmail.com (=?UTF-8?Q?C=C3=A9dric_VINCENT?=) Date: Fri, 16 Jul 2010 11:19:08 +0200 Subject: [ARMedslack] Linux 2.6.35 problems In-Reply-To: References: Message-ID: > Is there some new compilation/link flags? Actually the commit d0679c73 has change the default kernel build flags: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d0679c730395d0bde9a46939e7ba255b4ba7dd7c It was inserted in between v2.6.33-rc6 and v2.6.35-rc2 I don't have access to my ARMedSlack, thus I can't test a new build, sorry. From cedric.vincent at gmail.com Fri Jul 16 10:44:13 2010 From: cedric.vincent at gmail.com (=?UTF-8?Q?C=C3=A9dric_VINCENT?=) Date: Fri, 16 Jul 2010 12:44:13 +0200 Subject: [ARMedslack] UBI support is [partially] broken in Slackware/ARM 13.1 on SheevaPlug In-Reply-To: References: <887943.64540.qm@web52406.mail.re2.yahoo.com> Message-ID: 2010/7/15 C?dric VINCENT : > On Wed, Jul 14, 2010 at 2:44 PM, Stuart Winter wrote: >> However, instructions about making a jffs2 image from the mini rootfs >> image are welcomed, if applicable. > > I don't know about JFFS2, but it is quite easy with UBIFS. Actually I > just followed instructions from this wiki: > > ? ?http://www.plugcomputer.org/plugwiki/index.php/Enabling_UBIFS#Making_your_UBIFS_image > > with some help from the official FAQ to double-check some parameters: > > ? ?http://www.linux-mtd.infradead.org/faq/ubifs.html I forgot to say I removed the fsck part from the rc.S script since UBIFS does not need it: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/ubifs.txt;h=12fedb7834c65b27d9eda747e1d38b13ac49777b C?dric. From m-lists at biscuit.org.uk Fri Jul 16 13:40:22 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Fri, 16 Jul 2010 14:40:22 +0100 (BST) Subject: [ARMedslack] Linux 2.6.35 problems In-Reply-To: References: Message-ID: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d0679c730395d0bde9a46939e7ba255b4ba7dd7c > > It was inserted in between v2.6.33-rc6 and v2.6.35-rc2 OK, thanks for letting me know: that helps track it down. I've found a patch which looks as if it may help. If not, I'll go back to the config file and check what I have added. From linuxxr at yahoo.com Fri Jul 16 15:00:08 2010 From: linuxxr at yahoo.com (Brian Kelley) Date: Fri, 16 Jul 2010 08:00:08 -0700 (PDT) Subject: [ARMedslack] UBI support is [partially] broken in Slackware/ARM 13.1 on SheevaPlug In-Reply-To: Message-ID: <465253.35842.qm@web52402.mail.re2.yahoo.com> Very nice?? Thank you!! --- On Fri, 7/16/10, C?dric VINCENT wrote: From: C?dric VINCENT Subject: Re: [ARMedslack] UBI support is [partially] broken in Slackware/ARM 13.1 on SheevaPlug To: "Slackware ARM port" Date: Friday, July 16, 2010, 5:44 AM 2010/7/15 C?dric VINCENT : > On Wed, Jul 14, 2010 at 2:44 PM, Stuart Winter wrote: >> However, instructions about making a jffs2 image from the mini rootfs >> image are welcomed, if applicable. > > I don't know about JFFS2, but it is quite easy with UBIFS. Actually I > just followed instructions from this wiki: > > ? ?http://www.plugcomputer.org/plugwiki/index.php/Enabling_UBIFS#Making_your_UBIFS_image > > with some help from the official FAQ to double-check some parameters: > > ? ?http://www.linux-mtd.infradead.org/faq/ubifs.html I forgot to say I removed the fsck part from the rc.S script since UBIFS does not need it: ? ? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/ubifs.txt;h=12fedb7834c65b27d9eda747e1d38b13ac49777b C?dric. _______________________________________________ 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 Sat Jul 17 11:26:02 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sat, 17 Jul 2010 12:26:02 +0100 (BST) Subject: [ARMedslack] Linux 2.6.35 problems In-Reply-To: References: Message-ID: > I've found a patch which looks as if it may help. If not, I'll go back to > the config file and check what I have added. That didn't work. http://connie.slackware.com/~mozes/test/config-kirkwood-linux-2.6 that's the config I'm using, if anyone wants to try and build an rc5. I've added in the openrd ultimate patch to my build, but the same problem exists with a vanilla source as with patched. From cedric.vincent at gmail.com Sat Jul 17 15:27:38 2010 From: cedric.vincent at gmail.com (=?UTF-8?Q?C=C3=A9dric_VINCENT?=) Date: Sat, 17 Jul 2010 17:27:38 +0200 Subject: [ARMedslack] Linux 2.6.35 problems In-Reply-To: References: Message-ID: On Sat, Jul 17, 2010 at 1:26 PM, Stuart Winter wrote: > >> I've found a patch which looks as if it may help. ?If not, I'll go back to >> the config file and check what I have added. > > That didn't work. Very strange... I'm rebuilding two instances of the v2.6.35-rc5 with your config: the first one is vanilla and the second one is patched to revert the commit I talked about previously. I can already see the first instance has the [in]famous R_ARM_REL32 relocation in its module objects, unlike the second one: cedric at bare# readelf -r linux-2.6.35-rc5/kernel/configs.o | grep R_ARM_REL32 | wc -l 3 cedric at bare# readelf -r patched/linux-2.6.35-rc5/kernel/configs.o | grep R_ARM_REL32 | wc -l 0 The patch was generated then applied like this: cd linux-2.6.35-rc5 wget 'http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=patch;h=d0679c730395d0bde9a46939e7ba255b4ba7dd7c' -O d0679c73.patch patch -R -p1 < d0679c73.patch I keep you informed about my tests. C?dric. From m-lists at biscuit.org.uk Sat Jul 17 18:35:03 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sat, 17 Jul 2010 19:35:03 +0100 (BST) Subject: [ARMedslack] Linux 2.6.35 problems In-Reply-To: References: Message-ID: > cd linux-2.6.35-rc5 > wget 'http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=patch;h=d0679c730395d0bde9a46939e7ba255b4ba7dd7c' > -O d0679c73.patch > patch -R -p1 < d0679c73.patch Thanks. I've set off my build again with the patch and I'll try and test it tomorrow. From cedric.vincent at gmail.com Sun Jul 18 09:23:31 2010 From: cedric.vincent at gmail.com (=?UTF-8?Q?C=C3=A9dric_VINCENT?=) Date: Sun, 18 Jul 2010 11:23:31 +0200 Subject: [ARMedslack] UBI support is [partially] broken in Slackware/ARM 13.1 on SheevaPlug In-Reply-To: References: <887943.64540.qm@web52406.mail.re2.yahoo.com> Message-ID: 2010/7/15 C?dric VINCENT : > I don't know about JFFS2, but it is quite easy with UBIFS. Actually I > just followed instructions from this wiki: > > ? ?http://www.plugcomputer.org/plugwiki/index.php/Enabling_UBIFS#Making_your_UBIFS_image Also, you may want to write your uImage into the NAND: nandwrite -p /dev/mtd1 uImage And then boot it through U-Boot: bootcmd=setenv bootargs console=ttyS0,115200 ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs; nand read 0x800000 0x100000 0x330000; bootm 0x800000 From m-lists at biscuit.org.uk Sun Jul 18 09:50:50 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sun, 18 Jul 2010 10:50:50 +0100 (BST) Subject: [ARMedslack] Linux 2.6.35 problems In-Reply-To: References: Message-ID: > > I've set off my build again with the patch and I'll try and test it > tomorrow. Great - it works! Thanks C?dric. From john.oyler at smartfield.com Mon Jul 19 17:06:26 2010 From: john.oyler at smartfield.com (John Oyler) Date: Mon, 19 Jul 2010 12:06:26 -0500 Subject: [ARMedslack] Slackware 13.1 and forward is EABI... Message-ID: This should make it incompatible with the Technologic Systems TS-7500 which is a Cavium, but binaries seem to run without barfing. Am I just getting luck and choosing those that don't have thumb machine instructions, at least in the path that the code takes when I run them? And supposing I can't go with 13.1 (at least without rebuilding it from scratch), what's the latest I can go with? Was there no 13.0? Thanks, John O. From m-lists at biscuit.org.uk Mon Jul 19 17:40:15 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Mon, 19 Jul 2010 18:40:15 +0100 (BST) Subject: [ARMedslack] Slackware 13.1 and forward is EABI... In-Reply-To: References: Message-ID: > This should make it incompatible with the Technologic Systems TS-7500 > which is a Cavium, but binaries seem to run without barfing. Am I just > getting luck and choosing those that don't have thumb machine > instructions, at least in the path that the code takes when I run them? Why do you think EABI binaries won't run? As I recall when I was reading the ARM reference manual a while ago, only *really* old ARM CPUs don't have the "thumb" feature. This one you mention is an ARM9, according to the details I found in a brief search. root at zaden:~/ac/source/a/u-boot-tools# grep Feat /proc/cpuinfo Features : swp half thumb fastmult edsp Does your cpuinfo show "thumb" as a feature? > And supposing I can't go with 13.1 (at least without rebuilding it from > scratch), what's the latest I can go with? Was there no 13.0? 12.2 is the last good old ABI release but it'll be unsupported by the end of this month. There was no 13.0 release because work on the EABI port started at the time 13.0 was released. -- Stuart Winter Slackware ARM: www.armedslack.org From john.oyler at smartfield.com Mon Jul 19 19:27:39 2010 From: john.oyler at smartfield.com (John Oyler) Date: Mon, 19 Jul 2010 14:27:39 -0500 Subject: [ARMedslack] Slackware 13.1 and forward is EABI... In-Reply-To: References: Message-ID: I'm speaking with an engineer from that company. According to him: > The only thing is you need to make sure they are OABI and not EABI as the Cavium CPU does not support thumb instructions and therefore it does not support EABI. I don't know whether this is correct or not. Certainly I ran several binaries from slack 13.1, and they seemed ok, but not knowing much about the instruction set or even how gcc is set up, how can I say when it would bother to use those? On Intel, just because the CPU didn't have SSE didn't mean you couldn't run some binaries compiled with that flag, since those instructions weren't always selected by the compiler. I'd like to have Slackware on this thing, rather than debian (ugh), and I'm probably willing to compile my own 13.1 if it comes down to that... but I'd also like to steal the compiler out of 12.2 or whatever to bootstrap back up to it. John O. PS The wikipedia page doesn't make it clear whether a Cavium has thumb instructions, but certainly all the other ARM9 families look like they include it. Bleh. On Jul 19, 2010, at 12:40 PM, Stuart Winter wrote: > >> This should make it incompatible with the Technologic Systems TS-7500 >> which is a Cavium, but binaries seem to run without barfing. Am I just >> getting luck and choosing those that don't have thumb machine >> instructions, at least in the path that the code takes when I run them? > > Why do you think EABI binaries won't run? > As I recall when I was reading the ARM reference manual a while ago, only > *really* old ARM CPUs don't have the "thumb" feature. > This one you mention is an ARM9, according to the details I found > in a brief search. > > root at zaden:~/ac/source/a/u-boot-tools# grep Feat /proc/cpuinfo > Features : swp half thumb fastmult edsp > > Does your cpuinfo show "thumb" as a feature? > >> And supposing I can't go with 13.1 (at least without rebuilding it from >> scratch), what's the latest I can go with? Was there no 13.0? > > 12.2 is the last good old ABI release but it'll be unsupported by the > end of this month. > There was no 13.0 release because work on the EABI port started at the > time 13.0 was released. > > -- > Stuart Winter > Slackware ARM: www.armedslack.org > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack From m-lists at biscuit.org.uk Tue Jul 20 09:03:21 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Tue, 20 Jul 2010 10:03:21 +0100 (BST) Subject: [ARMedslack] Slackware 13.1 and forward is EABI... In-Reply-To: References: Message-ID: > > The only thing is you need to make sure they are OABI and not EABI as > > the Cavium CPU does not support thumb instructions and therefore it > > does not support EABI. Well - if that's what he says, I'd go with that. However, my personal opinion is that this is not a future-proof board: Old ABI is dead. Debian don't support old ABI anymore and I don't think anyone else does so you'll end up finding stuff that either won't build anymore, or does but doesn't work since the number of people testing it is minimal - an example is "Seamonkey" which is why I haven't released an updated version for 12.2. > I don't know whether this is correct or not. Certainly I ran several > binaries from slack 13.1, and they seemed ok, but not knowing much about > the instruction set or even how gcc is set up, how can I say when it > would bother to use those? I am not a toolchain or architecture wizard, so I might be wrong here; but I think it's not just compiling it for armv4t that matters (compared with -march=armv4 which is what AS 12.2 used). GCC specs from as 12.2 box: root at stokely-as-12-2:~# gcc -dumpspecs | grep abi %{mbig-endian:-EB} %{mlittle-endian:-EL} %{mcpu=*:-mcpu=%*} %{march=*:-march=%*} %{mapcs-*:-mapcs-%*} %(subtarget_asm_float_spec) %{mthumb-interwork:-mthumb-interwork} %{msoft-float:-mfloat-abi=soft} %{mhard-float:-mfloat-abi=hard} %{mfloat-abi=*} %{mfpu=*} %(subtarget_extra_asm_spec) %{msoft-float:-lfloat} %{mfloat-abi=soft*:-lfloat} %{static|static-libgcc:-lgcc -lgcc_eh}%{!static:%{!static-libgcc:%{!shared-libgcc:-lgcc --as-needed -lgcc_s --no-as-needed}%{shared-libgcc:-lgcc_s%{!shared: -lgcc}}}} root at stokely-as-12-2:~# On a -current box (EABI) root at zaden:~# gcc -dumpspecs | grep abi %{mbig-endian:-EB} %{mlittle-endian:-EL} %{mcpu=*:-mcpu=%*} %{march=*:-march=%*} %{mapcs-*:-mapcs-%*} %(subtarget_asm_float_spec) %{mthumb-interwork:-mthumb-interwork} %{msoft-float:-mfloat-abi=soft} %{mhard-float:-mfloat-abi=hard} %{mfloat-abi=*} %{mfpu=*} %(subtarget_extra_asm_spec) %{!-mimplicit-it=*:-mimplicit-it=thumb} %{!static:--eh-frame-hdr} %{h*} %{version:-v} %{b} %{static:-Bstatic} %{shared:-shared} %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker:-dynamic-linker %{muclibc:%{mglibc:%e-mglibc and -muclibc used together}/lib/ld-uClibc.so.0;:/lib/ld-linux.so.3}} -X %{mbig-endian:-EB} %{mlittle-endian:-EL} -m armelf_linux_eabi %{mabi=apcs-gnu|mabi=atpcs:-meabi=gnu;:-meabi=5} %{mcpu=arm8|mcpu=arm810|mcpu=strongarm*|march=armv4:--fix-v4bx} root at zaden:~# If you read this thread here: http://bioacoustics.cse.unsw.edu.au/archives/html/ts-7000/2009-09/msg00052.html and this post in particular: http://bioacoustics.cse.unsw.edu.au/archives/html/ts-7000/2009-09/msg00062.html "One option, I think, is to do a linker fixup, changing all 'bx Rm' into 'mov pc,Rm'. This is in binutils since v2.15, using the '--fix-v4bx' option to the linker (and assembler). But you would really have to rebuild *everything* from scratch, since debian did choose ARMv4t as their minimum processor. " which you can see in gcc's specs for EABI, that this is present. This *may* be why the binaries from -current are working on that CPU. If Jim is reading, he can probably tell for sure since he's our resident ARM assembler expert :-) > I'd like to have Slackware on this thing, rather than debian (ugh), and > I'm probably willing to compile my own 13.1 if it comes down to that... > but I'd also like to steal the compiler out of 12.2 or whatever to > bootstrap back up to it. It's quite an task, building the entire thing, or even if you're only building what you need - esp if you're building natively on a 250MHz ARM machine. I have my cross toolchain which you can find here: ftp://ftp.armedslack.org/armedslack/armedslack-devtools/x-toolchain/ which might help if you'd setup distcc. This is what I use to build armedslack. From john.oyler at smartfield.com Tue Jul 20 17:01:08 2010 From: john.oyler at smartfield.com (John Oyler) Date: Tue, 20 Jul 2010 12:01:08 -0500 Subject: [ARMedslack] Slackware 13.1 and forward is EABI... In-Reply-To: References: Message-ID: On Jul 20, 2010, at 4:03 AM, Stuart Winter wrote: > >>> The only thing is you need to make sure they are OABI and not EABI as >>> the Cavium CPU does not support thumb instructions and therefore it >>> does not support EABI. > > Well - if that's what he says, I'd go with that. > > However, my personal opinion is that this is not a future-proof board: > Old ABI is dead. They claim they'll never EOL the board, and they do industrial systems where that is often a requirement. But you raise a valid point. Thanks for all the advice on building, I may need that. John O. From m-lists at biscuit.org.uk Tue Jul 20 20:03:08 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Tue, 20 Jul 2010 21:03:08 +0100 (BST) Subject: [ARMedslack] Slackware 13.1 and forward is EABI... In-Reply-To: References: Message-ID: > They claim they'll never EOL the board, and they do industrial systems > where that is often a requirement. But you raise a valid point. Yeah, *they* may not but if support for old ABI is abandoned, it means you're stuck in time. There are plenty of other boards which are worth looking at. From jawkins at armedslack.org Tue Jul 20 22:45:49 2010 From: jawkins at armedslack.org (Jim Hawkins) Date: Tue, 20 Jul 2010 23:45:49 +0100 (BST) Subject: [ARMedslack] Slackware 13.1 and forward is EABI... In-Reply-To: References: Message-ID: On Tue, 20 Jul 2010, Stuart Winter wrote: > I am not a toolchain or architecture wizard, so I might be wrong here; > but I think it's not just compiling it for armv4t that matters (compared > with -march=armv4 which is what AS 12.2 used). I have to admit to having no experience of Thumb, but I would imagine you'd have to explicitly tell the compiler to target Thumb instead of normal 32-bit ARM instructions by specifying -mthumb or similar to gcc. Assuming AS isn't compiled in such a way, the only problem would be EABI's use of the "bx" instruction to return from function calls. > %{mcpu=arm8|mcpu=arm810|mcpu=strongarm*|march=armv4:--fix-v4bx} > [...snip...] > which you can see in gcc's specs for EABI, that this is present. > This *may* be why the binaries from -current are working on that CPU. The specs show that --fix-v4bx is only passed to the assembler for the ARMv4 ISA and specific v4 CPUs. > If Jim is reading, Hello :) > he can probably tell for sure since he's our resident ARM assembler > expert :-) Ok, so looking at an assembler dump of a binary on your -current box, you can clearly see it's riddled with "bx lr" instructions: root at zaden:~# objdump -d /bin/bash | grep bx | head 1df70: e12fff1e bx lr 1e8f0: e12fff1e bx lr 1e910: e12fff1e bx lr 1e938: 112fff13 bxne r3 1e940: e12fff1e bx lr 1e964: e12fff1e bx lr 1eb04: e12fff1e bx lr 1eb3c: e12fff1e bx lr 1eb6c: e12fff1e bx lr 1eb90: e12fff1e bx lr These are also not preceeded by any special instruction sequences to detect returning to non-Thumb mode and instead issuing the ARMv4 compatible "mov pc, lr". Obviously that leaves the question of how this is working for John if his platform supposedly doesn't support Thumb. I would guess that either: a) The CPU doesn't support Thumb, but partially implements the "bx" instruction insofar as it allows branching to non-Thumb destination addresses for the purposes of working with the EABI in non-Thumb mode. b) The kernel is emulating the "bx" instruction via an Undefined Instruction trap. I couldn't see any evidence of this from a quick look through the vanilla kernel source tree, but perhaps he's using a patched vendor-supplied kernel. If this is the case then it will probably cause most code to run slower than if it was compiled for the old ABI. I guess the kernel could also be dynamically patching running code so that it only suffers a performance hit the first time the instruction is executed, but that's not a perfect solution. c) He's actually running AS 12.2 binaries ;) Cheers, Jim From john.oyler at smartfield.com Wed Jul 21 00:36:19 2010 From: john.oyler at smartfield.com (John Oyler) Date: Tue, 20 Jul 2010 19:36:19 -0500 Subject: [ARMedslack] Slackware 13.1 and forward is EABI... In-Reply-To: References: Message-ID: On Jul 20, 2010, at 5:45 PM, Jim Hawkins wrote: > > c) He's actually running AS 12.2 binaries ;) > I don't think this is the case. Not in front of the machine right now, but I definitely downloaded the 13.1 On the other hand, the same source that told me this was an OABI machine also told me... well, I'll need a bit of background. I (out of habit) create two partitions, a small one at the beginning of the device, and a large second partition that has the root filesystem. After doing so with the full AS 13.1 install on that second partition (on SD card, you have some idea how long it can take to copy that), he tells me that their boot setup (not using U-boot or anything standard) needs two DA partitions, the first houses the kernel, the second an initrd image. Ugh. So, I sort of know the answer already, but I ask him anyway "Is there any reason why I can't delete my first partition, and create two partitions in its place with these things?". His answer? He didn't think that was possible. I even went into fdisk advanced mode, and fixed the numbering. (And the fstab, but that goes without saying, right?). Anyway, I'll go ahead and look up the cpu number on the ic package tomorrow, I didn't today out of laziness, the rtc battery obstructs it, and I'll have to pop that off. I'm really hoping this thing does do EABI after all. Gonna be a pain if I have to rebuild, and I'm not sure I want to go with 12.2 anyway, there are a few packages I need newer versions of. Thanks Jim and Stuart, I'm sure some of the stuff I ask sounds pretty dumb, and I appreciate the help. Somehow I've got to turn this into a product ready to ship in 6 months, and I've been stressing alot lately over that. John O. From m-lists at biscuit.org.uk Wed Jul 21 07:11:59 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Wed, 21 Jul 2010 08:11:59 +0100 (BST) Subject: [ARMedslack] Slackware 13.1 and forward is EABI... In-Reply-To: References: Message-ID: > you'd have to explicitly tell the compiler to target Thumb instead of > normal 32-bit ARM instructions by specifying -mthumb or similar to gcc. > Assuming AS isn't compiled in such a way, the only problem would be EABI's > use of the "bx" instruction to return from function calls. In the build scripts this hasn't been set although it may be set in some of the makefiles or configure scripts when they detect the ARM cpu. > b) The kernel is emulating the "bx" instruction via an Undefined > Instruction trap. In the kernel there is this option: CONFIG_OABI_COMPAT: This option preserves the old syscall interface along with the new (ARM EABI) one. It also provides a compatibility layer to intercept syscalls that have structure arguments which layout in memory differs between the legacy ABI and the new ARM EABI (only for non "thumb" binaries). This option adds a tiny overhead to all syscalls and produces a slightly larger kernel. If you know you'll be using only pure EABI user space then you can say N here. If this option is not selected and you attempt to execute a legacy ABI binary then the result will be UNPREDICTABLE (in fact it can be predicted that it won't work at all). If in doubt say Y. I only just removed this from -current's kernel 2.6.35 package (and forgot to put it into the changelog - it can go in the next "rc") but I don't think this is what would help you, if it's in the kernel you're using. John - if you need to get your project done soon, perhaps you can just compile newer versions of particular software in 12.2? If you look at the "arm/build" scripts in armedslack's source tree, it'll give you an idea of what the dependencies are. You could also get a SheevaPlug, put 12.2 on it and compile on there since it has a 1GHz CPU and 512MB RAM. From john.oyler at smartfield.com Wed Jul 21 15:33:02 2010 From: john.oyler at smartfield.com (John Oyler) Date: Wed, 21 Jul 2010 10:33:02 -0500 Subject: [ARMedslack] What's the difference between USB<->serial devices on Arm Slack and Intel Slack? Message-ID: Granted, I don't have matching release numbers exactly, I'm using 13.0 for Intel, and 13.1 for Arm. I've been using several different USB cellular modems, internally they're several different serial/usb chipsets. As an exampl, I'll go with the Multitech MTCBA-G-U-F4. This uses the TI TUSB3410 chipset. On an intel machine, I plug it in, and I get my /dev/ttyUSB0. Absolutely no twiddling needed. If I plug it into an Arm board (the Beagleboard), it complains about missing firmware. I went ahead and copied several likely looking files out of /lib/firmware on the Intel machine over to the Arm, and things are working a bit better (I suspect it's fixed at this point), but where are those files even populated from? There doesn't seem to be anything in the L series that's random-firmware-crap.txz, and I'm not sure why it'd be present on Intel but not Arm (if anything, the Arm should have it, since I did a full install but on Intel I was picky... had to fit it into 2 gigs). If I'm just being an idiot and screwed up the install, sorry about that. But I'd appreciate being told so. Thanks, John O. From m-lists at biscuit.org.uk Wed Jul 21 15:52:13 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Wed, 21 Jul 2010 16:52:13 +0100 (BST) Subject: [ARMedslack] What's the difference between USB<->serial devices on Arm Slack and Intel Slack? In-Reply-To: References: Message-ID: > complains about missing firmware. I went ahead and copied several likely > looking files out of /lib/firmware on the Intel machine over to the Arm, On the intel, grep for the file names you copied across and find out which package they came from. Slackware intel has an a/kernel-firmware package which populates some of /lib/firmware; ARM has this /lib/firmware stuff in the kernel-modules package because I only noticed a few months ago that there was a separate kernel-firmware package in Slackware (since ARM doesn't follow Slackware's kernel at all). This actually means that we have duplicated /lib/firmware files in both the "versatile" and "kirkwood" kernel_modules packages (not that it really matters - but I might address this at some point). > and things are working a bit better (I suspect it's fixed at this > point), but where are those files even populated from? There doesn't > seem to be anything in the L series that's random-firmware-crap.txz, root at zaden:~/slackware64-current/slackware64# find . -iname '*-fw-*.t?z' | wc -l 13 It might be in one of these packages, but as I said - the best place is to look for the specific files you copied. I'm not too familiar with why the kernel firmware stuff gets built but I suspect it's just because support for a specific driver is compiled in, or is compiled as a module, so the corresponding fw is built and packaged/installed when "make modules_install" is run. So I'd guess that it's because armedslack's kernel config doesn't have support for the same drivers as x86. Historically I've only included specifically what could be physically present or connected to a board, which worked well; but with USB and now some ARM devices having a PCI-x socket, I tend to compile as modules most of the new stuff I'm presented with from "make oldconfig". If there's anything particular anyone wants adding as a kernel module, I can add it in for -current going forwards. From jawkins at armedslack.org Wed Jul 21 17:03:25 2010 From: jawkins at armedslack.org (Jim Hawkins) Date: Wed, 21 Jul 2010 18:03:25 +0100 (BST) Subject: [ARMedslack] What's the difference between USB<->serial devices on Arm Slack and Intel Slack? In-Reply-To: References: Message-ID: On Wed, 21 Jul 2010, Stuart Winter wrote: > I'm not too familiar with why the kernel firmware stuff gets built but I > suspect it's just because support for a specific driver is compiled in, > or is compiled as a module, so the corresponding fw is built and > packaged/installed when "make modules_install" is run. Some of the firmwares needed by the drivers are not created as part of the kernel build. They are binary blobs (often extracted from the Windows drivers) which get uploaded to the hardware by the Linux kernel drivers to make the devices operate as intended. As such, the legality of distributing some of them is a bit dubious. You should be able to install and use the Intel kernel-firmware package on an ARMedslack system as it shouldn't contain any code for the host system (which is why it's marked as a noarch package). Cheers, Jim From unixjohn1969 at gmail.com Wed Jul 21 18:18:48 2010 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Wed, 21 Jul 2010 14:18:48 -0400 Subject: [ARMedslack] What's the difference between USB<->serial devices on Arm Slack and Intel Slack? In-Reply-To: References: Message-ID: <4C473A08.2050802@gmail.com> Jim Hawkins wrote: > On Wed, 21 Jul 2010, Stuart Winter wrote: > >> I'm not too familiar with why the kernel firmware stuff gets built but I >> suspect it's just because support for a specific driver is compiled in, >> or is compiled as a module, so the corresponding fw is built and >> packaged/installed when "make modules_install" is run. > > Some of the firmwares needed by the drivers are not created as part of the > kernel build. They are binary blobs (often extracted from the Windows > drivers) which get uploaded to the hardware by the Linux kernel drivers to > make the devices operate as intended. As such, the legality of > distributing some of them is a bit dubious. Is this why for the Globalscale GuruPlug's wifi drivers, I had to copy the debian /lib/firmware/mrvl files root at guruslack:/lib/firmware/mrvl# l total 512 -rwxr-xr-x 1 root root 2616 2010-05-27 23:54 helper_sd.bin* -rw-r--r-- 1 root root 278640 2010-05-27 23:54 sd8688.bin -rwxr-xr-x 1 root root 222572 2010-05-27 23:54 sd8688_ap.bin* -rw-r--r-- 1 root root 2616 2010-05-27 23:54 sd8688_helper.bin in order to get the wifi access point functionality working? I couldnt find these in the standard kernel and it kept complaining every time I loaded the uap8xxx driver that it couldnt find the firmware. Here is what a good boot looks like after I copied the firmware [ 59.381185] uap_probe: vendor=0x02DF device=0x9104 class=0 function=1 [ 59.401417] uap_sdio mmc0:0001:1: firmware: requesting mrvl/helper_sd.bin [ 59.424156] uap_sdio mmc0:0001:1: firmware: requesting mrvl/sd8688_ap.bin [ 59.718283] UAP FW is active one set of binaries is for access point, one set is for client (I believe). My /etc/rc.uap: #!/bin/sh # rc.uap: start/stop/restart Marvell access point subsystem. # # Load the kernel module and configure the access point # for the Marvell wireless adapter in the Guru Plug PC # using the binary (uaputl) copied from the Debian distribution # that came with the Guru Plug PC since no source could be found # as well as the firmware files that were not found with the # standard kernels. # # Make sure to set up your dhcpd. # # This script sets up the wireless network as a separate network and # assumes all your wireless devices will be NAT'ed out to your # wired network. # # John O'Donnell # # The IP address of the access point UAPIP=192.168.100.1 SSID=Pinguinista PROTOCOL=32 WPA_PASSPHRASE=SomeUberSuperSecretPassword CIPHER="8 8" NATDEV=eth2 UAPDEV=uap0 CHANNEL=6 uap_start() { if [ -x /usr/bin/uaputl ]; then modprobe uap8xxx ifconfig ${UAPDEV} ${UAPIP} up uaputl sys_cfg_radio_ctl 0 # Radio on uaputl sys_cfg_channel ${CHANNEL} uaputl sys_cfg_ssid ${SSID} uaputl sys_cfg_protocol ${PROTOCOL} uaputl sys_cfg_wpa_passphrase ${WPA_PASSPHRASE} uaputl sys_cfg_cipher ${CIPHER} uaputl bss_start # Set firewall to NAT these clients iptables -t nat -A POSTROUTING -o ${NATDEV} -j MASQUERADE # Set leds echo 1 > `eval ls /sys/class/leds/guruplug\:green\:health/brightness` echo 1 > `eval ls /sys/class/leds/guruplug\:green\:wmode/brightness` echo 0 > `eval ls /sys/class/leds/guruplug\:red\:health/brightness` echo 0 > `eval ls /sys/class/leds/guruplug\:red\:wmode/brightness` # Startup DHCPD /etc/rc.d/rc.dhcpd start fi } uap_stop() { if [ -x /usr/bin/uaputl ]; then /etc/rc.d/rc.dhcpd stop ifconfig ${UAPDEV} ${UAPIP} down uaputl bss_stop uaputl sys_cfg_radio_ctl 1 # Radio off iptables -t nat -D POSTROUTING -o ${NATDEV} -j MASQUERADE modprobe -r uap8xxx # Set leds echo 0 > `eval ls /sys/class/leds/guruplug\:green\:health/brightness` echo 0 > `eval ls /sys/class/leds/guruplug\:green\:wmode/brightness` echo 0 > `eval ls /sys/class/leds/guruplug\:red\:health/brightness` echo 0 > `eval ls /sys/class/leds/guruplug\:red\:wmode/brightness` fi } uap_status() { echo "--------------------------------------------------------------------------" uaputl sys_info # display system info uaputl sta_list # display list of clients echo "--------------------------------------------------------------------------" exit 0 } uap_restart() { uap_stop uap_start } case "$1" in 'start') uap_start ;; 'stop') uap_stop ;; 'status') uap_status ;; 'restart') uap_restart ;; *) echo "usage $0 start|stop|restart" esac -- === Never ask a geek why, just nod your head and slowly back away.=== +================================+==================================+ | John O'Donnell | | | (Sr. Systems Engineer, | http://juanisan.homeip.net | | Net Admin, Programmer, etc.) | E-Mail: unixjohn1969 at gmail.com | +================================+==================================+ No man is useless who has a friend, and if we are loved we are indispensable. -- Robert Louis Stevenson From john.oyler at smartfield.com Wed Jul 21 18:38:44 2010 From: john.oyler at smartfield.com (John Oyler) Date: Wed, 21 Jul 2010 13:38:44 -0500 Subject: [ARMedslack] What's the difference between USB<->serial devices on Arm Slack and Intel Slack? In-Reply-To: <4C473A08.2050802@gmail.com> References: <4C473A08.2050802@gmail.com> Message-ID: <377896F2-4670-4C6E-B20D-1C6BFE6929C1@smartfield.com> John O'Donnel, This is the sort of thing you'd see. Did you understand the fix that they're speaking of? Basically we just install the Intel Slackware firmware package, and this should all go away (or, at least work as well as the Intel Slack does). I haven't tried it myself, and probably won't get to for a few more hours, but it does sound like an obvious fix now that they've explained, and should be safe even if it doesn't (just use removepkg). John Oyler From atelszewski at gmail.com Wed Jul 21 18:54:47 2010 From: atelszewski at gmail.com (Andrzej Telszewski) Date: Wed, 21 Jul 2010 20:54:47 +0200 Subject: [ARMedslack] What's the difference between USB<->serial devices on Arm Slack and Intel Slack? In-Reply-To: <377896F2-4670-4C6E-B20D-1C6BFE6929C1@smartfield.com> References: <4C473A08.2050802@gmail.com> <377896F2-4670-4C6E-B20D-1C6BFE6929C1@smartfield.com> Message-ID: <4C474277.8090000@gmail.com> On 07/21/2010 08:38 PM, John Oyler wrote: > John O'Donnel, > > This is the sort of thing you'd see. Did you understand the fix that they're speaking of? Basically we just install the Intel Slackware firmware package, and this should all go away (or, at least work as well as the Intel Slack does). > > I haven't tried it myself, and probably won't get to for a few more hours, but it does sound like an obvious fix now that they've explained, and should be safe even if it doesn't (just use removepkg). > > John Oyler > > > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > Hi all! Look at the firmware as it was the operating system of the device. As your PC is useless without an OS, so are some devices without firmware. These devices are equipped with some kind of processor (it can be even an ARM) and depending of the firmware they can be once PPPoE modem, and the next time the other firmware is uploaded, they can be PPPoA modem. Simply put, firmware is code, that once uploaded, is executed by device or have some data that the device needs. One important thing is that, with firmware based devices it is possible to easily update the device to new revision by just updating the firmware. It wouldn't be possible if the device was based on some dedicated hardware. -- Pozdrawiam, Best regards, Andrzej Telszewski From unixjohn1969 at gmail.com Wed Jul 21 21:03:56 2010 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Wed, 21 Jul 2010 17:03:56 -0400 Subject: [ARMedslack] What's the difference between USB<->serial devices on Arm Slack and Intel Slack? In-Reply-To: <377896F2-4670-4C6E-B20D-1C6BFE6929C1@smartfield.com> References: <4C473A08.2050802@gmail.com> <377896F2-4670-4C6E-B20D-1C6BFE6929C1@smartfield.com> Message-ID: <4C4760BC.4060902@gmail.com> John Oyler wrote: > John O'Donnel, > > This is the sort of thing you'd see. Did you understand the fix that they're speaking of? Basically we just install the Intel Slackware firmware package, and this should all go away (or, at least work as well as the Intel Slack does). there is no Marvell files (mrvl) in the firmware package. There are no mrvl files in the kernel source tree either. I dont know where debian / globalscale got them. -- === 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 atelszewski at gmail.com Wed Jul 21 21:11:58 2010 From: atelszewski at gmail.com (Andrzej Telszewski) Date: Wed, 21 Jul 2010 23:11:58 +0200 Subject: [ARMedslack] What's the difference between USB<->serial devices on Arm Slack and Intel Slack? In-Reply-To: <4C4760BC.4060902@gmail.com> References: <4C473A08.2050802@gmail.com> <377896F2-4670-4C6E-B20D-1C6BFE6929C1@smartfield.com> <4C4760BC.4060902@gmail.com> Message-ID: <4C47629E.1090208@gmail.com> > there is no Marvell files (mrvl) in the firmware package. There are no > mrvl files in the kernel source tree either. I dont know where debian / > globalscale got them. Sometimes firmware can be found on the manufacturer website or some other site. For example, I remember the day (some years ago) when I needed firmware for Thomson SpeedTouch ADSL modem, and it could be found on (as far as I remember) website run by manufacturer. Last year I tested this firmware with armedslack and it worked just fine on my tiny board with AT91RM9200 CPU. -- Pozdrawiam, Best regards, Andrzej Telszewski From unixjohn1969 at gmail.com Wed Jul 21 22:08:13 2010 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Wed, 21 Jul 2010 18:08:13 -0400 Subject: [ARMedslack] What's the difference between USB<->serial devices on Arm Slack and Intel Slack? In-Reply-To: <4C47629E.1090208@gmail.com> References: <4C473A08.2050802@gmail.com> <377896F2-4670-4C6E-B20D-1C6BFE6929C1@smartfield.com> <4C4760BC.4060902@gmail.com> <4C47629E.1090208@gmail.com> Message-ID: <4C476FCD.2030401@gmail.com> Andrzej Telszewski wrote: >> there is no Marvell files (mrvl) in the firmware package. There are no >> mrvl files in the kernel source tree either. I dont know where debian / >> globalscale got them. > Sometimes firmware can be found on the manufacturer website or some > other site. For example, I remember the day (some years ago) when I > needed firmware for Thomson SpeedTouch ADSL modem, and it could be found > on (as far as I remember) website run by manufacturer. Last year I > tested this firmware with armedslack and it worked just fine on my tiny > board with AT91RM9200 CPU. As this was a Globalscale product I scoured their site and posted requests on their plug PC forums for the location. I should have probably looked at Marvell. The management executable (uaputl) looks like it was a port of a windoze package. root at guruslack:~# uaputl uaputl.exe - uAP utility ver 1.12 Usage: uaputl.exe [options] [command parameters] hmmm I wonder what gave that away ;-) -- === 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 m-lists at biscuit.org.uk Thu Jul 22 08:23:11 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Thu, 22 Jul 2010 09:23:11 +0100 (BST) Subject: [ARMedslack] What's the difference between USB<->serial devices on Arm Slack and Intel Slack? In-Reply-To: <4C476FCD.2030401@gmail.com> References: <4C473A08.2050802@gmail.com> <377896F2-4670-4C6E-B20D-1C6BFE6929C1@smartfield.com> <4C4760BC.4060902@gmail.com> <4C47629E.1090208@gmail.com> <4C476FCD.2030401@gmail.com> Message-ID: > As this was a Globalscale product I scoured their site and posted requests on > their plug PC forums for the location. I should have probably looked at > Marvell. The management executable (uaputl) looks like it was a port of a > windoze package. > > root at guruslack:~# uaputl > uaputl.exe - uAP utility ver 1.12 > Usage: > uaputl.exe [options] [command parameters] > Do you know the source/master URL for these? I looked at packages.debian.org for the names of some of those firmware files but didn't find a package to which they belong -- I suspect that these files are in the debian shipped on the NAND, but not in Debian itself. If I know where to get them from, I can package them as a package in the 'n/' which is where many firmware blobs for various network cards can be found. From tylernt at gmail.com Wed Jul 28 05:13:54 2010 From: tylernt at gmail.com (Tyler T) Date: Tue, 27 Jul 2010 23:13:54 -0600 Subject: [ARMedslack] A few questions on kirkwood initrd Message-ID: I've been enjoying Armedslack on my Sheeva for a while so I've decided to put it on my Seagate Dockstar (a stripped down Sheeva) too. This presents a few challenges that I think I can overcome with a little help: DockStar's u-Boot is crippled, so I use it to chainload a better u-Boot which I have flashed to mtd3. Even the mtd3 u-Boot can't boot an initrd, though, which brings me to my dilemma: I would like to use the u-Boot mkimage utility to meld the Slackware kernel and installer initrd into a single file so my mtd3 u-Boot can boot it from a USB stick. However, I need to alter the installer initrd first (to automatically run dhcpcd and dropbear, as the Dockstar has no serial console). I've tried to extract the initrd with gunzip and cpio; no luck. What format is the Armedslack installer initrd in, and how do I extract it? Once I can do this, I believe I can repackage it with mkinitrd and go from there. Thanks in advance for any tips and info... ___ ?/yler From atelszewski at gmail.com Wed Jul 28 05:56:43 2010 From: atelszewski at gmail.com (Andrzej Telszewski) Date: Wed, 28 Jul 2010 07:56:43 +0200 Subject: [ARMedslack] A few questions on kirkwood initrd In-Reply-To: References: Message-ID: <4C4FC69B.9010204@gmail.com> Hi, > I've tried to extract the initrd with gunzip and cpio; no > luck. What format is the Armedslack installer initrd in, and how do I > extract it? > > Once I can do this, I believe I can repackage it with mkinitrd and go > from there. One time I got this instructions from Stuart on how to extract initrd: cd /tmp mkdir foo cd foo dd if=armedslack-current/isolinux/uinitrd-kirkwood.img bs=64 skip=1 | gzip -dc | cpio -div So initrd is gzipped cpio archive, but you have to skip some data;) By the way, I used the extracted initrd to install Armedslack on my SD/MMC based system and there was no problem (I extracted initrd to the MMC card and booted it as my system has to little RAM to use initrd directly). -- Pozdrawiam, Best regards, Andrzej Telszewski From tylernt at gmail.com Wed Jul 28 06:20:37 2010 From: tylernt at gmail.com (Tyler T) Date: Wed, 28 Jul 2010 00:20:37 -0600 Subject: [ARMedslack] A few questions on kirkwood initrd In-Reply-To: <4C4FC69B.9010204@gmail.com> References: <4C4FC69B.9010204@gmail.com> Message-ID: >> I've tried to extract the initrd with gunzip and cpio; no >> luck. What format is the Armedslack installer initrd in, and how do I >> extract it? > > One time I got this instructions from Stuart on how to extract initrd: > dd if=armedslack-current/isolinux/uinitrd-kirkwood.img ?bs=64 skip=1 | > gzip -dc | cpio -div Ah, that worked, thank you! Unfortunately, the Dockstar won't finish booting the resulting image and without a serial console it's hard to say why... I may have to invest in a TTL-serial adapter and crack the case so I can see what's going on. Thanks again for putting me on the right track. From m-lists at biscuit.org.uk Wed Jul 28 11:52:24 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Wed, 28 Jul 2010 12:52:24 +0100 (BST) Subject: [ARMedslack] A few questions on kirkwood initrd In-Reply-To: References: <4C4FC69B.9010204@gmail.com> Message-ID: > > One time I got this instructions from Stuart on how to extract initrd: > > dd if=armedslack-current/isolinux/uinitrd-kirkwood.img ?bs=64 skip=1 | > > gzip -dc | cpio -div > > Ah, that worked, thank you! The initrd for kirkwood is in "u-boot" format - it was made with u-boot's "mkimage". The script I use to build the kirkwood installer is here: http://stash.armedslack.org/scripts/mk-kirkwood.sh It just unpacks the versatile one, replaces the kernel modules with the kirkwood ones and adds a few more. > Unfortunately, the Dockstar won't finish booting the resulting image > and without a serial console it's hard to say why... I may have to > invest in a TTL-serial adapter and crack the case so I can see what's > going on. It could be because the installer image is too large to fit in RAM, or into the addresses into which you're loading it. -- Stuart Winter Slackware ARM: www.armedslack.org From tylernt at gmail.com Wed Jul 28 17:00:03 2010 From: tylernt at gmail.com (Tyler T) Date: Wed, 28 Jul 2010 11:00:03 -0600 Subject: [ARMedslack] A few questions on kirkwood initrd In-Reply-To: References: <4C4FC69B.9010204@gmail.com> Message-ID: >> Unfortunately, the Dockstar won't finish booting the resulting image > > It could be because the installer image is too large to fit in RAM, or > into the addresses into which you're loading it. I think you're right. We're getting into stuff I don't know much about, but: # mkimage -l uImageInstaller Image Name: Slackware 13.1 Installer Created: Tue Jul 27 22:30:45 2010 Image Type: ARM Linux Multi-File Image (uncompressed) Data Size: 16795836 Bytes = 16402.18 kB = 16.02 MB Load Address: 00008000 Entry Point: 00008000 Contents: Image 0: 2096780 Bytes = 2047.64 kB = 2.00 MB Image 1: 14699044 Bytes = 14354.54 kB = 14.02 MB I think I might see the issue. The Load Address / Entry Point appears to be 32KB (00008000 is hex, I believe). This is probably fine for the typical u-Boot environment, but I'm chainloading a second bootloader so a Load Address of 32KB is probably right on top of my second u-Boot. Will play with it this evening. > By the way, I used the extracted initrd to install Armedslack on my > SD/MMC based system and there was no problem (I extracted initrd to the > MMC card and booted it as my system has to little RAM to use initrd > directly). That's clever. If I can't figure out the Load Address stuff, this should be a good alternative. From atelszewski at gmail.com Wed Jul 28 17:31:50 2010 From: atelszewski at gmail.com (Andrzej Telszewski) Date: Wed, 28 Jul 2010 19:31:50 +0200 Subject: [ARMedslack] A few questions on kirkwood initrd In-Reply-To: References: <4C4FC69B.9010204@gmail.com> Message-ID: <4C506986.7040904@gmail.com> On 07/28/2010 07:00 PM, Tyler T wrote: >> By the way, I used the extracted initrd to install Armedslack on my >> > SD/MMC based system and there was no problem (I extracted initrd to the >> > MMC card and booted it as my system has to little RAM to use initrd >> > directly). > That's clever. If I can't figure out the Load Address stuff, this > should be a good alternative. Hi, This worked out of the box, just after extracting initrd to MMC. As my processor isn't supported by the official Armedslack kernels (I'm working on it:)), I had to compile my own kernel and then transfer it to MMC and let know the U-Boot where the kernel is. As there's actually no initrd, it seems to be important to compile all the drivers needed to boot into kernel binary. In my situation it applied at least to the file system and MMC interface drivers. It seems that using initrd is no option for system with as little as 32MB of RAM, but when installed, Armedslack works OK on such a system (naturally without initrd:)). -- Pozdrawiam, Best regards, Andrzej Telszewski From tylernt at gmail.com Thu Jul 29 05:17:04 2010 From: tylernt at gmail.com (Tyler T) Date: Wed, 28 Jul 2010 23:17:04 -0600 Subject: [ARMedslack] A few questions on kirkwood initrd In-Reply-To: <4C506986.7040904@gmail.com> References: <4C4FC69B.9010204@gmail.com> <4C506986.7040904@gmail.com> Message-ID: Update: the 'mtd3' chained-bootloader that I'm using is from http://www.plugapps.com/index.php5?title=PlugApps:Pogoplug_Setboot so I examined the kernel it ships with using 'mkimage -l' and it's Load Address is the same as Armedslack's, 00008000. This works because upon closer examination, the stock u-Boot loads the second bootloader at 0xc00000, right near the end of the 128MB of RAM, so there's plenty of room for a kernel, initrd, and decompressed ramfs back at the beginning. Unfortunately I still can't get it to boot so there's probably some other minor setting somewhere that needs tweaked. >>> > (I extracted initrd to the >>> > MMC card and booted it as my system has to little RAM to use initrd >>> > directly). >> >> That's clever. If I can't figure out the Load Address stuff, this >> should be a good alternative. >> > As there's actually no > initrd, it seems to be important to compile all the drivers needed to > boot into kernel binary. In my situation it applied at least to the file > system and MMC interface drivers. Since I couldn't get my kernel+initrd combo to boot, I tried this. I compiled a kernel with SCSI, USB, ext2, NIC, and netconsole built-in along with netconsole kernel parameters and put it on the USB stick with the extracted contents of the Armedslack installer initrd. The USB stick activity light flashes for quite a long time, much longer than would be required to just load the kernel, but unfortunately I get nothing on the netconsole so I must have done something else wrong. I don't think it's getting past the second u-Boot because eventually the thing reboots which I don't think would happen after the Armedslack kernel starts executing. I now have a TTL-serial adapter on it's way so I can at least see on the console what's not happy.