Re: installboot is broken

[Johnny Billquist <bqt%softjar.se@localhost>]

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