From owner-freebsd-arm@FreeBSD.ORG Sat Oct 13 04:06:33 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6781EAD2 for ; Sat, 13 Oct 2012 04:06:33 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp3.clear.net.nz (smtp3.clear.net.nz [203.97.33.64]) by mx1.freebsd.org (Postfix) with ESMTP id 1D4638FC08 for ; Sat, 13 Oct 2012 04:06:32 +0000 (UTC) Received: from mxin2-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp3.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MBT009E8CQMBO10@smtp3.clear.net.nz> for freebsd-arm@freebsd.org; Sat, 13 Oct 2012 17:06:26 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO localhost) ([202.0.48.19]) by smtpin2.paradise.net.nz with ESMTP; Sat, 13 Oct 2012 17:06:25 +1300 Date: Sat, 13 Oct 2012 17:06:23 +1300 From: Andrew Turner Subject: Re: Latest code and scripts are working for me on BeagleBone... In-reply-to: <3ECCBCA3-D190-4AC0-8292-4B34BD43A45A@bsdimp.com> To: Warner Losh Message-id: <20121013170623.37672da1@fubar.geek.nz> MIME-version: 1.0 X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; i386-portbld-freebsd8.1) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Pirate: Arrrr References: <201210120839.q9C8dKR6073428@grabthar.secnetix.de> <2C318C44-38AB-4D56-B102-B12CD7E90776@neville-neil.com> <90FB30E0-569E-4DBF-ACCB-36C723A4E937@neville-neil.com> <82A753B1-B6EE-4B6A-9B5E-7F09FC5E1266@bsdimp.com> <20121013152610.5f5f72bd@fubar.geek.nz> <3ECCBCA3-D190-4AC0-8292-4B34BD43A45A@bsdimp.com> Cc: Tim Kientzle , George Neville-Neil , Oliver Fromme , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 04:06:33 -0000 On Fri, 12 Oct 2012 21:06:07 -0600 Warner Losh wrote: > > On Oct 12, 2012, at 8:26 PM, Andrew Turner wrote: > > > On Fri, 12 Oct 2012 19:27:15 -0600 > > Warner Losh wrote: > > > >> > >> On Oct 12, 2012, at 7:11 PM, George Neville-Neil wrote: > >>> > >>> What's the rough outline of what's necessary to do that? I can > >>> work on it. > >> > >> (1) Finish unifying the initarm() > > I'm working on this. I just need to update one more SoC before I can > > merge them. Even with them merged we will still need to detect the > > SoC we are running on. That shouldn't be a problem as long as we > > only allow FDT on ARMv6. > > This is ambiguous. Do you mean "All armv6 ports must support FDT" or > "we don't allow FDT on armv4?" I think the former is a-ok, but the > latter is a non-starter. I mean, using the definitions from rfc2119 [1], ARMv6 and ARMv7 families must use FDT, existing ARMv4 and ARMv5 families may use FDT, new ARMv4 and ARMv5 families (if any) should use FDT. > >> (2) Unify the interrupt code > >> (3) unify the shutdown/startup code > >> (4) polish off any of the dangling loose ends that compiling all > >> the armv6 together. (0) write a GENERICV6 config file > > There are a number of functions that currently need to be > > implemented for each SoC. They should be trivial to find, e.g. with > > the linker, but we will need to come up with a solution to detect > > which SoC we are on and call the correct function. > > Or we need to have drivers attach function pointers based on what > hardware is present... Yes, we still need to find the functions. > > Another problem I can see is in the memory layout. We need to > > specify a fixed virtual address layout for the kernel. It would be > > nice to be able to then load the kernel to any page aligned address > > and have it just work. It shouldn't be too difficult when the > > virtual and physical addresses don't overlap, e.g. we can figure > > out what address we have been loaded to by looking at the pc > > register at a known location. The problem will be when the virtual > > and physical addresses overlap but are not identical. In this case > > care will be needed when we turn the MMU on. This is because we > > create a map for the current physical address and the new virtual > > address to point them at the same physical memory then, when the > > MMU is enabled, jump between them. > > armv6 is supposed to solve this by standardizing the memory > layout... There are some compile-time constants that need to become > run-time values, which may have a minor performance hit in a few > places.... It is? Is it documented somewhere? I knew Cortex-M has a standard memory layout but this is the first I have heard about any standard memory layout on the ARMv{6,7} -A CPUs. > > > Having a look at the SoCs we support the only one I can see that > > might cause us problems is sa11x0. > > The sa11x0 is an ancient armv4 processor, I thoght, predecessor to > strongarm. Not really a consideration for this project. I know, I was using it as the example of VA == PA we have in the tree. [1] http://www.ietf.org/rfc/rfc2119.txt Andrew