[PATCH] GSoC: Cache configurations Raspberry Pi 2 support
Gedare Bloom
gedare at gwu.edu
Tue Aug 11 14:17:52 UTC 2015
Well, the unwind code is being pulled in for:
Unwind table index '.ARM.exidx' at offset 0xa3fb8 contains 1 entries:
0x9b300 <__divdi3>: 0x1 [cantunwind]
So back-tracking that may also help.
Gedare
On Tue, Aug 11, 2015 at 10:09 AM, Joel Sherrill
<joel.sherrill at oarcorp.com> wrote:
>
>
> On 8/11/2015 9:00 AM, Gedare Bloom wrote:
>>
>> On Tue, Aug 11, 2015 at 9:59 AM, Gedare Bloom <gedare at gwu.edu> wrote:
>>>
>>> Yeah until you or someone can figure out how to get the .ARM.exidx
>>> section from being placed in the .bss, a quick work-around would be to
>>> provide an alternate code to clear the bss that does something like...
>>>
>>> memset(bsp_section_bss_begin, 0, __exidx_start - bsp_section_bss_begin);
>>> memset(__exidx_start, 0, bsp_section_bss_end);
>>>
>> Let me be clear, this is a hack but hopefully will get you past the
>> exception.
>
>
> I don't see any difference between the xilinx BSP and the raspberrypi
> linkcmds. And it looks like the code for section copying/cleaning is
> the same.
>
> Comparing the two for differences might yield something but I am not
> seeing it quickly. :(
>
>
>>> On Tue, Aug 11, 2015 at 9:32 AM, Rohini Kulkarni <krohini1593 at gmail.com>
>>> wrote:
>>>>
>>>> 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
>>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
> --
> Joel Sherrill, Ph.D. Director of Research & Development
> joel.sherrill at OARcorp.com On-Line Applications Research
> Ask me about RTEMS: a free RTOS Huntsville AL 35805
> Support Available (256) 722-9985
More information about the devel
mailing list