Re: Fwd: Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
On 12/08/2015 6:02 am, Rohini Kulkarni wrote: Yes I have tried this. Didn't work out :( What was the reason ? I do not remembering seeing it. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
Well, the unwind code is being pulled in for: Unwind table index '.ARM.exidx' at offset 0xa3fb8 contains 1 entries: 0x9b300 __divdi3: 0x1 [cantunwind] So back-tracking that may also help. Gedare On Tue, Aug 11, 2015 at 10:09 AM, Joel Sherrill joel.sherr...@oarcorp.com wrote: 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: fab0 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 0x8 0x8 R 0x4 LOAD 0x093900 0x0010 0x0010 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.
Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
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: fab0 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 0x8 0x8 R 0x4 LOAD 0x093900 0x0010 0x0010 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
Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
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. 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: fab0 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 0x8 0x8 R 0x4 LOAD 0x093900 0x0010 0x0010 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,
Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
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); 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: fab0 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 0x8 0x8 R 0x4 LOAD 0x093900 0x0010 0x0010 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
Re: Fwd: Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
Yes I have tried this. Didn't work out :( On 11 Aug 2015 19:56, Joel Sherrill joel.sherr...@oarcorp.com wrote: Hi Has this been tried? Forwarded Message Subject: Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support Date: Tue, 28 Jul 2015 01:57:44 -0500 From: Sebastian Huber sebastian.hu...@embedded-brains.de To: Rohini Kulkarni krohini1...@gmail.com, Gedare Bloom ged...@gwu.edu CC: rtems-de...@rtems.org devel@rtems.org On 24/07/15 21:55, 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. Maybe this patch helps: diff --git a/c/src/lib/libbsp/arm/raspberrypi/startup/linkcmds b/c/src/lib/libbsp/arm/raspberrypi/startup/linkcmds index f1ad11c..f3b6232 100644 --- a/c/src/lib/libbsp/arm/raspberrypi/startup/linkcmds +++ b/c/src/lib/libbsp/arm/raspberrypi/startup/linkcmds @@ -62,7 +62,8 @@ REGION_ALIAS (REGION_NOCACHE_LOAD, RAM); bsp_stack_irq_size = DEFINED (bsp_stack_irq_size) ? bsp_stack_irq_size : 4096; bsp_stack_abt_size = DEFINED (bsp_stack_abt_size) ? bsp_stack_abt_size : 1024; -bsp_section_robarrier_align = DEFINED (bsp_section_robarrier_align) ? bsp_section_robarrier_align : 1M; +bsp_section_rwbarrier_align = DEFINED (bsp_section_rwbarrier_align) ? bsp_section_rwbarrier_align : 1M; + bsp_translation_table_base = ORIGIN (RAM_MMU); INCLUDE linkcmds.armv4 -- 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
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 49in ../../../../../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 71subsp, #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
Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
On 5 Aug 2015 01:47, 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? Ya, but its not helping either. Actually with the change the boot up is hanging even with read/write permission for .text section. 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 49in ../../../../../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 71subsp, #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 ___ devel mailing
Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
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 49in ../../../../../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 71subsp, #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 ___ devel mailing list devel@rtems.org
Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
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. 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 49in ../../../../../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 71subsp, #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
Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
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? 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 49in ../../../../../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 71subsp, #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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
On 24/07/15 21:55, 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. Maybe this patch helps: diff --git a/c/src/lib/libbsp/arm/raspberrypi/startup/linkcmds b/c/src/lib/libbsp/arm/raspberrypi/startup/linkcmds index f1ad11c..f3b6232 100644 --- a/c/src/lib/libbsp/arm/raspberrypi/startup/linkcmds +++ b/c/src/lib/libbsp/arm/raspberrypi/startup/linkcmds @@ -62,7 +62,8 @@ REGION_ALIAS (REGION_NOCACHE_LOAD, RAM); bsp_stack_irq_size = DEFINED (bsp_stack_irq_size) ? bsp_stack_irq_size : 4096; bsp_stack_abt_size = DEFINED (bsp_stack_abt_size) ? bsp_stack_abt_size : 1024; -bsp_section_robarrier_align = DEFINED (bsp_section_robarrier_align) ? bsp_section_robarrier_align : 1M; +bsp_section_rwbarrier_align = DEFINED (bsp_section_rwbarrier_align) ? bsp_section_rwbarrier_align : 1M; + bsp_translation_table_base = ORIGIN (RAM_MMU); INCLUDE linkcmds.armv4 -- 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
Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
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. 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 49in ../../../../../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 71subsp, #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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
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. -- 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
Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
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); (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 49in ../../../../../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/arm/armv4-exception-default.S:71 71subsp, #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
Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
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) These memset parameters indicate the start location bsp_section_bss_begin and size of bss section bsp_section_bss_size. 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 49in ../../../../../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/arm/armv4-exception-default.S:71 71subsp, #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
Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
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 49in ../../../../../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/arm/armv4-exception-default.S:71 71subsp, #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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
On Tue, Jun 23, 2015 at 4:27 PM, Rohini Kulkarni krohini1...@gmail.com
wrote:
On Tue, Jun 23, 2015 at 1:44 PM, Sebastian Huber
sebastian.hu...@embedded-brains.de wrote:
Please avoid unnecessary white-space changes and white-space at the end
of line.
Something went wrong with the whitespace. I couldn't see that change in
my code. I'll rectify it.
On 22/06/15 22:59, Rohini Kulkarni wrote:
---
.../arm/raspberrypi/startup/mm_config_table.c | 18
+++
c/src/lib/libbsp/arm/shared/mminit.c | 23
2 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c
b/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c
index 8a6d37a..dd1941e 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c
+++ b/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c
@@ -31,39 +31,39 @@ const arm_cp15_start_section_config
arm_cp15_start_mmu_config_table[] = {
}, {
.begin = (uint32_t) bsp_section_fast_data_begin,
.end = (uint32_t) bsp_section_fast_data_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_start_begin,
.end = (uint32_t) bsp_section_start_end,
-.flags = ARMV7_MMU_CODE_CACHED
+.flags = ARMV7_MMU_CODE_CACHED
}, {
.begin = (uint32_t) bsp_section_vector_begin,
.end = (uint32_t) bsp_section_vector_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_text_begin,
.end = (uint32_t) bsp_section_text_end,
-.flags = ARMV7_MMU_READ_WRITE
+.flags = ARMV7_MMU_READ_WRITE | ARM_MMU_SECT_C | ARM_MMU_SECT_B
Why is this not ARMV7_MMU_CODE_CACHED? Why can't this BSP use
ARMV7_CP15_START_DEFAULT_SECTIONS?
One question that came up when I figured out last night that this was the
only required change. This was the only uncached normal memory section in
the table. So there were many changes I tried before I made this cacheable.
Why was it not made cacheable (MMU_CODE_CACHED is read only. But then yes,
why is this made read write, differently from
ARMV7_CP15_START_DEFAULT_SECTIONS)
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.
Making this text section ARMV7_MMU_READ_WRITE causes no problem.
The TEX bits 2 and 1 have been assigned the value for cacheable memory but
are used in the defines for CACHED sections.
}, {
.begin = (uint32_t) bsp_section_rodata_begin,
.end = (uint32_t) bsp_section_rodata_end,
-.flags = ARMV7_MMU_DATA_READ_ONLY_CACHED
+.flags = ARMV7_MMU_DATA_READ_ONLY_CACHED
}, {
.begin = (uint32_t) bsp_section_data_begin,
.end = (uint32_t) bsp_section_data_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_bss_begin,
.end = (uint32_t) bsp_section_bss_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_work_begin,
.end = (uint32_t) bsp_section_work_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_stack_begin,
.end = (uint32_t) bsp_section_stack_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = RPI_PERIPHERAL_BASE,
.end = RPI_PERIPHERAL_BASE + RPI_PERIPHERAL_SIZE,
diff --git a/c/src/lib/libbsp/arm/shared/mminit.c
b/c/src/lib/libbsp/arm/shared/mminit.c
index acfbfc0..96ca1ec 100644
--- a/c/src/lib/libbsp/arm/shared/mminit.c
+++ b/c/src/lib/libbsp/arm/shared/mminit.c
@@ -13,6 +13,28 @@
#include bsp/linker-symbols.h
#include bsp/mm.h
+#if (BSP_IS_RPI2 == 1)
Such a construct in a shared folder makes no sense.
Thats right. Will change the integration for the two memory
initializations
+BSP_START_TEXT_SECTION void bsp_memory_management_initialize(void)
+{
+ /* Enable SMP in auxiliary control */
+ uint32_t actlr = arm_cp15_get_auxiliary_control();
+ actlr |= ARM_CORTEX_A9_ACTL_SMP;
+ arm_cp15_set_auxiliary_control(actlr);
+
+ uint32_t ctrl = arm_cp15_start_setup_mmu_and_cache(
+ARM_CP15_CTRL_A,
+ARM_CP15_CTRL_AFE| ARM_CP15_CTRL_Z
+ );
+
+ arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache(
+ctrl,
+(uint32_t *) bsp_translation_table_base,
+ARM_MMU_DEFAULT_CLIENT_DOMAIN,
+arm_cp15_start_mmu_config_table[0],
+
Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
Please avoid unnecessary white-space changes and white-space at the end
of line.
On 22/06/15 22:59, Rohini Kulkarni wrote:
---
.../arm/raspberrypi/startup/mm_config_table.c | 18 +++
c/src/lib/libbsp/arm/shared/mminit.c | 23
2 files changed, 32 insertions(+), 9 deletions(-)
diff --git
a/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c
b/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c
index 8a6d37a..dd1941e 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c
+++ b/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c
@@ -31,39 +31,39 @@ const arm_cp15_start_section_config
arm_cp15_start_mmu_config_table[] = {
}, {
.begin = (uint32_t) bsp_section_fast_data_begin,
.end = (uint32_t) bsp_section_fast_data_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_start_begin,
.end = (uint32_t) bsp_section_start_end,
-.flags = ARMV7_MMU_CODE_CACHED
+.flags = ARMV7_MMU_CODE_CACHED
}, {
.begin = (uint32_t) bsp_section_vector_begin,
.end = (uint32_t) bsp_section_vector_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_text_begin,
.end = (uint32_t) bsp_section_text_end,
-.flags = ARMV7_MMU_READ_WRITE
+.flags = ARMV7_MMU_READ_WRITE | ARM_MMU_SECT_C | ARM_MMU_SECT_B
Why is this not ARMV7_MMU_CODE_CACHED? Why can't this BSP use
ARMV7_CP15_START_DEFAULT_SECTIONS?
}, {
.begin = (uint32_t) bsp_section_rodata_begin,
.end = (uint32_t) bsp_section_rodata_end,
-.flags = ARMV7_MMU_DATA_READ_ONLY_CACHED
+.flags = ARMV7_MMU_DATA_READ_ONLY_CACHED
}, {
.begin = (uint32_t) bsp_section_data_begin,
.end = (uint32_t) bsp_section_data_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_bss_begin,
.end = (uint32_t) bsp_section_bss_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_work_begin,
.end = (uint32_t) bsp_section_work_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_stack_begin,
.end = (uint32_t) bsp_section_stack_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = RPI_PERIPHERAL_BASE,
.end = RPI_PERIPHERAL_BASE + RPI_PERIPHERAL_SIZE,
diff --git a/c/src/lib/libbsp/arm/shared/mminit.c
b/c/src/lib/libbsp/arm/shared/mminit.c
index acfbfc0..96ca1ec 100644
--- a/c/src/lib/libbsp/arm/shared/mminit.c
+++ b/c/src/lib/libbsp/arm/shared/mminit.c
@@ -13,6 +13,28 @@
#include bsp/linker-symbols.h
#include bsp/mm.h
+#if (BSP_IS_RPI2 == 1)
Such a construct in a shared folder makes no sense.
+BSP_START_TEXT_SECTION void bsp_memory_management_initialize(void)
+{
+ /* Enable SMP in auxiliary control */
+ uint32_t actlr = arm_cp15_get_auxiliary_control();
+ actlr |= ARM_CORTEX_A9_ACTL_SMP;
+ arm_cp15_set_auxiliary_control(actlr);
+
+ uint32_t ctrl = arm_cp15_start_setup_mmu_and_cache(
+ARM_CP15_CTRL_A,
+ARM_CP15_CTRL_AFE| ARM_CP15_CTRL_Z
+ );
+
+ arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache(
+ctrl,
+(uint32_t *) bsp_translation_table_base,
+ARM_MMU_DEFAULT_CLIENT_DOMAIN,
+arm_cp15_start_mmu_config_table[0],
+arm_cp15_start_mmu_config_table_size
+ );
+}
+#else
BSP_START_TEXT_SECTION void bsp_memory_management_initialize(void)
{
uint32_t ctrl = arm_cp15_get_control();
@@ -27,3 +49,4 @@ BSP_START_TEXT_SECTION void
bsp_memory_management_initialize(void)
arm_cp15_start_mmu_config_table_size
);
}
+#endif
\ No newline at end of file
--
1.7.9.5
--
Rohini Kulkarni
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
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
Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
On Tue, Jun 23, 2015 at 1:44 PM, Sebastian Huber
sebastian.hu...@embedded-brains.de wrote:
Please avoid unnecessary white-space changes and white-space at the end of
line.
Something went wrong with the whitespace. I couldn't see that change in my
code. I'll rectify it.
On 22/06/15 22:59, Rohini Kulkarni wrote:
---
.../arm/raspberrypi/startup/mm_config_table.c | 18 +++
c/src/lib/libbsp/arm/shared/mminit.c | 23
2 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c
b/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c
index 8a6d37a..dd1941e 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c
+++ b/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c
@@ -31,39 +31,39 @@ const arm_cp15_start_section_config
arm_cp15_start_mmu_config_table[] = {
}, {
.begin = (uint32_t) bsp_section_fast_data_begin,
.end = (uint32_t) bsp_section_fast_data_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_start_begin,
.end = (uint32_t) bsp_section_start_end,
-.flags = ARMV7_MMU_CODE_CACHED
+.flags = ARMV7_MMU_CODE_CACHED
}, {
.begin = (uint32_t) bsp_section_vector_begin,
.end = (uint32_t) bsp_section_vector_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_text_begin,
.end = (uint32_t) bsp_section_text_end,
-.flags = ARMV7_MMU_READ_WRITE
+.flags = ARMV7_MMU_READ_WRITE | ARM_MMU_SECT_C | ARM_MMU_SECT_B
Why is this not ARMV7_MMU_CODE_CACHED? Why can't this BSP use
ARMV7_CP15_START_DEFAULT_SECTIONS?
One question that came up when I figured out last night that this was the
only required change. This was the only uncached normal memory section in
the table. So there were many changes I tried before I made this cacheable.
Why was it not made cacheable (MMU_CODE_CACHED is read only. But then yes,
why is this made read write, differently from
ARMV7_CP15_START_DEFAULT_SECTIONS)
The TEX bits 2 and 1 have been assigned the value for cacheable memory but
are used in the defines for CACHED sections.
}, {
.begin = (uint32_t) bsp_section_rodata_begin,
.end = (uint32_t) bsp_section_rodata_end,
-.flags = ARMV7_MMU_DATA_READ_ONLY_CACHED
+.flags = ARMV7_MMU_DATA_READ_ONLY_CACHED
}, {
.begin = (uint32_t) bsp_section_data_begin,
.end = (uint32_t) bsp_section_data_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_bss_begin,
.end = (uint32_t) bsp_section_bss_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_work_begin,
.end = (uint32_t) bsp_section_work_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_stack_begin,
.end = (uint32_t) bsp_section_stack_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = RPI_PERIPHERAL_BASE,
.end = RPI_PERIPHERAL_BASE + RPI_PERIPHERAL_SIZE,
diff --git a/c/src/lib/libbsp/arm/shared/mminit.c
b/c/src/lib/libbsp/arm/shared/mminit.c
index acfbfc0..96ca1ec 100644
--- a/c/src/lib/libbsp/arm/shared/mminit.c
+++ b/c/src/lib/libbsp/arm/shared/mminit.c
@@ -13,6 +13,28 @@
#include bsp/linker-symbols.h
#include bsp/mm.h
+#if (BSP_IS_RPI2 == 1)
Such a construct in a shared folder makes no sense.
Thats right. Will change the integration for the two memory initializations
+BSP_START_TEXT_SECTION void bsp_memory_management_initialize(void)
+{
+ /* Enable SMP in auxiliary control */
+ uint32_t actlr = arm_cp15_get_auxiliary_control();
+ actlr |= ARM_CORTEX_A9_ACTL_SMP;
+ arm_cp15_set_auxiliary_control(actlr);
+
+ uint32_t ctrl = arm_cp15_start_setup_mmu_and_cache(
+ARM_CP15_CTRL_A,
+ARM_CP15_CTRL_AFE| ARM_CP15_CTRL_Z
+ );
+
+ arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache(
+ctrl,
+(uint32_t *) bsp_translation_table_base,
+ARM_MMU_DEFAULT_CLIENT_DOMAIN,
+arm_cp15_start_mmu_config_table[0],
+arm_cp15_start_mmu_config_table_size
+ );
+}
+#else
BSP_START_TEXT_SECTION void bsp_memory_management_initialize(void)
{
uint32_t ctrl = arm_cp15_get_control();
@@ -27,3 +49,4 @@ BSP_START_TEXT_SECTION void
bsp_memory_management_initialize(void)
arm_cp15_start_mmu_config_table_size
);
}
+#endif
\ No newline at end of file
--
1.7.9.5
--
Rohini Kulkarni
___
devel mailing list
devel@rtems.org
