[PATCH] GSoC: Cache configurations Raspberry Pi 2 support

Tue Aug 4 22:18:16 UTC 2015

On 5 Aug 2015 01:47, "Gedare Bloom" <gedare at gwu.edu> wrote:
>
> On Tue, Aug 4, 2015 at 2:18 PM, Rohini Kulkarni <krohini1593 at gmail.com>
wrote:
> >
> >
> > 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.
> The MMU defines memory regions in 1MB chunks. Each chunk can have its
> own permissions (read-only, or read-write) set. If the .text and .data
> (or some other section) overlaps in the same 1MB chunk, and the wrong
> permission gets set, then there can be a problem e.g. part of .data
> might be RO or part of .text might be RW.
>
> Did you try the code Sebastian posted? to change the robarrier to
rwbarrier?

Ya, but its not helping either. Actually with the change the boot up is
hanging even with read/write permission for .text section.

>
> Gedare
>
> >>
> >>
> >> 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
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20150805/d7cc4ea6/attachment-0002.html>