GENERIC kernel issues
Tim Kientzle
kientzle at freebsd.org
Mon Mar 4 16:31:43 UTC 2013
On Mar 3, 2013, at 6:39 PM, Warner Losh wrote:
>
> On Mar 3, 2013, at 12:43 PM, Tim Kientzle wrote:
>
>> I spent some time yesterday putting together a kernel
>> configuration for a GENERIC ARM kernel that would
>> support both RaspberryPi and BeagleBone.
>>
>> Just to see how far I could get.
>>
>> Here's a list of the problems I've found so far:
>>
>> ** Multiple MMU support. If you put these two lines into an
>> ARM kernel config, the build will fail in the MMU code:
>>
>> cpu CPU_ARM1176
>> cpu CPU_CORTEXA
>>
>> Basically, this turns on the support for multiple MMUs but the
>> ARMv6/ARMv7 MMU definitions don't play nicely with run-time
>> MMU selection.
>
> Having looked at the defines, it could be done with variables, but I fear that will slow things down to do a simple #define -> variable. We may need two sets of code for performance…
The MMU management I really know nothing about.
If you do … ;-)
>> ** PHYSADDR/KERNPHYSADDR hardwiring. Ian has made a
>> lot of progress and I'm working on some related changes to
>> address this. I think we understand how to eliminate these
>> constants and replace them with run-time detection of the
>> load address. I'm still not sure what changes might be needed
>> to the loader to make this work.
>>
>> ** PIPT vs. VIVT cache management. This is currently set at compile
>> time; we'll need to have a way to set this at run time based on the
>> CPU. (I have some skeletal code to select CPU at the top of
>> initarm by inspecting the FDT. I presume this switch will be routine
>> once a robust version of that is in place.)
>
> Generally we should be doing this, both for the Core and the SoC. I don't think we do this generally, and we should. It is one of the big advantages of FDT: It tells you what's going on so you don't have to guess....
>
>> ** TI processor detection. This is currently hardwired at build time,
>> so we cannot currently build a kernel that supports both AM335x
>> and OMAP4, for example.
>
> Can't we do this with compat field in the FDT?
I have prototype code that does exactly this, but it needs
a lot of cleanup before it can be committed.
Tim
More information about the freebsd-arm
mailing list