From owner-freebsd-arm@FreeBSD.ORG Wed May 7 15:03:31 2008 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00A1E1065671 for ; Wed, 7 May 2008 15:03:31 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id AE0BC8FC15 for ; Wed, 7 May 2008 15:03:30 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.2/8.14.2) with ESMTP id m47F3PMp053837; Wed, 7 May 2008 10:03:25 -0500 (CDT) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1210172605; bh=F4SX9hNyzjpxxPlGOk/wzAG70hc=; h=Date: From:Message-Id:To:Subject:Cc:In-Reply-To; b=icrIEJeI0sz8gOJTv0kwY IYUzMAUjpmnetqJCWyR8qdP0/Li52Efe9uptN4mGG8sSUZfD0UzQ2QGK7/zetEo/uSy w+AAWYB01vXiI54VQw2Mlot9ezcLmVFs7EkR7OBJXz01KuSVmY23LH8k6gEy2etC/es tTVLYolRHJWeWWqI= Received: (from tinguely@localhost) by casselton.net (8.14.2/8.14.2/Submit) id m47F3Puo053836; Wed, 7 May 2008 10:03:25 -0500 (CDT) (envelope-from tinguely) Date: Wed, 7 May 2008 10:03:25 -0500 (CDT) From: Mark Tinguely Message-Id: <200805071503.m47F3Puo053836@casselton.net> To: ray@dlink.ua, tinguely@casselton.net In-Reply-To: <20080505134045.0cf93a8d.ray@dlink.ua> Cc: freebsd-arm@freebsd.org Subject: ARM_USE_SMALL_ALLOC question X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2008 15:03:31 -0000 Alexandr Rybalko's PXA255 boot problems has tiggered a wonder that I have had about the ARM_USE_SMALL_ALLOC option for Xscale processor. I guess I am not a big fan of the ARM_USE_SMALL_ALLOC, so filter this email with that bias. ----- the Xscale machdep initialization routines set the dump_avail array to look like: dump_avail[0] = SDRAM_START; dump_avail[1] = SDRAM_START + memsize; in arm/vm_machdep.c the arm_init_smallalloc() and arm_ptovirt() calculate sizes of the memory as: (dump_avail[i + 1] & S_FRAME) + S_SIZE - (dump_avail[i] & S_FRAME); It seems to me, that in most cases, SDRAM_START will be S_FRAME (1M boundary) aligned and memsize will be a multiple of S_SIZE (1M), so my conclusion is that these calculations in the general case will be 1MB too big. ----- Of course there is the ARM_HAVE_SUPERSECTIONS case, but I bet the same general case would apply that SDRAM_START will be on a 16M boundary aligned and memsize will be a multiple of 16M also. This is an observation, I do not think this has caused any problems. --Mark Tinguely.