Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: installboot is broken



On 2013-03-24 19:16, Martin Husemann wrote:
You made your point perfectly clear, however, I do not know the differences
between the various boot details, so I don't know if the scheme used by
installboot is wrong.

Ah. Ok... Since installboot only pokes a couple of values of block 0, it can never work with systems that actually expect there to be code in block 0. That should be obvious. If you look at the source code in sys/arch/vax/boot/xxboot/start.S, you'll see what we actually should be putting at block 0, which installboot is not doing. We already have all the code. We just are not using it.

What it does:

  1) In block 0 create a struct vax_boot_block and fill in the magic needed.
     This includes pointing at block 1 as start of the loader:
         bb.bb_load = htole32(VAX_BOOT_LOAD);
         bb.bb_entry = htole32(VAX_BOOT_ENTRY);

Right. And those values seems to be used by the MicroVAX, but is not used by VMB.EXE.

  2) it writes all of xxboot (including the first sector, as created from
      start.S) to the sectors starting at 1.

Oh! Now I get it. installboot copies all of xxboot, but offset by one sector. It is broken, but it was slightly different than I first thought. Block 0 of xxboot really needs to be at block 0 of the disk. There is code there, and entry points which VMB will jump to, on some machines.

If the bb_load/bb_entry version does not work on all vaxes, and instead
the full first sector (with patched in disklabel) is needed, this has to
be an oversight during the conversion to single bootblock - easy to happen,
as it will only cause problems with brand new/zeroed disks, otherwise the
old block 0 will be preserved.

Yes. That is the problem. For some older VAXen, the boot basically implies reading in block 0, and start executing code expected to live there. The MicroVAX does not do this, but instead reads in several blocks, and expect to start executing code living in block 1 (or something like that).

I'd be happy to fix it, if we have consensus here on what to do (and
do testing on simh).

I've already given instructions on how to get a working boot block on any NetBSD/vax system. The data in xxboot is correct. You just need to merge that with the disk label.

However, installboot does not at all agree with the contents of block 0 as compared to what is in xxboot.

On my running VAX 8650 (actually a simh instance), with a correct boot block:

Puff# installboot -c /dev/rra0c
installboot: Old boot block magic number invalid; boot block invalid
installboot: Clear bootstrap operation failed


But it might maybe not be related to the boot block of xxboot. I have not verified it any further.

        Johnny

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


Home | Main Index | Thread Index | Old Index