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

[Warner Losh]

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.

>> (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