From mozes at slackware.com Sun Apr 1 09:24:18 2007 From: mozes at slackware.com (Stuart Winter) Date: Sun, 1 Apr 2007 01:24:18 -0800 (PST) Subject: [armedslack] Re: ARMedslack In-Reply-To: <1175375155.10235.4.camel@jetpack.demon.co.uk> References: <1174660070.10133.14.camel@jetpack.demon.co.uk> <1175287779.10147.10.camel@jetpack.demon.co.uk> <1175375155.10235.4.camel@jetpack.demon.co.uk> Message-ID: Hi Alan ( ccing armedslack list) > > working. > > I can do the X patches. Just wondering about any kernel patches etc. The only Kernel patches I have are ftp://ftp.slackware.pl/pub/armedslack/armedslack-current/source/k/sources/linux-2.6/patches The acorn framebuffer one you did; the rapide v2 (unfinished - doesn't do CD drives I don't think, but works fine for hard discs); the booting of zImage -- Jim looked at what RMK said in the bugzilla about updating this patch and couldn't understand what he was getting at, so it remains as it is -- besides, it works and it's only for the RiscPC. For the RiscPC the to do list is: ftp://ftp.slackware.pl/pub/armedslack/armedslack-current/ARMedslack-TODO The remaining X stuff for Xorg 6.9 was fixing the mapping of the keys for the RiscPC: everything worked as expected inside QEMU. The RiscPC key mapping could be fixed by xmodmap but I choose to have a real key map file, or a fix upstream (if it's actually a bug - probably isn't). Anyway, the key mapping is the least of the issues at the moment since xorg 7.2 doesn't work for me yet :-) Btw I have opened the real ARMedslack master tree which can be rsynced only - it's meant for mirrors: rsync -P bourbon.biscuit.org.uk::armedslack This one will always be up to date before anything else. Cheers s. From m-lists at biscuit.org.uk Wed Apr 4 16:04:00 2007 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Wed, 4 Apr 2007 17:04:00 +0100 (BST) Subject: [armedslack] X In-Reply-To: References: <1174660070.10133.14.camel@jetpack.demon.co.uk> <1175287779.10147.10.camel@jetpack.demon.co.uk> <1175375155.10235.4.camel@jetpack.demon.co.uk> Message-ID: I Think I have found how to make X build. It's always the simple things. I don't know whether X will *work*, but having it build would be a pretty good start ;-) From psychicistnonconformist at gmail.com Wed Apr 4 19:18:31 2007 From: psychicistnonconformist at gmail.com (Sunil Amitkumar Janki) Date: Wed, 04 Apr 2007 21:18:31 +0200 Subject: [armedslack] X In-Reply-To: References: <1174660070.10133.14.camel@jetpack.demon.co.uk> <1175287779.10147.10.camel@jetpack.demon.co.uk> <1175375155.10235.4.camel@jetpack.demon.co.uk> Message-ID: <4613FA07.9000103@gmail.com> Stuart Winter wrote: > I Think I have found how to make X build. It's always the simple things. > > I don't know whether X will *work*, but having it build would be a pretty > good start ;-) I very much agree. There was someone on the LinuxQuestions Slackware forum who said that Xorg in Current was frustrating. I replied that in Armedslack it didn't even run at the moment, so nothing to feel too frustrated about :-) That's why I have come to like virtual machines for the last few years. You can test all kinds of configurations. You can run released and test versions side by side and set up pristine build systems for packaging applications while still enjoying a stable, released Slackware system on your host. That's also what I am doing with Armedslack now, running 11.0 and current in separate QEMU machines, though not at the same time. I am now installing Armedslack Current after trying with the installer but somehow it ran out of space. So I am reverting to my tried and true method of "abusing" Debian to install Armedslack :-) From m-lists at biscuit.org.uk Wed Apr 4 21:25:44 2007 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Wed, 4 Apr 2007 22:25:44 +0100 (BST) Subject: [armedslack] X In-Reply-To: <4613FA07.9000103@gmail.com> References: <1174660070.10133.14.camel@jetpack.demon.co.uk> <1175287779.10147.10.camel@jetpack.demon.co.uk> <1175375155.10235.4.camel@jetpack.demon.co.uk> <4613FA07.9000103@gmail.com> Message-ID: > That's also what I am doing with Armedslack now, running 11.0 and current in > separate QEMU machines, though not at the same time. I am now installing > Armedslack Current after trying with the installer but somehow it ran out of > space. So I am reverting to my tried and true method of "abusing" Debian to > install Armedslack :-) Why do you not tell me where it fails and I will make a note to fix it. All of the fixes are in the root directory of the armedslack tree: ARMedslack-TODO - TODOs for ARMedslack specific port slk-current-TODO - package building progress against slackware-current It works fine for me but there have been some instances in the past where it did run out of space due to a bug where by the installation ended up going into the ram disk rather than the target filesystem on hard disk. The new initrd.img will be a cpio - I just need to re-run the installer build script to re-create it, but as it is -- for me-- it works as the 'initrd' loopback system, so I leave it as it is. a. From psychicistnonconformist at gmail.com Thu Apr 5 16:56:34 2007 From: psychicistnonconformist at gmail.com (Sunil Amitkumar Janki) Date: Thu, 05 Apr 2007 18:56:34 +0200 Subject: [armedslack] ARM EABI Message-ID: <46152A42.6090907@gmail.com> Incidentally I found this link to an article on the ARM EABI: http://linuxdevices.com/articles/AT5920399313.html It basically says floating point operations are sped up by more than 10x by using the ARM EABI. As far as I know this is only supported by GCC 4. BTW I am building X in Armedslack Current at the moment using the latest Slackware Current source and adding in your patches and CFLAGS. Let's see if it works that way. > Hm. I try to keep clear of patching the source because it means much > more of a time consuming job for me - usually I just overload CFLAGS or > use sed to update a Makefile. This full time job and life thing makes > me optimise one of my hobbies as much as possible :) The fuse build script is an exception but I did it because setting CFLAGS didn't work. I usually just grep for O2 so it is not that time-consuming but I'd rather still do without patches. I have seen some EXTRA_CFLAGS somewhere though so I'll look into that. The normal way is to just add the targets to the build script. See my attached template for an example. Even though I usually don't build that package anymore it is still the cleanest build script to serve as a template. > Oh OK - I have had a look. How would you differentiate package > names from the resulting build? I always build as root so as not to get permission problems. That's not a problem since VMs are disposable :-) So for the root user I create a .bash_profile containing a line "export ARCH=armv3" for Armedslack. For Slackintosh I would change that to "export ARCH=powerpc" etc. For one-off builds you can use e.g. "ARCH=xscale ./foo.SlackBuild". The packages automagically get a foo-*-armv3-* designation even though the default in the script is still i486. If you fail to set ARCH on an architecture other than i486 the build script will not get very far. > Why do you not tell me where it fails and I will make a note to fix it. > All of the fixes are in the root directory of the armedslack tree: > ARMedslack-TODO - TODOs for ARMedslack specific port > slk-current-TODO - package building progress against slackware-current Am I doing something wrong? I employ QEMU "kernel/initrd" booting using your supplied versatile kernel and color.gz initrd. I'll try again later but it is not necessary to get Armedslack installed. I have enough experience in Slackware to somehow get it to work ;-) But you're correct that the installer should be fixed to work on all kinds of platforms so the uninitiated can get it to work as well. Regards, Sunil -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: libiconv.SlackBuild URL: From m-lists at biscuit.org.uk Fri Apr 6 10:03:08 2007 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Fri, 6 Apr 2007 11:03:08 +0100 (BST) Subject: [armedslack] ARM EABI In-Reply-To: <46152A42.6090907@gmail.com> References: <46152A42.6090907@gmail.com> Message-ID: On Thu, 5 Apr 2007, Sunil Amitkumar Janki wrote: > http://linuxdevices.com/articles/AT5920399313.html > > It basically says floating point operations are sped up by > more than 10x by using the ARM EABI. As far as I know > this is only supported by GCC 4. You are welcome to start a port ;-) > BTW I am building X in Armedslack Current at the moment > using the latest Slackware Current source and adding in > your patches and CFLAGS. Let's see if it works that way. You probably will not get far with it because the build order isn't correct. Also, I just noticed that ARMedslack's x/mesa package is broken -- it's missing the libraries because I think they got installed onto the filesystem rather than the package. Infact most of the build breakages appear to stem from stuff being installed into /usr/local. I'm rebuilding Mesa now. > Am I doing something wrong? I employ QEMU "kernel/initrd" > booting using your supplied versatile kernel and color.gz > initrd. It's possible that the initrd I am using isn't the one on the ftp site. http://www.slackware.com/~mozes/dl/armedslack/ Those are the files I am using - give those a go. I'll rebuild the installer at some point -- there has been a few changes to some of the installer scripts inside the initrd, so I will have to spend some time to work out what has happened. > I'll try again later but it is not necessary to get Armedslack > installed. I have enough experience in Slackware to somehow > get it to work ;-) Cool - also there is 'tinstall.sh' inside the slackware/ directory which I used to use before I got the installer working. -- Stuart Winter www.armedslack.org From m-lists at biscuit.org.uk Fri Apr 6 10:49:12 2007 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Fri, 6 Apr 2007 11:49:12 +0100 (BST) Subject: [armedslack] ARM EABI In-Reply-To: References: <46152A42.6090907@gmail.com> Message-ID: > Those are the files I am using - give those a go. I'll rebuild > the installer at some point -- there has been a few changes to > some of the installer scripts inside the initrd, so I will have to > spend some time to work out what has happened. I meant to also add that when you get this working, you would be best to set the system date properly once you get to the installer's shell. I believe that QEMU can make the target OS' date the same as the host system's, but I didn't get this to work. Also, you probably do this already but if you don't get the date set, you would be best to do this inside the installer: tune2fs -i0 /dev/whatever I'm just rebuilding Mesa and wondering whether I made the right choice with 'make linux-fbdev'. I think so since all the ARM devices I have ever know about use a framebuffer. Everyone else chooses linux-dri. I may have to do some more docs consulting ;-) Thoughts? :-) From alanh at fairlite.demon.co.uk Fri Apr 6 11:01:00 2007 From: alanh at fairlite.demon.co.uk (Alan Hourihane) Date: Fri, 06 Apr 2007 12:01:00 +0100 Subject: [armedslack] ARM EABI In-Reply-To: References: <46152A42.6090907@gmail.com> Message-ID: <1175857260.10112.1.camel@jetpack.demon.co.uk> On Fri, 2007-04-06 at 11:49 +0100, Stuart Winter wrote: > > Those are the files I am using - give those a go. I'll rebuild > > the installer at some point -- there has been a few changes to > > some of the installer scripts inside the initrd, so I will have to > > spend some time to work out what has happened. > > I meant to also add that when you get this working, you would > be best to set the system date properly once you get to > the installer's shell. > > I believe that QEMU can make the target OS' date the same as the > host system's, but I didn't get this to work. > > Also, you probably do this already but if you don't get the date set, you > would be best to do this inside the installer: > > tune2fs -i0 /dev/whatever > > I'm just rebuilding Mesa and wondering whether I made the right > choice with 'make linux-fbdev'. I think so since all the ARM > devices I have ever know about use a framebuffer. > Everyone else chooses linux-dri. I may have to do some more > docs consulting ;-) > > Thoughts? :-) Yes, linux-fbdev will get you a usable interface. If I can get my RiscPC going, I'll help out with getting X and Mesa sorted out. Alan. From m-lists at biscuit.org.uk Fri Apr 6 12:08:52 2007 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Fri, 6 Apr 2007 13:08:52 +0100 (BST) Subject: [armedslack] ARM EABI In-Reply-To: <1175857260.10112.1.camel@jetpack.demon.co.uk> References: <46152A42.6090907@gmail.com> <1175857260.10112.1.camel@jetpack.demon.co.uk> Message-ID: > Yes, linux-fbdev will get you a usable interface. OK cool thanks I will rebuild it again with fbdev. > If I can get my RiscPC going, I'll help out with getting X and Mesa > sorted out. Great thanks! I think X is holding back most of the big builds at the moment since I'm waiting to build KDE and some other x apps. I have been working on the networking and application series though, so I will upload those changes soon. s. From psychicistnonconformist at gmail.com Fri Apr 6 12:16:36 2007 From: psychicistnonconformist at gmail.com (Sunil Amitkumar Janki) Date: Fri, 06 Apr 2007 14:16:36 +0200 Subject: [armedslack] ARM EABI In-Reply-To: References: <46152A42.6090907@gmail.com> Message-ID: <46163A24.8040104@gmail.com> Stuart Winter wrote: > I meant to also add that when you get this working, you would > be best to set the system date properly once you get to > the installer's shell. > > I use ntpdate from Armedslack so that's no problem. > I'm just rebuilding Mesa and wondering whether I made the right > choice with 'make linux-fbdev'. I think so since all the ARM > devices I have ever know about use a framebuffer. We can always build alternate packages if necessary. QEMU uses a framebuffer as well. That's how I run X so nothing to worry about except graphics performance. > Everyone else chooses linux-dri. I may have to do some more > docs consulting ;-) > That depends on whether you have a 3D graphics accelerator in one of your computers. I only have a PDA and QEMU :-) > Thoughts? :-) I am trying to figure out how to build X in Slackware Current in an x86 vm after ending up with many *.failed files when building in Armedslack. From alanh at fairlite.demon.co.uk Fri Apr 6 12:39:11 2007 From: alanh at fairlite.demon.co.uk (Alan Hourihane) Date: Fri, 06 Apr 2007 13:39:11 +0100 Subject: [armedslack] ARM EABI In-Reply-To: <46163A24.8040104@gmail.com> References: <46152A42.6090907@gmail.com> <46163A24.8040104@gmail.com> Message-ID: <1175863151.10112.3.camel@jetpack.demon.co.uk> On Fri, 2007-04-06 at 14:16 +0200, Sunil Amitkumar Janki wrote: > Stuart Winter wrote: > > I meant to also add that when you get this working, you would > > be best to set the system date properly once you get to > > the installer's shell. > > > > > > I use ntpdate from Armedslack so that's no problem. > > > I'm just rebuilding Mesa and wondering whether I made the right > > choice with 'make linux-fbdev'. I think so since all the ARM > > devices I have ever know about use a framebuffer. > > We can always build alternate packages if necessary. QEMU uses a > framebuffer as well. That's how I run X so nothing to worry about except > graphics performance. > > > Everyone else chooses linux-dri. I may have to do some more > > docs consulting ;-) > > > > That depends on whether you have a 3D graphics accelerator in one > of your computers. I only have a PDA and QEMU :-) Indeed. That's one of the reasons I have a ViewFinder in my RiscPC :-) Alan. From m-lists at biscuit.org.uk Fri Apr 6 19:28:51 2007 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Fri, 6 Apr 2007 20:28:51 +0100 (BST) Subject: [armedslack] ARM EABI In-Reply-To: <46163A24.8040104@gmail.com> References: <46152A42.6090907@gmail.com> <46163A24.8040104@gmail.com> Message-ID: > > I use ntpdate from Armedslack so that's no problem. Yeah me too -- I will include it in the installer initrd. > > Thoughts? :-) > > I am trying to figure out how to build X in Slackware Current in an x86 vm > after ending up with many *.failed files when building in Armedslack. I did that this way: http://wiki.x.org/wiki/ModularDevelopersGuide - Download the git fetching script and add in the fonts stuff: do_dir driver "${driver}" do_dir font "${font}" # this line added to get fonts do_dir lib "${lib}" On your x86 host: Update /usr/local to be /usr so the libs get put into the right place: fgrep -lr -- 'usr/local' . | xargs sed -i 's?usr/local?usr/?g' ./util/modular/build.sh -n -D /usr 2>&1 | tee build.log Then build x/mesa That's how I got the X packages to build. I don't remember at what point the modular X requires Mesa, but you could then re-build using the ./util/modular/build.sh script, *then* try x11.SlackBuild. The way Patrick did it was to have bootstrap scripts and generate larger packages. I still have his build scripts for those packages but it's almost identical to the one in -current, so it's not useful. This method certainly *helps* :-) -- Stuart Winter www.armedslack.org From psychicistnonconformist at gmail.com Fri Apr 6 19:45:52 2007 From: psychicistnonconformist at gmail.com (Sunil Amitkumar Janki) Date: Fri, 06 Apr 2007 21:45:52 +0200 Subject: [armedslack] ARM EABI In-Reply-To: References: <46152A42.6090907@gmail.com> Message-ID: <4616A370.6060106@gmail.com> Stuart Winter wrote: > You are welcome to start a port ;-) > I will probably build these packages for Xscale when Armedslack 11.1/12 will be stable. From the state of X we can conclude that will not be very soon ;-) > It's possible that the initrd I am using isn't the one on the ftp site. > I finally managed to install using the installer to an ext3 partition, but not to XFS. Then it bails out with input/output errors. So no installs to XFS for the moment :-) From alanh at fairlite.demon.co.uk Sat Apr 7 20:27:55 2007 From: alanh at fairlite.demon.co.uk (Alan Hourihane) Date: Sat, 07 Apr 2007 21:27:55 +0100 Subject: [armedslack] GRUB 1.91 problems Message-ID: <1175977675.10071.7.camel@localhost> So, I've been having problems with GRUB lately, and I'm currently getting this with 1.91 from ARMedslacks bootware for riscpc. Internal error: abort on data transfer at &03815F8C Postmortem requested 23d3144 in function ^grub_mod_init a214 in function grub_dl_load_core a330 in function grub_dl_load_file 9bf4 in function grub_dl_load e72c in function grub_address_space_get_physical 31ab0 in function grub_rescue_cmd_linux 3e4e0 in function ^grub_normal_linux_command 386a8 in function grub_command_execute 3a3dc in function ^run_menu_entry 3a744 in function grub_menu_run 39d88 in function grub_normal_execute 39e98 in function ^grub_rescue_cmd_normal cd58 in function grub_enter_rescue_mode Arg2: 0x00008178 33144 -> [0xe1a0c00d 0xe92dd830 0xe24cb004 0xeb0018af] Arg1: 0x00028be8 166888 -> [0x7572473c 0x69442462 0x672e3e72 0x5f627572] 23e4da0 in shared library function Not sure what's going on, but anyone ever seen something similar ??? Alan. From psychicistnonconformist at gmail.com Sun Apr 8 13:56:41 2007 From: psychicistnonconformist at gmail.com (Sunil Amitkumar Janki) Date: Sun, 08 Apr 2007 15:56:41 +0200 Subject: [armedslack] GRUB 1.91 problems In-Reply-To: <1175977675.10071.7.camel@localhost> References: <1175977675.10071.7.camel@localhost> Message-ID: <4618F499.3080406@gmail.com> Alan Hourihane wrote: > So, I've been having problems with GRUB lately, and I'm currently > getting this with 1.91 from ARMedslacks bootware for riscpc. I haven't installed GRUB to my (virtual) hard drive yet but I'll try to install it to /dev/sda1 and/or /dev/sda and see if I can get it to boot. I only have experience with x86 GRUB 1 so I have never seen your error message before. From psychicistnonconformist at gmail.com Sun Apr 8 14:05:27 2007 From: psychicistnonconformist at gmail.com (Sunil Amitkumar Janki) Date: Sun, 08 Apr 2007 16:05:27 +0200 Subject: [armedslack] ARM EABI In-Reply-To: References: <46152A42.6090907@gmail.com> <46163A24.8040104@gmail.com> Message-ID: <4618F6A7.1040906@gmail.com> Stuart Winter wrote: > The way Patrick did it was to have bootstrap scripts and generate larger > packages. I still have his build scripts for those packages but > it's almost identical to the one in -current, so it's not useful. > > This method certainly *helps* :-) I have come to the conclusion that the build script is too complex for the time being and have resorted to creating individual build scripts and description files from the files in Slackware Current. This way it is a lot easier to figure out what the build order should be and since it is not very well or at all documented I am documenting it as I am building packages. What I am doing now is creating packages for x86 and ARM in lockstep so given a week (or two :-)) there should be all fresh (or stale ;-)) ARM X packages. Regards, Sunil From m-lists at biscuit.org.uk Mon Apr 9 09:51:22 2007 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Mon, 9 Apr 2007 10:51:22 +0100 (BST) Subject: [armedslack] ARM EABI In-Reply-To: <4618F6A7.1040906@gmail.com> References: <46152A42.6090907@gmail.com> <46163A24.8040104@gmail.com> <4618F6A7.1040906@gmail.com> Message-ID: On Sun, 8 Apr 2007, Sunil Amitkumar Janki wrote: > I have come to the conclusion that the build script is too complex for the > time being > and have resorted to creating individual build scripts and description files > from the > files in Slackware Current. I also looked at Debian's and gentoo's scripts and came to the same conclusion! > What I am doing now is creating packages for x86 and ARM in lockstep so given > a > week (or two :-)) there should be all fresh (or stale ;-)) ARM X packages. Cool! I'll continue working on the other non-x stuff. By the way, I notice that x/mesa is a bit of a pain in the ass to package into a pseudo root directory. I have made a package now using slacktrack, and I'm uploading the latest tree. From m-lists at biscuit.org.uk Mon Apr 9 17:55:11 2007 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Mon, 9 Apr 2007 18:55:11 +0100 (BST) Subject: [armedslack] GRUB 1.91 problems In-Reply-To: <1175977675.10071.7.camel@localhost> References: <1175977675.10071.7.camel@localhost> Message-ID: > getting this with 1.91 from ARMedslacks bootware for riscpc. > > Internal error: abort on data transfer at &03815F8C Have you tried Tim's own binaries? http://www.majoroak.f2s.com/tim/grub/RISC_OS/ http://www.majoroak.f2s.com/tim/grub/RISC_OS/binaries/grub-1.91-teb3.zip Mine work for me but perhaps his work for you? From alanh at fairlite.demon.co.uk Mon Apr 9 18:21:30 2007 From: alanh at fairlite.demon.co.uk (Alan Hourihane) Date: Mon, 09 Apr 2007 19:21:30 +0100 Subject: [armedslack] GRUB 1.91 problems In-Reply-To: References: <1175977675.10071.7.camel@localhost> Message-ID: <1176142890.10098.33.camel@localhost> On Mon, 2007-04-09 at 18:55 +0100, Stuart Winter wrote: > > getting this with 1.91 from ARMedslacks bootware for riscpc. > > > > Internal error: abort on data transfer at &03815F8C > > Have you tried Tim's own binaries? > http://www.majoroak.f2s.com/tim/grub/RISC_OS/ > > http://www.majoroak.f2s.com/tim/grub/RISC_OS/binaries/grub-1.91-teb3.zip > > Mine work for me but perhaps his work for you? I'll give them a try. But I'm just getting a cross compiler setup so I can build the arm binaries for grub myself and start debugging. Alan. From alanh at fairlite.demon.co.uk Mon Apr 9 18:37:09 2007 From: alanh at fairlite.demon.co.uk (Alan Hourihane) Date: Mon, 09 Apr 2007 19:37:09 +0100 Subject: [armedslack] GRUB 1.91 problems In-Reply-To: <1176142890.10098.33.camel@localhost> References: <1175977675.10071.7.camel@localhost> <1176142890.10098.33.camel@localhost> Message-ID: <1176143829.10098.36.camel@localhost> O.k. so doing some debugging, shows that it's blowing up in grub_RISC_OS_get_page_arrangement_table The RiscPC works when I have 2 x 64Mb SIMMS installed, but with 2 x 128Mb SIMMs it blows up. Looking at that function it does some memory calculations, which obviously are going wrong with the larger memory size. I really need to get my ARM cross compiler running.... :-( Alan. From alanh at fairlite.demon.co.uk Mon Apr 9 20:28:16 2007 From: alanh at fairlite.demon.co.uk (Alan Hourihane) Date: Mon, 09 Apr 2007 21:28:16 +0100 Subject: [armedslack] GRUB 1.91 problems In-Reply-To: References: <1175977675.10071.7.camel@localhost> Message-ID: <1176150496.10098.43.camel@localhost> On Mon, 2007-04-09 at 18:55 +0100, Stuart Winter wrote: > > getting this with 1.91 from ARMedslacks bootware for riscpc. > > > > Internal error: abort on data transfer at &03815F8C > > Have you tried Tim's own binaries? > http://www.majoroak.f2s.com/tim/grub/RISC_OS/ > > http://www.majoroak.f2s.com/tim/grub/RISC_OS/binaries/grub-1.91-teb3.zip > > Mine work for me but perhaps his work for you? I've built the GCCSDK cross compiler now, but anyone got a clue about cross compiling grub and the command line flags ?? Alan. From alanh at fairlite.demon.co.uk Mon Apr 9 22:27:19 2007 From: alanh at fairlite.demon.co.uk (Alan Hourihane) Date: Mon, 09 Apr 2007 23:27:19 +0100 Subject: [armedslack] GRUB 1.91 problems In-Reply-To: <1176150496.10098.43.camel@localhost> References: <1175977675.10071.7.camel@localhost> <1176150496.10098.43.camel@localhost> Message-ID: <1176157639.10098.52.camel@localhost> O.k. I've got grub building now, so can I ask those who have a RiscPC to run this program and let me know their results.... http://ftp.netbsd.org/pub/NetBSD/arch/arm32/riscos/listphysmem.bas Thanks, Alan. From psychicistnonconformist at gmail.com Wed Apr 11 12:54:19 2007 From: psychicistnonconformist at gmail.com (Sunil Amitkumar Janki) Date: Wed, 11 Apr 2007 14:54:19 +0200 Subject: [armedslack] Armedslack X status Message-ID: <461CDA7B.6080708@gmail.com> I would like to keep you up to date on the status of the X build process so you know progress is being made :-) I have completed building the proto, lib, xcb and fontconfig series. After that data and util are not much work either. I will probably need some more time for mesa, app, driver, font, doc and xserver. This will probably take more than a week but the packages will be correct and high-quality ;-) Regards, Sunil From m-lists at biscuit.org.uk Wed Apr 11 13:54:50 2007 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Wed, 11 Apr 2007 14:54:50 +0100 (BST) Subject: [armedslack] GRUB 1.91 problems In-Reply-To: <1176157639.10098.52.camel@localhost> References: <1175977675.10071.7.camel@localhost> <1176150496.10098.43.camel@localhost> <1176157639.10098.52.camel@localhost> Message-ID: > http://ftp.netbsd.org/pub/NetBSD/arch/arm32/riscos/listphysmem.bas ATAFS::quana.$ * LanMan98::prisRoot.$.scratchbox.users.build.home.build.armedslack-current.source.bootware.riscos.tools *. Dir. LanMan98::prisRoot.$.scratchbox.users.build.home.build.armedslack-current.source.bootware.riscos.tools Option 00 (Off) CSD LanMan98::prisRoot.$.scratchbox.users.build.home.build.armedslack-current.source.bootware.riscos.tools Lib. LanMan98:"Unset" URD LanMan98:"Unset" listphysmem/bas WR/ source/download WR/ LanMan98::prisRoot.$.scratchbox.users.build.home.build.armedslack-current.source.bootware.riscos.tools *listphysmem/bas Program renumbered Memory table size = 65536 Page size = 4096 2 blocks of DRAM found 1 block of VRAM found 2 blocks of ROM found Dynamic RAM: 10000000 16384 pages 18000000 16384 pages 32768 pages found Video RAM: 2000000 512 pages 512 pages found ROM: 0 1024 pages 1024 pages found IO Space: 3000000 2048 pages 8000000 32768 pages 34816 pages found LanMan98::prisRoot.$.scratchbox.users.build.home.build.armedslack-current.source.bootware.riscos.tools * From alanh at fairlite.demon.co.uk Wed Apr 11 18:30:37 2007 From: alanh at fairlite.demon.co.uk (Alan Hourihane) Date: Wed, 11 Apr 2007 19:30:37 +0100 Subject: [armedslack] GRUB 1.91 problems In-Reply-To: References: <1175977675.10071.7.camel@localhost> <1176150496.10098.43.camel@localhost> <1176157639.10098.52.camel@localhost> Message-ID: <1176316237.10079.32.camel@jetpack.demon.co.uk> On Wed, 2007-04-11 at 14:54 +0100, Stuart Winter wrote: > > http://ftp.netbsd.org/pub/NetBSD/arch/arm32/riscos/listphysmem.bas > > ATAFS::quana.$ * > LanMan98::prisRoot.$.scratchbox.users.build.home.build.armedslack-current.source.bootware.riscos.tools > *. > Dir. > LanMan98::prisRoot.$.scratchbox.users.build.home.build.armedslack-current.source.bootware.riscos.tools > Option 00 (Off) > CSD > LanMan98::prisRoot.$.scratchbox.users.build.home.build.armedslack-current.source.bootware.riscos.tools > Lib. LanMan98:"Unset" > URD LanMan98:"Unset" > listphysmem/bas WR/ source/download WR/ > LanMan98::prisRoot.$.scratchbox.users.build.home.build.armedslack-current.source.bootware.riscos.tools > *listphysmem/bas > Program renumbered > Memory table size = 65536 Page size = 4096 > 2 blocks of DRAM found > 1 block of VRAM found > 2 blocks of ROM found > > Dynamic RAM: > 10000000 16384 pages > 18000000 16384 pages > 32768 pages found > > Video RAM: > 2000000 512 pages > 512 pages found > > ROM: > 0 1024 pages > 1024 pages found > > IO Space: > 3000000 2048 pages > 8000000 32768 pages > 34816 pages found > LanMan98::prisRoot.$.scratchbox.users.build.home.build.armedslack-current.source.bootware.riscos.tools > * Excellent. Which RiscOS version are you running ?? It appears I may have bumped into a RiscOS bug. Alan. From alanh at fairlite.demon.co.uk Wed Apr 11 19:41:54 2007 From: alanh at fairlite.demon.co.uk (Alan Hourihane) Date: Wed, 11 Apr 2007 20:41:54 +0100 Subject: [armedslack] GRUB 1.91 problems In-Reply-To: <1176316237.10079.32.camel@jetpack.demon.co.uk> References: <1175977675.10071.7.camel@localhost> <1176150496.10098.43.camel@localhost> <1176157639.10098.52.camel@localhost> <1176316237.10079.32.camel@jetpack.demon.co.uk> Message-ID: <1176320514.10079.41.camel@jetpack.demon.co.uk> On Wed, 2007-04-11 at 19:30 +0100, Alan Hourihane wrote: > On Wed, 2007-04-11 at 14:54 +0100, Stuart Winter wrote: > > > http://ftp.netbsd.org/pub/NetBSD/arch/arm32/riscos/listphysmem.bas > > > > ATAFS::quana.$ * > > LanMan98::prisRoot.$.scratchbox.users.build.home.build.armedslack-current.source.bootware.riscos.tools > > *. > > Dir. > > LanMan98::prisRoot.$.scratchbox.users.build.home.build.armedslack-current.source.bootware.riscos.tools > > Option 00 (Off) > > CSD > > LanMan98::prisRoot.$.scratchbox.users.build.home.build.armedslack-current.source.bootware.riscos.tools > > Lib. LanMan98:"Unset" > > URD LanMan98:"Unset" > > listphysmem/bas WR/ source/download WR/ > > LanMan98::prisRoot.$.scratchbox.users.build.home.build.armedslack-current.source.bootware.riscos.tools > > *listphysmem/bas > > Program renumbered > > Memory table size = 65536 Page size = 4096 > > 2 blocks of DRAM found > > 1 block of VRAM found > > 2 blocks of ROM found > > > > Dynamic RAM: > > 10000000 16384 pages > > 18000000 16384 pages > > 32768 pages found > > > > Video RAM: > > 2000000 512 pages > > 512 pages found > > > > ROM: > > 0 1024 pages > > 1024 pages found > > > > IO Space: > > 3000000 2048 pages > > 8000000 32768 pages > > 34816 pages found > > LanMan98::prisRoot.$.scratchbox.users.build.home.build.armedslack-current.source.bootware.riscos.tools > > * > > Excellent. Which RiscOS version are you running ?? > > It appears I may have bumped into a RiscOS bug. Nope. But I think I've found the problem now, not RiscOS's fault. Alan. From m-lists at biscuit.org.uk Wed Apr 11 20:25:44 2007 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Wed, 11 Apr 2007 21:25:44 +0100 (BST) Subject: [armedslack] GRUB 1.91 problems In-Reply-To: <1176316237.10079.32.camel@jetpack.demon.co.uk> References: <1175977675.10071.7.camel@localhost> <1176150496.10098.43.camel@localhost> <1176157639.10098.52.camel@localhost> <1176316237.10079.32.camel@jetpack.demon.co.uk> Message-ID: > Excellent. Which RiscOS version are you running ?? RISC OS 4.0.2. From m-lists at biscuit.org.uk Wed Apr 11 20:38:03 2007 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Wed, 11 Apr 2007 21:38:03 +0100 (BST) Subject: [armedslack] RiscPC In-Reply-To: References: <1175977675.10071.7.camel@localhost> <1176150496.10098.43.camel@localhost> <1176157639.10098.52.camel@localhost> <1176316237.10079.32.camel@jetpack.demon.co.uk> Message-ID: The RiscPC has my sympathy - it took a few seconds to even make some symlinks. How I ever natively compiled most of ARMedslack on two RiscPCs in the airing cupboard... Alan - yeah the installer I gave you plus slackb.zip works fine -- this RiscPC is a fresh install of armedslack-current. This one is going to make the new Perl package using distcc to a few fast x86 machines :-) root at zaden:~/ac/source/d/perl# cat /proc/cpuinfo Processor : StrongARM-110 rev 3 (v4l) BogoMIPS : 166.70 Features : swp 26bit fastmult CPU implementer : 0x44 CPU architecture: 4 CPU variant : 0x0 CPU part : 0xa10 CPU revision : 3 Hardware : Acorn-RiscPC Revision : 0000 Serial : 00000050a401dcab root at zaden:~/ac/source/d/perl# uname -a Linux zaden 2.6.20-riscpc #1 Fri Feb 9 08:33:36 GMT 2007 armv4l GNU/Linux root at zaden:~/ac/source/d/perl# From alanh at fairlite.demon.co.uk Wed Apr 11 21:52:36 2007 From: alanh at fairlite.demon.co.uk (Alan Hourihane) Date: Wed, 11 Apr 2007 22:52:36 +0100 Subject: [armedslack] RiscPC In-Reply-To: References: <1175977675.10071.7.camel@localhost> <1176150496.10098.43.camel@localhost> <1176157639.10098.52.camel@localhost> <1176316237.10079.32.camel@jetpack.demon.co.uk> Message-ID: <1176328356.10079.45.camel@jetpack.demon.co.uk> On Wed, 2007-04-11 at 21:38 +0100, Stuart Winter wrote: > The RiscPC has my sympathy - it took a few seconds to even > make some symlinks. How I ever natively compiled most of ARMedslack > on two RiscPCs in the airing cupboard... > > Alan - yeah the installer I gave you plus slackb.zip works fine -- this > RiscPC is a fresh install of armedslack-current. Hooray! I've found the problem and fixed my version of GRUB :-) I'll send Tim the fixes. Alan. From alanh at fairlite.demon.co.uk Fri Apr 13 10:20:45 2007 From: alanh at fairlite.demon.co.uk (Alan Hourihane) Date: Fri, 13 Apr 2007 11:20:45 +0100 Subject: [armedslack] GRUB 2 patch Message-ID: <1176459645.10137.7.camel@jetpack.demon.co.uk> Hello All, Here's the verified fix for grub booting problems on a RiscPC that has 256MB of RAM. The asm.S fix is something I found out from NetBSD's boot scripts and they also workaround it in a similar way. It seems RiscOS 4.x (i'm not sure on which versions) overrun when writing the page table arrangement and allocating this extra memory makes it work. I guess I could test further on what values make sense, but it's only another 128kb, so I'm not worried here. This problem usually causes grub to crash with a backtrace or possibly a data abort. The misc.c fix is because page 65536 is actually valid. And for a RiscPC with 256MB of RAM it's the only page that details the layout. So without knowing about it, we get "out of memory" errors from GRUB. Both these fixes have been verified and work for me. I've BCC'ed Tim to this too, rather than expose his email address on the mailing list. Many thanks to Tim for supporting GRUB on RiscOS in the first place. Alan. -------------- next part -------------- A non-text attachment was scrubbed... Name: grub.patch Type: text/x-patch Size: 1006 bytes Desc: not available URL: From m-lists at biscuit.org.uk Fri Apr 13 16:03:30 2007 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Fri, 13 Apr 2007 17:03:30 +0100 (BST) Subject: [armedslack] GRUB 2 patch In-Reply-To: <1176459645.10137.7.camel@jetpack.demon.co.uk> References: <1176459645.10137.7.camel@jetpack.demon.co.uk> Message-ID: > I've BCC'ed Tim to this too, rather than expose his email address on the > mailing list. Thanks Alan -- I'm building a new installer initrd.img & slackb.zip with the GRUB patch. I'll upload it once I've had time to test it the week after next. From psychicistnonconformist at gmail.com Wed Apr 18 19:23:48 2007 From: psychicistnonconformist at gmail.com (Sunil Amitkumar Janki) Date: Wed, 18 Apr 2007 21:23:48 +0200 Subject: [armedslack] Re: Armedslack X status In-Reply-To: <461CDA7B.6080708@gmail.com> References: <461CDA7B.6080708@gmail.com> Message-ID: <46267044.2030004@gmail.com> I have managed to build mesa with linux-dri support by excluding sis drivers that are x86 specific. So those with 3D graphics adapters will probably be able to use them. Furthermore I have progressed to building x11 apps. After this the x server and drivers will take most time. I probably have to set the schedule back by a week. So all will probably be ready in one and a half week. Cheers, Sunil From psychicistnonconformist at gmail.com Sat Apr 21 11:38:52 2007 From: psychicistnonconformist at gmail.com (Sunil Amitkumar Janki) Date: Sat, 21 Apr 2007 13:38:52 +0200 Subject: [armedslack] Re: Armedslack X status In-Reply-To: <461CDA7B.6080708@gmail.com> References: <461CDA7B.6080708@gmail.com> Message-ID: <4629F7CC.2060403@gmail.com> Hi all, I have looked at the Slackintosh and Alphaslack Xorg scripts and the same build script seems to work for them as well with fixes in the same places where I have done them. I have now completed manually building the base infrastructure of Xorg except drivers, fonts and xorg-docs. I'll sync to the latest Slackware Current as of today and copy the entire X source tree again. After that I'll incorporate ARM specific fixes that I have made. Then I'll run the (huge) build script and keep my fingers crossed that it generates all of the packages correctly this time :-). A nice side-effect will be that Armedslack Xorg will be current with latest Slackware Current so all of KDE and other dependent packages can finally be built. Cheers, Sunil From m-lists at biscuit.org.uk Sat Apr 21 13:22:33 2007 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sat, 21 Apr 2007 14:22:33 +0100 (BST) Subject: [armedslack] Re: Armedslack X status In-Reply-To: <4629F7CC.2060403@gmail.com> References: <461CDA7B.6080708@gmail.com> <4629F7CC.2060403@gmail.com> Message-ID: Hiya > A nice side-effect will be that Armedslack Xorg will be current > with latest Slackware Current so all of KDE and other dependent > packages can finally be built. Ah cool - I've been holding off KDE et al for X -- probably a good thing though since Pat's rebuilding KDE again at the moment. So how will it work so that I can build the X packages for ARMedslack? Will I be able to take your build script and run it on my build host without any existing X stuff installed? or will we still need a pre-package-building script to build & install all of X first? Cheers s. From psychicistnonconformist at gmail.com Sat Apr 21 13:36:30 2007 From: psychicistnonconformist at gmail.com (Sunil Amitkumar Janki) Date: Sat, 21 Apr 2007 15:36:30 +0200 Subject: [armedslack] Re: Armedslack X status In-Reply-To: References: <461CDA7B.6080708@gmail.com> <4629F7CC.2060403@gmail.com> Message-ID: <462A135E.7060100@gmail.com> Stuart Winter wrote: > Ah cool - I've been holding off KDE et al for X -- probably a good thing > though since Pat's rebuilding KDE again at the moment. > > So how will it work so that I can build the X packages for ARMedslack? > Will I be able to take your build script and run it on my build host > without any existing X stuff installed? or will we still need > a pre-package-building script to build & install all of X first? > > > Cheers > s. I now have packages for the base of Xorg and could upload them somewhere. I will have to test if building using the standard build script (including fixes) works and could upload those scripts and fixes as well. This will also result in packages that should be good enough to end up in Armedslack. And of course you could use these feature-complete packages as a base to run the script on your own build system to generate the final packages. But you will need to install them first before doing so. That's why I prefer building in QEMU, although slow the machines are disposable. You could see it more as some kind of bootstrapping like when compiling gcc. Cheers, Sunil From m-lists at biscuit.org.uk Sat Apr 21 18:23:24 2007 From: m-lists at biscuit.org.uk (Stuart Winter) Date: Sat, 21 Apr 2007 19:23:24 +0100 (BST) Subject: [armedslack] Re: Armedslack X status In-Reply-To: <462A135E.7060100@gmail.com> References: <461CDA7B.6080708@gmail.com> <4629F7CC.2060403@gmail.com> <462A135E.7060100@gmail.com> Message-ID: > I now have packages for the base of Xorg and could upload them somewhere. OK I can provide somewhere to upload them to. > But you will need to install them first before doing so. That's why I prefer > building > in QEMU, although slow the machines are disposable. You could see it more as > some > kind of bootstrapping like when compiling gcc. Yeah ok cool :) When you have finished please email me at mozes at slackware.com and I will give you an ftp location to upload to. By the way - I use distcc to my x86 hosts. On the x86 hosts I use this build script: ftp://ftp.slackware.pl/pub/armedslack/armedslack-current/source/x-toolchain which installs it into /opt/arm. On the x86 host I use the Slackware distcc package and in rc.local I put: PATH=/opt/arm/bin /usr/bin/distccd --daemon --allow 0/0 -j20 And on the qemu host I have a wrapper script for the arm/build scripts: #!/bin/bash if [ -f .no-distcc ]; then echo "This source is not to be built with distcc (.no-distcc exists)" ./arm/build else if [ ! -d /tmp/DISTCC ]; then mkdir -p /tmp/DISTCC ( cd /tmp/DISTCC ln -vfs /usr/bin/distcc gcc ln -vfs /usr/bin/distcc cc ln -vfs /usr/bin/distcc g++ ln -vfs /usr/bin/distcc c++ ln -vfs /usr/bin/distcc arm-slackware-linux-c++ ln -vfs /usr/bin/distcc arm-slackware-linux-g++ ln -vfs /usr/bin/distcc arm-slackware-linux-gcc ) fi export DISTCC_HOSTS="192.168.1.74/4 192.168.1.10/2 192.168.1.1 192.168.1.14 192.168.1.2" export CC=distcc PATH=/tmp/DISTCC:$PATH ./arm/build fi It's all a bit hacky but it works like a charm and the builds are much faster! :-) s. From mozes at slackware.com Mon Apr 30 15:16:13 2007 From: mozes at slackware.com (Stuart Winter) Date: Mon, 30 Apr 2007 08:16:13 -0700 (PDT) Subject: [armedslack] armedslack-current updates - 29th Apr Message-ID: Hi I have uploaded updates which include the new X11 packages -- thanks to Sunil for those! :-) rsync -Pavv ftp.slackware.pl::armedslack/armedslack-current s.