Subject: Re: proposed re-work / unification of boot block installation
To: None <lukem@wasabisystems.com>
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
List: tech-kern
Date: 04/30/2002 20:00:45
In article <20020430200313.R3537@wasabisystems.com>
lukem@wasabisystems.com wrote:
> Feel free to send the code past me for review.
Okay, I've put related files:
http://www.ceres.dti.ne.jp/~tsutsui/netbsd/news68k-installboot.tar.gz
(Sorry, since our cvs server seems down, I'm tired to make diffs by hand..)
> Yes, we probably should combine all the *_bbinfo structures and
> associated defines into one header file (sys/bbinfo.h or
> sys/bootblock.h or ... ?) instead of dev/sun/sun_boot.h.
I see, it's OK if all of them are combined into MI header files.
> The alpha, pmax and vax can all use this option to specify where to
> place the first stage (primary) boot loader, which can be useful for
> multi-boot cd9660 file systems and ustarfs boot floppies. Other
> platforms (e.g, i386, and news68k ?) could use this to specify where
> the secondary bootloader is found?
Hmm, if -b is already used for primary boot, I think it's better
to have another options (-B or something?) to specify place of
secondary boot.
Just FYI, news68k (and newsmips) machines load the first 8kbytes
of the boot disk into address 0x0 (0x80000000 on mips) and jump there.
Of course, the first sector would contain disklabel,
so installboot should put jump instruction before LABELOFFSET
and have to overwrite primary boot on existing disklabel.
installboot also have to update struct bbinfo in the primary boot
to note where secondary boot exists on the disk.
> I have some uncommitted patches which adds "raw" as a file system type
> (since the file system detection code was committed we need this for
> boot floppy ustarfs creation), which matches anything.
:
> | Of course, it is better to implement ufstarfs_match() and
> | ustarfs_findstage2() functions for ustarfs images
> | rather than using -b option, but it isn't easy work for me ;-)
>
> `See above' :-)
Yeah, it looks good idea and should work also on news68k and newsmips.
> Once I've got the "raw" support committed, I can review what you've
> done for the news68k stuff and consider the <sys/bbinfo.h> (or
> whatever) header file idea.
Please go ahead.
---
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp