From unixjohn1969 at gmail.com Sun Dec 11 09:30:34 2011 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Sun, 11 Dec 2011 04:30:34 -0500 Subject: [ARMedslack] qemu memory limitation Message-ID: <4EE4783A.3080700@gmail.com> Stuart, I notice that the 256M memory limitation still exists in the qemu 1.0 latest release yet google's android qemu variant can go well above. If I have 8gigs of RAM, why cant I just create a X gig amount of ram disk and make that swap space (virtual RAM) within the qemu virtual machine... Wouldnt that still be faster? I havent tried this yet. I was wondering if you had. 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 Dec 12 22:48:34 2011 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Mon, 12 Dec 2011 22:48:34 +0000 (GMT) Subject: [ARMedslack] qemu memory limitation In-Reply-To: <4EE4783A.3080700@gmail.com> References: <4EE4783A.3080700@gmail.com> Message-ID: > I notice that the 256M memory limitation still exists in the qemu 1.0 latest > release yet google's android qemu variant can go well above. If I have 8gigs > of RAM, why cant I just create a X gig amount of ram disk and make that swap > space (virtual RAM) within the qemu virtual machine... Wouldnt that still be > faster? I havent tried this yet. I was wondering if you had. Nope. I use real machines -- give it a go though! It makes sense to me.. -- Stuart Winter Slackware ARM: www.armedslack.org From pr0f3ss0r1492 at yahoo.com Tue Dec 13 00:11:53 2011 From: pr0f3ss0r1492 at yahoo.com (Ottavio) Date: Tue, 13 Dec 2011 00:11:53 +0000 Subject: [ARMedslack] qemu memory limitation In-Reply-To: <4EE4783A.3080700@gmail.com> References: <4EE4783A.3080700@gmail.com> Message-ID: On 11 December 2011 09:30, John O'Donnell wrote: > ?If I have 8gigs of RAM, why cant I just create a X gig amount of ram disk > and make that swap space (virtual RAM) within the qemu virtual machine... Is there any real life ARM device that supports 8G RAM? -- Ottavio qemu-users: http://groups.yahoo.com/group/qemu-users/ From louigi600 at yahoo.it Tue Dec 13 08:06:25 2011 From: louigi600 at yahoo.it (Davide) Date: Tue, 13 Dec 2011 08:06:25 +0000 (GMT) Subject: [ARMedslack] qemu memory limitation In-Reply-To: References: <4EE4783A.3080700@gmail.com> Message-ID: <1323763585.60313.YahooMailNeo@web29713.mail.ird.yahoo.com> ARMv8 is supposed to support 64 bit addressing otherwise as far as I know all current ARM devices have sub 32 bit address space. Ciao for now David ________________________________ Da: Ottavio A: Slackware ARM port Inviato: Marted? 13 Dicembre 2011 1:11 Oggetto: Re: [ARMedslack] qemu memory limitation On 11 December 2011 09:30, John O'Donnell wrote: > ?If I have 8gigs of RAM, why cant I just create a X gig amount of ram disk > and make that swap space (virtual RAM) within the qemu virtual machine... Is there any real life ARM device that supports 8G RAM? -- Ottavio qemu-users: http://groups.yahoo.com/group/qemu-users/ _______________________________________________ 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 Tue Dec 13 08:14:32 2011 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Tue, 13 Dec 2011 03:14:32 -0500 Subject: [ARMedslack] qemu memory limitation In-Reply-To: References: <4EE4783A.3080700@gmail.com> Message-ID: <4EE70968.5090502@gmail.com> On 12/12/2011 07:11 PM, Ottavio wrote: > On 11 December 2011 09:30, John O'Donnell wrote: >> If I have 8gigs of RAM, why cant I just create a X gig amount of ram disk >> and make that swap space (virtual RAM) within the qemu virtual machine... > > Is there any real life ARM device that supports 8G RAM? I dont know. All I know is I need more than 512M. I am experimenting with QT. Compiling it on a current Sheeva/Guru plug takes 3 days with about 2gb of swap. If I can get more memory to toy with then it will make life so much easier. After I get my results, I will spend the 3 days to get a compile on hardware. 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 pr0f3ss0r1492 at yahoo.com Tue Dec 13 09:56:28 2011 From: pr0f3ss0r1492 at yahoo.com (Ottavio) Date: Tue, 13 Dec 2011 09:56:28 +0000 Subject: [ARMedslack] qemu memory limitation In-Reply-To: <4EE70968.5090502@gmail.com> References: <4EE4783A.3080700@gmail.com> <4EE70968.5090502@gmail.com> Message-ID: On 13 December 2011 08:14, John O'Donnell wrote: > On 12/12/2011 07:11 PM, Ottavio wrote: >> >> On 11 December 2011 09:30, John O'Donnell ?wrote: >>> >>> ?If I have 8gigs of RAM, why cant I just create a X gig amount of ram >>> disk >>> and make that swap space (virtual RAM) within the qemu virtual machine... >> >> >> Is there any real life ARM device that supports 8G RAM? > > > I dont know. ?All I know is I need more than 512M. ?I am experimenting with > QT. Compiling it on a current Sheeva/Guru plug takes 3 days with about 2gb > of swap. ?If I can get more memory to toy with then it will make life so > much easier. After I get my results, I will spend the 3 days to get a > compile on hardware. I see these two options in the qemu manual: -mem-path path Allocate guest RAM from a temporarily created file in path. -mem-prealloc Preallocate memory when using -mem-path. I have never tried. -- Ottavio qemu-users: http://groups.yahoo.com/group/qemu-users/ From unixjohn1969 at gmail.com Tue Dec 13 10:37:35 2011 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Tue, 13 Dec 2011 05:37:35 -0500 Subject: [ARMedslack] qemu memory limitation In-Reply-To: References: <4EE4783A.3080700@gmail.com> <4EE70968.5090502@gmail.com> Message-ID: <4EE72AEF.6040202@gmail.com> On 12/13/2011 04:56 AM, Ottavio wrote: >>>> If I have 8gigs of RAM, why cant I just create a X gig amount of ram >>>> disk >>>> and make that swap space (virtual RAM) within the qemu virtual machine... >>> >>> Is there any real life ARM device that supports 8G RAM? >> >> I dont know. All I know is I need more than 512M. I am experimenting with >> QT. Compiling it on a current Sheeva/Guru plug takes 3 days with about 2gb >> of swap. If I can get more memory to toy with then it will make life so >> much easier. After I get my results, I will spend the 3 days to get a >> compile on hardware. > > I see these two options in the qemu manual: > > -mem-path path > Allocate guest RAM from a temporarily created file in path. > -mem-prealloc > Preallocate memory when using -mem-path. > > I have never tried. hmmm nice find! I suspect these only affect main ram usage within the guest as such the 256M qemu limitation would still apply, but I'll give it a try! Thanks again! 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 jawkins at armedslack.org Tue Dec 13 11:52:59 2011 From: jawkins at armedslack.org (Jim Hawkins) Date: Tue, 13 Dec 2011 11:52:59 +0000 (GMT) Subject: [ARMedslack] qemu memory limitation In-Reply-To: <4EE72AEF.6040202@gmail.com> References: <4EE4783A.3080700@gmail.com> <4EE70968.5090502@gmail.com> <4EE72AEF.6040202@gmail.com> Message-ID: On Tue, 13 Dec 2011, John O'Donnell wrote: > On 12/13/2011 04:56 AM, Ottavio wrote: > > I see these two options in the qemu manual: > > > > -mem-path path > > Allocate guest RAM from a temporarily created file in path. > > -mem-prealloc > > Preallocate memory when using -mem-path. > > > > I have never tried. > > hmmm nice find! I suspect these only affect main ram usage within the guest > as such the 256M qemu limitation would still apply, but I'll give it a try! AIUI, the RAM limit in qemu is platform dependant. The versatilepb platform is limited to 256MB, but according to the following page, the vexpress-a9 platform supports up to 1GB RAM: https://wiki.linaro.org/PeterMaydell/QemuVersatileExpress Although it will probably will take a bit more effort to get working than just changing the machine type on the qemu command line. Cheers, Jim From m-lists at biscuit.org.uk Tue Dec 13 12:48:43 2011 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Tue, 13 Dec 2011 12:48:43 +0000 (GMT) Subject: [ARMedslack] qemu memory limitation In-Reply-To: References: <4EE4783A.3080700@gmail.com> <4EE70968.5090502@gmail.com> <4EE72AEF.6040202@gmail.com> Message-ID: > AIUI, the RAM limit in qemu is platform dependant. The versatilepb > platform is limited to 256MB, but according to the following > page, the vexpress-a9 platform supports up to 1GB RAM: > > https://wiki.linaro.org/PeterMaydell/QemuVersatileExpress > > Although it will probably will take a bit more effort to get working than > just changing the machine type on the qemu command line. I might look at this later and replace the Versatile support with the Versatile Express. After all, the only aim is to 'showcase' Slackware ARM without having any real ARM hardware (although the original reason was because my RiscPC broke down and I had no substitute). Perhaps when I've finished adding support for the Trimslice, I'll look at this. From sunsmoke at gmail.com Tue Dec 13 18:01:18 2011 From: sunsmoke at gmail.com (Greg Lim) Date: Tue, 13 Dec 2011 13:01:18 -0500 Subject: [ARMedslack] qemu memory limitation In-Reply-To: <4EE70968.5090502@gmail.com> References: <4EE4783A.3080700@gmail.com> <4EE70968.5090502@gmail.com> Message-ID: <33AB60D7-6A19-42F1-9E2C-DFDD407ADAC5@gmail.com> On Dec 13, 2011, at 3:14 AM, John O'Donnell wrote: > On 12/12/2011 07:11 PM, Ottavio wrote: >> On 11 December 2011 09:30, John O'Donnell wrote: >>> If I have 8gigs of RAM, why cant I just create a X gig amount of ram disk >>> and make that swap space (virtual RAM) within the qemu virtual machine... >> >> Is there any real life ARM device that supports 8G RAM? > > I dont know. All I know is I need more than 512M. I am experimenting with QT. Compiling it on a current Sheeva/Guru plug takes 3 days with about 2gb of swap. If I can get more memory to toy with then it will make life so much easier. After I get my results, I will spend the 3 days to get a compile on hardware. > > 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 > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack If you really need to speed up builds and you have a spare SATA port or 2, you could use one of these: http://www.acard.com.tw/english/fb01-product.jsp?idno_no=270&prod_no=ANS-9010&type1_title=%20Solid%20State%20Drive&type1_idno=13 I used one for a bit as swap/tmp/build space and it helped. -Greg Lim From m-lists at biscuit.org.uk Wed Dec 14 22:08:56 2011 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Wed, 14 Dec 2011 22:08:56 +0000 (GMT) Subject: [ARMedslack] qemu memory limitation In-Reply-To: References: <4EE4783A.3080700@gmail.com> <4EE70968.5090502@gmail.com> <4EE72AEF.6040202@gmail.com> Message-ID: > AIUI, the RAM limit in qemu is platform dependant. The versatilepb > platform is limited to 256MB, but according to the following > page, the vexpress-a9 platform supports up to 1GB RAM: > > https://wiki.linaro.org/PeterMaydell/QemuVersatileExpress > > Although it will probably will take a bit more effort to get working than > just changing the machine type on the qemu command line. So this one has no SCSI or IDE bus - just SD card. That limits it as far as Slackware is concerned :-( I don't want to trade RAM for a lack of addressable standard storage. -- Stuart Winter Slackware ARM: www.armedslack.org From m-lists at biscuit.org.uk Thu Dec 15 12:08:48 2011 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Thu, 15 Dec 2011 12:08:48 +0000 (GMT) Subject: [ARMedslack] Slackware ARM current is being re-based to armv5te Message-ID: Hi After about 5 months or more of on-off thought, I've decided to re-base Slackware ARM to be armv5te. This means that the old devices that any devices that have an armv4t CPU will need to use the armedslack-13.37 release. The reason for this is that: * Slackware ARM only provides kernels for systems that have an armv5t CPU * The critical mass of consumer products (such as Plug computers) have an armv5 CPU. Therefore it makes sense to support the vast majority and provide an optimised userland. So, if you want -current for your armv4t devices - you can grab it quickly before I begin uploading packages compiled for armv5te :-) I'm rebuilding the core packages first such as bash and glibc, and will upgrade the others gradually as they get updated in Slackware x86. Stuart. -- Stuart Winter Slackware ARM: www.armedslack.org From atelszewski at gmail.com Thu Dec 15 12:57:58 2011 From: atelszewski at gmail.com (Andrzej Telszewski) Date: Thu, 15 Dec 2011 13:57:58 +0100 Subject: [ARMedslack] Slackware ARM current is being re-based to armv5te In-Reply-To: References: Message-ID: <4EE9EED6.4070000@gmail.com> On 12/15/2011 01:08 PM, Stuart Winter wrote: > > Hi > > After about 5 months or more of on-off thought, I've decided to re-base > Slackware ARM to be armv5te. This means that the old devices that any > devices that have an armv4t CPU will need to use the armedslack-13.37 > release. > > The reason for this is that: > * Slackware ARM only provides kernels for systems that have an armv5t CPU > * The critical mass of consumer products (such as Plug computers) have an > armv5 CPU. > > Therefore it makes sense to support the vast majority and provide an > optimised userland. > > So, if you want -current for your armv4t devices - you can grab it quickly > before I begin uploading packages compiled for armv5te :-) > > I'm rebuilding the core packages first such as bash and glibc, and will > upgrade the others gradually as they get updated in Slackware x86. > > Stuart. > Hi, Are you able to post some benchmarks after the switch to armv5te? The stock x86 Slackware kernel is compiled for 486 and there are little voices around saying that compiling for newer arch gives big performance boost (or I might be missing something). So if you have enough time, please try to make some comparison and post the results. I guess the game isn't only about the kernel but also about user space tools. So maybe some video/audio encoding/decoding or some calculations tests? -- Best regards, Andrzej Telszewski From tylernt at gmail.com Thu Dec 15 15:17:52 2011 From: tylernt at gmail.com (Tyler T) Date: Thu, 15 Dec 2011 08:17:52 -0700 Subject: [ARMedslack] Slackware ARM current is being re-based to armv5te In-Reply-To: References: Message-ID: Sounds great! From unixjohn1969 at gmail.com Thu Dec 15 19:50:15 2011 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Thu, 15 Dec 2011 20:50:15 +0100 Subject: [ARMedslack] Slackware ARM current is being re-based to armv5te In-Reply-To: References: Message-ID: It makes no performance difference whatsoever. On Dec 15, 2011 10:26 AM, "Tyler T" wrote: > Sounds great! > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > -------------- next part -------------- An HTML attachment was scrubbed... URL: From atelszewski at gmail.com Thu Dec 15 22:53:26 2011 From: atelszewski at gmail.com (Andrzej Telszewski) Date: Thu, 15 Dec 2011 23:53:26 +0100 Subject: [ARMedslack] Slackware ARM current is being re-based to armv5te In-Reply-To: References: Message-ID: <4EEA7A66.5010009@gmail.com> On 12/15/2011 08:50 PM, John O'Donnell wrote: > It makes no performance difference whatsoever. Can you give some comparison? -- Best regards, Andrzej Telszewski From unixjohn1969 at gmail.com Thu Dec 15 23:10:31 2011 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Fri, 16 Dec 2011 00:10:31 +0100 Subject: [ARMedslack] Slackware ARM current is being re-based to armv5te In-Reply-To: <4EEA7A66.5010009@gmail.com> References: <4EEA7A66.5010009@gmail.com> Message-ID: My web site is down at the moment but I recompiled the core libraries and a few of the packages and ran cpu tests on sheevas, guruplug, and a seagate dockstar and posted the results with stock armedslack and the arm5te compiled version with no differences. On Dec 15, 2011 5:54 PM, "Andrzej Telszewski" wrote: > On 12/15/2011 08:50 PM, John O'Donnell wrote: > > It makes no performance difference whatsoever. > > Can you give some comparison? > > -- > Best regards, > Andrzej Telszewski > _______________________________________________ > ARMedslack mailing list > ARMedslack at lists.armedslack.org > http://lists.armedslack.org/mailman/listinfo/armedslack > -------------- next part -------------- An HTML attachment was scrubbed... URL: From atelszewski at gmail.com Thu Dec 15 23:32:54 2011 From: atelszewski at gmail.com (Andrzej Telszewski) Date: Fri, 16 Dec 2011 00:32:54 +0100 Subject: [ARMedslack] Slackware ARM current is being re-based to armv5te In-Reply-To: References: <4EEA7A66.5010009@gmail.com> Message-ID: <4EEA83A6.2050000@gmail.com> On 12/16/2011 12:10 AM, John O'Donnell wrote: > My web site is down at the moment but I recompiled the core libraries and a > few of the packages and ran cpu tests on sheevas, guruplug, and a seagate > dockstar and posted the results with stock armedslack and the arm5te > compiled version with no differences. If that's true, then the result of armedslack arch change to armv5te will be the decrease in supported boards only. I'm not insisting on the armv4te, but I have one board which is arm4te and it's nice to run Slack on it - but this platform is mostly for research and I use it very rarely (although I would like to see the next Slack with real-time (PREEMPT_RT) patch running on it;)). -- Best regards, Andrzej Telszewski From thenktor at gmail.com Fri Dec 16 07:21:31 2011 From: thenktor at gmail.com (Thorsten =?ISO-8859-1?B?TfxobGZlbGRlcg==?=) Date: Fri, 16 Dec 2011 08:21:31 +0100 Subject: [ARMedslack] Slackware ARM current is being re-based to armv5te In-Reply-To: References: <4EEA7A66.5010009@gmail.com> Message-ID: <20111216082131.590d6301@pinkfloyd.tm-net> Am Fri, 16 Dec 2011 00:10:31 +0100 schrieb "John O'Donnell" : > My web site is down at the moment but I recompiled the core libraries > and a few of the packages and ran cpu tests on sheevas, guruplug, and > a seagate dockstar and posted the results with stock armedslack and > the arm5te compiled version with no differences. What kind of tests? On x86 platform I could measure slight differences on audio/video decoding/encoding. -- Thorsten M?hlfelder Salix OS: www.salixos.org From unixjohn1969 at gmail.com Fri Dec 16 10:16:40 2011 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Fri, 16 Dec 2011 05:16:40 -0500 Subject: [ARMedslack] Slackware ARM current is being re-based to armv5te In-Reply-To: <20111216082131.590d6301@pinkfloyd.tm-net> References: <4EEA7A66.5010009@gmail.com> <20111216082131.590d6301@pinkfloyd.tm-net> Message-ID: <4EEB1A88.8070102@gmail.com> On 12/16/2011 02:21 AM, Thorsten M?hlfelder wrote: > Am Fri, 16 Dec 2011 00:10:31 +0100 > schrieb "John O'Donnell": > >> My web site is down at the moment but I recompiled the core libraries >> and a few of the packages and ran cpu tests on sheevas, guruplug, and >> a seagate dockstar and posted the results with stock armedslack and >> the arm5te compiled version with no differences. > > What kind of tests? On x86 platform I could measure slight differences > on audio/video decoding/encoding. Well you obviously wont be processing anything like that on these plugs without an FPU, but I attached all the CPU benchmarks. I cannot benchmark anything else as all the sdcards that I use to run the systems are different and all the boxes are different configurations. The dockstar, sheevas, and the guruplug are all the same CPU. Enjoy ;-) 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: benchmark-logs.tar.gz Type: application/gzip Size: 1494 bytes Desc: not available URL: From unixjohn1969 at gmail.com Fri Dec 16 10:20:46 2011 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Fri, 16 Dec 2011 05:20:46 -0500 Subject: [ARMedslack] Slackware ARM current is being re-based to armv5te In-Reply-To: <20111216082131.590d6301@pinkfloyd.tm-net> References: <4EEA7A66.5010009@gmail.com> <20111216082131.590d6301@pinkfloyd.tm-net> Message-ID: <4EEB1B7E.2030909@gmail.com> On 12/16/2011 02:21 AM, Thorsten M?hlfelder wrote: > Am Fri, 16 Dec 2011 00:10:31 +0100 > schrieb "John O'Donnell": > >> My web site is down at the moment but I recompiled the core libraries >> and a few of the packages and ran cpu tests on sheevas, guruplug, and >> a seagate dockstar and posted the results with stock armedslack and >> the arm5te compiled version with no differences. > > What kind of tests? On x86 platform I could measure slight differences > on audio/video decoding/encoding. > I forgot to include what I recompiled: root at mrlinux:/v/htdocs/guruplug# ls -lR armedslack-arm5te/ armedslack-arm5te/: total 2 drwxr-xr-x 2 root root 768 May 3 2011 a/ drwxr-xr-x 2 root root 96 May 3 2011 ap/ drwxr-xr-x 2 root root 328 May 3 2011 d/ drwxr-xr-x 2 root root 1136 May 3 2011 l/ drwxr-xr-x 2 root root 184 May 3 2011 n/ armedslack-arm5te/a: total 23000 -rw-r--r-- 1 root root 1420330 May 3 2011 bash-4.1.010-arm5te-1.tgz -rw-r--r-- 1 root root 56634 May 3 2011 bin-11.1-arm5te-1.tgz -rw-r--r-- 1 root root 109776 May 3 2011 bzip2-1.0.6-arm5te-1.tgz -rw-r--r-- 1 root root 4678547 May 3 2011 coreutils-8.11-arm5te-1.tgz -rw-r--r-- 1 root root 3496097 May 3 2011 cups-1.4.6-arm5te-1.tgz -rw-r--r-- 1 root root 1083455 May 3 2011 e2fsprogs-1.41.14-arm5te-1.tgz -rw-r--r-- 1 root root 4631918 May 3 2011 glibc-solibs-2.13-arm5te-3.tgz -rw-r--r-- 1 root root 648908 May 3 2011 glibc-zoneinfo-2.13-noarch-3.tgz -rw-r--r-- 1 root root 261526 May 3 2011 gpm-1.20.4-arm5te-1.tgz -rw-r--r-- 1 root root 375620 May 3 2011 grep-2.7-arm5te-1.tgz -rw-r--r-- 1 root root 117752 May 3 2011 gzip-1.4-arm5te-1.tgz -rw-r--r-- 1 root root 3113134 May 3 2011 lvm2-2.02.84-arm5te-1.tgz -rw-r--r-- 1 root root 524646 May 3 2011 module-init-tools-3.12-arm5te-2.tgz -rw-r--r-- 1 root root 44604 May 3 2011 sysfsutils-2.1.0-arm5te-1.tgz -rw-r--r-- 1 root root 2648394 May 3 2011 util-linux-2.19-arm5te-1.tgz -rw-r--r-- 1 root root 291272 May 3 2011 xz-5.0.2-arm5te-1.tgz armedslack-arm5te/ap: total 40 -rw-r--r-- 1 root root 38130 May 3 2011 dmapi-2.2.10-arm5te-1.tgz armedslack-arm5te/d: total 59702 -rw-r--r-- 1 root root 5038952 May 3 2011 binutils-2.21-arm5te-2.tgz -rw-r--r-- 1 root root 12545430 May 3 2011 gcc-4.5.2-arm5te-3.tgz -rw-r--r-- 1 root root 7476118 May 3 2011 gcc-g++-4.5.2-arm5te-3.tgz -rw-r--r-- 1 root root 4787861 May 3 2011 gcc-gfortran-4.5.2-arm5te-3.tgz -rw-r--r-- 1 root root 27324627 May 3 2011 gcc-java-4.5.2-arm5te-3.tgz -rw-r--r-- 1 root root 3890497 May 3 2011 gcc-objc-4.5.2-arm5te-3.tgz armedslack-arm5te/l: total 77092 -rw-r--r-- 1 root root 478481 May 3 2011 db42-4.2.52-arm5te-1.tgz -rw-r--r-- 1 root root 2144196 May 3 2011 db44-4.4.20-arm5te-1.tgz -rw-r--r-- 1 root root 215950 May 3 2011 glib-1.2.10-arm5te-2.tgz -rw-r--r-- 1 root root 4678632 May 3 2011 glib2-2.28.6-arm5te-1.tgz -rw-r--r-- 1 root root 35887213 May 3 2011 glibc-2.13-arm5te-3.tgz -rw-r--r-- 1 root root 26967153 May 3 2011 glibc-i18n-2.13-arm5te-3.tgz -rw-r--r-- 1 root root 1507202 May 3 2011 glibc-profile-2.13-arm5te-3.tgz -rw-r--r-- 1 root root 945290 May 3 2011 gmp-5.0.1-arm5te-1.tgz -rw-r--r-- 1 root root 58132 May 3 2011 libcap-2.20-arm5te-1.tgz -rw-r--r-- 1 root root 103916 May 3 2011 libelf-0.8.13-arm5te-2.tgz -rw-r--r-- 1 root root 382913 May 3 2011 libidn-1.19-arm5te-1.tgz -rw-r--r-- 1 root root 310211 May 3 2011 libjpeg-v8a-arm5te-1.tgz -rw-r--r-- 1 root root 620888 May 3 2011 libpng-1.4.5-arm5te-1.tgz -rw-r--r-- 1 root root 60368 May 3 2011 libtermcap-1.2.3-arm5te-1.tgz -rw-r--r-- 1 root root 658366 May 3 2011 libtiff-3.9.4-arm5te-2.tgz -rw-r--r-- 1 root root 73047 May 3 2011 libusb-1.0.8-arm5te-2.tgz -rw-r--r-- 1 root root 37596 May 3 2011 mm-1.4.2-arm5te-1.tgz -rw-r--r-- 1 root root 1749585 May 3 2011 ncurses-5.9-arm5te-1.tgz -rw-r--r-- 1 root root 604383 May 3 2011 pcre-8.12-arm5te-1.tgz -rw-r--r-- 1 root root 55370 May 3 2011 popt-1.7-arm5te-2.tgz -rw-r--r-- 1 root root 387816 May 3 2011 readline-5.2-arm5te-1.tgz -rw-r--r-- 1 root root 506864 May 3 2011 slang-2.2.3-arm5te-1.tgz -rw-r--r-- 1 root root 217384 May 3 2011 slang1-1.4.9-arm5te-1.tgz -rw-r--r-- 1 root root 21554 May 3 2011 svgalib-1.3.1-arm5te-1.tgz -rw-r--r-- 1 root root 150455 May 3 2011 zlib-1.2.5-arm5te-4.tgz armedslack-arm5te/n: total 44127 -rw-r--r-- 1 root root 905811 May 3 2011 curl-7.21.4-arm5te-1.tgz -rw-r--r-- 1 root root 648771 May 3 2011 openldap-client-2.4.23-arm5te-1.tgz -rw-r--r-- 1 root root 43580259 May 3 2011 samba-3.5.8-arm5te-1.tgz root at mrlinux:/v/htdocs/guruplug# When my cable modem gets fixed you can get all this at http://mrlinux.homelinux.com/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 Fri Dec 16 15:56:48 2011 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Fri, 16 Dec 2011 15:56:48 +0000 (GMT) Subject: [ARMedslack] Slackware ARM current is being re-based to armv5te In-Reply-To: <4EEB1B7E.2030909@gmail.com> References: <4EEA7A66.5010009@gmail.com> <20111216082131.590d6301@pinkfloyd.tm-net> <4EEB1B7E.2030909@gmail.com> Message-ID: > > What kind of tests? On x86 platform I could measure slight differences > > on audio/video decoding/encoding. > > [..] You've made a good list there- I'm rebuilding some of the core stuff at the moment. I don't expect there to be much of a performance improvement either, but even if there's 0.5% it's better than nothing - since my goal is to have an ARM desktop machine. To be honest, the old ARM machines with an armv4t CPU in my opinion are painful to use (having used one for a while) and don't give an enjoyable experience - so I'm more interested in moving forwards and supporting the new mass market baseline of armv5t. The old machines can use armedslack 13.37 which is a very good release as far as Slackware goes - the only thing broken in armedslack is KDE, which would be unusable on such old hardware anyway. From thenktor at gmail.com Fri Dec 16 18:28:11 2011 From: thenktor at gmail.com (Thorsten =?ISO-8859-1?B?TfxobGZlbGRlcg==?=) Date: Fri, 16 Dec 2011 19:28:11 +0100 Subject: [ARMedslack] Slackware ARM current is being re-based to armv5te In-Reply-To: <4EEB1A88.8070102@gmail.com> References: <4EEA7A66.5010009@gmail.com> <20111216082131.590d6301@pinkfloyd.tm-net> <4EEB1A88.8070102@gmail.com> Message-ID: <20111216192811.36ede9f1@pinkfloyd.tm-net> Am Fri, 16 Dec 2011 05:16:40 -0500 schrieb John O'Donnell : > Well you obviously wont be processing anything like that on these > plugs without an FPU, Well, AFAIK mp3, flac and tremor is all integer processing. Only vorbis requires FPU. And a dockstar is a nice mpd server ;) Basically this was just meant as example, but I'm quite sure changing from armv4te to armv5te will be far is far away from changing from march=i486 to march=k8 on my x86 system. -- Thorsten M?hlfelder Salix OS: www.salixos.org From louigi600 at yahoo.it Mon Dec 19 19:48:58 2011 From: louigi600 at yahoo.it (Davide) Date: Mon, 19 Dec 2011 19:48:58 +0000 (GMT) Subject: [ARMedslack] Slackware ARM current is being re-based to armv5te In-Reply-To: References: Message-ID: <1324324138.89228.YahooMailNeo@web29705.mail.ird.yahoo.com> Will this impact just current or all actively maintained versions ? ________________________________ Da: Stuart Winter A: armedslack at lists.armedslack.org Inviato: Gioved? 15 Dicembre 2011 13:08 Oggetto: [ARMedslack] Slackware ARM current is being re-based to armv5te Hi After about 5 months or more of on-off thought, I've decided to re-base Slackware ARM to be armv5te.? This means that the old devices that any devices that have an armv4t CPU will need to use the armedslack-13.37 release. The reason for this is that: * Slackware ARM only provides kernels for systems that have an armv5t CPU * The critical mass of consumer products (such as Plug computers) have an ? armv5 CPU. Therefore it makes sense to support the vast majority and provide an optimised userland. So, if you want -current for your armv4t devices - you can grab it quickly before I begin uploading packages compiled for armv5te :-) I'm rebuilding the core packages first such as bash and glibc, and will upgrade the others gradually as they get updated in Slackware x86. Stuart. -- 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 m-lists at biscuit.org.uk Mon Dec 19 22:06:47 2011 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Mon, 19 Dec 2011 22:06:47 +0000 (GMT) Subject: [ARMedslack] Slackware ARM current is being re-based to armv5te In-Reply-To: <1324324138.89228.YahooMailNeo@web29705.mail.ird.yahoo.com> References: <1324324138.89228.YahooMailNeo@web29705.mail.ird.yahoo.com> Message-ID: On Mon, 19 Dec 2011, Davide wrote: > Will this impact just current or all actively maintained versions ? -current and onwards only. As I think I said, ARMv4t machines will need to use v13.37. -- Stuart Winter Slackware ARM: www.armedslack.org From unixjohn1969 at gmail.com Tue Dec 20 12:01:56 2011 From: unixjohn1969 at gmail.com (John O'Donnell) Date: Tue, 20 Dec 2011 07:01:56 -0500 Subject: [ARMedslack] Slackware ARM current is being re-based to armv5te In-Reply-To: <20111216192811.36ede9f1@pinkfloyd.tm-net> References: <4EEA7A66.5010009@gmail.com> <20111216082131.590d6301@pinkfloyd.tm-net> <4EEB1A88.8070102@gmail.com> <20111216192811.36ede9f1@pinkfloyd.tm-net> Message-ID: <4EF07934.5030003@gmail.com> On 12/16/2011 01:28 PM, Thorsten M?hlfelder wrote: > Am Fri, 16 Dec 2011 05:16:40 -0500 > schrieb John O'Donnell: > >> Well you obviously wont be processing anything like that on these >> plugs without an FPU, > > Well, AFAIK mp3, flac and tremor is all integer processing. Only vorbis > requires FPU. And a dockstar is a nice mpd server ;) > Basically this was just meant as example, but I'm quite sure changing > from armv4te to armv5te will be far is far away from changing from > march=i486 to march=k8 on my x86 system. Thank you for dropping the "video" from the conversation ;-) 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