<div dir="ltr">OK! So is there any immediate solution which can be tried?<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 11, 2015 at 6:32 PM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@gwu.edu" target="_blank">gedare@gwu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I can see the following pertinent information:<br>
[15] .bss NOBITS 001156e0 0a8fd8 00fab0 00 WA 0 0 32<br>
The bss section starts at 0x1156e0, has size 0xfab0, and is writeable.<br>
<br>
In the symbol table we can see:<br>
<br>
7825: 001156e0 0 NOTYPE GLOBAL DEFAULT 15 bsp_section_bss_begin<br>
The bsp_section_bss_begin variable has value 0x1156e0, this is good.<br>
<br>
8729: 0000fab0 0 NOTYPE GLOBAL DEFAULT ABS bsp_section_bss_size<br>
The bsp_section_bss_size is 0xfab0, which is also good.<br>
<br>
Looking at the segments I see one possible oddity. Look at the first and last<br>
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align<br>
EXIDX 0x0a3fb8 0x001106b8 0x001106b8 0x00008 0x00008 R 0x4<br>
LOAD 0x093900 0x00100000 0x00100000 0x156d8 0x7efc000 RW 0x20<br>
<br>
The first one starts inside of the second! This could well be the<br>
reason for your problem. The .ARM.exidx section is being define<br>
read-only, and is being put into a segment that overlaps with the<br>
segment that catches most of the RW memory.<br>
<span class="HOEnZb"><font color="#888888"><br>
Gedare<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Mon, Aug 10, 2015 at 4:23 PM, Rohini Kulkarni <<a href="mailto:krohini1593@gmail.com">krohini1593@gmail.com</a>> wrote:<br>
> I did a readelf on the rki elf. I have attached the file. Is this<br>
> information helping in anyway?<br>
><br>
> On Wed, Aug 5, 2015 at 9:16 PM, Gedare Bloom <<a href="mailto:gedare@gwu.edu">gedare@gwu.edu</a>> wrote:<br>
>><br>
>> In arm/shared/startup/linkcmds.base these barriers are used to add<br>
>> gaps in the memory layout at link-time to accommodate for the size<br>
>> requirements of the MMU. xbarrier aligns the executable region,<br>
>> robarrier aligns the read-only memory, and rwbarrier aligns the<br>
>> read-write memory.<br>
>><br>
>> On Tue, Aug 4, 2015 at 6:23 PM, Rohini Kulkarni <<a href="mailto:krohini1593@gmail.com">krohini1593@gmail.com</a>><br>
>> wrote:<br>
>> ><br>
>> ><br>
>> > On Wed, Aug 5, 2015 at 1:47 AM, Gedare Bloom <<a href="mailto:gedare@gwu.edu">gedare@gwu.edu</a>> wrote:<br>
>> >><br>
>> >> On Tue, Aug 4, 2015 at 2:18 PM, Rohini Kulkarni <<a href="mailto:krohini1593@gmail.com">krohini1593@gmail.com</a>><br>
>> >> wrote:<br>
>> >> ><br>
>> >> ><br>
>> >> > On Tue, Jul 28, 2015 at 5:51 AM, Pavel Pisa <<a href="mailto:ppisa4lists@pikron.com">ppisa4lists@pikron.com</a>><br>
>> >> > wrote:<br>
>> >> >><br>
>> >> >> Hello Rohini and Gedare,<br>
>> >> >><br>
>> >> >> On Friday 24 of July 2015 15:33:03 Gedare Bloom wrote:<br>
>> >> >> > What are the values of bsp_section_bss_begin, and<br>
>> >> >> > bsp_section_bss_size?<br>
>> >> >> ><br>
>> >> >> > Apparently, the memset is trying to write into the .text (code)<br>
>> >> >> > section, which is a very bad thing to do indeed.<br>
>> >> >> ><br>
>> >> >><br>
>> >> >> Qiao Yang in RPi 1 BSP now works in the similar<br>
>> >> >> area to enable right graphic memory mapping.<br>
>> >> >><br>
>> >> >> So my guess is that there could be problem caused<br>
>> >> >> by used MMU mode granularity, which is is 1 MB so<br>
>> >> >> if RO and RW sections are present in the same 1MB<br>
>> >> >> aligned block ten there can be problem. It depends<br>
>> >> >> which section is filled the first. If data and then<br>
>> >> >> text (RO) the troubles begin. If the order is vice<br>
>> >> >> versa then some part of text can be RW instead of RO,<br>
>> >> >> but it should work and cache should not be a problem.<br>
>> >> >><br>
>> >> >> But I have not dig into this case too much.<br>
>> >> >> Only short glimpse.<br>
>> >> >><br>
>> >> >> One option is to define 1 MB alignment between text<br>
>> >> >> ad data for RPi case. There is quite a lot of memory<br>
>> >> >> when compared to most RTEMS embedded targets to the<br>
>> >> >> waste is not so important.<br>
>> >> ><br>
>> >> ><br>
>> >> > I didn't quite get what this means. I have no clue on how to proceed<br>
>> >> > with<br>
>> >> > this.<br>
>> >> The MMU defines memory regions in 1MB chunks. Each chunk can have its<br>
>> >> own permissions (read-only, or read-write) set. If the .text and .data<br>
>> >> (or some other section) overlaps in the same 1MB chunk, and the wrong<br>
>> >> permission gets set, then there can be a problem e.g. part of .data<br>
>> >> might be RO or part of .text might be RW.<br>
>> >><br>
>> >> Did you try the code Sebastian posted? to change the robarrier to<br>
>> >> rwbarrier?<br>
>> ><br>
>> ><br>
>> > What exactly are these barriers?<br>
>> >><br>
>> >><br>
>> >> Gedare<br>
>> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> Best wishes,<br>
>> >> >><br>
>> >> >> Pavel<br>
>> >> >><br>
>> >> >> On Friday 24 of July 2015 21:55:00 Rohini Kulkarni wrote:<br>
>> >> >> > Hi,<br>
>> >> >> ><br>
>> >> >> > I have attached the report containing outputs of<br>
>> >> >> > arm-rtems4.11-size<br>
>> >> >> > and<br>
>> >> >> > arm-rtems4.11-nm -S.<br>
>> >> >> ><br>
>> >> >> > From arm-rtems4.11-nm -S I don't see how memset() is accessing<br>
>> >> >> > .text<br>
>> >> >> > section. The start and end values for both are not overlapping.<br>
>> >> >> ><br>
>> >> >> > On Fri, Jul 24, 2015 at 7:03 PM, Gedare Bloom <<a href="mailto:gedare@gwu.edu">gedare@gwu.edu</a>><br>
>> >> >> > wrote:<br>
>> >> >> > > On Fri, Jul 24, 2015 at 3:30 AM, Rohini Kulkarni<br>
>> >> >> > > <<a href="mailto:krohini1593@gmail.com">krohini1593@gmail.com</a>><br>
>> >> >> > ><br>
>> >> >> > > wrote:<br>
>> >> >> > > > On 24 Jul 2015 12:35, "Sebastian Huber" <<br>
>> >> >> > ><br>
>> >> >> > > <a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>><br>
>> >> >> > ><br>
>> >> >> > > > wrote:<br>
>> >> >> > > >> On 23/07/15 23:24, Rohini Kulkarni wrote:<br>
>> >> >> > > >>> I could finally get back to this issue. I used Pi 1 for<br>
>> >> >> > > >>> debugging,<br>
>> >> >> > > >>> but the reason for this problem will apply to Pi 2 also.<br>
>> >> >> > > >>> With text section set to ARMV7_MMU_CODE_CACHED ( which<br>
>> >> >> > > >>> implies<br>
>> >> >> > > >>> read<br>
>> >> >> > ><br>
>> >> >> > > only)<br>
>> >> >> > ><br>
>> >> >> > > >>> , a data abort exception occurs with memset() inside<br>
>> >> >> > ><br>
>> >> >> > > bsp_start_clear_bss()<br>
>> >> >> > ><br>
>> >> >> > > >>> function. An illegal write access to an address according to<br>
>> >> >> > > >>> me.<br>
>> >> >> > > >><br>
>> >> >> > > >> Which exception and which address? Something is not working<br>
>> >> >> > > >> here.<br>
>> >> >> > > ><br>
>> >> >> > > > This is a part of the debugging output. When I used<br>
>> >> >> > ><br>
>> >> >> > > ARMV7_MMU_CODE_CACHED.<br>
>> >> >> > ><br>
>> >> >> > > > (gdb) s<br>
>> >> >> > > > bsp_start_clear_bss ()<br>
>> >> >> > > > at<br>
>> >> >> > > > ../../../../../.././raspberrypi/lib/include/bsp/start.h:126<br>
>> >> >> > > > 126 memset(bsp_section_bss_begin, 0, (size_t)<br>
>> >> >> > > > bsp_section_bss_size);<br>
>> >> >> > ><br>
>> >> >> > > What are the values of bsp_section_bss_begin, and<br>
>> >> >> > > bsp_section_bss_size?<br>
>> >> >> > ><br>
>> >> >> > > Apparently, the memset is trying to write into the .text (code)<br>
>> >> >> > > section, which is a very bad thing to do indeed.<br>
>> >> >> > ><br>
>> >> >> > > > (gdb) s<br>
>> >> >> > > > memset (m=0x1157e0, c=0, n=64176)<br>
>> >> >> > > > at ../../../../../gcc-4.9.2/newlib/libc/string/memset.c:59<br>
>> >> >> > > > 59 ../../../../../gcc-4.9.2/newlib/libc/string/memset.c: No<br>
>> >> >> > > > such<br>
>> >> >> > > > file<br>
>> >> >> > ><br>
>> >> >> > > or<br>
>> >> >> > ><br>
>> >> >> > > > directory.<br>
>> >> >> > > > (gdb) s<br>
>> >> >> > > > 49 in ../../../../../gcc-4.9.2/newlib/libc/string/memset.c<br>
>> >> >> > > > (gdb) s<br>
>> >> >> > > > _ARMV4_Exception_data_abort_default ()<br>
>> >> >> > > > at<br>
>> >> >> > ><br>
>> >> >> > ><br>
>> >> >> > ><br>
>> >> >> > ><br>
>> >> >> > > ../../../../../../../../rtems-local/rtems/c/src/../../cpukit/score/cpu/ar<br>
>> >> >> > >m/armv4-exception-default.S:71<br>
>> >> >> > ><br>
>> >> >> > > > 71 sub sp, #MORE_CONTEXT_SIZE<br>
>> >> >> > > ><br>
>> >> >> > > > When I set text section flag to ARMV7_MMU_READ_WRITE, the<br>
>> >> >> > > > system<br>
>> >> >> > > > starts<br>
>> >> >> > > > successfully.<br>
>> >> >> > > ><br>
>> >> >> > > >> --<br>
>> >> >> > > >> Sebastian Huber, embedded brains GmbH<br>
>> >> >> > > >><br>
>> >> >> > > >> Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
>> >> >> > > >> Phone : +49 89 189 47 41-16<br>
>> >> >> > > >> Fax : +49 89 189 47 41-09<br>
>> >> >> > > >> E-Mail : <a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a><br>
>> >> >> > > >> PGP : Public key available on request.<br>
>> >> >> > > >><br>
>> >> >> > > >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne<br>
>> >> >> > > >> des<br>
>> >> >> > > >> EHUG.<br>
>> >> >> > > ><br>
>> >> >> > > > _______________________________________________<br>
>> >> >> > > > devel mailing list<br>
>> >> >> > > > <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
>> >> >> > > > <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>> >> >><br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > --<br>
>> >> > Rohini Kulkarni<br>
>> >> ><br>
>> >> > _______________________________________________<br>
>> >> > devel mailing list<br>
>> >> > <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
>> >> > <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Rohini Kulkarni<br>
><br>
><br>
><br>
><br>
> --<br>
> Rohini Kulkarni<br>
><br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr">Rohini Kulkarni</div></div>
</div>