Date: Wed, 7 May 2008 10:03:25 -0500 (CDT) From: Mark Tinguely <tinguely@casselton.net> To: ray@dlink.ua, tinguely@casselton.net Cc: freebsd-arm@freebsd.org Subject: ARM_USE_SMALL_ALLOC question Message-ID: <200805071503.m47F3Puo053836@casselton.net> In-Reply-To: <20080505134045.0cf93a8d.ray@dlink.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200805071503.m47F3Puo053836>