Date: Fri, 12 Oct 2012 21:06:07 -0600 From: Warner Losh <imp@bsdimp.com> To: Andrew Turner <andrew@fubar.geek.nz> 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: <3ECCBCA3-D190-4AC0-8292-4B34BD43A45A@bsdimp.com> In-Reply-To: <20121013152610.5f5f72bd@fubar.geek.nz> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >=20 >>=20 >> On Oct 12, 2012, at 7:11 PM, George Neville-Neil wrote: >>>=20 >>> What's the rough outline of what's necessary to do that? I can >>> work on it. >>=20 >> (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. >> (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... > 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.... > 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. Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ECCBCA3-D190-4AC0-8292-4B34BD43A45A>