Re: install/46027: First stage bootloader (bootxx_ffsv2) on i386 broken for Soekris net4801

[Marc Balmer <mbalmer%NetBSD.org@localhost>]

The following reply was made to PR install/46027; it has been noted by GNATS.

From: Marc Balmer <mbalmer%NetBSD.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: install/46027: First stage bootloader (bootxx_ffsv2) on i386
 broken for Soekris net4801
Date: Sat, 25 Feb 2012 10:03:01 +0100

 Am 24.02.12 19:15, schrieb David Laight:
 > The following reply was made to PR install/46027; it has been noted by GNATS.
 > 
 > From: David Laight <david%l8s.co.uk@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc: 
 > Subject: Re: install/46027: First stage bootloader (bootxx_ffsv2) on i386 
 > broken for Soekris net4801
 > Date: Fri, 24 Feb 2012 18:07:15 +0000
 > 
 >  On Fri, Feb 24, 2012 at 08:30:06AM +0000, Marc Balmer wrote:
 >  > The following reply was made to PR install/46027; it has been noted by 
 > GNATS.
 >  > 
 >  > From: Marc Balmer <mbalmer%NetBSD.org@localhost>
 >  > To: gnats-bugs%NetBSD.org@localhost
 >  > Cc: install-manager%NetBSD.org@localhost, 
 > gnats-admin%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
 >  > Subject: Re: install/46027: First stage bootloader (bootxx_ffsv2) on i386
 >  >  broken for Soekris net4801
 >  > Date: Fri, 24 Feb 2012 09:28:54 +0100
 >  > 
 >  >  It is (confirmed) not teh first stage boot loader bootxx_ffsv2 that
 >  >  causes the problem, but the second stage boot loader /boot.  The problem
 >  >  happens only when /boot is compiled with the GPT code (which is the
 >  >  default), when it is compiled with -DNO_GPT, the reset does not happen.
 >  
 >  Do you know if bootxx_ffsv2 manages to load /boot - and the fail is
 >  within /boot, or something (size) stops /boot itself being loaded.
 >  
 >  There ought to be a printf() very early on in /boot - so you can tell
 >  it has started at all (someone removed some of them ...)
 >  
 >  Also check the sizes of /boot (code/data/stack etc) and especially
 >  that its heap is actually beyond all the other sections.
 >  ISTR that the heap is at a fixed address, not one assigned by
 >  linker script 'magic'.
 
 Yes, as I said, the bug happens in /boot, so it gets loaded.  The
 problem is somewhere within the GPT support code.  If I build /boot with
 -DNO_GPT, there is no problem, no resets.