From owner-freebsd-mips@FreeBSD.ORG Thu Aug 26 15:49:46 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 0795D1065698 for ; Thu, 26 Aug 2010 15:49:46 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id A9AF28FC15 for ; Thu, 26 Aug 2010 15:49:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o7QFkS6B023948; Thu, 26 Aug 2010 09:46:28 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 26 Aug 2010 09:46:30 -0600 (MDT) Message-Id: <20100826.094630.94843338838666386.imp@bsdimp.com> To: PMahan@adaranet.com From: "M. Warner Losh" In-Reply-To: <32AB5C9615CC494997D9ABB1DB12783C024C875653@SJ-EXCH-1.adaranet.com> References: <20100825.232923.287595822763821210.imp@bsdimp.com> <32AB5C9615CC494997D9ABB1DB12783C024C875653@SJ-EXCH-1.adaranet.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-mips@FreeBSD.org Subject: Re: Is the MIPS kernel buildable from HEAD? 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: Thu, 26 Aug 2010 15:49:46 -0000 In message: <32AB5C9615CC494997D9ABB1DB12783C024C875653@SJ-EXCH-1.adaranet.com> Patrick Mahan writes: : : : > -----Original Message----- : > From: M. Warner Losh [mailto:imp@bsdimp.com] : > Sent: Wednesday, August 25, 2010 10:29 PM : > To: c.jayachandran@gmail.com : > Cc: Patrick Mahan; freebsd-mips@FreeBSD.org : > Subject: Re: Is the MIPS kernel buildable from HEAD? : > : > In message: : > "Jayachandran C." writes: : > : On Thu, Aug 26, 2010 at 2:43 AM, M. Warner Losh wrote: : > : > In message: <32AB5C9615CC494997D9ABB1DB12783C024C875590@SJ-EXCH- : > 1.adaranet.com> : > : > Patrick Mahan writes: : > : > : Is it possible to build the MIPS kernel from HEAD? Or is the : > : > : current development still external to the HEAD branch? : > : > : > : > Yes. The tip of head is where the mips action is these days. There : > : > is no external development branch. : > : > : > : > There is one issue, however. If you are building for one of the : > : > 64-bit processors a 64-bit kernel, then the required userland won't : > : > build. There's still issues that need to be sorted out... : > : : > : The 64-bit userland builds for me with -DWITHOUT_CDDL -DWITHOUT_USB : > : -DWITHOUT_BLUETOOTH -DWITHOUT_RESCUE - are you referring to these, or : > : are there other issues? : > : > I can do a buildworld now without any of these flags. I don't know : > what the bluetooth issue is/was, but it doesn't kill the build. I : > fixed the CDDL issue, and papered over the uath and rescue issues in : > the build system. : > : > I can now build a n64 world in -current. I haven't had a chance to : > run it yet, but hope to soon. My CN38xx board doesn't like the 32-bit : > kernel anymore... It also doesn't like the 64-bit kernel, but I think : > that's a uboot issue. It seems older ldscripts didn't tickle the bugs : > the current one does (on the other hand, the old ldscripts only worked : > on the CN38xx board). On the other hand, SDK 1.9.0's uboot on another : > board works fine with the 64-bit kernel. : > : : Warner, : : We build o32 with our modified FreeBSD 8.0 that boots under the SDK 1.8.1 : on a CN58XX. However, I was looking at the ldscript that we use versus : the one in use for you. We are using what is basically sys/conf/ldscript.mips. That's good to know... : Also, I think our problem is with the a3 register passed in as part of : platform_start() in cavium/octeon_machdep.c. We have the following in : mips/lowcore.S - : : #if defined(TARGET_OCTEON) : la a0, app_descriptor_addr : sw a3, 0(a0) /* Store app descriptor ptr */ : #endif : : So we are storing the value of a3 into a global that we later use in : octeon32/Octeon_machdep.c - Yea. The old code did that. We removed it because we were passing a3 into the platform_start routine directly. I had to fix some of locore to not clobber the a3 register, however, to make it useful... A quick look at locore.S shows : static void : mips_boot_params_init(void) : { : int descriptor_not_parsed = 1; : : if ((app_descriptor_addr == 0) || (app_descriptor_addr >= 0xAfffffff)) { : printf("address of app_descriptor is %x\n", : app_descriptor_addr); : } else { : : app_desc_ptr = (octeon_boot_descriptor_t *) app_descriptor_addr; : octeon_bd_ver = app_desc_ptr->desc_version; : ... : : : I am need to investigate, but I think we found that a3 was getting clobbered on : the inbound call to platform_start(). You might try not using the app_desc_ptr at all. It used to be possible to boot things w/o it before Juli's changes. I haven't tried since then. Also, there was a bug with the bzero in locore where it would round to the next page bogusly. As a result, it overwrote part of the app_descriptor leading to much confusion inside the kernel... You might also try poking some kind of character into the LEDs at different points to see how far you get. When I've seen uboot bugs, they have kept me from even getting to the first line of locore.S. Warner