Beagleboard stuff

[Mark Tinguely]

On 3/31/2011 11:18 AM, Ben Gray wrote:
> Hi Mark,
>
>     I don't think the OMAP4430 techref manual is available on the TI 
> website, however you can get it via the Pandaboard site:
>
> <http://www.pandaboard.org/content/resources/omap-device>
>
>     In terms of cache coherency - the OMAP4430 has separate L1 caches 
> (32KB inst/32KB data) for each core with a snoop control unit (ARM 
> SCU?) which "ensures memory coherency between the two CPUs".
>
>
>     In regards to the ARMv6/v7 roadmap, have you started work on this? 
> I would love to see some of these changes in the tree and can help out 
> in some areas, however if you look at the hacks in my pmap.c code for 
> armv7 you'll notice that I'm not very experienced in this area of the 
> kernel ;-).
>
>
> Thanks,
> Ben.

The SCU does snoop the internal processors' cache but the external 
processors (DMA) do not snoop the cache, so certain pre and post DMA 
commands still need to flush and/or invalidate the internal caches. 
Since the caches could still be active on any processor (because the 
process is on multiple processors or because the process recently 
switched processors), we have to perform the needed pre/post DMA cache 
operation on every processor. Without the multiprocessing extensions, 
this involves sending a message (IPI) from the current processor to all 
other processors telling them to perform necessary cache operation. 
Multiprocessor extensions performs the cache operations on the remote 
processors without sending a IPI.

I have started to rewrite the easiest parts of the low level code. See 
the "toc.txt" file on my website. These rewrites use instructions 
(ldrex, strex, clrex, isb, dsb, etc) that the current compiler and 
binutils do not understand. A new binutils can be easily dropped into 
the source tree. We need a new compiler that can understand these 
instructions and also be able to generate VFP/Neon user instructions. I 
have been using a hacked up compiler to make kernels but it won't 
compile world and it is starting to become inadequate for kernels also.

I have studied the i386 and amd64 low level routines to see what we 
could use and what we can't use. Right now,  I do not have the financial 
resources to finish a rewrite the low level code.

--Mark.