OK! So is there any immediate solution which can be tried? On Tue, Aug 11, 2015 at 6:32 PM, Gedare Bloom <ged...@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 <krohini1...@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 <ged...@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 <krohini1...@gmail.com> > >> wrote: > >> > > >> > > >> > On Wed, Aug 5, 2015 at 1:47 AM, Gedare Bloom <ged...@gwu.edu> wrote: > >> >> > >> >> On Tue, Aug 4, 2015 at 2:18 PM, Rohini Kulkarni < > krohini1...@gmail.com> > >> >> wrote: > >> >> > > >> >> > > >> >> > On Tue, Jul 28, 2015 at 5:51 AM, Pavel Pisa < > ppisa4li...@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 <ged...@gwu.edu> > >> >> >> > wrote: > >> >> >> > > On Fri, Jul 24, 2015 at 3:30 AM, Rohini Kulkarni > >> >> >> > > <krohini1...@gmail.com> > >> >> >> > > > >> >> >> > > wrote: > >> >> >> > > > On 24 Jul 2015 12:35, "Sebastian Huber" < > >> >> >> > > > >> >> >> > > sebastian.hu...@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.hu...@embedded-brains.de > >> >> >> > > >> PGP : Public key available on request. > >> >> >> > > >> > >> >> >> > > >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne > >> >> >> > > >> des > >> >> >> > > >> EHUG. > >> >> >> > > > > >> >> >> > > > _______________________________________________ > >> >> >> > > > devel mailing list > >> >> >> > > > devel@rtems.org > >> >> >> > > > http://lists.rtems.org/mailman/listinfo/devel > >> >> >> > >> >> > > >> >> > > >> >> > > >> >> > -- > >> >> > Rohini Kulkarni > >> >> > > >> >> > _______________________________________________ > >> >> > devel mailing list > >> >> > devel@rtems.org > >> >> > http://lists.rtems.org/mailman/listinfo/devel > >> > > >> > > >> > > >> > > >> > -- > >> > Rohini Kulkarni > > > > > > > > > > -- > > Rohini Kulkarni > > > > _______________________________________________ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > -- Rohini Kulkarni
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
