Latest code and scripts are working for me on BeagleBone...

[Andrew Turner]

On Fri, 12 Oct 2012 21:06:07 -0600
Warner Losh <imp at 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 at 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