On 8/11/2015 9:00 AM, Gedare Bloom wrote:
On Tue, Aug 11, 2015 at 9:59 AM, Gedare Bloom <ged...@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 <krohini1...@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 <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
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
