From m-lists at biscuit.org.uk Sat May 1 10:34:00 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sat, 1 May 2010 11:34:00 +0100 (BST) Subject: [ARMedslack] slackware on chumby one In-Reply-To: References: Message-ID: > fdisk -l to find out that it is /dev/sdb1 > then fdisk /dev/sdb1 to make a 1gb linux partition sdb1 is a partition on "sdb". So you want to use fdisk /dev/sdb not sdb1. Which instructions are you looking at? > then mkfs.ext3 /dev/sdb1 > mkdir /mnt/sdb1 > mount /dev/sdb1 /mnt/sdb1 > error no such dir > > so i try > mount /dev/sdb1 > > ok bit more info this time. You haven't said what information there is or isn't. You need to find out what "sd" letter ("SCSI disc") your USB reader/microsd has been assigned. You can use dmesg | tail -n15 to do this - you should see some info about a USB device being connected. The scsi letter your machine receives depends on the configuration of your system. Some systems will get /dev/sdb, others may get /dev/sda, for example. > so I edit this file by running my text editor with sudo as root, save > it with the new line for this usb drive, try to mount again. Still > nothing ! > > What am I doing wrong here ? Without you describing your environment, I'll just have to make experienced guesses. 1. Your *host* (Linux PC) device name - (/dev/sdb you think) has no connection with what it'll appear as on the ARM device. If the device *does* happen to be /dev/sdb on ARM & PC, it's a coincidence in your case. If your ARM device has only one storage device, then it's probably /dev/sda so this is what you'd put into the fstab. 2. Whose kernel are you using for this device? I assume you are mixing some 3rd party kernel with the Slackware ARM root fs, because I haven't heard of the "Chumby" before, and haven't selected any support for it in the two kernels shipped. Wherever you got the kernel from ought to include some Linux loader information. This is it? http://www.arm.com/markets/enterprise/chumby-industries-chumby.php Heh it looks funny :-) Anyway you need to provide more information about what you're doing. It's probably pretty simple to get up and running but there's only so much I can guess! From gwolfendale at gmail.com Sat May 1 11:04:38 2010 From: gwolfendale at gmail.com (Graeme Wolfendale) Date: Sat, 1 May 2010 12:04:38 +0100 Subject: [ARMedslack] slackware on chumby one In-Reply-To: References: Message-ID: Hi Stuart Thanks for the super detailed reply I will try to fill in the gaps below: On Sat, May 1, 2010 at 11:34 AM, Stuart Winter wrote: > >> fdisk -l to find out that it is /dev/sdb1 >> then fdisk /dev/sdb1 to make a 1gb linux partition > > sdb1 is a partition on "sdb". > So you want to use fdisk /dev/sdb not sdb1. > > Which instructions are you looking at? > I just googled how to format usb drive in linux >> then mkfs.ext3 /dev/sdb1 > >> mkdir /mnt/sdb1 >> mount /dev/sdb1 /mnt/sdb1 > > > >> error no such dir >> >> so i try >> mount /dev/sdb1 >> >> ok bit more info this time. > > You haven't said what information there is or isn't. > You need to find out what "sd" letter ("SCSI disc") your USB > reader/microsd has been assigned. > You can use dmesg | tail -n15 ?to do this - you should see some info about > a USB device being connected. > > The scsi letter your machine receives depends on the configuration of your > system. ?Some systems will get /dev/sdb, others may get /dev/sda, for > example. > >> so I edit this file by running my text editor with sudo as root, save >> it with the new line for this usb drive, try to mount again. Still >> nothing ! >> >> What am I doing wrong here ? > > Without you describing your environment, I'll just have to make > experienced guesses. > > 1. Your *host* (Linux PC) device name - (/dev/sdb you think) has no > connection with what it'll appear as on the ARM device. > If the device *does* happen to be /dev/sdb on ARM & PC, it's a > coincidence in your case. > > If your ARM device has only one storage device, then it's probably > /dev/sda so this is what you'd put into the fstab. > > 2. Whose kernel are you using for this device? > I assume you are mixing some 3rd party kernel with the Slackware ARM > root fs, because I haven't heard of the "Chumby" before, and haven't selected any > support for it in the two kernels shipped. http://www.armedslack.org/ I selected the mini root filesystem: A mini root filesystem of Slackware ARM ?current? is now available from the FTP site. > > Wherever you got the kernel from ought to include some Linux loader > information. > > This is it? > http://www.arm.com/markets/enterprise/chumby-industries-chumby.php > http://www.chumby.com/pages/compare nearly, it's the chumby one, the newer version. > Heh it looks funny :-) :) yes but it is cheap, has a nice cpu and display so it seemed like a nice platform to experiment with embedded linux. Also as a nice sidenote it is open hardware so there are highly detailed specs down to the individual chip level :D > > Anyway you need to provide more information about what you're doing. > It's probably pretty simple to get up and running but there's only so much > I can guess! > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > From gwolfendale at gmail.com Sat May 1 11:29:54 2010 From: gwolfendale at gmail.com (Graeme Wolfendale) Date: Sat, 1 May 2010 12:29:54 +0100 Subject: [ARMedslack] slackware on chumby one In-Reply-To: References: Message-ID: Hi stuart I am using crunchbang lite 9.04.01 from virtualbox with windows xp as a host system. To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. crunchbang at crunchbang:~$ fdisk -l Disk /dev/sdb: 1018 MB, 1018691584 bytes 32 heads, 61 sectors/track, 1019 cylinders Units = cylinders of 1952 * 512 = 999424 bytes Disk identifier: 0x803cbee2 Device Boot Start End Blocks Id System /dev/sdb1 1 1019 994513+ 83 Linux crunchbang at crunchbang:~$ fdisk /dev/sdb Command (m for help): m Command action a toggle a bootable flag b edit bsd disklabel c toggle the DOS compatibility flag d delete a partition l list known partition types m print this menu n add a new partition o create a new empty DOS partition table p print the partition table q quit without saving changes s create a new empty Sun disklabel t change a partition's system id u change display/entry units v verify the partition table w write table to disk and exit x extra functionality (experts only) Command (m for help): l 0 Empty 1e Hidden W95 FAT1 80 Old Minix bf Solaris 1 FAT12 24 NEC DOS 81 Minix / old Lin c1 DRDOS/sec (FAT- 2 XENIX root 39 Plan 9 82 Linux swap / So c4 DRDOS/sec (FAT- 3 XENIX usr 3c PartitionMagic 83 Linux c6 DRDOS/sec (FAT- 4 FAT16 <32M 40 Venix 80286 84 OS/2 hidden C: c7 Syrinx 5 Extended 41 PPC PReP Boot 85 Linux extended da Non-FS data 6 FAT16 42 SFS 86 NTFS volume set db CP/M / CTOS / . 7 HPFS/NTFS 4d QNX4.x 87 NTFS volume set de Dell Utility 8 AIX 4e QNX4.x 2nd part 88 Linux plaintext df BootIt 9 AIX bootable 4f QNX4.x 3rd part 8e Linux LVM e1 DOS access a OS/2 Boot Manag 50 OnTrack DM 93 Amoeba e3 DOS R/O b W95 FAT32 51 OnTrack DM6 Aux 94 Amoeba BBT e4 SpeedStor c W95 FAT32 (LBA) 52 CP/M 9f BSD/OS eb BeOS fs e W95 FAT16 (LBA) 53 OnTrack DM6 Aux a0 IBM Thinkpad hi ee GPT f W95 Ext'd (LBA) 54 OnTrackDM6 a5 FreeBSD ef EFI (FAT-12/16/ 10 OPUS 55 EZ-Drive a6 OpenBSD f0 Linux/PA-RISC b 11 Hidden FAT12 56 Golden Bow a7 NeXTSTEP f1 SpeedStor 12 Compaq diagnost 5c Priam Edisk a8 Darwin UFS f4 SpeedStor 14 Hidden FAT16 <3 61 SpeedStor a9 NetBSD f2 DOS secondary 16 Hidden FAT16 63 GNU HURD or Sys ab Darwin boot fb VMware VMFS 17 Hidden HPFS/NTF 64 Novell Netware b7 BSDI fs fc VMware VMKCORE 18 AST SmartSleep 65 Novell Netware b8 BSDI swap fd Linux RAID auto 1b Hidden W95 FAT3 70 DiskSecure Mult bb Boot Wizard hid fe LANstep 1c Hidden W95 FAT3 75 PC/IX be Solaris boot ff BBT Command (m for help): k k: unknown command Command action a toggle a bootable flag b edit bsd disklabel c toggle the DOS compatibility flag d delete a partition l list known partition types m print this menu n add a new partition o create a new empty DOS partition table p print the partition table q quit without saving changes s create a new empty Sun disklabel t change a partition's system id u change display/entry units v verify the partition table w write table to disk and exit x extra functionality (experts only) Command (m for help): d Selected partition 1 Command (m for help): p Disk /dev/sdb: 1018 MB, 1018691584 bytes 32 heads, 61 sectors/track, 1019 cylinders Units = cylinders of 1952 * 512 = 999424 bytes Disk identifier: 0x803cbee2 Device Boot Start End Blocks Id System Command (m for help): m Command action a toggle a bootable flag b edit bsd disklabel c toggle the DOS compatibility flag d delete a partition l list known partition types m print this menu n add a new partition o create a new empty DOS partition table p print the partition table q quit without saving changes s create a new empty Sun disklabel t change a partition's system id u change display/entry units v verify the partition table w write table to disk and exit x extra functionality (experts only) Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 1 First cylinder (1-1019, default 1): 1 Last cylinder, +cylinders or +size{K,M,G} (1-1019, default 1019): Using default value 1019 Command (m for help): m Command action a toggle a bootable flag b edit bsd disklabel c toggle the DOS compatibility flag d delete a partition l list known partition types m print this menu n add a new partition o create a new empty DOS partition table p print the partition table q quit without saving changes s create a new empty Sun disklabel t change a partition's system id u change display/entry units v verify the partition table w write table to disk and exit x extra functionality (experts only) Command (m for help): a Partition number (1-4): 1 Command (m for help): p Disk /dev/sdb: 1018 MB, 1018691584 bytes 32 heads, 61 sectors/track, 1019 cylinders Units = cylinders of 1952 * 512 = 999424 bytes Disk identifier: 0x803cbee2 Device Boot Start End Blocks Id System /dev/sdb1 * 1 1019 994513+ 83 Linux Command (m for help): v 604 unallocated sectors Command (m for help): w The partition table has been altered! Calling ioctl() to re-read partition table. WARNING: Re-reading the partition table failed with error 13: Permission denied. The kernel still uses the old table. The new table will be used at the next reboot. Syncing disks. crunchbang at crunchbang:~$ dmesg | tail -n15 [ 105.349997] intel8x0: measured clock 60413 rejected [ 105.350014] intel8x0: clocking to 48000 [ 106.251792] ppdev: user-space parallel port driver [ 108.981989] lp: driver loaded but no devices found [ 113.325992] Adding 238584k swap on /dev/sda5. Priority:-1 extents:1 across:238584k [ 136.902041] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 136.902068] Bluetooth: BNEP filters: protocol multicast [ 137.050569] Bridge firewalling registered [ 148.448932] eth0: link up, 100Mbps, full-duplex [ 159.357057] eth0: no IPv6 routers present [ 273.559938] sd 2:0:0:0: [sdb] Device not ready: Sense Key : Not Ready [current] [ 273.560053] sd 2:0:0:0: [sdb] Device not ready: <> ASC=0xff ASCQ=0xffASC=0xff <> ASCQ=0xff [ 273.560155] end_request: I/O error, dev sdb, sector 0 [ 273.560469] Buffer I/O error on device sdb, logical block 0 [ 273.560958] lost page write due to I/O error on sdb crunchbang at crunchbang:~$ From m-lists at biscuit.org.uk Wed May 5 12:49:26 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Wed, 5 May 2010 13:49:26 +0100 (BST) Subject: [ARMedslack] slackware on chumby one In-Reply-To: References: Message-ID: Hi Graeme > > crunchbang at crunchbang:~$ fdisk -l > > Disk /dev/sdb: 1018 MB, 1018691584 bytes Is this actualy your MicroSD card or the disc that the "crunchbag" is running from? [..] Also, I don't mean to discourage you but if you're quite new to Linux, then you've jumped into the deep end here -- the mini root filesystem is meant for developers or experience Linux administrators, because it needs quite a bit of work in order to get up and running. If you wanted a more gentle approach, it'd be easier to go for a documented system with a straight forward installation routine - such as the Marvell Sheevaplug. I am sure you'll be able to get it working eventually, but it just depends how much time and skills you can call on for help. -- Stuart Winter Slackware ARM: www.armedslack.org From gwolfendale at gmail.com Wed May 5 13:19:43 2010 From: gwolfendale at gmail.com (Graeme Wolfendale) Date: Wed, 5 May 2010 14:19:43 +0100 Subject: [ARMedslack] slackware on chumby one In-Reply-To: References: Message-ID: Hi Stuart, I am an inventor developing a new portable computer. My experiments have shown the i.mx233 as in the chumby to be too slow, so I have moved to the omap 3530. I intend to develop a custom linux distro, but have no idea how to go about this.. I do however think that the linux community would be interested in a low cost portable communicator ? Graeme On Wed, May 5, 2010 at 1:49 PM, Stuart Winter wrote: > > Hi Graeme > >> >> crunchbang at crunchbang:~$ fdisk -l >> >> Disk /dev/sdb: 1018 MB, 1018691584 bytes > > > Is this actualy your MicroSD card or the disc that the "crunchbag" is > running from? > > [..] > > Also, I don't mean to discourage you but if you're quite new to Linux, > then you've jumped into the deep end here -- the mini root filesystem is > meant for developers or experience Linux administrators, because it > needs quite a bit of work in order to get up and running. > > If you wanted a more gentle approach, it'd be easier to go for a > documented system with a straight forward installation routine - such as > the Marvell Sheevaplug. > > I am sure you'll be able to get it working eventually, but it just depends > how much time and skills you can call on for help. > > > -- > Stuart Winter > Slackware ARM: www.armedslack.org > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > From niels.horn at gmail.com Mon May 10 02:25:44 2010 From: niels.horn at gmail.com (Niels Horn) Date: Sun, 9 May 2010 23:25:44 -0300 Subject: [ARMedslack] kde3-compat packages Message-ID: Hi, Any special reason why there are no kde3-compat packages in /extra for ARMedslack (like there are for "normal" Slackware)? Simply never needed them, or any technical hurdle? Just tried to build an older program on ARMedslack that still used the qt3 library... Thanks, Niels From m-lists at biscuit.org.uk Mon May 10 09:44:23 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Mon, 10 May 2010 10:44:23 +0100 (BST) Subject: [ARMedslack] kde3-compat packages In-Reply-To: References: Message-ID: > > Any special reason why there are no kde3-compat packages in /extra for > ARMedslack (like there are for "normal" Slackware)? I usually deal with /extra immediately before a release rather than keeping up to date during the development of -current. I've just had a quick look at the kde3 compat build scripts and remembered how kde3 was a bit of a PITA. I'll run the scripts and see if they work but won't promise anything! -- Stuart Winter Slackware ARM: www.armedslack.org From niels.horn at gmail.com Mon May 10 10:12:20 2010 From: niels.horn at gmail.com (Niels Horn) Date: Mon, 10 May 2010 07:12:20 -0300 Subject: [ARMedslack] kde3-compat packages In-Reply-To: References: Message-ID: On Mon, May 10, 2010 at 6:44 AM, Stuart Winter wrote: > >> >> Any special reason why there are no kde3-compat packages in /extra for >> ARMedslack (like there are for "normal" Slackware)? > > I usually deal with /extra immediately before a release rather than > keeping up to date during the development of -current. > > I've just had a quick look at the kde3 compat build scripts and remembered > how kde3 was a bit of a PITA. ?I'll run the scripts and see if they work > but won't promise anything! > > -- > Stuart Winter > Slackware ARM: www.armedslack.org OK, thanks. :) I thought of compiling them myself, but I know it's big, so I preferred to ask before running into a heap of problems you might have discovered already. I think the most interesting package is the qt3 library, that's still needed by some older programs. I never needed any of the other "kde3-compat" stuff. BTW: My SheevaPlug has become a portable mainframe with the Hercules emulator. :) Niels From m-lists at biscuit.org.uk Tue May 11 07:18:07 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Tue, 11 May 2010 08:18:07 +0100 (BST) Subject: [ARMedslack] kde3-compat packages In-Reply-To: References: Message-ID: > I thought of compiling them myself, but I know it's big, so I > preferred to ask before running into a heap of problems you might have > discovered already. I've just discovered them :) > I think the most interesting package is the qt3 library, that's still > needed by some older programs. I never needed any of the other > "kde3-compat" stuff. qt3 is building (again). Hopefully it'll work 2nd time around. I won't build any of the kde3 stuff. -- Stuart Winter Slackware ARM: www.armedslack.org From m-lists at biscuit.org.uk Tue May 11 09:02:44 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Tue, 11 May 2010 10:02:44 +0100 (BST) Subject: [ARMedslack] kde3-compat packages In-Reply-To: References: Message-ID: Hi Niels, > qt3 is building (again). Hopefully it'll work 2nd time around. Does this work? ftp://ftp.armedslack.org/testing/qt3-3.3.8b-arm-opt2.tgz -- Stuart Winter Slackware ARM: www.armedslack.org From niels.horn at gmail.com Tue May 11 09:26:13 2010 From: niels.horn at gmail.com (Niels Horn) Date: Tue, 11 May 2010 06:26:13 -0300 Subject: [ARMedslack] kde3-compat packages In-Reply-To: References: Message-ID: On Tue, May 11, 2010 at 6:02 AM, Stuart Winter wrote: > > > Hi Niels, > >> qt3 is building (again). ?Hopefully it'll work 2nd time around. > > Does this work? > > ftp://ftp.armedslack.org/testing/qt3-3.3.8b-arm-opt2.tgz > It installed fine :) Building a qt3-based program now... This will take some time, but it looks promising for now. Thanks, and I'll report back later with the final results! Niels From niels.horn at gmail.com Tue May 11 11:44:06 2010 From: niels.horn at gmail.com (Niels Horn) Date: Tue, 11 May 2010 08:44:06 -0300 Subject: [ARMedslack] kde3-compat packages In-Reply-To: References: Message-ID: On Tue, May 11, 2010 at 6:26 AM, Niels Horn wrote: > On Tue, May 11, 2010 at 6:02 AM, Stuart Winter wrote: >> >> >> Hi Niels, >> >>> qt3 is building (again). ?Hopefully it'll work 2nd time around. >> >> Does this work? >> >> ftp://ftp.armedslack.org/testing/qt3-3.3.8b-arm-opt2.tgz >> > > It installed fine :) > > Building a qt3-based program now... > This will take some time, but it looks promising for now. > > Thanks, and I'll report back later with the final results! > > Niels > OK, tested it with two different programs and both built fine. I'm having a problem with the open-file dialog though. In one program it never works, in the other it sometimes doesn't work. Not sure if this is a problem with qt3 or something specific to the program I'm using. I guess this needs some more investigation :) Niels From mozes at slackware.com Mon May 17 17:17:15 2010 From: mozes at slackware.com (Stuart Winter) Date: Mon, 17 May 2010 10:17:15 -0700 (PDT) Subject: [ARMedslack] Slackware ARM 13.1 & Linux 2.6.33.4 Message-ID: Hi I was planning on using Linux 2.6.34 for Slackware ARM 13.1, but we've discovered that mdadm and Linux 2.6.34 isn't yet compatible with the Slackware init scripts. I've changed the kernel for Slackware ARM to be 2.6.33.4, and applied the OpenRD client patches to it, but have now lost the eSATA SheevaPlug support (which was in 2.6.34). For Slackware ARM 13.1 does anybody: a - care about eSATA SheevaPlug b - care about GuruPlug? If so and you can find patches to apply against 2.6.33.4, please let me know! I will upload the latest batch of updates in the next few days. -- Stuart Winter www.slackware.com/~mozes Slackware for ARM: www.armedslack.org From unixjohn1969 at gmail.com Mon May 17 18:03:27 2010 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Mon, 17 May 2010 14:03:27 -0400 Subject: [ARMedslack] Slackware ARM 13.1 & Linux 2.6.33.4 In-Reply-To: References: Message-ID: I am waiting for my guru plug with esata this week. But then I usually use my own kernels on my sheeva plugs so I dont think I would be affected. But these notes are good to know. Thanks for all your hard work Stuart This e-mail is brought to you by a Linux Android... On May 17, 2010 1:18 PM, "Stuart Winter" wrote: Hi I was planning on using Linux 2.6.34 for Slackware ARM 13.1, but we've discovered that mdadm and Linux 2.6.34 isn't yet compatible with the Slackware init scripts. I've changed the kernel for Slackware ARM to be 2.6.33.4, and applied the OpenRD client patches to it, but have now lost the eSATA SheevaPlug support (which was in 2.6.34). For Slackware ARM 13.1 does anybody: a - care about eSATA SheevaPlug b - care about GuruPlug? If so and you can find patches to apply against 2.6.33.4, please let me know! I will upload the latest batch of updates in the next few days. -- Stuart Winter www.slackware.com/~mozes Slackware for ARM: www.armedslack.org _______________________________________________ ARMedslack mailing list ARMedslack at lists.armedslack.org http://lists.armedslack.org/mailman/listinfo/armedslack -------------- next part -------------- An HTML attachment was scrubbed... URL: From jawkins at armedslack.org Mon May 17 23:22:14 2010 From: jawkins at armedslack.org (Jim Hawkins) Date: Tue, 18 May 2010 00:22:14 +0100 (BST) Subject: [ARMedslack] Slackware ARM 13.1 & Linux 2.6.33.4 In-Reply-To: References: Message-ID: Hi Stuart, You should be able to grab the 2.6.34 eSATA SheevaPlug patches from here: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d8ecb3490050b33bf46ce77c7f239e0fc51a6835 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d7b222d708e6eff0cf47928f439c8bcf49f10bb6 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d5b5746bed1023e4a55f96405422d3e51968fa43 And the GuruPlug patch from here: http://git.kernel.org/?p=linux/kernel/git/nico/orion.git;a=commit;h=d8f089d2ad35861c432618900fa08ca70c168d76 These seem to apply against 2.6.33.4 as long as you do them in the right order, although I haven't tried compiling them and I certainly haven't tested them as I don't have any kind of SheevaPlug and I'm still waiting for my GuruPlug to turn up :) The following states there are some additional GuruPlug patches as well: http://www.plugcomputer.org/plugwiki/index.php/Re-building_the_kernel_and_U-Boot I've put them all in a tarball and attached them to this mail. Isn't that nice? Cheers, Jim On Mon, 17 May 2010, Stuart Winter wrote: > > Hi > > I was planning on using Linux 2.6.34 for Slackware ARM 13.1, but > we've discovered that mdadm and Linux 2.6.34 isn't yet compatible with the > Slackware init scripts. > > I've changed the kernel for Slackware ARM to be 2.6.33.4, and applied > the OpenRD client patches to it, but have now lost the eSATA SheevaPlug > support (which was in 2.6.34). > > For Slackware ARM 13.1 does anybody: > a - care about eSATA SheevaPlug > b - care about GuruPlug? > > If so and you can find patches to apply against 2.6.33.4, please let me > know! > > I will upload the latest batch of updates in the next few days. > > -- > Stuart Winter > www.slackware.com/~mozes > Slackware for ARM: www.armedslack.org > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > -------------- next part -------------- A non-text attachment was scrubbed... Name: esata_sheevaplug_and_guruplug-patchset-2.6.33.4.tar.bz2 Type: application/octet-stream Size: 44725 bytes Desc: Patches URL: From m-lists at biscuit.org.uk Tue May 18 09:47:55 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Tue, 18 May 2010 10:47:55 +0100 (BST) Subject: [ARMedslack] Slackware ARM 13.1 & Linux 2.6.33.4 In-Reply-To: References: Message-ID: Hi Jim > These seem to apply against 2.6.33.4 as long as you do them in the right > order, although I haven't tried compiling them and I certainly haven't > tested them as I don't have any kind of SheevaPlug and I'm still waiting > for my GuruPlug to turn up :) I'd guess that the right order would be numerical since the patches are numbered in numerical order, but junk 3 of patch 0003 doesn't apply. I haven't tried alternating the order yet. > nice? Thanks! From jawkins at armedslack.org Tue May 18 10:03:49 2010 From: jawkins at armedslack.org (Jim Hawkins) Date: Tue, 18 May 2010 11:03:49 +0100 (BST) Subject: [ARMedslack] Slackware ARM 13.1 & Linux 2.6.33.4 In-Reply-To: References: Message-ID: On Tue, 18 May 2010, Stuart Winter wrote: > I'd guess that the right order would be numerical since the patches are > numbered in numerical order, but junk 3 of patch 0003 doesn't apply. I > haven't tried alternating the order yet. You're not trying to do a patch --dry-run are you? Hunk #3 of patch 3 depends on patch 2, so you need to actually *apply* the patches, in order. I just tried again on a clean 2.6.33.4 and they apply fine. Cheers, Jim From m-lists at biscuit.org.uk Tue May 18 10:26:20 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Tue, 18 May 2010 11:26:20 +0100 (BST) Subject: [ARMedslack] Slackware ARM 13.1 & Linux 2.6.33.4 In-Reply-To: References: Message-ID: > You're not trying to do a patch --dry-run are you? Hunk #3 of patch 3 > depends on patch 2, so you need to actually *apply* the patches, in order. I was but I'd also applied them ontop of a tree which had the openrd client patches. > I just tried again on a clean 2.6.33.4 and they apply fine. Same here. I shouldn't have left home without drinking the rest of the coffee from the pot ;-) /me starts the kernel building -- Stuart Winter Slackware ARM: www.armedslack.org From mozes at slackware.com Wed May 19 17:23:54 2010 From: mozes at slackware.com (Stuart Winter) Date: Wed, 19 May 2010 10:23:54 -0700 (PDT) Subject: [ARMedslack] Slackware ARM 13.1 rc1 ready Message-ID: Hi Slackware ARM 13.1 release candidate 1 is now ready for testing! Go go go GO! ;) -- Stuart Winter www.slackware.com/~mozes Slackware for ARM: www.armedslack.org From niels.horn at gmail.com Wed May 19 18:57:58 2010 From: niels.horn at gmail.com (Niels Horn) Date: Wed, 19 May 2010 15:57:58 -0300 Subject: [ARMedslack] Slackware ARM 13.1 rc1 ready In-Reply-To: References: Message-ID: On Wed, May 19, 2010 at 2:23 PM, Stuart Winter wrote: > > Hi > > Slackware ARM 13.1 release candidate 1 is now ready for testing! > > Go go go GO! ;) > > -- > Stuart Winter > www.slackware.com/~mozes > Slackware for ARM: www.armedslack.org > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > Updating my SheevaPlug remotely as I write! :) Niels From niels.horn at gmail.com Thu May 20 02:12:28 2010 From: niels.horn at gmail.com (Niels Horn) Date: Wed, 19 May 2010 23:12:28 -0300 Subject: [ARMedslack] Slackware ARM 13.1 rc1 ready In-Reply-To: References: Message-ID: On Wed, May 19, 2010 at 3:57 PM, Niels Horn wrote: > On Wed, May 19, 2010 at 2:23 PM, Stuart Winter wrote: >> >> Hi >> >> Slackware ARM 13.1 release candidate 1 is now ready for testing! >> >> Go go go GO! ;) >> >> -- >> Stuart Winter >> www.slackware.com/~mozes >> Slackware for ARM: www.armedslack.org >> _______________________________________________ >> ARMedslack mailing list >> ARMedslack at lists.armedslack.org >> http://lists.armedslack.org/mailman/listinfo/armedslack >> > > Updating my SheevaPlug remotely as I write! :) > > Niels > Hi, I'm getting the following md5sum errors when updating with slackpkg: ============================================================================== WARNING! WARNING! WARNING! WARNING! WARNING! ============================================================================== One or more errors occurred while slackpkg was running: kdegames-4.4.3-arm-1.tgz: md5sum kdegraphics-4.4.3-arm-1.tgz: md5sum kdelibs-4.4.3-arm-1.tgz: md5sum ============================================================================== Since I don't run KDE on my SheevaPlug, I did not care too much, but I resynced my local mirror and the error continued. Regards, Niels From m-lists at biscuit.org.uk Thu May 20 08:42:11 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Thu, 20 May 2010 09:42:11 +0100 (BST) Subject: [ARMedslack] Slackware ARM 13.1 rc1 ready In-Reply-To: References: Message-ID: > kdegames-4.4.3-arm-1.tgz: md5sum > kdegraphics-4.4.3-arm-1.tgz: md5sum > kdelibs-4.4.3-arm-1.tgz: md5sum These are the MD5 sums on the master: [mozes at bourbon slackware] $ egrep "kdegames.*z$|kdegraphi.*z$|kdelib.*z$" CHECKSUMS.md5 9837b6f7815397ed9467d98d3c0ff655 ./kde/kdegames-4.4.3-arm-1.tgz a0f9cf46893dffc6c87b126a44c3f7d2 ./kde/kdegraphics-4.4.3-arm-1.tgz 4caf608c837de8e861ad545fd5afd3e3 ./kde/kdelibs-4.4.3-arm-1.tgz [mozes at bourbon slackware] $ ( cd kde ; openssl md5 kdegames-4.4.3-arm-1.tgz kdegraphics-4.4.3-arm-1.tgz kdelibs-4.4.3-arm-1.tgz ) MD5(kdegames-4.4.3-arm-1.tgz)= 9837b6f7815397ed9467d98d3c0ff655 MD5(kdegraphics-4.4.3-arm-1.tgz)= a0f9cf46893dffc6c87b126a44c3f7d2 MD5(kdelibs-4.4.3-arm-1.tgz)= 4caf608c837de8e861ad545fd5afd3e3 [mozes at bourbon slackware] $ So they match there. What mirror are you downloading from? -- Stuart Winter Slackware ARM: www.armedslack.org From niels.horn at gmail.com Thu May 20 09:42:17 2010 From: niels.horn at gmail.com (Niels Horn) Date: Thu, 20 May 2010 06:42:17 -0300 Subject: [ARMedslack] Slackware ARM 13.1 rc1 ready In-Reply-To: References: Message-ID: On Thu, May 20, 2010 at 5:42 AM, Stuart Winter wrote: > >> kdegames-4.4.3-arm-1.tgz: ? ? md5sum >> kdegraphics-4.4.3-arm-1.tgz: ?md5sum >> kdelibs-4.4.3-arm-1.tgz: ? ? ?md5sum > > These are the MD5 sums on the master: > > [mozes at bourbon slackware] $ egrep "kdegames.*z$|kdegraphi.*z$|kdelib.*z$" > CHECKSUMS.md5 > 9837b6f7815397ed9467d98d3c0ff655 ?./kde/kdegames-4.4.3-arm-1.tgz > a0f9cf46893dffc6c87b126a44c3f7d2 ?./kde/kdegraphics-4.4.3-arm-1.tgz > 4caf608c837de8e861ad545fd5afd3e3 ?./kde/kdelibs-4.4.3-arm-1.tgz > > [mozes at bourbon slackware] $ ( cd kde ; openssl md5 > kdegames-4.4.3-arm-1.tgz kdegraphics-4.4.3-arm-1.tgz > kdelibs-4.4.3-arm-1.tgz ?) > MD5(kdegames-4.4.3-arm-1.tgz)= 9837b6f7815397ed9467d98d3c0ff655 > MD5(kdegraphics-4.4.3-arm-1.tgz)= a0f9cf46893dffc6c87b126a44c3f7d2 > MD5(kdelibs-4.4.3-arm-1.tgz)= 4caf608c837de8e861ad545fd5afd3e3 > [mozes at bourbon slackware] $ > > So they match there. > > What mirror are you downloading from? > > -- > Stuart Winter I downloaded from ftp.armedslack.org :) The CHECKSUMS.md5 file gives your values, but "md5sum -c CHECKSUMS.md5 | grep FAIL" gives: ./kde/kdegames-4.4.3-arm-1.tgz: FAILED ./kde/kdegraphics-4.4.3-arm-1.tgz: FAILED ./kde/kdelibs-4.4.3-arm-1.tgz: FAILED md5sum: WARNING: 3 of 3068 computed checksums did NOT match "ls -l kde{games,graphics,libs}-*.tgz" gives: -rw-r--r-- 1 65534 65534 64008341 2010-05-17 07:57 kdegames-4.4.3-arm-1.tgz -rw-r--r-- 1 65534 65534 4836747 2010-05-18 06:38 kdegraphics-4.4.3-arm-1.tgz -rw-r--r-- 1 65534 65534 18175456 2010-05-14 18:40 kdelibs-4.4.3-arm-1.tgz and the result of "md5sum kde{games,graphics,libs}-*.tgz": e017f736989dd79f4ce5c2f1d37124eb kdegames-4.4.3-arm-1.tgz a359f1819a1b8ae3868fcc581c583227 kdegraphics-4.4.3-arm-1.tgz f9846fad5b186468e7523ffceaa26fb9 kdelibs-4.4.3-arm-1.tgz No match indeed... I deleted and redownloaded the files, but got the same result. Niels From m-lists at biscuit.org.uk Thu May 20 09:54:48 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Thu, 20 May 2010 10:54:48 +0100 (BST) Subject: [ARMedslack] Slackware ARM 13.1 rc1 ready In-Reply-To: References: Message-ID: > I downloaded from ftp.armedslack.org :) The files were corrupted on there so I wiped them and re-pushed. I checked the sums on the server itself and they now match the CHECKSUMS file. I've added -c to the rsync options I use to push the stuff to that server. Looks like tetex-doc was also corrupt. From niels.horn at gmail.com Thu May 20 16:46:45 2010 From: niels.horn at gmail.com (Niels Horn) Date: Thu, 20 May 2010 13:46:45 -0300 Subject: [ARMedslack] Slackware ARM 13.1 rc1 ready In-Reply-To: References: Message-ID: On Thu, May 20, 2010 at 6:54 AM, Stuart Winter wrote: > >> I downloaded from ftp.armedslack.org :) > > The files were corrupted on there so I wiped them and re-pushed. > I checked the sums on the server itself and they now match the CHECKSUMS > file. > > I've added -c to the rsync options I use to push the stuff to that > server. > > Looks like tetex-doc was also corrupt. > OK, resynced and upgraded with SlackPkg. Everything is fine now :) I did not have any problems with tetex-doc btw... Niels From unixjohn1969 at gmail.com Fri May 21 00:03:10 2010 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Thu, 20 May 2010 20:03:10 -0400 Subject: [ARMedslack] Slackware ARM 13.1 rc1 ready In-Reply-To: References: Message-ID: <4BF5CDBE.4060509@gmail.com> Stuart Winter wrote: > Hi > > Slackware ARM 13.1 release candidate 1 is now ready for testing! > > Go go go GO! ;) Brand spanking new Guru Plug server. The debian on it has issues with gigabit ethernet that causes it to spin in a reboot cycle. Not that I care because I was going to install Slackware anyway. Attempting the TFTP/NFS install to an SD (hopefully) with the end result (after much tweaking) to roll my own jffs2 root image and run off the internal flash like I did with the Sheeva plug. But I am 20 steps ahead at the moment. I am just trying to get this to boot. Here is my session: U-Boot 2009.11-rc1-00602-g28a9c08-dirty (Feb 09 2010 - 18:15:21) Marvell-Plug2L SoC: Kirkwood 88F6281_A0 DRAM: 512 MB NAND: 512 MiB In: serial Out: serial Err: serial Net: egiga0, egiga1 88E1121 Initialized on egiga0 88E1121 Initialized on egiga1 Hit any key to stop autoboot: 0 Marvell>> printenv bootcmd=setenv ethact egiga0; ${x_bootcmd_ethernet}; setenv ethact egiga1; ${x_bootcmd_ethernet}; ${x_bootcmd_usb}; ${x_bootcmd_kernel}; setenv bootargs ${x_bootargs} ${x_bootargs_root}; bootm 0x6400000; bootdelay=3 baudrate=115200 x_bootcmd_ethernet=ping 192.168.2.1 x_bootcmd_usb=usb start x_bootcmd_kernel=nand read.e 0x6400000 0x100000 0x400000 x_bootargs=console=ttyS0,115200 x_bootargs_root=ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs ethact=egiga0 ethaddr=00:50:43:01:82:84 eth1addr=00:50:43:01:82:85 ipaddr=192.168.1.1 serverip=192.168.1.3 arcNumber=2097 mainlineLinux=yes stdin=serial stdout=serial stderr=serial Environment size: 622/131068 bytes Marvell>> usb start (Re)start USB... USB: Register 10011 NbrPorts 1 USB EHCI 1.00 scanning bus for devices... 4 USB Device(s) found scanning bus for storage devices... Device NOT ready Request Sense returned 02 3A 00 2 Storage Device(s) found Marvell>> tftpboot 0x01100000 GuruPlug/uinitrd-kirkwood.img Using egiga0 device TFTP from server 192.168.1.3; our IP address is 192.168.1.1 Filename 'GuruPlug/uinitrd-kirkwood.img'. Load address: 0x1100000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# (...later that day...) ################################################################# ############################################################## done Bytes transferred = 14625371 (df2a5b hex) Marvell>> tftpboot 0x00800000 GuruPlug/uImage-kirkwood Using egiga0 device TFTP from server 192.168.1.3; our IP address is 192.168.1.1 Filename 'GuruPlug/uImage-kirkwood'. Load address: 0x800000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ############ done Bytes transferred = 2056040 (1f5f68 hex) Marvell>> setenv bootargs console=ttyS0,115200 nodhcp kbd=us root=/dev/ram rw Marvell>> bootm 0x00800000 0x01100000 ## Booting kernel from Legacy Image at 00800000 ... Image Name: Linux-2.6.33.4-kirkwood Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2055976 Bytes = 2 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 01100000 ... Image Name: Slackware ARM Installer Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 14625307 Bytes = 13.9 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. And thats it... It just hangs. Any ideas for me to try? I'll have to re-rsync to get those checksum changes, other than that this is the latest and greatest 13.1 rc1 -- === 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 Fri May 21 09:23:40 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Fri, 21 May 2010 10:23:40 +0100 (BST) Subject: [ARMedslack] Slackware ARM 13.1 rc1 ready In-Reply-To: <4BF5CDBE.4060509@gmail.com> References: <4BF5CDBE.4060509@gmail.com> Message-ID: Hi John > arcNumber=2097 This value is correct for a SheevaPlug, but looking at the trouble shooting guides for Linux on the SP, the common cause of the problem you see is because the arcNumber isn't set correctly. I'd guess that the GuruPlug has a different value, given that the OpenRD client & OpenRD Base have different values but are almost identical bits of hardware. The other cause of no output after uncompressing the kernel was due to the u-boot "console" value being incorrectly set, but yours looks ok. I had a look for the value for a GuruPlug but I couldn't find it yet. I'll have to add this into the INSTALL_KIRKWOOD.TXT file once we know what it is, or whatever else is needed to boot the system. From jawkins at armedslack.org Fri May 21 11:34:01 2010 From: jawkins at armedslack.org (Jim Hawkins) Date: Fri, 21 May 2010 12:34:01 +0100 (BST) Subject: [ARMedslack] Slackware ARM 13.1 rc1 ready In-Reply-To: References: <4BF5CDBE.4060509@gmail.com> Message-ID: $ grep guruplug arch/arm/tools/mach-types guruplug MACH_GURUPLUG GURUPLUG 2659 Try arcNumber=2659 instead. Cheers, Jim On Fri, 21 May 2010, Stuart Winter wrote: > > Hi John > > > arcNumber=2097 > > This value is correct for a SheevaPlug, but looking at the trouble > shooting guides for Linux on the SP, the common cause of the problem > you see is because the arcNumber isn't set correctly. > I'd guess that the GuruPlug has a different value, given that the OpenRD > client & OpenRD Base have different values but are almost identical bits > of hardware. > > The other cause of no output after uncompressing the kernel was due to the > u-boot "console" value being incorrectly set, but yours looks ok. > > I had a look for the value for a GuruPlug but I couldn't find it yet. > I'll have to add this into the INSTALL_KIRKWOOD.TXT file once we know what > it is, or whatever else is needed to boot the system. > > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > From unixjohn1969 at gmail.com Fri May 21 16:06:47 2010 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Fri, 21 May 2010 12:06:47 -0400 Subject: [ARMedslack] Slackware ARM 13.1 rc1 ready In-Reply-To: References: <4BF5CDBE.4060509@gmail.com> Message-ID: <4BF6AF97.9050304@gmail.com> Jim Hawkins wrote: > $ grep guruplug arch/arm/tools/mach-types > guruplug MACH_GURUPLUG GURUPLUG 2659 > > Try arcNumber=2659 instead. Marvell>> printenv bootcmd=setenv ethact egiga0; ${x_bootcmd_ethernet}; setenv ethact egiga1; ${x_bootcmd_ethernet}; ${x_bootcmd_usb}; ${x_bootcmd_kernel}; setenv bootargs ${x_bootargs} ${x_bootargs_root}; bootm 0x6400000; bootdelay=3 baudrate=115200 x_bootcmd_ethernet=ping 192.168.2.1 x_bootcmd_usb=usb start x_bootcmd_kernel=nand read.e 0x6400000 0x100000 0x400000 x_bootargs=console=ttyS0,115200 x_bootargs_root=ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs ethact=egiga0 ethaddr=00:50:43:01:82:84 eth1addr=00:50:43:01:82:85 ipaddr=192.168.1.1 serverip=192.168.1.3 mainlineLinux=yes arcNumber=2659 stdin=serial stdout=serial stderr=serial Environment size: 622/131068 bytes Marvell>> It still hangs at the same spot. -- === 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 Fri May 21 16:21:38 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Fri, 21 May 2010 17:21:38 +0100 (BST) Subject: [ARMedslack] Slackware ARM 13.1 rc1 ready In-Reply-To: <4BF6AF97.9050304@gmail.com> References: <4BF5CDBE.4060509@gmail.com> <4BF6AF97.9050304@gmail.com> Message-ID: > It still hangs at the same spot. I am reluctant to say this because it may not be the same set of conditions, but: I had the same problem when I got my SheevaPlugs. When I upgraded u-boot, I chose to erase all of the settings back to the defaults, and then it all worked. I never figured out what the difference was in the two configs because I didn't save the out-of-box one. I haven't got a u-boot console to hand, but there's probably a way to reset the settings to the defaults; then change the additional "mainlinelinux" and "arcnumber" settings and try again. Prior to this, save a copy of your "printenv". Disclaimer: if it breaks, don't blame me ;-) -- Stuart Winter Slackware ARM: www.armedslack.org From unixjohn1969 at gmail.com Fri May 21 16:37:02 2010 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Fri, 21 May 2010 12:37:02 -0400 Subject: [ARMedslack] Slackware ARM 13.1 rc1 ready In-Reply-To: References: <4BF5CDBE.4060509@gmail.com> <4BF6AF97.9050304@gmail.com> Message-ID: <4BF6B6AE.2090902@gmail.com> Stuart Winter wrote: >> It still hangs at the same spot. > > I am reluctant to say this because it may not be the same set of > conditions, but: I had the same problem when I got my SheevaPlugs. > When I upgraded u-boot, I chose to erase all of the settings back to the > defaults, and then it all worked. > > I never figured out what the difference was in the two configs because I > didn't save the out-of-box one. > > I haven't got a u-boot console to hand, but there's probably a way to > reset the settings to the defaults; then change the additional > "mainlinelinux" and "arcnumber" settings and try again. > Prior to this, save a copy of your "printenv". > > Disclaimer: if it breaks, don't blame me ;-) Oooooo Standard Disclaimers!!! You may be right though. I was reading this thread which seems to describe my exact problem: http://plugcomputer.org/plugforum/index.php?topic=1669.0 I am going to give the new u-boot a try this weekend. I noticed no mmcinit. I hope the new u-boot adds this as I was hoping to boot off the SD card like on the Sheeva. Thanks for your help guys. John -- === Never ask a geek why, just nod your head and slowly back away.=== +================================+==================================+ | John O'Donnell | | | (Sr. Systems Engineer, | http://juanisan.homeip.net | | Net Admin, Programmer, etc.) | E-Mail: unixjohn1969 at gmail.com | +================================+==================================+ No man is useless who has a friend, and if we are loved we are indispensable. -- Robert Louis Stevenson From unixjohn1969 at gmail.com Fri May 21 16:54:58 2010 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Fri, 21 May 2010 12:54:58 -0400 Subject: [ARMedslack] Slackware ARM 13.1 rc1 ready In-Reply-To: References: <4BF5CDBE.4060509@gmail.com> <4BF6AF97.9050304@gmail.com> Message-ID: <4BF6BAE2.2040100@gmail.com> Stuart Winter wrote: >> It still hangs at the same spot. > > I am reluctant to say this because it may not be the same set of > conditions, but: I had the same problem when I got my SheevaPlugs. > When I upgraded u-boot, I chose to erase all of the settings back to the > defaults, and then it all worked. It worked! I am being VERY VERBOSE in case there is anything you need to note. Marvell>> tftp 0x6400000 uboot.guruplug.bin Using egiga0 device TFTP from server 192.168.1.3; our IP address is 192.168.1.1 Filename 'uboot.guruplug.bin'. Load address: 0x6400000 Loading: #################################### done Bytes transferred = 180220 (2bffc hex) Marvell>> nand erase 0x0 0x100000 NAND erase: device 0 offset 0x0, size 0x100000 Erasing at 0xe0000 -- 100% complete. OK Marvell>> nand write.e 0x6400000 0x0 0x100000 NAND write: device 0 offset 0x0, size 0x100000 1048576 bytes written: OK Marvell>> reset resetting ... U-Boot 2010.03-01161-gd91b0a9 (Apr 22 2010 - 03:24:41) Marvell-GuruPlug SoC: Kirkwood 88F6281_A0 DRAM: 512 MB NAND: 512 MiB *** Warning - bad CRC or NAND, using default environment In: serial Out: serial Err: serial Net: egiga0, egiga1 88E1121 Initialized on egiga0 88E1121 Initialized on egiga1 Hit any key to stop autoboot: 0 Marvell>> printenv bootcmd=${x_bootcmd_usb}; ${x_bootcmd_kernel}; setenv bootargs ${x_bootargs} ${x_bootargs_root}; bootm 0x6400000; bootdelay=3 baudrate=115200 x_bootcmd_usb=usb start x_bootcmd_kernel=nand read.e 0x6400000 0x100000 0x400000 x_bootargs=console=ttyS0,115200 x_bootargs_root=ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs stdin=serial stdout=serial stderr=serial ethaddr=02:50:43:61:ec:4e ethact=egiga0 eth1addr=02:50:43:eb:a3:23 Environment size: 423/131068 bytes Marvell>> setenv ipaddr 192.168.1.1 Marvell>> setenv serverip 192.168.1.3 Marvell>> setenv arcNumber 2659 Marvell>> setenv mainlineLinux yes Marvell>> saveenv Saving Environment to NAND... Erasing Nand... Erasing at 0x40000 -- 100% complete. Writing to Nand... done Marvell>> reset resetting ... U-Boot 2010.03-01161-gd91b0a9 (Apr 22 2010 - 03:24:41) Marvell-GuruPlug SoC: Kirkwood 88F6281_A0 DRAM: 512 MB NAND: 512 MiB In: serial Out: serial Err: serial Net: egiga0, egiga1 88E1121 Initialized on egiga0 88E1121 Initialized on egiga1 Hit any key to stop autoboot: 0 Marvell>> tftpboot 0x01100000 GuruPlug/uinitrd-kirkwood.img Using egiga0 device TFTP from server 192.168.1.3; our IP address is 192.168.1.1 Filename 'GuruPlug/uinitrd-kirkwood.img'. Load address: 0x1100000 Loading: ################################################################# ################################################################# (...later that day...) ################################################################# ############################################################## done Bytes transferred = 14625371 (df2a5b hex) Marvell>> tftpboot 0x00800000 GuruPlug/uImage-kirkwood Using egiga0 device TFTP from server 192.168.1.3; our IP address is 192.168.1.1 Filename 'GuruPlug/uImage-kirkwood'. Load address: 0x800000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ############ done Bytes transferred = 2056040 (1f5f68 hex) Marvell>> setenv bootargs console=ttyS0,115200 nodhcp kbd=us root=/dev/ram rw Marvell>> bootm 0x00800000 0x01100000 ## Booting kernel from Legacy Image at 00800000 ... Image Name: Linux-2.6.33.4-kirkwood Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2055976 Bytes = 2 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 01100000 ... Image Name: Slackware ARM Installer Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 14625307 Bytes = 13.9 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [ 0.000000] Linux version 2.6.33.4-kirkwood (root at wizbit) (gcc version 4.4.4 (GCC) ) #2 PREEMPT Wed May 19 11:14:40 BST 2010 [ 0.000000] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977 [ 0.000000] CPU: VIVT data cache, VIVT instruction cache [ 0.000000] Machine: Marvell GuruPlug Reference Board [ 0.000000] Memory policy: ECC disabled, Data cache writeback [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 [ 0.000000] Kernel command line: console=ttyS0,115200 nodhcp kbd=us root=/dev/ram rw [ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes) [ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] Memory: 256MB 256MB = 512MB total [ 0.000000] Memory: 500736KB available (3676K code, 557K data, 124K init, 0K highmem) [ 0.000000] Hierarchical RCU implementation. [ 0.000000] NR_IRQS:114 [ 0.000000] Console: colour dummy device 80x30 [ 0.000178] Calibrating delay loop... 1192.75 BogoMIPS (lpj=5963776) [ 0.240166] Security Framework initialized [ 0.240241] Mount-cache hash table entries: 512 [ 0.240546] Initializing cgroup subsys ns [ 0.240559] Initializing cgroup subsys cpuacct [ 0.240568] Initializing cgroup subsys devices [ 0.240578] Initializing cgroup subsys freezer [ 0.240586] Initializing cgroup subsys net_cls [ 0.240638] CPU: Testing write buffer coherency: ok [ 0.242754] regulator: core version 0.5 [ 0.243023] NET: Registered protocol family 16 [ 0.244534] Kirkwood: MV88F6281-A1, TCLK=200000000. [ 0.244547] Feroceon L2: Cache support initialised. [ 0.253129] bio: create slab at 0 [ 0.253919] vgaarb: loaded [ 0.255496] Switching to clocksource orion_clocksource [ 0.262065] NET: Registered protocol family 2 [ 0.262268] IP route cache hash table entries: 4096 (order: 2, 16384 bytes) [ 0.262976] TCP established hash table entries: 16384 (order: 5, 131072 bytes) [ 0.263330] TCP bind hash table entries: 16384 (order: 4, 65536 bytes) [ 0.263510] TCP: Hash tables configured (established 16384 bind 16384) [ 0.263520] TCP reno registered [ 0.263530] UDP hash table entries: 256 (order: 0, 4096 bytes) [ 0.263553] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) [ 0.263760] NET: Registered protocol family 1 [ 0.263952] Trying to unpack rootfs image as initramfs... [ 1.128625] Freeing initrd memory: 14280K [ 1.129141] NetWinder Floating Point Emulator V0.97 (double precision) [ 1.129828] audit: initializing netlink socket (disabled) [ 1.129872] type=2000 audit(1.120:1): initialized [ 1.175289] VFS: Disk quotas dquot_6.5.2 [ 1.175398] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 1.175606] JFFS2 version 2.2. (NAND) (SUMMARY) ?? 2001-2006 Red Hat, Inc. [ 1.176046] msgmni has been set to 1006 [ 1.178919] alg: No test for stdrng (krng) [ 1.179184] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) [ 1.179198] io scheduler noop registered [ 1.179206] io scheduler deadline registered [ 1.179275] io scheduler cfq registered (default) [ 1.191490] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled [ 1.192300] serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A [ 1.494310] console [ttyS0] enabled [ 1.506271] brd: module loaded [ 1.510201] NAND device: Manufacturer ID: 0xec, Chip ID: 0xdc (Samsung NAND 512MiB 3,3V 8-bit) [ 1.518969] Scanning device for bad blocks [ 1.656288] Bad eraseblock 3558 at 0x00001bcc0000 [ 1.681104] Creating 3 MTD partitions on "orion_nand": [ 1.686280] 0x000000000000-0x000000100000 : "u-boot" [ 1.692302] ftl_cs: FTL header not found. [ 1.696972] 0x000000100000-0x000000500000 : "uImage" [ 1.702923] ftl_cs: FTL header not found. [ 1.707477] 0x000000500000-0x000020000000 : "root" [ 1.713653] ftl_cs: FTL header not found. [ 1.720231] mice: PS/2 mouse device common for all mice [ 1.726179] rtc-mv rtc-mv: rtc core: registered rtc-mv as rtc0 [ 1.732193] i2c /dev entries driver [ 1.736506] cpuidle: using governor ladder [ 1.741126] cpuidle: using governor menu [ 1.745269] Registered led device: guruplug:red:health [ 1.750653] Registered led device: guruplug:green:health [ 1.756198] Registered led device: guruplug:red:wmode [ 1.761440] Registered led device: guruplug:green:wmode [ 1.766860] mv_xor_shared mv_xor_shared.0: Marvell shared XOR driver [ 1.773260] mv_xor_shared mv_xor_shared.1: Marvell shared XOR driver [ 1.815565] mv_xor mv_xor.0: Marvell XOR: ( xor cpy ) [ 1.855562] mv_xor mv_xor.1: Marvell XOR: ( xor fill cpy ) [ 1.895562] mv_xor mv_xor.2: Marvell XOR: ( xor cpy ) [ 1.935562] mv_xor mv_xor.3: Marvell XOR: ( xor fill cpy ) [ 1.942165] TCP cubic registered [ 1.945414] NET: Registered protocol family 17 [ 1.950536] registered taskstats version 1 [ 1.955226] rtc-mv rtc-mv: setting system clock to 2009-08-08 08:32:13 UTC (1249720333) [ 1.963399] Freeing init memory: 124K [ 2.024938] device-mapper: ioctl: 4.17.0-ioctl (2010-03-05) initialised: dm-devel at redhat.com [ 2.115562] Slow work thread pool: Starting up [ 2.120186] Slow work thread pool: Ready [ 2.390998] JFS: nTxBlock = 4026, nTxLock = 32214 [ 2.498695] RPC: Registered udp transport module. [ 2.503423] RPC: Registered tcp transport module. [ 2.508213] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 2.881718] SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no debug enabled [ 2.892452] SGI XFS Quota Management subsystem [ 2.986281] usbcore: registered new interface driver usbfs [ 2.992128] usbcore: registered new interface driver hub [ 2.997720] usbcore: registered new device driver usb [ 3.026219] usbcore: registered new interface driver libusual [ 3.113637] SCSI subsystem initialized [ 3.141178] Initializing USB Mass Storage driver... [ 3.146338] usbcore: registered new interface driver usb-storage [ 3.152373] USB Mass Storage support registered. [ 3.188346] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 3.194956] orion-ehci orion-ehci.0: Marvell Orion EHCI [ 3.200336] orion-ehci orion-ehci.0: new USB bus registered, assigned bus number 1 [ 3.235551] orion-ehci orion-ehci.0: irq 19, io mem 0xf1050000 [ 3.255534] orion-ehci orion-ehci.0: USB 2.0 started, EHCI 1.00 [ 3.261543] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 3.268389] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 3.275663] usb usb1: Product: Marvell Orion EHCI [ 3.280393] usb usb1: Manufacturer: Linux 2.6.33.4-kirkwood ehci_hcd [ 3.286788] usb usb1: SerialNumber: orion-ehci.0 [ 3.292020] hub 1-0:1.0: USB hub found [ 3.295857] hub 1-0:1.0: 1 port detected [ 3.456360] MV-643xx 10/100/1000 ethernet driver version 1.4 [ 3.462257] mv643xx_eth smi: probed [ 3.468475] net eth0: port 0 with MAC address 02:50:43:61:ec:4e [ 3.476941] net eth1: port 0 with MAC address 02:50:43:eb:a3:23 Welcome to the Slackware Linux installation disk! (version 13.1) ###### IMPORTANT! READ THE INFORMATION BELOW CAREFULLY. ###### - You will need one or more partitions of type 'Linux' prepared. It is also recommended that you create a swap partition (type 'Linux swap') prior to installation. For more information, run 'setup' and read the help file. - If you're having problems that you think might be related to low memory (this is possible on machines with 64 or less megabytes of system memory), you can try activating a swap partition before you run setup. After making a swap partition (type 82) with cfdisk or fdisk, activate it like this: mkswap /dev/ ; swapon /dev/ - Once you have prepared the disk partitions for Linux, type 'setup' to begin the installation process. - If you do not have a color monitor, type: TERM=vt100 before you start 'setup'. You may now login as 'root'. slackware login: WOOT! Cant play now, but I will this weekend and let you know how it goes Note: I did set -- === 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 Fri May 21 18:56:22 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Fri, 21 May 2010 19:56:22 +0100 (BST) Subject: [ARMedslack] Slackware ARM 13.1 rc1 ready In-Reply-To: <4BF6BAE2.2040100@gmail.com> References: <4BF5CDBE.4060509@gmail.com> <4BF6AF97.9050304@gmail.com> <4BF6BAE2.2040100@gmail.com> Message-ID: > It worked! Excellent. I've added the arcNumber to the install docs. I think I'll keep the bit about resetting the environment out of it though. [..] > WOOT! Cant play now, but I will this weekend and let you know how it goes > Note: I did set .... what did you set? Can you do a diff between the u-boot config you had before and after the u-boot upgrade? -- Stuart Winter Slackware ARM: www.armedslack.org From atelszewski at gmail.com Fri May 21 20:19:12 2010 From: atelszewski at gmail.com (Andrzej Telszewski) Date: Fri, 21 May 2010 22:19:12 +0200 Subject: [ARMedslack] armedslack & experimental kernel options Message-ID: <4BF6EAC0.4060903@gmail.com> Hi Stuart, I'm reviewing your kernel config (2.6.33.4) for upcoming 13.1 to make it suit my board and processor (the same I wrote you of in e-mails some time ago) and I've noticed that there are many experimental options enabled. Are they really needed or would it be better if you wipe the off as Slackware rules say that as much as possible should be stable and not experimental? Some example options: General setup ---> Export task/process statistics through netlink (EXPERIMENTAL) General setup ---> User namespace (EXPERIMENTAL) By the way, in few days I'm going to try 13.1rc1 on my board so I let you know "how and if" it works;) -- Best regards, Andrzej Telszewski From rw at rlworkman.net Fri May 21 22:15:32 2010 From: rw at rlworkman.net (Robby Workman) Date: Fri, 21 May 2010 17:15:32 -0500 Subject: [ARMedslack] Slackware ARM 13.1 rc1 ready In-Reply-To: <4BF6BAE2.2040100@gmail.com> References: <4BF5CDBE.4060509@gmail.com> <4BF6AF97.9050304@gmail.com> <4BF6BAE2.2040100@gmail.com> Message-ID: <20100521171532.1672078b@liberty.rlwhome.lan> On Fri, 21 May 2010 12:54:58 -0400 John O'Donnell wrote: > It worked! > I am being VERY VERBOSE in case there is anything you need to note. > > Marvell>> tftp 0x6400000 uboot.guruplug.bin > ... snipped ... I'm looking forward to migrating firewall duties from my SheevaPlug to the GuruPlug, which is scheduled to arrive on Monday :-) I'm curious though -- do you *need* the JTAG thingy to get serial console access? I didn't order one with the GuruPlug since it "just worked" on the SheevaPlug already... -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From m-lists at biscuit.org.uk Sat May 22 08:01:38 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sat, 22 May 2010 09:01:38 +0100 (BST) Subject: [ARMedslack] armedslack & experimental kernel options In-Reply-To: <4BF6EAC0.4060903@gmail.com> References: <4BF6EAC0.4060903@gmail.com> Message-ID: > > I'm reviewing your kernel config (2.6.33.4) for upcoming 13.1 to make it > suit my board and processor (the same I wrote you of in e-mails some > time ago) and I've noticed that there are many experimental options > enabled. Are they really needed or would it be better if you wipe the > off as Slackware rules say that as much as possible should be stable and > not experimental? > > Some example options: > General setup ---> Export task/process statistics through netlink > (EXPERIMENTAL) > General setup ---> User namespace (EXPERIMENTAL) I have only knowingly selected experimental stuff on a few occasions when I believe it's necessary for performance or provides a particular functionality. In the cases above, that applies to neither of them, so it might be that when running "make oldconfig" - I chose the default recommendation from the help text - I didn't notice it was experimental and selected "M" (I add most new stuff as modules) - and the most likely case - those options aren't exprimental in linux 2.6.34 which was what the kernel config was originally intended for. The "User namespace" is recommended "N" if unsure, and from reading the description, it doesn't look like something that'd be useful on the ARM platform. I will review the kernel configs at a later date and see if there's anything like this that can be removed. > By the way, in few days I'm going to try 13.1rc1 on my board so I let > you know "how and if" it works;) Great thanks. -- Stuart Winter Slackware ARM: www.armedslack.org From unixjohn1969 at gmail.com Sat May 22 19:40:32 2010 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Sat, 22 May 2010 15:40:32 -0400 Subject: [ARMedslack] guruplug In-Reply-To: References: <4BF6EAC0.4060903@gmail.com> Message-ID: <4BF83330.6050000@gmail.com> Well you can rethink the way you install Slackware on the GuruPlug. There are many commands missing (and some new) in the U-Boot for the GuruPlug. Missing is an important one for your Slackware directions: ext2load There is no command Marvell>> ext2load Unknown command 'ext2load' - try 'help' Marvell>> mmcinit Unknown command 'mmcinit' - try 'help' Marvell>> fatload usage: fatload [bytes] Marvell>> I guess we need to change /boot to a FAT partition!?! YUCK! John -- === Never ask a geek why, just nod your head and slowly back away.=== +================================+==================================+ | John O'Donnell | | | (Sr. Systems Engineer, | http://juanisan.homeip.net | | Net Admin, Programmer, etc.) | E-Mail: unixjohn1969 at gmail.com | +================================+==================================+ No man is useless who has a friend, and if we are loved we are indispensable. -- Robert Louis Stevenson From m-lists at biscuit.org.uk Sat May 22 21:14:33 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sat, 22 May 2010 22:14:33 +0100 (BST) Subject: [ARMedslack] guruplug In-Reply-To: <4BF83330.6050000@gmail.com> References: <4BF6EAC0.4060903@gmail.com> <4BF83330.6050000@gmail.com> Message-ID: > I guess we need to change /boot to a FAT partition!?! I'd look around and ask on the plug web site about it before making such a choice; I'm shocked to see ext2 filesystem support missing. The Kernel package won't install properly to a FAT filesystem /boot because the "uImage-" file names are symlinks to a version-named kernel file. You could still work around this manually in the installer, but I'd wait to find out why ext2 support is missing first. -- Stuart Winter Slackware ARM: www.armedslack.org From m-lists at biscuit.org.uk Sat May 22 21:24:27 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sat, 22 May 2010 22:24:27 +0100 (BST) Subject: [ARMedslack] guruplug In-Reply-To: References: <4BF6EAC0.4060903@gmail.com> <4BF83330.6050000@gmail.com> Message-ID: > You could still work around this manually in the installer, but > I'd wait to find out why ext2 support is missing first. http://plugcomputer.org/plugforum/index.php?topic=1642.0 http://www.plugcomputer.org/index.php/us/resources/downloads?func=select&id=15 Does the guruplug u-boot binary available from the 2nd url provide ext2load ? -- Stuart Winter Slackware ARM: www.armedslack.org From m-lists at biscuit.org.uk Sat May 22 21:28:36 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sat, 22 May 2010 22:28:36 +0100 (BST) Subject: [ARMedslack] guruplug In-Reply-To: References: <4BF6EAC0.4060903@gmail.com> <4BF83330.6050000@gmail.com> Message-ID: > http://www.plugcomputer.org/index.php/us/resources/downloads?func=select&id=15 > > Does the guruplug u-boot binary available from the 2nd url provide > ext2load ? I ran "strings" over it: It doesn't. http://oinkzwurgl.org/guruplug_uboot http://oinkzwurgl.org/dl.php?file=guruplug-u-boot-flipflip-20100512.tar.gz However, this one does. Try that :) -- Stuart Winter Slackware ARM: www.armedslack.org From unixjohn1969 at gmail.com Sat May 22 21:29:24 2010 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Sat, 22 May 2010 17:29:24 -0400 Subject: [ARMedslack] guruplug In-Reply-To: References: <4BF6EAC0.4060903@gmail.com> <4BF83330.6050000@gmail.com> Message-ID: If you search on the forums you will find various comments about it missing. I found out that the sd card slot is a usb device. Sda and sdb are taken so the usb stick is sdc. Dont know what the other device is yet. I'll post more as I learn more. ** This e-mail was sent from a Linux Android phone. ** On May 22, 2010 5:14 PM, "Stuart Winter" wrote: > I guess we need to change /boot to a FAT partition!?! I'd look around and ask on the plug web site about it before making such a choice; I'm shocked to see ext2 filesystem support missing. The Kernel package won't install properly to a FAT filesystem /boot because the "uImage-" file names are symlinks to a version-named kernel file. You could still work around this manually in the installer, but I'd wait to find out why ext2 support is missing first. -- Stuart Winter Slackware ARM: www.armedslack.org _______________________________________________ ARMedslack mailing list ARMedslack at lists.armedslack.org http://lists.armedslack.org/mailman/listinfo/armedslack -------------- next part -------------- An HTML attachment was scrubbed... URL: From unixjohn1969 at gmail.com Sat May 22 21:31:54 2010 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Sat, 22 May 2010 17:31:54 -0400 Subject: [ARMedslack] Slackware ARM 13.1 rc1 ready In-Reply-To: <20100521171532.1672078b@liberty.rlwhome.lan> References: <4BF5CDBE.4060509@gmail.com> <4BF6AF97.9050304@gmail.com> <4BF6BAE2.2040100@gmail.com> <20100521171532.1672078b@liberty.rlwhome.lan> Message-ID: You NEED to upgrade your uboot to boot non-factory kernel it seems. I dont know how to upgrade uboot without the console. Perhaps you can with the mtd utils on a booted system?? ** This e-mail was sent from a Linux Android phone. ** On May 21, 2010 6:15 PM, "Robby Workman" wrote: On Fri, 21 May 2010 12:54:58 -0400 John O'Donnell wrote: > It worked! > I ... > ... snipped ... I'm looking forward to migrating firewall duties from my SheevaPlug to the GuruPlug, which is scheduled to arrive on Monday :-) I'm curious though -- do you *need* the JTAG thingy to get serial console access? I didn't order one with the GuruPlug since it "just worked" on the SheevaPlug already... -RW _______________________________________________ ARMedslack mailing list ARMedslack at lists.armedslack.org http://lists.armedslack.org/mailman/listinfo/armedslack -------------- next part -------------- An HTML attachment was scrubbed... URL: From m-lists at biscuit.org.uk Sun May 23 07:25:38 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sun, 23 May 2010 08:25:38 +0100 (BST) Subject: [ARMedslack] Slackware ARM 13.1 rc1 ready In-Reply-To: References: <4BF5CDBE.4060509@gmail.com> <4BF6AF97.9050304@gmail.com> <4BF6BAE2.2040100@gmail.com> <20100521171532.1672078b@liberty.rlwhome.lan> Message-ID: > You NEED to upgrade your uboot to boot non-factory kernel it seems. I dont > know how to upgrade uboot without the console. Perhaps you can with the mtd > utils on a booted system?? It can be done this way but you'd need access to the console to perform the installation of Slackware; although technically you could install the sheeva-u-boot tools onto the existing installation; modify the u-boot config from linux and cause it boot the installer (getting it to configure its eth0 and start sshd). But at some point you'd most likely need the JTAG console because if the system ever fails to boot, you won't be able to see why. From unixjohn1969 at gmail.com Mon May 24 03:54:26 2010 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Sun, 23 May 2010 23:54:26 -0400 Subject: [ARMedslack] guruplug In-Reply-To: References: <4BF6EAC0.4060903@gmail.com> <4BF83330.6050000@gmail.com> Message-ID: <4BF9F872.9000703@gmail.com> Stuart Winter wrote: >> http://www.plugcomputer.org/index.php/us/resources/downloads?func=select&id=15 >> >> Does the guruplug u-boot binary available from the 2nd url provide >> ext2load ? > > I ran "strings" over it: It doesn't. > > http://oinkzwurgl.org/guruplug_uboot > http://oinkzwurgl.org/dl.php?file=guruplug-u-boot-flipflip-20100512.tar.gz > > However, this one does. Try that :) > I got mine loading from FAT16 but not FAT32. 32 gave me streaming errors even trying a "fatls". I converted it to FAT16 (<32M) and it boots fine now from an SD card. I will be a guinea pig and try that u-boot. I'll let you know how it goes. -- === 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 unixjohn1969 at gmail.com Mon May 24 05:08:12 2010 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Mon, 24 May 2010 01:08:12 -0400 Subject: [ARMedslack] guruplug update In-Reply-To: References: <4BF6EAC0.4060903@gmail.com> <4BF83330.6050000@gmail.com> Message-ID: <4BFA09BC.4000509@gmail.com> I installed that new u-boot and now I get ext2load. This is so strange that Globalscale felt it necessary/wise to leave this out. Converting the SD card /dev/sdc1 from FAT back to ext2 on my linux desktop. Symlinks intact.. PLugged back into the plug. and.... Booting.... Sweeeeeet! ------------------------------------------------------------- Hit any key to stop autoboot: 0 GuruPlug>> setenv bootargs_console console=ttyS0,115200 GuruPlug>> setenv bootargs_root 'root=/dev/sdc3 waitforroot=10 rootfs=ext3' GuruPlug>> setenv bootcmd 'setenv bootargs $(bootargs_console) $(bootargs_root); run bootcmd_slk ; reset' GuruPlug>> setenv bootcmd_slk 'usb start;ext2load usb 1:1 0x01100000 uinitrd-kirkwood;ext2load usb 1:1 0x0080 0000 /uImage-kirkwood;bootm 0x00800000 0x01100000' GuruPlug>> boot (Re)start USB... USB: Register 10011 NbrPorts 1 USB EHCI 1.00 scanning bus for devices... 4 USB Device(s) found scanning bus for storage devices... Device NOT ready Request Sense returned 02 3A 00 2 Storage Device(s) found Loading file "uinitrd-kirkwood" from usb device 1:1 (usbdb1) -------------------------------------------------- (.... this is taking a while.... minutes later and USB stick still blinking... It didnt take this long to "fatload".... DONE finally! - fatload was pretty instantaneous) -------------------------------------------------- 7700860 bytes read Loading file "/uImage-kirkwood" from usb device 1:1 (usbdb1) 2056040 bytes read ## Booting kernel from Legacy Image at 00800000 ... Image Name: Linux-2.6.33.4-kirkwood Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2055976 Bytes = 2 MB 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: 7700796 Bytes = 7.3 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [ 0.000000] Linux version 2.6.33.4-kirkwood (root at wizbit) (gcc version 4.4.4 (GCC) ) #2 PREEMPT Wed May 19 11:14:40 BST 2010 [ 0.000000] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977 [ 0.000000] CPU: VIVT data cache, VIVT instruction cache [ 0.000000] Machine: Marvell GuruPlug Reference Board ------------------------------------------------------------ fatload takes seconds compared to ext2load. I timed a reboot root at mary:~# date # ext2load start Mon May 24 00:51:29 EDT 2010 root at mary:~# date # ext2load finish Mon May 24 00:54:07 EDT 2010 root at mary:~# This makes for a long boot time. Why am I getting these UDEV errors during the init? ------------------------------------------------------------- Going multiuser... Updating shared library links: /sbin/ldconfig & cannot (un)set powersave mode udevd[976]: bind failed: Address already in use udevd[976]: error binding control socket, seems udevd is already running Triggering udev events: /sbin/udevadm trigger --type=failed /etc/rc.d/rc.inet1: /sbin/ifconfig lo 127.0.0.1 /etc/rc.d/rc.inet1: /sbin/route add -net 127.0.0.0 netmask 255.0.0.0 lo ---------------------------------------------------------------- Is this because udev is already started in the initrd? (I am only guessing) SWEET! I can use Slackware now! Thanks Stuart!!!! John -- === Never ask a geek why, just nod your head and slowly back away.=== +================================+==================================+ | John O'Donnell | | | (Sr. Systems Engineer, | http://juanisan.homeip.net | | Net Admin, Programmer, etc.) | E-Mail: unixjohn1969 at gmail.com | +================================+==================================+ No man is useless who has a friend, and if we are loved we are indispensable. -- Robert Louis Stevenson From unixjohn1969 at gmail.com Mon May 24 05:13:35 2010 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Mon, 24 May 2010 01:13:35 -0400 Subject: [ARMedslack] guruplug kernel panic on reboot In-Reply-To: References: <4BF6EAC0.4060903@gmail.com> <4BF83330.6050000@gmail.com> Message-ID: <4BFA0AFF.60305@gmail.com> I consistently get a NON FATAL panic on shutting down... root at guruslack:~# init 6 INIT: Sending processes the TERM signal INIT: SRunning shutdown script /etc/rc.d/rc.6: Saving system time to the hardware clock (localtime). Stopping system message bus... Unmounting remote filesystems. /etc/rc.d/rc.inet1: /sbin/route del default /etc/rc.d/rc.inet1: /sbin/dhcpcd -k -d eth0 /etc/rc.d/rc.inet1: /sbin/ifconfig eth1 down /etc/rc.d/rc.inet1: /sbin/ifconfig lo down [ 486.999664] default_device_exit: failed to move eth0 to init_net: -22 [ 487.011094] kernel BUG at net/core/dev.c:5805! [ 487.015637] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 487.023769] pgd = c0004000 [ 487.026569] [00000000] *pgd=00000000 [ 487.030171] Internal error: Oops: 817 [#1] PREEMPT [ 487.034983] last sysfs file: /sys/devices/platform/orion-ehci.0/usb1/1-1/1-1.3/1-1.3:1.0/host2/target2:0:0 /2:0:0:0/block/sdc/size [ 487.046683] Modules linked in: ipv6 uap8xxx libertas_sdio libertas btmrvl_sdio btmrvl cfg80211 bluetooth l ib80211 rfkill mv_cesa aes_generic mvsdio nfs lockd nfs_acl auth_rpcgss sunrpc mv643xx_eth fscache xfs jfs re iserfs ext4 ext3 ext2 mbcache dm_mod md_mod exportfs jbd2 jbd vfat fat ums_onetouch ums_jumpshot ums_alauda u ms_sddr55 ums_sddr09 ums_isd200 ums_freecom ums_usbat ums_cypress usb_storage usb_libusual ohci_hcd usbhid hi d uhci_hcd ehci_hcd usbcore nls_base sata_mv libata mmc_block mmc_core scsi_tgt sr_mod cdrom sd_mod crc_t10di f sg scsi_mod [ 487.096085] CPU: 0 Not tainted (2.6.33.4-kirkwood #2) [ 487.101514] PC is at __bug+0x18/0x24 [ 487.105109] LR is at __bug+0x14/0x24 [ 487.108704] pc : [] lr : [] psr: 60000013 [ 487.108710] sp : df851f28 ip : 00000000 fp : df801f28 [ 487.120246] r10: 00000000 r9 : c025f9bc r8 : c03f6868 [ 487.125496] r7 : df851f30 r6 : c045cf88 r5 : dfefe000 r4 : dfeb6000 [ 487.132054] r3 : 00000000 r2 : df851f1c r1 : c036da51 r0 : 00000038 [ 487.138613] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 487.145954] Control: 0005397f Table: 1e1a4000 DAC: 00000017 [ 487.151726] Process netns (pid: 9, stack limit = 0xdf850270) [ 487.157411] Stack: (0xdf851f28 to 0xdf852000) [ 487.161794] 1f20: dfeb6000 c0265dc4 32766564 bf5b8a00 c045cf50 df851f68 [ 487.170018] 1f40: c03f686c c03f6ad8 c045cf50 df851f68 c03f686c c025f184 c03f6ad8 c03f684c [ 487.178240] 1f60: c03fc620 c025facc c045cf64 c045cf64 c045cf5c c045cf5c df850000 df801f20 [ 487.186463] 1f80: c03fc620 c005bd94 00000000 00000000 00000ed3 00000000 df838b00 c005fdfc [ 487.194686] 1fa0: df851fa0 df851fa0 df801f20 df823f00 df851fd4 c005bb8c df801f20 00000000 [ 487.202908] 1fc0: 00000000 00000000 00000000 c005f990 00000000 00000000 df851fd8 df851fd8 [ 487.211131] 1fe0: 00000000 00000000 00000000 00000000 00000000 c0028a74 00000000 00000000 [ 487.219369] [] (__bug+0x18/0x24) from [] (default_device_exit+0x84/0xc0) [ 487.227852] [] (default_device_exit+0x84/0xc0) from [] (ops_exit_list+0x2c/0x60) [ 487.237032] [] (ops_exit_list+0x2c/0x60) from [] (cleanup_net+0x110/0x1b8) [ 487.245696] [] (cleanup_net+0x110/0x1b8) from [] (worker_thread+0x208/0x2cc) [ 487.254533] [] (worker_thread+0x208/0x2cc) from [] (kthread+0x78/0x80) [ 487.262842] [] (kthread+0x78/0x80) from [] (kernel_thread_exit+0x0/0x8) [ 487.271239] Code: e1a01000 e59f000c eb0ad9ea e3a03000 (e5833000) [ 487.277443] ---[ end trace e460593696c3f9b5 ]--- Saving random seed from /dev/urandom in /etc/random-seed. Turning off swap. Unmounting local file systems. tmpfs umounted usbfs umounted /dev/sdc3 umounted Remounting root filesystem read-only. /dev/sdc3 on / type ext3 (ro) Rebooting. [ 502.194555] md: stopping all md devices. [ 503.199417] Restarting system. U-Boot 2010.03-01266-g42f7128-dirty (Mai 12 2010 - 13:28:48) Marvell-GuruPlug (-: flipflip's version 20100512 :-) SoC: Kirkwood 88F6281_A0 DRAM: 512 MB NAND: 512 MiB In: serial Out: serial Err: serial Net: egiga0, egiga1 88E1121 Initialized on egiga0 88E1121 Initialized on egiga1 Hit any key to stop autoboot: 0 GuruPlug>> -- === 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 Mon May 24 11:29:05 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Mon, 24 May 2010 12:29:05 +0100 (BST) Subject: [ARMedslack] guruplug update In-Reply-To: <4BFA09BC.4000509@gmail.com> References: <4BF6EAC0.4060903@gmail.com> <4BF83330.6050000@gmail.com> <4BFA09BC.4000509@gmail.com> Message-ID: > (.... this is taking a while.... > minutes later and USB stick still blinking... > It didnt take this long to "fatload".... > DONE finally! - fatload was pretty instantaneous) I don't know about that. The only problems I have seen are with u-boot's USB support being hit and miss -- sometimes it'd find the device, others not; but on both of my SheevaPlugs with USB, they boot very quickly using ext2load. I'd keep an eye on plugcomputer.org for Guruplug u-boot posts. I'm sure you won't be the only person who's going to have a problem. As with the Sheevaplug, someone hopefully will come up with a decent u-boot patch set and produce a binary. > ------------------------------------------------------------- > Going multiuser... > Updating shared library links: /sbin/ldconfig & > cannot (un)set powersave mode Apparently this is because of setterm: http://www.linuxquestions.org/questions/slackware-14/screen-blanking-out-582748/ > udevd[976]: error binding control socket, seems udevd is already running > > > Triggering udev events: /sbin/udevadm trigger --type=failed > /etc/rc.d/rc.inet1: /sbin/ifconfig lo 127.0.0.1 > /etc/rc.d/rc.inet1: /sbin/route add -net 127.0.0.0 netmask 255.0.0.0 lo > ---------------------------------------------------------------- > > Is this because udev is already started in the initrd? (I am only guessing) Yes it's started from initrd in order to populate /dev and pivot into the OS and continue from there. Before "/init" from the initrd exists, it tries to kill udevd so that the copy on the OS can be loaded. I haven't seen a case on my machines where this doesn't work. If you comment out the "setterm" line in rc.M, I wonder if that fixes the udev problem? -- Stuart Winter Slackware ARM: www.armedslack.org From unixjohn1969 at gmail.com Mon May 24 18:14:17 2010 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Mon, 24 May 2010 14:14:17 -0400 Subject: [ARMedslack] guruplug update In-Reply-To: References: <4BF6EAC0.4060903@gmail.com> <4BF83330.6050000@gmail.com> <4BFA09BC.4000509@gmail.com> Message-ID: <4BFAC1F9.4050003@gmail.com> Stuart Winter wrote: >> (.... this is taking a while.... >> minutes later and USB stick still blinking... >> It didnt take this long to "fatload".... >> DONE finally! - fatload was pretty instantaneous) > > I don't know about that. > The only problems I have seen are with u-boot's USB support being hit and > miss -- sometimes it'd find the device, others not; but on both of my > SheevaPlugs with USB, they boot very quickly using ext2load. > > I'd keep an eye on plugcomputer.org for Guruplug u-boot posts. I'm sure > you won't be the only person who's going to have a problem. As with the > Sheevaplug, someone hopefully will come up with a decent u-boot patch set > and produce a binary. Well when I'm finished with the thing, I'll have a JFFS2 (or UBI) fs flashed and I'll be loading from nand. But I wanted to let you know what I saw. >> ------------------------------------------------------------- >> Going multiuser... >> Updating shared library links: /sbin/ldconfig & >> cannot (un)set powersave mode > > Apparently this is because of setterm: > http://www.linuxquestions.org/questions/slackware-14/screen-blanking-out-582748/ Oh! I never thought about that. I thought it was a CPU setting thing. I wasnt actually asking about that but the next thing.... >> udevd[976]: error binding control socket, seems udevd is already running >> >> >> Triggering udev events: /sbin/udevadm trigger --type=failed >> /etc/rc.d/rc.inet1: /sbin/ifconfig lo 127.0.0.1 >> /etc/rc.d/rc.inet1: /sbin/route add -net 127.0.0.0 netmask 255.0.0.0 lo >> ---------------------------------------------------------------- >> >> Is this because udev is already started in the initrd? (I am only guessing) > > Yes it's started from initrd in order to populate /dev and pivot into > the OS and continue from there. > Before "/init" from the initrd exists, it tries to kill udevd so that the > copy on the OS can be loaded. > > I haven't seen a case on my machines where this doesn't work. > If you comment out the "setterm" line in rc.M, I wonder if that fixes the > udev problem? This probably wont concern me then as my goal is to boot directly to the root FS without initrd with a custom kernel. But again. Just wanted to give you feedback on what I saw with 13.1. Thanks John -- === Never ask a geek why, just nod your head and slowly back away.=== +================================+==================================+ | John O'Donnell | | | (Sr. Systems Engineer, | http://juanisan.homeip.net | | Net Admin, Programmer, etc.) | E-Mail: unixjohn1969 at gmail.com | +================================+==================================+ No man is useless who has a friend, and if we are loved we are indispensable. -- Robert Louis Stevenson From m-lists at biscuit.org.uk Mon May 24 20:06:29 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Mon, 24 May 2010 21:06:29 +0100 (BST) Subject: [ARMedslack] guruplug update In-Reply-To: <4BFAC1F9.4050003@gmail.com> References: <4BF6EAC0.4060903@gmail.com> <4BF83330.6050000@gmail.com> <4BFA09BC.4000509@gmail.com> <4BFAC1F9.4050003@gmail.com> Message-ID: > > you won't be the only person who's going to have a problem. As with the > > Sheevaplug, someone hopefully will come up with a decent u-boot patch set > > and produce a binary. > > Well when I'm finished with the thing, I'll have a JFFS2 (or UBI) fs flashed > and I'll be loading from nand. But I wanted to let you know what I saw. You might want to try this u-boot: http://people.debian.org/~schizo/guruplug/u-boot.kwb-42f7128c1a4b3bfcb97a12df0c764efe439b5bbd This was posted on debian-arm today, and apparently was built from good sources. > > > > Apparently this is because of setterm: > > http://www.linuxquestions.org/questions/slackware-14/screen-blanking-out-582748/ > > Oh! I never thought about that. Me neither -- I was surprised when I saw the answer. I have never seen this problem on the SheevaPlug, Versatile or OpenRD client. > > If you comment out the "setterm" line in rc.M, I wonder if that fixes the > > udev problem? > > This probably wont concern me then as my goal is to boot directly to the root > FS without initrd with a custom kernel. But again. Just wanted to give you > feedback on what I saw with 13.1. Thanks -- I don't think your Guruplug experience is going to be isolated to you, so it's good to get a heads up in advance. I don't plan to release Slackware ARM 13.1 until the 1st week of June, so there's still a bit of time left to do something with the Guruplug. I'm curious whether linux 2.6.34 would work for you, if you can get the guruplug patches to apply. I don't know of anything in the kirkwood kernel included in Slackware ARm that would cause the problem you see on the Guruplug though; but if you have a different experience using the same kernel sources but with a different .config, that would be interesting. -- Stuart Winter Slackware ARM: www.armedslack.org From atelszewski at gmail.com Tue May 25 19:38:31 2010 From: atelszewski at gmail.com (Andrzej Telszewski) Date: Tue, 25 May 2010 21:38:31 +0200 Subject: [ARMedslack] armedslack & experimental kernel options In-Reply-To: References: <4BF6EAC0.4060903@gmail.com> Message-ID: <4BFC2737.2090702@gmail.com> >> By the way, in few days I'm going to try 13.1rc1 on my board so I let >> you know "how and if" it works;) > > Great thanks. > > > It seems that because of my job I won't be able to check 13.1 on my board before release:/ But I'll surely do it one time - then I'll have got official kernel .config and basing on it I'll prepare one that suits my board and then let you know how all these things work together. -- Best regards, AT From rw at rlworkman.net Wed May 26 06:16:29 2010 From: rw at rlworkman.net (Robby Workman) Date: Wed, 26 May 2010 01:16:29 -0500 Subject: [ARMedslack] guruplug In-Reply-To: References: <4BF6EAC0.4060903@gmail.com> <4BF83330.6050000@gmail.com> Message-ID: <20100526011629.676ec73b@liberty.rlwhome.lan> On Sat, 22 May 2010 22:14:33 +0100 (BST) Stuart Winter wrote: > > I guess we need to change /boot to a FAT partition!?! > > I'd look around and ask on the plug web site about it before > making such a choice; I'm shocked to see ext2 filesystem support > missing. > > The Kernel package won't install properly to a FAT filesystem /boot > because the "uImage-" file names are symlinks to a > version-named kernel file. > > You could still work around this manually in the installer, but > I'd wait to find out why ext2 support is missing first. Well, I guess if I/we can ever get this ubootconfig project in a working state, it could use the full filename of the kernel image. That would require one to run ubootconfig after every kernel upgrade, which considering that we're used to this anyway with lilo, might not be such a big deal... -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From unixjohn1969 at gmail.com Wed May 26 06:51:29 2010 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Wed, 26 May 2010 02:51:29 -0400 Subject: [ARMedslack] guruplug In-Reply-To: <20100526011629.676ec73b@liberty.rlwhome.lan> References: <4BF6EAC0.4060903@gmail.com> <4BF83330.6050000@gmail.com> <20100526011629.676ec73b@liberty.rlwhome.lan> Message-ID: <4BFCC4F1.2060302@gmail.com> Robby Workman wrote: > On Sat, 22 May 2010 22:14:33 +0100 (BST) > Stuart Winter wrote: > >>> I guess we need to change /boot to a FAT partition!?! >> I'd look around and ask on the plug web site about it before >> making such a choice; I'm shocked to see ext2 filesystem support >> missing. >> >> The Kernel package won't install properly to a FAT filesystem /boot >> because the "uImage-" file names are symlinks to a >> version-named kernel file. >> >> You could still work around this manually in the installer, but >> I'd wait to find out why ext2 support is missing first. > > > Well, I guess if I/we can ever get this ubootconfig project > in a working state, it could use the full filename of the > kernel image. That would require one to run ubootconfig after > every kernel upgrade, which considering that we're used to this > anyway with lilo, might not be such a big deal... > > -RW Actually it works fine under FAT. Lickety split too. Its not the same as ext with the sym links. But it works great - booted many times over the last few days. Works much faster than the ext2load I tried recently. I have questions still for Stuart. I tried compiling a kernel with the config from /kernels/kirkwood I want to use this as a reference to start trimming down what I do not need for my project. I am compiling it right on the plug itself. I get a uImage that doesnt match in byte size (but it is close) and will not boot. When booting my uImage-jjo it says Uncompressing and hangs instead of the uImage-kirkwood. Am I missing any patches? John -- === Never ask a geek why, just nod your head and slowly back away.=== +================================+==================================+ | John O'Donnell | | | (Sr. Systems Engineer, | http://juanisan.homeip.net | | Net Admin, Programmer, etc.) | E-Mail: unixjohn1969 at gmail.com | +================================+==================================+ No man is useless who has a friend, and if we are loved we are indispensable. -- Robert Louis Stevenson From m-lists at biscuit.org.uk Wed May 26 07:53:34 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Wed, 26 May 2010 08:53:34 +0100 (BST) Subject: [ARMedslack] guruplug In-Reply-To: <4BFCC4F1.2060302@gmail.com> References: <4BF6EAC0.4060903@gmail.com> <4BF83330.6050000@gmail.com> <20100526011629.676ec73b@liberty.rlwhome.lan> <4BFCC4F1.2060302@gmail.com> Message-ID: > > Well, I guess if I/we can ever get this ubootconfig project in a working > > state, it could use the full filename of the kernel image. I hadn't thought of that; I think it's a good idea. > for my project. I am compiling it right on the plug itself. I get a uImage > that doesnt match in byte size (but it is close) and will not boot. When > booting my uImage-jjo it says Uncompressing and hangs instead of the > uImage-kirkwood. Am I missing any patches? All of the patches applied are in the tree: ftp://ftp.armedslack.org/armedslack/armedslack-current/source/k/sources/linux-2.6/patches/ Also, if you upgrade to the latest k/kernel-source package, you'll have a fully patched /usr/src/linux tree that was used to build the "kirkwood" kernel. If you have applied those patches already, and your uImage file is *larger* than the one in AS, then what's likely the problem is that your kernel is simply too large (which is one of the reasons why I moved from monolithic to modular kernels). In this case you can either review what you're compiling in, or adjust the memory locations you load the kernel into (the 0x200000 type numbers in the INSTALL_KIRKWOOD doc). I copied some settings I found on the plugcomputer.org forum for larger kernels, so I can't help a lot there because I didn't take time to figure out how the new numbers were generated. -- Stuart Winter Slackware ARM: www.armedslack.org From thierry.merle at free.fr Wed May 26 19:33:02 2010 From: thierry.merle at free.fr (Thierry Merle) Date: Wed, 26 May 2010 21:33:02 +0200 Subject: [ARMedslack] guruplug In-Reply-To: <4BFCC4F1.2060302@gmail.com> References: <4BF6EAC0.4060903@gmail.com> <4BF83330.6050000@gmail.com> <20100526011629.676ec73b@liberty.rlwhome.lan> <4BFCC4F1.2060302@gmail.com> Message-ID: <20100526213302.626ddff9@gorbag.houroukhai.org> Hi John, Le Wed, 26 May 2010 02:51:29 -0400, John O'Donnell a ?crit : > Robby Workman wrote: > > On Sat, 22 May 2010 22:14:33 +0100 (BST) > > Stuart Winter wrote: > > > >>> I guess we need to change /boot to a FAT partition!?! > >> I'd look around and ask on the plug web site about it before > >> making such a choice; I'm shocked to see ext2 filesystem support > >> missing. > >> > >> The Kernel package won't install properly to a FAT filesystem /boot > >> because the "uImage-" file names are symlinks to a > >> version-named kernel file. > >> > >> You could still work around this manually in the installer, but > >> I'd wait to find out why ext2 support is missing first. > > I prefer the kernel+initrd to be written in flash. This does not require any u-boot upgrade, and it is quite simple: flash_erase /dev/mtdblock1 flash_eraseall /dev/mtd1 flash_erase /dev/mtdblock2 flash_eraseall /dev/mtd2 cat uImage-kirkwood > /dev/mtdblock1 cat uinitrd-kirkwood > /dev/mtdblock2 > > > > Well, I guess if I/we can ever get this ubootconfig project > > in a working state, it could use the full filename of the > > kernel image. That would require one to run ubootconfig after > > every kernel upgrade, which considering that we're used to this > > anyway with lilo, might not be such a big deal... > > > > -RW > FYI, fw_printenv/fw_saveenv should work with this /etc/fw_env.config: # Configuration file for fw_(printenv/saveenv) utility. # Up to two entries are valid, in this case the redundand # environment sector is assumed present. # MTD device name Device offset Env. size Flash sector size /dev/mtd0 0xA0000 0x20000 0x20000 Works for me on the sheevaplug. Hope this helps... Thierry From thierry.merle at free.fr Wed May 26 21:47:51 2010 From: thierry.merle at free.fr (Thierry Merle) Date: Wed, 26 May 2010 23:47:51 +0200 Subject: [ARMedslack] guruplug In-Reply-To: <20100526213302.626ddff9@gorbag.houroukhai.org> References: <4BF6EAC0.4060903@gmail.com> <4BF83330.6050000@gmail.com> <20100526011629.676ec73b@liberty.rlwhome.lan> <4BFCC4F1.2060302@gmail.com> <20100526213302.626ddff9@gorbag.houroukhai.org> Message-ID: <20100526234751.29b0253a@gorbag.houroukhai.org> Le Wed, 26 May 2010 21:33:02 +0200, Thierry Merle a ?crit : > Hi John, > > Le Wed, 26 May 2010 02:51:29 -0400, > John O'Donnell a ?crit : > > > Robby Workman wrote: > > > On Sat, 22 May 2010 22:14:33 +0100 (BST) > > > Stuart Winter wrote: > > > > > >>> I guess we need to change /boot to a FAT partition!?! > > >> I'd look around and ask on the plug web site about it before > > >> making such a choice; I'm shocked to see ext2 filesystem support > > >> missing. > > >> > > >> The Kernel package won't install properly to a FAT > > >> filesystem /boot because the "uImage-" file names are > > >> symlinks to a version-named kernel file. > > >> > > >> You could still work around this manually in the installer, but > > >> I'd wait to find out why ext2 support is missing first. > > > > I prefer the kernel+initrd to be written in flash. This > does not require any u-boot upgrade, and it is quite simple: > flash_erase /dev/mtdblock1 > flash_eraseall /dev/mtd1 > flash_erase /dev/mtdblock2 > flash_eraseall /dev/mtd2 > cat uImage-kirkwood > /dev/mtdblock1 > cat uinitrd-kirkwood > /dev/mtdblock2 > > > > > > > Well, I guess if I/we can ever get this ubootconfig project > > > in a working state, it could use the full filename of the > > > kernel image. That would require one to run ubootconfig after > > > every kernel upgrade, which considering that we're used to this > > > anyway with lilo, might not be such a big deal... > > > > > > -RW > > > FYI, fw_printenv/fw_saveenv should work with > this /etc/fw_env.config: > # Configuration file for fw_(printenv/saveenv) utility. > # Up to two entries are valid, in this case the redundand > # environment sector is assumed present. > > # MTD device name Device offset Env. size Flash sector > size /dev/mtd0 0xA0000 0x20000 0x20000 > Works for me on the sheevaplug. > Well, I found the "Device offset" parameter by chance (looking at each sector beginning in flash); the best way is to look at the documentation. SheevaPlug DevKit Reference Design-Rev1.2.pdf states that UBOOT_IMAGE_ENV is at 0xA0000. For the guruplug, this offset is at 0x40000, something that should be found in guruplug documentation that I don't have. Thierry From m-lists at biscuit.org.uk Thu May 27 10:05:21 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Thu, 27 May 2010 11:05:21 +0100 (BST) Subject: [ARMedslack] armedslack & experimental kernel options In-Reply-To: <4BFC2737.2090702@gmail.com> References: <4BF6EAC0.4060903@gmail.com> <4BFC2737.2090702@gmail.com> Message-ID: > It seems that because of my job I won't be able to check 13.1 on my > board before release:/ But I'll surely do it one time - then I'll have > got official kernel .config and basing on it I'll prepare one that suits > my board and then let you know how all these things work together. OK. Cool. I have just removed those two experimental kernel options to do with containers, and am now building 2.6.33.5 and will push it out later today. From m-lists at biscuit.org.uk Sun May 30 10:17:37 2010 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sun, 30 May 2010 11:17:37 +0100 (BST) Subject: [ARMedslack] guruplug In-Reply-To: <4BFCC4F1.2060302@gmail.com> References: <4BF6EAC0.4060903@gmail.com> <4BF83330.6050000@gmail.com> <20100526011629.676ec73b@liberty.rlwhome.lan> <4BFCC4F1.2060302@gmail.com> Message-ID: > I have questions still for Stuart. > I tried compiling a kernel with the config from /kernels/kirkwood > I want to use this as a reference to start trimming down what I do not need > for my project. I am compiling it right on the plug itself. I get a uImage > that doesnt match in byte size (but it is close) and will not boot. When > booting my uImage-jjo it says Uncompressing and hangs instead of the > uImage-kirkwood. Am I missing any patches? Did you figure this out? When I upgraded to 2.6.33.5 the other day, I did what I always do: download the kernel into the tree extract it on an x86 box and run make ARCH=arm oldconfig copy that new config file over the original in the AS tree But because I hadn't applied the GuruPlug, eSata Sheevaplug & openRD patches, the support for those devices had been dropped from the new .config file. If you took a fresh kernel.org source archive, copied AS's config file without applying the patches first, then you're probably missing the Guruplug support from your kernel. -- Stuart Winter Slackware ARM: www.armedslack.org From rw at rlworkman.net Mon May 31 05:30:43 2010 From: rw at rlworkman.net (Robby Workman) Date: Mon, 31 May 2010 00:30:43 -0500 Subject: [ARMedslack] My experience with the GuruPlug Message-ID: <20100531003043.13d596ce@liberty.rlwhome.lan> Well, this has been a fun (and annoying) process... :-) Maybe there's some secret (or not so secret) info that I'm not finding, but I've thus far been unable to get any uboot build to successfully load kernel and initrd from a removable device. I've tried a usb stick and an mmc card, for what it's worth. I have a 4G minisd card in there, partitioned with sdb1 as a 100M fat32 and sdb2 as the remainder in ext4. I guess I should go back and try fat16 and such to see if that has better results, but for now, I *know* this arrangement works: I made the kernel and initrd images available via tftp and got them flashed to nand like this: Marvell>> tftp 0x6400000 uImage-kirkwood Using egiga0 device TFTP from server 192.168.13.11; our IP address is 192.168.13.50 Filename 'uImage-kirkwood'. Load address: 0x6400000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# #################### done Bytes transferred = 2096780 (1ffe8c hex) Marvell>> nand erase 0x100000 0x400000 NAND erase: device 0 offset 0x100000, size 0x400000 Erasing at 0x4e0000 -- 100% complete. OK Marvell>> nand write.e 0x6400000 0x100000 0x400000 NAND write: device 0 offset 0x100000, size 0x400000 4194304 bytes written: OK Marvell>> tftp 0x6400000 uinitrd-kirkwood Using egiga0 device TFTP from server 192.168.13.11; our IP address is 192.168.13.50 Filename 'uinitrd-kirkwood'. Load address: 0x6400000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ########### done Bytes transferred = 7706248 (759688 hex) Marvell>> nand erase 0x500000 0x1fb00000 NAND erase: device 0 offset 0x500000, size 0x1fb00000 Skipping bad block at 0x19ee0000 Erasing at 0x1ffe0000 -- 100% complete. OK Marvell>> nand write.e 0x6400000 0x500000 0x800000 NAND write: device 0 offset 0x500000, size 0x800000 8388608 bytes written: OK Now, let's verify that this did what I think it did: Marvell>> nand start Marvell>> nand read.e 0x00800000 0x100000 0x400000 Marvell>> nand read.e 0x01100000 0x500000 0x600000 Marvell>> iminfo 0x00800000 ## Checking Image at 00800000 ... Legacy image found Image Name: Linux-2.6.33.5-kirkwood Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2096716 Bytes = 2 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Marvell>> iminfo 0x01100000 ## Checking Image at 01100000 ... Legacy image found Image Name: Slackware ARM Initial RAM disk f Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 7706184 Bytes = 7.3 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Okay, both images look good - yay! Now here's the important bits from the uboot environment: Marvell>> printenv bootdelay=3 baudrate=115200 ethact=egiga0 eth1addr=02:50:43:eb:75:43 ethaddr=00:50:43:01:5D:EA arcNumber=2659 mainlineLinux=yes filesize=759688 fileaddr=6400000 ipaddr=192.168.13.50 serverip=192.168.13.11 stdin=serial stdout=serial stderr=serial bootargs_root=root=/dev/sdb2 waitforroot=10 rootfs=ext4 bootargs_console=console=ttyS0,115200 bootcmd_slack=bootm 0x00800000 0x01100000 bootcmd_usb=usb start; bootcmd=setenv bootargs $(bootargs_console) $(bootargs_root); run bootcmd_usb; run bootcmd_nand; run bootcmd_slack; bootcmd_nand=nand start; nand read.e 0x00800000 0x100000 0x400000; nand read.e 0x01100000 0x500000 0x800000 Environment size: 629/131068 bytes Note that putting the initrd into nand like this WILL kill the jffs2 root filesystem shipped with the guruplug. FWIW, I'm also getting the stacktrace on halt/reboot: The system is going down for reboot NOW! INIT: Sending processes the TERM signal INIT: SendingRunning shutdown script /etc/rc.d/rc.6: Saving system time to the hardware clock (UTC). Stopping system message bus... Unmounting remote filesystems. [ 112.344583] default_device_exit: failed to move eth0 to init_net: -22 [ 112.356199] kernel BUG at net/core/dev.c:5805! [ 112.360745] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 112.368881] pgd = c0004000 [ 112.371676] [00000000] *pgd=00000000 [ 112.375283] Internal error: Oops: 817 [#1] PREEMPT [ 112.380094] last sysfs file: /sys/devices/platform/orion-ehci.0/usb1/1-1/1-1.1/1-1.1:1.0/host1/target1:0:0/1:0:0:1/block/sdb/size [ 112.391794] Modules linked in: ipv6 nls_utf8 nls_cp437 fuse uap8xxx libertas_sdio btmrvl_sdio libertas btmrvl bluetooth cfg80211 rfkill lib80211 mv_cesa aes_generic mvsdio nfs lockd nfs_acl auth_rpcgss sunrpc mv643xx_eth fscache xfs jfs reiserfs ext4 ext3 ext2 mbcache dm_mod md_mod exportfs jbd2 jbd vfat fat ums_onetouch ums_jumpshot ums_alauda ums_sddr55 ums_sddr09 ums_isd200 ums_freecom ums_usbat ums_cypress usb_storage usb_libusual ohci_hcd usbhid hid uhci_hcd ehci_hcd usbcore nls_base sata_mv libata mmc_block mmc_core scsi_tgt sr_mod cdrom sd_mod crc_t10dif sg scsi_mod [ 112.443316] CPU: 0 Not tainted (2.6.33.5-kirkwood #2) [ 112.448744] PC is at __bug+0x18/0x24 [ 112.452340] LR is at __bug+0x14/0x24 [ 112.455935] pc : [] lr : [] psr: 60000013 [ 112.455940] sp : df851f28 ip : 00000000 fp : df801f28 [ 112.467477] r10: 00000000 r9 : c0267860 r8 : c040cc68 [ 112.472727] r7 : df851f30 r6 : c04736c8 r5 : dfd3e000 r4 : dfeb6000 [ 112.479284] r3 : 00000000 r2 : df851f1c r1 : c0381b51 r0 : 00000038 [ 112.485843] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 112.493184] Control: 0005397f Table: 1e014000 DAC: 00000017 [ 112.498957] Process netns (pid: 9, stack limit = 0xdf850270) [ 112.504642] Stack: (0xdf851f28 to 0xdf852000) [ 112.509024] 1f20: dfeb6000 c026dc68 32766564 bf5a1a00 c0473690 df851f68 [ 112.517248] 1f40: c040cc6c c040ced8 c0473690 df851f68 c040cc6c c0267028 c040ced8 c040cc4c [ 112.525471] 1f60: c0412d60 c0267970 c04736a4 c04736a4 c047369c c047369c df850000 df801f20 [ 112.533693] 1f80: c0412d60 c005bc90 00000000 00000000 00000e88 00000000 df838b00 c005fcb4 [ 112.541917] 1fa0: df851fa0 df851fa0 df801f20 df823f00 df851fd4 c005ba88 df801f20 00000000 [ 112.550139] 1fc0: 00000000 00000000 00000000 c005f848 00000000 00000000 df851fd8 df851fd8 [ 112.558362] 1fe0: 00000000 00000000 00000000 00000000 00000000 c0028a74 0000ffff 0000ffff [ 112.566593] [] (__bug+0x18/0x24) from [] (default_device_exit+0x84/0xc0) [ 112.575084] [] (default_device_exit+0x84/0xc0) from [] (ops_exit_list+0x2c/0x60) [ 112.584263] [] (ops_exit_list+0x2c/0x60) from [] (cleanup_net+0x110/0x1b8) [ 112.592927] [] (cleanup_net+0x110/0x1b8) from [] (worker_thread+0x208/0x2cc) [ 112.601765] [] (worker_thread+0x208/0x2cc) from [] (kthread+0x78/0x80) [ 112.610072] [] (kthread+0x78/0x80) from [] (kernel_thread_exit+0x0/0x8) [ 112.618469] Code: e1a01000 e59f000c eb0b13a2 e3a03000 (e5833000) [ 112.624677] ---[ end trace 5962ca148b8ec255 ]--- Saving random seed from /dev/urandom in /etc/random-seed. Turning off swap. Unmounting local file systems. tmpfs umounted tmpfs umounted /dev/sdb1 umounted usbfs umounted /dev/sdb2 umounted Remounting root filesystem read-only. /dev/sdb2 on / type ext4 (ro) Rebooting. Anyway, it's up and running now, even though I guess I'll have to use the JTAG console on any kernel upgrades :/ root at guruplug:~# uname -a Linux guruplug 2.6.33.5-kirkwood #2 PREEMPT Thu May 27 14:47:11 BST 2010 armv5tel Feroceon 88FR131 rev 1 (v5l) Marvell GuruPlug Reference Board GNU/Linux root at guruplug:~# mount /dev/sdb2 on / type ext4(rw,relatime,barrier=1,data=ordered) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) usbfs on /proc/bus/usb type usbfs (rw) /dev/sdb1 on /boot type vfat (rw) tmpfs on /dev/shm type tmpfs (rw) tmpfs on /tmp type tmpfs (rw) -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From thierry.merle at free.fr Mon May 31 08:15:48 2010 From: thierry.merle at free.fr (Thierry Merle) Date: Mon, 31 May 2010 10:15:48 +0200 Subject: [ARMedslack] My experience with the GuruPlug In-Reply-To: <20100531003043.13d596ce@liberty.rlwhome.lan> References: <20100531003043.13d596ce@liberty.rlwhome.lan> Message-ID: <20100531101548.75d3445a@gorbag.houroukhai.org> Le Mon, 31 May 2010 00:30:43 -0500, Robby Workman a ?crit : > Well, this has been a fun (and annoying) process... :-) > [..] > > FWIW, I'm also getting the stacktrace on halt/reboot: > > The system is going down for reboot NOW! > INIT: Sending processes the TERM signal > INIT: SendingRunning shutdown script /etc/rc.d/rc.6: > Saving system time to the hardware clock (UTC). > Stopping system message bus... > Unmounting remote filesystems. > [ 112.344583] default_device_exit: failed to move eth0 to init_net: > -22 [ 112.356199] kernel BUG at net/core/dev.c:5805! -EINVAL error return is the cause of the bug. dev/net/core.c for 2.6.33.5, in dev_change_net_namespace(): 5799 /* Push remaing network devices to init_net */ 5800 snprintf(fb_name, IFNAMSIZ, "dev%d", dev->ifindex); 5801 err = dev_change_net_namespace(dev, &init_net, fb_name); 5802 if (err) { 5803 printk(KERN_EMERG "%s: failed to move %s to init_net: %d\n", 5804 __func__, dev->name, err); 5805 BUG(); 5806 } dev_change_net_namespace returns EINVAL for some reason (probably something related to sysfs interaction). [..] > 5962ca148b8ec255 ]--- Saving random seed from /dev/urandom > in /etc/random-seed. Turning off swap. Unmounting local file systems. > tmpfs umounted tmpfs umounted /dev/sdb1 umounted usbfs > umounted /dev/sdb2 umounted Remounting root filesystem > read-only. /dev/sdb2 on / type ext4 (ro) Rebooting. > But finishes OK, so seems harmless. Did you try the latest kernel (2.6.34rc6-kirkwood)? > > Anyway, it's up and running now, even though I guess I'll have to use > the JTAG console on any kernel upgrades :/ > Why the JTAG? Each time I have to upgrade my kernel in flash, I use the running Armedslack system to re-generate the kernel+initrd uboot images. Then I write them into the right flash areas. Even if something needs to be changed in the uboot command line, you can use fw_printenv/fw_setenv from linux... I used only 1 time the JTAG with Openocd, this was when I erased the u-boot flash area by mistake (/dev/mtdblock0). Thierry