[PATCH] GSoC: Cache configurations Raspberry Pi 2 support
Joel Sherrill
joel.sherrill at oarcorp.com
Tue Aug 11 14:09:50 UTC 2015
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