From owner-freebsd-mips@FreeBSD.ORG Fri Aug 27 16:07:25 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9B4110656A6 for ; Fri, 27 Aug 2010 16:07:25 +0000 (UTC) (envelope-from PMahan@adaranet.com) Received: from barracuda.adaranet.com (smtp.adaranet.com [72.5.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id CBE0E8FC15 for ; Fri, 27 Aug 2010 16:07:25 +0000 (UTC) X-ASG-Debug-ID: 1282925245-5061655e0001-1gY7mK Received: from SJ-EXCH-1.adaranet.com ([10.10.1.29]) by barracuda.adaranet.com with ESMTP id KF3wJBykGCzVnFZO; Fri, 27 Aug 2010 09:07:25 -0700 (PDT) X-Barracuda-Envelope-From: PMahan@adaranet.com Received: from mycroft.adaranet.com (10.10.24.100) by SJ-EXCH-1.adaranet.com (10.10.1.29) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 27 Aug 2010 09:07:25 -0700 Message-ID: <4C77E3E6.8060002@adaranet.com> X-Barracuda-BBL-IP: nil Date: Fri, 27 Aug 2010 09:12:22 -0700 From: Patrick Mahan User-Agent: Thunderbird 2.0.0.23 (X11/20091021) MIME-Version: 1.0 To: Juli Mallett X-ASG-Orig-Subj: Re: Cannot build the Mips 32 bit kernel References: <4C76F4B6.5050607@adaranet.com> <20100826.171545.705015198975915183.imp@bsdimp.com> <4C76FA9F.2070805@adaranet.com> In-Reply-To: Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: UNKNOWN[10.10.1.29] X-Barracuda-Start-Time: 1282925245 X-Barracuda-URL: http://172.16.10.203:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at adaranet.com Cc: "freebsd-mips@freebsd.org" Subject: Re: Cannot build the Mips 32 bit kernel X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 16:07:26 -0000 Juli Mallett wrote: > On Thu, Aug 26, 2010 at 16:37, Patrick Mahan wrote: >> We build for mips o32 under 8.0 and our kernel (before we insert the >> rootfile system) is >> >> -rwxr-xr-x 1 pmahan pmahan 38155521 Aug 24 19:22 kernel.octeon.32 >> >> Where when we build it off of head we are seeing >> >> -rwxr-xr-x 1 pmahan pmahan 243364423 Aug 26 09:45 kernel.octeon.32 >> >> ~38 Mbytes versus ~243 Mbytes >> >> a 6x increase in size. So I was playing around with the configuration >> file to decide what to leave out. > > That must be either some difference in allocating space for the root > filesystem or related to having a lot of debugging info and not > stripping the one from HEAD. The Cavium Simple Executive (I don't > know if the proprietary port you're using uses it or not) adds some > bloat, but nothing like that much. My kernels, n64 and o32 both, are > around 8M. I'm not embedding any sort of root filesystem. Okay, problem solved, pilot error (sort of :-p). It was a case of allocating space for the root filesystem. We have build scripts that are suppose to winnow down the stuff put into world/ after we finish a 'buildworld'. This winnowing reduces the overall size of the root filesystem. The script then compares the size of the created filesystem image to the value of MD_ROOT_SIZE in OCTEON1-32 and if it is too small, increase it to the correct size and rebuild the kernel. It seems that our initial build, the root filesystem was not reduced in size and this caused MD_ROOT_SIZE to be set to a really large size and subsequent builds do not reduce the size of MD_ROOT_SIZE thus the resultant kernel builds were too large. It wasn't till I went back and pulled a fresh checkout and carefully ran our build scripts one at a time that I figured this out. I've got some code that is not ready for prime time for building the embedded root filesystem more like how linux uses its initramfs. This method does require messing with a large array in place to hold the root filesystem. Instead, it will be captured in its own data section. Patrick