Hi Paul.

I've written a sparc backend for the machine independent
/usr/sbin/installboot, but I have an implementation issue that
needs to be resolved.

As far as I can tell, the existing /usr/mdec/installboot:
	1. uses libsa's loadfile() to get the text &
	   data sections from the ELF /usr/mdec/bootxx,
	2. examines the provided file system for the blocks occupied
	   by /boot,
	3. searches for the bbinfo structure in 1., and adjusts it
	   with the blocks found by 2.
	4. writes out the bootblock to sectors 1..15 of the file system.

The sparc installboot(8) backend (arch/sparc.c) that I've written,
which is heavily based on arch/sun68k.c, doesn't use loadfile().
Instead, it expects that /usr/mdec/bootxx is already in a binary
format (converted with objcopy -O binary), which significantly
increases the simplicitly and portability of the arch/sparc.c module.

So, the new installboot needs bootxx built with something like:
	${PROG}: ${OBJS} ${LIBKERN} ${LIBSA}
		${LD} -o ${.TARGET}.sym ${LINKFLAGS} ${OBJS} ${LIBSA} ${LIBKERN}
		@${SIZE} ${.TARGET}.sym
		${OBJCOPY} -O binary ${.TARGET}.sym ${.TARGET}.bin
		(printf ${SUN_MAGIC_HEADER}; cat ${.TARGET}.bin ) > ${.TARGET}

(In my testing on my SS5 with the miniroot image, I found that I needed to
prepend the 32 bytes of PROM magic.)

My questions are:

	+ Would it be OK for me to cut over the sparc port from the
	  MD /usr/mdec/installboot and ELF /usr/mdec/bootxx to the
	  MI /usr/sbin/installboot and binary /usr/mdec/bootxx ?

	  This would mean that an old /usr/mdec/installboot would
	  not be able to install a new "binary" /usr/mdec/bootxx,
	  and /usr/sbin/installboot would not be able to install
	  an old ELF /usr/mdec/bootxx vice versa.

	  However, the benefits of using the MI installboot is
	  that it's portable and works on file system images,
	  which helps significantly when converting distrib/sparc
	  to the "New Distrib World Order" of allowing easy non-root
	  non-NetBSD cross-release building of NetBSD/sparc.

	+ Should bootxx always contain the 32 byte PROM magic prepended
	  to the start?  If not, I'll instead add an installboot -o
	  option for the sparc backend to control this. 

An alternate option would be to convert the primary boostrap bootxx
away from the bbinfo approach (of hard-coded blocks) to a "search
the filesystem for /boot" approach a la the alpha/pmax/vax/sparc64.
This is much more effort, but would result in one less "bootxx flag
day".

Thoughts?

Luke.

-- 
Luke Mewburn  <lukem@wasabisystems.com>  http://www.wasabisystems.com
Luke Mewburn     <lukem@netbsd.org>      http://www.netbsd.org
Wasabi Systems - NetBSD hackers for hire