Installation instructions for Linux on the MVME147 board NOTE: This MVME147 port is considerably less well tested than my ports to other boards, and so there may be a few surprises for you! This note is not supposed to be complete instructions for loading linux on to your MVME147 - you need to read the other notes referenced on my web page also. The first problem you have with the MVME147 board is that the Bug PROMs do not support TFTP as a means of loading the kernel. Your options are to either (a) write the kernel to a disk sectors on some other system and then use 147Bug to read it in to memory, or (b) use the sboot utility to load the kernel via TFTP. sboot is code I picked up from a NetBSD site, developed by Charles D. Cranor and Seth Widoff - I have only made small modifications to it. Of course, you can load the whole kernel as srecords, but that is kind of slow. In the sboot package on my website you will find sboot.srec; this is a Motorola s-record file which you load in to memory via the serial port. You do this by entering 'lo 0' and then using the capabilities of your terminal emulator to send the contents of sboot.srec just as though you were typing them in at the terminal. I use minicom from my Linux PC, and am able to type 'lo 0', then exit minicom and type 'cat sboot.srec > /dev/ttyS2', before reconnecting with minicom - YMMV. Running sboot seems to force the console port to 9600 baud, which can be a pain if you run at 19200 by default. Must be easy to fix, I just havn't got round to it. The srecords load at address 0x8000, and use up to 0x10000 for workspace. The sequence for running sboot goes something like this: 147-Bug>g 8000 Effective address: 00008000 sboot: serial line bootstrap program (&end = ad80) >>> i // initialise chip le0: ethernet address: 8:0:3e:a5:a5:a5 >>> a // reverse arp My ip address is: 10.1.1.7 Server ip address is: 10.1.1.1 >>> l 10000 /tftpboot/vm147 // load a file aee00 Download was a success! >>> e // exit to 147Bug Having got your ethernet address from the 'i' command, you have to add entries to the RARP and ARP caches on your TFTP server, like so: rarp -s mvme147 08:00:3e:a5:a5:a5 arp -s mvme147 08:00:3e:a5:a5:a5 The 'a' command will then do an RARP request to find its IP address. Try this now with a simple file, and then use the 147Bug 'MD 10000' command to see that the file loaded OK. Before you can load your kernel, you must configure it with 16xcfg. NOTE you must use a version of 16xcfg from 981129, or later, as earlier ones did not support MVME147. 16xcfg writes a code module, loader.bin, in to the kernel image; you must use a recent (981129 or later) version of loader.bin also. A suitable loader.bin is included in the 16xcfg package, so that souldn't cause problems. For the 2.2.8 kernel I used the following data with 16xcfg: (for a local disk root file system) KERNEL 2.1 MACHINE MVME147 CPUTYPE 68030 FPU Yes RAMSIZE 0x01000000 RDBASE 0x00000000 RDSIZE 0x00000000 CMNDLINE root=/dev/sda1 ro console=ttyS0,19200 (for an nfs mounted root filesystem) KERNEL 2.1 MACHINE MVME147 CPUTYPE 68030 FPU Yes RAMSIZE 0x01000000 RDBASE 0x00000000 RDSIZE 0x00000000 CMNDLINE root=/dev/nfs nfsroot=10.1.1.1:/tftpboot/debian-fs ip=10.1.1.7:10.1.1.1:::nfs68k::off rw console=ttyS0,19200 I havn't tried to configure a 2.2 kernel with a ramdisk using 16xcfg. Having configured your kernel, see 16xcfg.txt for help, load it in to memory at 0x10000 as detailed above. Next start the kernel with 'go 10800'. The boot process first moves the whole file down to address 0 (overwriting the 147Bug workspace), moves the ramdisk (if present) to the correct address, and then moves the various sections of the ELF kernel image to the correct addresses. Finally it does a jump to 0x1000 to enter the kernel proper: 147-Bug>g 10800 Effective address: 00010800 ABCDJKLMN Bootinfo: machtype=0x7 cputype=0x42 Ramdisk size=0x0 addr=0x0 Command Line= Memory: NumBlocks=1 Block 1: size=0x1000000 addr=0x0 DEBUG: request_irq: irq=0x48 flags=0x2 devname=timer 1 handler=0x5e54 Calibrating delay loop.. ok - 3.92 BogoMIPS Memory: 15416k/16384k available (476k kernel code, 492k data) Swansea University Computer Society NET3.035 for Linux 2.0 NET3: Unix domain sockets 0.13 for Linux NET3.035. Swansea University Computer Society TCP/IP for NET3.034 IP Protocols: ICMP, UDP, TCP Linux version 2.0.33pl1 (richard@rgh68k) (gcc version 2.7.2.3) #10 Sun Nov 29 21 :50:51 GMT 1998 Starting kswapd v 1.4.2.2 .... On my system, at least, the SCSI chip seems to fail to generate selection timeouts for invalid SCSI IDs. The higher level software times out, and the system does boot eventually, but it does seems to need a key press on the console after mounting the root filesystem - otherwise it hangs. I think the failure to generate a selection timeout is a result of some missing initialisation in the driver. If I boot from local disk (so 147Bug inisitalises the chip) I don't get a problem. If I boot with an NFS root filesystem (or from a ramdisk, I guess) then I do see this problem. If some SCSI devices give trouble, you can add 'wd33c93=ignore:0xfe' to the CMNDLINE under 16xcfg - that makes it ignore all but SCSI ID 0. Once you have your system up and running you should switch to using VMELILO. My vmelilo.conf reads: [options] default = Linux boot = /dev/sda delay = 2 debug = False [boot] label = 228-147 image = /vm228-147 cmdline = root=/dev/sda1 ro console=ttyS0,19200 wd33c93=disconnect:0 memsize = 16M I'm lucky enough to have 32MB on my 147 board, but I limit it to 16MB because I havn't checked how the 16MB DMA limit on the ethernet driver works with > 16M of memory. Note also the 'wd33c93=disconnect:0' parameter - my board doesn't work with multiple SCSI devices if you allow disconnect/reselect on the SCSI bus. I disable the feature with that option, and it then works fine with two disks active. As this is a new port, I am especially interested to hear from people who try it. Positive as well as negative reports are most welcome! Last updated 25 July 1999. richard@sleepie.demon.co.uk