[PATCH] GSoC: Cache configurations Raspberry Pi 2 support
Gedare Bloom
gedare at gwu.edu
Tue Aug 11 13:02:03 UTC 2015
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
More information about the devel
mailing list