Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: Failure on August 11, 2004, 05:05:17 AM
-
Well, I'm probably more pleased with myself than I really should be but...I have installed AMIX 2.01 without a tape drive and without leaving the install script. I used a variation of a method I found in a Usenet post, using dd to copy the install tape "image" to a hard drive. Here is the short, short version (it's late):
* I made a big cpio archive of all the individual cpio files on the tape
* I dd'd this file using the old 1.1 installation (could have used x86 Linux, or AmigaOS...AmigaOS has dd available?) onto a spare HD
* Modified the 2.03 root floppy install script to skip the tape drive, and un-cpio my kludge instead
* Booted the test A3000 into installation with the pseudo tape drive attached externally...went off without a hitch.
* Rebooted into AMIX 2.01 without having done any crap on the CLI to install the kernel, etc, that I noticed had to be done in all these other kludges people came up with...
I actually installed 2.01 by mistake, I'll redo the big ol' cpio using 2.03 files. Should work identically. It's a nasty kludge, what I did, but it works and since most people won't have the A3070 tape drive, it's a nice solution. Should be able to be done using only AmigaOS to prep for it.
Anyway I'll document more on it in the next day or so, I was just so happy I wanted to post something right away ;-)
Here's some pics just for fun:
The rig, ugly but works...I used the A3070 case to mount the HD inside (http://failsure.net/~failure/img/dscf0159.jpg)
My kludge working, I had it echo filenames so I could tell if it hung (http://failsure.net/~failure/img/dscf0158.jpg)
Installation completed, time to reboot! (http://failsure.net/~failure/img/dscf0160.jpg)
And here it is, with a shot of some of the post-install config (http://failsure.net/~failure/img/dscf0161.jpg)
-
Can you take a picture with the X Window server booted? :-)
I wish they still made these Amiga 3000UX. For some unknown reason, I want one. :-(
-
Now there's a nice coincidence!
I've been looking for simple information on how to install AMIX all night. I'd nearly given up, when I said to myself, "Well, let me just check in at Amiga.org and see if there's anything new." Lo and behold, there is!
I'd be extremely grateful if you could post a detailed guide. There's nothing of the sort out there right now. Yours actually looks to be the easiest method out there since it doesn't require access to 3+ different OSes. :-)
I've found the AMIX patches on the Gateway CD (v.2). The documentation is mediocre, but present. There are some patches for older Zorro2 RTG boards (PicassoII, most notably, with blitter support!), Ariadne, and GVP SCSI. The catch is that they're written for AMIX 2.1c, so getting them working in a 2.03 environment could be tough/impossible. I'll double check the distribution guidelines tomorrow and then hopefully upload them a bit later.
-
Yes, please do a real tutorial on how to install AMIX. :-)
-
I was planning on doing a guide on getting AMIX installed via this method, I want to clean up one or two things in the script first and get 2.03 installed. Mostly I want to get rid of a couple error messages that might be alarming to new users, since they are unimportant with the new installation method.
I've been going through the 2.03 archives and, unfortunately, a number of the cpio files are corrupt :-( These are the sysadm package, emacs, X extras, and all the source code except the Amiga-specific. I plan on using the 2.01 versions of all of these, since there should only be minor changes and the source code (except Amiga-specific!) is likely of dubious importance anyway since it's really, really old. Everything else seems to be good.
I can't find 2.1 media anywhere; 2.1c is, I believe, the last release of AMIX ever (obtained by installing base 2.1, followed by the patch disk to 2.1c). I have come across references of people downloading it off the internet, but I certainly can't find it now.
2.01 is already way way better than 1.1. For example, "w" works properly :-)
-
What are you using to extract the 2.03 archives? I got variable results depending on what I used. DOpus4.16 chokes on them, but OS3.9's Unarc seemed to do a better job. I have no way of actual testing, but DOpus often extracted a file of 0 bytes from a 7K archive, while Unarc actually found some data.
-
@Failure: Sounds great, keep up the good work. :-)
-
Hmm. I'm not sure what you mean. I'm using unzip on Linux to uncompress the archive, AMIX203.ZIP, which contains a bunch of cpio files (i_01.cpio.gz - i_27.cpio.gz) and several of these are bad when I attempt to extract them with cpio. After uncompressing them of course.
Do you maybe have a different archive, with maybe files that work? :-D
*edit* the files I have are the ones from the mmhart.com site
-
I fixed the error messages in the install script, and installed 2.03 last night, so I wrote up how to do it:
AMIX installation instructions (http://amix.failsure.net/tiki-index.php?page=dd+Install)
The only thing I wasn't sure of was how to write the cpio file to the drive in AmigaOS, hopefully someone here can help with that. From reading the install script, it seems that AMIX can also run on a machine with 1.3 ROMs and 2620/2630 card.
Best of luck to those that try this!
As a side note, when the 3000UX with the large HD failed to boot (described in the instructions) it came up with a weird boot screen, it said "Version 1.4 Beta, do not distribute" with the animated floppy drive. I had never seen that before.
-
Failure wrote:
From reading the install script, it seems that AMIX can also run on a machine with 1.3 ROMs and 2620/2630 card.
Yep, on the A2500UX.
-
@ Failure
Ah. If the archives are failing under Linux, then they're probably corrupt. I was having trouble getting them extracted on the Amiga side, which I thought could have been due to differences/bugs in the Amiga implementation of cpio/zip/gz/etc.
Thanks for writing that install guide!
EDIT: As for the 1.4 Kickstart screen, it seems like you've got a very early version of the A3000 boot ROMs! You might want to save a image of that kickstart :-)
Mine are strange - They come up as 36.016 by default, but sometimes as 36.143 after a failed boot. They always say "2.0 ROMs," though.
-
@Failure: Found some files, maybe you´re interested in them. Sent you an e-mail. :-)
-
As a side note, when the 3000UX with the large HD failed to boot (described in the instructions) it came up with a weird boot screen, it said "Version 1.4 Beta, do not distribute" with the animated floppy drive. I had never seen that before.
That's the one Kickstart image I've been trying to find for quite a long time, incidentally. I've acquired a copy of several other 1.4 and 2.0 betas, but this particular build has window gadgets that I haven't seen in any other build, and I'm curious what else is different. Perhaps you should try to get a copy of the ROM dumped (would a standard Kick grabber work? I don't know if this particular 1.4 build included the bonus code or not). I'm not asking you for a copy of the ROM image here, since that's technically illegal. If nothing else, it should be dumped for preservation, even if it's not distributed, since several A3000's have hardware 2.0 ROMs or later (such as mine).
This ROM is also accessible on the earlier A3000s that came with both 1.3 and 2.0 - if you fudge around where a close gadget would be on the OS selection screen, it should eventually boot to the 1.4 hardware ROM.
-
Just out of curiousity will AMIX boot with 3.0 or 3.1 ROMs?
-
I've been busy :-)
I made a new version of the install disk that allows you to select the SCSI ID and partition to get the install media from. Now it is possible to install using only one drive! I haven't updated the documentation yet, but it's pretty easy, basically make a partition (I recommend at the front of the drive) as FFS but do not format it. AMIX ignores AmigaOS partitions, so it won't get zapped. dd the cpio archive to the partition, reboot using the AMIX floppies, and tell the installer where you put it...and off it goes. When the install finishes, you can wipe out that partition and install AmigaOS on it if you like, or use it for UNIX. I also had the script copy cpio to the hard disk and use that for extraction, as constantly going back to the floppy for it slows the install down.
I stuck 3.1 ROMs in the 3000UX and AMIX still booted fine, so that works. The 3000 the ROMs came out of is apart for soldering...
And LocalH (pack up the cats!) is right, the window gadgets were...weird for that 1.4 beta. I dumped a ROM image for posterity.
Finally, I did locate dd for AmigaOS on Aminet, as dd.lzh. So it should definitely be possible now to install AMIX using only AmigaOS to prep for it.
I'll update the docs time permitting. I'd love to hear about someone doing this with just AmigaOS.
-
It should be possible to write s5 and UFS filesystem handlers for AmigaOS, but they would cause a conflict if BSD or Linux were installed, as they all use the UNI\? partition types to mean different things. But I think it goes like this for AMIX:
UNI\1 s5
UNI\2 swap
UNI\3 UFS
Can anyone confirm?
Does AMIX recognize SCSI CD-ROM drives on /dev? If so, it should also be possible to port and/or compile the SVR4 Filesystem Survival Kit for AMIX to provide ISO9660 support. But I'm not a UNIX guru, and I don't know how AMIX handles kernel changes.
EDIT: I may be way off on my s5/UFS talk. I'm just going on what I've read here and there. I haven't actually used AMIX. ;-)
Trev
-
YEY! I have Amix 2.03 running on my A3000 using your guide Failure. Fantastic. I created the "Tape" image on the hard drive from Amiga OS, and I'll write up what I did. Thanks for you efforts on this. Now to find more stuff to load on it. Look forward to hearing from me Soon(tm). :-D
-
Just curious, are there any actual differences between a bogstandard 3000 and a 3000UX :-? (apart from a decal on the case and the tape drive).
-
any actual differences between a bogstandard 3000 and a 3000UX
nope
-
So for the Amiga OS install here is what I did:
Started with:
-two blank Harddisks in the system, each 2GB
-CDROM containing the extracted cpio files, floppy images, and dd utility for AmigaOS from Aminet
-AmigaOS 3.9 Emergency Boot Floppy for this system
I booted the system with the Emergency Floppy and put the CD of the AMIX source files in the drive. I followed the instructions on Failure's site to create partitions. I then copied the files to the first harddisk (SCSI 0) and replaced the AmigaOS3.9 CDROM when it was complete. Ran Shell and changed to the folder where the files were copied to and ran:
dd -c145834496b -wCDH0 amix-2.03.cpio
I went somewhere else for 2 hours while the raw write hit the CDH0 drive (SCSI 1, the "Tape" for the install of AMIX in my system). When this was complete I used transdisk to write the two floppy images from Failure's web site.
I followed the install instructions on the web site and it worked great! I will say that my root file system is on a 1GB partition and I know Failure reported it didn't boot on his with a 1.3GB partition. The 1GB boots. The root file system installed on SCSI 0 disk which is the same disk that I copied the files to temporarily during the raw write phase. I allowed AMIX to overwrite all the data on that disk.
I'm happy. I've been trying to get this loaded for months. Many thanks again Failure! :-D
-
Damn, Amix is way cool, but that would mean I have to get rid of the cyberstorm 040 (wont boot on it, right?) and the 128MB of ram on it... So, I'll stick with NetBSD on that miggy for the time being, unless I can get my hands on another A3000...
-
Congratulations Dalamar, I am very happy that this can be accomplished with AmigaOS :-)
Someone had requested pics of X running...getting xdm going was tricky/archaic. Once I figured out what was wrong, finding the solution didn't take too terribly long. But look at this user-friendly way to enable xdm:
pmadm -d -p screens -s con10
sacadm -a -p xdm -t xdm -v1 -c /usr/X/bin/xdm
pmadm is "port monitor" admin tool...I found a lot of posts from bitter Solaris users about this gem. sacadm, couldn't tell you. In addition, the /usr/X/lib/xdm/Xsession file was not set executable, so logins would give you a crappy xterm and no window management. Making the file executable got twm going, but without the never-gonna-find-one-A2410 card the display is so small, and in 1-bit color, so that the experience is fairly "meh".
Behold the xdm login screen in all its 1-bit glory:
Ta-daah! (http://failsure.net/~failure/img/DSCF0162.JPG)
Yeah not so exciting. But this is X, so we don't have to be limited by that video hardware since we have the network.
xdm in 24 bit color! (http://failsure.net/~failure/img/DSCF0168.JPG)
Well, that's only really 4 colors but it *could* be displaying millions if it really wanted to! That's an X server on a Linux box talking to the xdm on the Amiga. I was actually surprised how responsive this was. For graphical applications (to use the term loosely, I'm talking about xeyes here) the network was faster at rendering than on the Amiga locally.
X session over the network (http://failsure.net/~failure/img/DSCF0171.JPG)
For some reason applications that generate color do not display at all, but color is working since I set the background color in AMIX and you can see the windows are a different color. I think it might work if I run at 8-bit depth. I had similar problems with old Solaris apps.
Fun stuff. You have to respect open standards like X11. These two machines talking to each other, it would be like Windows 3.11 displaying applications natively on a Windows Server 2003 machine, in terms of the age difference.
-
Thanks for your work on making this go. X is my next project. It's been quite some time since I made X work the "manual" way. I must admit I'm confused that X can only display 1 bit color given the builtin Amiga graphics. I would think it would be capable of more, but then again I'm not an expert in AMIX.
Have you tried to upgrade the C compiler? I'm trying to find a build of PERL to put on there and I think a newer compiler might be a good idea.
-
Yeah I am trying to go about that now. I had to get the screen utility first so that I can log out during the few days this process is likely to take ;-) Screen didn't compile under 1.1 but it did fine with 2.03, happily. There is actually one included with AMIX but it doesn't work, at least from a telnet session.
I figure on attempting gcc 2.95-ish since that is widely regarded as "stable", and if that works maybe try the 3.x.x. I wonder though if I have enough HD space, I might need to reinstall on that 4GB drive with the 1GB partition that you found works.
Matt_H gave me some more info to chew on regarding installation from AmigaOS, including a possibly easier dd alternative. Maybe he will chime in later :-)
For now I am considering creating some kind of mechanism on the AMIX site to prevent duplication of effort on compiling things, since it takes such a long time on these machines. Not sure what to do yet. But I made a new file gallery and stuck screen in there, pre-compiled.
*edit* it goes without saying, but really don't forget to strip the binaries...it shaved 1.4MB off of screen, which goes a long way with 8MB memory!
-
*Chime*
Here follows my massive AMIX install report.
Main Hardware:
Amiga 3000, 030/16MHz+881
1.4 BootROMs, Kickstart 2.04 on hard drive
2MB Chip, 12MB Fast
~1GB Fujitsu hard drive
a whole mess of external SCSI devices
Support Hardware:
Amiga 1200 060/50 w/ SCSI Kit
3.1 ROMs
2MB Chip, 96MB Fast
Q-Drive CD-ROM Drive
Software:
Clean install of Workbench2.1 + DOpus 4.11
Replaced 2.1 HDToolbox with one from 3.1
Following Failure's report of a working AMIX box, I was inspired to bring the spare A3000 that had been sitting in my basement into service again. My initial search for information came from the mmhart site. I downloaded various sets of boot disks, tape images, and the AMIX manuals.
Reading further, I discovered that this would be a lot harder than I thought. I decided to put the software aside for a while, and familiarize myself with UNIX a bit more. I started reading the manuals. Thankfully, they contained information about a possible default partition table.
AMIX's rdb program for repartitioning the drive looked very intimidating to a non-UNIX user like myself, so I decided to take care of partitioning under AmigaOS. The HDToolbox that shipped with 3.1 thankfully has a preset filesystem option for UNIX (UNI\01). From the start of the drive, I created a 449MB Unix_Root partition, an 18MB Unix_Swap partition, and a 10MB Unix_Boot partition. I then added a 40MB WB_2.x partition, and a 512MB Work partition.
I decided to boot up the floppy images from the mmhart site. They worked, but of course would not do anything without a tape drive. I read more and more information from Usenet, and the possibilities of getting AMIX installed with my hardware seemed to dim.
I tried writing a kernal image to Unix_Boot with dd, but ended up destroying the RDB. Thankfully, putting the exact same settings back into HDToolbox restored my data. Having to reinstall AmigaOS wouldn't have been terrible, but it would have been annoying.
Then Failure reappeared on the scene with the shiny, new, single-file install image. Hooray! I broke out a spare SCSI hard drive, and wrote the image to it. Or rather, I tried. Something about this drive caused the 1200 to hang, so I don't even know if the image was successfully written. No problem, I said; I'll just use a cartridge drive.
Unfortunately, the install image was juuuuuust slightly too big for my SyQuest 135 drive. I found a Nomai 750 drive to use, but due to some SCSI cabling issues, I had to daisy-chain it off the SyQuest.
I connected the SCSI chain to the 1200. While browsing around the Gateway! CDs earlier, I came across a raw-write program called dcp, with the same functionality of dd, plus a few more perks, and a lot more user-friendliness. I had it write the image to 1230scsi.device, unit 1. It didn't work, saying I didn't specify a unit number. Ah, clearly I did, so there must have been a bug in the program. Thankfully, it's also bundled in bffs.lha (a filesystem to read UNIX drives on an Amiga) on Aminet, and at a higher version. New version worked perfectly. I connected the SCSI chain to the 3000, and booted from the install disks.
And the installer hung when it tried to read what devices were on the SCSI bus. Several hours later, after declaring that the problem could not possibly be a termination issue, I threw a switch on the drive to disable synchronous transfers, and I finally was back in business. Note that before throwing the switch, ENABLING synchronous transfers using SCSI Prefs under AmigaOS, did not help.
Finally I was ready to boot. I selected my install media drive, and the drive to install to. The installer found my partition table, pronounced it usable, and started chugging away. And failed. I tried again. And failed. I rewrote the image to the Nomai, and THEN it worked. Apparently I had accidentally clobbered it while fiddling with HDToolbox.
It finished installing sometime later and told me to reboot. So I did - to a purple "Insert Workbench Disk" screen. Throwing in a SuperKickstart disk allowed me to reach 2.04's Early Boot Menu. My hard drive had vanished. I powered down, disconnected the external SCSI chain, and tried again. Back in business.
The AMIX post-install completed nicely, but the install script's clock-setter choked on a >2000 year, and set the date to 1970. Thankfully the normal clock command is Y2K compliant. The script also asked me about network settings and node names. I don't have a network card for the 3000, so figured it didn't matter too much what I filled in for these values. It also offered to create user and guest accounts for me, a welcome addition, since the AMIX manuals only mention how to add users manually, and as a UNIX beginner, I wasn't looking forward to that. These same scripts can also be run again later to easily change settings.
So the system is up, though I get a strange "date: bad conversion" reminder whenever the system boots. Very odd, though it doesn't seem to have any ill effects that I can notice.
I also got BFFS going today, which allows the Amiga side to play with UNIX partitions. If you've installed AMIX or dealt with UNIX before, you'll definitely be able to configure BFFS. Don't change the filesystem identifier, though. It doesn't work. For the record, I installed AMIX with ufs, I don't know how well BFFS works with the s5 filesystem. The readme says it should, but it's not really tested.
As a final note, no, I did not get AMIX installed using only one system, though I did get it going with only one platform :-). With a slightly more up to spec 3000 (3.1 ROMs, 030/25+882, 16MB Fast, internet access), this could easily be done on one machine.
Thanks to Failure's updated (v2) Install floppies, at this point I could now dump the AMIX image to a spare partition on the 3000's drive (thinking of reducing Work:, as I already have primary and secondary Amigas and probably won't need the space here). That'll make reinstalling VERY easy if the need arises. I've broken several Linux installs to a level beyond my expertise to fix in the past, so it's only a matter of time before I mess up AMIX. ;-)
-
Very nice Matt_H,
I'm doing a reinstall now to test a theory (which I'll keep to myself until it works :-) ) but I just wanted to *ring* in and say that I tried the v2 method and made a BIG mess. Be cautious. :-o
-
I just want to say very good work on the part of all of those involved - I can remember when the only info one could find on AMIX, was a JPG photograph of the install media, and nowhere was there a dumped version available.
Then, I (as did many others) came across mmhart's site, which was the first place I actually saw AMIX for download. And now, we actually have people who have gotten it installed. Perhaps if I can get my A3000 to recognize all its RAM (right now it only sees it's 1MB chip, none of the fast), I'll attempt to get this stuff set up. Too bad that X doesn't seem to support more than 1-bit color (as I am completely unfamiliar with non-XF86 X servers, I would have no idea where the equivalent of XF86Config is located). Still, this is quite interesting. I wonder if that MMU-enabled version of UAE might be sufficient to install it...unlikely, but who knows.
Once again, congrats to all, you're preserving history, and I applaud you for it.
A question - has anyone tried to see if standard SCSI CD-ROM drives work, either for use as an install medium (unlikely, I would think), or simply after a successful install?
-
Just to share, I installed on a 2GB root partition and it works. I'll post my configs later.
-
gcc 3.4 series will be the last that possibly compiles on AMIX:
http://gcc.gnu.org/gcc-3.4/changes.html#obsolete_systems
:-(
Struggling to get 2.95 compiled; the version of make with AMIX segfaults and dumps core so I am trying to get a newer version of make compiled. It's like a kind of version hop-scotch here.
*edit* got GNU make 3.70 to compile (none newer I tried would compile), and it handles the gcc makefile...it's on its way...
*edit2* gcc 2.4.5 compiled, is now compiling itself again :-)
-
Update on the clock issues mentioned in my report:
AMIX is not setting the clock correctly. I booted into the Amiga side yesterday and found the hardware clock set to 3:00AM in 2010:-o. Apparently the "date: bad conversion" error is more serious than I thought.
I rebooted into AMIX today and found the clock set to 5 minutes before midnight yesterday (If that makes sense...). From what I can tell, date is executed (incorrectly) in the AMIX equivalent of the startup-sequence (before the login prompt appears), though I don't know what that file is.
The other possibility is that AMIX is a lot more sensitive to a bad clock battery than AmigaOS is. As mentioned in another thread, my A3000 battery is near-death (keeping an eye on it in case it starts leaking), and I'll be replacing it shortly. Hopefully a few problems will resolve themselves.
-
The file you speak of is /etc/sysinit. :-) Not sure what's going on except that the setclk util isnt y2k compliant perhaps.
-
Yeah. I was trying to adjust the clock from sysadm and it kept telling me the date was invalid. Looks like we've got a Y2K problem indeed. :-(
If it's just that one program, though, maybe it could be easily replaced with a fixed one.
-
Found this in a USENET post:
Thank you for suggestions. After replacing the battery and the crystal
and checking that the generator is running when power is off, I found
that clock was running all the time! The problem was in AMIX 2.1, which
has the Y2K bug :) I feel so stupid! Is this problem documented
somewhere? Is it possible to circumvent the Y2K bug? The faulty program
is the one used for reading the NVRAM clock. I think it is named 'setclk'.
If you look at this post from Commodore and notice the required format for the date command I think it shows they were only expecting 2 digit years:
http://groups.google.com/groups?q=setclk+Amiga&hl=en&lr=&ie=UTF-8&selm=1992Oct3.031754.1826%40mirchi.uucp&rnum=5 (http://groups.google.com/groups?q=setclk+Amiga&hl=en&lr=&ie=UTF-8&selm=1992Oct3.031754.1826%40mirchi.uucp&rnum=5)
I'd say my previous post holds true. The sysadm utility doesn't accept the date if you try to put it in using that tool. That's a glaring bug I'm afraid. Oh well, just don't turn the system off. :-)
-
Hmm. I dunno, my time stays correct between reboots, but I don't turn the thing off (My 3000UX has no battery). However, if it *is* the setclk utility, take a look in /usr/amiga/src/cmd/setclk *edit* setclk appears to be the equivalent of hwclock in Linux (ie, hwclock --systohc), so it's certainly the cause of the problem.
I get the "bad date conversion" but again, my time stays correct. I will reboot the machine in just a minute because now I am curious if it shifts at all.
I got gcc 2.4.5 to compile itself, so I uploaded it as a cpio package to my AMIX site. Next is 2.95 which I will let go overnight, I don't hold much hope for it compiling all the way but it should at least get farther than it did with...uh...gcc 1.4.0 or whatever it is. It's so old, the version number is faded.
*badum-ching!*
Thank you, I'll be here all week. Try the tuna.
-
Excellent. I'll download that when you upload it.
The time stays true until it's powered off so I would say that rebooting will definitely show that the clock keeps time. ;-)
-
Argh. I appear to have hit a roadblock compiling gcc 2.95: running into a memory limit. I only have 8 meg and 30 meg swap, and for some reason it fails on this step:
gcc -DIN_GCC -g -O2 -DHAVE_CONFIG_H -o cc1 toplev.o version.o tree.o print-tree.o stor-layout.o fold-const.o function.o stmt.o except.o expr.o calls.o expmed.o explow.o optabs.o intl.o varasm.o rtl.o print-rtl.o rtlanal.o emit-rtl.o genrtl.o real.o dbxout.o sdbout.o dwarfout.o dwarf2out.o xcoffout.o bitmap.o alias.o gcse.o integrate.o jump.o cse.o loop.o unroll.o flow.o stupid.o combine.o varray.o regclass.o regmove.o local-alloc.o global.o reload.o reload1.o caller-save.o insn-peep.o reorg.o sched.o final.o recog.o reg-stack.o insn-opinit.o insn-recog.o insn-extract.o insn-output.o insn-emit.o lcm.o profile.o insn-attrtab.o m68k.o getpwd.o convert.o mbchar.o dyn-string.o splay-tree.o graph.o sbitmap.o resource.o hash.o c-parse.o c-lang.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-iterate.o obstack.o ../libiberty/libiberty.a
ld: cc1: libelf error: Memory error: output file space elf_update:
make[1]: *** [cc1] Error 1
make[1]: Leaving directory `/usr/src/gcc-2.95.3/gcc'
make: *** [all-gcc] Error 1
Uh...heh. Yeah, so I am trying to figure out how to remove the limits (viewable by ulimit -a) so this will work. This is a bit dangerous since I have such limited memory. I'd like to buy more ZIPs but they're not on pricewatch :-) Well if I crash it doing this, is anybody running with 16MB or > 30MB swap?
And I need to reinstall on a bigger drive, I'm running out of HD space too.
*snif* :-(
The good news is, gcc 2.95 is more or less compiled!
*edit* hmm probably need a new thread for this, since it's nothing to do with installation
-
Have you tried cross-compiling from another system that has more RAM etc?
-
I have not, but I am planning on doing that as soon as I get as far up the compiler version chain as I can...it's not a trivial process (crossing both arch *and* OS), so I want to avoid doing it more than once. Reading the docs to do it with 2.4.5 makes me sweat a little but I think I could do it, although I don't want to. I'd like one of the guys with 16MB to try it first!
If it continues to not work, I'm not sure whether to just stop at 2.4.5, try something less than 2.95.3, or go through the hassle of the cross compiler.
From this post, it clearly continues to fail even after I removed all system limits...
-
I have 16 installed. :-) Do you want to put up what you have and let me give it a try?
-
Yeah I'll do that if my next attempt doesn't work. I noticed the ld that the system was using isn't GNU, and is also in excess of 14 years old. So I am compiling the latest GNU binutils, and will try with that...if I am right, it would have failed with 16MB anyway.
-
Building a Linux or Cygwin m68k-amigaos cross is pretty straightforward, so I can't imagine a Linux or Cygwin m68k-sysv4 cross being much different. And since a sysv4 cross shouldn't require patching the gcc sources. . . . Sounds like a project.
[color=FF0000]EDIT: The m68k*-sysv4 targets were removed quite some time ago, and from what I've read, AMIX doesn't properly support the m68k-elf application binary interface. D'oh![/color]
I've also been toying with adding MMU support to WinUAE. I'm using the uae-8.20 MMU patches as a starting point. The code compiles (good start), but I've still got logic errors to work out. WinUAE's CPU emulation has changed non-trivially since uae-8.20.0. And Toni should be releasing a new source snapshot soon, so there's that to contend with as well.
Trev
-
@Trev:
Good luck on your MMU work, it's possible that this might enable the 3000's 1.4 boot ROM to work as well - currently, all I get is a flashing grey or white screen with 020/040, JIT or not, and a solid grey screen with 000/010. The ROM I have is 512KB, I don't know if there's supposed to be bonus code or not.
Also, if I can get my A3000 to recognize it's fast RAM, or get another one, I might attempt to install AMIX using a CD-ROM drive instead of the single- or dual-hard drive methods. I would imagine the main difficulty would be burning the CD in the same raw fashion - perhaps using the cpio file as a bin, and writing a cuesheet for it, will work. As I have no way to burn CDs from my Amiga, I'd be burning the CD on my PC, but if I can get it to burn as a bin/cue, then it might work.
-
@LocalH
I'd use a native version of cdrtools (http://www.fokus.fhg.de/research/cc/glone/employees/joerg.schilling/private/cdrecord.html).
And I don't have a copy of the 1.4 ROM, but I guess that would be the best place to start if my intention is to get AMIX running on WinUAE.
-
@Trev:
Well, as I mentioned, I do have a copy of the 1.4 ROM, and it does not work within WinUAE currently. The ROM is a solid 512K and lacks bonus code, unless the 1.4 ROM was relinked and the bonus code is within the first 512K (this is plausible, as the end of the ROM has text dealing with the OS boot screen), and thus the ROM doesn't need to be larger than 512K as the later ROMs with bonus code do.
WinUAE lacks emulation of one or more A3000 hardware components that this particular 1.4 ROM requires, I believe. Since it was dumped with a regular Kickstart dumper, it should reside at $F80000, whether in the physical memory map (as I would likely believe), or via MMU. Without investigating, I am thinking that MMU emulation might allow the ROM to boot. I will try setting up some hardfiles and name them correctly, but I doubt that will work, as even without the HD partitions I should at least see the purple 'insert disk' screen.
-
It might be useful to note that AMIX doesn't depend on ROM 1.4, but works fine even on 3.1 ROMs. Not that I'm trying to say getting 1.4 working in WinUAE is pointless, just that it isn't necessary for AMIX.
I played around a little with the UAE MMU patch, but wasn't able to do anything with it. But I am a really poor programmer so I am pretty sure the hacks I was doing to get the MMU to "work" on 68020 were completely bogus. IIRC, the MMU in that patch is for 68040 which is simpler than the MMU in the 68030 although I do not know the specifics of it. There is a thread I started around here somewhere on that topic.
Back to my gcc 2.95.3 problems, GNU binutils won't compile since there is no m68k-cbm-sysv4 target for ld or gas. So I gave up on that. Further Usenet searching reveals that the problem really might just be memory, like I originally thought, so I'm gonna put the partially compiled sources online and hopefully Dalamar (with perhaps more than 30MB swap) will have better luck.
I am still having a good time but I wish they made a 300MHz 68030 :-)
-
@LocalH
Yes, I think some hacking of UAE's expansion interface will be necessary to provide support for all the hardware Amix expects to see. The downside is that UAE provides device driver emulation for most of its hardware. This definitely isn't a small project.
-
After a bit of futzing around, I am rewarded with this:
# ./xgcc -v
Using builtin specs.
gcc version 2.95.3 20010315 (release)
Still not done compiling all the other stuff, 25MHz is slooooow for all this code. One of the unfortunate aspects of working with AMIX is these lengthy compiles...I start the compilation in a screen session, log out, come back some hours later and it has errored out on something. On the bright side, I replaced the HD in the machine when I reinstalled, so I have 100MB swap and everything is faster since the HD is a better one. In particular, multitasking was helped. It used to take several seconds to get a login via telnet if the machine was compiling, now it is very fast.
This compile is using m68k-cbm-sysv4 as a target and at least for gcc, it works fine.
Hey I know what I need! distcc! :-)
-
Hi,
I was reading this thread and I thought "COOL!" Just to read about this makes you want to go out and buy the stuff it needs to get it done. I found a site on the internet about this too. Check:
http://www.mmhart.com/AMIX.htm
I have no idea if this guy is here on Amiga.org
If not maybe we should drop him a note. There is some info on that site which might interest some people.
Coder
-
I have just finished a rewrite of the installation documentation incorporating the new information re: installing using AmigaOS to prepare (thanks to Matt and Dal), along with installation using a single HD and more detailed information regarding pitfalls in the installation process.
I am really tired so I probably made some mistakes or weird statements, it's a wiki so feel free to fix them!
http://amix.failsure.net/tiki-index.php?page=dd+Install
Enjoy and as usual, best of luck to anybody who gives this a shot.
Brief status update on gcc. My AMIX box has been compiling for about 5 straight days. gcc-2.95.3 is going to take more work, so I am jumping from version to version up from 2.4.5 until it breaks. I am compiling 2.7.2.3 now, 2.5.8 and 2.6.3 compiled fine as well.