[PATCH] GSoC: Cache configurations Raspberry Pi 2 support

[Rohini Kulkarni]

On Tue, Jul 28, 2015 at 5:51 AM, Pavel Pisa <ppisa4lists at pikron.com> wrote:

> Hello Rohini and Gedare,
>
> On Friday 24 of July 2015 15:33:03 Gedare Bloom wrote:
> > What are the values of bsp_section_bss_begin, and bsp_section_bss_size?
> >
> > Apparently, the memset is trying to write into the .text (code)
> > section, which is a very bad thing to do indeed.
> >
>
> Qiao Yang in RPi 1 BSP now works in the similar
> area to enable right graphic memory mapping.
>
> So my guess is that there could be problem caused
> by used MMU mode granularity, which is is 1 MB so
> if RO and RW sections are present in the same 1MB
> aligned block ten there can be problem. It depends
> which section is filled the first. If data and then
> text (RO) the troubles begin. If the order is vice
> versa then some part of text can be RW instead of RO,
> but it should work and cache should not be a problem.
>
> But I have not dig into this case too much.
> Only short glimpse.
>
> One option is to define 1 MB alignment between text
> ad data for RPi case. There is quite a lot of memory
> when compared to most RTEMS embedded targets to the
> waste is not so important.
>

I didn't quite get what this means. I have no clue on how to proceed with
this.

>
> Best wishes,
>
>               Pavel
>
> On Friday 24 of July 2015 21:55:00 Rohini Kulkarni wrote:
> > Hi,
> >
> > I have attached the report containing outputs of arm-rtems4.11-size and
> > arm-rtems4.11-nm -S.
> >
> > From arm-rtems4.11-nm -S I don't see how memset() is accessing .text
> > section. The start and end values for both are not overlapping.
> >
> > On Fri, Jul 24, 2015 at 7:03 PM, Gedare Bloom <gedare at gwu.edu> wrote:
> > > On Fri, Jul 24, 2015 at 3:30 AM, Rohini Kulkarni <
> krohini1593 at gmail.com>
> > >
> > > wrote:
> > > > On 24 Jul 2015 12:35, "Sebastian Huber" <
> > >
> > > sebastian.huber at embedded-brains.de>
> > >
> > > > wrote:
> > > >> On 23/07/15 23:24, Rohini Kulkarni wrote:
> > > >>> I could finally get back to this issue. I used Pi 1 for debugging,
> > > >>> but the reason for this problem will apply to Pi 2 also.
> > > >>> With text section set to ARMV7_MMU_CODE_CACHED ( which implies read
> > >
> > > only)
> > >
> > > >>> , a data abort exception occurs with memset() inside
> > >
> > > bsp_start_clear_bss()
> > >
> > > >>> function. An illegal write access to an address according to me.
> > > >>
> > > >> Which exception and which address? Something is not working here.
> > > >
> > > > This is a part of the debugging output. When I used
> > >
> > > ARMV7_MMU_CODE_CACHED.
> > >
> > > > (gdb) s
> > > > bsp_start_clear_bss ()
> > > >     at ../../../../../.././raspberrypi/lib/include/bsp/start.h:126
> > > > 126      memset(bsp_section_bss_begin, 0, (size_t)
> > > > bsp_section_bss_size);
> > >
> > > What are the values of bsp_section_bss_begin, and bsp_section_bss_size?
> > >
> > > Apparently, the memset is trying to write into the .text (code)
> > > section, which is a very bad thing to do indeed.
> > >
> > > > (gdb) s
> > > > memset (m=0x1157e0, c=0, n=64176)
> > > >     at ../../../../../gcc-4.9.2/newlib/libc/string/memset.c:59
> > > > 59    ../../../../../gcc-4.9.2/newlib/libc/string/memset.c: No such
> > > > file
> > >
> > > or
> > >
> > > > directory.
> > > > (gdb) s
> > > > 49    in ../../../../../gcc-4.9.2/newlib/libc/string/memset.c
> > > > (gdb) s
> > > > _ARMV4_Exception_data_abort_default ()
> > > >     at
> > >
> > >
> ../../../../../../../../rtems-local/rtems/c/src/../../cpukit/score/cpu/ar
> > >m/armv4-exception-default.S:71
> > >
> > > > 71        sub    sp, #MORE_CONTEXT_SIZE
> > > >
> > > > When I set text section flag to ARMV7_MMU_READ_WRITE, the system
> starts
> > > > successfully.
> > > >
> > > >> --
> > > >> Sebastian Huber, embedded brains GmbH
> > > >>
> > > >> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> > > >> Phone   : +49 89 189 47 41-16
> > > >> Fax     : +49 89 189 47 41-09
> > > >> E-Mail  : sebastian.huber at embedded-brains.de
> > > >> PGP     : Public key available on request.
> > > >>
> > > >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des
> EHUG.
> > > >
> > > > _______________________________________________
> > > > devel mailing list
> > > > devel at rtems.org
> > > > http://lists.rtems.org/mailman/listinfo/devel
>
>


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