On 25 Oct 2001 cgd@broadcom.com wrote:

: > In order to fix the installboot problem, we're going to need a
: > cross-nlist(3).  This should not be that hard to do, and having
: > it would eliminate the need to have a BFD'ified mdsetimage(8) (and
: > dbsym(8), although that is not yet in the tree).

Doesn't say much for this living in the "stand"-alone software directory,
does it?  <grin>

: Also, it's possible to solve "the installboot problem" via (IMO
: better) means.  E.g. actually having an identifiable structure in the
: binary which contains the info you want, rather than relying on
: symbols and the object format of a particular file on disk.

"What he said."  An array of u_int32_t's, where the first N are
preinitialized to a particular magic value, provides you with a
4-byte-aligned memory area guaranteed to be in the data (rather than bss)
segment.  To wit, including backwards compatibility with older
installboot binaries(!):

===== in some .h file =====

#define MAGIC1		0xfeedbabe
#define MAGIC2		0xdeadbeef
#define MAXBLOCKNUM	256	/* enough for a 2MB boot program (bs 8K) */

struct bootdata {
	u_int32_t	magic1;
	u_int32_t	magic2;
	int32_t		block_size;
	int32_t		block_count;
	int32_t		block_table[MAXBLOCKNUM];
} __attribute__((packed));	/* packed to make host platforms happy */

===== in bootxx/bootxx.c =====

extern struct bootdata bd;
/* change "block_*" references to "bd.block_*" */

===== added to end of common/srt0.s =====

	.data
	.globl	bd, block_size, block_count, block_table
	.align	4

bd:
	.word	0xfeedbabe	! MAGIC1
	.word	0xdeadbeef	! MAGIC2
block_size:			! name used by old installboot
	.word	0
block_count:			! name used by old installboot
	.word	256		! MAXBLOCKNUM
block_table:			! name used by old installboot
	.fill	256, 4, 0	! MAXBLOCKNUM, sizeof(daddr_t), 0

===== end =====

Now it's a SMOP to make installboot use it.  :)

: I don't see why e.g. the x86 installboot couldn't/shouldn't use a
: similar technique to what the Alpha uses, for instance.

The nlist usage of sparc's installboot is to get symbols from the
first-stage bootloader, in order to shove block numbers into it.  Similar
foo is used for i386.

The alpha bootstrap is a single piece ~8K stuffed below the real fs data
start.  So the alpha can get away with more, because it doesn't have to
write block numbers into the bootstrap.

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi NetBSD:  Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/