[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
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 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
Main Index |
Thread Index |