Date: Sat, 13 Oct 2012 15:26:10 +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: <20121013152610.5f5f72bd@fubar.geek.nz> In-Reply-To: <82A753B1-B6EE-4B6A-9B5E-7F09FC5E1266@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > (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. 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. Having a look at the SoCs we support the only one I can see that might cause us problems is sa11x0. Andrew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121013152610.5f5f72bd>