<div dir="ltr"><p dir="ltr"><br>
On 5 Aug 2015 01:47, "Gedare Bloom" <<a href="mailto:gedare@gwu.edu" target="_blank">gedare@gwu.edu</a>> wrote:<br>
><br>
> On Tue, Aug 4, 2015 at 2:18 PM, Rohini Kulkarni <<a href="mailto:krohini1593@gmail.com" target="_blank">krohini1593@gmail.com</a>> wrote:<br>
> ><br>
> ><br>
> > On Tue, Jul 28, 2015 at 5:51 AM, Pavel Pisa <<a href="mailto:ppisa4lists@pikron.com" target="_blank">ppisa4lists@pikron.com</a>> 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 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 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 rwbarrier?</p><p>Ya, but its not helping either. Actually with the change the boot up is hanging even with read/write permission for .text section. <br></p><p dir="ltr">
><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 arm-rtems4.11-size and<br>
> >> > arm-rtems4.11-nm -S.<br>
> >> ><br>
> >> > From arm-rtems4.11-nm -S I don't see how memset() is accessing .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" target="_blank">gedare@gwu.edu</a>> wrote:<br>
> >> > > On Fri, Jul 24, 2015 at 3:30 AM, Rohini Kulkarni<br>
> >> > > <<a href="mailto:krohini1593@gmail.com" target="_blank">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" target="_blank">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 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 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 me.<br>
> >> > > >><br>
> >> > > >> Which exception and which address? Something is not working 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 ../../../../../.././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 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>
> >> > > ../../../../../../../../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 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" target="_blank">sebastian.huber@embedded-brains.de</a><br>
> >> > > >> PGP : Public key available on request.<br>
> >> > > >><br>
> >> > > >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des<br>
> >> > > >> EHUG.<br>
> >> > > ><br>
> >> > > > _______________________________________________<br>
> >> > > > devel mailing list<br>
> >> > > > <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> >> > > > <a href="http://lists.rtems.org/mailman/listinfo/devel" 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" target="_blank">devel@rtems.org</a><br>
> > <a href="http://lists.rtems.org/mailman/listinfo/devel" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</p>
</div>