Date: Sat, 13 Oct 2012 17:06:23 +1300 From: Andrew Turner <andrew@fubar.geek.nz> To: Warner Losh <imp@bsdimp.com> Cc: Tim Kientzle <tim@kientzle.com>, George Neville-Neil <gnn@neville-neil.com>, Oliver Fromme <olli@lurza.secnetix.de>, freebsd-arm@freebsd.org Subject: Re: Latest code and scripts are working for me on BeagleBone... Message-ID: <20121013170623.37672da1@fubar.geek.nz> In-Reply-To: <3ECCBCA3-D190-4AC0-8292-4B34BD43A45A@bsdimp.com> References: <201210120839.q9C8dKR6073428@grabthar.secnetix.de> <2C318C44-38AB-4D56-B102-B12CD7E90776@neville-neil.com> <E8A50C0A-9E34-4E03-95A7-EA2336C0EC83@bsdimp.com> <E123697D-F79F-4E48-91F1-4CA9B6900069@kientzle.com> <AB3E9CC0-0310-4A47-8F24-CDD127E46596@bsdimp.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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 12 Oct 2012 21:06:07 -0600
Warner Losh <imp@bsdimp.com> wrote:
>
> On Oct 12, 2012, at 8:26 PM, Andrew Turner wrote:
>
> > On Fri, 12 Oct 2012 19:27:15 -0600
> > Warner Losh <imp@bsdimp.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121013170623.37672da1>