nessus@athena.mit.edu (Doug Alan) (03/11/88)
I've been having some problems trying to boot a VAXstation-II from a disk drive on a second disk controller. I know that the kernal on the root partition of the drive in question is good, because that is our normal root partition. I also know that the boot blocks are good because they were copied (dd count=16 bs=1b) from the drive that is currently being booted from, and both controllers are MSCP controllers. This is what I am doing: >>>b/3 dub0 The "u" meaning MSCP controller, the "b" meaing the second controller, and the "0" meaning the first drive on that controller. Well, all this seems to work. The drive whirs for a little while, and then I get the Unix boot prompt: Boot : To this I add the following: Boot :ra(4,0)vmunix The "4" meaning ra4, which is what the drive I want to boot off of is known as, and the "0" meaning the first partition on this drive. Shortly after typing this, the machine halts, instead of booting, and the ">>>" prompts have been output on top of any error message that might have been there. Anyone have any idea what I am doing wrong? I've tried using "2" - "7" instead of "4", in case I'm just using the wrong number, but none of them worked, either. I'm also a little bit puzzled about how the boot program is supposed to know what the two numbers in "ra(4,0)vmunix" mean. According to the man page for 'reboot(8)', the first number is the unit number and the second number is the partition number. I don't understand how the boot program is supposed to know what unit number is where. I can configure the kernal so that any drive has any unit number I want it to have. Also, how does the boot program know where different partitions begin? I can configure the kernal so partitions begin wherever I want them to. How does the boot program know where I've configured the various partitions to begin? |>oug /\lan
chris@mimsy.UUCP (Chris Torek) (03/12/88)
In article <3661@bloom-beacon.MIT.EDU> nessus@athena.mit.edu (Doug Alan) writes: >... boot a VAXstation-II from a disk drive on a second disk controller. Ultrix may support several uda50 controllers on one bus. 4.2 and 4.3 BSD do not. In 4.xBSD, one does >... I get the Unix boot prompt: > > Boot > : ra(4,0)vmunix or more generally, xx(y,z)pathname where `xx' is one of `hp' `ra' `up' and a few others. `z' is just the partition (on disks at least). `y' is computed as 8 * bus_adapter_index + slave (note 1) Hence ra(4,0) is adapter 0 (uba0) unit 4 (slave 4). Note that there is no room for a controller index! ----- [1] `bus adapter index' is actually `SBI TR - 3' for UBAs on SBI Vaxen, and `UBA nexus - 3' on 750s and 730s. Hence the built-in uda50-unibus in an 8600 is ra(16,z) through ra(23,z), since this UBA is at TR 5. For MBAs, it is `TR - 8' (or nexus minus 8 on 750s). The second SBI on an 8600 is indicated by an MBA index >= 4 (this may not be in 4.3BSD). ----- Under 4.3-tahoe the format will be xx(a,b,c,d)pathname where `a' is the adapter index, b is the controller, c is the drive, and d is the partition. (Multiple SBIs on 8600s will still be kludged with mod-4 or perhaps mod-8 values for `a'.) 8200 BI adapter indicies will not be node numbers (unless we change this), but rather determined by the actual index, such that the first BUA (counting up from node 0) is uba0 and the second is uba1. (Example: two BUAs, one at node 6 and one at node E; the one at node 6 is uba0 and the one at E is uba1.) >Also, how does the boot program know where different >partitions begin? I can configure the kernal so partitions begin >wherever I want them to. How does the boot program know where I've >configured the various partitions to begin? It does not. The partition offsets are compiled into the various standalone drivers. In 4.3-tahoe the partition offset in the label overrides, assuming there is a label. Most of the standalone drivers support labels, although as yet only the hp and uda/ra Unix drivers use them. (The 8200 KDB50 driver does not; it needs to be re-merged with the UDA50 driver. Sigh.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
mike@turing.UNM.EDU (Michael I. Bushnell) (03/13/88)
In article <10627@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >In article <3661@bloom-beacon.MIT.EDU> nessus@athena.mit.edu (Doug Alan) writes: >>... boot a VAXstation-II from a disk drive on a second disk controller. > >Ultrix may support several uda50 controllers on one bus. 4.2 and >4.3 BSD do not. In 4.xBSD, one does 4.3 BSD DOES support multiple uda controllers. All our Microvax-II's have two controllers: RQDXn and something like an Emulex QD-32. 4.2 BSD doesn't support the Microvax, and I don't know what it does for a big vax. >>... I get the Unix boot prompt: >> >> Boot >> : ra(4,0)vmunix > >or more generally, > > xx(y,z)pathname > >where `xx' is one of `hp' `ra' `up' and a few others. `z' is just >the partition (on disks at least). `y' is computed as > > 8 * bus_adapter_index + slave (note 1) > >Hence ra(4,0) is adapter 0 (uba0) unit 4 (slave 4). Note that >there is no room for a controller index! The slave is on the controller booted. Here is how you boot from the second controller: >>> b dub0 -- Read boot block from second controller, first disk Loading ra(0,0)boot -- Reading UNIX boot from first disk, first partition of the SAME controller the boot block came from Boot : ra(0,0)vmunix -- Load vmunix from first disk, first partition of the SAME controller the boot block came from. We do this all the time. Michael I. Bushnell mike@turing.unm.edu {ucbvax,gatech}!unmvax!turing!mike HASA -- "A" division
chris@trantor.umd.edu (Chris Torek) (03/14/88)
>>In article <3661@bloom-beacon.MIT.EDU> nessus@athena.mit.edu (Doug Alan) writes: >>>... boot a VAXstation-II from a disk drive on a second disk controller. >In article <10627@mimsy.UUCP> I answered: >>Ultrix may support several uda50 controllers on one bus. 4.2 and >>4.3 BSD do not. That is, 4.xBSD *standalone* drivers do not (an important distinction). In article <884@unmvax.unm.edu> mike@turing.UNM.EDU.UUCP (Michael I. Bushnell) writes: >4.3 BSD DOES support multiple uda controllers. All our Microvax-II's >have two controllers: RQDXn and something like an Emulex QD-32. Sure. But on the other hand, 4.3BSD does not have a working Microvax boot at all (which I completely forgot). You have to use whatever Ultrix boot loader you have. All of my comments only applied to those who modified the 4.3 code to work on their uVax-IIs (not many I guess). Sorry about the goof. >The slave is on the controller booted. Here is how you boot from the >second controller: >>>> b dub0 -- Read boot block from second controller, first disk > >Loading ra(0,0)boot -- Reading UNIX boot from first disk, first partition > of the SAME controller the boot block came from > >Boot >: ra(0,0)vmunix -- Load vmunix from first disk, first partition of the > SAME controller the boot block came from. > >We do this all the time. Perhaps Ultrix supports this. The 4.3+ boot code does not; again, this will be >>>b/3 dub0 // invoke boot block loader in ROM. // this works much as on 750s, except // that the `level 0 bootstrap' is a // header interpreted by the ROM. Boot // this is the max-7.5K-boot-block. : ra(0,1,0,0)vmunix // ctlr 1, drive 0, partition a. if you stick with what we have now. We have no idea how to find out which device the ROM used. Is this in the Extended RPB? Where? Here is what we do in /sys/vaxstand/srt0.c. If you know we can stop `guessing' at the boot device, tell me or Keith Bostic. entry: .globl entry nop; nop # .word 0x0101 mtpr $HIGH,$IPL # just in case #ifdef REL # we need to do special stuff on microvax II mfpr $SID,r0 cmpzv $24,$8,r0,$VAX_630 bneq 1f /* * Were we booted by VMB? If so, r11 is not boothowto, * but rather the address of the `Extended RPB' (see KA630 * User's Manual, pp 3-21). These tests were devised by * richl@tektronix, 11/10/87. */ cmpl (r11),r11 # if boothowto, r11 will be small bneq 1f # and these will not fault cmpl 4(r11),$0 bneq 1f cmpl 8(r11),$-1 bneq 1f tstl 0xc(r11) bneq 1f /* * Booted by VMB: get flags from extended rpb. * We can only guess at the boot device (here ra(0,0,0,0)). */ movl 0x30(r11),r11 movl $9,r10 # device = ra(0,0,0,0) 1: movl $RELOC,sp #else movl $RELOC-0x2400,sp #endif /* end of stuff related to boot devices on microvax */ -- In-Real-Life: Chris Torek, Univ of MD Computer Science, +1 301 454 7163 Domain: chris@mimsy.umd.edu Path: ...!uunet!mimsy!chris