Tycho Nightingale wrote: > > On Fri, 9 Jan 2009, Jean McCormack wrote: > >> Tycho Nightingale wrote: >>> >>> On Thu, 8 Jan 2009, Jean McCormack wrote: >>> >>>> Please review the following fixes >>>> >>>> >>>> CR: >>>> 5887 DC needs to install boot blocks to sparc bootroot >>>> http://defect.opensolaris.org/bz/show_bug.cgi?id=5887 >>>> >>>> 5888 /platform/[sun4u|sun4v]/wanboot is needed in AI image >>>> http://defect.opensolaris.org/bz/show_bug.cgi?id=5888 >>>> >>>> Webrev: >>>> http://cr.opensolaris.org/~jeanm/slim_5888_5887/ >>> >>> The path to the bootblock with an embedded 'sun4u' may break on >>> 'sun4v' systems. It's probably best to use: >>> >>> /usr/platform/`uname -m`/lib/fs/ufs/bootblk >> There's actually 2 reasons not to. 1) You could be building on a >> different architecture than what you will run on. Thus uname -m might >> return >> a different platform anyway. 2) I was told (2nd hand) that Jan >> recommended using sun4u. Since he's the boot guy I figured this was >> correct. > > This brings up a fundamental issue. The resulting image must work for > both sun4u and sun4v systems and hence the installed boot block must > support both systems. Today the sun4u and sun4v boot blocks are built > from a single forth source file, so luckily you are fine using either. Which is probably why I was told to use sun4u. I know the statement was made that they're the same. > > However, the point I was making was the the boot block for the current > architecture is more likely to be on the build system than the block > block for a specific architecture, so the build has a greater chance > of working and not failing because of a missing file. I actually use the boot block not from the system but from the image. All architectures should be there so I don't think this is an issue. > > But in the future if the boot blocks diverge this entire strategy > crumbles. Yes. But at that point we'll probably need to make other changes to the microroot and this will be the least of our worries.
Jean > > Tycho
