GSoC 2015: Raspberry Pi 2 Support

[Rohini Kulkarni]

Hi All,

I have to implement the cache coherency support for Cortex A7. But for A7
MPCore, unlike for A9, I am not able to find any register description for
the Snoop Control Unit from the TRM.
I need help here on how to proceed.

Additionally for A9 there is a single bit for A9 in the Auxiliary Control
Register which enables cache broadcast operations. The register format is
different for A7 and again I am unable to find how to achieve the same for
A7.

Thanks!




On Tue, May 5, 2015 at 10:42 PM, Joel Sherrill <joel.sherrill at oarcorp.com>
wrote:

>
>
> On 5/5/2015 11:11 AM, Rohini Kulkarni wrote:
>
> Hi,
>
> I am working with the code for bsp hooks. I am referring to existing ARM
> multicore bsp codes, zync mainly.
>
> 1. There are existing hooks for the raspberry pi. Where should the code
> for the  Pi2 hooks be added?
>
> The Pi and Pi2 are remarkably similar so Pi2 should be placed inside the
> Pi BSP directory.
> There is already a Pi2 variant of that code built. But we know specific
> places where there
> are variances. Depending on the scope of what is different, it can be as
> simple as
> a cpp conditional in a .h to select a value or two implementations of a
> single method
> and the Makefile.am picking the right file to build based on the board
> variant.
>
> The big question to always ask is: Is this specific to the Pi2 and
> incompatible with the Pi?
>
> Since the Pi BSP is still missing capabilities, it is likely code common
> to both will
> be added this summer. For example, did the mailbox interface change? I
> don't know
> but would guess that it didn't.  Each new capability added needs that
> added.
>
> And any differences need to be analyzed to pick the least intrusive way to
> provide
> alternate implementations. Or enable special code like the Pi2 SMP support
> which
> is dependent on --enable-smp and being a Pi2.
>
> 2. Am I right in understanding that I will have to implement A7 specific
> functions as have been for A9? I am referring specifically to the
> arm-a9mpcore-start.h
>
> Yes.
>
> If the code is very similar between the a7 and a9, then a discussion
> on devel@ should occur to decide the best way to minimize duplication.
>
> If you end up with a7 specific code, you should follow the location and
> naming patterns already established. That places it in
> libbsp/arm/shared/...
> so it can be used by any BSP with the right SMP core.
>
>
>  I am referring to existing codes to locate and get hold of what needs to
> be done in the hooks. However, being new to such implementations, I am
> taking longer to understand the details. Any suggestions that might help
> here are welcome
>
> The answer will depend on the factors listed above. When code can
> be shared, we want to share it across as many BSPs as makes sense.
> When it is unique to a specific BSP **variant** (e.g. Pi vs Pi2), then
> you want to find the way to account for the variation in the least
> intrusive code way possible.
>
> Thanks!
> On 1 May 2015 12:45, "Rohini Kulkarni" <krohini1593 at gmail.com> wrote:
>
>>
>>  Hi,
>>
>>  Excited to be a part of  this edition of GSoC! Thanks to everybody for
>> helping me get here and congratulations to all the participating students!
>>
>>  So, now getting to work, firstly I wish to know, specifically from my
>> mentors, any changes that must be made to my proposed project or schedule.
>>
>> Secondly, are there any specifics for the development blog that we need
>> to create for the project? Over time what is the blog expected to convey.
>>
>> Also, I have to create a new wiki page for my project as none exists. I
>> want to know how to add one.
>>
>>  --
>>  Rohini Kulkarni
>>
>
> --
> Joel Sherrill, Ph.D.             Director of Research & Developmentjoel.sherrill at OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985
>
>


-- 
Rohini Kulkarni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20150528/28b5f1a5/attachment-0002.html>