[PATCH] GSoC: Cache configurations Raspberry Pi 2 support

Rohini Kulkarni krohini1593 at gmail.com
Tue Aug 11 13:32:13 UTC 2015


OK! So is there any immediate solution which can be tried?

On Tue, Aug 11, 2015 at 6:32 PM, Gedare Bloom <gedare at gwu.edu> wrote:

> I can see the following pertinent information:
> [15] .bss              NOBITS          001156e0 0a8fd8 00fab0 00  WA  0
>  0 32
> The bss section starts at 0x1156e0, has size 0xfab0, and is writeable.
>
> In the symbol table we can see:
>
>   7825: 001156e0     0 NOTYPE  GLOBAL DEFAULT   15 bsp_section_bss_begin
> The bsp_section_bss_begin variable has value 0x1156e0, this is good.
>
>  8729: 0000fab0     0 NOTYPE  GLOBAL DEFAULT  ABS bsp_section_bss_size
> The bsp_section_bss_size is 0xfab0, which is also good.
>
> Looking at the segments I see one possible oddity. Look at the first and
> last
> Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
> EXIDX          0x0a3fb8 0x001106b8 0x001106b8 0x00008 0x00008 R   0x4
> LOAD           0x093900 0x00100000 0x00100000 0x156d8 0x7efc000 RW  0x20
>
> The first one starts inside of the second! This could well be the
> reason for your problem. The .ARM.exidx section is being define
> read-only, and is being put into a segment that overlaps with the
> segment that catches most of the RW memory.
>
> Gedare
>
> On Mon, Aug 10, 2015 at 4:23 PM, Rohini Kulkarni <krohini1593 at gmail.com>
> wrote:
> > I did a readelf on the rki elf. I have attached the file. Is this
> > information helping in anyway?
> >
> > On Wed, Aug 5, 2015 at 9:16 PM, Gedare Bloom <gedare at gwu.edu> wrote:
> >>
> >> In arm/shared/startup/linkcmds.base these barriers are used to add
> >> gaps in the memory layout at link-time to accommodate for the size
> >> requirements of the MMU. xbarrier aligns the executable region,
> >> robarrier aligns the read-only memory, and rwbarrier aligns the
> >> read-write memory.
> >>
> >> On Tue, Aug 4, 2015 at 6:23 PM, Rohini Kulkarni <krohini1593 at gmail.com>
> >> wrote:
> >> >
> >> >
> >> > On Wed, Aug 5, 2015 at 1:47 AM, 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?
> >> >
> >> >
> >> > What exactly are these barriers?
> >> >>
> >> >>
> >> >> 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
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Rohini Kulkarni
> >
> >
> >
> >
> > --
> > Rohini Kulkarni
> >
> > _______________________________________________
> > 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/20150811/f2af751e/attachment-0002.html>


More information about the devel mailing list